Opened 14 years ago
Closed 12 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)
Change History (4)
comment:1 by , 14 years ago
Keywords: | fraps added |
---|---|
Reproduced by developer: | set |
Status: | new → open |
by , 14 years ago
Attachment: | fraps_artefacts.avi added |
---|
comment:2 by , 14 years ago
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.
Three frames attached, they play fine with mplayer -vc fraps, ffmpeg shows blue artefacts for the first and third frame.