Ticket #1073 (closed defect: worksforme)

Opened 15 months ago

Last modified 15 months ago

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

comment:1 Changed 15 months ago by cehoyos

  • Keywords jpeg removed

Command line and complete, uncut console output missing.

comment:2 follow-up: ↓ 3 Changed 15 months 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 15 months ago by cehoyos

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

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 15 months 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 15 months 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.