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

[cehoyos]

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.

[cehoyos]

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

[cehoyos]

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]

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.

[cehoyos]

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.

[cehoyos]

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.

[cehoyos]

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.

[cehoyos]

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 rgb24 frame allocated with av_image_alloc().

[cehoyos]

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