Field order problem in damaged TP streams

[wbo]

I have been using DGIndex and DGDecode to feed DTV/HDTV transport streams into AVISynth for further processing/filtering. Yesterday I ran across a rather odd problem when I tried processing the transport stream I recorded.

The video in the transport stream is telecined film, but I am not using the Force Film option in DGIndex, instead I prefer to use Decomb in AVISynth for IVTC. In the middle of the stream there was a minor dropout. After the dropout the video is really jerky, almost as if the field order is wrong. But if I use a binary file splitter to remove the damaged section, the video after the dropout is decoded just fine.

At first I thought that DGIndex and/or DGDecode was getting confused when it encountered the bad packets and could not render the good video after the error correctly. But when if I use a binary splitter and remove all but about 5 seconds of good video before the error. DGDecode decodes the video just fine with a few blocks in the frames that are affected by the bad packets!

Why does DGIndex and/or DGDecode have trouble decoding the video when there is more than about 8+ seconds of good video before the error, but decodes the same stream just fine when their is only about 5 seconds of good video before the error?

I have had a few other streams in the past that showed the same problem. I have tried using both DGIndex/DGDecode 1.30 and 1.30b3.

I have uploaded a small segment of the transport stream here (http://164.106.37.42/WilliamsPlayZone/fieldorder.tp) (50 Mb). Sorry for the large file size, but if I slice it much more then the error does not appear.

[neuron2]

I'll have a look at it today.

[neuron2]

According to the PAT/PMT, there are 4 programs in that TS. Which one are you talking about (i.e., what PIDs are you using)?

[wbo]

Originally posted by neuron2
According to the PAT/PMT, there are 4 programs in that TS. Which one are you talking about (i.e., what PIDs are you using)?
Sorry about that, The Video PID that has the problem is 0x31 and the Audio PID is 0x34.

[neuron2]

OK. If you run DGParse on the D2V for program 3, you see an illegal transition, which changes the field order. You can fix it with DGFix. Deleting video before the error has the effect of correcting the bad transition as well. Of course, it's better to use DGFix, because you don't have to cut out frames.

[wbo]

Thanks for your help. I didn't know exactly what DGFix was used for, but now I know :)

[Cyberia]

Is there a downside to running DGFix unnecessarily? Why don't we just loop every d2v back through DGFix before outputting it?

On the other hand, why doesn't DGIndex catch the problem in the first place and avoid the need for DGFix?

[neuron2]

It's already on the development list:

15) (GUI) Integrate DGFix and DGParse into the GUI