On 2/7/24 13:56, Andreas Rheinhardt wrote:
> Leo Izen:
>> On 1/23/24 14:22, Michael Niedermayer wrote:
>>> Hi all
>>>
>>> As it was a little difficult for me to not loose track of what is
>>> blocking a release. I suggest that for all release blocking issues
>>> open a ticket and set Blocking to 7.0
>>> that way this:
>>> https://trac.ffmpeg.org/query?blocking=~7.0
>>>
>>> or for the ones not closed:
>>> https://trac.ffmpeg.org/query?status=new&status=open&status=reopened&blocking=~7.0
>>>
>>> will list all blocking issues
>>>
>>> Ive added one, for testing that, i intend to add more if i see something
>>>
>>> What is blocking? (IMHO)
>>> * regressions (unless its non possible to fix before release)
>>> * crashes
>>> * security issues
>>> * data loss
>>> * privacy issues
>>> * anything the commuity agrees should be in the release
>>>
>>> thx
>>>
>>>
>>
>> My EXIF overhaul is going to be an ABI break so I'd like to get it in,
>> if and only if we are doing an ABI break with the release.
>>
> 
> What EXIF overhaul? Since when is EXIF part of the ABI?
> 
> - Andreas
> 

I'm working on a patch to centralize a lot of the exif logic and make it 
easier for decoders to attach it to an AVFrame as side data, rather than 
dumping all the key/value pairs into AVFrame.metadata and then hoping 
that an encoder can serialize them out properly.

As for ABI, there's an avpriv in libavcodec/exif.c that is called by the 
AVI demuxer in avformat. My plan is to expose some of these exif parse 
routines as a proper av_ API, and replace that avpriv_ call with a call 
to the new API. I mentioned this to James on IRC and he said it would 
have to go in during an ABI flexibility period.

- Leo Izen