Watch out, DivX5 creates 1 or 2 frame delay!

[Chibi Jasmin]

Hope this hasn't already been reported here, then sorry for double-posting.

In my few tests, the new DivX5 causes a one frame delay in the output video without B-Frames and a 2 frame delay with B-Frames. Important, when adding audio...just to let you know...

[Actron]

yae, thats right...had some serious problems with that shit, when I made my comparsion....

[Chibi Jasmin]

They could at least have mentioned it anywhere, or have I overlooked it?

[-i-]

I haven't had this problem, are you sure it's a constant issue??


my audio synched perfectly without any adjustments or delays...

and I used B-frames, etc etc....

[Chibi Jasmin]

Well, I haven't workted too much with DivX5 til now, but I don't see, why this should vary...

Simply check out yourself, by comparing your input vs the encode...and with b-frames step only forward in timeline or at least a few frames forward, after having moved backwards..

[Jorgosch]

Are you sure this is not one of the VirtualDub issues they fixed in the last version?

[Chibi Jasmin]

As far as you refer to 1.4.9 as latest I am, because this is the one I am using...why don't you people who doubt it, not just check it yourself and post results...load input in one VDub, encode in other and jump to same frame number...

DivX5 should be 2 frames delayed when using b-frames, otherwise one frame...

[-i-]

nope, no probs, I just checked, I just sis 2 encodes, and no synch issues...


I'm not sure if I follow your logic though, perhaps I am reading your post wrong...

Are you saying that a B frame is an *additional* frame to the nomal I frame set that old divx used??

Because it isn't 'additional', it is rather, an *included* frame, creating a larger "GOP" (Group Of Pics), in true MPEG fashion (MPEG2 has I,P,B frames)

In other words, (this is a hypothetical example BTW): if you didn't have B frames, like with old DivX, you have a result of 1 I frame, per frame. With B frames, you are dealing now with true I frames, and B frames, but you are not *adding* frames to the fps. The fps is the same.

a GOP can be as small as 1 I frame, or as large as you need, but usually are 12-15 frames....

[Chibi Jasmin]

Maybe you don't notice a 1 or 2 frame delay as sync issue?

All I am saying is, that

using B-Frames:

Frame 10 from input gets frame 12 in output..

without B-Frames:

Frame 11 from input gets frame 12 in output..

That's it...how B-Frames work is not the subject of this thread...

[FactorM]

so the first 2 frames are black then?

[Chibi Jasmin]

They are not black...I don't remember the pattern exactly...

something like (for b-frames)

Frame 1 picture from Input frame 1
Frame 2 dropped
Frame 3 same picture

All you people asking here, why not just encode 1000 test frames and take a look yourself?

[saVe]

what you are talking about could be due to th avi-b-frame workaround because the codec has to always load two frames in advance to encode b-frames properly. so the first two frames are empty (or sort of).
read that over at the xvid-forum, i'm not sure if everything is correct this way...

[zulu]

what you are talking about could be due to th avi-b-frame workaround because the codec has to always load two frames in advance to encode b-frames properly


yes, this was also posted by a divx developer (eagle?)over @ divx.com.
there is a 2 frames delay when using an avi container for bi-directional divx encodings.

[Northpack]

So does this delay always appear when encoding in standard mode? Does it also apear in MPEG4 mode?

What is if you're using OGG format? Are there the same problems with it as with AVI? Can you mux MPEG4 output into an OGG stream?

Northpack

[FH2]

I'd the same problem. For comparing the different codecs, i encoded some clips with the different codecs. The result was, that exactly the same frame was to be found in the divx5-file exactly 2 frames later then in the divx;)/xvid files. i used vdub 1.4.9 both for encoding divx5/xvid and viewing all of them.

[Chibi Jasmin]

is the one frame delay, when not using b-frames...someone knows?

[-h]

I posted about this on the XviD forums here (http://www.xvid.org/forum/viewtopic.php?topic=321&forum=2&10).

DivX5's directshow filter somehow removes the delay which is present when decoding with vfw, for example in virtualdub.

-h

[BlackSun]

B-frames can be handled by AVI by putting the VOPs in decode order into the AVI chunks. This is how DivX has always been contained in AVI. The side effect of B-frames in this environment is a two frame delay in the video.
You're right, mp4 is a better container for video with B-frames as the CT/DT offset values allow us to get the timing absolutely correct.
AVI output is disabled when Intelligent IVTC is in use. The IVTC can produce video with a variable framerate (some 24fps, some 30fps). AVI can't handle variable framerates easily so mp4 is the only output in this mode.

[tiki4]

Hi there,

thanks Chibi for the workaround with the DivX3.11 filter. Good work! But that doesn't belong in that thread...

My question: If the DivX5 produces a delay by 2 frames in final AVI, is there a workaround to get Audio and Video again in sync? Yes, usually two frames don't make a big deal, but when it comes to cutting for 2 CD rips I doubt that 2 more frames is really good for Audio/Video-syncing.

Sorry, I didn't have the time to do much testing myself, just one movie yet and I packed it in OGM. There seems to be some trouble with searching in the video as posted somewhere else in this forum. Maybe this is from the 2 frames delay?

Thanks in advance.

tiki4

[theReal]

I found one test file I encoded was pretty much out of sync. If it was two frames or more I don't know, but it was too much to be ok ...

[FactorM]

if there are 2 frames more with b-frames enabled, then the audio has to step in 80ms (25frames in 1000ms = 2 in 80ms) later for an PAL movie, right? so i have to delay the audio track by 80ms?

[Chibi Jasmin]

Well, anyone can comment on one frame delay when using no b-frames?

And is it true, or not, that delay is removed by the DirectShow-Filter? (I won't rely on myself watching and listening)

And yes, 2 frames delay at 25 fps pal is 80 ms...

But maybe, if the DS-Filter removes the delay, we won't have to delay the audio...

[Chibi Jasmin]

@tiki...ah, yeah..delay audio by the time the 2 (or 1) frames are displayed...

but well, if ds-filter really compensates, it is not necessary.

[tiki4]

Thanks for your reply.

Please understand, I'm still at work and I cannot test that stuff here (I'm considered working). On the other hand I cannot post from my home (there's no internet connection (would also be pretty useless as I'm on T1 here and on max. ISDN at home)).

Nevertheless I'm thinking that the seeking problems posted elsewhere in that forum inside .ogm files have something to do with the 2 more frames. I'll test this if I can until tomorrow (DivX5 encoding takes awfully long even on my Athlon XP 1600+). I just think of that because I had the same seeking problem when I put DivX5 with b-frames and stuff into and OGM. I cutted the audio with vcut before into two parts and so I did with the DivX5 AVI in Nandub.

And now again: there is something like a one to one correspondence between video frames and audio samples (video 25 fps as I'm using PAL and audio 48000 samples per second). I'm pretty much sure this gets mixed up if you have a video stream that's two frames more. How should Tobias' DS filter know about that. I don't think it can compensate.

Regards,

tiki4

[Chibi Jasmin]

Well, look at the referenced post above in the xvid-forum, there is a statement, that DivX5-DS-Filter does not show the 2 frame delay problem...

[tiki4]

Thanks for kicking me the right way.

But still I must insist that even if you don't see a problem during playback - because the DivX5 DS filter compensates this - you get a too short Vorbis stream in your OGM and that should screw up the internal time stamps. We've got to ask Tobias about that I guess.

Don't get me wrong, while playback may be fine for looking at a running video stream, when it comes to seeking I expect problems! That's nothing to do with the DS filter, it's just inside the OGM.

That's just my opinion. I'll get home next minutes to make some tests. I'm slowly getting really curious. I'll have a look at the XviD DS filter problems posted somewhere else as well. I hope I can reproduce or better not reproduce the reported problems.

tiki4

[Chibi Jasmin]

As I have never played with ogg-media streams I can't help you with this...seems we need more information how DivX5 is intented to handle this...

[Chibi Jasmin]

So finally someone played around enough to tell us, if we have to delay audio for 1 or 2 frames or not?

[tiki4]

Well,

I was home for testing. Now slowly I'm getting aching hands. It seems the discussion is now in three threads, but O.K. I encoded some music videos in DivX 5 Pro and still with b-frames (sorry for not testing without b-frames), with GMC and without QPel (makes things awfully slow and doesn't make any difference to me).

Well, when I opened my encoded video stream in VirtualDub it had exactly the same number of frames as the .AVS source had shown. So what about this 2 frame delay? I used 'File Information' in VirtualDub 1.4.9 to find out about the number of frames. I compared to an XviD encode of the same clip and it also showed the same number of frames.

My syncing issues in .OGM files - as discussed elsewhere - are still not gone. Video and audio play fine but after seeking they get horribly out of sync (audio will never catch up again). In AVI files however there seems to be no such a problem.

I used the DivX 5 Pro Codec only and the new OggDS 0.9.6 on my machine...

For now I'm testing some full movies...

Regards,

tiki4

P.S.: By the way, I have the XviD build from Koepi's site installed in parallel. For now I didn't seek any problem with XviD playback as long as I use the right FourCC (XVID). In fact my comparisons showed that the two codecs are pretty close up from what I can see.

[Chibi Jasmin]

You have to compare input frame from your script vs. output frame with the same number...

Normally: Frame 10 in output is frame 10 in input.
In your case it should now be: Frame 10 in output is frame 8 in input...

So open two VDubs and compare the frames...

[tiki4]

Alright!


I'll do so. But does this mean that two frames are missing in the end?

[Chibi Jasmin]

to be honest, I never checked, but I that's the only way it could be!? Let us know, when you find out :-)

[-h]

Guys,

If you use B-frames, the video is delayed by 2 frames. But that's ONLY when decoding with vfw - if you decode with the dshow filter, there is no delay whatsoever (not sure how they managed that, but I'm not a dshow guy). So you don't have to worry about delaying audio if you decode with the dshow filter.

Also, due to the buffering system DivX5 uses when encoding, the last frame "disappears" and never gets written to the file.

-h

[Chibi Jasmin]

I'd still be interested to know, why there is a 1-frame delay without b-frames...

[tiki4]

O.K.,
confirmed. I did an test yesterday. 1 frame delay without B-frames and 2 frames with B-frames. But still this is very hard to find out. You need to seek frame by frame in VDub and still it's hopping around. Still wondering about that as the total number of frames doesn't change. So does this mean that the last to frames are skipped completely?

Regards,

tiki4

[-h]

The reason for the 1-frame delay, is that DivX5 doesn't know in advance whether a B-frame is going to appear in the stream, so it has to read an extra frame to make sure.

Once it knows there aren't any B-frames (by getting two consecutive P-frames), it then merrily decodes every frame delayed by 1.

-h