[FFmpeg-user] Increasing the decoding speed of yuv444p h.264 files

Yan Li elliot.li.tech at gmail.com
Mon May 18 18:22:35 CEST 2015

On Mon, May 18, 2015 at 2:00 AM, Carl Eugen Hoyos <cehoyos at ag.or.at> wrote:
> Yan Li <elliot.li.tech <at> gmail.com> writes:
>> 2. I want to archive the files in yuv444p. Is there
>> any option that can make ffplay play these files
>> faster? I don't mind losing replay quality for now,
>> but I do need to keep yuv444p files.
> Please test and report, I would expect that different
> encoding options imply different decoding speeds.

I've done some more tests. Input file src.flv is in yuv444p with 48
fps. I use the following commands to generate two lossless test files:
1: ffmpeg -i src.flv -c:v libx264 -qp 0 -preset ultrafast -an yuv444p.mkv
2: ffmpeg -i src.flv -c:v libx264 -qp 0 -preset ultrafast -pix_fmt
yuv420p -an yuv420p.mkv

Then I test the decoding speed using:
time ffmpeg -i yuv444p.mkv -f rawvideo -an - >/dev/null

 - yuv444p.mkv (496 Mb/s): decoded at 55 fps
 - yuv420p.mkv (336 Mb/s): decoded at 92 fps

(I/O is not the bottleneck here. Four threads are used.)

A player that outputs video are slower than pure ffmpeg decoding, thus
the 48 fps yuv444p.mkv looks choppy on my machine.

> Iirc, there is a x264 option that makes the output
> file decode faster.

I'm aware of that option. I can't find this documented anywhere, but
it seems to me that fastdecode has no effect on lossless encoding.

I do have lossy files too. But they are for archive purpose, and I
don't want to sacrifice quality/compression ratio for decoding speed;
I bet future hardware would have no problem playing them.

>> 3. Are there any chance that the software (ffmpeg or
>> x264/x265) can get better optimized in the near
>> future (1 or 2 years?)
> I don't have a crystal ball but I can say that this
> was the case in the past (but this is also something
> you could test).

I guess the color space conversion itself can't explain the huge gap
in decoding speed. So it is actually ffmpeg's yuv444p decoding is
compute-intensive. I think what I want to know is whether the code is
already fully optimized/SIMDized, because h264 has been standardized
for a decade, and I'm not sure if someone is still actively optimizing
ffmpeg's h264 decoder. If that's the case I won't expect magic to
happen in the near future, and will just wait for my budget to buy new
hardware. But heck, what do I know about ffmpeg, I won't be surprised
if I were totally wrong.


More information about the ffmpeg-user mailing list