[FFmpeg-trac] #2640(undetermined:new): When dropping most frames, conversion from yuvj420p to gbrp becomes faster if explicitly asking rgb24 intermediate

[FFmpeg]

#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