Correctly handling 1080i with duplicate frames

[cogman]

I'm currently working on this ( https://www.amazon.com/Sherlock-Season-Blu-ray-Benedict-Cumberbatch/dp/B004132I20 ) and can't seem to figure out the right incantation to get it deinterlaced.

What I've observed,
It looks like nearly every interlaced frame is duplicated one after the other (I've found 1 or 2 exceptions in ~30 second samples). Pulling in the source without forcing a CFR causes the deinterlace algorithm to go nuts. Motion seems to advance forward then backwards at weird intervals.

Forcing CFR seems to MOSTLY fix things, however, there is still some weird jank I've not figured out. It's almost as if very brief clips (not present in the source) will jump into the wrong place. I suspect that it's a problem with ffms2 seekmode and h.264? (testing that now).

Here is my current best attempt

from vapoursynth import core
import havsfunc as haf

clip = core.ffms2.Source(source='/input/S01E01.mkv', threads=1, fpsnum=30000, fpsden=1001)
clip = haf.QTGMC(clip, Preset='Fast', TFF=True, EZDenoise=0.5, Denoiser='KNLMeansCL', opencl=True)
clip.set_output()

And here is some FFProbe info.


index=0
codec_name=h264
codec_long_name=H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10
profile=High
codec_type=video
codec_time_base=1001/60000
codec_tag_string=[0][0][0][0]
codec_tag=0x0000
width=1920
height=1080
coded_width=1920
coded_height=1088
closed_captions=0
has_b_frames=1
sample_aspect_ratio=1:1
display_aspect_ratio=16:9
pix_fmt=yuv420p
level=41
color_range=tv
color_space=bt709
color_transfer=bt709
color_primaries=bt709
chroma_location=left
field_order=tt
timecode=N/A
refs=1
is_avc=true
nal_length_size=4
id=N/A
r_frame_rate=30000/1001
avg_frame_rate=30000/1001
time_base=1/1000
start_pts=0
start_time=0.000000
duration_ts=N/A
duration=N/A
bit_rate=N/A
max_bit_rate=N/A
bits_per_raw_sample=8
nb_frames=N/A
nb_read_frames=N/A
nb_read_packets=N/A
DISPOSITION:default=0
DISPOSITION:dub=0
DISPOSITION:original=0
DISPOSITION:comment=0
DISPOSITION:lyrics=0
DISPOSITION:karaoke=0
DISPOSITION:forced=0
DISPOSITION:hearing_impaired=0
DISPOSITION:visual_impaired=0
DISPOSITION:clean_effects=0
DISPOSITION:attached_pic=0
DISPOSITION:timed_thumbnails=0
TAG:language=eng
TAG:BPS-eng=29451715
TAG:DURATION-eng=01:28:10.618666666
TAG:NUMBER_OF_FRAMES-eng=317120
TAG:NUMBER_OF_BYTES-eng=19477222333
TAG:SOURCE_ID-eng=001011
TAG:_STATISTICS_WRITING_APP-eng=MakeMKV v1.16.3 linux(x64-release)
TAG:_STATISTICS_WRITING_DATE_UTC-eng=2021-04-21 01:46:32
TAG:_STATISTICS_TAGS-eng=BPS DURATION NUMBER_OF_FRAMES NUMBER_OF_BYTES SOURCE_ID

[wonkey_monkey]

I'd be curious to see a sample to know if it has the same blended chroma problem that was present on the Doctor Who Specials blu-rays which were produced at around the same time.

If it is like those blu-rays, you should be able to reconstruct the proper progressive sequence just by shuffling fields around. There shouldn't be any need to resort to QTGMC.

Are there any seeking problems evident if you just do a plain bob?

[cogman]

I'd be curious to see a sample to know if it has the same blended chroma problem that was present on the Doctor Who Specials blu-rays which were produced at around the same time.

If it is like those blu-rays, you should be able to reconstruct the proper progressive sequence just by shuffling fields around. There shouldn't be any need to resort to QTGMC.

Are there any seeking problems evident if you just do a plain bob?

Here's a sample file. This file has been ran through ffms2 with default settings and encoded into vp9. Let me know if you want something a little more pure.

Let me play around with bob and see if that's good enough.

https://gofile.io/d/6Leh7s

[wonkey_monkey]

Purer would be good. That sample doesn't look anything like the right framerate. Lots of duplicated frames.

If you can find an action sequence with traffic lights in, those are good for spotting chroma problems.

[cogman]

Ok, here's a better sample just using ffmpeg's copy.

https://gofile.io/d/zb448Y

lots of "Non-monotonous DTS in output stream" warnings when I did that.

[jackoneill]

It's probably ffms2. Try lsmas.LWLibavSouce instead.

[wonkey_monkey]

Something still wrong there. It does't playback smoothly with MPC-HC or Windows Media Player either. What filetype is the original rip? What's your command to remux it to mkv?

[poisondeathray]

Works ok with dgsource ;

It fails with lsmash, ffms2, - tried threads=1, and remuxing with mkvtoolnix , also hw vs cpu for lsmash

It's a field blended conversion . DGSource + QTGMC + SRestore works ok

[poisondeathray]

I think the buggy timestamps are messing everything up. Whatever your process was for making the sample - it has buggy timestamps

If you demux to ES (discarding the timestamps), rewrap and force the correct framerate it works ok too (then LSmash + QTGMC + SRestore)

[videoh]

Works ok with dgsource ; It fails with lsmash, ffms2, - tried threads=1, and remuxing with mkvtoolnix , also hw vs cpu for lsmash Music to my ears. ;)

[cogman]

Something still wrong there. It does't playback smoothly with MPC-HC or Windows Media Player either. What filetype is the original rip? What's your command to remux it to mkv?

Original filetype was mkv and came from makemkvcon on the original blu-ray.

The sample was taken with the following command

ffmpeg -ss 00:05:24 -i S01E01.mkv -t 00:00:30 -c:v copy -c:a copy test.mkv

I think the buggy timestamps are messing everything up. Whatever your process was for making the sample - it has buggy timestamps

If you demux to ES (discarding the timestamps), rewrap and force the correct framerate it works ok too (then LSmash + QTGMC + SRestore)

Yeah, I'll give that a shot and see if it makes things easier.

I'll look into dgsource, but I'm using linux which seems to make it less an option.

Thanks for all the suggestions!

[cogman]

Ok, just got done playing with LSMash (with hardware decoding) + QTGMC, worked like a charm!

I think my ffmpeg command for getting the slice must have screwed up the timecodes (sorry about that).