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

[wm4]

On Tue, 10 Mar 2015 18:02:12 +0100
Reimar Döffinger <Reimar.Doeffinger at gmx.de> wrote:

> 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.

Then lavc should provide a proper mechanism for this.

The get_format thing doesn't work if the hardware decoder and the
software decoder are different AVCodecs.

> > 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.
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel