[FFmpeg-devel] [PATCH] avisynth.c corrected interlace detection

[emcodem at ffastrans.com]

Am 2021-05-27 22:38, Stephen Hutchinson wrote:

> The change seems okay, but the comment and commit message need to
> explain what's going on better, because the confusion that's erupted
> over this seems to derive from the rather poor way the AviSynth
> documentation describes the difference between field-based and
> frame-based clips, and how to access this information through the API.
> After having read through all of this a bit more, the situation
> appears to
> be as follows:
> 
> AviSynth works on Frame-based video.  Full stop.  'Frame-based',
> despite the name, is not a synonym for 'progressive', merely that
> it's being processed as a single frame rather than as a half-height
> field.  This is the single point from which all the rest of this
> got confused.
> 
> Using SeparateFields(), you can break the frame into its constituent
> half-height fields so that certain filters which don't like processing
> interlaced footage can filter the fields as a sort of 'fake
> progressive', before using Weave() to combine the fields again into
> a singular full height frame.  That's its intention, rather than to
> signal to a client program that something is interlaced. The
> AssumeFieldBased() function and avs_is_field_based API check are
> there to allow other functions to understand this situation
> where the fields have been broken apart (or to override the
> field-based setting in cases that it didn't get set properly).
> 
> The confusion seems to have arisen from mistaking these as ways
> that AviSynth indicates something is interlaced or not, and it
> isn't.  For that purpose, you have to look at frame properties,
> something that was introduced in AviSynth+ as a flag that a source
> plugin can set to indicate whether the frame is interlaced (either
> tff or bff) or progressive.  Adding frame property detection to
> the demuxer here would require larger changes that need to be
> guarded from 2.6, but it would accomplish the goal I *think*
> this is ultimately intended to address.
> 
> The in-code comment should probably be something closer to:
> 
> /* AviSynth works on frame-based video by default, which can
> /* be either progressive or interlaced. Some filters can break
> /* frames into half-height fields, at which point it considers
> /* the clip to be field-based (avs_is_field_based can be used
> /* to check for this situation).
> 
> /* To properly detect the field order of a typical video clip,
> /* the frame needs to have been weaved back together already,
> /* so avs_is_field_based should actually report 'false' when
> /* checked. */

Yeah i think a huge part of all the confusion is that all existing 
descriptions are written from an "inside avisynth" perspective, while 
from feeling most readers see it from the "recieving applications 
perspective". From this perspective, it is kind of guaranteed that 
field_based clips have to be threated as progressive because is not 
really a chance that the delivered frames are interlaced - except a 
filter did not set the value correctly.
Checking the Frame property as you suggest could make it for sure better 
but honestly i don't see a need for it because env->field- and frame 
based should be set correctly by the filters. It would be a shame if the 
demuxer would have to actually decode a frame to get this propety 
correctly - also it could potentially take many minutes for the first 
frame to be decoded when the script does lots of smart stuff and the 
resolution and bit depth is very high. Last but not least, you could 
potentially decode frame 0 while the script doesn't even need frame 0 
because it starts at another one.

However, leaving all this aside, i also hope my stuff makes the 
situation better than it was before and of course
i am ok with your comment version, have nothing to add.
You want me to change it and re-send the patch (i always struggle in how 
exactly to do that, you want me to work from my current fork where the 
commit i sent is included , alter it and commit again - or you want me 
to start from scratch and send a totally new patch?)

Thanks a lot Steve
-emcodem