[FFmpeg-devel] [PATCH] Populate field order returned by avs script, Trac Ticket 8757

[Stephen Hutchinson]

On 1/16/21 7:26 PM, emcodem at ffastrans.com wrote:
> The purpose of this is to tell ffmpeg which field order the returned 
> clip of the avisynth .avs script decided to finally deliver, which is 
> handy in an automated environment.
> Interlacing is generally a very hard topic in avisynth, the huge comment 
> is neccessary to explain my reasons.
> Additionally to the comment in the patch, i can tell that i set unknown 
> instead of progressive for backward compatibility. (i was struggeling 
> with this, maybe i should have even left it unset in case it is not 
> clearly tff or bff interlaced.
> 
>     /*  Set interlacing type. 
> http://avisynth.nl/index.php/Interlaced_fieldbased
>      *   The following typically only works when assumetff (-bff) and 
> assumefieldbased is used in the avs.
>      *   This is because most avisynth source plugins do not set the 
> parity info in the clip properties.
>      *   We could use GetParity() to be more accurate but it decodes a 
> frame which is
>      *   expensive and can potentially lead to unforeseen behaviour when 
> seeking later.
>      *   In case Parity is not known, we still cannot guarantee that
>      */
Going into detail about GetParity wouldn't be necessary if it's not
used (and there aren't any other invoke-parsed functions aside from
checking with Import() whether the script actually returns a clip),
so the comment could be shortened.  Also, since this is the avisynth
demuxer, 'in the avs' would be better rendered as 'in the script',
and simply refer to 'source plugins' rather than 'avisynth source
plugins'.

Comment bikeshedding aside, LGTM, but the avs_is* API usage added here
needs to be reflected in the AVSC_DECLARE_FUNC and LOAD_AVS_FUNC blocks.
If those parts of the API are present in 2.5, the LOAD_AVS_FUNC can be a
0. If they were added in 2.6 (or Plus, but I know these would have to be
from classic AviSynth), then it should be 1.