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

[wm4]

On Mon, 09 Mar 2015 18:56:57 +0100
Reimar Döffinger <Reimar.Doeffinger at gmx.de> wrote:

> On 9 March 2015 15:28:48 CET, Hendrik Leppkes <h.leppkes at gmail.com> wrote:
> >On Mon, Mar 9, 2015 at 1:50 PM, Reimar Döffinger
> ><Reimar.Doeffinger at gmx.de> wrote:
> >> On 9 March 2015 13:34:24 CET, Hendrik Leppkes <h.leppkes at gmail.com>
> >wrote:
> >>>On Mon, Mar 9, 2015 at 7:38 AM, Rainer Hochecker
> >>><fernetmenta at 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.