Opened 7 years ago

Closed 5 years ago

#75 closed defect (fixed)

Chroma corruption with specific Fraps sample

Reported by: Snowknight26 Owned by:
Priority: normal Component: avcodec
Version: git Keywords: fraps
Cc: Blocked By:
Blocking: Reproduced by developer: yes
Analyzed by developer: no

Description

With a specific sample (http://stfcc.org/misc/fraps_chroma_corruption.avi - ~48MB), chroma corruption is produced on at least two different frames after the decoding process.

With the same frame, note the difference between FFmpeg's output and the Fraps video decompresser's:
FFmpeg: http://stfcc.org/misc/fraps_chroma_corruption_ffmpeg.png
Fraps: http://stfcc.org/misc/fraps_chroma_corruption_fraps.png

Below output was for converion to huffyuv so it could be viewed in ffplay (ffplay doesn't display video for Fraps it seems):

C:\temp\Encoding\test>ffmpeg.exe -v 9 -loglevel 99 -i fraps_chroma_corruption.avi -vcodec huffyuv -pix_fmt rgb32 -y output.avi
FFmpeg version git-N-29181-ga304071, Copyright (c) 2000-2011 the FFmpeg developers
  built on Apr 18 2011 21:24:03 with gcc 4.5.2
  configuration: --enable-gpl --enable-version3 --enable-runtime-cpudetect --enable-memalign-hack --enable-avisynth --enable-bzlib --enable-frei0r --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libfreetype --enable-libgsm --enable-libmp3lame --enable-libopenjpeg --enable-librtmp --enable-libschroedinger --enable-libspeex --enable-libtheora --enable-libvorbis --enable-libvpx --enable-libx264 --enable-libxavs --enable-libxvid --enable-zlib --cross-prefix=i686-w64-mingw32- --target-os=mingw32 --arch=x86_32 --extra-cflags=-I/home/kyle/software/ffmpeg/external-libraries/win32/include --extra-ldflags=-L/home/kyle/software/ffmpeg/external-libraries/win32/lib --pkg-config=pkg-config
  libavutil    50. 40. 1 / 50. 40. 1
  libavcodec   52.120. 0 / 52.120. 0
  libavformat  52.108. 0 / 52.108. 0
  libavdevice  52.  4. 0 / 52.  4. 0
  libavfilter   1. 79. 0 /  1. 79. 0
  libswscale    0. 13. 0 /  0. 13. 0
[NULL @ 018BBE60] Probed with size=2048 and score=100
[avi @ 018BBE60] All info found
Input #0, avi, from 'fraps_chroma_corruption.avi':
  Duration: 00:00:01.51, start: 0.000000, bitrate: 260416 kb/s
    Stream #0.0, 1, 1/60: Video: fraps, bgr24, 960x540, 1/60, 60 tbr, 60 tbn, 60 tbc
[buffer @ 01747A30] w:960 h:540 pixfmt:bgr24
[ffsink @ 01747C30] auto-inserting filter 'auto-inserted scaler 0' between the filter 'src' and the filter 'out'
[scale @ 01747E90] w:960 h:540 fmt:bgr24 -> w:960 h:540 fmt:bgra flags:0x4
[huffyuv @ 01751A70] using huffyuv 2.2.0 or newer interlacing flag
Output #0, avi, to 'output.avi':
  Metadata:
    ISFT            : Lavf52.108.0
    Stream #0.0, 0, 1/60: Video: huffyuv, bgra, 960x540, 1/60, q=2-31, 200 kb/s, 60 tbn, 60 tbc
Stream mapping:
  Stream #0.0 -> #0.0
Press [q] to stop encoding
frame=   91 fps= 60 q=0.0 Lsize=   70979kB time=1.52 bitrate=383378.5kbits/s

video:70971kB audio:0kB global headers:0kB muxing overhead 0.010824%

Attachments (1)

fraps_artefacts.avi (2.0 MB) - added by cehoyos 7 years ago.

Download all attachments as: .zip

Change History (4)

comment:1 Changed 7 years ago by cehoyos

  • Keywords fraps added
  • Reproduced by developer set
  • Status changed from new to open

Three frames attached, they play fine with mplayer -vc fraps, ffmpeg shows blue artefacts for the first and third frame.

ffmpeg -v 9 -loglevel 99 -i fraps_artefacts.avi out%1d.png
FFmpeg version git-N-29241-gddb00ad, Copyright (c) 2000-2011 the FFmpeg developers
  built on Apr 20 2011 11:37:48 with gcc 4.4.5
  configuration: --cc='/usr/local/gcc-4.4.5/bin/gcc -m32' --disable-asm
  libavutil    51.  0. 0 / 51.  0. 0
  libavcodec   53.  0. 0 / 53.  0. 0
  libavformat  53.  0. 0 / 53.  0. 0
  libavdevice  53.  0. 0 / 53.  0. 0
  libavfilter   2.  0. 0 /  2.  0. 0
  libswscale    0. 13. 0 /  0. 13. 0
[NULL @ 0x8c64390] Format avi probed with size=2048 and score=100
[avi @ 0x8c64390] All info found
Input #0, avi, from 'fraps_artefacts.avi':
  Metadata:
    encoder         : Lavf53.0.0
  Duration: 00:00:00.05, start: 0.000000, bitrate: 329638 kb/s
    Stream #0.0, 1, 1/60: Video: fraps, bgr24, 960x540, 1/60, 60 tbr, 60 tbn, 60 tbc
Incompatible pixel format 'bgr24' for codec 'png', auto-selecting format 'rgb24'
[buffer @ 0x8c65ce0] w:960 h:540 pixfmt:bgr24
[ffsink @ 0x8c65f30] auto-inserting filter 'auto-inserted scaler 0' between the filter 'src' and the filter 'out'
[scale @ 0x8c6a4f0] w:960 h:540 fmt:bgr24 -> w:960 h:540 fmt:rgb24 flags:0x4
Output #0, image2, to 'out%1d.png':
  Metadata:
    encoder         : Lavf53.0.0
    Stream #0.0, 0, 1/90000: Video: png, rgb24, 960x540, 1/60, q=2-31, 200 kb/s, 90k tbn, 60 tbc
Stream mapping:
  Stream #0.0 -> #0.0
Press [q] to stop encoding
frame=    3 fps=  0 q=0.0 Lsize=      -0kB time=0.05 bitrate=  -3.5kbits/s
video:3255kB audio:0kB global headers:0kB muxing overhead -100.000660%

Changed 7 years ago by cehoyos

comment:2 Changed 7 years ago by reimar

There seems to be some extra data in the first plane, skipping e.g. the first 13 VLC values significantly improves the image.
All the broken frames start with very peculiar VLC-decoded data:
Frame 54:
1a 1 1 0 1 fd 1 1 1 2 0 ff 1 1 1 ff 2 0 1 0
Frame 59:
4e 1 1 0 1 ff 1 1 1 1 0 fb a 0 4 0 3e 3d 3f 3e
Frame 61:
98 1 1 0 ff 0 0 1 1 1 1 0 1 ff 1 1 1 1 1 1
Frame 62:
90 2 0 ff 1 0 1 1 1 1 0 ff 1 ff 5 ff 1 1 1 2

There might be an issue in the huffman table generation.
For example removing FF_HUFFMAN_FLAG_ZERO_COUNT reduces the issues, but causes issues with many other frames.

comment:3 Changed 5 years ago by cehoyos

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

Fixed by Michael.

Note: See TracTickets for help on using tickets.