#2640: When dropping most frames, conversion from yuvj420p to gbrp becomes
faster
if explicitly asking rgb24 intermediate
-------------------------------------+-------------------------------------
Reporter: b_jonas | Owner:
Type: defect | Status: new
Priority: minor | Component:
Version: unspecified | undetermined
Keywords: | Resolution:
Blocking: | Blocked By:
Analyzed by developer: 0 | Reproduced by developer: 0
-------------------------------------+-------------------------------------
Comment (by b_jonas):
Replying to [comment:2 cehoyos]:
> Why should this be exclusive to Windows? (It is of course exclusive to
x86 with SIMD.)
I did not think it was exclusive, but have not tested before.
> What I would like to know is why do you think there is a bug if FFmpeg
writes on the console that it will run slow because no optimized
conversion routines are available?
There are two reasons why I think there is a bug. The first is that there
is an optimized conversion, which you can get by converting yuvj420p to
rgb24 and that to gbrp, but ffmpeg does not find this automatically. The
second is that the direct color space conversion slows down the pipeline
even when I drop most frames, even though in that case only the video
decompression should be performed on all frames and the color space
conversion only on the frames output.
Replying to [comment:3 cehoyos]:
> Replying to [ticket:2640 b_jonas]:
> I strongly suspect you can achieve that higher performance if you put
the fps filter in front of the scale filter in your filter chain.
In the example commands I gave, there is no scale filter. The `-s` option
is used as an input option to tell the `rawvideo` input format the size of
images to read, for the raw video input does not have that included as
metadata.
--
Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/2640#comment:4>
FFmpeg <http://ffmpeg.org>
FFmpeg issue tracker
_______________________________________________
FFmpeg-trac mailing list
FFmpeg-trac@avcodec.org
http://avcodec.org/mailman/listinfo/ffmpeg-trac
