|
|
| XEQtor |
| Posted: Sep 7 2010, 09:15 AM |
 |
|
Newbie
Group: Members
Posts: 2
Member No.: 15885
Joined: 13-July 05
|
I'm sure this could have been asked before, but my search in the forum did not return anything.
Please bear with me...
I have an AVI with Huffyuv v2.1.1 video (all key frames) and AC3 audio (fccHandler's plugin). Video is 25 fps (40 ms/frame). AC3 is 32 ms/packet (checked, no ECC errors). Audio delay is 0ms, preload 512ms, Interleave every 1 frame. Clip duration: 79372 video frames, 99183 audio samples. VirtualDub 1.9.9 Build 32817/release.
Under "Direct Stream Copy" (DSC), I would like to cut off commercial advertisements in several areas and then save this back to an AVI, under DSC for both audio and video. I would like to encode the video later and use the audio "as is" when I remux to another container.
Questions:
What does VirtualDub do when I cut off video frames which are not located at full audio packet boundaries? Or when I cut off video frames which do not total full audio packets? What happens to the remaining audio? With 40ms/frame and 32ms/packet, there will be many areas where I may introduce AV skews.
Scenario 1:
Since all my videos are key frames, what if I cut off the 1st video frame (40ms)? What happens to the audio? Does VirtualDub remove 1 audio packet (32 ms), leaving behind an 8ms skew? It's impossible to check an 8ms skew and nobody will notice this under normal playback.
If it does this, will it remember that we now have 8ms of "extra" audio and will "adjust" this if we do another edit somewhere else? Say, I go somewhere inside and cut off just 1 more frame - that's another audio packet off and another 8ms of "extra" audio skew, making this 16ms of skew (half a packet). If I do another 1 frame cut (another 1 packet off, plus another 8ms of "extra" audio), the total skew will be 24ms so far. If this is what happens, will VirtualDub recognize this and "throw out 1 more audio packet at this point and get to a -8ms skew" instead? Will my audio skew by 8ms initially, and then by 16 ms after the 2nd cut, and then magically gets back to only -8ms?
Or, does VirtualDub blindly cuts into the audio packet to the full 40ms? I'm sure VirtualDub does not do this or else I would have gotten lots of ECC errors in my AC3 packets (and playback will skew horribly).
Scenario 2:
If I "selection start" at frame number 250 (0:00:10.000), and "selection end" at frame number 282, a total of 32 frames (40 audio packets), and delete them, what happens to the audio skew? Looking at the audio track, I started the cut at audio packet location 312.5, and lobe off 40 packets worth of audio. What did VirtualDub do? Did it start the audio cut after 312 packets (round down) or 313 packets (rounding up)? I though I observed an extra 32 ms of audio (1 packet) was removed, and needed a delay of 32ms to maintain sync. But I might be mistaken (perhaps just 16ms?).
What if I then do another cut? Reset audio delay back to 0 ms. I "selection start" at frame number 750, and "selection end" at frame number 782 (another 32 frames, or 40 audio packets). Again, this starts somewhere in the middle of an audio packet. I noticed that there is perfect sync after this. What happened? Did VirtualDub just "corrected itself" because it "remembered"?
I'm sorry that this sounds so convoluted. I hope some of the experts here can give some insights. I've been pulling my hair out trying to anticipate and understand what VirtualDub is doing to my edits. 16 or 32 ms is very hard to catch, you thought you saw it at some places, but then it goes away at other places. I can easily cut 1 or 2 frames more or less from my edits if this will give me a maximum skew of 8ms throughout. No human eye will catch this.
Thank you for reading this far.
XEQ. |
|
| phaeron |
| Posted: Sep 8 2010, 03:18 AM |
|
|
Virtualdub Developer
Group: Administrator
Posts: 7773
Member No.: 61
Joined: 30-July 02
|
I don't know the details of AC3 encoding, but I can tell you how VirtualDub handles it.
VirtualDub works with AVI streams in general, so whether or not you can get runts depends on whether the audio frames are aligned to sample boundaries in the AVI container. For MP3, and I suspect, AC3, they aren't and therefore you'll get partial packets on the cut boundaries. This means that the decoder needs to recognize this and appropriately adjust the decoded output. Dealing with this properly involves heavy format-specific handling and is often tricky even at that level -- in MP3 it involves decoding and re-encoding several frames, which is one reason I have avoided doing any such code. (It sort of defeats the idea of stream abstraction too, but people don't seem to care much about that anymore.)
If the sample boundaries are aligned, then you can get clean cuts between the frames/packets, in which case VirtualDub will attempt to keep the error to within 1/2 packet. For instance, with 40ms packets, the start of each cut section will be aligned to within +/-20 ms. The error is tracked for further sections, so if one section ends up being 10ms ahead, VirtualDub will bias the decision for the next section by -10ms to compensate, preventing error from accumulating later in the video. Even though you've got reasonably clean edits at this point, you can still end up with decoding errors at the join points because it's common for there to be dependencies between the packets -- in MPEG layer III there are "rollover bits" from previous frames (bit reservoir). Good decoders will mute or conceal the audio on detecting decoding errors; bad ones will give "oink" sounds or possibly even crash.
The audio delay is applied after the edit list / subset has been processed; it doesn't matter what delay setting you have set when you make the edits, only when you start the final render. The way this works is that it shifts the entire source stream, then the edits are applied.
Basically, the conclusion is that if you can edit in uncompressed / source form, you're much better off. That not being possible, your second best bet is to use a format-dedicated editor if you have one available. Modern compression formats are complex enough that attempting to edit them is frought with peril.
|
|
|
