Opened 12 years ago

Last modified 11 years ago

#1031 reopened defect

yuv420p to rgb24 wrong pixels at end of rows

Reported by: SephiRok Owned by: Michael Niedermayer
Priority: normal Component: swscale
Version: git-master Keywords: yuv2rgb
Cc: Blocked By:
Blocking: Reproduced by developer: yes
Analyzed by developer: yes

Description

Seems to occur only at certain sizes.

Steps to reproduce:
ffmpeg -i Input.avi -vcodec libvpx -s 180x256 Output.avi
ffmpeg -i Output.avi Output.png

Attachments (2)

Output.png (66.1 KB ) - added by SephiRok 12 years ago.
Output.avi (163.0 KB ) - added by SephiRok 12 years ago.
yuv720p

Download all attachments as: .zip

Change History (21)

by SephiRok, 12 years ago

Attachment: Output.png added

comment:2 by Carl Eugen Hoyos, 12 years ago

Priority: importantnormal

Is this a regression?

A link to the used binary is never useful and I do not remember many issues where the output file was needed.

Please upload the input file for the buggy conversion and please provide complete, uncut console output together with the command line that you used.

by SephiRok, 12 years ago

Attachment: Output.avi added

yuv720p

comment:3 by SephiRok, 12 years ago

Attached yuv420p 180x256 clip (Output.avi).

Command:

>ffmpeg -i Output.avi Output.png
ffmpeg version N-38292-ga4c22e3 Copyright (c) 2000-2012 the FFmpeg developers
  built on Feb 27 2012 14:50:39 with gcc 4.6.2
  configuration: --enable-gpl --enable-version3 --disable-w32threads --enable-runtime-cpudetect --enable-avisynth --enable-bzlib --enable-fr
ei0r --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libfreetype --enable-libgsm --enable-libmp3lame --enable-libopenjpeg --e
nable-librtmp --enable-libschroedinger --enable-libspeex --enable-libtheora --enable-libvo-aacenc --enable-libvo-amrwbenc --enable-libvorbis
 --enable-libvpx --enable-libx264 --enable-libxavs --enable-libxvid --enable-zlib
  libavutil      51. 41.100 / 51. 41.100
  libavcodec     54.  4.100 / 54.  4.100
  libavformat    54.  1.100 / 54.  1.100
  libavdevice    53.  4.100 / 53.  4.100
  libavfilter     2. 62.101 /  2. 62.101
  libswscale      2.  1.100 /  2.  1.100
  libswresample   0.  7.100 /  0.  7.100
  libpostproc    52.  0.100 / 52.  0.100
Input #0, avi, from 'Output.avi':
  Metadata:
    encoder         : Lavf54.1.100
  Duration: 00:00:06.69, start: 0.000000, bitrate: 199 kb/s
    Stream #0:0: Video: vp8 (VP80 / 0x30385056), yuv420p, 180x256, 30 tbr, 30 tbn, 30 tbc
    Metadata:
      title           : fanatic animation.avi Video #1
Incompatible pixel format 'yuv420p' for codec 'png', auto-selecting format 'rgb24'
[buffer @ 034A1F00] w:180 h:256 pixfmt:yuv420p tb:1/1000000 sar:0/1 sws_param:
[buffersink @ 034A2920] auto-inserting filter 'auto-inserted scale 0' between the filter 'src' and the filter 'out'
[scale @ 034C31A0] w:180 h:256 fmt:yuv420p -> w:180 h:256 fmt:rgb24 flags:0x4
Output #0, image2, to 'Output.png':
  Metadata:
    encoder         : Lavf54.1.100
    Stream #0:0: Video: png, rgb24, 180x256, q=2-31, 200 kb/s, 90k tbn, 30 tbc
    Metadata:
      title           : fanatic animation.avi Video #1
Stream mapping:
  Stream #0:0 -> #0:0 (vp8 -> png)
Press [q] to stop, [?] for help
[image2 @ 03496E60] Could not get frame filename number 2 from pattern 'Output.png'
av_interleaved_write_frame(): Invalid argument

comment:4 by SephiRok, 12 years ago

Don't know if it worked in any previous versions.

comment:5 by Carl Eugen Hoyos, 12 years ago

Keywords: regression added
Priority: normalimportant
Status: newopen

Not reproducible with --disable-asm.

Steps to reproduce, regression since over two months:
$ ./ffmpeg -i tests/lena.pnm -s 180x256 out.jpg
$ ./ffmpeg -i out.jpg out.png

comment:6 by Carl Eugen Hoyos, 12 years ago

Looks like a regression since f4ea7c (r31135), but this conversion showed similar artefacts before if MMX-optimization was activated with --enable-gpl.

It is a regression that the artefacts are visible for a default compilation.

comment:7 by Michael Niedermayer, 12 years ago

Analyzed by developer: set
Keywords: yuv2rgb added
Reproduced by developer: set

The yuv2rgb SIMD code should call the C code to handle the w%8 pixels when it cannot safely write up to a multiple of 8 pixels.
Its easy to workaround by allocating a large enough buffer (see patch on ML) but the yuv2rgb code still should be fixed. The larger allocation though is also either way a good idea as it would avoid the use of slower C code for the end pixels where that implemented in yuv2rgb.
Iam not sure if regression and important still apply after the "workaround" though this bug isnt fixed by it even if it disappears as such.

comment:8 by Carl Eugen Hoyos, 12 years ago

Resolution: fixed
Status: openclosed

A workaround was applied by Michael.

comment:9 by SephiRok, 11 years ago

Resolution: fixed
Status: closedreopened
Version: git-master1.0

This still occurs for me in 1.0 and any other packaged version I've tried. Haven't tried git master.

comment:10 by Carl Eugen Hoyos, 11 years ago

Could you provide command line and complete, uncut console output for a new failing version (either 1.0 or git head)?
I tested git head, 1.0 and a4c22e3 and while the issue is very clearly visible for the old version, it is unreproducible here with 1.0 and git head.

$ md5sum Output.avi
54e993efc87efa40f4c8b6c0c2be8731  Output.avi
$ ffmpeg -i Output.avi -vframes 1 out.png
ffmpeg version N-45400-gcdfa926 Copyright (c) 2000-2012 the FFmpeg developers
  built on Oct 13 2012 00:10:32 with gcc 4.7 (SUSE Linux)
  configuration: --enable-gpl
  libavutil      51. 76.100 / 51. 76.100
  libavcodec     54. 65.100 / 54. 65.100
  libavformat    54. 32.100 / 54. 32.100
  libavdevice    54.  3.100 / 54.  3.100
  libavfilter     3. 19.102 /  3. 19.102
  libswscale      2.  1.101 /  2.  1.101
  libswresample   0. 16.100 /  0. 16.100
  libpostproc    52.  1.100 / 52.  1.100
Input #0, avi, from 'Output.avi':
  Metadata:
    encoder         : Lavf54.1.100
  Duration: 00:00:06.69, start: 0.000000, bitrate: 199 kb/s
    Stream #0:0: Video: vp8 (VP80 / 0x30385056), yuv420p, 180x256, 30 tbr, 30 tbn, 30 tbc
    Metadata:
      title           : fanatic animation.avi Video #1
Output #0, image2, to 'out.png':
  Metadata:
    encoder         : Lavf54.32.100
    Stream #0:0: Video: png, rgb24, 180x256, q=2-31, 200 kb/s, 90k tbn, 30 tbc
    Metadata:
      title           : fanatic animation.avi Video #1
Stream mapping:
  Stream #0:0 -> #0:0 (vp8 -> png)
Press [q] to stop, [?] for help
frame=    1 fps=0.0 q=0.0 Lsize=       0kB time=00:00:00.03 bitrate=   0.0kbits/s
video:66kB audio:0kB subtitle:0 global headers:0kB muxing overhead -100.000000%

(out.png looks fine)

comment:11 by SephiRok, 11 years ago

It seems to only happen in our program if mmx optimizations are enabled in the ffmpeg configure. Doesn't happen with the ffmpeg or ffplay executables. Haven't been able to figure out why yet.

comment:12 by Carl Eugen Hoyos, 11 years ago

Resolution: fixed
Status: reopenedclosed
Version: 1.0git-master

Are you using av_image_alloc()? A workaround for the problem you described was applied as 62e5ef9, try to copy the behaviour into your application if not.

Last edited 11 years ago by Carl Eugen Hoyos (previous) (diff)

comment:13 by SephiRok, 11 years ago

I'm using avpicture_alloc(). Also happens with git-master.

comment:14 by Carl Eugen Hoyos, 11 years ago

Call instead av_image_alloc() directly (that is what avpicture_alloc() does, see libavcodec/imgconvert.c) with an align parameter of 32.

comment:15 by SephiRok, 11 years ago

That makes it even worse, the whole image becomes distorted. I'm using swscale to convert from yuv420p of the video frame to a rgb24 frame allocated with av_image_alloc().

Last edited 11 years ago by SephiRok (previous) (diff)

comment:16 by Carl Eugen Hoyos, 11 years ago

Resolution: fixed
Status: closedreopened

The original issue is reproducible with current git head, it needs -pix_fmt yuv420p / yuvj420p now.

comment:17 by Takis Issaris, 11 years ago

With current git head, it is still reproducible, and it still works fine when compiling FFmpeg with --disable-asm.

comment:18 by Michael Niedermayer, 11 years ago

Priority: importantnormal

comment:19 by Michael Niedermayer, 11 years ago

Keywords: regression removed

not a regression, this was never really fixed, and the workaround is back so it should not be marked as regression

Note: See TracTickets for help on using tickets.