What you are seeing is an error that was introduced during capture. While you were capturing your video, there was either a virus checker or some other background process that took your capture utility's attention away for just long enough for this mistake to be made writing the video or video format data.

The real fix would be for the video capture process to be made a little more bullet-proof: maybe a little extra buffering or a little higher priority assigned to it.

The fix for stuff already recorded is to do a non-smart render, at least on the offending portion of the bad clip.

My new captures are all fine (because I now capture with my virus protection disabled and the video preview window off). Where I am running into this is when I try to use footage captured before I realized this.

hi laurence,

i appreciate your help immensely, but i have to disagree with you in as much as the problem was during capture - i have used and edited the offending section numerous times. this error only started appearing after my not having it on the timeline for a month or so, and perhaps defragging the drive in the meantime - where i might have induced a problem?

either way, i wholeheartedly agree that a more robust codec is probably needed in all aspects of hdv, capture, editing, and especially editing with 'no-recompress'.

have you, or anyone else submitted a ticket?

leslie

For me, the problems started being noticable with Vegas 7e. That's when the preview efficiency was improved at the price of less stability.

For a while I thought that somehow problems were sneaking into my clips because clips that had been fine started crashing Vegas. In reality though, it was just that Vegas had changed, not the clips. The clips that crashed would only crash in the more recent (7e and on) versions of Vegas and since so few of them had problems I hadn't noticed that this was what was happening.

As I read posts on this forum and on DVInfo,net, I realize that many seemingly unrelated problems are actually just this same problem. Here are a couple of the problems that people are reporting that are really just this one problem:

1/ Vegas randomly crashes.
2/ Vegas 8a and b not stable
3/ I can't write my m2t video back to tape.
4/ my m2t video stops playing in the middle when I play it back on a PS3
5/ My Blu-ray discs don't play on all Blu-ray players.
6/ Errors are somehow creeping into my video files that were fine before.
7/ My m2t video crashes Windows Media Player.

OLD THREAD ALERT

Just been doing some work with this so I thought I'd add my findings even though the thread is old.

I'm capturing HDV with HDVSplit. On a small percentage of these clips, Vegas 8.0c hangs on the last frame of the clip when played on the timeline. This is pretty much the only error I get. I can make the clip play successfully by running it through MPEG2Repair. After this fix it is played in Vegas 8.0c by the MainConcept MPEG2 codec, not the new Sony HDV codec. Preview is not quite as responsive, but it's OK.

I did what Laurence suggested and smart rendered the repaired clip from Vegas and the error does indeed return, same as you guys found. However when I smart render the repaired clip in a sequence of other clips on the timeline (i.e. to a longer clip), the resulting file is OK, even if the fixed file is at the end of the sequence.

So in my case it is is OK to smart render a MPEG2Repaired clip if it's part of a longer sequence. Just don't smart render it to a clip the same length as it already is.

Replying to old threads with new information is totally OK.
I have used MPEG2Repair in the past, but for both scenarios you described, I use VideoRedo, a paid solution.

Quickstream Fix in VRD for scenario #1, and then Join for scenario #2. Advantage is it repairs and reindexes the GOP structure without touching the actual encoding.

OK but what I was saying is that in my case a file that has been fixed with MPEG2Repair can be smart rendered in a longer sequence on the Vegas timeline and the errors will "go away". Of course, the beginning and end few frames will get re-encoded if the ends don't fall on an I-frame, so if you're just joining clips then it sounds like VideoRedo will have the advantage of not doing that.

However, Quickstream Fix in VideoRedo (trial version) crashed on 9 out of 10 of my corrupt files with a "stream error" message (I thought that's what it's supposed to fix!). So it doesn't look like it's an option for me.

Weird indeed. Can you upload one of your "crashy" files somewhere? I'd like to test it since VRD has fixed some pretty messed up files here.

I'm getting more success today but still some "crashes". It's not really a crash but rather it aborts with the message "Mpeg stream error: Transport Muxer Buffer Underflow". In the log it says "too many underflows". It still creates a usable mpeg2 transport stream file but it's much shorter than the original. MPEG2Repair does output a good file the same length as the original.

Could you send me an email via the forum and I'll email you a link to an example file if you're still insterested.

One significant difference is that "transport stream" output from MPEG2Repair is decoded by mcplug.dll (in Vegas Pro 8.0c) whereas output from VideoReDo is decoded by m2tsplug.dll. Files decoded by m2tsplug.dll are snappier in the preview for me.

Sent you an email.
I'm going to dust off Mpeg2Repair and try some tests with it too.

Nick,
I downloaded the file and my initial results were mixed.

Vegas 9.0c on Windows 7 (64 bit) has been looping the file for 15 minutes with no problem. I was also able to "smart render" the file out to a second copy. I then added the second copy to the timeline of the original project and "smart rendered" to a third copy. Rendered out to Blu-ray 1440x1080x60i-25mbps template with no problem. From this small sample, Vegas Pro 9.0c seems to be improved and represents a reasonable upgrade for you.

Vegas 8.0c on Windows XP SP2 failed at the end of the file as you described. Ran VideoReDo Quickstream fix and saved as a transport stream with no changes and it failed as you described. Ran VideoReDo Quickstream fix and saved as a program stream successfully. Created a new Vegas 8.0c project with the program stream file and it has been looping for a few minutes with no problems. I "smart rendered" this project to a file using MainConcept HDV 1080-60i codec and all was well. For this small test, it appears that VideoReDo repairs the file (if you save as a program stream .mpg file) and you don't lose any of the smart rendering capability.

John, Thanks for looking at this.

Very interesting that Vegas 9.0c seems to cope with the file without hanging. Still too many concerns for me to upgrade now but when version d comes along I might even try it, depending on forum feedback.

VideoReDo Quickstream Fix to a program stream is working for me too but it cuts 2 frames from the beginning of the file and 3 frames from the end of the file. For me that's a significant number because my stock clips are generally cut pretty short with little head or tail, so I'd rather use MPEG2Repair and retain as many frames as possible.