[RESOLVED] Corrupt MPEG2 messes up field order

[nomolu]

Here's an interesting problem I just encountered with DGDecNV (and DGMPGDec): I captured a HD (1920x1080i) movie off the air and used VideoReDo Plus to remove the commercials. When saving the resulting video & audio streams, VideoReDo said there were 2 Input Sequence Errors.

After converting the HD MPEG2 video stream with DGDecNV (and HC) to a 720x480i MPEG2 file I noticed that there seemed to be field order problems starting about 40% into the movie. It turns out that's where the 2 Input Sequence Errors are. So I tried DGMPGDec 1.5.8 and it converted the HD movie just fine, except for a few corrupt frames at part with the sequence errors. One other odd thing: The DGMPGDec version is one frame shorter than the DGDecNV version.

I've tried versions 2037 and 2038 of DGDecNV and both have the same problem with this corrupt MPEG2 stream. I don't know if anything can be done to improve DGDecNV's handling of such problems, but here's a small sample of the corrupt file which exhibits the problem: http://www.mediafire.com/?vcqv7qlew9i5vtn . The problem starts about 15 frames into the sample.

Thanks!
- nomolu

[admin]

A 2MB sample is way too small. Give me 100MB. Also, give me the *original* TS file (before VideoRedo processing), not the demuxed video. You can cut it with DGSplit. Thank you.

[nomolu]

Here's a link to the 100 MB transport stream file which contains the corrupt section: http://www.mediafire.com/?af8fnofbd1lynda.

Naturally, it doesn't show the problem when I index it with DGDecNV. If you like, I can upload the VideoReDo demuxed version of the TS file which does exhibit the "field order" problem.

I forgot to mention in my first post that VideoReDo said that there was one "video resync frame removed" from the demuxed stream. It did this in order to keep the audio and video in sync.

Thanks for looking into this!

[admin]

A stream that doesn't show the problem is not useful.

So you are saying that VideoReDo ruins the stream and you want me to somehow work around that? Have you asked VideoReDo for support?

[nomolu]

I haven't asked VideoReDo for support, yet. Sure, this time VideoReDo produced a less than perfect MPEG2 stream. Next time it might be Project X, or Smart Cutter Ps/Ts, or Cuttermaran. I thought you might be interested in this because of the differences in how DGMPGDec and DGDecNV handled a corrupt stream and that you might want to improve DGDecNV's handling of such files. If you like, here's a 100 MB demuxed sample which shows the problem: http://www.mediafire.com/?q8891vvv8r0k4kp. I understand your time is limited and you have to pick and choose very carefully what you'll work on.

Anyhow, thanks for all of your great software!

[admin]

Investigating...

[admin]

I have slipstreamed what I hope is a fix into 2038, so re-download it, and update DGIndexNV.exe.

I still get a glitch at the error point but it no longer inverts the field order. Please advise your test results and thank you for pointing this out, nomolu.

[nomolu]

The update definitely fixes the problem! And now the frame counts match between DGMPGDec and DGDecNV.

It's interesting that you only needed to update the indexing program and not the decoder.

Thanks for investigating (and fixing) this problem, admin!

[admin]

It's interesting that you only needed to update the indexing program and not the decoder.

The decoder knows only about the frames indexed in the DGI file; it doesn't have to re-parse.

Thanks for investigating (and fixing) this problem, admin!

My pleasure.