View Single Post
Old 1st April 2010, 20:20   #98  |  Link
Robert Martens
Registered User
 
Join Date: Feb 2010
Location: New York
Posts: 116
Turns out more had changed than I remembered, in that I had been using the CoreAVC decoder and loading the fake AVI files into a trial copy of Vegas Pro. I've downloaded Vegas too many times now (I've needed it more than once to help someone diagnose a problem; it now tells me the trial period has expired, so I can't register the download), and pathetic as it may seem I can't throw any money at CoreAVC for the moment.

I have nonetheless confirmed the behavior in question by other means. I have ffdshow-tryouts version 3154 installed, and I have the H.264/AVC "decoder" dropdown set to ffmpeg-mt for both DShow and VfW, since I find that performs best on my system.

I created a simple script, AVFSsynctest.avs, containing these lines:

AVFS_AVI_NoInterleave=false
DirectShowSource("C:\Downloads\mvi_1419.mov")
ConvertToRGB24(matrix="PC.709")

The source clip doesn't appear to be in the same place as when I grabbed it, but that Vimeo user referenced in the DVi thread has made the clip available here: http://drop.io/larktav

I swapped NoInterleave between true and false, and commented out the ConvertToRGB line for a couple of tests. The script was mounted with the latest PFM/AVFS, the files were opened in Liquid 7.2, combustion 3.0.4, and MediaInfo, and the script was explicitly Unmounted between each change. Results were as follows:

1.) NoInterleave=false->DirectShowSource->ConvertToRGB24->Liquid 7.2

On a 1080/30p timeline (exactly 30p, not 29.97), everything displays as if it's fine; the audio in the AVI file shows up as being the same duration as the video, as do the two WAV files generated (AVFSsynctest.wav and AVFSsynctest.00.wav). I'm inclined to believe this is a quirk of the NLE, however, thanks to tests 3 through 8.

2.) NoInterleave=true->DirectShowSource->ConvertToRGB24->Liquid 7.2

Same as 1; everything looks fine, durations all appear to match.

3.) NoInterleave=false->DirectShowSource->combustion 3.0.4

Here's where the first sign of trouble begins. The video track is reported as 491 frames, but audio is reported as 490 whether I load it from the AVI container or either of the WAVs.

4.) NoInterleave=true->DirectShowSource->combustion 3.0.4

Even stranger; the durations behave as in test 3, but trying to load the AVI as an audio source causes only the last ten frames or so to display a waveform in the combustion interface; further, the audio track is silent even during those ten frames. The WAVs as audio sources had the 490 duration, but played back without issue.

5.) NoInterleave=false->DirectShowSource->ConvertToRGB24->combustion 3.0.4

For tests 3 and 4 I had initially removed the ConvertToRGB line, as combustion doesn't require it, but thinking it might have some impact on my results I restored the line and tried again. Results were identical to test 3.

6.) NoInterleave=true->DirectShowSource->ConvertToRGB24->combustion 3.0.4

Same as number 4.

7.) NoInterleave=false->DirectShowSource->ConvertToRGB24->MediaInfo

Finally, I loaded the phantom files in MediaInfo 0.7.19 to see what it could tell me, and found that in this case the AVI video track showed a duration of 16s 366ms, and the audio a duration of 16s 333ms. The external files, AVFSsynctest.wav and AVFSsynctest.00.wav, were also both 16s 333ms.

8.) NoInterleave=true->DirectShowSource->ConvertToRGB24->MediaInfo

Changing only the NoInterleave option, this time I found the AVI video track was its expected 16s 366ms, but the audio packed into the AVI had shrunk to 15s 867ms. AVFSsynctest.wav and AVFSsynctest.00.wav, though, were both 16s 333ms, as I'd seen in the other examinations.

All of this is in line with what we experienced in that thread; I was unclear at first, but as soon as I saw those numbers in MediaInfo I remembered running into the same audio-shrink last time.

Last edited by Robert Martens; 1st April 2010 at 20:25.
Robert Martens is offline   Reply With Quote