Color mismatch on recorded file

[andrasfuchs]

When I compare the original and recorded video there is a value difference in the green channel. The strange thing is that the other red/blue channels are not affected.

On the screenshot I attached you can see the original video on the right and the screen captured version of it on the left.

When I check the attached image in Photoshop with the color picker tool, I got 15-25 differences in the green value.

I got Windows 8 64bit. What can be the reason for this?

[rdp]

My guess is that if you compare it carefully you'll see a difference in all colors, is that the case?

On Mon, Nov 25, 2013 at 4:12 PM, Andras Fuchs notifications@github.comwrote:

When I compare the original and recorded video there is a value difference in the green channel. The strange thing is that the other red/blue channels are not affected.

On the screenshot I attached you can see the original video on the right and the screen captured version of it on the left.

When I check the attached image in Photoshop with the color picker tool, I got 15-25 differences in the green value.

I got Windows 8 64bit. What can be the reason for this?

[image: scr_comparesamples]https://f.cloud.github.com/assets/910321/1618018/c1d6ffec-5626-11e3-92db-385aed1f317a.png

— Reply to this email directly or view it on GitHubhttps://github.com/rdp/screen-capture-recorder-to-video-windows-free/issues/29 .

[andrasfuchs]

Yes, you are right, here are some sample RGB values:

        recorded | original

Black: 0,0,0 | 0,0,0 Light Blue: 0,210,255 | 0, 231,255 Purple: 255,73,255 | 255,39,255 Dark Blue: 0,28,255 | 0,15,255 Yellow: 255,227,0 | 255,240,0 Green: 0,183,0 | 0,217,0 Red: 255,46,0 | 255,25,0 White: 250,254,255 | 253,254,255

I have just realized that in the case of the white you can see that the problem affects not only the green channel, since it's red values are different too. So if the source is 0 or 255 then it's fine, otherwise there is a color distortion on all channels.

[rdp]

How was it recorded initially? Anyway I think it's related to http://trac.ffmpeg.org/ticket/437 ...

On Mon, Nov 25, 2013 at 4:12 PM, Andras Fuchs notifications@github.comwrote:

When I compare the original and recorded video there is a value difference in the green channel. The strange thing is that the other red/blue channels are not affected.

On the screenshot I attached you can see the original video on the right and the screen captured version of it on the left.

When I check the attached image in Photoshop with the color picker tool, I got 15-25 differences in the green value.

I got Windows 8 64bit. What can be the reason for this?

[image: scr_comparesamples]https://f.cloud.github.com/assets/910321/1618018/c1d6ffec-5626-11e3-92db-385aed1f317a.png

— Reply to this email directly or view it on GitHubhttps://github.com/rdp/screen-capture-recorder-to-video-windows-free/issues/29 .

[andrasfuchs]

I read the ffmpeg trac entry you included, but to be honest, I don't know how to fix it :)

I've attached a compilation of (left to right): 1, Original video played in MPC-HC 2, Recording screen of SCR 3, Captured MP4 in avidemux 4, Captured MP4 in MPC-HC

The colors are all different on all the three players.

I've also realized that in SCR ffmpeg's source is mpegts, h264+mp3 and it's output is mp4, h264+mp3 and I guess it uses my lav filters/codecs to do the compression.

Can I disable this and just save the original mpegts file somehow?

[rdp]

I will test this out and see why it's using yuv420p...

On Wed, Nov 27, 2013 at 10:59 AM, Andras Fuchs notifications@github.comwrote:

I read the ffmpeg trac entry you included, but to be honest, I don't know how to fix it :)

I've attached a compilation of (left to right): 1, Original video played in MPC-HC 2, Recording screen of SCR 3, Captured MP4 in avidemux 4, Captured MP4 in MPC-HC

The colors are all different on all the three players.

I've also realized that in SCR ffmpeg's source is mpegts, h264+mp3 and it's output is mp4, h264+mp3 and I guess it uses my lav filters/codecs to do the compression.

Can I disable this and just save the original mpegts file somehow?

[image: scr_comparesamples2]https://f.cloud.github.com/assets/910321/1630773/b56dfaee-5752-11e3-8e4a-328a54afa936.png

— Reply to this email directly or view it on GitHubhttps://github.com/rdp/screen-capture-recorder-to-video-windows-free/issues/29#issuecomment-29375912 .

[andrasfuchs]

Did you find out what happened there?

[rdp]

rtry http://rdp.inet2.org/incoming/Setup%20Screen%20Capturer%20Recorder%20v0.9.7test.exeand see? (uses yuv444 instead of yuv420)

On Mon, Dec 16, 2013 at 3:49 PM, Andras Fuchs notifications@github.comwrote:

Did you find out what happened there?

— Reply to this email directly or view it on GitHubhttps://github.com/rdp/screen-capture-recorder-to-video-windows-free/issues/29#issuecomment-30709440 .

[andrasfuchs]

Yes, I can confirm that it records now in yuv444, but the difference between the colors are still there.

I attached a screenshot with the original above and the recorded below.

[rdp]

what if you just snap to a jpg, does that show up with color change? What if you play the file with "ffplay" or "mplayer?

On Fri, Dec 20, 2013 at 8:21 AM, Andras Fuchs notifications@github.comwrote:

Yes, I can confirm that it records now in yuv444, but the difference between the colors are still there.

I attached a screenshot with the original above and the recorded below.

[image: scr_comparesamples3]https://f.cloud.github.com/assets/910321/1791286/5f7752e4-698a-11e3-94bc-4e13e2b04ccb.png

Reply to this email directly or view it on GitHubhttps://github.com/rdp/screen-capture-recorder-to-video-windows-free/issues/29#issuecomment-31016510 .

[andrasfuchs]

I have made some tests: I selected a photo and opened it in MPC-HC, recorded with SCR (using both desktop and hwnd modes) and played it back with MPC-HC and FFPlay.

I have created a PSD file with all the different result, you can grab it from here: https://dl.dropboxusercontent.com/u/7485893/SCR-ButteryFlyTest.psd

The short conclusion is:

• MPC-HC opens the image files without changing it's color (it doesn't prove that it also open mp4 files though)
• it doesn't matter if I play back the mp4 with MPC-HC or FFPlay they return the exact same image
• recording in desktop or hwnd mode doesn't change the result
• SCR seems to record with slightly invalid colors

I used SCR 0.9.6 with yuv444p color space and libx264 codec with ultrafast profile.

Do you need any more tests with this version, or is it ok if I update SCR to 0.12.3?

[rdp]

ok so snapping jpg shots doesn't mess the color...only mp4...hmm... what about mplayer playing back mp4?

On Fri, May 2, 2014 at 2:53 AM, Andras Fuchs notifications@github.comwrote:

I have made some tests: I selected a photo and opened it in MPC-HC, recorded with SCR (using both desktop and hwnd modes) and played it back with MPC-HC and FFPlay.

I have created a PSD file with all the different result, you can grab it from here: https://dl.dropboxusercontent.com/u/7485893/SCR-ButteryFlyTest.psd

The short conclusion is:

• MPC-HC opens the image files without changing it's color (it doesn't prove that it also open mp4 files though)
• it doesn't matter if I play back the mp4 with MPC-HC or FFPlay they return the exact same image
• recording in desktop or hwnd mode doesn't change the result
• SCR seems to record with slightly invalid colors

I used SCR 0.9.6 with yuv444p color space and libx264 codec with ultrafast profile.

Do you need any more tests with this version, or is it ok if I update SCR to 0.12.3?

[image: butterfly]https://cloud.githubusercontent.com/assets/910321/2860973/ff9ae45c-d1d6-11e3-98c3-89276db933c9.jpg

— Reply to this email directly or view it on GitHubhttps://github.com/rdp/screen-capture-recorder-to-video-windows-free/issues/29#issuecomment-42005142 .

[andrasfuchs]

Downloaded the lastest mplayer, and but I got the following results with the mp4... :(

[rdp]

OK shoot me the command line you're using to record with it (or are you using the gui)? and I'll try and repro...(I presume that those showed up as green for your screen?)

On Sun, May 4, 2014 at 1:24 AM, Andras Fuchs notifications@github.comwrote:

Downloaded the lastest mplayer, and but the following results with the mp4... :(

[image: screenshot 2014-05-04 08 58 06]https://cloud.githubusercontent.com/assets/910321/2872371/15622782-d35d-11e3-95f4-f825021ecce5.png

[image: screenshot 2014-05-04 08 58 12]https://cloud.githubusercontent.com/assets/910321/2872372/1e6fa1ec-d35d-11e3-8b3a-870e102b9ace.png

— Reply to this email directly or view it on GitHubhttps://github.com/rdp/screen-capture-recorder-to-video-windows-free/issues/29#issuecomment-42126458 .

[andrasfuchs]

Yes, mplayer played back the mp4 file as flat green.

I use the GUI to record and this is the dump of the console window. I hope it helps, but let me know if you need something else.

C:/Program Files (x86)/Screen Capturer Recorder/configuration_setup_utility/jruby-swing-helpers/lib/simple_gui_creator/ffmpeg_helpers.rb:9 warning: already initialized constant FFmpegNameToUse ffmpeg version N-44080-gdfb4757 Copyright (c) 2000-2012 the FFmpeg developers built on Aug 31 2012 16:58:51 with gcc 4.7.1 (GCC) configuration: --enable-gpl --enable-version3 --disable-pthreads --enable-runtime-cpudetect --enable-avisynth --enable-bzlib --enable-frei0r --enable-libass --enable-libcelt --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libfreetype --enable-libgsm --enable-libmp3lame --enable-libnut --enable-libopenjpeg --enable-librtmp --enable-libschroedinger --enable-libspeex --enable-libtheora --enable-libutvideo --enable-libvo-aacenc --enable-libvo-amrwbenc --enable-libvorbis --enable-libvpx --enable-libx264 --enable-libxavs --enable-libxvid --enable-zlib libavutil 51. 70.100 / 51. 70.100 libavcodec 54. 55.100 / 54. 55.100 libavformat 54. 25.104 / 54. 25.104 libavdevice 54. 2.100 / 54. 2.100 libavfilter 3. 15.101 / 3. 15.101 libswscale 2. 1.101 / 2. 1.101 libswresample 0. 15.100 / 0. 15.100 libpostproc 52. 0.100 / 52. 0.100 [dshow @ 020fc4a0] DirectShow video devices [dshow @ 020fc4a0] "Blackmagic WDM Capture" [dshow @ 020fc4a0] "Logitech QuickCam Ultra Vision" [dshow @ 020fc4a0] "Decklink Video Capture" [dshow @ 020fc4a0] "screen-capture-recorder" [dshow @ 020fc4a0] DirectShow audio devices [dshow @ 020fc4a0] "Microphone (Logitech Mic (Ultra Vision))" [dshow @ 020fc4a0] "virtual-audio-capturer" [dshow @ 020fc4a0] "Decklink Audio Capture" [dshow @ 020fc4a0] "Microphone (SoundMAX Integrated Digital HD Audio)" dummy: Immediate exit requested writing to C:/Users/Andras/AppData/Local/Temp/3.mp4 about to run ffmpeg -loglevel info -f dshow -video_device_number 0 -i video="screen-capture-recorder" -f dshow -audio_device_number 0 -i audio="Microphone (Logitech Mic (Ultra Vision))" -vcodec libx264 -pix_fmt yuv444p -s hd720 -preset ultrafast -vsync vfr -acodec libmp3lame -f mpegts - | ffmpeg -f mpegts -i - -c copy "C:/Users/Andras/AppData/Local/Temp/3.mp4" ffmpeg version N-44080-gdfb4757 Copyright (c) 2000-2012 the FFmpeg developers built on Aug 31 2012 16:58:51 with gcc 4.7.1 (GCC) configuration: --enable-gpl --enable-version3 --disable-pthreads --enable-runtime-cpudetect --enable-avisynth --enable-bzlib --enable-frei0r --enable-libass --enable-libcelt --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libfreetype --enable-libgsm --enable-libmp3lame --enable-libnut --enable-libopenjpeg --enable-librtmp --enable-libschroedinger --enable-libspeex --enable-libtheora --enable-libutvideo --enable-libvo-aacenc --enable-libvo-amrwbenc --enable-libvorbis --enable-libvpx --enable-libx264 --enable-libxavs --enable-libxvid --enable-zlib libavutil 51. 70.100 / 51. 70.100 libavcodec 54. 55.100 / 54. 55.100 libavformat 54. 25.104 / 54. 25.104 libavdevice 54. 2.100 / 54. 2.100 libavfilter 3. 15.101 / 3. 15.101 libswscale 2. 1.101 / 2. 1.101 libswresample 0. 15.100 / 0. 15.100 libpostproc 52. 0.100 / 52. 0.100 [dshow @ 03731060] Estimating duration from bitrate, this may be inaccurate Input #0, dshow, from 'video=screen-capture-recorder': Duration: N/A, start: 36494.816000, bitrate: N/A Stream #0:0: Video: rawvideo, bgra, 1280x720, 30 tbr, 10000k tbn, 30 tbc [dshow @ 03731060] real-time buffer 242% full! frame dropped! Last message repeated 15 times [dshow @ 0373d0e0] Estimating duration from bitrate, this may be inaccurate Guessed Channel Layout for Input Stream #1.0 : stereo Input #1, dshow, from 'audio=Microphone (Logitech Mic (Ultra Vision))': Duration: N/A, start: 36494.917000, bitrate: 1411 kb/s Stream #1:0: Audio: pcm_s16le, 44100 Hz, stereo, s16, 1411 kb/s [dshow @ 03731060] real-time buffer 242% full! frame dropped! [libx264 @ 037b0e20] using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.1 Cache64 [libx264 @ 037b0e20] profile High 4:4:4 Predictive, level 3.1, 4:4:4 8-bit [mpegts @ 037b0640] muxrate VBR, pcr every 3 pkts, sdt every 200, pat/pmt every 40 pkts Output #0, mpegts, to 'pipe:': Metadata: encoder : Lavf54.25.104 Stream #0:0: Video: h264, yuv444p, 1280x720, q=-1--1, 90k tbn, 30 tbc Stream #0:1: Audio: mp3, 44100 Hz, stereo, s16 Stream mapping: Stream #0:0 -> #0:0 (rawvideo -> libx264) Stream #1:0 -> #0:1 (pcm_s16le -> libmp3lame) Press [q] to stop, [?] for help [dshow @ 03731060] real-time buffer 242% full! frame dropped! ffmpeg version N-44080-gdfb4757 Copyright (c) 2000-2012 the FFmpeg developersts/s built on Aug 31 2012 16:58:51 with gcc 4.7.1 (GCC) configuration: --enable-gpl --enable-version3 --disable-pthreads --enable-runtime-cpudetect --enable-avisynth --enable-bzlib --enable-frei0r --enable-libass --enable-libcelt --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libfreetype --enable-libgsm --enable-libmp3lame --enable-libnut --enable-libopenjpeg --enable-librtmp --enable-libschroedinger --enable-libspeex --enable-libtheora --enable-libutvideo --enable-libvo-aacenc --enable-libvo-amrwbenc --enable-libvorbis --enable-libvpx --enable-libx264 --enable-libxavs --enable-libxvid --enable-zlib libavutil 51. 70.100 / 51. 70.100 libavcodec 54. 55.100 / 54. 55.100 libavformat 54. 25.104 / 54. 25.104 libavdevice 54. 2.100 / 54. 2.100 libavfilter 3. 15.101 / 3. 15.101 libswscale 2. 1.101 / 2. 1.101 libswresample 0. 15.100 / 0. 15.100 libpostproc 52. 0.100 / 52. 0.100 [mpegts @ 0217c4a0] max_analyze_duration 5000000 reached at 5015467 [mpegts @ 0217c4a0] Estimating duration from bitrate, this may be inaccurate Input #0, mpegts, from 'pipe:': Duration: N/A, start: 1.374944, bitrate: 128 kb/s Program 1 Metadata: service_name : Service01 service_provider: FFmpeg Stream #0:0[0x100]: Video: h264 (High 4:4:4 Predictive) ([27][0][0][0] / 0x001B), yuv444p, 1280x720, 30 fps, 30 tbr, 90k tbn, 60 tbc Stream #0:1[0x101]: Audio: mp3 ([3][0][0][0] / 0x0003), 44100 Hz, stereo, s16, 128 kb/s Output #0, mp4, to 'C:/Users/Andras/AppData/Local/Temp/3.mp4': Metadata: encoder : Lavf54.25.104 Stream #0:0: Video: h264 ([33][0][0][0] / 0x0021), yuv444p, 1280x720, q=2-31, 30 fps, 90k tbn, 90k tbc Stream #0:1: Audio: mp3 (i[0][0][0] / 0x0069), 44100 Hz, stereo, 128 kb/s Stream mapping: Stream #0:0 -> #0:0 (copy) Stream #0:1 -> #0:1 (copy) frame= 352 fps= 25 q=13.0 Lsize= 1788kB time=00:00:14.96 bitrate= 978.9kbits/s video:1376kB audio:227kB subtitle:0 global headers:0kB muxing overhead 11.576745% [libx264 @ 037b0e20] frame I:2 Avg QP:15.00 size:301798 [libx264 @ 037b0e20] frame P:350 Avg QP:13.19 size: 2301 [libx264 @ 037b0e20] mb I I16..4: 100.0% 0.0% 0.0% [libx264 @ 037b0e20] mb P I16..4: 0.3% 0.0% 0.0% P16..4: 2.3% 0.0% 0.0% 0.0% 0.0% skip:97.4% [libx264 @ 037b0e20] coded y,u,v intra: 22.7% 20.4% 20.5% inter: 0.9% 0.6% 0.6% [libx264 @ 037b0e20] i16 v,h,dc,p: 75% 21% 2% 1% [libx264 @ 037b0e20] kb/s:753.10 frame= 352 fps= 37 q=-1.0 Lsize= 1616kB time=00:00:14.95 bitrate= 885.0kbits/s s/s video:1378kB audio:227kB subtitle:0 global headers:0kB muxing overhead 0.694349% detected ffmpeg is done [ping said so] in wait_for_ffmpeg_close method ffmpeg exited apparently gracefully in 0.308s > 0

done writing C:/Users/Andras/AppData/Local/Temp/3.mp4 ffmpeg exited apparently gracefully in 15.327s > 0

[rdp]

I did look at this a little bit, apparently there's an "libx264rgb" and -q 0 or something like that that is "less lossy" but...I don't think it's an exact pixel for pixel match [off by 1?sometimes slightly more?], I'm really not sure why...hmm...there are some lossless codecs maybe?

On Mon, May 5, 2014 at 10:41 AM, Andras Fuchs notifications@github.comwrote:

I use the GUI and this is the dump of the console window. I hope it helps, but let me know if you need something else.

C:/Program Files (x86)/Screen Capturer Recorder/configuration_setup_utility/jruby-swing-helpers/lib/simple_gui_creator/ffmpeg_helpers.rb:9 warning: already initialized constant FFmpegNameToUse ffmpeg version N-44080-gdfb4757 Copyright (c) 2000-2012 the FFmpeg developers built on Aug 31 2012 16:58:51 with gcc 4.7.1 (GCC) configuration: --enable-gpl --enable-version3 --disable-pthreads --enable-runtime-cpudetect --enable-avisynth --enable-bzlib --enable-frei0r --enable-libass --enable-libcelt --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libfreetype --enable-libgsm --enable-libmp3lame --enable-libnut --enable-libopenjpeg --enable-librtmp --enable-libschroedinger --enable-libspeex --enable-libtheora --enable-libutvideo --enable-libvo-aacenc --enable-libvo-amrwbenc --enable-libvorbis --enable-libvpx --enable-libx264 --enable-libxavs --enable-libxvid --enable-zlib libavutil 51. 70.100 / 51. 70.100 libavcodec 54. 55.100 / 54. 55.100 libavformat 54. 25.104 / 54. 25.104 libavdevice 54. 2.100 / 54. 2.100 libavfilter 3. 15.101 / 3. 15.101 libswscale 2. 1.101 / 2. 1.101 libswresample 0. 15.100 / 0. 15.100 libpostproc 52. 0.100 / 52. 0.100 [dshow @ 020fc4a0] DirectShow video devices [dshow @ 020fc4a0] "Blackmagic WDM Capture" [dshow @ 020fc4a0] "Logitech QuickCam Ultra Vision" [dshow @ 020fc4a0] "Decklink Video Capture" [dshow @ 020fc4a0] "screen-capture-recorder" [dshow @ 020fc4a0] DirectShow audio devices [dshow @ 020fc4a0] "Microphone (Logitech Mic (Ultra Vision))" [dshow @ 020fc4a0] "virtual-audio-capturer" [dshow @ 020fc4a0] "Decklink Audio Capture" [dshow @ 020fc4a0] "Microphone (SoundMAX Integrated Digital HD Audio)" dummy: Immediate exit requested writing to C:/Users/Andras/AppData/Local/Temp/3.mp4 about to run ffmpeg -loglevel info -f dshow -video_device_number 0 -i video="screen-capture-recorder" -f dshow -audio_device_number 0 -i audio="Microphone (Logitech Mic (Ultra Vision))" -vcodec libx264 -pix_fmt yuv444p -s hd720 -preset ultrafast -vsync vfr -acodec libmp3lame -f mpegts

• | ffmpeg -f mpegts -i - -c copy "C:/Users/Andras/AppData/Local/Temp/3.mp4" ffmpeg version N-44080-gdfb4757 Copyright (c) 2000-2012 the FFmpeg developers built on Aug 31 2012 16:58:51 with gcc 4.7.1 (GCC) configuration: --enable-gpl --enable-version3 --disable-pthreads --enable-runtime-cpudetect --enable-avisynth --enable-bzlib --enable-frei0r --enable-libass --enable-libcelt --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libfreetype --enable-libgsm --enable-libmp3lame --enable-libnut --enable-libopenjpeg --enable-librtmp --enable-libschroedinger --enable-libspeex --enable-libtheora --enable-libutvideo --enable-libvo-aacenc --enable-libvo-amrwbenc --enable-libvorbis --enable-libvpx --enable-libx264 --enable-libxavs --enable-libxvid --enable-zlib libavutil 51. 70.100 / 51. 70.100 libavcodec 54. 55.100 / 54. 55.100 libavformat 54. 25.104 / 54. 25.104 libavdevice 54. 2.100 / 54. 2.100 libavfilter 3. 15.101 / 3. 15.101 libswscale 2. 1.101 / 2. 1.101 libswresample 0. 15.100 / 0. 15.100 libpostproc 52. 0.100 / 52. 0.100 [dshow @ 03731060] Estimating duration from bitrate, this may be inaccurate Input #0, dshow, from 'video=screen-capture-recorder': Duration: N/A, start: 36494.816000, bitrate: N/A Stream #0:0: Video: rawvideo, bgra, 1280x720, 30 tbr, 10000k tbn, 30 tbc [dshow @ 03731060] real-time buffer 242% full! frame dropped! Last message repeated 15 times [dshow @ 0373d0e0] Estimating duration from bitrate, this may be inaccurate Guessed Channel Layout for Input Stream #1https://github.com/rdp/screen-capture-recorder-to-video-windows-free/issues/1.0 : stereo Input #1https://github.com/rdp/screen-capture-recorder-to-video-windows-free/issues/1, dshow, from 'audio=Microphone (Logitech Mic (Ultra Vision))': Duration: N/A, start: 36494.917000, bitrate: 1411 kb/s Stream #1https://github.com/rdp/screen-capture-recorder-to-video-windows-free/issues/1:0: Audio: pcm_s16le, 44100 Hz, stereo, s16, 1411 kb/s [dshow @ 03731060] real-time buffer 242% full! frame dropped! [libx264 @ 037b0e20] using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.1 Cache64 [libx264 @ 037b0e20] profile High 4:4:4 Predictive, level 3.1, 4:4:4 8-bit [mpegts @ 037b0640] muxrate VBR, pcr every 3 pkts, sdt every 200, pat/pmt every 40 pkts Output #0, mpegts, to 'pipe:': Metadata: encoder : Lavf54.25.104 Stream #0:0: Video: h264, yuv444p, 1280x720, q=-1--1, 90k tbn, 30 tbc Stream #0:1: Audio: mp3, 44100 Hz, stereo, s16 Stream mapping: Stream #0:0 -> #0:0 (rawvideo -> libx264) Stream #1https://github.com/rdp/screen-capture-recorder-to-video-windows-free/issues/1:0 -> #0:1 (pcm_s16le -> libmp3lame) Press [q] to stop, [?] for help [dshow @ 03731060] real-time buffer 242% full! frame dropped! ffmpeg version N-44080-gdfb4757 Copyright (c) 2000-2012 the FFmpeg developersts/s built on Aug 31 2012 16:58:51 with gcc 4.7.1 (GCC) configuration: --enable-gpl --enable-version3 --disable-pthreads --enable-runtime-cpudetect --enable-avisynth --enable-bzlib --enable-frei0r --enable-libass --enable-libcelt --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libfreetype --enable-libgsm --enable-libmp3lame --enable-libnut --enable-libopenjpeg --enable-librtmp --enable-libschroedinger --enable-libspeex --enable-libtheora --enable-libutvideo --enable-libvo-aacenc --enable-libvo-amrwbenc --enable-libvorbis --enable-libvpx --enable-libx264 --enable-libxavs --enable-libxvid --enable-zlib libavutil 51. 70.100 / 51. 70.100 libavcodec 54. 55.100 / 54. 55.100 libavformat 54. 25.104 / 54. 25.104 libavdevice 54. 2.100 / 54. 2.100 libavfilter 3. 15.101 / 3. 15.101 libswscale 2. 1.101 / 2. 1.101 libswresample 0. 15.100 / 0. 15.100 libpostproc 52. 0.100 / 52. 0.100 [mpegts @ 0217c4a0] max_analyze_duration 5000000 reached at 5015467 [mpegts @ 0217c4a0] Estimating duration from bitrate, this may be inaccurate Input #0, mpegts, from 'pipe:': Duration: N/A, start: 1.374944, bitrate: 128 kb/s Program 1 Metadata: service_name : Service01 service_provider: FFmpeg Stream #0:0[0x100]: Video: h264 (High 4:4:4 Predictive) ([27][0][0][0] / 0x001B), yuv444p, 1280x720, 30 fps, 30 tbr, 90k tbn, 60 tbc Stream #0:1[0x101]: Audio: mp3 ([3][0][0][0] / 0x0003), 44100 Hz, stereo, s16, 128 kb/s Output #0, mp4, to 'C:/Users/Andras/AppData/Local/Temp/3.mp4': Metadata: encoder : Lavf54.25.104 Stream #0:0: Video: h264 ([33][0][0][0] / 0x0021), yuv444p, 1280x720, q=2-31, 30 fps, 90k tbn, 90k tbc Stream #0:1: Audio: mp3 (i[0][0][0] / 0x0069), 44100 Hz, stereo, 128 kb/s Stream mapping: Stream #0:0 -> #0:0 (copy) Stream #0:1 -> #0:1 (copy) frame= 352 fps= 25 q=13.0 Lsize= 1788kB time=00:00:14.96 bitrate= 978.9kbits/s video:1376kB audio:227kB subtitle:0 global headers:0kB muxing overhead 11.576745% [libx264 @ 037b0e20] frame I:2 Avg QP:15.00 size:301798 [libx264 @ 037b0e20] frame P:350 Avg QP:13.19 size: 2301 [libx264 @ 037b0e20] mb I I16..4: 100.0% 0.0% 0.0% [libx264 @ 037b0e20] mb P I16..4: 0.3% 0.0% 0.0% P16..4: 2.3% 0.0% 0.0% 0.0% 0.0% skip:97.4% [libx264 @ 037b0e20] coded y,u,v intra: 22.7% 20.4% 20.5% inter: 0.9% 0.6% 0.6% [libx264 @ 037b0e20] i16 v,h,dc,p: 75% 21% 2% 1% [libx264 @ 037b0e20] kb/s:753.10 frame= 352 fps= 37 q=-1.0 Lsize= 1616kB time=00:00:14.95 bitrate= 885.0kbits/s s/s video:1378kB audio:227kB subtitle:0 global headers:0kB muxing overhead 0.694349% detected ffmpeg is done [ping said so] in wait_for_ffmpeg_close method ffmpeg exited apparently gracefully in 0.308s > 0

done writing C:/Users/Andras/AppData/Local/Temp/3.mp4 ffmpeg exited apparently gracefully in 15.327s > 0

— Reply to this email directly or view it on GitHubhttps://github.com/rdp/screen-capture-recorder-to-video-windows-free/issues/29#issuecomment-42208341 .

[andrasfuchs]

Yes, there is a lossless option for the libx264 too. https://trac.ffmpeg.org/wiki/Encode/H.264#LosslessH.264

The parameter we need to add is -qp 0

I've made some tests with the following parameters: -vcodec libx264 -preset ultrafast -crf 0 -pix_fmt yuv420p -vcodec libx264 -preset ultrafast -qp 0 -pix_fmt yuv420p -vcodec libx264 -preset veryslow -qp 0 -pix_fmt yuv420p -c:v huffyuv

All the libx264 versions had the same color mismatch as before. The HUFFYUV recorded it perfectly without any color distortion.

Here are the results: https://dl.dropboxusercontent.com/u/7485893/SCR-AccentColors.psd

The original image:

According to MediaInfo the main differences between the generated files are:

• codecs: libx264 VS huffyuv
• container: mp4 VS avi
• color space: yuv VS rgba
• video stream: "h264 high 4:4:4 predictive L3.1, yuv420p" VS "huffyuv, bgra"

Here is an interesting thread: http://forum.doom9.org/archive/index.php/t-163518.html

They say that the RGB -> YUV conversion should be lossless...

Do you have any other ideas?

[rdp]

OK huffyuv being accurate means that the problem isn't at the source :) Anyway there's an libx264rgb encoder I believe, and http://forum.doom9.org/showthread.php?t=168999 maybe a "fullrange" option or -sws_flags +accurate_rnd+full_chroma_int options? http://ffmpeg-users.933282.n4.nabble.com/How-can-I-convert-rbg-to-yuv420p-loseless-td4660765.html Let me know if anything helps here...hmm... [note to self, try to provide a distro that forces everything to full range, does that make a difference?]

The problem has got to be in the conversion to YUV [is my guess].

On Sat, Jun 7, 2014 at 2:21 PM, Andras Fuchs notifications@github.com wrote:

Yes, there is a lossless option for the libx264 too. https://trac.ffmpeg.org/wiki/Encode/H.264#LosslessH.264

The parameter we need to add is -qp 0

I've made some tests with the following parameters: -vcodec libx264 -preset ultrafast -crf 0 -pix_fmt yuv420p -vcodec libx264 -preset ultrafast -qp 0 -pix_fmt yuv420p -vcodec libx264 -preset veryslow -qp 0 -pix_fmt yuv420p -c:v huffyuv

All the libx264 versions had the same color mismatch as before. The HUFFYUV recorded it perfectly without any color distortion.

Here are the results: https://dl.dropboxusercontent.com/u/7485893/SCR-AccentColors.psd

The original image: [image: all-accent-colors] https://cloud.githubusercontent.com/assets/910321/3209675/a47a2824-ee7f-11e3-8e80-4c963f7c38ff.png

According to MediaInfo the main differences between the generated files are:

• codecs: libx264 VS huffyuv
• container: mp4 VS avi
• color space: yuv VS rgba
• video stream: "h264 high 4:4:4 predictive L3.1, yuv420p" VS "huffyuv, bgra"

Here is an interesting thread: http://forum.doom9.org/archive/index.php/t-163518.html

They say that the RGB -> YUV conversion should be lossless...

Do you have any other ideas?

— Reply to this email directly or view it on GitHub https://github.com/rdp/screen-capture-recorder-to-video-windows-free/issues/29#issuecomment-45420180 .

[andrasfuchs]

Alright, this is it, libx264rgb works just fine.

I've updated the PSD file where every test I made is included. https://dl.dropboxusercontent.com/u/7485893/SCR-AccentColors.psd

The command line I used is: -vcodec libx264rgb -preset ultrafast -qp 0 -pix_fmt rgb24

Do you think that we should report this to the ffmpeg team? Probably their RGB->YUV converter isn't lossless, but my understanding is that is should be. Or do I misunderstand the reason for the color mismatch?

Here is the thread again about the problem: http://forum.doom9.org/archive/index.php/t-163518.html and another http://forum.doom9.org/archive/index.php/t-168027.html

The link to libswscale (which does the color conversion in ffmpeg): https://github.com/FFmpeg/FFmpeg/tree/master/libswscale

[rdp]

would you mind trying the other params to see if they help with "normal" libx264 as well, just for curiosity?

On Sun, Jun 8, 2014 at 2:23 AM, Andras Fuchs notifications@github.com wrote:

Alright, this is it, libx264rgb works just fine.

I've updated the PSD file where every test I made is included. https://dl.dropboxusercontent.com/u/7485893/SCR-AccentColors.psd

The command line I used is: -vcodec libx264rgb -preset ultrafast -qp 0 -pix_fmt rgb24

— Reply to this email directly or view it on GitHub https://github.com/rdp/screen-capture-recorder-to-video-windows-free/issues/29#issuecomment-45431354 .

[andrasfuchs]

I've also tested the fullrange, colormatrix and swsflags options and updated the file: https://dl.dropboxusercontent.com/u/7485893/SCR-AccentColors.psd

None of them produced perfect results.

You can find more info about the ffmpeg color matrices here: http://ffmpeg.org/ffmpeg-filters.html#colormatrix

[rdp]

Were any closer or almost perfect? Seriously yuv444p should be lossless shouldn't it?

On Mon, Jun 9, 2014 at 1:54 AM, Andras Fuchs notifications@github.com wrote:

I've also tested the fullrange, colormatrix and swsflags options and updated the file: https://dl.dropboxusercontent.com/u/7485893/SCR-AccentColors.psd

None of them produced perfect results.

You can find more info about the ffmpeg color matrices here: http://ffmpeg.org/ffmpeg-filters.html#colormatrix

— Reply to this email directly or view it on GitHub https://github.com/rdp/screen-capture-recorder-to-video-windows-free/issues/29#issuecomment-45468741 .

[andrasfuchs]

You can check it out in the SCR-AccentColors.psd file mentioned above.

To summarize the findings, I would say:

• x264 veryslow vs. ultrafast doesn't make any difference
• x264's default colorspace setting is yuv420p
• x264's yuvj420p, yuv444p, yuvj444p and yuv420p are all different. Probably yuvj420p is the best, yuv444p is the worst, but it is subjective, since they are all lossy. yuvj444p and yuv420p are nearly identical, and are close to the yuvj420p.
• swsflags doesn't make a difference when using with x264
• x264's colormatrix makes a difference, bt709 is the default, YCgCo is totally wrong
• only huffyuv and x264rgb could produce color-perfect results

I agree, theoretically yuv444p should be lossless (or at least much better than yuv420p), but it isn't.

((I have just realized that I used an ffmpeg built on 2012-08-31. I am going to download the latest build and try a few things again. I think you include this version in your project too, don't you?))

UPDATE: I tried the newest build from http://ffmpeg.zeranoe.com/builds/ (2014-06-09) and the results are the same.

[rdp]

I'll ask on the ffmpeg user ML.

On Tue, Jun 10, 2014 at 1:27 AM, Andras Fuchs notifications@github.com wrote:

You can check it out in the SCR-AccentColors.psd file mentioned above.

To summarize the findings, I would say:

• x264 veryslow vs. ultrafast doesn't make any difference
• x264's default colorspace setting is yuv420p

in ffmpeg the default is yuv444p I think?

• x264's yuvj420p, yuv444p and yuv420p are all different. Probably yuvj420p is the best, yuv444p is the worst, but it is subjective, since they are all lossy.

Is yuvj444p possible? I assume j means full range?

• swsflags doesn't make a difference when using with x264
• x264's colormatrix makes a difference, bt709 is the default, YCgCo is totally wrong
• only huffyuv and x264rgb could produce color-perfect results

I agree, theoretically yuv444p should be lossless (or at least much better than yuv420p), but it isn't..

— Reply to this email directly or view it on GitHub https://github.com/rdp/screen-capture-recorder-to-video-windows-free/issues/29#issuecomment-45581810 .

[andrasfuchs]

Did you get any response from him?

[rdp]

somehow I forgot to send it, gah! will let you know...

On Tue, Jun 24, 2014 at 3:14 PM, Andras Fuchs notifications@github.com wrote:

Did you get any response from him?

— Reply to this email directly or view it on GitHub https://github.com/rdp/screen-capture-recorder-to-video-windows-free/issues/29#issuecomment-47031813 .

[andrasfuchs]

No worries! Any feedback so far? In case you posted it in a forum, could you post the link of the thread here?

[rdp]

Here's the thread:

v https://ffmpeg.org/pipermail/ffmpeg-user/2014-June/022114.html The next thing we could do/try is to convert it to "raw" yuvj444p and see if that already shows the lossiness or not...hrm...

On Mon, Jun 30, 2014 at 3:43 AM, Andras Fuchs notifications@github.com wrote:

No worries! Any feedback so far? In case you posted it in a forum, could you post the link of the thread here?

— Reply to this email directly or view it on GitHub https://github.com/rdp/screen-capture-recorder-to-video-windows-free/issues/29#issuecomment-47512992 .

[andrasfuchs]

So, according to their answer we should just switch to libx264rgb, right?

[rdp]

It seems like it, my guess is that you'll get at least some lossiness converting to yuv444p FWIW

On Sat, Jul 5, 2014 at 2:58 AM, Andras Fuchs notifications@github.com wrote:

So, according to their answer should we just switch to libx264rgb, right?

— Reply to this email directly or view it on GitHub https://github.com/rdp/screen-capture-recorder-to-video-windows-free/issues/29#issuecomment-48081644 .

[andrasfuchs]

Are you planning to make a new release with the libx264rgb config?

And I also noticed that you include the 2012-08-31 build of ffmpeg in your package. I'm not sure if it has a great significance, but could you replace it with the most recent one? (http://ffmpeg.zeranoe.com/builds/)

[rdp]

Yeah there could be some changes there that might be useful I suppose...hmm... You want a new option "lossless encoding" or something? [I don't plan a new release yet, but hopefully sometime :) ]

On Fri, Jul 11, 2014 at 1:02 AM, Andras Fuchs notifications@github.com wrote:

Are you planning to make a new release with the libx264rgb config?

And I also noticed that you include the 2012-08-31 build of ffmpeg in your package. I'm not sure if it has a great significance, but could you replace it with the most recent one? (http://ffmpeg.zeranoe.com/builds/)

— Reply to this email directly or view it on GitHub https://github.com/rdp/screen-capture-recorder-to-video-windows-free/issues/29#issuecomment-48700231 .

[andrasfuchs]

I did some tests to check the -qp and -crf parameters. Generally ffmpeg recommends using -crf over -qp.

crf's valid range is 0..51 (0 best quality, 51 worst quality)

Here are the results recording something very similar each time: (parameter, overall fps, video kbps)

-qp 0 58.941 fps 2 156 Kbps

-qp 1 58.905 fps 68.7 Kbps

-qp 2 58.890 fps 66.3 Kbps

-qp 3 58.964 fps 67.6 Kbps

-crf 0 59.083 fps 2 161 Kbps

-crf 1 57.487 fps 72.5 Kbps

-crf 3 57.832 fps 78.6 Kbps

-crf 5 58.153 fps 77.8 Kbps

-crf 10 57.873 fps 67.1 Kbps

-crf 18 57.833 fps 60.5 Kbps

-crf 23 57.910 fps 48.1 Kbps

-crf 28 57.852 fps 39.7 Kbps

-crf 51 57.241 fps 22.7 Kbps

Visually all videos are color perfect, but the crf 51 video is blurry.

Looking at the results I would recommend to have only one checkbox on the UI (unchecked by default) to allow the user to choose if he wants to use lossless mode, and in that case set the "-crf 0" parameter otherwise the "-crf 1".

What do you think?

[rdp]

I like it, good idea.

On Fri, Jul 11, 2014 at 10:12 AM, Andras Fuchs notifications@github.com wrote:

I did some tests to check the -qp and -crf parameters. Generally ffmpeg recommends using -crf over -qp.

crf's valid range is 0..51 (0 best quality, 51 worst quality)

Here are the results recording something very similar each time: (parameter, overall fps, video kbps)

-qp 0 58.941 fps 2 156 Kbps

-qp 1 58.905 fps 68.7 Kbps

-qp 2 58.890 fps 66.3 Kbps

-qp 3 58.964 fps 67.6 Kbps

-crf 0 59.083 fps 2 161 Kbps

-crf 1 57.487 fps 72.5 Kbps

-crf 3 57.832 fps 78.6 Kbps

-crf 5 58.153 fps 77.8 Kbps

-crf 10 57.873 fps 67.1 Kbps

-crf 18 57.833 fps 60.5 Kbps

-crf 23 57.910 fps 48.1 Kbps

-crf 28 57.852 fps 39.7 Kbps

-crf 51 57.241 fps 22.7 Kbps

Visually all videos are color perfect, but the crf 51 video is blurry.

Looking at the results I would recommend to have only one checkbox on the UI (unchecked by default) to allow the user to choose if he wants to use lossless mode, and in that case set the "-crf 0" parameter otherwise the "-crf 1".

What do you think?

— Reply to this email directly or view it on GitHub https://github.com/rdp/screen-capture-recorder-to-video-windows-free/issues/29#issuecomment-48750449 .

[andrasfuchs]

Cool. :) Just FYI, I include the 2 command lines I used for my crf recordings:

ffmpeg -loglevel warning -f dshow -i video="screen-capture-recorder" -f dshow -i audio="Microphone (Sound Blaster Z)" -vcodec libx264rgb -preset ultrafast -crf 0 -pix_fmt rgb24 -s 1280x720 -vsync vfr -acodec libmp3lame -ac 1 -ar 44100 -b:a 96k -f mpegts - | ffmpeg -f mpegts -i - -c copy "x264rgb_crf00_uf_rgb24.mp4"

ffmpeg -loglevel warning -f dshow -i video="screen-capture-recorder" -f dshow -i audio="Microphone (Sound Blaster Z)" -vcodec libx264rgb -preset ultrafast -crf 1 -pix_fmt rgb24 -s 1280x720 -vsync vfr -acodec libmp3lame -ac 1 -ar 44100 -b:a 96k -f mpegts - | ffmpeg -f mpegts -i - -c copy "x264rgb_crf01_uf_rgb24.mp4"