[FFmpeg-devel] [PATCH] Revert "avcodec/decode: copy the output parameters from the last bsf in the chain back to the AVCodecContext"

[James Almer]

On 10/22/2018 6:44 PM, James Almer wrote:
> On 9/13/2018 6:50 AM, Timo Rothenpieler wrote:
>>> So, what do we do now? Honor the doxy and stop trying to manipulate
>>> what's meant to be an user owned pointer/buffer, officially break the
>>> API and declare it's meant to be allocated by the user but then
>>> ownership is passed to the library during or after the avcodec_open2()
>>> call, or just revert this commit and pretend nothing happened?
>>
>> Documenting the API break that already happened seems like the least bad
>> option right now. Firefox already merged code to work around the crash.
>>
>> It already is freed in multiple places, so existing code probably
>> already is compatible.
>>
>> No solution to this is overly pretty unfortunately.
>> Specially as this goes along with likely leaking the extradata pointer,
>> as unconditionally freeing it will most definitely cause crashes left
>> and right.
> 
> [18:32:33] <@mateo`> jamrial: hello, it looks like
> 662558f985f50834eebe82d6b6854c66f33ab320 introduced a regression on the
> mediacodec decoders. The decoder ends up receiving the bitstream in the
> hvcC form (for hevc) and not annex-b. The underlying bsf seems
> initialized twice, first time, everything is fine, second time it
> beleives the bitstream is already annex-b because of the newly replaced
> extradata (now in annex-b form).
> [18:35:00] <@mateo`> jamrial: any ideas on how to fix that ? I haven't
> found yet why the bsf is initialized twice (maybe because of
> avformat_find_stream_info() which opens a decoder)
> 
> I'm going to push this revert commit soon. We can reintroduce it and
> adapt the doxy accordingly at some later time. But for now we gain
> nothing and it only brought issues for library users.

Pushed.