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