Frame Degradation to to I frame insertion in MPEG2 streams

[Pentajet]

I would appreciate if anyone could tell me what this problem is called exactly as I am keeping searching for it but can't find any reference to the exact problem that I am experiencing. A soloution would also be much appreciatted, of course.

Sometimes MPEG2 streams occasionally exhibit a series of degraded (very low quality especially in regards to chroma)frames usually in groups od 1-11 frames. Typically this occurs after a scene change. The cause of this problem (I think) is pretty obvious: in a GOP of 12 frames the I frame is inserted on the previous scene so the new scene starts with a P frame or B frame and not enough bitrate is allocatted to it so the frame is of a terribly low quality.

I am not looking for prevention (I know how to do that) since what I am trying to restore is a pretty old wedding dvd but for a cure. Ideally a filter that will detect the frames and perhaps replace them with neighbours or at least improves he overall quality. Even the exact name of this problem would be appreciatted.

:thanks:

[Mug Funky]

yeah, you'll get this when a P-frame comes right after an I frame when there's a scenecut in between. ratecontrol will often hit the p-frame very hard because the preceding I frame was quite large and the encoder doesn't want to cause an underflow.

the P-frame will have no good temporal reference, and will be given a high quantizer (ie low quality), so it'll just completely mong out, along with the frames around it that refer to it. however, this situation should recover within a couple of P-frames. if it's going for the length of the GOP, then there's something wrong with the encoder that was used.

as far as solving it goes... hard to say, because blocks are difficult to remove in this situation, and quite hard to detect without the original to refer to.

you could try just using DGdecode's internal deblocking - it's triggered by quantizer (and has access to the stream to read them from), but can also cause details to be lost, or pulse around due to b-frame offsets and other things. failing that you could make a per-frame metric that uses mvtools to check the current frame against surrounding frames, and compare it with a scenechange detector - if current (compensated) frame is more similar to a frame before a scenechange than after it, it can be declared "mong" and you could rebuild it with motion-compensation. but then you've got the rest of the GOP to deal with...

[Boulder]

I've been removing ugly DVB broadcast blocking (interlaced stuff at ~2.5Mbps) with DGDecode's deblocking set at CPU=4 and then using MVDegrain2. I know it's a bit harsh but the output looks much better than the original. For creating fake detail after the cleanup, there's Didée's Grain-o-matic and trbarry's AddGrain.

http://www.neuron2.net/board/viewtopic.php?t=720