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

James Almer jamrial at gmail.com
Tue Oct 23 00:44:00 EEST 2018


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.


More information about the ffmpeg-devel mailing list