Yes, that is as it should.
This has been answered before.
Quote:Deinterlace handling:
Sets what method will be used to deal with non-progressive content, assuming the output isn't marked as interlaced in the encoder.
Hybrid does only deinterlace if:
a. the source is non-progressive
b. the output is not interlaced
So:
- If your source is flagged as interlaced, but in reality is progressive: overwrite the scan type.
- If your source is flagged progressive, but in reality interlaced: overwrite the scan type.
- If your source is progressive and properly flagged, do not worry Hybrid will not try to deinterlace the source.
Cu Selur
(29.07.2024, 05:25)Selur Wrote: [ -> ]Yes, that is as it should.
This has been answered before.
Quote:Deinterlace handling:
Sets what method will be used to deal with non-progressive content, assuming the output isn't marked as interlaced in the encoder.
Hybrid does only deinterlace if:
a. the source is non-progressive
b. the output is not interlaced
So:
- If your source is flagged as interlaced, but in reality is progressive: overwrite the scan type.
- If your source is flagged progressive, but in reality interlaced: overwrite the scan type.
- If your source is progressive and properly flagged, do not worry Hybrid will not try to deinterlace the source.
Cu Selur
Why remove the option to do this? It's just faith at this point to assume it's "properly flagged" enough for Hybrid to not alter the file?
Setting it to 'none' before could still cause Hybrid to deinterlaced in some cases.
It is/was always 'faith' that Hybrid does as intended.
So keep it 'clean' removing that option was the right call.
This is not going to change.
Cu Selur
(29.07.2024, 05:38)Selur Wrote: [ -> ]Setting it to 'none' before could still cause Hybrid to deinterlaced in some cases.
It is/was always 'faith' that Hybrid does as intended.
So keep it 'clean' removing that option was the right call.
This is not going to change.
Cu Selur
Why... would it be trying to deinterlace if it's specifically told not to? And why would this not be fixed instead of removing the none option and not communicating at all how the new forced-faith deinterlace option works in the actual program?
The behavior how Hybrid handles interlacing is not new, that is how it always was.
The removal of that option, simplified the maintenance and complexity of the general code.
I write and maintain Hybrid on my own and keeping that in mind, stuff needs to be cleaned up from time to time and removing unneeded stuff is sometimes part of it.
This will not change.
Cu Selur
i think that the issue is that users see "Progressive" greyed out... maybe better to remove the "progressive" text from the gui (if the source is an interlaced one) ... or clearly write "interlaced" ... .. or a text saying : video will be not deinterlaced
just to reassure users that no kind of "deinterlacing" is being done
![[Image: progressive.jpg]](http://www.wcn.it/progressive.jpg)
also now i'm concerned about this:
i need to remove the "OVERWRITE SCAN" flag if i'm processing a progressive clip? (i set this enabled by defualt because i'm working on interlaced PAL... but how i can be sure that hybrid is not doing a deinterlacing job if this flag is set?)
looking at the ineterface seems that i need to remove the flag on modern videos... but removing it i have an "abort" processing the clip...
(this is a debug log without the OVERWRITE flag) :
http://www.wcn.it/debug.txt
http://www.wcn.it/abort.mp4
That indicates what the input scan type info is.
How would you know that you needed to overwrite that scan type in the second case (where you interlaced content lags proper interlacing tags) if it was not indicated there?
Selur, with this file: ( a progressive from a smartphone )
http://www.wcn.it/test.mp4
the rendering is aborting and i need to force some sort of deinterlacing to have a rendering.
using latest Experimental
Without a debug output, I have no clue what you are doing,...
Instead of forcing some deinterlacing, you could enable "Filtering->Vapoursynth->Misc->Script->Always use Vapoursynth" this should force Vapoursynth handling.
There also seems some issue with the time codes, which causes a crash during muxing.
(more or less time codes than frames,...) Enabling Config->Input->Decoding->CFR seems to help (this way Hybrid will not try to remux the time codes).
=> going to bed now