Hello Selur:
Please bring back the force deinterlace option, is needed to encode (upscale) interlaced VOB files using DNxHD since some profiles only works if the source material is progressive.
Thank you.
Ig your source is interlaced, but not properly flagged, you should overwrite the scan type to TFF or BFF and keep 'auto' enabled. I don't the whats wrong with this.
Cu Selur
The sources are in fact properly flagged as interlaced, problem is that DNxHD profiles 115, 145 and 175, which are the ones for 1080p NTSC, only takes progressive inputs otherwise the encode fails, so I have to overwrite the input scan type to progressive in order to make it work but as a result the source is not being deinterlaced, so just activating the force option in older versions the source is then deinterlaced and the encode is done producing a beautiful upscaled video @ 1080p from a SD interlaced source.
Now, it can't be done unless I use other codec such as ProRes which is inferior to my eyes.
Cheers.
Okay, that makes no sense to me.
If your source is interlaced and deinterlace is set to auto, Hybrid should deinterlaced and produce progressive output which should then work fine if the selected DNxHD profile support progressive content.
If this fails then it's a bug.
Cu Selur
Maybe it is just confusion bug between "Overwrite input scan type" and QTGMC Order: -1, as i described in other thread?
MixMaker, try to turn off "Overwrite input scan type" and use only QTGMC "Order: 0 or 1" to force set lower or upper field list input, and see if it will work.
![[Image: X3q8hAa.jpg]](https://i.imgur.com/X3q8hAa.jpg)
In his case he should not touch the "overwrite input scan type to" option I don't see the connection to the bug mentioned in the other thread.
(20.08.2020, 20:03)Selur Wrote: [ -> ]Okay, that makes no sense to me.
If your source is interlaced and deinterlace is set to auto, Hybrid should deinterlaced and produce progressive output which should then work fine if the selected DNxHD profile support progressive content.
If this fails then it's a bug.
Cu Selur
It is a bug indeed.
The only way the encode starts without error is overwriting the input scan order to progressive, but then the source obviously is not deinterlaced despite the deinterlace is set to auto.
-> will look into it after work
(20.08.2020, 20:36)shijan Wrote: [ -> ]Yep, "overwrite the input scan type to progressive in order to make codec work" makes no sense
Maybe codec conflict is somehow related to Vapoursynth R51 aliasing problem? https://github.com/vapoursynth/vapoursynth/issues/625
I've been able to successfully encode using the same settings with overwriting the input scan to progressive and then force Hybrid to deinterlace.