[MEncoder-users] V210 Codec

[Larry Reznick]

Reimar Döffinger wrote:
> Hello,
>
> Please do not quote parts you do not directly reply to.
>   

Hi, Reimar. Thanks for your contribution to this.

I've seen so much variance in quoting here that I figured it would be 
safest to quote the entire discussion.


> On Wed, Feb 18, 2009 at 08:29:48AM -0800, Larry Reznick wrote:
>   
>> the resulting file is 1,829,939,518 bytes long with 1752 frames. Its 
>> YUV4MPEG2 header shows:
>>
>> $ head -1 spirit_720p.y4m
>> YUV4MPEG2 W1280 H544 F12570329:524288 Ip A1:1
>>     
>
> Either you used an old MPlayer version or something is wrong with your
> source file. -fps 24000/1001 results in a file with "F6285171:262144"
> for me.
>   

No, I didn't use an old MPlayer version, nor is there anything peculiar 
about the input source. Here's the output of that particular run:

====8<====
$ time mplayer -nocache -nosound -vo yuv4mpeg:file=spirit_720p_2.y4m 
~/movies/trailers/the_spirit_h720p.mov
MPlayer SVN-r28635-4.3.0 (C) 2000-2009 MPlayer Team
138 audio & 293 video codecs

Playing /home/lreznick/movies/trailers/the_spirit_h720p.mov.
libavformat file format detected.
[lavf] Video stream found, -vid 0
[lavf] Audio stream found, -aid 1
VIDEO:  [avc1]  1280x544  24bpp  23.976 fps    0.0 kbps ( 0.0 kbyte/s)
Clip info:
 name: The Spirit
 copyright:  2008 Lionsgate Films. All Rights Reserved
 comments: Encoded and delivered by apple.com/trailers/
Using (default) progressive frame 
mode.==========================================================================
Opening video decoder: [ffmpeg] FFmpeg's libavcodec codec family
Selected video codec: [ffh264] vfm: ffmpeg (FFmpeg H.264)
==========================================================================
Audio: no sound
Starting playback...
VDec: vo config request - 1280 x 544 (preferred colorspace: Planar YV12)
VDec: using Planar YV12 as output csp (no 0)
Movie-Aspect is undefined - no prescaling applied.
VO: [yuv4mpeg] 1280x544 => 1280x544 Planar YV12
V:  73.0   0/  0  9% 11%  0.0% 0 0

Exiting... (End of file)

real    1m17.132s
user    0m7.105s
sys    0m3.307s
====>8====

The input file is as it came from the Apple site, as I recall.

Here is the header from the resulting file:

====8<====
$ head -1 spirit_720p_2.y4m
YUV4MPEG2 W1280 H544 F12570329:524288 Ip A1:1
====>8====

Here's what my own rational fraction routine delivers:

====8<====
$ rational 12570329 524288 8
fraction=12570329/524288 (23.975999832) -> 12570329/524288 == 
23+511705/524288

$ rational 23.976 8
mixednumber=23.976000 -> 2997/125 == 23+122/125

$ rational 24000 1001 8
fraction=24000/1001 (23.976023976) -> 24000/1001 == 23+977/1001
====>8====

The Qalculate! program gives me the same numbers.


>> That fraction is bizarre. Obviously, the denominator is binary based, 
>> but why use that one?
>>     
>
> Because it is the one that still fits in 32 bits and represents the
> value of the single-precision floating-point value that MPlayer had
> stored as fps most closely.
>   

Looking inside the MOV reveals that the time scale is 2997, the duration 
is 219125, which works out to 73.114781 seconds, and the number of 
frames is 1753. Thus, 1753/(219125/2997) = 23.976, or 2997/125. Despite 
any internal single-precision rounding error the YUV4MPEG2 header should 
have got the 2997:125 value because 1753*2997 = 5253741, which fits into 
32 bits, and 5253741/219125 reduces to 2991/125. The rational fraction 
routine MPlayer uses is a problem. Creeping sync errors bit me too many 
times in the past.


>> Mathematically, this fraction works out to 
>> 23.97599983 instead of 23.976. In fact, 23.976 should have been 
>> expressed as 2997/125.
>>     
>
> 23.976 is a rounded value for display, not exact.
>   

I understand, but, as I showed above, the metadata in the MOV works out 
to that number number, while single-precision error delivered the number 
that went into the YUV4MPEG2 file header. While it may or may not be 
accurate to put 24000:1001 in the file when 2997:125 comes out of the 
MOV data, it is certainly inaccurate to put 12570329:524288 into the file.


>> However, one could argue that the rate is 
>> supposed to be 24000/1001, which is 23.976023976 (repeating the last six 
>> digits). Thus, while 23.976 is theoretically inaccurate enough, the 
>> bizarre fraction MPlayer comes up with causes even more error.
>>     
>
> Well, it's not the one I get, mine corresponds to
> 23.97602462768554687500.
> Nevertheless, since the calculation method was already changed in
> mencoder I saw no fault in using the same in that code, which works for
> all common frame rates (though I notice it might cause issues for frame
> rates < 0), e.g. I now get F24000:1001
> _______________________________________________
> MEncoder-users mailing list
> MEncoder-users at mplayerhq.hu
> https://lists.mplayerhq.hu/mailman/listinfo/mencoder-users
>
>   

It's an interesting problem. As you can see, I'm using an SVN version 
from this week and I don't get the number you got.

--Larry