[x264-devel] [patch] x264 --sar in mp4 container

[vmrsss]

On 12 May 2008, at 18:09, vmrsss wrote:
> Hi Loren,
>
> On 11 May 2008, at 17:30, Loren Merritt wrote:
>> On Sat, 10 May 2008, vmrsss wrote:
>>
>>> Inspecting the code shows that in fact the DAR is not computed  
>>> from the frame
>>> size and the SAR. The patch attached just does this, and then  
>>> calls a
>>> suitable GPAC function to set the "Indicated track size". Can this  
>>> please be
>>> considered for inclusion in the build tree?
>>
>> From the <<16, I assume that mp4 supports sub-pixel precision? In  
>> that
>> case, don't perform intermediate rounding.
>
> Well spotted. Inspecting gpac, I gathered that the code expects u32  
> which then interprets as 16.16 fixed point floats, and indeed I am  
> using 16.0, as I set the lower 16 bits to zero.
>
> I don't know what the effect of a fractional display size would be  
> on players (and I am not able to do any tests for the next couple of  
> days), but if you think that's the way to go, I can clearly change  
> the code easily.
>
> A related issue is whether or not we want the command lines
>
>> x264 [OPTS] -o test.mp4
>
> and
>
>> x264 [OPTS] -o test.264; MP4Box -add test.264 -new test.mp4
>
> to give the same result, in which case we ought to check whether or  
> not MP4Box drops the lower 16 bits when imports h264 raw streams  
> (which I think it does).

Loren I changed the code as you suggested. New patch attached. Tested  
with mplayer. VLC, and QT, seems to work fine. (There can be a  
difference of +/- 1bit in playack size, because some player truncate  
the fractional part of the size, and others round it up. Not a real  
problem, I'd say,)

Cheers.
vmrsss

-------------- next part --------------
A non-text attachment was scrubbed...
Name: sar_mp4-2.patch
Type: application/octet-stream
Size: 846 bytes
Desc: not available
Url : http://mailman.videolan.org/pipermail/x264-devel/attachments/20080514/8c3525ff/attachment.obj