How to deal with Youtube making videos 'pinkish'?

Question

Often my videos that i upload to Youtube turn 'pinkish' when played there. And unfortunately Youtube allows to adjust Yellow-Blue ratio, but doesn't allow one to play with any other colour after upload.

Sometimes i can counteract this 'pinkification' by using the Youtube editor and increasing both brightness and contrast, but since that implies one extra re-encoding step i would like to avoid that if at all possible (also it doesn't always work).

What i have notice is that this happens more often if the video is shot with just slightly insufficient lighting, where the video (as it plays on my computer) appears just a little darker than it should be.

1. Is this something that is a common problem or is it just my particular approach to recording that causes that?
2. Can i expect better quality if i re-encode video locally by increasing luma? Or maybe by decreasing red in RGB?

Additional details:

I am not adding any extra profiles/filters when viewing videos locally. I have tried two separate players (totem and vlc) and both play all the videos equally well. Dark ones are a little dark, but no pinkish colour is added.

The video is recorded by Panasonic HC-V500 and is directly (without any extra reencoding) uploaded to youtube. Recording mode is 1080/50p (i have also tried 1080/50i). The file format is M2TS. Here is the avprobe output:

$ avprobe 00002.MTS 
avprobe version v10_alpha1-32-g9a4c10e, Copyright (c) 2007-2013 the Libav developers
  built on Jan  2 2014 23:10:46 with gcc 4.8 (Ubuntu/Linaro 4.8.1-10ubuntu9)
[mpegts @ 0xa5bfb60] Non-increasing DTS in stream 2: packet 2 with DTS 170282, packet 3 with DTS 170282
[mpegts @ 0xa5bfb60] Non-increasing DTS in stream 2: packet 5 with DTS 213482, packet 6 with DTS 213482
(..... some more of these, but they are unlikely to be a cause of anything....)
[mpegts @ 0xa5bfb60] Non-increasing DTS in stream 2: packet 17 with DTS 299882, packet 18 with DTS 299882
Input #0, mpegts, from '00002.MTS':
  Duration: 00:19:09.10, start: 1.957800, bitrate: 25053 kb/s
  Program 1 
    Stream #0.0[0x1011]: Video: h264 (High), yuv420p, 1920x1080 [PAR 1:1 DAR 16:9], 50 fps, 90k tbn, 100 tbc
    Stream #0.1[0x1100]: Audio: ac3, 48000 Hz, stereo, fltp, 256 kb/s
    Stream #0.2[0x1200]: Data: [144][0][0][0] / 0x0090
Failed to probe codec for input stream 2
# avprobe output

My monitor is calibrated just fine and i have no problems playing anything else. In fact, as i've said i have no problem playing these exact videos locally before they get converted by Google (Youtube).

Answer 1

One way you could deal with this is to try some tests where you move the color of the video towards green until you get something that looks right when uploaded. (You don't say which editor you're using, but you could use the color board in FCPX or use DaVinci Resolve Lite, or whatever works for your setup.) Green is going to be the opposite of pink on the color wheel. You might be able to figure out the right color transform by taking a screenshot of the pinkish video and seeing if you can correct that. Then apply that same correction to some footage before uploading it and see what happens.

Answer 2

Have you tried transcoding locally with no modifications, and uploading that? Maybe your camera's h.264 encoder is producing streams that trigger a bug in youtube's h.264 decoder? Or maybe one of their h.264 colorspace flags is set to something that makes youtube think it needs to do a colorspace conversion? mediainfo can report on this, I think.

But yeah, I'd try uploading a 10 sec test clip (-t 10) transcoded with ffmpeg:

ffmpeg -i input.mp4 -t 20  -vf scale=-1:480 -acodec copy -vcodec libx264 -crf 24 -preset faster -movflags faststart  downscaled.mp4

The same cmdline should work with avconv, too. IDK, maybe have to use -a:c instead of -acodec, I forget how avconv differs.

Pick a test clip that will make it easy to see what you're looking for, and preferably low motion for a smaller output file in CRF target-quality mode. Use a lower crf value if you think compression artifacts will interfere with seeing the problem.

If that works, then try without downscaling (take out -vf scale=...).

If it still has the glitch, then try cutting the frame rate down to 25. -vf framestep=2:scale=-1:480 -r 25. Your ffmpeg output will then be bog-standard h.264 high profile 480p25 just like tons of people upload all the time.

If running it through x264 makes it work, you could always do that in future, with -crf 16 or something, and -preset medium, before uploading.

Apparently Youtube is going to xcode it regardless; I don't think it will use your h.264 stream untouched for the 1080p player, even if it's already at the right bitrate, GOP size, and everything else that it will xcode to. (point being, don't spend a ton of CPU time making a really rate-distortion-optimal encode before uploading, unless your bandwidth is very precious.)