On Mon, 09 Mar 2015 18:56:57 +0100 Reimar Döffinger <reimar.doeffin...@gmx.de> wrote:
> On 9 March 2015 15:28:48 CET, Hendrik Leppkes <h.lepp...@gmail.com> wrote: > >On Mon, Mar 9, 2015 at 1:50 PM, Reimar Döffinger > ><reimar.doeffin...@gmx.de> wrote: > >> On 9 March 2015 13:34:24 CET, Hendrik Leppkes <h.lepp...@gmail.com> > >wrote: > >>>On Mon, Mar 9, 2015 at 7:38 AM, Rainer Hochecker > >>><fernetme...@online.de> wrote: > >>>> Reimar Döffinger <Reimar.Doeffinger <at> gmx.de> writes: > >>>> > >>>>> > >>>>> Any reason to believe this patch causes it? > >>>>> Because I can't see how it would. > >>>>> Maybe it's just a bug with DXVA and multithreading in the HEVC > >code? > >>>>> Can you provide some more information like a stacktrace, possibly > >>>using a > >>>> tool like DrMemory? > >>>> > >>>> I don't think the patch itself is the root cause of the issue, it > >>>just > >>>> triggers it. get_format is called 4 times, something seems to get > >>>corrupted > >>>> in opening our hw decoder. > >>>> Do you have an explanation why it works with thread_safe_callbacks > >>>set to 1? > >>>> > >>>> I am wondering if hevc misses the multithreading fix done for other > >>>codecs: > >>>> http://ffmpeg.org/pipermail/ffmpeg-cvslog/2013-March/062620.html > >>>> > >>>> What do you think? > >>>> > >>> > >>>I build the HEVC HWAccel support, and I consider frame-threading with > >>>hwaccel an abomination that should not be supported, so I didn't > >spend > >>>any time thinking about it. > >>> > >>>Honestly, there are several issues with MT+HWaccel in H264 as well, > >at > >>>least on Intel hardware, so I can only strongly urge everyone to not > >>>combine it. There is zero advantages, and only downsides! > >> > >> Only if you completely ignore the practical issues that anyone trying > >to use it will have. > >> In many cases applications will not know whether hardware supports > >decoding the video until there get_format call. Worse, it can even > >change from supported to not supported. > >> Do you expect everyone to disable multithreading "just in case"? > >Buffer the last n bits of data to be able to restart decoding? > > > >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. 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. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
