FRAPS Video Color Space

[DJX]

The color space that ffmpeg uses on FRAPS videos seems to be wrong or mishandled.

First, running ffplay on a video (color space detected as yuvj420p), the output looks washed out (too white).
Second, when transcoding a video to H264 (which keeps the color space as yuvj420p) the output looks too dark. Forcing the color space to yuv420p, the output looks fine.
Third, when transcoding a video to MPEG2 (which changes the colorspace to yuv420p), the output looks fine.

Here is how ffmpeg detects the original file:

ffmpeg -i "C:\Fraps\Movies\cod2sp_s 2012-08-12 13-39-04-15.avi"
ffmpeg version N-43418-g633b90c Copyright (c) 2000-2012 the FFmpeg developers
  built on Aug  9 2012 23:56:26 with gcc 4.7.1 (GCC)
  configuration: --enable-gpl --enable-version3 --disable-pthreads --enable-runt
ime-cpudetect --enable-avisynth --enable-bzlib --enable-frei0r --enable-libass -
-enable-libcelt --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-l
ibfreetype --enable-libgsm --enable-libmp3lame --enable-libnut --enable-libopenj
peg --enable-librtmp --enable-libschroedinger --enable-libspeex --enable-libtheo
ra --enable-libutvideo --enable-libvo-aacenc --enable-libvo-amrwbenc --enable-li
bvorbis --enable-libvpx --enable-libx264 --enable-libxavs --enable-libxvid --ena
ble-zlib
  libavutil      51. 67.100 / 51. 67.100
  libavcodec     54. 51.100 / 54. 51.100
  libavformat    54. 22.104 / 54. 22.104
  libavdevice    54.  2.100 / 54.  2.100
  libavfilter     3.  7.100 /  3.  7.100
  libswscale      2.  1.101 /  2.  1.101
  libswresample   0. 15.100 /  0. 15.100
  libpostproc    52.  0.100 / 52.  0.100
[avi @ 000000000217aa20] non-interleaved AVI
Guessed Channel Layout for  Input Stream #0.1 : stereo
Input #0, avi, from 'C:\Fraps\Movies\orig.avi':
  Duration: 00:07:26.85, start: 0.000000, bitrate: 530091 kb/s
    Stream #0:0: Video: fraps (FPS1 / 0x31535046), yuvj420p, 1920x1080, 60 tbr,
60 tbn, 60 tbc
    Stream #0:1: Audio: pcm_s16le ([1][0][0][0] / 0x0001), 48000 Hz, stereo, s16
, 1536 kb/s
At least one output file must be specified

Let me know what other info you need.
Thanks.

[cehoyos]

A sample will be needed and is the problem also reproducible if you encode to jpeg?

[DJX]

Here is a four (4) second sample (289MB):
 http://www.djxmmx.net/ffmpeg/1636/cod2-credits-4sec.avi
MD5: d1426a8809acd5d8ff9e115a1b213f4a
SHA1: d0f0eb3384549bcf66f3ac996a0ad3a431f4331d

The color space is not 100% correct when encoded to JPEG.
It's close but not 100%.

Reference these files for a visual comparison only (not correct colorspace):
This is the original (rendered by WMPlayer with official FRAPS codec):
 http://www.djxmmx.net/ffmpeg/1636/orig.bmp

This is a JPEG rendered by FFmpeg:
 http://www.djxmmx.net/ffmpeg/1636/jpeg.jpg

This is an H264 encoded by FFmpeg, rendered by WMPlayer:
 http://www.djxmmx.net/ffmpeg/1636/h264.bmp

This is an MPEG2 encoded by FFmpeg, rendered by WMPlayer:
 http://www.djxmmx.net/ffmpeg/1636/mpeg2.bmp

[DJX]

Doing some research on the Internet, I've found that FRAPS can use one of two color spaces (not sure how it chooses) for recording. These are YV12 or RGB24, I believe, so maybe FFmpeg is not equipped to detect both kinds of FRAPS files.

[cehoyos]

Replying to DJX:

Doing some research on the Internet, I've found that FRAPS can use one of two color spaces (not sure how it chooses) for recording. These are YV12 or RGB24, I believe, so maybe FFmpeg is not equipped to detect both kinds of FRAPS files.

FFmpeg supports both RGB and YV12 in FRAPS, the problem you see happens only with YV12 (which can be interpreted in - subtly - different ways).

[richardpl]

This is not fraps decoder bug. Instead this is ffplay issue (which video output is quite limited) and colorspace handling/detection bug which is reported multiply times in several other bug reports.

[cehoyos]

Could you point me to one of those tickets so I can connect them?

[richardpl]

The only valid issue may be that decoder use YUVJ when it actually should use YUV. Only way to find out is inspecting pixel values in decoded output.

[cehoyos]

Replying to richardpl:

The only valid issue may be that decoder use YUVJ when it actaully should use YUV. Only way to find out is inspecting pixel values in decoded output.

So this ticket should be reopened until further inspection?

[DJX]

This issue is more then FFplay.
I found the issue while using FFmpeg.

The main issue is when converting these videos with FFmpeg the color space is wrong.
FFmpeg (Auto detect color space) --> Libx264 (Auto detect color space) = Dark video output

If you wish to inspect the correct decoding values, the FRAPS codec is free with the trial version and allows you to decode these on Windows.

[richardpl]

Please read what I write.

[richardpl]

Also you should note that your reference is bmp which is rgb and ffmpeg output it jpeg which is yuv.
Comparing rgb with yuv is invalid. Trial Fraps codecs converts yuv to rgb.

[DJX]

Yes, you also mentioned the YUVJ issue but I want to highlight that this in the main issue and is valid.

My screen shots are for visual reference only.
I just used BMP b/c I know it's lossless and it is the default in Windows.
I do not know much about color spaces.
I did not know BMP is RGB.

I'm not an expert on these matters at all, I'm just trying to help the project.

[richardpl]

I was wrong in such sense that yuvj vs yuv should not matter. The fraps sample you uploaded appears to make use of all bytes 0-255, so color-range should be set and pixel format switched from YUVJ (which is deprecated) to YUV.

[richardpl]

When transcoding your sample to png/bmp output is similar to your orig.bmp one but not same. So I really see no obvious bug here.
It is just that windows app internally converts to rgb. Question which conversion to bmp is closer to original is pointless because both are just wrong. So just use rgb with fraps.

[DJX]

I really don't know any better way to show the official FRAPS codec rendering other than taking a screen shot in WMP and saving it in MSPaint.
That is why I did that but once again, it was mainly for a visual compare, not a literal compare.

I cannot use RGB in FRAPS all the time b/c it is slower.
...I assume you are referring to the Force RGB capture option in FRAPS.

[richardpl]

Sample use JPEG color range and that is reason why you get wrong colors when you view them with ffplay.

Please do not use ffplay when comparing, It outputs only yuv420 (rgb will look shitty) and ignores color ranges, and etc...

If I use more relevant application to display rgb images which are transcoded from fraps sample they are similar to your orig.bmp.

[DJX]

Could you please try one more test.

Play cod2-credits-4sec.avi in WMP with official FRAPS binary codec.
Observe picture.

Convert cod2-credits-4sec.avi to H264 with FFmpeg
ffmpeg -i "cod2-credits-4sec.avi" "Out.mp4"

Play Out.mp4 in WMP
Observe picture.

To me, they are not the same.
Tested with N-49352-gc46943e.

[richardpl]

Thing is that fraps use YUVJ (full range) and whatever is stored in mp4 is using YUV (or YUVJ but program that you use to view it is not supporting it properly) and there is missing step to change colorspace. (Could use colormatrix filter) This is could be duplicate ticked (already reported in another form).