DVB-C - HD H264 stream with blurred frames

[martin53]

asteri,
trust Didée's experience in framerate conversion, IVTC etc.

Since you also PM-ed me, find my contributions here.

(I don't own DGDecNV, nor a NVidia card. DGAVCIndex+AVCSource() (DGAVCDecode.dll, all march 2009) gave errors "Found NALU type 13, len 2 undefined, ignore NALU, moving on". The output was buggy and unusable. So I transcoded the AVC to huffyuv (XMediaRecode) and tested with AviSource() ).

HD, Deinterlace, downscaling
Because you downscale below one half of the original height 1080, I suggest you leave away all deinterlacing/bobbing and just take one field.

Motion smoothness reconstrucion
Mediainfo tells me that the example from the first post is 25fps. With telecined or otherwise framerate-crafted footage, I know three effects: duplicated fields/frames, blended frames and missing frames. In general, inverse telecine depends on the cuts and the assembly of the original. For broadcasts assembled from 50fps or 60fps interlaced video and 24fps film, obviously there is no solution that fits both without any quality loss. And if a clip was assembled after 24->30 or 24->25 or 30->25 or ... fps conversion, the inserted frames may be at different positions of the group over a cut.

The given example does indeed show blended frames, but it also puzzled me. The mentioned scene with the bottles, papers etc. shows a frame-by-frame motion scheme migrating between [normal-normal-normal] and [big-small-big] (~ frames 265, 288 and 311). Jerkyness seems to come from that: with 25fps and two frames nearly identical, then a big move, you have in fact 12.5fps.

-> I don't think Srestore can help here. Frame replacement looks even more jerky in pan scenes, and i found no suitable pattern for frame removal in the clip.

Instead, I figured out a frame realignment method with MVTools (would have proposed SVPflow, but that throws an exeption on my V2.6 x64 system), see example.
The idea is to take every 2nd frame, calculate the motion vectors and move the contents of the middle frame to the middle of the motion vectors. Pan looks good, station logo not. I didn't succeed with scene changes - so I leave that as an exercise for you

function FlowComp(Clip c) {
# Function takes every 2nd frame and calculates motion vectors.
# Then, MFlowInter is the result of the frames, with pixels moved to the position of the removed frame.
# Because not always all objects are visible in the first, second and third frame, there are typically atrefacts.
    c
    SelectEvery(2,0)
    super = MSuper()
    backward_vectors = MAnalyse(super, isb = true, delta=1)
    forward_vectors = MAnalyse(super, isb = false, delta=1)
    MFlowInter(super, backward_vectors, forward_vectors, time=50, ml=70)
# The artefacts are reduced a bit by the second process: Motion vectors between the removed frame and the synthesized frame are calculated
    super = MSuper()
    vectors = MAnalyse(super, isb = false, delta=1)
# And now the pixels of the removed frame itself are moved to the positions in the synthesized frame.
# So, most of the content of the 'removed' frame is in fact not removed, but it is moved to positions 50% between previous and following frame
    MCompensate(c.SelectEvery(2,1), super, vectors)
    Interleave(c.SelectEvery(2,0),  last)
}

function CompareHor(clip c0, clip c1) {
# Function is just there to show differences between to similar clips
    d= mt_makediff(c1,c0)
    d= mt_lutxy(c1, c0, expr="x y - 5 * 128 +", chroma="process")
    StackHorizontal(c0, c1, d)
}
#==============================================
# Input
AVIsource("test.avi")
trim(254,0)

AssumeTFF()
SeparateFields()
# Remove one field - is in fact similar to VerticalReduceBy2()
SelectEvery(2,0)

# Correct aspect ratio
HorizontalReduceBy2()

# Remove following line for final processing
CompareHor(last,FlowComp())

[Didée]

Originally Posted by martin53

I suggest you leave away all deinterlacing/bobbing and just take one field.

If the source is field blended, the one thing you must not do is discarding one field. There will be vital information in even and in odd fields (alternating by phase of blending pattern). If you start out with discarding half the fields, I suppose that's the cause of the jerky- or jumpy-ness that you mention.

IMO Srestore does a reasonable job on this source, the script I posted gives a smooth result. There are no motion states missing in the source, and there are neither skipped nor duplicate frames in the result.

[asteri]

Hi, I am little bit busy before Christmas I guess as anybody else

I think Didees script is fine BUT... I have try this method on whole documentary. The test scene is looking quite well now, unfortunatelly I have found others which are maybe worse than without using SRestore. Or maybe I am so confused from making the comparison again and again that I dont see well I need someone who can confirm it.

I will try prepare some more test scenes from the same documentary and show what I am talking about. Thanks for now to all. I really apreciate your help!

[martin53]

Originally Posted by Didée

If the source is field blended.

Agree if. This test clip did not look that way to me after SeparateFields(), I think I can judge that from the motion of objects.
If they originally shot it at 60i, the fields origin from t=0 (top field) and t=8.3ms (bottom field).
If they now left away one frame to convert 60->30 fps, there is 8.3ms difference between the fields in one frame, but then 25ms to the next top field, to achieve 33.3ms between frames.
Maybe this is where the appearingly odd motion comes from. To my eyes, there was no or substantially less motion between the fields of one frame than between bottom field of preceding frame and top field of next frame.
Could be worthwile to analyse by synthesizing full frames from the fields, but I won't

[Didée]

Originally Posted by martin53

Agree if. This test clip did not look that way to me after SeparateFields(), I think I can judge that from the motion of objects.

Dunno, perhaps you didn't look close enough. I looked at the source after bob-deinterlacing, and can clearly see that 1/4th~1/3rd of all bob frames are blended.The only odd thing is the actual pattern ... in this kind of norm conversion, usually one would expect to be almost half of all fields (or bob-frames) to be blended, and 2 fields (bob-frames) per second to be duplicates (or weave-able fields). In this sample there are less blends than usual, and much more dup-things than usual. (Perhaps they have discovered a forgotten knob on the normconverter box, enabling an alternative blending pattern ... )

Originally Posted by asteri

The test scene is looking quite well now, unfortunatelly I have found others which are maybe worse than without using SRestore.

That's quite possible. As already mentioned - if the original source actually was a mix of 24p film sections and 60i (maybe 30p) NTSC-sections, then after normconversion you're facing a real problem. In this case you can't get the thing done in one go by an automated tool. You would have to isolate the different sections manually, treat them seperately, and finally either create a VFR (variable framerate) MKV file, or speed the unblended 24p section up to 25p, to merge them with the NTSC sections (which would be left in their blend-converted 25i stage).