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

[Yan Li]

On Mon, May 18, 2015 at 9:48 AM, Claudiu Rad <jazzman at misalpina.net> wrote:
> On 5/18/2015 7:22 PM, Yan Li wrote:
>>   - 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.)
> sorry to question, but:
> are you really sure about this? those are really high bitrates and it
> appears to be a direct link between bitrate and decoding speed: 496 x 55 ~=
> 336 x 92 (by a 10% margin).
> I don't know what's the drive access pattern in this case but if seeks just
> a bit, you have a problem.
> as a test, I would encode at much smaller bitrates and then compare the fps.
> of course, you can measure the disk I/O load with appropriate tools during
> decoding.

Thanks for pointing this out. But I don't think that's the problem here.

My tests were done on a high speed SSD (Samsung SSD 840 PRO) that can
easily sustain sequatial read at higher than 180MB/s. I don't know
about ffmpeg's I/O pattern, but random read shouldn't be a problem for
SSD, unless the read is done in tiny I/O size. I straced the ffmpeg
process and found that most I/O reads have size ~2M and 32KB, which
shouldn't be very unperformant.

That's why I think I/O is not bottlenecked on my computer.

But your calculation is right. Maybe the slower decoding speed _is_
because of the high volume of the data stream, assuming that ffmpeg's
handling of yuv444p is as efficient as yuv420p.

-- 
Yan