On Mon, May 18, 2015 at 9:48 AM, Claudiu Rad <jazz...@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 _______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
