[FFmpeg-trac] #2640(undetermined:new): When dropping most frames, conversion from yuvj420p to gbrp becomes faster if explicitly asking rgb24 intermediate
FFmpeg
trac at avcodec.org
Tue Jun 4 19:13:52 CEST 2013
#2640: When dropping most frames, conversion from yuvj420p to gbrp becomes faster
if explicitly asking rgb24 intermediate
-------------------------------------+-------------------------------------
Reporter: b_jonas | Type: defect
Status: new | Priority: minor
Component: | Version:
undetermined | unspecified
Keywords: | Blocked By:
Blocking: | Reproduced by developer: 0
Analyzed by developer: 0 |
-------------------------------------+-------------------------------------
Summary of the bug:
If I decode a video from native yuvj420p to raw video output in gbrp pixel
format (plane-major rgb with the planes in funny order), then ffmpeg gives
warnings about no accelerated color space conversion found, and the
decoding becomes very slow. When, however, I do the same explicitly
converting through rgb24 to gbrp, then the conversion is fast.
The strange part of the bug is that there is a pronounced time difference
only if I drop most of the frames (because I write in a much lower frame
rate than the input), so the color space conversion isn't actually needed.
If I output all frames, then the time difference becomes much less
pronounced. This may be due to that writing the output is slow on
windows.
I have originally found this bug when decoding a h264-compressed video,
but I can reproduce it below by reading a raw video. Direct
(unaccelerated) conversion to gbrp is so slow that the time for it
dominates the video decompression time. The direct and indirect
decompression both appear to work, they give visually similar but not
bitwise equal output.
I believe that direct color space conversion to gbrp should not add this
much overhead if I am dropping most of the output frames anyway, because
the color space conversion should be needed only for the frames kept.
Further, ffmpeg should automatically select an indirect conversion through
rgb24 if that is faster, or ideally support a fast direct conversion.
For context, I am usually reading the raw video into a program through a
pipe, and I would actually like an rgbp (plane-major rgb) output because
that's easier to handle than rgb24 (pixel-major rgb), but ffmpeg does not
currently support rgbp format at all, so I ask for gbrp and reorder the
three planes.
How to reproduce:
I have ran all the following commands on windows 7 x86_64 with an intel
core 2 quad CPU and 4 GB of RAM. I'm running the Zeranoe build of ffmpeg
version N-53307-g5a65fea built on May 20 2013 22:46:15 with gcc 4.7.3
(GCC) (this is a newer version than in my previous report).
Create a large all zeros raw video input (1.4 gigabytes, 3000 frames) with
the following command.
{{{perl -we "binmode STDOUT or die; print pack qq(x).(640*480*1.5) for
1..3000" > zeros.dat}}}
Now run the following two ffmpeg commands.
{{{ffmpeg -report -v 99 -f rawvideo -pix_fmt yuvj420p -s 640x480 -r 30 -i
zeros.dat -r 1 -f rawvideo -pix_fmt gbrp -y dump.dat 2>nul}}}
{{{ffmpeg -report -v 99 -f rawvideo -pix_fmt yuvj420p -s 640x480 -r 30 -i
zeros.dat -r 1 -f rawvideo -vf format=pix_fmts=rgb24 -pix_fmt gbrp -y
dump.dat 2>nul}}}
The first command (the direct conversion) took 29.7 seconds to run and
gave the warnings, the second (the indirect conversion) took 6.9 seconds.
I attach the log files from both runs.
(I use the `2>nul` part because the windows console is slow and writing
the debug messages there would overwhelm it.)
--
Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/2640>
FFmpeg <http://ffmpeg.org>
FFmpeg issue tracker
More information about the FFmpeg-trac
mailing list