alosada wrote:The effects of the bug
As noted in the first post, VideoStudio introduces a pair of redundant frames at each edit point when it smart renders a field-based mpeg2 file. As a result, the audio goes ahead of the video by two frames after the edit point. For example, if two redundant video frames (R
1 and R
2) are inserted at position 5 in the following stream
V
1V
2V
3V
4V
5V
6V
7V
8V
9
A
1A
2A
3A
4A
5A
6A
7A
8A
9
the result is
V
1V
2V
3V
4V
5R
1R
2V
6V
7
A
1A
2A
3A
4A
5A
6A
7A
8A
9
so the seventh video frame, which was initially matched to the seventh audio frame, is now aligned with the ninth and the audio is therefore two frames ahead of the video.
As new pairs of RFs are inserted at subsequent points, the gap between the video and audio grows, so, when playing back any VOBs made from the smart rendered file, the audio will finish before video to an extent proportional to the number of redundant video frames present in the buggy file.
An NTSC frame lasts one-29.97th of a second (that is, 33.37 milliseconds) and a PAL frame one-25th (40.00 ms). Each pair of redundant frames therefore introduces a lag of 66.74 ms in NTSC files and 80.00 ms in PAL files. As a result, the video in a spuriously smart rendered file will be delayed with respect to the audio by about 1 second (1000 ms) after 15 (1000/66.74) pairs of bad frames (that is, 15 edits) in an NTSC file or 12 (1000/80) in a PAL file.
The asynchrony, however, may start at the very beginning of the clip. So, if a captured file is trimmed to remove the commercials preceding a show, for example, the first pair of redundant frames in the smart rendered mpeg file will normally appear within the first 0.5 seconds and an audio delay of 67 ms (NTSC) or 80 ms (PAL) which is long enough for some people to notice will be present virtually right from the start even if the original clip goes through no further editing.
Why is the AV asynchrony initially not apparent?
The video and audio streams in an mpeg file that contains redundant video frames usually appear to be in perfect synchrony during playback in programs such as WMP, Ulead DVD Player or VideoStudio itself. Only after the file is burned to a DVD or converted into VOB files does the problem become apparent. Why?
During playback, the timing information contained in an mpeg file (so-called presentation time stamps) helps software players align video frames with their matching audio frames (that is, to present them simultaneously at the right time). As a result, AV asynchrony problems usually go unnoticed since most players are capable of resynchronizing the video and audio at the start of each GOP (that is, approximately every 0.5 seconds).
However, when an mpeg file is converted into VOBs for burning onto a DVD, the video and audio streams which together form a program stream?are first separated (demultiplexed) as two elementary (video and audio) streams that are then rejoined (multiplexed) to make a new program stream (one or more VOB files).
Because the separate, elementary streams contain no presentation time stamps, any redundant or missing frames in either will inevitably lead to desynchronization of the video and audio when they are recombined as their frames will have to be matched blindly in the order they appear in their respective streams with no provision for potential misalignment at any point.
Detecting the FR bug and identifying its effects
How does one know whether a file contains redundant frames?
Detecting the presence of the FR bug in an mpeg file could be as easy as comparing its length with the combined length of the bits from which it was rendered (that is, the project length). The latter is displayed as project duration in VideoStudio 9 ─and under project preview range in VideoStudio 7 and 8─ while the project containing such bits or clips is on the timeline click the Share tab and then the Edit tab if you don't see it.
However, the duration of an mpeg file containing redundant frames one sees in VideoStudio (for example, by right clicking its thumbnail and selecting Properties) is not its actual length, but rather the one it would have had if the project had been properly rendered.
An external program is therefore needed to determine the true length of files having the FR bug. One such program is VirtualDub MPEG2, which is available for free at
http://fcchandler.home.comcast.net/stab ... -MPEG2.zip
VirtualDub will tell you the exact number of video frames a file contains, which you will then be able to compare with the duration of the project used to encode it if you still have the .vsp file. If the rendered mpeg file has more video frames and is thus longer than its parent clips together, then you can suspect it contains redundant frames. The difference will normally be an even number as each instance of the bug introduces a pair of redundant frames.
What do redundant video frames look like?
In a word: scrambled. In fact, unless closed GOPs rather than open GOPs the standard in VideoStudio have been used from the beginning, the redundant frames contain a number of spurious large square blocks 16x16 pixels in size. Oddly enough, these macropixels are invisible in stills captured from the bad frames, so if you want to take a snapshot of a redundant frame you will have to use screen capture software.
Also, the frames can only be inspected in programs affording smooth frame-by-frame navigation through the video stream without skipping redundant frames. VirtualDub MPEG2 is one such program.
In any case, locating the redundant frames is easier when the project from which the suspect file was rendered is still available and the exact points in time where some edit (cut, transition, filter) was introduced can be used to determine their positions in the rendered file. Alternatively, you can use insert scenes as chapters in the Share step to help you locate the redundant frames produced by trimming or any visual effect except an overlay.
After you have recorded the positions of your edit points, open the suspect file in VirtualDub and navigate or jump to their immediate vicinity in order to inspect the individual pictures one by one in search of the tell-tale macropixels.
How can AV asynchrony be checked?
As noted previously, VideoStudio is normally useless to check mpeg files for AV asynchrony as it manages to align their video and audio as if they were in perfect synchrony and so does Ulead DVD Player, for example.
As before, you will need an appropriate program for this purpose. VirtualDub MPEG2 is fit for mpeg files, but Windows Media Player is not as it conceals AV asynchrony in them just like Ulead software does. Please note, however, that VirtualDub cannot play back Dolby audio and that WMP requires installing an AC3 codec other than the Ulead's for this purpose. You can download a free AC3 codec that works with WMP here:
http://www.free-codecs.com/AC3_Filter_download.htm
On the other hand, the best free program for checking whether DVD files (VOBs) are OOS and also for fitting overly long VOBs onto a DVD, which is its primary purpose? is probably DVD Shrink, which you can obtain here:
http://www.dvdshrink.org/where.html
WMP is also fit for detecting AV asynchrony in VOBs, an so is obviously any software-based DVD player such as Ulead's.
Which burning engine versions work?
Nearly all burning engine versions released by Ulead since VideoStudio 7 was launched allow both VS7, VS8 and VS9 to produce synchronous VOBs from mpeg files containing redundant frames. Such versions, identified by that of the file ULCDRDrv.dll in the \\Program files\\Common files\\Ulead Systems\\DVD folder, include the following:
2.9.2.98, dated 12/06/02 and released with VS7
3.4.8.162, dated 07/29/03 and released as the D/DVD Plugin Patch?
3.6.15.218, dated 03/12/04 and released with VS8
3.6.15.232, dated 04/21/04
3.6.8.260, dated 01/31/05 and released with VS9
On the other hand, the following updates to the burning engine don't repair the AV asynchrony produced by the FR bug:
3.6.15.239, which was first released as a stand-alone file package on 06/03/04 and then included in the VS 8.01 update patch (06/07/04)
3.6.17.246, dated 07/27/04
3.6.17.255, dated 10/22/04
Therefore, all versions predating the native burning engine of VS9 and following that of VS8 are ineffective to correct the AV asynchrony produced by redundant frames. If one doesn't have VS9 and has applied any of the intervening burning engine updates, then regaining the ability to repair the asynchrony requires restoring the original files in the VS7 or VS8 \\Program Files\\Common files\\Ulead Systems\\DVD folder at the expense of missing any enhancements introduced by the subsequent, ineffective versions.
The foregoing also applies to Movie Factory, MediaStudio Pro and DVD Workshop, which produce synchronous VOBs both with the previous effective burning engines and with their own native files, namely: version 3.0.2.104 (dated 12/05/02 and belonging to the bundled MF2) in MSP 7; v. 3.5.13.196 (11/26/03) in MF3; v. 3.6.14.201 (12/24/03) in DVD Workshop and v. 3.6.8.260 (01/06/05) in MF4 he last, however, fails with the ~convert###.mpg files produced from MF4 projects.
How is the AV asynchrony repaired?
In order to repair the AV asynchrony introduced by redundant frames in an mpeg file, the burning engine shortens the time each frame following them in the resulting VOB file is displayed as required for the video to catch up with the audio within a reasonable time which is usually only about half a second. In this way, it forces DVD players to display up to 32 NTSC frames or 27 PAL frames in one second that containing each pair of redundant frames.
On the other hand, those burning engine versions that fail to correct the asynchrony when multiplexing the elementary streams complete the audio stream before the video stream, so they have to add some audio actually, some silence at the end of the VOB in order to match the surplus video frames.
As noted in is there a cure? in post 1, VideoStudio can also correct the asynchrony caused by the redundant frames present in mpeg files obtained by using Save Trimmed Video on the Clip menu without the need to wait until the Create Disc step. In fact, in dumb rendering an STV clip, VideoStudio removes a couple of frames at the end, so the number of video frames matches that of audio frames and the two streams are properly aligned beyond that point. This can be used to assemble virtually synchronous long composite files from short clips previously rendered by using the STV function as the audio lag within each clip will never exceed about 67 milliseconds in NTSC files and 80 ms in PAL files which may be quite acceptable or even undetectable.
How does VideoStudio produce the redundant frames?
Trimmed clips
When a video clip is trimmed, VideoStudio splices the segments preceding and following the trimmed portion after reconstructing the tail of the former and the head of the latter. In the process, it closes the last GOP in the tail (the pre-GOP) and sets the broken link flag on the first GOP in the head (the post-GOP).
While redoing the tail of the segment preceding the trimmed portion normally poses no problem for VideoStudio, the program fails in reconstructing the head of the segment following it. So, it encodes the last two frames in the post-GOP twice and uses the two redundant frames to open a new GOP immediately after it.
In fact, once it has encoded the last frame in the post-GOP, it starts a new GOP with two B frames preceding the first I frame in it. However, instead of starting with the frame naturally following the last in the post-GOP, it rolls back two frames in the sequence and encodes the last two in the post-GOP again, using the latest P or I frame available as backward reference B frames can be encoded with respect to a previous I or P (backward reference) frame and a subsequent I or P (forward reference) frame.
If the post-GOP consists of a single, I frame, then the first redundant frame in the pair is the last frame in the trimmed portion which should obviously not be present in the rendered clip?and the second is the last and only frame in the post-GOP, which is used as the backward reference for both.
Finally, if the post-GOP contains zero frames (that is, if no GOP was broken in the head of the segment following the trimmed portion because the cut was made at an I frame), then the two redundant frames are the last two in the trimmed portion which, again, should not be there as they were supposed to have been removed?and their backward reference is the last frame in the pre-GOP which is also the latest P or I frame available.
When a whole number of GOPs is trimmed from the beginning of the first clip in a project, VideoStudio has no backward references to encode the redundant frames to pre-GOP exists so it produces none. This only applies to the first clip in the project as trimming any number of GOPs off a subsequent clip on the timeline does leave a pair of bad frames because a backward reference exists in front of the trimmed portion.
Because the frame used as backward reference to encode the redundant frames is not their natural, closest reference, but rather one a variable number of frames back in the sequence, its macroblocks do not blend in harmoniously with the rest of the picture and look extraneous. Hence the scrambled appearance of the two redundant frames particularly when the original clip is trimmed at an I frame and, as a result, the post-GOP is zero frames long, the redundant frames belong to the trimmed portion and the spurious macropixels are from the last frame in the pre-GOP, which may have come seconds or minutes earlier in the original clip.
This last situation, which should be the least troublesome in editing mpeg files as it represents GOP-accurate rather than frame-accurate trimming, results in the most striking effects: a sort of flashback at the scene change usually underlying a trimming operation.
Unfortunately, these posts lack the formatting capabilities required to illustrate the previous explanation with tables clearly showing the changes undergone by the different frames and GOPs involved in a trimming operation.
Visually edited clips
The problem here is similar to that faced when trimming a clip. Unlike cut points on both sides of a trimmed portion, however, VideoStudio cannot smart render a transition, filter, title, overlay or playback speed change as the process involves altering the visual appearance of some video frames rather than simply removing them and splicing the remainder. As a consequence, a video portion that has been applied a visual effect will never contain redundant frames; rather, the bad frames will appear immediately after the end of the visually altered portion. Why?
The process can be thought of as VideoStudio extracting the visually edited portion from the video stream, dumb rendering the required changes in the frames it contains and, finally, splicing both ends with the tail of the video portion preceding it on one side and the head of that following it in the clip on the other. Again, VideoStudio has no problem with the GOP preceding the edited footage (the pre-GOP), but fails rebuilding the joint on the other end (the post-GOP). The resulting bad, redundant frames appear in the same position relative to the edit point which is now the equivalent of the cut point in trimming operations.
Where does the edit point thus lie? Exactly at the frame immediately following the last touched by the visual effect as if the video clip were trimmed at the point where the effect ends.