#1073 closed defect (worksforme)
jpeg yuv444 input to yuv420 output
Reported by: | kaijun | 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 by , 13 years ago
Keywords: | jpeg removed |
---|
follow-up: 3 comment:2 by , 13 years ago
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 by , 13 years ago
Keywords: | mjpeg added |
---|---|
Resolution: | → worksforme |
Status: | new → 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 by , 13 years ago
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 by , 13 years ago
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
Command line and complete, uncut console output missing.