mirror of https://github.com/FFmpeg/FFmpeg.git
The MJPEG encoder supports some pixel format/color range combinations only when strictness is set to unofficial or less. Before commitpull/362/head059fc2d9da
said encoder's pix_fmts array only included the pixel formats supported with default strictness. When strictness was <= unofficial, fftools/ffmpeg_filter.c used an extended list of pixel formats instead of the encoder's including the pixel formats only supported when strictness <= unofficial. Said commit turned the logic around: The encoder's pix_fmts array now included all pixel formats and fftools/ffmpeg_filter.c instead used a small list of all pixel formats supported when strictness is > unofficial and the encoder's pixel formats instead. In particular, the codec's pix_fmt is not used when strictness is normal. This works for the mjpeg encoder; yet it did not work for other (hardware-based) mjpeg encoders, because the check for whether one is using the MJPEG encoder is wrong: It just checks the codec id. So if one used strict unofficial with a hardware-accelerated MJPEG encoder before commit059fc2d9da
, the unofficial (non-hardware) pixel formats of the MJPEG encoder would be used; since said commit the codec's pixel formats are overridden at ordinary strictness by the ordinary MJPEG pixel formats. This leads to format conversion errors lateron which were reported in #9186. The solution to this is to check AVCodec.name instead of its id. Fixes ticket #9186. Tested-by: Eoff, Ullysses A <ullysses.a.eoff@intel.com> Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
parent
707f9c9f47
commit
4e39cd67b7
1 changed files with 4 additions and 4 deletions
Loading…
Reference in new issue