Opened 7 years ago

Closed 6 years ago

Last modified 6 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 7 years ago.

Change History (7)

Changed 7 years ago by ami_stuff

comment:1 Changed 7 years ago by richardpl

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

comment:2 Changed 6 years ago by michael

  • Keywords swscale added

comment:3 Changed 6 years ago by cehoyos

  • Component changed from undetermined to swscale
  • Keywords swscale removed

comment:4 Changed 6 years ago by richardpl

  • Resolution set to wontfix
  • Status changed from new to closed

I really do not see how this could be fixed.

comment:5 Changed 6 years ago by michael

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 Changed 6 years ago by gjdfgh

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.