yuv420p to rgb24 wrong pixels at end of rows

[SephiRok]

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

[SephiRok]

Build used: ​http://ffmpeg.zeranoe.com/builds/win32/static/ffmpeg-git-a4c22e3-win32-static.7z

[Carl Eugen Hoyos]

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.

[SephiRok]

yuv720p

[SephiRok]

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

[SephiRok]

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

[Carl Eugen Hoyos]

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

[Carl Eugen Hoyos]

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.

[Michael Niedermayer]

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.

[Carl Eugen Hoyos]

A workaround was applied by Michael.

[SephiRok]

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

[Carl Eugen Hoyos]

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)

[SephiRok]

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.

[Carl Eugen Hoyos]

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.

[SephiRok]

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

[Carl Eugen Hoyos]

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

[SephiRok]

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().

[Carl Eugen Hoyos]

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

[Takis Issaris]

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

[Michael Niedermayer]

Decreasing priority after workaround from 9626d0e906f698504efb8652bac143b98d66b088
See https://ffmpeg.org/trac/ffmpeg/ticket/1031#comment:7

[Michael Niedermayer]

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

[Niklas Haas]

Cannot reproduce on current FFmpeg, assuming fixed.