|
|
| rmanal |
| Posted: Aug 20 2007, 04:36 PM |
 |
|
Advanced Member
Group: Members
Posts: 153
Member No.: 11636
Joined: 28-August 04
|
NAV block = NAV PACK as shown by VOBedit software.
There is a field "offset to audio packet for audio stream N". |
|
| fccHandler |
| Posted: Aug 20 2007, 07:17 PM |
|
|
Administrator n00b
Group: Moderators
Posts: 3961
Member No.: 280
Joined: 13-September 02
|
| 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.
--------------------
May the FOURCC be with you... |
|
| fccHandler |
| Posted: Aug 20 2007, 07:35 PM |
|
|
Administrator n00b
Group: Moderators
Posts: 3961
Member No.: 280
Joined: 13-September 02
|
| 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.
--------------------
May the FOURCC be with you... |
|
| phaeron |
| Posted: Aug 20 2007, 09:11 PM |
|
|
Virtualdub Developer
Group: Administrator
Posts: 7773
Member No.: 61
Joined: 30-July 02
|
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.  |
|
| fccHandler |
| Posted: Aug 21 2007, 12:55 AM |
|
|
Administrator n00b
Group: Moderators
Posts: 3961
Member No.: 280
Joined: 13-September 02
|
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).
--------------------
May the FOURCC be with you... |
|
| phaeron |
| Posted: Aug 21 2007, 01:15 AM |
|
|
Virtualdub Developer
Group: Administrator
Posts: 7773
Member No.: 61
Joined: 30-July 02
|
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.
|
|
| fccHandler |
| Posted: Aug 21 2007, 01:21 AM |
|
|
Administrator n00b
Group: Moderators
Posts: 3961
Member No.: 280
Joined: 13-September 02
|
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.
--------------------
May the FOURCC be with you... |
|
| rmanal |
| Posted: Aug 21 2007, 04:46 PM |
|
|
Advanced Member
Group: Members
Posts: 153
Member No.: 11636
Joined: 28-August 04
|
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? |
|
| fccHandler |
| Posted: Aug 21 2007, 06:44 PM |
|
|
Administrator n00b
Group: Moderators
Posts: 3961
Member No.: 280
Joined: 13-September 02
|
| 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?
--------------------
May the FOURCC be with you... |
|
| rmanal |
| Posted: Aug 22 2007, 12:35 PM |
|
|
Advanced Member
Group: Members
Posts: 153
Member No.: 11636
Joined: 28-August 04
|
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 |
|
| fccHandler |
| Posted: Aug 22 2007, 06:03 PM |
|
|
Administrator n00b
Group: Moderators
Posts: 3961
Member No.: 280
Joined: 13-September 02
|
| 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.
--------------------
May the FOURCC be with you... |
|
| rmanal |
| Posted: Aug 23 2007, 12:14 PM |
|
|
Advanced Member
Group: Members
Posts: 153
Member No.: 11636
Joined: 28-August 04
|
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.
|
|
| fccHandler |
| Posted: Aug 23 2007, 08:25 PM |
|
|
Administrator n00b
Group: Moderators
Posts: 3961
Member No.: 280
Joined: 13-September 02
|
| 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 here. 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.
--------------------
May the FOURCC be with you... |
|
| fccHandler |
| Posted: Aug 24 2007, 01:24 AM |
|
|
Administrator n00b
Group: Moderators
Posts: 3961
Member No.: 280
Joined: 13-September 02
|
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 request 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.
--------------------
May the FOURCC be with you... |
|
| neuron2 |
| Posted: Aug 24 2007, 03:59 AM |
|
|
Advanced Member
Group: Members
Posts: 1244
Member No.: 5294
Joined: 18-July 03
|
. |
|
