[FFmpeg-devel] [PATCH] pthread: Fix ff_thread_get_formatissues when called outside frame decode.

[Reimar Döffinger]

On 10.03.2015, at 12:10, wm4 <nfxjfg at googlemail.com> wrote:

> On Mon, 09 Mar 2015 18:56:57 +0100
> Reimar Döffinger <Reimar.Doeffinger at gmx.de> wrote:
>>> 
>>> What I do is simply restart decoding with the packet that failed the
>>> hardware decoder. Don't need to buffer anything, you still have the
>>> AVPacket in question anyway.
>> 
>> Uh, so you simply assume that decoding the same frame twice doesn't break anything? How do you enable multithreading? Do you just assume you can do that in the middle of decoding?
>> Or do you create a new decoder? In which case, how do you ensure that the new SPS wasn't in an earlier packet due to bad muxing for example?
>> Also the buffering issue is the other way, when you try to go from multithreading to HW decode, how do you handle that?
>> If it works well I'd be totally in favour, but I strongly suspect it only works because you both got lucky and don't even try the hard things and still need more code on the user side.
> 
> Just create a new context.

There is nothing "just" about creating a new context, not for those who want seamless switching between hardware and software decoding.
I am not one of those people admittedly, but I do see it as an issue.

> Really, there are (or will be) hardware decoders which do not fit into
> the hwaccel model. So you need to open a new codec anyway to handle
> fallbacks correctly. I think the current way how hardware decoding
> fallback is supposed to work in lavc sucks by design, has multiple
> implementation problems (like this one!), and is a dead-end.

That may well be, but that doesn't mean it should be our goal to make things work worse and be even more effort for users.