Opened 5 years ago

Last modified 3 years ago

#1031 reopened defect

yuv420p to rgb24 wrong pixels at end of rows

Reported by: SephiRok Owned by: michael
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 5 years ago.
Output.avi (163.0 KB) - added by SephiRok 5 years ago.
yuv720p

Download all attachments as: .zip

Change History (21)

Changed 5 years ago by SephiRok

comment:2 Changed 5 years ago by cehoyos

  • Priority changed from important to normal

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.

Changed 5 years ago by SephiRok

yuv720p

comment:3 Changed 5 years ago by 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

comment:4 Changed 5 years ago by SephiRok

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

comment:5 Changed 5 years ago by cehoyos

  • Keywords regression added
  • Priority changed from normal to important
  • Status changed from new to open

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 Changed 5 years ago by 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.

comment:7 Changed 4 years ago by michael

  • 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 Changed 4 years ago by cehoyos

  • Resolution set to fixed
  • Status changed from open to closed

A workaround was applied by Michael.

comment:9 Changed 4 years ago by SephiRok

  • Resolution fixed deleted
  • Status changed from closed to reopened
  • Version changed from git-master to 1.0

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

comment:10 Changed 4 years ago by 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)

comment:11 Changed 4 years ago by 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.

comment:12 Changed 4 years ago by cehoyos

  • Resolution set to fixed
  • Status changed from reopened to closed
  • Version changed from 1.0 to git-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 4 years ago by cehoyos (previous) (diff)

comment:13 Changed 4 years ago by SephiRok

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

comment:14 Changed 4 years ago by cehoyos

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

comment:15 Changed 4 years ago by 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().

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

comment:16 Changed 4 years ago by cehoyos

  • Resolution fixed deleted
  • Status changed from closed to reopened

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

comment:17 Changed 3 years ago by takis

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

comment:18 Changed 3 years ago by michael

  • Priority changed from important to normal

comment:19 Changed 3 years ago by michael

  • 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.