[FFmpeg-devel] h264_qsv decoder speed
yijinliu at gmail.com
Fri Aug 19 01:38:55 EEST 2016
On Thu, Aug 18, 2016 at 7:50 AM, Moritz Barsnick <barsnick at gmx.net> 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
> > > used:
> > > - ffmpeg -c:v h264_qsv -async_depth 10 -i test.h264 -c:v rawvideo -f
> > > /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
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.)
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
More information about the ffmpeg-devel