Unofficial VirtualDub Support Forums [Powered by IB Forums]

Printable Version of Topic
Click here to view this topic in its original format

Unofficial VirtualDub Support Forums > Testing / Bug Reports > Vdmpeg2; Gap In Audio Stream

Posted by: rmanal Jul 13 2007, 01:53 PM

Hello,

I have a VOB file that i convert into DIVX AVI file.
In the VOB file, I have no gap in the audio stream, but in the AVI file, and even in VDMPEG2, I can see a gap of less than 1s in the audio stream.
In other VOB file, I don't have in general this issue.
I don't know how to put the VOB file in this topic.

Could anyone help be by reproducing my issue?

Thanks
Rmanal

Posted by: rmanal Aug 13 2007, 09:46 AM

FCCHandler, where are you ;-)

Posted by: fccHandler Aug 13 2007, 06:12 PM

I don't know why there would be a gap in the output, unless the VOB is broken somehow. But it's impossible to say without examining the VOB.

Posted by: rmanal Aug 14 2007, 09:43 AM

tell me what and how I can see something in my VOB file, or how I can send it to you?

Thanks

Posted by: fccHandler Aug 14 2007, 06:23 PM

QUOTE (rmanal @ Aug 14 2007, 05:43 AM)

tell me what and how I can see something in my VOB file

Try the conversion with other programs. There is lots of commercial software to convert VOBs to DivX, in fact I think DivX makes something to do that. Other free tools to try are http://neuron2.net/dgmpgdec/dgmpgdec.html and http://www.tmpgenc.net/en/index.html. If you still have problems with this same VOB using other programs, then the VOB is probably broken and can't be fixed.

QUOTE

... or how I can send it to you?

If it's a typical 1 GB VOB, you can't. There is a list of file hosting sites http://forum.doom9.org/showthread.php?t=96362 but AFAIK they all have limits on how big the file can be. You can try to cut the file to a smaller size, and there are http://forum.doom9.org/showthread.php?t=128679 for that too. The trick will be to isolate a small portion (small enough to send) that still demonstrates the original problem.

Posted by: rmanal Aug 18 2007, 10:11 AM

I have tried to analyse my VOB file with VOB edit and I have found that it does not begin with a nav-pack.
If I use chopperXP it adds a nav pack block, but I can't know with which informations and I still have a shorter delay.
I I use MPEG cut then the new VOB files can't be opened with powed DVD.

So I don't know how to cut my big VOB file.
I have created a FTP server: could-you use it to download my VOB file called "VTS_01_4.VOB".
FTP site name: ftp://rmanal.ftpaccess.cc/
user name: tmp
Password: tmp

Posted by: fccHandler Aug 18 2007, 06:39 PM

I'm going to try, but Windows is estimating 5 hours to download.

Doesn't the name "VTS_01_4" indicate that this is the 4th VOB of title set number 01? If so, then it isn't meant to be parsed independently, and it's probably broken at the beginning for that reason.

The Correct™ thing to do is to process the title set as a whole, by joining the separate VOBs into one giant VOB using the "copy /b" command, or better, just load them all into http://neuron2.net/dgmpgdec/dgmpgdec.html. If you've never done that before, make sure you read the DGMPGDec instructions:

http://neuron2.net/dgmpgdec/QuickStart.html

Posted by: fccHandler Aug 18 2007, 06:54 PM

After re-reading all of your posts, I'm suddenly confused about your use of the word "gap," and now I wonder if you are simply talking about a delay in the audio stream. In fact, I expect there will be a delay when opening any VOB that is not the 1st VOB of a title set.

If that's all it is, then it's easily fixable. After loading the VOB, open the "File / File Information" dialog and look at the audio track "Skew" field. If it shows a nonzero value, then open the "Audio / Interleaving" dialog and enter that same value into the "Delay audio track by" field.

Posted by: fccHandler Aug 19 2007, 06:55 AM

I finally got your video, but it took two attempts.

I understand now why you have persisted about this for over a month. This appears to be homemade video of a wedding reception; there are probably priceless family memories recorded here. Let me just say, thank you for using VirtualDub-MPEG2 for its intended purpose.

(The owner of this forum knows I can become upset about people downloading/ripping Hollywood DVDs, and/or content they have no right to.)

Anyway, the steps I described in my previous post don't work with your video. VirtualDub-MPEG2 reports an audio skew of -128 milliseconds, but my eyes and ears say it's significantly more than that. I think I got much better sync using values between -400 and -500.

BTW, there seems to be some inconsistency in the way the audio delay is presented during preview, which (I believe) is inherent in the underlying VirtualDub engine. I could only make my skew changes visible by setting the audio to "Direct Stream Copy," and pressing the "Output Playback" button. (The third button at the bottom.)

Just in case phaeron is listening, I'm referring solely to the real-time playback in VirtualDub's window. As far as I know, if you set a nonzero audio skew, it ALWAYS takes effect when saving the file; it's only the preview that is inconsistent.

I also saw a rare bug in the MPEG-2 decoder, when starting from a nonzero key frame, which causes blocks to appear briefly. It's not the first time I've seen it, but in the past it's always been difficult or impossible to reproduce. Tonight I saw it numerous times in your video; maybe I can finally track that bug down and kill it...

My native language is English, and I thought of a "gap" as a brief moment where the audio disappears, then reappears again. If there is such a moment in this video, please post the time where it happens.

Thank you for the video. I'll wait to hear from you.

Posted by: rmanal Aug 19 2007, 11:30 AM

I hace effectively seen that my FTP server has gone down due to the break of my DSL connection. Sorry for that.

It is effectively my wedding that I arrange under Pinnacle Studio 10 under which I have discovered a delay, and not a gap - sorry but English is not my native language - between audio and video.

I have made two another VOB files (essai.vob and essai2.vob) by spiltting the original one by using chopperXP which deletes all the blocks before the first NAV block. You can also download them if you want, in particular the short one.
And I you have said, the audio delay shown in the NAV block does not correspond to the delay that I'm seeing in VIRTUALDUB MPEG2.
I don't really understand what you've said to BTW: what should I do to retrieve the correct audio-video delay? Why the MPEG2 decoder does not correct them automatically by using the information of the NAV block, instead of presenting that through the file information menu?

To finish with what you've said to phareon, I also see the same behavior.

Posted by: fccHandler Aug 19 2007, 07:13 PM

QUOTE (rmanal @ Aug 19 2007, 07:30 AM)

I have made two another VOB files (essai.vob and essai2.vob) by spiltting the original one by using chopperXP which deletes all the blocks before the first NAV block. You can also download them if you want, in particular the short one.

I will, because I don't know what a "NAV block" is.

The skew reported in "File Information" is derived by subtracting the earliest video PTS from the earliest audio PTS. PTS are the "Presentation Time Stamp" fields found in all MPEG program streams, however, it's possible that DVDs don't use them and rely on "NAV blocks" instead to sync audio and video. I really don't know. I'll have to do some more research.

QUOTE

And I you have said, the audio delay shown in the NAV block does not correspond to the delay that I'm seeing in VIRTUALDUB MPEG2.

What exactly is the "audio delay shown in the NAV block" and how did you get it? Does chopperxp show it?

QUOTE

I don't really understand what you've said to BTW: what should I do to retrieve the correct audio-video delay?

I don't know yet; I didn't retrieve the correct audio delay, rather, I just used my eyes and ears to judge sync, while trying different skew values. -450 looks pretty close.

QUOTE

Why the MPEG2 decoder does not correct them automatically by using the information of the NAV block, instead of presenting that through the file information menu?

Well, I don't have the DVD specification. The parser in VirtualDub-MPEG2 was written based on the MPEG-2 specification (ISO/IEC 13818), and I don't recall any "NAV blocks" described in those specs. I assume it's some metadata added for DVD players, which would have been described in the DVD spec. I'll see what I can find out.

Posted by: phaeron Aug 19 2007, 08:03 PM

QUOTE (fccHandler @ Aug 18 2007, 11:55 PM)

Just in case phaeron is listening, I'm referring solely to the real-time playback in VirtualDub's window. As far as I know, if you set a nonzero audio skew, it ALWAYS takes effect when saving the file; it's only the preview that is inconsistent.

This shouldn't be the case -- it's exactly the same mechanism. Are we talking about the displacement value in Audio > Interleaving?

Posted by: fccHandler Aug 19 2007, 10:48 PM

QUOTE (phaeron @ Aug 19 2007, 04:03 PM)

Are we talking about the displacement value in Audio > Interleaving?

Yes. And whether a nonzero skew is visible during preview seems to depend on several settings, like whether I push "Input Playback" or "Output Playback," and whether audio is set for "Direct Stream Copy" or "Full Processing." It may also depend on whether the skew is positive or negative; I can't recall offhand.

Obviously you won't be able to reproduce it with these VOBs, so I'll try to make you a repro case later, so you can see what we're seeing.

Posted by: fccHandler Aug 20 2007, 03:02 AM

Well, I was afraid of something like this. I did reproduce the behavior in the official VirtualDub 1.6.19 and the experimental 1.7.2, but only when the AVI has AC-3 audio. It doesn't happen with PCM or MP3 audio.

One major difference in the three formats is the nBlockAlign field, which in my tests was 4 for PCM, 1 for MP3, and 768 for AC-3 (the size of one AC-3 frame, in this particular source file).

I think we've argued before over whether that is the "correct" value to go in the nBlockAlign field, so I won't rehash that. But it's the value I've always used, and as far as I know VirtualDub is the only program that has a problem with it, and only in this one specific case (previewing with a nonzero skew).

If you're still interested in a repro case I can post mine, but you will have to install http://fcchandler.home.comcast.net/AC3ACM to preview it. (That leaves you an out though, since you can always blame me.)

Anyway, it's not a problem that comes up often, so I'll understand if you're not interested.

Posted by: phaeron Aug 20 2007, 08:59 AM

It shouldn't be a problem in this case unless there is a difference in decoder handling between AC3ACM and the installed DirectShow decoder. When nBlockAlign is a fib and doesn't reflect the true size of the compressed blocks, then the most likely cause is runts appearing in the bitstream. The most reliable way to handle this is for the codec to estimate how much time the runt corresponds to and pad according to that amount, but if the decoder instead absorbs the bad packets for zero time then the result is a desync. You can get these in both directions when using the skew field. Pushing the audio stream forward results in the first audio block being duplicated, and pushing it backward drops blocks at the beginning. For a stream with self-contained blocks, like ADPCM, this works fine; for dependent blocks, it's up to the codec to handle the results.

If you have a sample I can look at, I'd be happy to look at it. I doubt this problem is AC3 specific if the problem is on my end, as there is very little format-specific code in VirtualDub.

Posted by: rmanal Aug 20 2007, 04:36 PM

NAV block = NAV PACK as shown by VOBedit software.
There is a field "offset to audio packet for audio stream N".

Posted by: fccHandler Aug 20 2007, 07:17 PM

QUOTE (phaeron @ Aug 20 2007, 04:59 AM)

Pushing the audio stream forward results in the first audio block being duplicated, and pushing it backward drops blocks at the beginning. For a stream with self-contained blocks, like ADPCM, this works fine; for dependent blocks, it's up to the codec to handle the results.

I see. I think the codec handles it OK. AFAIK, all of the decoder state is passed in each AC-3 frame header (similar to MPEG), but there may be some sample buffer state that is propagated from frame to frame (exponents, mantissas). I'm not too sure...

In this case, I think it isn't so much a problem of bad blocks being sent, as it is a problem of the audio not being skewed at all from your end, and only in certain scenarios.

A light bulb came on in my head when you mentioned ADPCM, and sure enough, I can reproduce the problem with Microsoft ADPCM also (nBlockAlign = 0x800).

Here are two samples I made (3.83 MB):
http://fcchandler.home.comcast.net/sw.7z
They are XviD (no b-frames), AC-3 and ADPCM.

Here are two examples of inconsistent behavior:

1) Set "Delay audio by = 1000 ms"
2) Set Audio to "Direct Stream Copy"
3) Start playing from frame 0
Now "Output Playback" shows the skew, but "Input Playback" doesn't.
4) Change Audio to "Full Processing Mode"
5) Start playing from frame 0
Now neither "Output Playback" nor "Input Playback" shows the skew.

1) Set "Delay audio by = -1000 ms"
2) Set Audio to "Direct Stream Copy"
3) Start playing from frame 0
Both "Output Playback" and "Input Playback" show the skew.
4) Start playing from key frame 177
Now "Output Playback" shows the skew, but "Input Playback" doesn't.

That should be enough to get you started. (Basically you just ring all the changes.) I hope you can reproduce it.

Posted by: fccHandler Aug 20 2007, 07:35 PM

QUOTE (rmanal @ Aug 20 2007, 12:36 PM)

NAV block = NAV PACK as shown by VOBedit software.
There is a field "offset to audio packet for audio stream N".

Thanks. I found all the information I needed here:
http://dvd.sourceforge.net/dvdinfo/index.html

But I'm seriously debating whether I want to incorporate parsing of the DVD "private_stream_2" metadata into VirtualDub-MPEG2; it looks like a huge pain. And those aren't even the real specs, it's just some stuff mpucoder and others figured out.

Although I think your project is honorable and I want to help you, I really didn't make VirtualDub-MPEG2 for DVD ripping. I still say it would be better to process the whole title with a set of tools specifically designed for the task. Did you ever try DGMPGDec? If I were in your situation, THAT is the tool I would use for this project.

Posted by: phaeron Aug 20 2007, 09:11 PM

Thanks for the precise repro case. Found the bug -- it's caused by a units mixup when decompression is occurring. Fix, in case you're curious:

CODE

==== //depot/VirtualDub/1.x/stable17/src/VirtualDub/source/Audio.cpp#14 - d:\p4root2\dev_stable\src\VirtualDub\source\Au
dio.cpp ====
@@ -442,7 +442,12 @@
stream_len = std::min<sint64>(max_samples, aSrc->getEnd() - first_samp);

if (mCodec.IsInitialized()) {
- stream_len = (sint64)VDUMulDiv64x32(stream_len, GetFormat()->nSamplesPerSec * aSrc->getWaveFormat()->nBlockAlign, aSrc->getWaveFormat()->nAvgBytesPerSec);
+ const WAVEFORMATEX *wfexSrc = aSrc->getWaveFormat();
+ const WAVEFORMATEX *wfexDst = GetFormat();
+ double sampleRatio = (double)wfexDst->nSamplesPerSec * (double)wfexSrc->nBlockAlign / (double)wfexSrc->nAvgBytesPerSec;
+ mPrefill = (sint64)VDRoundToInt64(mPrefill * sampleRatio);
+ mOffset = (sint64)VDRoundToInt64(mOffset * sampleRatio);
+ stream_len = (sint64)VDRoundToInt64(stream_len * sampleRatio);
}

mBasePos = first_samp;

I'll have to rethink this for 1.7.3, because there's rounding going on here that shouldn't be, due to the value being passed in compressed samples. There is some seriously old VirtualDub code involved here.

Posted by: fccHandler Aug 21 2007, 12:55 AM

Thanks.

I'm having trouble porting this though. In your publicly available source code of 1.6.19, AudioStreamSource doesn't have the members "mOffset" and "mBasePos." Is this the 1.7.2 source that we're looking at above?

Scaling "mPrefill" and "stream_len" does help 1.6.19, but it doesn't fix every scenario. I tried scaling "first_samp" too but that just made one of the scenarios worse (no audio at all).

Posted by: phaeron Aug 21 2007, 01:15 AM

Yeah, it is from my 1.7.x dev tree. I haven't looked at back-porting it to 1.6.x yet, although I suspect the core issue is the same. I reworked some of that code in the 1.7.x branch to fix a number of other bugs regarding handling offsets and compressed formats, so I'm not surprised that it's different. When I look at the 1.6.x version, I'll get back to you.

Posted by: fccHandler Aug 21 2007, 01:21 AM

Take your time. Like I said, it's not an issue that comes up often, and it's publicly documented now. Speaking for myself, I'm perfectly content to wait for the next official release at your leisure.

Posted by: rmanal Aug 21 2007, 04:46 PM

I have read the documentation of the software you have suggested but it looks more complicated.
Another way to do is to know what delay to apply in virtualdub for every VOB file.
How could I get this value?
Should I take into account the value given in the NAV block? Has it a impact on this audio-video delay?

Posted by: fccHandler Aug 21 2007, 06:44 PM

QUOTE (rmanal @ Aug 21 2007, 12:46 PM)

I have read the documentation of the software you have suggested but it looks more complicated.

It is, but I think you'll find that the reward is worthwhile. With the help of DGMPGDec you can load the whole DVD title into VirtualDub, and this will probably eliminate your sync problem.

QUOTE

Another way to do is to know what delay to apply in virtualdub for every VOB file.
How could I get this value?

If the skew value in "File Information" looks incorrect, then I really don't know. Your video suggests to me that DVDs may use the NAV block info exclusively, and ignore the MPEG-2 system-level PTS. If so, I don't have a solution for that yet, because VirtualDub-MPEG2 is wholly ignorant of NAV blocks.

QUOTE

Should I take into account the value given in the NAV block? Has it a impact on this audio-video delay?

You still haven't told me what the "value given in the NAV block" is. I mean, what tool do you use to get this value, and what is the value?

Posted by: rmanal Aug 22 2007, 12:35 PM

I have read some forum about DVD contents and I don't really know if NAV block is used to calculate audio-video sync.
What is strange is that with my first complete file, I get a real desync of ~450ms instead of the 128ms given mi VDMPEG2.
But in the other file cut with chopperXP, which has remove all the blocks before the first nav block, then in VDMPEG2 the real desync is ~100ms for 128ms shown in file information.
I don't see any difference in the corresponding block with VOBedit in the two VOB files, so I don't anderstand why VDMPEG2 introduces another delay of ~300ms with the first VOB file.

Furthermore because I have already began my video under Studio, I don't want to generate another avi file from another VOB files. I just want to correct to delay by using VD with the good delay value for each of my VOB files.

Thank you again

Posted by: fccHandler Aug 22 2007, 06:03 PM

QUOTE (rmanal @ Aug 22 2007, 08:35 AM)

I don't anderstand why VDMPEG2 introduces another delay of ~300ms with the first VOB file.

VirtualDub-MPEG2 doesn't introduce a delay. The delay is already present in the VOB because it is a slice from a much larger set; it's not an independent video file. Treating VTS_01_4 as a single file is the wrong way to approach this project. DVDs don't work that way.

QUOTE

I don't want to generate another avi file from another VOB files. I just want to correct to delay by using VD with the good delay value for each of my VOB files.

I don't understand you here. The only way you can use VirtualDub to correct the delay is to re-encode the movie as an AVI file. That's the only kind of video that VirtualDub can generate. If that isn't what you want, then VirtualDub is the wrong tool to use.

Does your actual DVD disc show a delay when you play it on television?

Also, please answer the last question in my previous post.

Posted by: rmanal Aug 23 2007, 12:14 PM

OK, treating my VOB file as a single file is probably not the good way, but as I have said I have already created my studio project and I don't want to take many hours to do this project again with new input files.
Furthermore other software like powerDVD treats correctly this video-audio delay, so I have to find how.
Could you explain to me how VDMPEG2 calculates this delay value given in file information? Which parameter of the VOB/mpeg file are taken into account in the PTS or DTS stream?
Could you give me the exact algorithm?
In parallel i'm trying to get how audio-video- delay is calculate in a VOB file through internets forum.

Furthermore my purpose is effectivly to produce avi files from VOB files, coming from my living room SONY DVD writter. Actually I have these avi files which are in input of my Studio project, and I only want to correct the delay in these avi files, then without changing anything in my Studio project. Sorry for my bad English.

the software I use, as I have wrotten in a previous post, is VOBedit software, the "brother" of IFOedit software.
When I play my VOB files neither with powerDVD or with my DVD player, I don't have any delay.

Posted by: fccHandler Aug 23 2007, 08:25 PM

QUOTE (rmanal @ Aug 23 2007, 08:14 AM)

Could you explain to me how VDMPEG2 calculates this delay value given in file information? Which parameter of the VOB/mpeg file are taken into account in the PTS or DTS stream?
Could you give me the exact algorithm?

The source code is available http://fcchandler.home.comcast.net/stable. The calculation is done in Mpeg2.cpp. Only the two earliest Presentation Time Stamps are considered. Basically:

- Make a list of all the video frames and video PTS
- Make a list of all the audio frames and audio PTS
- Sort the video frames in presentation order
- Remove any orphan video frames
- Locate the earliest PTS in the video list
- Locate the earliest PTS in the audio list
- Skew = (audioPTS - videoPTS) / 90

("Orphan" video frames are P- or B-frames which can't be decoded because their associated reference frames are missing.)

Applying the above skew should guarantee that the audio and video streams start in sync, if I'm interpreting the MPEG standard correctly. However, VOBs are not MPEGs, and from what we're seeing there may be a LOT more going on behind the scenes when a DVD player parses your disc files.

I've made a handful of DVDs myself, and I've noticed for example that GOP time code seems to be ignored by the player. Maybe the MPEG-2 PTS values are ignored too, and DVD players sync using some other method. If that's true then the skew reported by VirtualDub-MPEG2 is not useful for VOBs. (It certainly isn't useful in this case...)

But to be honest, you probably know as much about the DVD standard as I do.

QUOTE

the software I use, as I have wrotten in a previous post, is VOBedit software, the "brother" of IFOedit software.

Does that software give you a delay value for the VOB? If so, then use that value, and disregard the skew reported by VirtualDub-MPEG2.

I'm going to research this later when I get time, and see if I can come up with some way to measure the true delay in VTS_01_4.VOB using the NAV blocks.

Posted by: fccHandler Aug 24 2007, 01:24 AM

Eureka!

I know what the problem is, and it is a bug in VirtualDub-MPEG2. I'll avoid a long explanation, and just say that my above description of the correct skew calculation is NOT what the program is actually doing.

I broke it a long time ago when I honored a http://forums.virtualdub.org/index.php?act=ST&f=11&t=10880 to reduce the memory footprint of VirtualDub-MPEG2 by not storing the PTS of every sample.

I'll fix the bug ASAP.

BTW, the correct skew for VTS_01_4.VOB is -432 ms.

Posted by: neuron2 Aug 24 2007, 03:59 AM

Posted by: fccHandler Aug 24 2007, 04:16 AM

QUOTE (neuron2 @ Aug 23 2007, 11:59 PM)

What does DGIndex report? Just curious.

DGIndex reports -128, but that's correct for DGIndex because you elect to remove part of the audio to compensate for the orphan frames you remove.

The sequence (in coding order) begins BBPBBIBBPBBP...

DGIndex removes 5 frames (I think) and pops up a warning about the opening GOP not being closed. VirtualDub-MPEG2 removes 7 frames, but doesn't remove any of the audio, so it reports a larger skew.

@rmanal:
I've put a new build up:
http://fcchandler.home.comcast.net/stable

This should give an accurate skew value in "File Information" for all of your VOBs. Let me know if it doesn't.

Keep in mind the bug I spoke to phaeron about (earlier in this thread), because that is not yet fixed in my version.

Posted by: rmanal Aug 24 2007, 11:47 AM

Very great job. SO as I have read, NAV block does not enter in delay calculation.
Because I'm a newbee in MPEG2 specification, could you show me in VOBedit where are the PTS video and audio time parameter in PTS part, because I have understood, PTS part only exist for audio stream, exactly for private stream #1.
Now I'm curious

I have tried to use DGIndex but I don't andertand where you have seen this -128ms value???? Furthermore I don't andesrtand what the meaning of a GOP not being closed.

I will try your new version, thank you very much for your effort.

Posted by: neuron2 Aug 24 2007, 12:14 PM

Posted by: fccHandler Aug 24 2007, 06:02 PM

DTS and PTS must be sent periodically for all of the elementary audio and video streams in a program stream. They are described in the "Systems" part of the MPEG-2 specification:

http://www.neuron2.net/library/library.html
(Scroll down to "Encoding/Decoding MPEG-2")

Posted by: rmanal Aug 28 2007, 07:57 AM

OK I have read a lot of informations about MPEG2 specification and, with your help, I have retrieved how you calculate audio-video delay, but this have implied another question:
- How VDMPEG2 will remove orphan picture and audio pack?
- Because B and P pictures are not generally in the presentation order in the stream, and because in some VOB files thay do not includes PTS informations, how is rebuilt the presentation order?

I have tried your new VDMPEG2 and it looks good. Thank you.

Posted by: fccHandler Aug 28 2007, 06:43 PM

The presentation order is derived from the frame type, and the list of frames is sorted using a simple algorithm. In pseudo code:

CODE

for (n = 1; n < number_of_frames; ++n) {
if (frame[n] is a B-frame) {
exchange frame[n] and frame[n - 1];
}
}

After the list is sorted into presentation order, any P- and B-frames at the beginning of the list are removed, so that the first frame in the list is always an I-frame.

VirtualDub-MPEG2 doesn't remove any audio.

Posted by: phaeron Aug 29 2007, 06:46 AM

You can have B frames prior to the first I frame in presentation order and still have a valid first closed GOP, as long as the B frames only use backward prediction. Dunno about MPEG-2, but the MPEG-1 spec specifically calls this out as valid, and I've hit MPEG streams in the wild that had this.

Posted by: fccHandler Aug 29 2007, 07:26 AM

I know, and it's the same with MPEG-2. But I fear that trying to handle that situation will make the code overly complicated. It's much easier to simply assume that B-frames generated by the MPEG encoder must depend on both forward and backward reference frames, and just remove them if those references are not present.

I am actually rethinking all of the Mpeg2.cpp code though, because I'm still not convinced that the reported "skew" is 100% reliable.

Posted by: rmanal Aug 30 2007, 08:42 AM

OK with my VOB files and with VOBedit I have retrieved manually the value given by your new version of VDMPEG2.

Two questions:
- why do you think the reliability of your skew calculation are wrong?
- why do you keep audio block before the first I picture. Are they useful, because this functionning introduce a larger delay in audio-video?

Posted by: fccHandler Aug 30 2007, 06:15 PM

Two answers:

- It could be wrong if the first samples in the presentation are lacking PTS (particularly audio samples).

- As a general rule, I try to remove as little as possible, but I'm rethinking that in light of the above.

Posted by: rmanal Sep 6 2007, 11:54 AM

OK so I have rebuilt all my avi files from VOB files using your next version of VDMPEG2 and it works well.
Nevertheless I have encountered a new problem: with 4 of the avi files I have created, I have made a unique file using the append command.
No problem with the first avi file but with the other I see again a delay in audio in the unique avi file instead there is no delay in the four avi files: what'wrong?

I will add these files in my ftp server this evening.

Posted by: foxidrive Sep 6 2007, 12:29 PM

IIANM it's likely that the video and audio streams in one/all of the files is not the same length, hence the following stream gets shifted in time. A solution I have used in the past is to remove the last snippet in each file to even out the ends of the streams and then append them.

Posted by: fccHandler Sep 7 2007, 07:14 AM

Sync isn't guaranteed if the appended files have compressed audio. It's a long story, but your best bet is to stick with uncompressed PCM audio when you're editing and/or appending video files, and only compress the audio when you're ready to render the final AVI.

In other news, I'm seeing a long freeze after parsing some large MPEG-2 files. It isn't fatal, just annoying. I'll fix this as soon as I can.

Posted by: rmanal Sep 7 2007, 10:42 AM

The audio part of my avi files are in PCM.
You can download my files:
Film Mariage-film 2-partie 01.avi, composed of the following files:
Film Mariage-film 2-partie 01-part1.avi
Film Mariage-film 2-partie 01-part2.avi
Film Mariage-film 2-partie 01-part3.avi
Film Mariage-film 2-partie 01-part4.avi

Posted by: fccHandler Sep 7 2007, 06:09 PM

I downloaded your smallest file (part 2), and indeed its audio track is slightly shorter than its video track (72 milliseconds, to be exact). It's a small amount, but the difference will accumulate to a big amount if all of your pieces are like this.

VirtualDub joins the audio end-to-end when appending, so if the audio of part 1 is too short, then the audio of part 2 will start too early, and so on with additional parts.

There are at least two ways to fix this. As foxidrive said, you can trim a video frame or two from the end of the movie, and resave the file in direct stream copy mode, until the audio duration exactly matches the video duration. You'll need to do this for each part before you append them together. In your case, the formula you want to match is:

number of audio samples = number of video frames * 1920

You can see the number of audio samples in "File Information."

The other (more tedious) way is to manually edit the audio tracks by saving them as WAV files and loading the WAVs into an audio editor. Use the editor to add or remove samples as needed, until the duration is exactly correct, then import the WAV back into VirtualDub and resave the movie using direct stream copy.

Posted by: rmanal Sep 9 2007, 06:37 PM

Isn't it possible for VDMPEG2 to automatically corrects shorter audio stream when it appends avi files?

Posted by: fccHandler Sep 9 2007, 10:52 PM

Possible? Sure, but it would have to be rewritten. Unfortunately, I didn't write the "append" code and I don't know anything about how it works.

Just to clarify, I can only address flaws specific to the code I've added to VirtualDub-MPEG2. I'm not able to fix issues in VirtualDub itself, because the base code is huge and complex, and most of it is way beyond my level of understanding.

Posted by: rmanal Sep 11 2007, 08:08 AM

For the developers of VirtualDub: could-you improve the append function as described just before?

Posted by: fccHandler Sep 13 2007, 06:31 AM

I've released a new build tonight, which will (hopefully) give you a more reliable skew value in "File Information." Unfortunately I had to delete my copy of your VOB file (because I needed to free some hard drive space), so I haven't tested the new build with your movie. I will leave that job to you.

The new skew value will likely be different from the skew value in my previous build, because I'm now removing audio blocks which lack PTS.

Please let me know if this build works for you:
http://fcchandler.home.comcast.net/stable

Posted by: rmanal Sep 14 2007, 07:03 AM

I have retested my VOB file and instead the old version of VDMPEG2 gave -432ms, the new one gave -112ms but the delay between audio and video is still of -432ms, as shown when I play it under VDMPEG2.
So it looks like not working.

Posted by: fccHandler Sep 14 2007, 07:46 AM

Damn, I'm sorry to hear that. I still have the previous version, if you need to restore it:

http://fcchandler.home.comcast.net/stable/Previous/VirtualDub-MPEG2-1.6.19.zip

I haven't given up on this, but I'll probably need to download VTS_01_4.VOB again, for testing. If you would be so kind, please use VirtualDub's hex editor to extract a 10 MB portion from the beginning of the VOB file:

- Go to "Tools / Hex editor"
- Open your "VTS_01_4.VOB"
- Choose "Edit / Extract segment", address = 0, length = A00000

Save that file, and please make it available to me on your FTP server, hopefully by Sunday. Thanks rmanal.

Posted by: rmanal Sep 14 2007, 06:12 PM

The name of the file is VTS_segment.

Posted by: fccHandler Sep 14 2007, 08:28 PM

It turns out that my fix for the freezing problem breaks the skew calculation for your VOB, but I think I've solved it now:

http://fcchandler.home.comcast.net/stable

This build reports the same skew as before (-432 ms), and I'll affirm that is 100% correct for this particular VOB.

It actually doesn't remove any audio in this case because your first audio packet does have a Presentation Time Stamp on it. However, if you open a VOB in which that is not true, any unstamped audio packets will be removed from the start of the presentation, to ensure that the reported skew is correct.

Posted by: rmanal Sep 17 2007, 06:34 PM

What was the freezing problem?

Posted by: fccHandler Sep 17 2007, 06:45 PM

I posted about it on page 3 of this thread:

QUOTE (fccHandler @ Sep 7 2007, 03:14 AM)

In other news, I'm seeing a long freeze after parsing some large MPEG-2 files. It isn't fatal, just annoying. I'll fix this as soon as I can.

It's fixed now.

Posted by: rmanal Sep 27 2007, 06:21 AM

OK now everything work fine.
Thank you very much for all tour help.