On Tue, 10 Mar 2015 18:02:12 +0100 Reimar Döffinger <reimar.doeffin...@gmx.de> wrote:
> 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. 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@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
