Frame Accurate Editing Report #3 - A User Solution
I was not entirely happy with the test script and output in Report #2 for 4 reasons:
1. The single frames selected for the master test file generated underflows when the file was created, which although VRD says it should have no effect, did not make me entirely happy.
2. Some of the clips made during the test, when played back on my player showed an incorrect total time, which I think was because they were too short.
3. That these two things might have corrupted the test results.
4. That I still didn't have a tested workaround to the problems.
So I decided to make a new master video, where I took 4 frames for each indentifiable frame rather than 1, and I put 5 seconds of video on the front of the master so that the clips I cut at the identifiable points would be at least 5 seconds long.. a more realistic simulation of a real editing session.
I also wanted to try adding some black frames between each joined clip in hopes that they might fix the lost frames bug or at least make them more consistent, and so that they could be found with ad-detective in the final video to aid in removing any extra frames that I added to each clip to allow me to get frame accurate after the fact.
Taking this approach, the created master video had no buffer underflows, all the clips displayed the correct total time in the player and the results duplicated and validated the lost frame findings in report #2.
Even better news was that by using joiner to add a 4 black frame clip, that I created separately, to the end of each output clip and outputting the clip using joiner rather than "save video as", the frame accuracy of the clip itself was preserved, so that when I joined the individual clips, I only lost black frames at the end of each clip, which I could then detect with ad-detective (set the minimum space between to the shortest clip) and jump to and cut out of the final video. It also left a frame accurate cut at the end of the video followed by black frames which I left as a trailer in the final cut, since some players do not play the last few frames. I chose not to use a 1 black frame clip because I'm not sure it would work, due to buffer underflows and because I wanted a last chance to review the individual cuts in the final video which the 3 remaining black frames let me detect.
So bottom line, I now have a process, whereby despite the problems, and more work on my part, that I can build a set of frame accurate clips, assemble them in a storyboard of non-linear clips, (add titles where I want using the new VRD facility), and produce a video with all my frames, that can then have the black frames detected and removed. And in case you wondered, the 3 black frames do leave a blip on playback if not removed, which only demonstrates again the need for the frame accurate editing that VRD does not provide on clip joins.
Indoing this I also discovered a number of bugs in the joiner process, which is of course the only way that VRD can do non-linear editing, and so it needs to work dependably and correctly, and I have reported these problems separately.
My final advice if you are non-linear editing is to mannually record the Video and Audio Output Frame count for each clip you produce (they are also in the log), and then verify any joiner output by ensuring the joiner output counts equal the sum of the input clip counts less the expected 2 or 3 frame loss.
Reply With Quote
Originally Posted by jhb
