For the past several years, audio–video asynchrony in VideoStudio and other Ulead programs has been blamed on a number of factors relating to the hardware and software we use or the way we use them. However, many people have rightly complained that they follow the good practices recommended in this forum and yet continue to have AV asynchrony problems. What follows is a compilation of the results I have obtained after a fair amount of testing following my recently bumping into what might be the origin of some: the frame redundancy bug.
This topic is presented in three posts. This first post introduces the problem, which is explained in greater detail in the second (“More about the FR bug”). Finally, the third post provides sort of a standard test for checking whether one's VideoStudio version produces the bug.
Although the focus is on VideoStudio, the key points also apply to Movie Factory and MediaStudio Pro. For specific information about the latter two, please read “What about other Ulead programs? in post 2.
I apologize for taking up so much forum space and for any inconsistencies in the discussion. I hope it may be of help to clarify the issue anyway.
What is the frame redundancy bug?
As we know, AV asynchrony can be gradual or non-gradual depending on whether it increases uniformly throughout a clip or only, abruptly, after specific points in it.
Gradual asynchrony often arises from the video and audio in a clip being acquired separately via two devices such as a video capture board and a sound card. Any difference in sampling rate between the two can result in the lengths of the video and audio streams captured after some time not matching, the gap widening with time.
With non-gradual or abrupt asynchrony, however, the video and audio may be mismatched virtually from the beginning. The problem can grow at specific points, but usually doesn't in between —unless gradual asynchrony is also present.
Non-gradual asynchrony is usually the result of a captured file containing dropped frames or acquiring them at some time during its processing. In VideoStudio, it often arises from the editing of mpeg files. So, while just removing a few portions from an mpeg clip should pose no problem, it seemingly does in some versions.
This self-caused problem is what we might call the “frame redundancy bug”, a software glitch that artificially lengthens the video stream of an edited mpeg clip upon re-encoding and may be behind some elusive OOS issues reported in this and other Ulead forums.
What are the symptoms and how can they be detected?
The frame redundancy (FR) bug has a visual impact and also what seem to be audio-related effects but are actually the consequences of its altering the video stream. Its principal visual effect is jerky scene changes —as if the action froze or the video were played backwards for a split second.
Besides, the FR bug introduces non-gradual AV asynchrony that builds up as it surfaces at each edit point in the video stream. In fact, the bug sends the video in a clip out of synchrony (OOS) with its audio by effect of its introducing spurious, redundant video frames that artificially increase the length of the video and cause it to be misaligned with the audio.
The outcome is a departure —specifically, a delay— of the video from the audio that grows as the number of redundant frames increases. For more details, please read “The effects of the bug” in post 2.
Identifying the FR bug from its symptoms is rather difficult, if not impossible, in VideoStudio because it manages to skip the spurious frames and not display them. Also, like most software capable of playing back mpeg files, VideoStudio can realign the video and audio streams in a clip approximately every 0.5 seconds, so any audio or video delay will normally go unnoticed until the buggy file is converted into VOBs for burning onto a DVD. Please read “Why is the AV asynchrony initially not apparent?” in post 2 for more details.
Consequently, accessing and inspecting redundant frames requires using an appropriate external program as described in “Detecting the FR bug and identifying its effects” in post 2. While it can also be done in VideoStudio, the procedure is rather cumbersome as it involves using the buggy file to make an OOS VOB with a burning engine version unable to repair the asynchrony.
What causes the bug and what doesn't?
The FR bug arises when a previously captured or rendered field-based mpeg2 file the video stream of which has been “touched” in any way is smart rendered. “Touched” here means trimmed or applied any visual effects and “visual effects” include transitions, video filters, titles, overlays and even playback speed changes. Also, note that all clips obtained by using Clip > Save Trimmed Video on the VideoStudio menu are smart rendered.
AV asynchrony has sometimes been ascribed to a bug in the CD/DVD Burning Engine. Any such bug is definitely not the FR bug. In fact, while installing Ulead's succession of updates to the files in the \Ulead Systems\DVD shared folder may have left some systems defenseless against the effects of the bug, the burning engine is not the origin, but the solution to the OOS problem caused by VideoStudio itself.
Unfortunately, some versions of the engine fail to repair the AV asynchrony. You can check whether yours does in “Which burning engine versions work?” in post 2.
Going to Create Disc directly to burn a project on the timeline rather than encoding its contents into a single mpeg file first has also been cited as a source of AV asynchrony. Again, this has nothing to do with the FR bug. Why? Because VideoStudio first encodes the clips on the timeline into a file named ~convert###.mpg from which it then produces the required VOB file(s). Because the conversion and multiplexing (VOB-making) operations are sequential, not simultaneous, the burning engine is given the opportunity to correct the asynchrony resulting from the redundant frames contained in ~convert###.mpg as explained in “How is the AV asynchrony repaired?” in post 2.
For identical reasons, using Add VideoStudio Project instead of Add Video in the Create Disc step does not trigger the FR bug either.
The bug never occurs in frame-based videos, which include all mpeg1 files, but only in field-based (Lower Field First or Upper Field First) mpeg2 files.
Although it has a deceptive impact on the audio, the bug is associated to no specific audio format (LPCM, MPEG, AC3) or sampling mode–rate–bitrate combination as, in fact, it doesn't alter the audio stream. Therefore, it doesn't arise from treating the audio in any way such as normalizing the volume, inserting fading-in/out effects or using an audio filter, for example.
Also, the FR bug is unrelated to whether square or non-square pixels are used, or whether the edited file is encoded using CBR or VBR, whichever the video bitrate.
Finally, simply joining two previously encoded mpeg clips doesn't trigger the bug unless a transition is inserted between the two or some visual effect is applied to either.
What is the origin?
Smart rendering involves scanning the clips that make up a project in order to detect any changes made with respect to the original mpeg file(s) and re-encoding only small portions on both sides of each edit point. “Edit point” here means the frame immediately following the last in a portion trimmed off a clip (that is, the first frame retained after a cut) or that following the last frame affected by a visual effect —be it a transition, filter, title, overlay or playback speed change.
In smart rendering the timeline contents, VideoStudio spuriously encodes a couple of frames in the vicinity of each edit point twice, thereby introducing two redundant frames into the video stream. This causes the video to depart from the audio in much the same way dropped video frames do.
For a more detailed explanation, please read “How does VideoStudio produce the redundant frames?” in post 2.
Is there a cure?
There is —at least for the OOS problem. In fact, the appropriate versions of the burning engine manage to repair the AV asynchrony introduced by the FR bug and to produce synchronous VOBs and DVDs as long as the source mpeg file isn't subject to asynchrony of a different origin as well.
In any case, the burning engine does not remove the bad frames, so the video will still exhibit jerky scene changes at edit points when converted into VOB files and, ultimately, a DVD.
Unfortunately, once an mpeg file containing redundant video frames is rendered into one or more OOS VOB files as a result of using an ineffective burning engine version, restoring AV asynchrony is difficult and time-consuming, if not impossible. Also, a DVD made from such an mpeg file in non-Ulead authoring software will be OOS unless the file is previously repaired by using an appropriate mpeg editor.
By exception, the AV synchrony in an mpeg clip which was obtained by using Save Trimmed Video on the Clip menu can be restored —albeit only at its very end—by re-rendering the clip with SmartRender disabled. This can be used to assemble virtually synchronous long composite files from short clips previously rendered with the STV function.
Removing the redundant frames in order to avoid their visual impact is even more complicated. In fact, some video editing and repair programs automatically delete the two frames following each pair of redundant frames rather than the offending frames, so getting rid of the latter is an elaborate process that includes splitting the video and audio streams, trimming the bad video frames by hand and rejoining the two elementary streams into a synchronous program stream —obviously, with SmartRender off this time.
Please read “How is the AV asynchrony repaired?” in post 2 for further details.
Can the bug be avoided?
As usual, prevention is better than cure here. So, the FR bug can always be avoided by re-encoding (that is, “dumb” rendering) one's projects with SmartRender disabled. It is therefore advisable to keep project (vsp) files at least until one has checked that any VOB files made from them are not subject to the FR bug since once an edited file is saved with SmartRender on, the redundant frames produced will be preserved throughout the process unless they are removed by trimming the clip portions that contain them.
With Smart Render disabled, VideoStudio does not simply rebuild small clip portions at edit points. Rather, it re-encodes the whole timeline contents frame by frame. For this reason, “dumb” rendering an mpeg file takes much longer than smart rendering it —roughly as long as transcoding an avi file to mpeg format.
Which VideoStudio versions cause the FR bug?
In VideoStudio, the FR bug was possibly introduced by Update 6.02, dated 11/28/02. This patch revamped the Ulead MPEG.Now video encoding engine, which was made “up to 46% faster” —possibly by reducing the length of the portions that were re-encoded on the two sides of each edit point. Although I have never used VS 6, judging by some comments posted in other, non-Ulead forums, something changed “for the worse” as regards smart rendering in that version.
In my experience, both VideoStudio 7 and 8 produce the bug. On the other hand, VideoStudio 9 seems to smart render properly. In fact, I have so far obtained synchronous VOBs from edited mpeg files ranging from 1 minute to 2 hours in length and containing between 1 and 60 edits including trimming, mixed transition types, titles, overlays and playback speed changes.
The only, minor glitch I have found in smart rendered VS9 files is the presence of spurious macropixels such as those seen in redundant frames when the edit point coincides with the first frame in a GOP. In any case, the frames containing the macropixels are not redundant, so they introduce no AV asynchrony.
What about other Ulead programs?
Please note that the comments which follow are based on the results obtained with trial versions, so they may or may not apply to the full programs.
Like VideoStudio, Movie Factory 4 (MF4), its predecessor (MF3), and MediaStudio Pro 7 (MSP7) are subject to the frame redundancy bug. Also, MF3 and MSP7 deliver synchronous VOBs and DVDs from files containing redundant frames, both with their native burning engines and with any other effective version. On the other hand, the burning engine in MF4 only repairs AV asynchrony in files which have acquired the FR bug in another Ulead program. Why?
Although the ~convert###.mpg files smart rendered by both MF4 and MF3 from their own projects contain redundant frames, those produced by MF3 are “program” files (that is, files containing both audio and video), whereas those rendered by MF4 are elementary video-only files. MF4 uses its video-only ~convert###.mpg files in conjunction with their matching elementary audio-only files (whether .mpa, .wav or .ac3) to assemble VOB files with the aid of a third, .pts file which presumably contains the presentation time stamps of the video GOPs. The process, however, fails, and the result is OOS VOBs despite the fact that MF4 uses virtually the same burning engine as VideoStudio 9.
Unlike MF4, however, VideoStudio's latest version uses program (that is, self-contained) rather than elementary (video-only) ~convert###.mpg files when rendering a project directly from the timeline or adding one instead of a previously created mpeg file in the Create Disc step. In addition, the ~convert###.mpg files produced by VS9 contain no redundant frames.
Finally, DVD Workshop 2 produces synchronous DVDs from mpeg files subject to the FR bug, both with its own burning engine and with other effective versions.
The specific burning engine versions used by each program are listed in “Which burning engine versions work” in post 2.
AV asynchrony, smart render and the frame redundancy bug
Moderator: Ken Berry
-
alosada
AV asynchrony, smart render and the frame redundancy bug
Last edited by alosada on Thu May 12, 2005 4:42 pm, edited 1 time in total.
-
alosada
MORE ABOUT THE FR BUG
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 (R1 and R2) are inserted at position 5 in the following stream
V1V2V3V4V5V6V7V8V9···
A1A2A3A4A5A6A7A8A9···
the result is
V1V2V3V4V5R1R2V6V7···
A1A2A3A4A5A6A7A8A9···
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 “CD/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 —the 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 “deplete” 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 —no 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.
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 (R1 and R2) are inserted at position 5 in the following stream
V1V2V3V4V5V6V7V8V9···
A1A2A3A4A5A6A7A8A9···
the result is
V1V2V3V4V5R1R2V6V7···
A1A2A3A4A5A6A7A8A9···
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 “CD/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 —the 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 “deplete” 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 —no 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.
Last edited by alosada on Thu May 12, 2005 4:45 pm, edited 1 time in total.
-
alosada
THE FRAME REDUNDANCY TEST
This test will tell you whether your VideoStudio version produces redundant frames when smart rendering.
What do you need?
A clean source file
Because you will be checking whether VideoStudio smart renders properly, you will need a “clean” mpeg2 file in order to avoid introducing any artifacts into process.
A clean mpeg2 file can usually be obtained by encoding an avi file. VideoStudio 7, 8 and 9 come with some in their respective \Samples\Video folders. Unfortunately, those possibly best serving the purpose of this test (V17.avi in the VS8 samples folder and V12.avi in VS9) require version 5.11 or later of the Indeo codec, which is not installed by default. Those having VideoStudio on a CD can install the codec from it; those who don't, can download it here:
ftp://aiedownload.intel.com/df-support/ ... dinstl.exe
Please note that some users have reported running into problems with installer files not downloaded directly from the Intel site. In any case, the codec version needed to process the previous avi files might already be present in your system. You can check this by double clicking the Sounds and Audio Devices icon in the Windows Control panel and clicking the Hardware tab next. Double click the Video codecs entry and then click the Properties tab. If the list you see includes version 5.11 or later of the Indeo video codec, then you can use the previous samples as “pre-source” files.
If you don't have the Indeo video 5.11 codec on your machine and would rather not install it, you can use the V13.avi file that comes with both VS7 and VS8. This file was packed with the Cinepak Radius codec, so it should pose no problem.
An appropriate program to inspect the results
The easiest way to inspect the rendered file is by using a program affording smooth frame by frame browsing and accurate display of individual frames such as VideoReDo or VirtualDub MPEG2. If you don't have VideoReDo, you can download a 30-day trial version here:
http://www.drdsystems.com/VideoReDo
Also, you can download a free, fully functional version of VirtualDub MPEG2 at the following URL:
http://fcchandler.home.comcast.net/stab ... -MPEG2.zip
Neither program alters any crucial files in your system and both can coexist peacefully with any video editing software you may have installed.
Making a clean mpeg source file
Before starting, press the F6 key to display the Preferences dialog box in VideoStudio and make sure the small checkbox next to “Show message when inserting first video clip into the Timeline” in the General section is CHECKED and that next to “Use default transition effect” is UNCHECKED. Click the OK button.
The steps to be taken now depend on whether you will be using an avi file as pre-source or an mpeg file directly as source.
Preparing your source file from an AVI file
The procedure is as follows:
1. Press Ctrl+N to start a new project —also, click the Edit tab at the top if you are using VideoStudio 7— and insert your pre-source avi file into the timeline (for example, by right clicking the blank timeline, selecting “Insert Video”, browsing to your chosen file, clicking its name in the Open Video File dialog box and, finally, the Open button).
If you insert one of the files that come with VideoStudio, right click its thumbnail on the timeline and select Properties you will see it contains no audio. Don't worry, it will still be usable for the purpose of this test —also, if you wish, you can insert an equivalent length of audio from a sound clip of your choice into the Voice or Music track prior to rendering.
You can also use any other avi file of yours instead. Before encoding, however, reduce its length to a practical 5 or 6 seconds by trimming appropriate segments from the beginning and end.
2. Click the Share tab at the top of the window and then the Create Video File icon. Select Custom, click the Options button and then the Compression tab to select “NTSC DVD” as Media type —those wishing to use “PAL DVD” can do so and replace the figures below by those in brackets in each case.
3. While in the Create Video File dialog box, click the General tab and make sure your Frame type is either Lower Field First (Field Order A in VS7) or Upper Field First (Field Order B in VS7); choose either otherwise. Click OK to return to the main dialog box, type in an appropriate name for your file (I suggest Source.mpg) and click the Save button. Once the file has been rendered, jump to step 4 below.
Preparing an existing mpeg file for use as source
You can use an mpeg file you are confident is clean as a direct source instead of an avi file as pre-source. What is a “clean” mpeg file? Basically, an untouched captured file —one that has been subjected to no visual editing (trimming, filtering, titling). You can confirm whether your candidate file is actually clean by having it parsed in VideoReDo, for example. Once you are sure it is, do the following:
A. Press Ctrl+N to start a new project —and the Edit tab at the top if you are in VS7— and answer No if asked “Save changes to Untitled?”. For easier operation, you may click the filmstrip icon on the left of the video track in the timeline to switch back to Storyboard View (or Storyboard Mode in VS7) if needed.
B. Insert your source file into the timeline. Answer Yes if asked “Do you want to change the project settings to match the video's properties so VideoStudio can perform SmartRender?”.
C. Now, reduce the clip length to 5 or 6 seconds by trimming appropriate portions at the beginning and end, and render the remainder by clicking the Share tab first and the Create Video File icon then. Select “Same as Project Settings” and UNCHECK the box next to “Perform SmartRender” —after clicking the Options button if you are using VS8 or VS9. Type in a name for your file (preferably something like Source.mpg) and click Save. Once the file has been rendered, proceed to step 4 below.
Trimming and smart rendering your source file
Please take the following steps to obtain the file to be subsequently checked for bad frames:
4. Press Ctrl+N to start a new project —and the Edit tab at the top if you are in VS7— and answer No if asked “Save changes to Untitled?”. For easier operation, you may click the filmstrip icon on the left of the video track in the timeline to switch back to Storyboard View (or Storyboard Mode in VS7) if needed.
5. Now, insert your source mpeg file into the timeline. If you followed steps 1 to 3 above, simply click and drag the thumbnail for Source.mpg in the Video Library and drop it on the timeline; otherwise, right-click the blank timeline, select “Insert Video” and navigate to your source mpeg file to open it. Answer Yes if asked “Do you want to change the project settings to match the video's properties so VideoStudio can perform SmartRender?”.
6. We will now trim a portion off this video. Click its thumbnail on the timeline and then the seconds timecode (the second pair of zeros from the right) in the digital display under the Preview window. Type 02 and click the Scissors button above the timecode display in VS8 and VS9, but below it in VS7.
7. Now, click thumbnail no. 2 on the timeline and the seconds timecode, but type 03 (or 0309 if you chose PAL DVD as Media type) rather than 02 this time. A new clip (no. 3) will appear on the timeline after you click the Scissors button.
8. If the thumbnail for clip no. 2, which should be exactly 1:00 seconds long (1:09 with PAL), is still highlighted, press the Del key to remove it; otherwise, click it before.
9. Save the timeline contents by pressing Ctrl + S. Type in a name for your project (I suggest Source.vsp) and click Save.
10. Now, smart render the trimmed video by clicking the Share tab first and the Create Video File icon then. Select “Same as Project Settings” and make sure that the small box next to “Perform SmartRender” is CHECKED —click the Options button first in you are in VS8 or VS9. Type in a name for the new file (for example, Trimmed.mpg) and click Save. You will see the Preview window go black (or remain unchanged in VS7) and the rendering process take much shorter than with Source.mpg. This is because VideoStudio is smart rendering the edited portion of the video rather than re-encoding the whole of it.
11. If you now click the Play button under the Preview window you will probably see nothing strange in the new clip —not even if you browse it frame by frame. In fact, VideoStudio manages to make redundant frames “invisible” here. That's why we need an external program to check whether the smart rendered clip is actually OK.
Inspecting the output
We will be looking for spurious, redundant frames in the vicinity of the splicing point in our trimmed file (that is, timecode 0:00:02.00). The procedure depends on the particular program we use. Please note that the timecodes below apply if you used NTSC DVD as Media type when rendering your file and that the equivalent numbers for PAL DVD are given in brackets.
VideoReDo procedure
1. Launch VRD and open Trimmed.mpg —or whatever you called your trimmed file.
2. Select Tools and then Options from the menu. Click the Navigation tab and make sure the Left/Right Arrow keys, Unshifted selection is “Move next frame” and the first number under “Button movements (in seconds)” is 1. Click OK to close the dialog box.
3. Navigate to timecode 00:00:02.00 by clicking the green fast forward button next to the play button twice and then press the left arrow key three times. You should be at frame 00:00:01.27 (00:00:01.22 in a PAL file) now.
4. Press the right arrow key twice to reach frame 00:00:01.29 (00:00:01.24 in PAL). You will probably see nothing strange yet.
5. Now, press the right arrow key once more. If the timecode changes to 00:00:02.00 and the new frame looks normal, then your video doesn't have redundant frames. On the other hand, if the timecode goes back to 00:00:01.28 (00:00:01.23 for PAL) instead, you will probably see a scrambled picture containing a number of large “foreign” pixels. This is a redundant frame and if you press the right arrow key again you will be taken to a duplicate 00:00:01.29 frame (00:00:01.24 with PAL) also containing spurious “macropixels”.
6. Finally, pressing the arrow key once more will lead you to frame 00:00:02.00, which would have come immediately after the last “good” frame (the first instance of frame 00:00:01.29 in the NTSC file or 00:00:01.24 in the PAL file) if the clip had been properly rendered.
VirtualDub procedure
1. Start the program, maximize the window and press Ctrl + O to open your Trimmed.mpg file.
2. Press Ctrl + G, type 59 (49 if you used PAL DVD as Media type) and press Enter.
3. Press the right arrow key once. If you see nothing strange in the current frame, then your video doesn't have the frame redundancy bug. However, if you see a number of large “foreign” pixels scattered over the picture, then you will be in front of a redundant frame and pressing the right arrow key again will take you to a frame also containing odd “macropixels” —the second redundant frame in the pair.
4. Finally, pressing the arrow key once more will lead you to a new “good” frame with no spurious macropixels.
Does “dumb” render solve the problem?
If your Trimmed.mpg file contains redundant frames, please repeat the process. This time, however, re-encode rather than smart render the file by taking the following steps:
1. Open your Source.vsp project in VideoStudio.
2. Click the Share tab and the Create Video File icon to select “Same as Project Settings” and UNCHECK the box next to “Perform SmartRender” —after clicking the Options button if you are in VideoStudio 8 or 9. Type in a name for your file (for example, DR.mpg) and click Save. The Preview window will not go black —or remain unchanged in VS7— now, and the rendering process will take longer than with Trimmed.mpg. This is because VideoStudio is re-encoding the whole video rather than smart rendering it.
3. Once rendered, check whether DR.mpg contains redundant frames in VideoReDo or VirtualDub. It shouldn't.
Further testing
If you encounter the bug and have the time and will to test further, you can repeat the process by using other templates (Media types) and as many combinations of Field Order, video compression type (CBR or VBR) and bitrate, or even audio format, as you like in the Create Video File step. Please note that frame-based files, which include all mpeg1 files, cannot “contract” FR bug; only field-based (Lower Field First or Upper Field First) mpeg2 files can.
Also, you can repeat some runs by opening your Source.vsp project and trimming a variable number of frames off the beginning of clip no. 2 to make new “source” files and smart render them to see if they contain redundant frames. The pictures in any such frames will be the same as those in the original tests —unless the cut is made exactly at an I frame—, but will obviously appear at other timecodes.
Please note that some VideoStudio sample files such as V13.avi in VS7 and VS8 are computer animations rather than real-file videos and contain duplicate frames, so they may give redundant frames with no macropixels when trimmed at certain points. The only way to identify redundant frames in this situation is by checking for the timecode rollback described in step 5 of the VideoReDo inspection procedure above. This is why I recommend using a fluid motion clip such as the V17.avi sample that comes with VideoStudio 8.
This test will tell you whether your VideoStudio version produces redundant frames when smart rendering.
What do you need?
A clean source file
Because you will be checking whether VideoStudio smart renders properly, you will need a “clean” mpeg2 file in order to avoid introducing any artifacts into process.
A clean mpeg2 file can usually be obtained by encoding an avi file. VideoStudio 7, 8 and 9 come with some in their respective \Samples\Video folders. Unfortunately, those possibly best serving the purpose of this test (V17.avi in the VS8 samples folder and V12.avi in VS9) require version 5.11 or later of the Indeo codec, which is not installed by default. Those having VideoStudio on a CD can install the codec from it; those who don't, can download it here:
ftp://aiedownload.intel.com/df-support/ ... dinstl.exe
Please note that some users have reported running into problems with installer files not downloaded directly from the Intel site. In any case, the codec version needed to process the previous avi files might already be present in your system. You can check this by double clicking the Sounds and Audio Devices icon in the Windows Control panel and clicking the Hardware tab next. Double click the Video codecs entry and then click the Properties tab. If the list you see includes version 5.11 or later of the Indeo video codec, then you can use the previous samples as “pre-source” files.
If you don't have the Indeo video 5.11 codec on your machine and would rather not install it, you can use the V13.avi file that comes with both VS7 and VS8. This file was packed with the Cinepak Radius codec, so it should pose no problem.
An appropriate program to inspect the results
The easiest way to inspect the rendered file is by using a program affording smooth frame by frame browsing and accurate display of individual frames such as VideoReDo or VirtualDub MPEG2. If you don't have VideoReDo, you can download a 30-day trial version here:
http://www.drdsystems.com/VideoReDo
Also, you can download a free, fully functional version of VirtualDub MPEG2 at the following URL:
http://fcchandler.home.comcast.net/stab ... -MPEG2.zip
Neither program alters any crucial files in your system and both can coexist peacefully with any video editing software you may have installed.
Making a clean mpeg source file
Before starting, press the F6 key to display the Preferences dialog box in VideoStudio and make sure the small checkbox next to “Show message when inserting first video clip into the Timeline” in the General section is CHECKED and that next to “Use default transition effect” is UNCHECKED. Click the OK button.
The steps to be taken now depend on whether you will be using an avi file as pre-source or an mpeg file directly as source.
Preparing your source file from an AVI file
The procedure is as follows:
1. Press Ctrl+N to start a new project —also, click the Edit tab at the top if you are using VideoStudio 7— and insert your pre-source avi file into the timeline (for example, by right clicking the blank timeline, selecting “Insert Video”, browsing to your chosen file, clicking its name in the Open Video File dialog box and, finally, the Open button).
If you insert one of the files that come with VideoStudio, right click its thumbnail on the timeline and select Properties you will see it contains no audio. Don't worry, it will still be usable for the purpose of this test —also, if you wish, you can insert an equivalent length of audio from a sound clip of your choice into the Voice or Music track prior to rendering.
You can also use any other avi file of yours instead. Before encoding, however, reduce its length to a practical 5 or 6 seconds by trimming appropriate segments from the beginning and end.
2. Click the Share tab at the top of the window and then the Create Video File icon. Select Custom, click the Options button and then the Compression tab to select “NTSC DVD” as Media type —those wishing to use “PAL DVD” can do so and replace the figures below by those in brackets in each case.
3. While in the Create Video File dialog box, click the General tab and make sure your Frame type is either Lower Field First (Field Order A in VS7) or Upper Field First (Field Order B in VS7); choose either otherwise. Click OK to return to the main dialog box, type in an appropriate name for your file (I suggest Source.mpg) and click the Save button. Once the file has been rendered, jump to step 4 below.
Preparing an existing mpeg file for use as source
You can use an mpeg file you are confident is clean as a direct source instead of an avi file as pre-source. What is a “clean” mpeg file? Basically, an untouched captured file —one that has been subjected to no visual editing (trimming, filtering, titling). You can confirm whether your candidate file is actually clean by having it parsed in VideoReDo, for example. Once you are sure it is, do the following:
A. Press Ctrl+N to start a new project —and the Edit tab at the top if you are in VS7— and answer No if asked “Save changes to Untitled?”. For easier operation, you may click the filmstrip icon on the left of the video track in the timeline to switch back to Storyboard View (or Storyboard Mode in VS7) if needed.
B. Insert your source file into the timeline. Answer Yes if asked “Do you want to change the project settings to match the video's properties so VideoStudio can perform SmartRender?”.
C. Now, reduce the clip length to 5 or 6 seconds by trimming appropriate portions at the beginning and end, and render the remainder by clicking the Share tab first and the Create Video File icon then. Select “Same as Project Settings” and UNCHECK the box next to “Perform SmartRender” —after clicking the Options button if you are using VS8 or VS9. Type in a name for your file (preferably something like Source.mpg) and click Save. Once the file has been rendered, proceed to step 4 below.
Trimming and smart rendering your source file
Please take the following steps to obtain the file to be subsequently checked for bad frames:
4. Press Ctrl+N to start a new project —and the Edit tab at the top if you are in VS7— and answer No if asked “Save changes to Untitled?”. For easier operation, you may click the filmstrip icon on the left of the video track in the timeline to switch back to Storyboard View (or Storyboard Mode in VS7) if needed.
5. Now, insert your source mpeg file into the timeline. If you followed steps 1 to 3 above, simply click and drag the thumbnail for Source.mpg in the Video Library and drop it on the timeline; otherwise, right-click the blank timeline, select “Insert Video” and navigate to your source mpeg file to open it. Answer Yes if asked “Do you want to change the project settings to match the video's properties so VideoStudio can perform SmartRender?”.
6. We will now trim a portion off this video. Click its thumbnail on the timeline and then the seconds timecode (the second pair of zeros from the right) in the digital display under the Preview window. Type 02 and click the Scissors button above the timecode display in VS8 and VS9, but below it in VS7.
7. Now, click thumbnail no. 2 on the timeline and the seconds timecode, but type 03 (or 0309 if you chose PAL DVD as Media type) rather than 02 this time. A new clip (no. 3) will appear on the timeline after you click the Scissors button.
8. If the thumbnail for clip no. 2, which should be exactly 1:00 seconds long (1:09 with PAL), is still highlighted, press the Del key to remove it; otherwise, click it before.
9. Save the timeline contents by pressing Ctrl + S. Type in a name for your project (I suggest Source.vsp) and click Save.
10. Now, smart render the trimmed video by clicking the Share tab first and the Create Video File icon then. Select “Same as Project Settings” and make sure that the small box next to “Perform SmartRender” is CHECKED —click the Options button first in you are in VS8 or VS9. Type in a name for the new file (for example, Trimmed.mpg) and click Save. You will see the Preview window go black (or remain unchanged in VS7) and the rendering process take much shorter than with Source.mpg. This is because VideoStudio is smart rendering the edited portion of the video rather than re-encoding the whole of it.
11. If you now click the Play button under the Preview window you will probably see nothing strange in the new clip —not even if you browse it frame by frame. In fact, VideoStudio manages to make redundant frames “invisible” here. That's why we need an external program to check whether the smart rendered clip is actually OK.
Inspecting the output
We will be looking for spurious, redundant frames in the vicinity of the splicing point in our trimmed file (that is, timecode 0:00:02.00). The procedure depends on the particular program we use. Please note that the timecodes below apply if you used NTSC DVD as Media type when rendering your file and that the equivalent numbers for PAL DVD are given in brackets.
VideoReDo procedure
1. Launch VRD and open Trimmed.mpg —or whatever you called your trimmed file.
2. Select Tools and then Options from the menu. Click the Navigation tab and make sure the Left/Right Arrow keys, Unshifted selection is “Move next frame” and the first number under “Button movements (in seconds)” is 1. Click OK to close the dialog box.
3. Navigate to timecode 00:00:02.00 by clicking the green fast forward button next to the play button twice and then press the left arrow key three times. You should be at frame 00:00:01.27 (00:00:01.22 in a PAL file) now.
4. Press the right arrow key twice to reach frame 00:00:01.29 (00:00:01.24 in PAL). You will probably see nothing strange yet.
5. Now, press the right arrow key once more. If the timecode changes to 00:00:02.00 and the new frame looks normal, then your video doesn't have redundant frames. On the other hand, if the timecode goes back to 00:00:01.28 (00:00:01.23 for PAL) instead, you will probably see a scrambled picture containing a number of large “foreign” pixels. This is a redundant frame and if you press the right arrow key again you will be taken to a duplicate 00:00:01.29 frame (00:00:01.24 with PAL) also containing spurious “macropixels”.
6. Finally, pressing the arrow key once more will lead you to frame 00:00:02.00, which would have come immediately after the last “good” frame (the first instance of frame 00:00:01.29 in the NTSC file or 00:00:01.24 in the PAL file) if the clip had been properly rendered.
VirtualDub procedure
1. Start the program, maximize the window and press Ctrl + O to open your Trimmed.mpg file.
2. Press Ctrl + G, type 59 (49 if you used PAL DVD as Media type) and press Enter.
3. Press the right arrow key once. If you see nothing strange in the current frame, then your video doesn't have the frame redundancy bug. However, if you see a number of large “foreign” pixels scattered over the picture, then you will be in front of a redundant frame and pressing the right arrow key again will take you to a frame also containing odd “macropixels” —the second redundant frame in the pair.
4. Finally, pressing the arrow key once more will lead you to a new “good” frame with no spurious macropixels.
Does “dumb” render solve the problem?
If your Trimmed.mpg file contains redundant frames, please repeat the process. This time, however, re-encode rather than smart render the file by taking the following steps:
1. Open your Source.vsp project in VideoStudio.
2. Click the Share tab and the Create Video File icon to select “Same as Project Settings” and UNCHECK the box next to “Perform SmartRender” —after clicking the Options button if you are in VideoStudio 8 or 9. Type in a name for your file (for example, DR.mpg) and click Save. The Preview window will not go black —or remain unchanged in VS7— now, and the rendering process will take longer than with Trimmed.mpg. This is because VideoStudio is re-encoding the whole video rather than smart rendering it.
3. Once rendered, check whether DR.mpg contains redundant frames in VideoReDo or VirtualDub. It shouldn't.
Further testing
If you encounter the bug and have the time and will to test further, you can repeat the process by using other templates (Media types) and as many combinations of Field Order, video compression type (CBR or VBR) and bitrate, or even audio format, as you like in the Create Video File step. Please note that frame-based files, which include all mpeg1 files, cannot “contract” FR bug; only field-based (Lower Field First or Upper Field First) mpeg2 files can.
Also, you can repeat some runs by opening your Source.vsp project and trimming a variable number of frames off the beginning of clip no. 2 to make new “source” files and smart render them to see if they contain redundant frames. The pictures in any such frames will be the same as those in the original tests —unless the cut is made exactly at an I frame—, but will obviously appear at other timecodes.
Please note that some VideoStudio sample files such as V13.avi in VS7 and VS8 are computer animations rather than real-file videos and contain duplicate frames, so they may give redundant frames with no macropixels when trimmed at certain points. The only way to identify redundant frames in this situation is by checking for the timecode rollback described in step 5 of the VideoReDo inspection procedure above. This is why I recommend using a fluid motion clip such as the V17.avi sample that comes with VideoStudio 8.
-
Trevor Andrew
-
jchunter
-
maddrummer3301
- Posts: 2507
- Joined: Fri Dec 10, 2004 10:24 pm
- Location: US
-
jchunter
-
Trevor Andrew
-
jchunter
-
alosada
Thank you John, Trevor, BL and MD for your kind comments.
I have rarely used STV as I find the multitrimming process rather cumbersome. Like Trevor, I prefer to use the Storyboard mode and the scissors to have complete control of the portions I trim off a clip.
Anyway, this morning I used a clean PAL mpeg2 file 30+ minutes long and multitrimmed it to obtain 34 clips of 30 seconds each that I rendered into a single mpeg file with SmartRender both enabled and disabled in VS8.
The result was consistent with my previous findings: the dumb rendered file was the same length as the combined clips, contained no redundant frames and was synchronous throughout; on the other hand, the smart rendered file contained 33 pairs of redundant video frames (one per splicing point) and was OOS (by more than 2 seconds near the end).
I have rarely used STV as I find the multitrimming process rather cumbersome. Like Trevor, I prefer to use the Storyboard mode and the scissors to have complete control of the portions I trim off a clip.
Anyway, this morning I used a clean PAL mpeg2 file 30+ minutes long and multitrimmed it to obtain 34 clips of 30 seconds each that I rendered into a single mpeg file with SmartRender both enabled and disabled in VS8.
The result was consistent with my previous findings: the dumb rendered file was the same length as the combined clips, contained no redundant frames and was synchronous throughout; on the other hand, the smart rendered file contained 33 pairs of redundant video frames (one per splicing point) and was OOS (by more than 2 seconds near the end).
-
alosada
Not exactly, rs. If you upgrade to VS9 you will not experience the FR bug in it, but remember AV asynchrony ─particularly that of the gradual type─ can have many different origins.
And, no, you needn't uninstall any earlier versions of VideoStudio. VS9 will overwrite the files in the Ulead Systems\DVD shared folder with the latest proper version of the burning engine, so you will be able to correct OOS in your previously smart rendered mpeg files by making your VOBs in VS7 or VS8 if you so wish.
This doesn't mean you will also be able to avoid the redundant frames in VS7 or VS8 as each VideoStudio version uses its own smart rendering engine and those in the previous two versions are both buggy.
Hope it helps.
Antonio
And, no, you needn't uninstall any earlier versions of VideoStudio. VS9 will overwrite the files in the Ulead Systems\DVD shared folder with the latest proper version of the burning engine, so you will be able to correct OOS in your previously smart rendered mpeg files by making your VOBs in VS7 or VS8 if you so wish.
This doesn't mean you will also be able to avoid the redundant frames in VS7 or VS8 as each VideoStudio version uses its own smart rendering engine and those in the previous two versions are both buggy.
Hope it helps.
Antonio
-
jchunter
Alosada,
As a practical matter, my travel videos contain copious quantities of bad material. For example, I have superb shots of the floors of my rental cars, the inside of my camera bag, as well as audio recordings of me cursing out some of the drivers on the Autobahn... All in all, I leave more than half of the video on the cutting room floor. The virtual cut technique would leave all this to clog up my computer and be rearchived (the original tape already IS this archive).
Save Trimmed Video (STV) is the most convienent method to cut video into economical pieces and I assume that it uses Smart Render. Could you please check to see if STV produces the redundant frames?
If so, it would be a nice feature to add to the VS9 update to use the Shift key with STV to disable Smart Render.
John
As a practical matter, my travel videos contain copious quantities of bad material. For example, I have superb shots of the floors of my rental cars, the inside of my camera bag, as well as audio recordings of me cursing out some of the drivers on the Autobahn... All in all, I leave more than half of the video on the cutting room floor. The virtual cut technique would leave all this to clog up my computer and be rearchived (the original tape already IS this archive).
Save Trimmed Video (STV) is the most convienent method to cut video into economical pieces and I assume that it uses Smart Render. Could you please check to see if STV produces the redundant frames?
If so, it would be a nice feature to add to the VS9 update to use the Shift key with STV to disable Smart Render.
John
-
alosada
John:
As I said in my reply to you, MD et al. four posts back, smart rendering the clips inserted into the timeline after a multitrimming operation in VS8 produced redundant frames, whereas dumb rendering such clips did not.
I have replicated the test in VS9 and, as expected, the smart rendered file contains no redundant frames and is synchronous from beginning to end.
Both VS8 and VS9 smart render the multi-clips unless you tell them not to by unchecking the box next to "Perform SmartRender" after clicking the Options button in the Create Video File dialog box.
Disabling smart render resulted in the preview window in VS8 and VS9 not going black while the timeline was being encoded and in the process being about 8 times slower that with SR on.
The only difference I have seen regarding multitrimming in VS8 and VS9 is that the latter does not let you use the Ctrl or Shift key to select several clips for deletion before the remainder are inserted into the timeline.
As I said in my reply to you, MD et al. four posts back, smart rendering the clips inserted into the timeline after a multitrimming operation in VS8 produced redundant frames, whereas dumb rendering such clips did not.
I have replicated the test in VS9 and, as expected, the smart rendered file contains no redundant frames and is synchronous from beginning to end.
Both VS8 and VS9 smart render the multi-clips unless you tell them not to by unchecking the box next to "Perform SmartRender" after clicking the Options button in the Create Video File dialog box.
Disabling smart render resulted in the preview window in VS8 and VS9 not going black while the timeline was being encoded and in the process being about 8 times slower that with SR on.
The only difference I have seen regarding multitrimming in VS8 and VS9 is that the latter does not let you use the Ctrl or Shift key to select several clips for deletion before the remainder are inserted into the timeline.