Re: [FFmpeg-devel] [PATCH] pthread: Fix ff_thread_get_formatissues when called outside frame decode.
On 09.03.2015, at 15:54, Hendrik Leppkes wrote: > > Of course avcodec shouldn't crash when you use it, but a patch to > disallow this combination would never be accepted by yourself and some > others that "like" this cheap (albeit wrong) method for fallback. I forgot to reply: of course I would accept a patch that returns PATCHWELCOME for HEVC if the alternative is that the code crashes and explodes into the users' face... Or just not advertise hwaccel if multi-threading is enabled. Breaking code that currently works like H.264 to disallow this I would indeed mind though. > So the only solution is to add the extra magic that makes it not > crash, and someone should produce a patch for that if their setup can > reproduce it. Though that as preferred by me indeed. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] pthread: Fix ff_thread_get_formatissues when called outside frame decode.
On 11.03.2015, at 12:34, wm4 wrote: > On Tue, 10 Mar 2015 18:02:12 +0100 > Reimar Döffinger wrote: 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. No disagreement here. That doesn't make any of the not working suggestions a solution though, and I don't find it appropriate to "attack" (ok, a bit exaggerated) people trying to make the code we have work for them. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] pthread: Fix ff_thread_get_formatissues when called outside frame decode.
On Tue, 10 Mar 2015 18:02:12 +0100 Reimar Döffinger wrote: > On 10.03.2015, at 12:10, wm4 wrote: > > > On Mon, 09 Mar 2015 18:56:57 +0100 > > Reimar Döffinger 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
Re: [FFmpeg-devel] [PATCH] pthread: Fix ff_thread_get_formatissues when called outside frame decode.
On 10.03.2015, at 12:10, wm4 wrote: > On Mon, 09 Mar 2015 18:56:57 +0100 > Reimar Döffinger 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
Re: [FFmpeg-devel] [PATCH] pthread: Fix ff_thread_get_formatissues when called outside frame decode.
On Mon, 09 Mar 2015 18:56:57 +0100 Reimar Döffinger wrote: > On 9 March 2015 15:28:48 CET, Hendrik Leppkes wrote: > >On Mon, Mar 9, 2015 at 1:50 PM, Reimar Döffinger > > wrote: > >> On 9 March 2015 13:34:24 CET, Hendrik Leppkes > >wrote: > >>>On Mon, Mar 9, 2015 at 7:38 AM, Rainer Hochecker > >>> wrote: > Reimar Döffinger 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
Re: [FFmpeg-devel] [PATCH] pthread: Fix?ff_thread_get_formatissues?when called outside frame decode.
Hendrik Leppkes gmail.com> writes: > > Just making the ff_thread_finish_setup call in hevc_frame_start > conditional on !hwaccel should do what the other patches did. > My code isn't setup to use this path, so someone that does should test > it and send it. > > - Hendrik > ___ I does not solve my particular problem which is all the pointers to hwaccel. flush_buffers triggers a return of all video surfaces back to application but application can't terminate the hw decoder because ffmpeg has still pointers to hwaccel. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] pthread: Fix?ff_thread_get_formatissues?when called outside frame decode.
On Mon, Mar 9, 2015 at 11:06 PM, Michael Niedermayer wrote: > On Mon, Mar 09, 2015 at 06:38:18AM +, Rainer Hochecker wrote: >> Reimar Döffinger 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 > > from a quick look yes, this appears missing > can someone who can reprodeuce this problem test if adding such code > would fix it ? if yes please send a patch Just making the ff_thread_finish_setup call in hevc_frame_start conditional on !hwaccel should do what the other patches did. My code isn't setup to use this path, so someone that does should test it and send it. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] pthread: Fix?ff_thread_get_formatissues?when called outside frame decode.
On Mon, Mar 09, 2015 at 06:38:18AM +, Rainer Hochecker wrote: > Reimar Döffinger 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 from a quick look yes, this appears missing can someone who can reprodeuce this problem test if adding such code would fix it ? if yes please send a patch [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The real ebay dictionary, page 3 "Rare item" - "Common item with rare defect or maybe just a lie" "Professional" - "'Toy' made in china, not functional except as doorstop" "Experts will know" - "The seller hopes you are not an expert" signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] pthread: Fix ff_thread_get_formatissues when called outside frame decode.
On 9 March 2015 15:28:48 CET, Hendrik Leppkes wrote: >On Mon, Mar 9, 2015 at 1:50 PM, Reimar Döffinger > wrote: >> On 9 March 2015 13:34:24 CET, Hendrik Leppkes >wrote: >>>On Mon, Mar 9, 2015 at 7:38 AM, Rainer Hochecker >>> wrote: Reimar Döffinger 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
Re: [FFmpeg-devel] [PATCH] pthread: Fix ff_thread_get_formatissues when called outside frame decode.
On Mon, Mar 9, 2015 at 3:28 PM, Hendrik Leppkes wrote: > On Mon, Mar 9, 2015 at 1:50 PM, Reimar Döffinger > wrote: >> On 9 March 2015 13:34:24 CET, Hendrik Leppkes wrote: >>>On Mon, Mar 9, 2015 at 7:38 AM, Rainer Hochecker >>> wrote: Reimar Döffinger 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. > This allows a perfect and seamless change without requiring the hwaccel-mt > hack. In the end it also comes down to this: On Intel hardware, MT+HWAccel (at least DXVA2) is fundamentally broken, and unfixable in the current design. The problem is that concurrent access to the decoded surfaces from different threads simply does not work, and while avcodec locks the decoding threads out that only ever one is working, it does not know when the user code accesses the surface, and there is no way to tell it either. So anytime a frame is used as a reference and you try to process it in user code at the same time, decoding fails. This can be reproduced with ffmpeg CLI even. This reason is enough to consider the entire concept flawed, imho. Of course avcodec shouldn't crash when you use it, but a patch to disallow this combination would never be accepted by yourself and some others that "like" this cheap (albeit wrong) method for fallback. So the only solution is to add the extra magic that makes it not crash, and someone should produce a patch for that if their setup can reproduce it. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] pthread: Fix ff_thread_get_formatissues when called outside frame decode.
On Mon, Mar 9, 2015 at 1:50 PM, Reimar Döffinger wrote: > On 9 March 2015 13:34:24 CET, Hendrik Leppkes wrote: >>On Mon, Mar 9, 2015 at 7:38 AM, Rainer Hochecker >> wrote: >>> Reimar Döffinger 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. This allows a perfect and seamless change without requiring the hwaccel-mt hack. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] pthread: Fix ff_thread_get_formatissues when called outside frame decode.
On 9 March 2015 13:34:24 CET, Hendrik Leppkes wrote: >On Mon, Mar 9, 2015 at 7:38 AM, Rainer Hochecker > wrote: >> Reimar Döffinger 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? Hack things in get_format to trick FFmpeg into single threaded? All these have been tried and didn't work. (Kind of) supporting frame multithreading with hwaccel in contrast has worked and is convenient to our users. Unless you have a simple solution to these real world problems I very much think supporting it is a requirement. That is besides the fact that causing memory corruption it's not "not supporting" it but a bug. If it's not supported it should return an appropriate error. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] pthread: Fix ff_thread_get_formatissues when called outside frame decode.
On Mon, Mar 9, 2015 at 7:38 AM, Rainer Hochecker wrote: > Reimar Döffinger 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! - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] pthread: Fix ff_thread_get_formatissues when called outside frame decode.
On 09.03.2015, at 07:38, Rainer Hochecker wrote: > Reimar Döffinger 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? As you get green frames it does not really "work". It might simply be that setting it breaks decoding of the first frames and thus the code causing the issues is never executed. > 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? Mostly I think that I don't have enough information by far, someone will have to do proper debugging. And as long as this is a Windows-only issue very few people will be able to help. But the fact that my previous patch worked for me despite the major bug suggests that HEVC does not call the can_start function properly. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] pthread: Fix ff_thread_get_formatissues when called outside frame decode.
Reimar Döffinger 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? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] pthread: Fix ff_thread_get_formatissues when called outside frame decode.
On 08.03.2015, at 22:56, Rainer Hochecker wrote: > Reimar Döffinger gmx.de> writes: > > > I have tested this with Kodi. Works with sw decoding. With DXVA it crashes, > looks like heap corruption or the like. > setting thread_safe_callbacks = 1 cures the issue but I get some green > frames at start of playback. 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? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] pthread: Fix ff_thread_get_formatissues when called outside frame decode.
Reimar Döffinger gmx.de> writes: I have tested this with Kodi. Works with sw decoding. With DXVA it crashes, looks like heap corruption or the like. setting thread_safe_callbacks = 1 cures the issue but I get some green frames at start of playback. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] pthread: Fix ff_thread_get_formatissues when called outside frame decode.
On 08.03.2015, at 19:15, Rainer Hochecker wrote:
> Reimar Döffinger gmx.de> writes:
>
> I tried this patch with Kodi but did not get very far.
>
> int ff_thread_can_start_frame(AVCodecContext *avctx)
> {
>PerThreadContext *p = avctx->internal->thread_ctx;
>if (avctx->active_thread_type&FF_THREAD_FRAME)
>return 0;
>av_assert0(!p->main_thread);
>
> It hit this assert and call stack showed avformat_find_stream_info
This was the buggy first version, please see patch from march 2nd.
I have another fix locally that also fixes potential hangs with corrupted
streams in addition, but the newer version should work.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] pthread: Fix ff_thread_get_formatissues when called outside frame decode.
Reimar Döffinger gmx.de> writes:
I tried this patch with Kodi but did not get very far.
int ff_thread_can_start_frame(AVCodecContext *avctx)
{
PerThreadContext *p = avctx->internal->thread_ctx;
if (avctx->active_thread_type&FF_THREAD_FRAME)
return 0;
av_assert0(!p->main_thread);
It hit this assert and call stack showed avformat_find_stream_info
How can I help progressing this. I want to run hevc frame threaded but
without thread_safe_callback because of DXVA.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
