[FFmpeg-devel] [PATCH 2/3] avisynth: use AviSynth+'s frame properties to set various fields

[Stephen Hutchinson]

On 8/25/22 3:46 AM, Steinar Apalnes wrote:
> tor. 25. aug. 2022 kl. 02:11 skrev Stephen Hutchinson <qyot27 at gmail.com>:
> 
>> On 8/24/22 1:04 PM, Steinar Apalnes wrote:
>>> tir. 8. feb. 2022 kl. 12:03 skrev Stephen Hutchinson <qyot27 at gmail.com>:
>>>
>>>> * Field Order
>>>> * Chroma Location
>>>> * Color Transfer Characteristics
>>>> * Color Range
>>>> * Color Primaries
>>>> * Matrix Coefficients
>>>>
>>>> The existing TFF/BFF detection is retained as a fallback for
>>>> older versions of AviSynth that can't access frame properties.
>>>> The other properties have no legacy equivalent to detect them.
>>>>
>>>> Signed-off-by: Stephen Hutchinson <qyot27 at gmail.com>
>>>>
>>> .......
>>>    Hi Stephen,
>>>
>>> Would it be possible to add support for "_SARum" and "_SARDen" so that
>>> ffmpeg could also recognize the sample aspect ratio in avs scripts?
>>>
>>
>> I'm a bit hesitant to do so, namely because the _SARNum/Den properties
>> are much more likely to need to have been changed due to operations
>> in-script, and unless the user is studious about updating those
>> properties after even just a basic resizing operation, then _SARNum/Den
>> will still be set to the original values populated by the source filter,
>> and will be wrong, leading to encodes ending up wrong and potentially
>> bug reports to Trac which aren't actually the fault of the demuxer.
>>
>> This is partially coming from the fact that even the color-based
>> properties that were already added have experienced some level of
>> backlash because of the requirement for users to ensure the properties
>> are correctly updated if they've done any changes to those factors
>> (as best as I'm aware, the filters in the AviSynth+ core still only pass
>> through the existing properties, but they don't update them if they
>> pertain to that property's functionality; I believe some external
>> filters do update them, however).  I would be fairly confident in
>> betting that users resizing video is far more common than them doing
>> color correction ops that would require updating the frameprops FFmpeg
>> can currently read.
>>
>> One mitigation to that, IMO, would be to flag that as an experimental
>> feature, making it to where FFmpeg won't read _SARNum/Den unless
>> the -strict option has been used.
>> _______________________________________________
>>
>>
> If you think cherry picking what props to support under normal operation is
> the way to go
> then a -strict option to support *all* "scary" avs props would be very
> welcome indeed.
> Because as it is now we have nothing at all in regards to the SAR.
> 
> Thanks for your efforts :-)
> 
> -steinar

SAR frameprops implemented in commit c49beead, and a more fine-grained,
flags-based way to toggle any of the frameprops on and off added in
commit adead1cc.  Pushed a few minutes ago.