On 10.03.2015, at 12:10, wm4 <nfx...@googlemail.com> wrote: > On Mon, 09 Mar 2015 18:56:57 +0100 > Reimar Döffinger <reimar.doeffin...@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. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
