Opened 10 years ago

Closed 9 years ago

Last modified 9 years ago

#814 closed defect (wontfix)

rgb24 -> yuv420p conversion is not precise?

Reported by: ami_stuff Owned by:
Priority: normal Component: swscale
Version: unspecified Keywords:
Cc: Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no

Description

I don't know if this is a bug (or it should be like it is), but when you convert the attached rgb24 sample to yuv420p then for example the red line in the picture will be not smooth anymore

C:\>ffmpeg -i tetest.tif -pix_fmt yuv420p out.tif
ffmpeg version N-35966-g1d0ae92, Copyright (c) 2000-2011 the FFmpeg developers
  built on Dec 19 2011 13:01:15 with gcc 4.6.2
  configuration: --enable-gpl --enable-version3 --disable-w32threads --enable-ru
ntime-cpudetect --enable-avisynth --enable-bzlib --enable-frei0r --enable-libope
ncore-amrnb --enable-libopencore-amrwb --enable-libfreetype --enable-libgsm --en
able-libmp3lame --enable-libopenjpeg --enable-librtmp --enable-libschroedinger -
-enable-libspeex --enable-libtheora --enable-libvo-aacenc --enable-libvo-amrwben
c --enable-libvorbis --enable-libvpx --enable-libx264 --enable-libxavs --enable-
libxvid --enable-zlib
  libavutil    51. 32. 0 / 51. 32. 0
  libavcodec   53. 46. 1 / 53. 46. 1
  libavformat  53. 27. 0 / 53. 27. 0
  libavdevice  53.  4. 0 / 53.  4. 0
  libavfilter   2. 53. 0 /  2. 53. 0
  libswscale    2.  1. 0 /  2.  1. 0
  libpostproc  51.  2. 0 / 51.  2. 0
Input #0, image2, from 'tetest.tif':
  Duration: 00:00:00.04, start: 0.000000, bitrate: N/A
    Stream #0:0: Video: tiff, rgb24, 1024x768, 25 tbr, 25 tbn, 25 tbc
[buffer @ 020E1200] w:1024 h:768 pixfmt:rgb24 tb:1/1000000 sar:0/1 sws_param:
[buffersink @ 020E1480] auto-inserting filter 'auto-inserted scale 0' between th
e filter 'src' and the filter 'out'
[scale @ 020E1880] w:1024 h:768 fmt:rgb24 -> w:1024 h:768 fmt:yuv420p flags:0x4
Output #0, image2, to 'out.tif':
  Metadata:
    encoder         : Lavf53.27.0
    Stream #0:0: Video: tiff, yuv420p, 1024x768, q=2-31, 200 kb/s, 90k tbn, 25 t
bc
Stream mapping:
  Stream #0:0 -> #0:0 (tiff -> tiff)
Press [q] to stop, [?] for help
frame=    1 fps=  0 q=0.0 Lsize=       0kB time=00:00:00.04 bitrate=   0.0kbits/
s
video:1158kB audio:0kB global headers:0kB muxing overhead -100.000000%

Attachments (1)

tetest.tif (2.3 MB ) - added by ami_stuff 10 years ago.

Change History (7)

by ami_stuff, 10 years ago

Attachment: tetest.tif added

comment:1 by Elon Musk, 10 years ago

I'm pretty much sure this can not be fixed.

comment:2 by Michael Niedermayer, 9 years ago

Keywords: swscale added

comment:3 by Carl Eugen Hoyos, 9 years ago

Component: undeterminedswscale
Keywords: swscale removed

comment:4 by Elon Musk, 9 years ago

Resolution: wontfix
Status: newclosed

I really do not see how this could be fixed.

comment:5 by Michael Niedermayer, 9 years ago

Try this:
ffmpeg -i tetest.tif -sws_flags lanczos+accurate_rnd+full_chroma_int+full_chroma_inp -pix_fmt yuv420p out.y4m
ffmpeg -i out.y4m -sws_flags lanczos+accurate_rnd+full_chroma_int+full_chroma_inp out.bmp

and view the bmp with something not based on SDL (that is something not converting to YUV420 again)

comment:6 by gjdfgh, 9 years ago

It would be nice if these magical flags would be documented anywhere. Especially how to get highest quality output. (Maybe even add a #define for this.)

Note: See TracTickets for help on using tickets.