44 minute video only shows 9 minutes

[gadgetguy]

After reading about the DeLogo filter for VirtualDub I decided to give it a try. The video I captured came from my VCR tuner, passthrough my Sony D8 camcorder via firewire into my PC. But, it was capped as Type1. I then put it in Ulead VS7 and edited out all the commercials and saved it as a Type2. I then opened it in VirtualDubMod and applied the Delogo filter and did "Save As" using Full Processing mode and Panasonic DV CODEC. The resulting avi looks and played fine in VirtualDub and PowerDVD, but when I opened it in Ulead VS7 it showed only the first 9 minutes.

When I check the video in VirtualDub it shows that there are 79632 frames (44:17.05). When I check it with YAAI it shows only 16851 frames (9m 22s). I compared the pre-filtered Type2 and it shows the same number of frames in both (79632). So the problem seems to be with the re-encoding. I'm really happy with the resulting video but I need to use Ulead because it's the only MPG2 encoder I have. Correct me if I'm wrong, but I'm assuming that the problem is in the header info. Is there a way to "correct" the header info without having to re-encode? Or is it something else that I'm doing wrong?

[mpack]

I could be wrong, but it sounds to me like there'is nothing wrong with the AVI created by VirtualDubMod, my guess is that Ulead VS7 does not support OpenDML format AVI files? (ie. AVI files written in the AVI format variant which is able to grow beyond 4gigs).

The way the OpenDML format works is this (and this is a gross simplification): it's basically a bunch of standard (4 gigs or less) AVI files back to back in one physical file. An older media player only sees the first AVI in the file, while more modern OpenDML savvy apps (including VDub and PowerDVD) correctly sees them all.

Since you mention MPEG encoders, I know that TMPGEnc Plus and CCE recognise OpenDML AVI files.

Windows Media Player (XP) treats OpenDML AVIs strangely: plays some, fails to recognise others even though they are (as far as I can tell) completely compliant with the standard - and accepted by all the other apps I mentioned.

[gadgetguy]

Thanks, but I'm a little confused by your answer because all of the files involved are over 9 gigs and the ones before filtering report properly. I'm not saying you're wrong, I just don't understand. BTW I'm on a Win2k machine using NTSF file system.

[mpack]

Thanks, but I'm a little confused by your answer because all of the files involved are over 9 gigs and the ones before filtering report properly. I'm not saying you're wrong, I just don't understand. BTW I'm on a Win2k machine using NTSF file system.

The 4gig limit existed both in the Win9x family and in the AVI format itself. NTFS came along and removed the OS limit, but the AVI format itself was still limited by its specification to 4gigs. OpenDML is an extention to the AVI format which allows it to break the 4gig limit on NTFS systems (and other OS which allow files that large).

When I read your original message you mentioned 'type 1' and 'type 2', which I understood to refer to DV capture, ie. lightly compressed MPEG2. Is that not correct. The first time you required VS7 to read a large AVI file was after processing by VDub?

If your original files were AVIs > 4gig which VS7 could read then something else must be going on - perhaps VS7 is having exactly the same issues with some OpenDMLs as Media Player does (perhaps because it uses the same DirectX driver to read them).

[gadgetguy]

I used VS7 to convert the originally captured file from Type1 to Type2 and it had no troubles with the large filesizes. It is only after processing with the filters in VirtualDubMod that I have the problem.

[gadgetguy]

More Info
I tried re-encoding the file into <4gig segments and each segment displayed the same problem. With the exact same number of frames (16851), which is slightly less than 2 gigs. I then noticed VirtualDubMod has the option to save the file in segments and if you choose this option the maximum filesize allowed is 2 gigs. Does this mean that the OpenDML has 2 gig segments instead of 4 gig?
As a workaround I am going to use that option to break the file into usable segments and recombine them in VS7 to convert to DVD, but I still don't understand what is causing this problem.

[mpack]

I used VS7 to convert the originally captured file from Type1 to Type2 and it had no troubles with the large filesizes.

I don't use DV: does "Type 2" refer to an AVI file or not? If not, then the large file size of the Type2 file is not important to the question of whether VS7 understands OpenDML AVI files. It isn't the size that matters, its the file format.

[mpack]

More Info
I tried re-encoding the file into <4gig segments and each segment displayed the same problem.

I'm afraid that doesn't prove what you think it does. OpenDML removes the 4gig limit - but that doesn't mean that every OpenDML AVI has to be greater than 4gigs, and it also doesn't mean that an AVI which is less than 4gigs can't be of the OpenDML type. So, your test AVI could still have been OpenDML even though you kept them below 4gigs, and VS7 could still have had problems interpreting it. The only thing you can be sure of is that, if it is greater than 4gigs, and its an AVI, then it must be an OpenDML AVI.

I would expect that if you use the "Write segmented AVI..." option in VDub then each of the segments would be standard AVI (not OpenDML), otherwise it makes the feature less useful than it might otherwise be. That's a guess however - I'm not checked the VDub sources so I can't offer any guarantee...

[mpack]

Sorry, missed this question :-

Does this mean that the OpenDML has 2 gig segments instead of 4 gig?

Yes, it could mean that...

I said earlier (and although its a simplification its a workable one) that an OpenDML AVI is basically a bunch of standard AVIs stored back to back in one file. Each segment in the OpenDML file has the same size flexibility as a standalone standard AVI, ie. each can be any size from a few bytes up to 4gigs max - the choice of what size to make the segments is entirely down to the app that created the file.

[gadgetguy]

I appreciate your help and patience although I'm not sure the "light bulb" has lit over my head yet. (Maybe very dimly).
Yes, it is DV and Type2 does refer to a .avi file. Using the segmenting option in VirtualDubMod did give me usable files that I could load into VS7 and assemble for my final MPG2 for DVD. If indeed OpenDML is the issue, then there must be some difference in how VirtualDubMod and VS7 implement it when encoding .avi DV files.

[mpack]

If indeed OpenDML is the issue, then there must be some difference in how VirtualDubMod and VS7 implement it when encoding .avi DV files.

Very likely - especially considering what I already know, which is that Windows Media Player see all the frames in some OpenDML AVIs and not others - and I'll bet the difference between VDub (and my own homebrew apps) and VS7 (and Media Player) is that the latter two use a DirectX driver to read the AVI, and VDub doesn't.

Glad you've managed to make progress anyway.

[mpack]

I'd just like to add an addendum to this thread: it turned out that the reason that Media Player ignored everything except the first segment in OpenDML AVIs was due to a bug in my own software which generated the AVI, it was not due to a bug or OpenDML incompatibility in Media Player. I must therefore humbly apologise for maligning Microsoft...

The bug was that I was setting the video stream length (dwLength field in video stream header) to the number of frames in the first riff segment only, instead of the whole file. I did that because I thought the first segment had to be a self-contained, AVI 1.0 compatible: but I discovered today that other programs don't do it that way, and Media Player (and any other directx client app) doesn't like it that way, even though TMPGEnc, CCE, VDub etc were all happy.