Re: [FFmpeg-devel] [PATCH] lavformat/utils: Fix a memleak that st->codec->hw_frames_ctx

[Chao Liu]

On Sun, Jan 22, 2017 at 9:03 PM, Mark Thompson  wrote:

> On 20/01/17 02:06, Huang, Zhengxu wrote:
> > From 9ceb2ac6a89246f2e686eb3ad3448fbaff5328f7 Mon Sep 17 00:00:00 2001
> > From: Zhengxu 
> > Date: Fri, 13 Jan 2017 10:33:05 +0800
> > Subject: [PATCH] lavformat/utils: Fix a memleak that
> st->codec->hw_frames_ctx
> >  is not released.
> >
> > Signed-off-by: ChaoX A Liu 
> > Signed-off-by: Huang, Zhengxu 
> > Signed-off-by: Andrew, Zhang 
> > ---
> >  libavformat/utils.c | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/libavformat/utils.c b/libavformat/utils.c
> > index d5dfca7..cadec15 100644
> > --- a/libavformat/utils.c
> > +++ b/libavformat/utils.c
> > @@ -4127,6 +4127,7 @@ static void free_stream(AVStream **pst)
> >  FF_DISABLE_DEPRECATION_WARNINGS
> >  av_freep(&st->codec->extradata);
> >  av_freep(&st->codec->subtitle_header);
> > +av_buffer_unref(&st->codec->hw_frames_ctx);
> >  av_freep(&st->codec);
> >  FF_ENABLE_DEPRECATION_WARNINGS
> >  #endif
> > --
> > 1.8.3.1
> >
>
> As stated elsewhere, this should never happen in a sane program
> (AVStream.codec was deprecated before AVCodecContext.hw_frames_ctx was
> introduced), but I admit that ffmpeg.c cannot be said to be a sane program.
>
> I think the patch is probably ok, but it is very difficult to tell.  Why
> doesn't the code here already call avcodec_free_context() here to free
> st->codec properly, including unreffing hw_frames_ctx?  I imagine there is
> some crazy reason for this (some fields have been copied somewhere else,
> maybe?), and without knowing that I don't think this patch should be
> applied.
>
> So, I mostly agree with Hendrik that it is probably better to fix ffmpeg.c
> to not cause the problem in the first place rather than changing this
> deprecated code in lavf.
>
> Thanks,
>
> - Mark


OK. Let's end this topic till we find out a graceful way to fix it.

Thanks for all your patient explaining.

Regards,
Chao
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavformat/utils: Fix a memleak that st->codec->hw_frames_ctx

[Chao Liu]

Have you ever used valgrind? Please just run the command below:
valgrind --leak-check=full --log-file=out.log ffmpeg -hwaccel qsv
-qsv_device /dev/dri/renderD128 -c:v h264_qsv -i a.h264 -c:v h264_qsv -b:v
2M  -y out.h264

See line 3323 of ffmpeg.c,
ret = avcodec_copy_context(ost->st->codec, ost->enc_ctx);
and see what have been done in avcodec_copy_context:
if (src->hw_frames_ctx) {
dest->hw_frames_ctx = av_buffer_ref(src->hw_frames_ctx);
if (!dest->hw_frames_ctx)
goto fail;
}
However, that is not freed when calling avformat_free_context.

On Fri, Jan 20, 2017 at 4:47 PM, wm4  wrote:

> On Fri, 20 Jan 2017 10:06:50 +0800
> "Huang, Zhengxu"  wrote:
>
> > From 9ceb2ac6a89246f2e686eb3ad3448fbaff5328f7 Mon Sep 17 00:00:00 2001
> > From: Zhengxu 
> > Date: Fri, 13 Jan 2017 10:33:05 +0800
> > Subject: [PATCH] lavformat/utils: Fix a memleak that
> st->codec->hw_frames_ctx
> >  is not released.
> >
> > Signed-off-by: ChaoX A Liu 
> > Signed-off-by: Huang, Zhengxu 
> > Signed-off-by: Andrew, Zhang 
> > ---
> >  libavformat/utils.c | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/libavformat/utils.c b/libavformat/utils.c
> > index d5dfca7..cadec15 100644
> > --- a/libavformat/utils.c
> > +++ b/libavformat/utils.c
> > @@ -4127,6 +4127,7 @@ static void free_stream(AVStream **pst)
> >  FF_DISABLE_DEPRECATION_WARNINGS
> >  av_freep(&st->codec->extradata);
> >  av_freep(&st->codec->subtitle_header);
> > +av_buffer_unref(&st->codec->hw_frames_ctx);
> >  av_freep(&st->codec);
> >  FF_ENABLE_DEPRECATION_WARNINGS
> >  #endif
>
> What triggers this? In a sane world this should never ever happen.
> ___
> 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] is it possible that avfilter graph updates its setting in realtime?

[Chao Liu]

On Mon, Oct 24, 2016 at 11:24 PM, qw  wrote:

> Hi,
>
>
> I have one question about some rare usage for avfilter graph:
>
>
> Sometimes, I want to change the setting in avfilter graph. For example,
> fps filter is used to set output frame rate, and it's expected that fps can
> be changed in accordance to real needs. Sometimes, fps is set to 25, and
> later 15 as network bandwidth is not good. Is it possible that avfilter
> graph updates its setting in realtime, such as fps in fps filter, and
> widthxheight in scale filter?
>
(You probably want to send such questions to libav-u...@ffmpeg.org instead.)
I guess you are looking for avfilter_graph_send_command.
Unfortunately, "fps" filter doesn't provide any command you can use.
"scale" does have it, see here
.


>
> Thanks!
>
>
> Regards
>
>
> Andrew
> ___
> 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 1/5] lavc : yami : add libyami decoder/encoder

[Chao Liu]

On Wed, Sep 28, 2016 at 3:23 PM, Mark Thompson  wrote:

> On 28/09/16 22:57, Chao Liu wrote:
> > BTW, is there any plan to support VP8 with vaapi hwaccel?
>
> No plan; already done: <https://git.libav.org/?p=libav.git;a=commit;h=
> a9fb134730da1f9642eb5a2baa50943b8a4aa245>.
>
Cool. Thanks!
What about VP8 encoder?

>
> (Depends on the changed decode infrastructure though, so it won't
> cherry-pick easily.)


> - Mark
>
> ___
> 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 1/5] lavc : yami : add libyami decoder/encoder

[Chao Liu]

On Wed, Sep 28, 2016 at 2:45 PM, wm4  wrote:

> On Wed, 28 Sep 2016 12:18:38 -0700
> Chao Liu  wrote:
>
> > On Sat, Sep 24, 2016 at 6:18 AM, wm4  wrote:
> >
> > > On Sat, 24 Sep 2016 02:34:56 +0200
> > > Michael Niedermayer  wrote:
> > >
> > > > On Mon, Aug 15, 2016 at 04:22:33PM +0800, Jun Zhao wrote:
> > > > > add libyami decoder/encoder/vpp in ffmpeg, about build step,
> > > > > please refer to the link: https://github.com/01org/
> > > ffmpeg_libyami/wiki/Build
> > > >
> > > > >  Makefile   |1
> > > > >  configure  |   27 ++
> > > > >  ffmpeg.c   |4
> > > > >  ffmpeg.h   |1
> > > > >  ffmpeg_libyami.c   |   85 ++
> > > > >  libavcodec/Makefile|8
> > > > >  libavcodec/allcodecs.c |6
> > > > >  libavcodec/libyami.cpp |  429 ++
> +
> > > > >  libavcodec/libyami.h   |   59 
> > > > >  libavcodec/libyami_dec.cpp |  527 ++
> > > +
> > > > >  libavcodec/libyami_dec.h   |   56 
> > > > >  libavcodec/libyami_enc.cpp |  551 ++
> > > +++
> > > > >  libavcodec/libyami_enc.h   |   70 +
> > > > >  libavutil/pixdesc.c|4
> > > > >  libavutil/pixfmt.h |5
> > > > >  15 files changed, 1833 insertions(+)
> > > > > d5ebbaa497e6f36026a4482dc6e0f26b370561b5
> 0001-lavc-yami-add-libyami-
> > > decoder-encoder.patch
> > > > > From 7147fdb375cb7241d69823d8b9b6e94f66df3a32 Mon Sep 17 00:00:00
> 2001
> > > > > From: Jun Zhao 
> > > > > Date: Mon, 15 Aug 2016 15:36:14 +0800
> > > > > Subject: [[PATCH] 1/5] lavc : yami : add libyami decoder/encoder.
> > > >
> > > > it seems people are not in favor of this patchset, judging from this
> > > > thread.
> > > > If you are interrested in maintaining this code externally as a patch
> > > > or git repository, then please add some reasonable link/mention to
> > > > some page on https://trac.ffmpeg.org/wiki so users are aware of its
> > > > existence and can find it
> > > >
> > > > If you belive thats incorret and people in fact majorly support this
> > > > patchset then you can also start a vote of course.
> > > >
> > > > ill mark this patchset as rejected on patchwork as that seems the
> > > > de-facto current situation
> > > >
> > >
> > > From one person who tried to use it (and who's also in the list), I
> > > heard that ffmpeg native vaapi decoding/encoding works better for him.
> > >
> > I don't know how he made that conclusion. Maybe he only uses the command
> > line?
> > We are building a product using ffmpeg C interface. For me, hwaccel is
> way
> > too complicated to use. IIUC, I have to copy thousand lines of code from
> > ffmpeg_*.c to use it ...
>
> Much less with the latest Libav changes once they're merged in FFmpeg.
> Only at most 200 lines (all pretty trivial glue code, much of that
> just to hook it up to ffmpeg.c-specifics). The new code will remove the
> requirement to manually create the VAAPI context in the decoding case.
>
Oh, that's great! When do you think it'll be ready? Cannot wait to give it
a try!

>
> Since libyami requires usinf weird libyami-specific buffers instead of
> vaapi surfaces, it's unlikely that libyami could profit from further
> developments, such as vaapi filters within libavfilter. Unless someone
> changes the libyami wrapper to input/output native vaapi surfaces.
>
> Also, there were issues that were never fixed in the libyami wrapper.
>
> > With this patch, it's trivial to switch between codecs like qsv_h264,
> > libyami_h264, libyami_vp8.
> >
> > We have been trying different hardware acceleration solutions in our
> > product. So far, QSV works best for us.
> > However, QSV itself has a lot of problems, like too much work to use it
> > under Linux, quite a few critical bugs, no support for VP8.
> > Even worse, it only supports latest CPUs. We cannot use it in production
> > because we don't know when they'll stop supporting our hardware, which'll
> > leave us no option.
> >
> > So far, libyami looks like the best options for people like us. If you
> guys
> > in the end reject this patch, we'll have to patch it ourselves. That'll
> be
> > awful. I hope we won't need to do that..
>
> So it's better if _we_ have to maintain code that is redundant to our
> "proper" APIs, and that has a bunch of issues the patch submitters
> don't want to fix? Sounds wrong to me.
>
I didn't know the unfixed issues of libyami, which you mentioned above.
I agree that if you could make hwaccels easy to use, this patch is not very
useful.
BTW, is there any plan to support VP8 with vaapi hwaccel?

> ___
> 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 1/5] lavc : yami : add libyami decoder/encoder

[Chao Liu]

On Sat, Sep 24, 2016 at 6:18 AM, wm4  wrote:

> On Sat, 24 Sep 2016 02:34:56 +0200
> Michael Niedermayer  wrote:
>
> > On Mon, Aug 15, 2016 at 04:22:33PM +0800, Jun Zhao wrote:
> > > add libyami decoder/encoder/vpp in ffmpeg, about build step,
> > > please refer to the link: https://github.com/01org/
> ffmpeg_libyami/wiki/Build
> >
> > >  Makefile   |1
> > >  configure  |   27 ++
> > >  ffmpeg.c   |4
> > >  ffmpeg.h   |1
> > >  ffmpeg_libyami.c   |   85 ++
> > >  libavcodec/Makefile|8
> > >  libavcodec/allcodecs.c |6
> > >  libavcodec/libyami.cpp |  429 +++
> > >  libavcodec/libyami.h   |   59 
> > >  libavcodec/libyami_dec.cpp |  527 ++
> +
> > >  libavcodec/libyami_dec.h   |   56 
> > >  libavcodec/libyami_enc.cpp |  551 ++
> +++
> > >  libavcodec/libyami_enc.h   |   70 +
> > >  libavutil/pixdesc.c|4
> > >  libavutil/pixfmt.h |5
> > >  15 files changed, 1833 insertions(+)
> > > d5ebbaa497e6f36026a4482dc6e0f26b370561b5  0001-lavc-yami-add-libyami-
> decoder-encoder.patch
> > > From 7147fdb375cb7241d69823d8b9b6e94f66df3a32 Mon Sep 17 00:00:00 2001
> > > From: Jun Zhao 
> > > Date: Mon, 15 Aug 2016 15:36:14 +0800
> > > Subject: [[PATCH] 1/5] lavc : yami : add libyami decoder/encoder.
> >
> > it seems people are not in favor of this patchset, judging from this
> > thread.
> > If you are interrested in maintaining this code externally as a patch
> > or git repository, then please add some reasonable link/mention to
> > some page on https://trac.ffmpeg.org/wiki so users are aware of its
> > existence and can find it
> >
> > If you belive thats incorret and people in fact majorly support this
> > patchset then you can also start a vote of course.
> >
> > ill mark this patchset as rejected on patchwork as that seems the
> > de-facto current situation
> >
>
> From one person who tried to use it (and who's also in the list), I
> heard that ffmpeg native vaapi decoding/encoding works better for him.
>
I don't know how he made that conclusion. Maybe he only uses the command
line?
We are building a product using ffmpeg C interface. For me, hwaccel is way
too complicated to use. IIUC, I have to copy thousand lines of code from
ffmpeg_*.c to use it ...
With this patch, it's trivial to switch between codecs like qsv_h264,
libyami_h264, libyami_vp8.

We have been trying different hardware acceleration solutions in our
product. So far, QSV works best for us.
However, QSV itself has a lot of problems, like too much work to use it
under Linux, quite a few critical bugs, no support for VP8.
Even worse, it only supports latest CPUs. We cannot use it in production
because we don't know when they'll stop supporting our hardware, which'll
leave us no option.

So far, libyami looks like the best options for people like us. If you guys
in the end reject this patch, we'll have to patch it ourselves. That'll be
awful. I hope we won't need to do that..

>
> So there's probably no reason to use this patch at all.
> ___
> 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] h264_qsv decoder speed

[Chao Liu]

On Thu, Aug 18, 2016 at 7:50 AM, Moritz Barsnick  wrote:

> On Wed, Aug 17, 2016 at 23:13:13 +0100, Mark Thompson wrote:
> > > The test video was captured from a 3MP(2048x1536) camera. The commands
> I
> > > used:
> > > -  ffmpeg -c:v h264_qsv -async_depth 10 -i test.h264 -c:v rawvideo -f
> null
> > > /dev/null
> > > -  sample_decode h264 -i test.h264
> > > Both uses 100% cpu (a full core). ffmpeg got 170FPS. sample_decode got
> > > 370FPS.
>
> > I think in both cases your speed bound must be on something other
> > than the decode, because the hardware goes a lot faster than either
> > of those for me.
>
> Don't explicitly convert to rawvideo, the null muxer recently defaults
> to wrapped_avframe, which is a tad bit faster:
>
> $ ffmpeg -c:v h264_qsv -async_depth 10 -i test.h264 -f null /dev/null

Right. rawvideo was causing the problem. However, even with this command.
ffmpeg is still slow than sample_decode. 240fps VS 370fps.
The interesting thing is that if I set async_depth to 1, both sample_decode
and ffmpeg got only 100fps.

>
> Actually, you may want to rule out too much influence from the output
> section of the chain by using "-c copy", if possible:
>
> $ ffmpeg -c:v h264_qsv -async_depth 10 -i test.h264 -c copy -f null
> /dev/null
>
Well, ffmpeg is smart enough to figure out it doesn't need to do anything
here and return immediately..
I don't think demuxer matters here, since samle_decode needs to demux too.

>
> In addition to this, do benchmark the demuxing/muxing overhead for
> comparison, without HW decoding. (Yes this is a different demuxer, but
> just in order to see.):
>
> $ ffmpeg -i test.h264 -c copy -f null /dev/null
>
> (And drop audio processing using "-an". Not applicable in this case.)
>
> Moritz
> ___
> 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] h264_qsv decoder speed

[Chao Liu]

On Wed, Aug 17, 2016 at 4:41 PM, Andy Furniss  wrote:

> Mark Thompson wrote:
>
>> On 17/08/16 20:47, Chao Liu wrote:
>>
>>> Hi there,
>>> I compared h264_qsv decoder from ffmpeg to intel media sdk sample_decode.
>>> There is pretty big speed gap. I wonder whether I did sth. wrong or there
>>> are really some problems with ffmpeg's implementation..
>>>
>>> The test video was captured from a 3MP(2048x1536) camera. The commands I
>>> used:
>>> -  ffmpeg -c:v h264_qsv -async_depth 10 -i test.h264 -c:v rawvideo -f
>>> null
>>> /dev/null
>>> -  sample_decode h264 -i test.h264
>>> Both uses 100% cpu (a full core). ffmpeg got 170FPS. sample_decode got
>>> 370FPS.
>>>
>>> I haven't got time debugging into this. Sending this out to see whether
>>> you
>>> guys might have sth. in mind..
>>>
>>
>> I think in both cases your speed bound must be on something other than
>> the decode, because the hardware goes a lot faster than either of those for
>> me.  Perhaps you are downloading the all of the output frames to normal
>> memory in order to write them to a null device output, and one of the cases
>> is doing that less efficiently somehow?
>>
>
> Only tested with AMD UVD, but unless you use -pix_fmt nv12 you will also
> get cpu load from ffmpeg doing nv12 -> yuv420p conversion.

I tried  ffmpeg -c:v h264_qsv -async_depth 4 -i test.h264 -pix_fmt nv12 -f
null /dev/null
I couldn't tell any difference.

>
>
>
>> Using vaapi on a low-power Haswell mobile chip (i.e. the same Quick Sync
>> hardware that libmfx uses) decodes a single 2048x1536 stream at around
>> 800fps with less than 50% CPU for me.
>>
>> - Mark
>>
>>
>> (My command to compare is:
>>
>> ./ffmpeg_g -vaapi_device /dev/dri/renderD128 -hwaccel vaapi
>> -hwaccel_output_format vaapi -i input.mp4 -an -vf
>> 'format=nv12|vaapi,hwupload' -f null -
>>
>
> Oh nice, I always wondered if there was a way to bench without copy back.
>
>
>
>> The nasty filtering there is contrived to do nothing, even with the
>> inconvenient stream reinitialisation.  I think libmfx might also work
>> somehow with "-c:v h264_qsv -hwaccel qsv", but I'm not sure and I don't
>> have anything to try it on right now.)
>>
>
> ___
> 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] h264_qsv decoder speed

[Chao Liu]

On Wed, Aug 17, 2016 at 3:13 PM, Mark Thompson  wrote:

> On 17/08/16 20:47, Chao Liu wrote:
> > Hi there,
> > I compared h264_qsv decoder from ffmpeg to intel media sdk sample_decode.
> > There is pretty big speed gap. I wonder whether I did sth. wrong or there
> > are really some problems with ffmpeg's implementation..
> >
> > The test video was captured from a 3MP(2048x1536) camera. The commands I
> > used:
> > -  ffmpeg -c:v h264_qsv -async_depth 10 -i test.h264 -c:v rawvideo -f
> null
> > /dev/null
> > -  sample_decode h264 -i test.h264
> > Both uses 100% cpu (a full core). ffmpeg got 170FPS. sample_decode got
> > 370FPS.
> >
> > I haven't got time debugging into this. Sending this out to see whether
> you
> > guys might have sth. in mind..
>
> I think in both cases your speed bound must be on something other than the
> decode, because the hardware goes a lot faster than either of those for
> me.  Perhaps you are downloading the all of the output frames to normal
> memory in order to write them to a null device output, and one of the cases
> is doing that less efficiently somehow?
>
You are right. QSV does output video to system memory by default.
For sample_decode, I could turn that off and got 700 FPS (using a 4th gen
mobile i3, with HD 4400). This is very close to your number.
  sample_decode h264 -vaapi -i test.h264
So I assume the number from sample_decode makes sense.

I just found the parameter "-c:v rawvideo" affects the performance a lot
(why?). Using the following command, I could get 240fps. (I changed
async_depth to 4 because this is what sample_code uses.)
  ffmpeg -c:v h264_qsv -async_depth 4 -i ../../4shome2/go/orig.h264 -f
null -
So the speed difference is 370 (sample_decode) VS 240 (ffmpeg qsv)

>
> Using vaapi on a low-power Haswell mobile chip (i.e. the same Quick Sync
> hardware that libmfx uses) decodes a single 2048x1536 stream at around
> 800fps with less than 50% CPU for me.
>
> - Mark
>
>
> (My command to compare is:
>
> ./ffmpeg_g -vaapi_device /dev/dri/renderD128 -hwaccel vaapi
> -hwaccel_output_format vaapi -i input.mp4 -an -vf
> 'format=nv12|vaapi,hwupload' -f null -
>
> The nasty filtering there is contrived to do nothing, even with the
> inconvenient stream reinitialisation.  I think libmfx might also work
> somehow with "-c:v h264_qsv -hwaccel qsv", but I'm not sure and I don't
> have anything to try it on right now.)


> ___
> 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

[FFmpeg-devel] h264_qsv decoder speed

[Chao Liu]

Hi there,
I compared h264_qsv decoder from ffmpeg to intel media sdk sample_decode.
There is pretty big speed gap. I wonder whether I did sth. wrong or there
are really some problems with ffmpeg's implementation..

The test video was captured from a 3MP(2048x1536) camera. The commands I
used:
-  ffmpeg -c:v h264_qsv -async_depth 10 -i test.h264 -c:v rawvideo -f null
/dev/null
-  sample_decode h264 -i test.h264
Both uses 100% cpu (a full core). ffmpeg got 170FPS. sample_decode got
370FPS.

I haven't got time debugging into this. Sending this out to see whether you
guys might have sth. in mind..
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/5] lavc : yami : add libyami decoder/encoder

[Chao Liu]

On Tue, Aug 16, 2016 at 11:27 AM, Mark Thompson  wrote:

> On 16/08/16 03:44, Jun Zhao wrote:
> >
> >
> > On 2016/8/16 10:14, Chao Liu wrote:
> >> On Mon, Aug 15, 2016 at 6:00 PM, Jun Zhao  wrote:
> >>
> >>>
> >>>
> >>> On 2016/8/16 1:48, Jean-Baptiste Kempf wrote:
> >>>> On 15 Aug, Hendrik Leppkes wrote :
> >>>>>> On Mon, Aug 15, 2016 at 10:22 AM, Jun Zhao 
> >>> wrote:
> >>>>>>>> add libyami decoder/encoder/vpp in ffmpeg, about build step,
> >>>>>>>> please refer to the link: https://github.com/01org/
> >>> ffmpeg_libyami/wiki/Build
> >>>>>>>>
> >>>>>>
> >>>>>> We've had patches for yami before, and they were not applied because
> >>>>>> many developers did not agree with adding more wrappers for the same
> >>>>>> hardware decoders which we already support.
> >>>>>> Please refer to the discussion in this thread:
> >>>>>> https://ffmpeg.org/pipermail/ffmpeg-devel/2015-January/167388.html
> >>>>>>
> >>>>>> The concerns and reasons brought up there should not really have
> >>> changed.
> >>>> I still object very strongly against yami.
> >>>>
> >>>> It is a library that does not bring much that we could not do
> ourselves,
> >>>> it duplicates a lot of our code, it is the wrong level of abstraction
> >>>> for libavcodec, it is using a bad license and there is no guarantee of
> >>>> maintainership in the future.
> >>>
> >>> I know the worry after read the above thread.For Intel GPU HW
> accelerate
> >>> decode/encode,
> >>> now have 3 options in ffmpeg:
> >>>
> >>> 1. ffmpeg and QSV (Media SDK)
> >>> 2. ffmpeg vaapi hw accelerate decoder/native vaapi encoder
> >>> 3. ffmpeg and libyami
> >>>
> >> Sorry for this little diversion: what are the differences between QSV
> and
> >> vaapi?
> >> My understanding is that QSV has better performance, while vaapi
> supports
> >> more decoders / encoders. Is that correct?
> >> It would be nice if there are some data showing the speed of these HW
> >> accelerated decoders / encoders.
> >
> > QSV has better performance is right, but libyami have more
> decoders/encoders than
> > vaapi hw accel decoder/encoder. :)
> >
> > According our profile, the speed of QSV/Libyami/vaapi-hw accel decoder
> and native
> > vaapi encoder are: QSV > ffmpeg and libyami > vaapi-hw accel decoder and
> native
> > vaapi encoder
>
> In a single ffmpeg process I believe that result, but I'm not sure that
> it's the question you really want to ask.
>
> The lavc VAAPI hwaccel/encoder are both single-threaded, and while they
> overlap operations internally where possible the single-threadedness of
> ffmpeg (the program) itself means that they will not achieve the maximum
> performance.  If you really want to compare the single-transcode
> performance like this then you will want to make a test program which does
> the threading outside lavc.
>
>
> In any case, I don't believe that the single generic transcode setup is a
> use that many people are interested in (beyond testing to observe that
> hardware encoders kindof suck relative to libx264, then using that instead).
>
> To my mind, the cases where it is interesting to use VAAPI (or really any
> hardware encoder on a normal PC-like system) are:
>
> * You want to do /lots/ of simultaneous transcodes in some sort of server
> setup (often with some simple transformation, like a scale or codec
> change), and want to maximise the number you can do while maintaining some
> minimum level of throughput on each one.  You can benchmark this case for
> VAAPI by running lots of instances of ffmpeg, and I expect that the libyami
> numbers will be precisely equivalent because libyami is using VAAPI anyway
> and the hardware is identical.
>
Our use case is similar to this one. In one process, we have multiple
threads that decode the input video streams, process the decoded frames and
encode.
To process the frames efficiently, we would like the decoded frames to be
of some format like yuv420p, which has a separate luminance channel.
We would like to use whatever hardware accelerations that are available. So
far, we have only tried QSV. It works, with some problems though, like no
support for VP8, only available for relatively new intel CPUs.
I just took a

Re: [FFmpeg-devel] [PATCH 1/5] lavc : yami : add libyami decoder/encoder

[Chao Liu]

On Tue, Aug 16, 2016 at 1:06 AM, Jun Zhao  wrote:

>
>
> On 2016/8/16 15:37, Chao Liu wrote:
> > On Mon, Aug 15, 2016 at 7:44 PM, Jun Zhao  wrote:
> >
> >>
> >>
> >> On 2016/8/16 10:14, Chao Liu wrote:
> >>> On Mon, Aug 15, 2016 at 6:00 PM, Jun Zhao  wrote:
> >>>
> >>>>
> >>>>
> >>>> On 2016/8/16 1:48, Jean-Baptiste Kempf wrote:
> >>>>> On 15 Aug, Hendrik Leppkes wrote :
> >>>>>>> On Mon, Aug 15, 2016 at 10:22 AM, Jun Zhao 
> >>>> wrote:
> >>>>>>>>> add libyami decoder/encoder/vpp in ffmpeg, about build step,
> >>>>>>>>> please refer to the link: https://github.com/01org/
> >>>> ffmpeg_libyami/wiki/Build
> >>>>>>>>>
> >>>>>>>
> >>>>>>> We've had patches for yami before, and they were not applied
> because
> >>>>>>> many developers did not agree with adding more wrappers for the
> same
> >>>>>>> hardware decoders which we already support.
> >>>>>>> Please refer to the discussion in this thread:
> >>>>>>> https://ffmpeg.org/pipermail/ffmpeg-devel/2015-January/167388.html
> >>>>>>>
> >>>>>>> The concerns and reasons brought up there should not really have
> >>>> changed.
> >>>>> I still object very strongly against yami.
> >>>>>
> >>>>> It is a library that does not bring much that we could not do
> >> ourselves,
> >>>>> it duplicates a lot of our code, it is the wrong level of abstraction
> >>>>> for libavcodec, it is using a bad license and there is no guarantee
> of
> >>>>> maintainership in the future.
> >>>>
> >>>> I know the worry after read the above thread.For Intel GPU HW
> accelerate
> >>>> decode/encode,
> >>>> now have 3 options in ffmpeg:
> >>>>
> >>>> 1. ffmpeg and QSV (Media SDK)
> >>>> 2. ffmpeg vaapi hw accelerate decoder/native vaapi encoder
> >>>> 3. ffmpeg and libyami
> >>>>
> >>> Sorry for this little diversion: what are the differences between QSV
> and
> >>> vaapi?
> >>> My understanding is that QSV has better performance, while vaapi
> supports
> >>> more decoders / encoders. Is that correct?
> >>> It would be nice if there are some data showing the speed of these HW
> >>> accelerated decoders / encoders.
> >>
> >> QSV has better performance is right, but libyami have more
> >> decoders/encoders than
> >> vaapi hw accel decoder/encoder. :)
> >>
> >> According our profile, the speed of QSV/Libyami/vaapi-hw accel decoder
> and
> >> native
> >> vaapi encoder are: QSV > ffmpeg and libyami > vaapi-hw accel decoder and
> >> native
> >> vaapi encoder
> >>
> >>>
> >>>>
> >>>> And I know the guys prefer option 2 than 3, but I have a little
> >> question,
> >>>> what's the
> >>>> difference about ffmpeg/libyami and the other external codec
> library(e,g
> >>>> openh264,
> >>>> videotoolbox...)?
> >>>>
> >>> Is 2 available in ffmpeg today or is it sth. planned?
> >>>
> >>
> >> Option 2 is available today :), I think the wiki page (
> >> https://wiki.libav.org/Hardware/vaapi)
> >> is good refer to for option 2, if you want to try. :)
> >
> > Thanks. But that's for libav. These decoders and encoders are not
> available
> > for ffmpeg.
> >
>
> I can run ffmpeg vaapi hw accel decoder and vaapi encoder with zero-copy
> mode for
> transcode case, I don't know why you can't succeed.
>
> Do you re-build intel-driver/libva with master branch?
>
Right. I am using an old version. There is an h264_vaapi encoder in the
latest release.

> ___
> 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 1/5] lavc : yami : add libyami decoder/encoder

[Chao Liu]

On Mon, Aug 15, 2016 at 10:22 PM, Jun Zhao  wrote:

>
>
> On 2016/8/16 11:07, Timothy Gu wrote:
> > Hi
> >
> > On Mon, Aug 15, 2016 at 7:44 PM Jun Zhao  wrote:
> >
> >>
> >>
> >> On 2016/8/16 10:14, Chao Liu wrote:
> >>> Sorry for this little diversion: what are the differences between QSV
> and
> >>> vaapi?
> >>> My understanding is that QSV has better performance, while vaapi
> supports
> >>> more decoders / encoders. Is that correct?
> >>> It would be nice if there are some data showing the speed of these HW
> >>> accelerated decoders / encoders.
> >>
> >> QSV has better performance is right, but libyami have more
> >> decoders/encoders than
> >> vaapi hw accel decoder/encoder. :)
> >>
> >
> > I am not sure where you got this information.
> >
> > On Intel platforms they all use the same chip. Because VAAPI supports
> more
> > than just Intel platforms, VAAPI supports all codecs libyami and QSV
> > support, if not more.
> >
> > QSV works on both Windows and Linux, although it is a pain to set up a
> > Linux QSV environment (you have to have the right distro, right kernel,
> > etc.).
> >
> >
>
> I means ffmpeg_VAAPI hw accel decoder/native VAAPI encoder, not the VAAPI
> as
> interface.
>
> >>
> >> According our profile, the speed of QSV/Libyami/vaapi-hw accel decoder
> and
> >> native
> >> vaapi encoder are: QSV > ffmpeg and libyami > vaapi-hw accel decoder and
> >> native
> >> vaapi encoder
> >>
> >
> > You didn't mention _how_ you profiled things, and for HW encoding
> different
> > ways of profiling can cause wildly different results. If for example you
> > are not doing zero-copy VAAPI operations, you are inherently giving the
> > other two methods an edge.
> >
>
> I used the ffmpeg_QSV/ffmpeg_libyami/ffmpeg_vaapi to do zero-copy mode
> transcode with default setting as profile case.
>
Perhaps you could share your test environment settings and the results, so
others could repro and confirm what you said, which could make this patch
more appealing.
IIUC, there is no hardware accelerated encoder for VP8 in ffmpeg yet.
That's another value of this patch..

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

Re: [FFmpeg-devel] [PATCH 1/5] lavc : yami : add libyami decoder/encoder

[Chao Liu]

On Mon, Aug 15, 2016 at 7:44 PM, Jun Zhao  wrote:

>
>
> On 2016/8/16 10:14, Chao Liu wrote:
> > On Mon, Aug 15, 2016 at 6:00 PM, Jun Zhao  wrote:
> >
> >>
> >>
> >> On 2016/8/16 1:48, Jean-Baptiste Kempf wrote:
> >>> On 15 Aug, Hendrik Leppkes wrote :
> >>>>> On Mon, Aug 15, 2016 at 10:22 AM, Jun Zhao 
> >> wrote:
> >>>>>>> add libyami decoder/encoder/vpp in ffmpeg, about build step,
> >>>>>>> please refer to the link: https://github.com/01org/
> >> ffmpeg_libyami/wiki/Build
> >>>>>>>
> >>>>>
> >>>>> We've had patches for yami before, and they were not applied because
> >>>>> many developers did not agree with adding more wrappers for the same
> >>>>> hardware decoders which we already support.
> >>>>> Please refer to the discussion in this thread:
> >>>>> https://ffmpeg.org/pipermail/ffmpeg-devel/2015-January/167388.html
> >>>>>
> >>>>> The concerns and reasons brought up there should not really have
> >> changed.
> >>> I still object very strongly against yami.
> >>>
> >>> It is a library that does not bring much that we could not do
> ourselves,
> >>> it duplicates a lot of our code, it is the wrong level of abstraction
> >>> for libavcodec, it is using a bad license and there is no guarantee of
> >>> maintainership in the future.
> >>
> >> I know the worry after read the above thread.For Intel GPU HW accelerate
> >> decode/encode,
> >> now have 3 options in ffmpeg:
> >>
> >> 1. ffmpeg and QSV (Media SDK)
> >> 2. ffmpeg vaapi hw accelerate decoder/native vaapi encoder
> >> 3. ffmpeg and libyami
> >>
> > Sorry for this little diversion: what are the differences between QSV and
> > vaapi?
> > My understanding is that QSV has better performance, while vaapi supports
> > more decoders / encoders. Is that correct?
> > It would be nice if there are some data showing the speed of these HW
> > accelerated decoders / encoders.
>
> QSV has better performance is right, but libyami have more
> decoders/encoders than
> vaapi hw accel decoder/encoder. :)
>
> According our profile, the speed of QSV/Libyami/vaapi-hw accel decoder and
> native
> vaapi encoder are: QSV > ffmpeg and libyami > vaapi-hw accel decoder and
> native
> vaapi encoder
>
> >
> >>
> >> And I know the guys prefer option 2 than 3, but I have a little
> question,
> >> what's the
> >> difference about ffmpeg/libyami and the other external codec library(e,g
> >> openh264,
> >> videotoolbox...)?
> >>
> > Is 2 available in ffmpeg today or is it sth. planned?
> >
>
> Option 2 is available today :), I think the wiki page (
> https://wiki.libav.org/Hardware/vaapi)
> is good refer to for option 2, if you want to try. :)

Thanks. But that's for libav. These decoders and encoders are not available
for ffmpeg.

>


> >>
> >> As I know Intel have 3 full time Libyami developers, so no guarantee
> maybe
> >> is wrong.:)
> >>
> >> Tks.
> >> ___
> >> 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
> >
> ___
> 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 1/5] lavc : yami : add libyami decoder/encoder

[Chao Liu]

On Mon, Aug 15, 2016 at 6:00 PM, Jun Zhao  wrote:

>
>
> On 2016/8/16 1:48, Jean-Baptiste Kempf wrote:
> > On 15 Aug, Hendrik Leppkes wrote :
> >> > On Mon, Aug 15, 2016 at 10:22 AM, Jun Zhao 
> wrote:
> >>> > > add libyami decoder/encoder/vpp in ffmpeg, about build step,
> >>> > > please refer to the link: https://github.com/01org/
> ffmpeg_libyami/wiki/Build
> >>> > >
> >> >
> >> > We've had patches for yami before, and they were not applied because
> >> > many developers did not agree with adding more wrappers for the same
> >> > hardware decoders which we already support.
> >> > Please refer to the discussion in this thread:
> >> > https://ffmpeg.org/pipermail/ffmpeg-devel/2015-January/167388.html
> >> >
> >> > The concerns and reasons brought up there should not really have
> changed.
> > I still object very strongly against yami.
> >
> > It is a library that does not bring much that we could not do ourselves,
> > it duplicates a lot of our code, it is the wrong level of abstraction
> > for libavcodec, it is using a bad license and there is no guarantee of
> > maintainership in the future.
>
> I know the worry after read the above thread.For Intel GPU HW accelerate
> decode/encode,
> now have 3 options in ffmpeg:
>
> 1. ffmpeg and QSV (Media SDK)
> 2. ffmpeg vaapi hw accelerate decoder/native vaapi encoder
> 3. ffmpeg and libyami
>
Sorry for this little diversion: what are the differences between QSV and
vaapi?
My understanding is that QSV has better performance, while vaapi supports
more decoders / encoders. Is that correct?
It would be nice if there are some data showing the speed of these HW
accelerated decoders / encoders.

>
> And I know the guys prefer option 2 than 3, but I have a little question,
> what's the
> difference about ffmpeg/libyami and the other external codec library(e,g
> openh264,
> videotoolbox...)?
>
Is 2 available in ffmpeg today or is it sth. planned?

>
> As I know Intel have 3 full time Libyami developers, so no guarantee maybe
> is wrong.:)
>
> Tks.
> ___
> 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] How to force key frame for h264_qsv encoder?

[Chao Liu]

Need to add some code like following here
<https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/qsvenc.c#L941>
if (frame->pict_type == AV_PICTURE_TYPE_I) {
enc_ctrl->FrameType = MFX_FRAMETYPE_I | MFX_FRAMETYPE_IDR |
MFX_FRAMETYPE_REF;
 }


On Mon, Aug 1, 2016 at 1:20 PM, Chao Liu  wrote:

> Hi,
> Looks like h264_qsv doesn't respect AVFrame.pict_type now.
> It always encodes to non-key frames except for the first frame.
> Is this a bug of ffmpeg or QSV doesn't support key frames?
>
> Command I use:
> ffmpeg -debug_ts -i orig.mp4 -force_key_frames 'expr:gte(t,n_forced)'
> -look_ahead 0 -c:v h264_qsv -b:v 800k -maxrate 1600k -preset faster test.mp4
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] How to force key frame for h264_qsv encoder?

[Chao Liu]

Hi,
Looks like h264_qsv doesn't respect AVFrame.pict_type now.
It always encodes to non-key frames except for the first frame.
Is this a bug of ffmpeg or QSV doesn't support key frames?

Command I use:
ffmpeg -debug_ts -i orig.mp4 -force_key_frames 'expr:gte(t,n_forced)'
-look_ahead 0 -c:v h264_qsv -b:v 800k -maxrate 1600k -preset faster test.mp4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] ffmpeg stuck in transcoding H264 using QSV

[Chao Liu]

On Tue, Jul 26, 2016 at 2:08 AM, Ivan Uskov  wrote:

>
> Hello Chao,
>
> Tuesday, July 26, 2016, 9:04:49 AM, you wrote:
>
> > I tried to debug it a bit by comparing ffmpeg code with intel media SDK.
> > There is sth. I don't understand. Not sure whether it's related..
> > In ffmpeg, we decode the frame in a loop
> > ,
> it
> > sleeps and retries as long as MFXVideoDECODE_DecodeFrameAsync returns
> busy.
> > In intel media SDK sample_decode, it calls SyncOperation when
> > MFXVideoDECODE_DecodeFrameAsync returns busy.
>
> > Could this be the cause?
> The documentation for MFXVideoDECODE_DecodeFrameAsync says:
> =
> MFX_WRN_DEVICE_BUSY
> Hardware device is currently busy. Call this function again in a few
> milliseconds.
> =
> So if documented way does not work it looks like we have issue inside SDK.
> But I will try to double check sample_decode code.
>
> By the way, what is your platform? Linux? Do you use a patched kernel
> recommended by Intel for specific sdk version?
>
You are right. It seems to be caused by the kernel.
It works well on Intel's golden CentOS 7.1 (3.10.0-229 with patches)
The same code and environment doesn't work on Ubuntu 16.04 (4.4.0)
I'll ask help on Intel forum. Thanks.

>
>
> --
> Best regards,
>  Ivanmailto:ivan.us...@nablet.com
>
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] ffmpeg stuck in transcoding H264 using QSV

[Chao Liu]

On Mon, Jul 25, 2016 at 11:08 PM, Chao Liu  wrote:

>
>
> On Mon, Jul 25, 2016 at 11:04 PM, Chao Liu  wrote:
>
>> Hi,
>>
>> (Ivan, I am sending this mail to you directly because you said you are
>> the maintainer of QSV related code in a recent mail. Apologize if this is
>> inappropriate.. )
>>
>> I am trying to use h264_qsv to transcode a MP4 file. This is my command:
>> ffmpeg -c:v h264_qsv -i input.mp4 -look_ahead 0 -c:v h264_qsv -b:v 800k
>> -maxrate 1600k -preset fast output.mp4
>> It always stucks in this loop
>> <https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/qsvenc.c#L970>.
>>
>> It works if I change the command to
>> ffmpeg -i input.mp4 -look_ahead 0 -c:v h264_qsv -b:v 800k -maxrate 1600k
>> -preset fast output.mp4
>> (not using qsv for decoding).
>>
>> Looks like the decoding and encoding were contending for the resources
>> and there is a deadlock or sth. like that..
>>
>> I tried to debug it a bit by comparing ffmpeg code with intel media SDK.
>> There is sth. I don't understand. Not sure whether it's related..
>> In ffmpeg, we decode the frame in a loop
>> <https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/qsvdec.c#L357>,
>> it sleeps and retries as long as MFXVideoDECODE_DecodeFrameAsync returns
>> busy.
>> In intel media SDK sample_decode, it calls SyncOperation when
>> MFXVideoDECODE_DecodeFrameAsync returns busy.
>>
> Sorry, forgot to paste the link to the code
> https://github.com/Intel-Media-SDK/samples/blob/master/samples/sample_decode/src/pipeline_decode.cpp#L1631
>
>

>> Could this be the cause?
>>
>
I think this is red herring. I could repro the deadlock w/o qsv decoding,
just the chance is pretty low.
And looks like this is a known issue: https://trac.ffmpeg.org/ticket/4832
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] ffmpeg stuck in transcoding H264 using QSV

[Chao Liu]

On Mon, Jul 25, 2016 at 11:04 PM, Chao Liu  wrote:

> Hi,
>
> (Ivan, I am sending this mail to you directly because you said you are the
> maintainer of QSV related code in a recent mail. Apologize if this is
> inappropriate.. )
>
> I am trying to use h264_qsv to transcode a MP4 file. This is my command:
> ffmpeg -c:v h264_qsv -i input.mp4 -look_ahead 0 -c:v h264_qsv -b:v 800k
> -maxrate 1600k -preset fast output.mp4
> It always stucks in this loop
> <https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/qsvenc.c#L970>.
>
> It works if I change the command to
> ffmpeg -i input.mp4 -look_ahead 0 -c:v h264_qsv -b:v 800k -maxrate 1600k
> -preset fast output.mp4
> (not using qsv for decoding).
>
> Looks like the decoding and encoding were contending for the resources and
> there is a deadlock or sth. like that..
>
> I tried to debug it a bit by comparing ffmpeg code with intel media SDK.
> There is sth. I don't understand. Not sure whether it's related..
> In ffmpeg, we decode the frame in a loop
> <https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/qsvdec.c#L357>,
> it sleeps and retries as long as MFXVideoDECODE_DecodeFrameAsync returns
> busy.
> In intel media SDK sample_decode, it calls SyncOperation when
> MFXVideoDECODE_DecodeFrameAsync returns busy.
>
Sorry, forgot to paste the link to the code
https://github.com/Intel-Media-SDK/samples/blob/master/samples/sample_decode/src/pipeline_decode.cpp#L1631


>
> Could this be the cause?
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] ffmpeg stuck in transcoding H264 using QSV

[Chao Liu]

Hi,

(Ivan, I am sending this mail to you directly because you said you are the
maintainer of QSV related code in a recent mail. Apologize if this is
inappropriate.. )

I am trying to use h264_qsv to transcode a MP4 file. This is my command:
ffmpeg -c:v h264_qsv -i input.mp4 -look_ahead 0 -c:v h264_qsv -b:v 800k
-maxrate 1600k -preset fast output.mp4
It always stucks in this loop
.

It works if I change the command to
ffmpeg -i input.mp4 -look_ahead 0 -c:v h264_qsv -b:v 800k -maxrate 1600k
-preset fast output.mp4
(not using qsv for decoding).

Looks like the decoding and encoding were contending for the resources and
there is a deadlock or sth. like that..

I tried to debug it a bit by comparing ffmpeg code with intel media SDK.
There is sth. I don't understand. Not sure whether it's related..
In ffmpeg, we decode the frame in a loop
, it
sleeps and retries as long as MFXVideoDECODE_DecodeFrameAsync returns busy.
In intel media SDK sample_decode, it calls SyncOperation when
MFXVideoDECODE_DecodeFrameAsync returns busy.

Could this be the cause?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] libavcodec/qsvdec.c: Restoring decoding functionality after unsuccessful merge from libav.

[Chao Liu]

Ivan Uskov  nablet.com> writes:

> 
> Hello All,
> 
> After   commit  d30cf57a7b2097b565db02ecfffbdc9c16423d0e  qsv-based  
decoding
> aborts  with  crash,  there  are many incorrect places appeared. The 
attached
> patch fixes the issues but keeps new method of the 'sync' variable 
allocation
> introduced in commit d30cf57a7b2097b565db02ecfffbdc9c16423d0e.
> 
> Please review.
> 

I had the same crashes. After reading the code, you are certainly right.
Why nobody review this commit?

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel