Opened 4 years ago

Closed 4 years ago

Last modified 4 years ago

#1073 closed defect (worksforme)

jpeg yuv444 input to yuv420 output

Reported by: kaijun61 Owned by:
Priority: normal Component: avcodec
Version: unspecified Keywords: mjpeg
Cc: Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no

Description

When I input a yuv444 jpeg, but I got yuv420 output, I checked output size is 1.5 x width x height. I try ffplay in PC, it shows

Input #0, image2, from '/home/tang/Pictures/15.jpg':

Duration: 00:00:00.04, start: 0.000000, bitrate: N/A

Stream #0.0: Video: mjpeg, yuvj444p, 854x480 [PAR 72:72 DAR 427:240], 25 tbr, 25 tbn, 25 tbc

[buffersink @ 0x7f4ddc001020] auto-inserting filter 'auto-inserted scaler 0' between the filter 'src' and the filter 'out'
[scale @ 0x7f4ddc0016e0] w:854 h:480 fmt:yuvj444p -> w:854 h:480 fmt:yuv420p flags:0x4

4.64 A-V: 0.000 s:0.0 aq= 0KB vq= 0KB sq= 0B f=0/0 0/0


Change History (5)

comment:1 Changed 4 years ago by cehoyos

  • Keywords jpeg removed

Command line and complete, uncut console output missing.

comment:2 follow-up: Changed 4 years ago by kaijun61

ffplay ~/Pictures/15.jpg
ffplay version 0.8.9, Copyright (c) 2003-2011 the FFmpeg developers

built on Feb 1 2012 18:29:27 with gcc 4.6.2 20111027 (Red Hat 4.6.2-1)
configuration: --prefix=/usr --bindir=/usr/bin --datadir=/usr/share/ffmpeg --incdir=/usr/include/ffmpeg --libdir=/usr/lib64 --mandir=/usr/share/man --arch=x86_64 --extra-cflags='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic' --enable-bzlib --enable-libcelt --enable-libdc1394 --enable-libdirac --enable-libfreetype --enable-libgsm --enable-libmp3lame --enable-libopenjpeg --enable-librtmp --enable-libschroedinger --enable-libspeex --enable-libtheora --enable-libvorbis --enable-libvpx --enable-libx264 --enable-libxvid --enable-x11grab --enable-avfilter --enable-postproc --enable-pthreads --disable-static --enable-shared --enable-gpl --disable-debug --disable-stripping --shlibdir=/usr/lib64 --enable-runtime-cpudetect
libavutil 51. 9. 1 / 51. 9. 1
libavcodec 53. 8. 0 / 53. 8. 0
libavformat 53. 5. 0 / 53. 5. 0
libavdevice 53. 1. 1 / 53. 1. 1
libavfilter 2. 23. 0 / 2. 23. 0
libswscale 2. 0. 0 / 2. 0. 0
libpostproc 51. 2. 0 / 51. 2. 0

Input #0, image2, from '/home/tang/Pictures/15.jpg':

Duration: 00:00:00.04, start: 0.000000, bitrate: N/A

Stream #0.0: Video: mjpeg, yuvj444p, 854x480 [PAR 72:72 DAR 427:240], 25 tbr, 25 tbn, 25 tbc

[buffersink @ 0x7faefc001020] auto-inserting filter 'auto-inserted scaler 0' between the filter 'src' and the filter 'out'
[scale @ 0x7faefc0016e0] w:854 h:480 fmt:yuvj444p -> w:854 h:480 fmt:yuv420p flags:0x4
C 4.53 A-V: 0.000 s:0.0 aq= 0KB vq= 0KB sq= 0B f=0/0 0/0

comment:3 in reply to: ↑ 2 Changed 4 years ago by cehoyos

  • Keywords mjpeg added
  • Resolution set to worksforme
  • Status changed from new to closed

Replying to kaijun61:

ffplay ~/Pictures/15.jpg
ffplay version 0.8.9, Copyright (c) 2003-2011 the FFmpeg developers

This is old, please use current git head.

Input #0, image2, from '/home/tang/Pictures/15.jpg':

Duration: 00:00:00.04, start: 0.000000, bitrate: N/A

Stream #0.0: Video: mjpeg, yuvj444p

The decoder (correctly) provides yuvj444p.

[scale @ 0x7faefc0016e0] w:854 h:480 fmt:yuvj444p -> w:854 h:480 fmt:yuv420p flags:0x4

Since ffplay (the application) only supports showing yuv420p, this conversion is necessary. If you use an encoder that supports YUV444 (like ffv1, tiff or v308), this conversion is not necessary (the colour dynamics may be wrong, but this has nothing to do with yuv444 vs yuv420).

I hope the explanation is sufficient, I am closing this ticket.

comment:4 Changed 4 years ago by kaijun61

Do you mean image is YUV420, not YUV444. That means the parser can not distinguish them. Otherwise, as I explained, the output size is like yuv420 from jpeg decoder.

comment:5 Changed 4 years ago by cehoyos

The image you provided as an attachment to ticket #1072 (15.jpg) is YUV444 correctly identified by ffmpeg -i 15.jpg pasted by you above. ffplay does not support displaying YUV444 and therefore has to convert YUV444 to YUV420 before displaying (this is not a bug in the jpg decoder, but a limitation of ffplay), mplayer -vo gl for example allows to display YUV444 with libavcodec.
ffmpeg (the trancoding application) does support YUV444, so if you choose an encoder that accepts YUV444 as input, no such conversion will be applied, for example:
ffmpeg -i 15.jpg -pix_fmt yuv444p out.tif

Note: See TracTickets for help on using tickets.