x264 not writing video track framerate?

[Boulder]

As posting in the "other" forum did not produce any replies, I'll try my luck here as well :)

Has anyone noticed that x264 is not writing the video track framerate to the AVC stream (output to mp4 during the encoding process)? I ran into this problem with an VFR encode of mine, which runs way too fast on my media player.

If I run eac3to on the mkv file created from the video track, it warns that the video track doesn't contain framerate information. If I run eac3to on an older vfr mkv file of mine (muxed with the same version of mkvmerge), the framerate is there.

Do you have any ideas how to try to find out the real cause of the issue? This issue occurs with at least r2208 from x264.nl, the working mkv file was created from an encode with r2200.

[sneaker_ger]

What steps are you doing exactly to produce your files? You are talking about using the mp4 output, then suddenly mkvmerge and eac3to, so it's hard to follow.

[Boulder]

Output to mp4 in the x264 command line, then muxing that video and and audio track to mkv with mkvmerge. With x264 r2208 there is no framerate information in the video file, with r2200 there was. The MinGW libpack has not been updated so it cannot be the mp4 muxing that is causing the issue.

Some parts of the video are 25fps and some 59.94fps. If there is no framerate information in the video, the video seems to run at 59.94fps throughout the whole clip even though there are proper timecodes input while encoding and muxing.

[sneaker_ger]

I cannot reproduce the issue. I used a VFR mkv file as input:
x264.exe input.mkv -o intermediate.mp4
mkvmerge.exe intermediate.mp4 sound.aac -o output.mkv

x264 2208 8 bit 64 bit from x264.nl
mkvmerge 5.8.0

Playing fine in MPC-HC.

[Boulder]

Plays fine in MPC (both cases work for me there too) but please check what eac3to says about the mkv file.

[sneaker_ger]

"v01 The video track doesn't contain framerate information."
No difference if I replace 2208 with 2200, though.
Did you create your older file as CFR in x264 and only later muxed as VFR with mkvmerge?

[Boulder]

No, both were created with timecodes in the encoding phase (due to CRF mode)

Both r2200 and r2208 were/are my own builds but the libpack was still the same in both cases, GCC 4.4.6 for r2200 and 4.4.7 for r2208.

This one seems to be a known issue for many hardware media players but I don't understand how it just started happening :(

[Boulder]

The "faulty" file also shows up as 0fps in the media player and a correct one shows 50 fps (a clip which contains 25p and 50p parts).

[filler56789]

Hmmmm, that's interesting, and weird O_o

Just encoded a short CFR clip, remuxed with mkvmerge, and yes, eac3to says:

MKV, 1 video track, 0:01:23, 30p /1.001
1: h264/AVC, 640x480 29.970p
v01 The video bitstream is encoded in a non-standard framerate.

Also, MMG gave me a "warning":

The AVC video track is missing the 'CTTS' atom for frame timecode offsets. However, AVC/h.264 allows frames to have more than the traditional one (for P frames) or two (for B frames) references to other frames. The timecodes for such frames will be out-of-order, and the 'CTTS' atom is needed for getting the timecodes right. As it is missing the timecodes for this track might be wrong. You should watch the resulting file and make sure that it looks like you expected it to.

[sneaker_ger]

For "non-standard" framerates you have to look at what the x264 log says about the framerate. Sometimes there are slight variations in fraction that you don't see when rounded.
The CTTS warning for mov/mp4 can be ignored - you most likely haven't used b frames.

@Boulder
I cannot test on your hardware player for obvious reasons, but here you can play with my output files:
http://www.mediafire.com/?drc58d31d1jplae
You're not a beginner, otherwise I would have said you have created the files differently (aside from the x264 revision).

[filler56789]

^ Thanks for the clarification, BTW it sucks to know I'm still a n00b :mad: , ARGH :)

[Boulder]

The CTTS warning for mov/mp4 can be ignored - you most likely haven't used b frames.I get the same warning from mkvmerge if I output to mp4 when encoding. I did not get it before, but maybe it's just a change to mkvmerge. [EDIT:] No, I get it if I feed x264 with the timecode file with 25.00000 and 59.940000 parts..

It seems that CFR encoding does stamp the timecode but VFR does not. The funny thing is, I cannot get the timecode there anymore no matter how I try with for example r1947 which I happened to have on my HD.

Could the problem be something fishy elsewhere? Look what I extracted from the clips.

This is from a working clip, first 50p then 25p (timecodes only for the 50p part)
# timecode format v2
0
20
40
60
80
100
120

This is from the non-working clip, first 25p, then 59.94p (timecodes only for the 25p part)
# timecode format v2
0
40
80
120
160
200

If I remember correctly, both were fed into x264 as a 25p clip and a proper timecode file was input. All the settings were basically the same.

[sneaker_ger]

The funny thing is, I cannot get the timecode there anymore no matter how I try with for example r1947 which I happened to have on my HD.

So it is not a regression after all?

[Boulder]

Yes, it seems so after playing around it more. But I don't know if it's x264 or mkvmerge related..

[Boulder]

I think the problem is in x264 itself.

This is the contents of the timecode file that doesn't work, the video track does not have framerate information:
# timecode format v1
assume 25.00000
20,50,59.94000
80,110,59.94000
150,999,59.94000

In this case, x264 shows "timecode [info]: automatic timebase generation 1/149850" in the output.


If I use this timecode, it works:# timecode format v1
assume 25.00000
20,50,50.00000
80,110,50.00000
150,999,50.00000

In this case, I get "timecode [info]: automatic timebase generation 1/50"

[skontel]

I ran into this with the 'mencoder' vs. 'ffmpeg' encoding. The controlling factor is the 'b_vfr_input' member of the x264 structure.

If it's cleared, then the frame rate gets written to the stream. This controls the playback speed via the frame rate (the 'mencoder' approach).

If it's set, then the frame rate doesn't seem to get written to the stream. This controls the playback speed via the time codes stored in the individual frames (the 'ffmpeg' approach).

I don't know how to control this setting in the x264 executable, but I had to patch 'ffmpeg' to clear the data member, or I could never re-mux the resulting file. If I did re-mux the resulting file, the frame rate was anything but what I wanted. My favorite was the 48000/1001 playback result.

One thing I've noticed with my patched ffmpeg is that the lip-sync is occasionally off by a fraction of a second, but only momentarily. Of course, with the mencoder the lip-sync is never correct, so... I guess it's an improvement.

[nm]

I ran into this with the 'mencoder' vs. 'ffmpeg' encoding. The controlling factor is the 'b_vfr_input' member of the x264 structure.

If it's cleared, then the frame rate gets written to the stream. This controls the playback speed via the frame rate (the 'mencoder' approach).

If it's set, then the frame rate doesn't seem to get written to the stream. This controls the playback speed via the time codes stored in the individual frames (the 'ffmpeg' approach).

Yes, FFmpeg uses variable framerate encoding, MEncoder uses constant framerate. This is different from Boulder's problem since he wants to use VFR but his players don't seem to support it fully. Personally I'm not surprised that mixed PAL and NTSC framerates with a weird timebase don't work on a random device while 1/50 timebase works.

I don't know how to control this setting in the x264 executable

You can force constant framerate with --force-cfr --fps 24000/1001

but I had to patch 'ffmpeg' to clear the data member, or I could never re-mux the resulting file. If I did re-mux the resulting file, the frame rate was anything but what I wanted. My favorite was the 48000/1001 playback result.

How exactly are you remuxing? Sounds like your process doesn't support VFR and only reads the timebase.

[sneaker_ger]

You can force constant framerate with --force-cfr --fps 24000/1001

--fps already implies --force-cfr
(It is correct, nonetheless, of course.)