On 2/14/2018 2:09 AM, wm4 wrote:
> On Wed, 14 Feb 2018 07:07:09 +0700
> Muhammad Faiz <mfc...@gmail.com> wrote:
> 
>> On Tue, Feb 13, 2018 at 3:57 AM, wm4 <nfx...@googlemail.com> wrote:
>>> On Mon, 12 Feb 2018 12:42:10 +0700
>>> Muhammad Faiz <mfc...@gmail.com> wrote:
>>>  
>>>> Modify the behavior of init_static_data().
>>>>
>>>> Signed-off-by: Muhammad Faiz <mfc...@gmail.com>
>>>> ---  
>>>
>>> Seems OK, but I'm also not sure about the benefit. The fundamental
>>> problem that these codecs need to mutate AVCodec before the users sees
>>> it won't go away.  
>>
>> Actually, I'm too. Any idea how to remove init_static_data()?
> 
> The only way is to change the API somehow and deprecate
> AVCodec.pix_fmts.

That's not the only thing you can do to an AVCodec during init_static.
Before we dropped support for old libvpx versions we'd set the
experimental cap to the encoder's AVCodec if it was a version known for
generating bad streams.
The same may end up being done for libaom and AV1.

> Or we could define that entries in pix_fmts are not
> always available at runtime, but this would still be an API break and
> require deprecation and a replacement mechanism. Honestly I'm not
> really sure how to do this - maybe the simplest possible replacement
> would be fine, like avcodec_get_pix_fmts(AVCodec)?
> 
> For now it actually seems less trouble to just leave those maybe 3 or 4
> AVCodecs mutable. At least there are no race anymore thanks to
> init_once.
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Reply via email to