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

2015-03-11 Thread Reimar Döffinger
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.

2015-03-11 Thread Reimar Döffinger


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.

2015-03-11 Thread wm4
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.

2015-03-10 Thread Reimar Döffinger
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.

2015-03-10 Thread wm4
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.

2015-03-09 Thread Rainer Hochecker
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.

2015-03-09 Thread Hendrik Leppkes
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.

2015-03-09 Thread Michael Niedermayer
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.

2015-03-09 Thread Reimar Döffinger
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.

2015-03-09 Thread Hendrik Leppkes
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.

2015-03-09 Thread Hendrik Leppkes
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.

2015-03-09 Thread Reimar Döffinger
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.

2015-03-09 Thread Hendrik Leppkes
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.

2015-03-09 Thread Reimar Döffinger
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.

2015-03-08 Thread Rainer Hochecker
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.

2015-03-08 Thread Reimar Döffinger
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.

2015-03-08 Thread Rainer Hochecker
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.

2015-03-08 Thread Reimar Döffinger
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.

2015-03-08 Thread Rainer Hochecker
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