The 2-frame Delay with x264

[Fenyő]

Hi!

I want to clarify the 2-frame delay with x264.

First of all, i still don't understand why the heck x264 makes this 2-frame delay on my encodes.

Yeah, i've read that this is because of multithreading and b-pyramid. But on the developers side: WHY?? Why x264 developers can't eliminate this 2-frame delay?

It's really annoying!!

And what the hell is the first(0.) and second(1.) frame??

And why is this 2-frame delay hidden when i use directshow for playing?
In AVIDemux i can clearly see this 2-frame delay, but if i open the mkv in GraphStudio, i can't see the 2 junk frame!
Which is the real one?

I have to clarify this, because i want to reencode a VFR mp4 file as if it were a CFR, and i want to remux(with mkvtoolnix) the timecodes with the reencoded file to get back the correct VFR video. (already reencoded)
And for this i have to know if i have to insert 2 dummy lines in the timecode file because of the 2-frame delay, or i don't have to. So?


By the way, you can see the difference between AVIDemux and GraphStudio, if you make an encode with multithreading of this AviSynth script as video source:
Blankclip(length=128, width=320,height=240, fps=25)
ShowFrameNumber(scroll=false, offset=0, text_color=$ff0000)
ConvertToYV12
After you encode this(x264-multithreading) with AVIDemux, and open the encoded file again with AVIDemux, you can see that frame 0 is invalid, frame 1 is also invalid, and frame 2 is "0000".
And if you open this encode in GraphStudio, you can see the first frame: "0000". (use the frame step button)

[poisondeathray]

In AVIDemux i can clearly see this 2-frame delay, but if i open the mkv in GraphStudio, i can't see the 2 junk frame!
Which is the real one?



It's probably an avidemux decoding issue, not a x264 dev issue

Try a nightly 2.6 build of avidemux, which handles h.264 better (or don't use avidemux at all, instead use a frame accurate source filter like dgnvtools or ffms2 is another option)
http://avidemux.org/nightly/win32/
http://avidemux.razorbyte.com.au/

[Fenyő]

It's probably an avidemux decoding issue, not a x264 dev issue
But the question is: these 2 junk frames are really exist in the file, or not?
So i have to insert 2 ghost-frames in the timecodes file (of the original mp4 file), or i don't have to?

Try a nightly 2.6 build of avidemux, which handles h.264 better

In 2.6 its a little strange. It doesn't show frame numbers, only timecodes. And the first frame is at 00:00:00.280, and the horizontal slider is not on the absolute left side. (but the first frame shows the real first frame)

(or don't use avidemux at all, instead use a frame accurate source filter like dgnvtools or ffms2 is another option)
Use a source filter instead of a whole editing application? :)

[Dark Shikari]

But the question is: these 2 junk frames are really exist in the file, or not?No, they don't. Your application is inserting them because it's broken.

[Fenyő]

No, they don't. Your application is inserting them because it's broken.
Okay, but something must be exist in the file, because AVIDemux is not showing me 2 junk frames when i make the encode with 1 thread! So something is really different in the file. But what?
And why that thing can not be the same in the file when encoding with multithreading?

[LoRd_MuldeR]

H.264 decoding in Avidemux 2.5.x and earlier was absolutely not frame-accurate (and it warns you about that!). That was the main reason to make 2.6 :)

If you need to process H.264 input with Avidemux 2.5.x, then your best way is using Avisynth input (via AVSProxy/AVSProxyGUI) with FFmpegSource2 or DGDecNV...

[Fenyő]

H.264 decoding in Avidemux 2.5.x and earlier was absolutely not frame-accurate (and it warns you about that!
No! Actually it offers me an "another mode which is safe but you will lose frame accuracy". I always choose NO, and i assumed that this way i have frame accuracy. So that sentence "you will lose frame accuracy" is a lie, because there is no frame-accuracy to lose!


If you need to process H.264 input with Avidemux 2.5.x, then your best way is using Avisynth input (via AVSProxy/AVSProxyGUI) with FFmpegSource2 or DGDecNV...
Yeah.
Are LAV Splitter Source and Haali Media Splitter also frame-accurate?

[LoRd_MuldeR]

No! Actually it offers me an "another mode which is safe but you will lose frame accuracy". I always choose NO, and i assumed that this way i have frame accuracy. So that sentence "you will lose frame accuracy" is a lie, because there is no frame-accuracy to lose!

I never noticed much difference between those modes, to be honest.

Also the warning (http://i36.tinypic.com/2euir9v.jpg) clearly says that, while the "other" mode looses frame-accuracy, the "normal" mode is completely broken when B-Frames are present :rolleyes:

(And, unless you are dealing with "Basline" footage only, there will be B-Frames in your H.264 stream!)

Are LAV Splitter Source and Haali Media Splitter also frame-accurate?

Haali Media Splitter is a DirectShow Filter and, as such, would only be relevant for Avisynth when working with DirectShowSource.

(which is known for its own frame-accuracy problems, so DirectShowSource probably is not what you want).

I don't know what "LAV Splitter Source" is supposed to mean, but if you use FFmpegSource2() in Avisynth, it should be frame-accurate, yes!

Though you better have your H.264 stored in MKV, as FFmpegSource2() has some problems with parsing TS/M2TS files...

[Fenyő]

Also the warning clearly says that, ... the "normal" mode is completely broken when B-Frames are present :rolleyes:
Ouh! I think you mean the "stuttering" part of the first sentence. Okay, i didn't realized that means complete frame-INaccuracy. My fault, sorry...

Haali Media Splitter is a DirectShow Filter and, as such, would only be relevant for Avisynth when working with DirectShowSource.
Yepp. I always used that for MKV as input in AviSynth.

(which is known for its own frame-accuracy problems, so DirectShowSource probably is not what you want).
Ouch.. :( I didn't know that. Thanx for the info!

I don't know what "LAV Splitter Source" is supposed to mean,
It's a DirectShow filter just like Haali Media Splitter. It comes with K-Lite codec pack. :)

but if you use FFmpegSource2() in Avisynth, it should be frame-accurate, yes!
Okay, so FFmpegSource2 is a function in a plugin DLL for AviSynth. I thought its a DirectShow filter too. :)

I think i'll use FFmpegSource2 from now on. :)

Though you better have your H.264 stored in MKV, as FFmpegSource2() has some problems with parsing TS/M2TS files...
I don't use TS/M2TS files...