Deinterlacing AVS still interlaced bug?

[flyordie]

Thank you for continuing to support this software!

I just jumped back into this with a 7950x and 4080 to hopefully reduce my older larger files. No real issues getting this to work on Windows 11 with AviSynth+ 3.7.2.

I came across a MKV with h.264 video that is interlaced 29.970
Scan type : MBAFF
Scan type, store method : Interleaved fields
Scan order : Top Field First

I ran this through dgdecnv_248 without issues and adjusted the output avs to add deinterlace
DGSource(input.dgi,ct=104,cb=104,cl=0,cr=0, deinterlace=1)

The oddity is when I go to encode based on this avs input I get
Input #0, avisynth, from 'input.avs':
Duration: 02:28:00.47, start: 0.000000, bitrate: N/A
Stream #0:0: Video: rawvideo (I420 / 0x30323449), yuv420p(tv, top first), 1920x872, 29.97 fps, 29.97 tbr, 29.97 tbn

and therefore the output gets
Stream #0:0: Video: hevc (Main) (hev1 / 0x31766568), yuv420p(tv, top coded first (swapped)), 1920x872, q=2-31, 29.97 fps, 30k tbn

I tried with deinterlace=2 but I get the same results at 59.94 fps
When I run the the output file back into DGIndexNV and play it shows Frame Struct is Progressive with zero frame/field repeats and 0% film.

I tried with the oldest you have hosted dgdecnv_242, but same results.
Most everything I have delt with so far is Progressive 23.976 fps so I haven't come across an interlaced video yet.
To see if this is a me problem or not I goodle'd and found these two sample interlaced files
https://forum.videohelp.com/threads/400 ... ced-sample
McCartney-MPEG2_1080-interlaced_sample.mkv (128.97 MB)
0090227_233739-H.264.m2ts_1080i_interlaced_letterman_sample.mp4 (55.14 MB)
and these also show the same characteristics. ffmpeg input and output metadata keeps it thinking its interlaced, but the actual encoded video is progressive.

Is this a bug or something I can/should force in the avisynth script? Not sure what command in Avisynth I should use to say hey this is progressive, if there is one.

Thank you

[Rocky]

Deinterlacing via DGDecode will make the content progressive. Avisynth then delivers it as raw video. If ffmpeg thinks its input is interlaced that's an issue for ffmpeg not DGDecNV. Anyway, can't see how what you posted shows the input as interlaced. This matter is better suited for doom9 or videohelp, as we do not support ffmpeg.

[flyordie]

Thank you for the quick follow up.
Just to close the loop on this.

I installed 32-bit AviSynth 2.6 and the avs input stream now states:
Input #0, avisynth, from 'input.avs':
Duration: 02:28:00.47, start: 0.000000, bitrate: N/A
Stream #0:0: Video: rawvideo (I420 / 0x30323449), yuv420p, 1920x1080, 29.97 fps, 29.97 tbr, 29.97 tbn
with an output of:
Stream #0:0: Video: hevc (Main) (hev1 / 0x31766568), yuv420p(progressive), 1920x1080, q=2-31, 29.97 fps, 30k tbn

MediaInfo now shows progressive instead of interlaced in the metadata of the output mp4.
I'll see if I reach out to AviSynth+.

Thank you for responding.

[flyordie]

I did notice if I open the letterman example video and accidently hit demux menu it will crash DGIndexNV.

[flyordie]

I did get a reply regarding this and thought I would share here.
https://github.com/AviSynth/AviSynthPlus/issues/356

Recent builds of FFmpeg can read AviSynth+'s frame properties (which is also where it gets the Range, Primaries, Transfer, and Matrix information). This would have one of three places it could be resolved:

In plugin:
A) It sounds like DGDecNV isn't changing the _FieldBased frame property after it deinterlaces. There's a post from last year stating that frame properties for pulldown have been added ( https://rationalqm.us/board/viewtopic.p ... 665#p15665 ), but I'm not entirely sure whether that meant unique frameprops were added (therefore _FieldBased wasn't touched after being populated at the time the video was opened), or if it specifically only referred to pulldown removal and not deinterlacing.

In script:
B1) If you know the video has been deinterlaced but the frame property hasn't been changed to reflect that the video is now progressive, you can change the frameprop yourself by using propSet("_FieldBased", 0) (0 = progressive, 1 = bottom field first, 2 = top field first).

B2) Alternatively to just changing a known-progressive script to report that it is progressive, you could just delete that frameprop with propDelete("_FieldBased").

In client:
C) If you want to control which frame properties FFmpeg reads, you can use the -avisynth_flags parameter. So you can tell FFmpeg to just ignore the _FieldBased frameprop. Compare with:

ffmpeg -avisynth_flags -field_order -i input.avs

[Rocky]

I did notice if I open the letterman example video and accidently hit demux menu it will crash DGIndexNV.

Thank you for the report. The stream uses an unusual atom to signal the AC3 properties (Apple stuff?). An exception is thrown when the usual atom is not found. I'll see if I can add support for that.

Will answer your points about _FieldBased etc. after looking into this bug.

[Rocky]

Got a fix working. Will do some refactoring/regression testing and then give you a test version later today.

There's a post from last year stating that frame properties for pulldown have been added

That was completed only for DGMPGDec. I clarified that post you referred to. Yes, need to port the latest frame properties code from DGMPGDec. I'll probably do a few at a time, starting with _FieldBased.

[Rocky]

Please test this for your MP4 crash bug fix. If you approve it, we'll move on to the _FieldBased stuff. Thank you.

https://rationalqm.us/misc/DGIndexNV_flyordie.rar

[Rocky]

Went ahead and slipstreamed the MP4 crash bug into build 248. Moving on to frame properties...

[Rocky]

OK, slipstreamed another change into build 248. The _FieldBased variable is now doing this instead of the older Avisynth semantics:

_FieldBased [int]
Describes the composition of the frame:
0=frame based (progressive), 1=bottom field first, 2=top field first.
Note that for DGSource() the GOP progressive flag is used to determine whether the
frame is progressive. If deinterlacing is enabled in DGSource() then _FieldBased is overridden
as progressive. If DGBob() or PVBob() are invoked, then _FieldBased is overridden
as progressive; if neither is invoked then _FieldBased is passed through from DGSource().

It requires Avisynth+ version 8 or greater. The changes for DGSource() are implemented for Vapoursynth also. DGBob() and PVBob() do not currently support Vapoursynth.