VideoHelp Forum

Our website is made possible by displaying online advertisements to our visitors. Consider supporting us by disable your adblocker or Try ConvertXtoDVD and convert all your movies to DVD. Free trial ! :)
+ Reply to Thread
Page 1 of 2
1 2 LastLast
Results 1 to 30 of 45
Thread
  1. Here is a test pattern I have made, mainly for checking color and luminance accuracy:

    https://www.youtube.com/watch?v=G86FdE9XhqA

    If using Firefox, pause the playback and use a program such as ColorZilla to check the color values in the color patches. The RGB readout (in hex) on ColorZilla should match the text in the color patch. They likely will not match in all cases.

    The workflow for making this test pattern was:

    bmp file -> online-convert.com to mp4 -> YouTube. I suspect online-convert.com may be an online front end to ffmpeg.
    Quote Quote  
  2. Use Avisynth and x264 with proper color space description...
    Quote Quote  
  3. Originally Posted by pandy View Post
    Use Avisynth and x264 with proper color space description...
    Could you please elaborate?
    Quote Quote  
  4. Member
    Join Date
    Oct 2013
    Location
    Germany
    Search Comp PM
    Unless this behavior has changed recently, YouTube does not consider any color space description of the uploaded video. Use Rec.709 and it'll have correct colors on YouTube.
    Quote Quote  
  5. Is it not safe to assume that rec.709 is being used when a video is being encoded as an mp4 file, presumably using H.264 by, say, ffmpeg or Windows Movie Maker? What other color space might commonly be used for mp4?

    I get color errors when the mp4 file is played back locally on different players such as Firefox, Chrome, I.E., Opera or VLC, bypassing any on-line server altogether.

    When the unencoded bmp file is viewed locally on any of these programs, there are no color errors. This suggests errors in either the encoding or decoding process or both.
    Quote Quote  
  6. Originally Posted by chris319 View Post
    Originally Posted by pandy View Post
    Use Avisynth and x264 with proper color space description...
    Could you please elaborate?
    It is quite clear - encode h.264 with x264, use proper colour space description i.e. bt709

    Originally Posted by chris319 View Post
    When the unencoded bmp file is viewed locally on any of these programs, there are no color errors. This suggests errors in either the encoding or decoding process or both.
    So download video from YT to local HDD and use proper decoder to decode video.
    Quote Quote  
  7. So download video from YT to local HDD and use proper decoder to decode video.
    How many YouTube users download their videos prior to viewing in order to play them using a "proper decoder"?

    Probably none.
    Quote Quote  
  8. You should use rec.709 colors with youtube, not rec.601.
    Quote Quote  
  9. Originally Posted by jagabo View Post
    You should use rec.709 colors with youtube, not rec.601.
    Are you saying ffmpeg and Windows Movie Maker use bt.601 for mp4 encoding by default?
    Quote Quote  
  10. Originally Posted by chris319 View Post
    So download video from YT to local HDD and use proper decoder to decode video.
    How many YouTube users download their videos prior to viewing in order to play them using a "proper decoder"?

    Probably none.
    How you verify where is a problem? in video?, in YT transcoding? in your browser decoder? in browser renderer?

    btw proper mean one that was verified as OK - easy to do this when source is available.
    Quote Quote  
  11. Originally Posted by chris319 View Post
    Originally Posted by jagabo View Post
    You should use rec.709 colors with youtube, not rec.601.
    Are you saying ffmpeg and Windows Movie Maker use bt.601 for mp4 encoding by default?
    I don't know about WMM but ffmpeg will convert RGB to YUV with a rec.601 matrix by default.
    Quote Quote  
  12. I don't know about WMM but ffmpeg will convert RGB to YUV with a rec.601 matrix by default.
    I've dusted off an old ffmpeg .bat file and I'm seeing that now, thank you.
    Quote Quote  
  13. Here is the command line I'm using to launch ffmpeg from my .bat file, and it works, but I'm not sure how to specify bt.709 color space. Does anyone reading this know how?

    ffmpeg -y -loop 1 -i test_pattern.bmp -r 30 -t 10 -c:v libx264 -preset slow -crf 18 test_pattern.mp4
    Quote Quote  
  14. I believe you need to add "-vf colormatrix=bt601:bt709" after specifying the input.
    Quote Quote  
  15. Originally Posted by jagabo View Post
    I believe you need to add "-vf colormatrix=bt601:bt709" after specifying the input.
    Thank you very much for that.

    Would it work to just add "-vf colormatrix=bt709", omitting the ":bt601"?
    Quote Quote  
  16. Originally Posted by chris319 View Post
    Would it work to just add "-vf colormatrix=bt709", omitting the ":bt601"?
    I don't think so. The command converts from one colorspace to the other so it needs both an input and output colormatrix. But why bother asking when it will only take you 10 seconds to try it for yourself?

    BTW, I recommend you also specify the colormatrix in the x264 options by adding " -x264opts colormatrix=bt709" after specifying libx264. That will give you the highest probability of the video playing properly.
    Last edited by jagabo; 31st May 2016 at 19:18.
    Quote Quote  
  17. Originally Posted by jagabo View Post
    Originally Posted by chris319 View Post
    Would it work to just add "-vf colormatrix=bt709", omitting the ":bt601"?
    I don't think so. The command converts from one colorspace to the other so it needs both an input and output colormatrix. But why bother asking when it will only take you 10 seconds to try it for yourself?

    BTW, I recommend you also specify the colormatrix in the x264 options by adding " -x264opts colormatrix=bt709" after specifying libx264. That will give you the highest probability of the video playing properly.
    Thanks again for the help. I understand now about needing an input and an output. I will try "-vf colormatrix=rgb:bt709" and see what happens, as I'm starting with an RGB .bmp file.
    Quote Quote  
  18. Encoding with the following command line:

    ffmpeg -y -loop 1 -i test_pattern.bmp -t 10 -c:v libx264 -x264opts colormatrix=bt709 -vf colormatrix=bt601:bt709 -preset slow -crf 18 test_pattern.mp4
    Still getting color errors when played back locally using VLC.

    Color #942525 appears as #932623. Not the exact color but an approximation.

    NOTE: The test pattern has been modified and has different colors than the one you see on YouTube.
    Quote Quote  
  19. Originally Posted by chris319 View Post
    Color #942525 appears as #932623. Not the exact color but an approximation.
    That's perfectly normal. The conversion from RGB to YUV and back to RGB will typically give 1 or 2 digit differences when dealing with 8 bit components.
    Quote Quote  
  20. As jagabo says - there's going to be rounding errors and other lossess when converting 8bit RGB to 8bit YUV .

    You can encode RGB with x264 as well. This will give you perfect color accuracy on test patterns locally. But if it's for youtube, it will get converted to YUV 4:2:0 .

    And if your goal is youtube or other streaming platforms - then there are many other problems you will face. In addition to what YT does behind the scenes - there are problems such as browser type /configuration, OS, HW accel on vs. Off , If GPU on, then GPU settings (levels), HTML5 vs. Flash . You will never get 100% consistency across all client configurations. It's a bloody mess right now.
    Quote Quote  
  21. Originally Posted by jagabo View Post
    Originally Posted by chris319 View Post
    Color #942525 appears as #932623. Not the exact color but an approximation.
    That's perfectly normal. The conversion from RGB to YUV and back to RGB will typically give 1 or 2 digit differences when dealing with 8 bit components.
    I'm sure that's true but it needn't be. I've written code to go from RGB to YCbCr in bt.709 space and back to RGB. The math is quite straightforward and I get perfect colors every time.

    It's possible that the programmers are taking shortcuts to speed up their code. That's understandable when you're doing real-time playback, but if you're encoding a file not in real time it's questionable.
    Quote Quote  
  22. You can encode RGB with x264 as well. This will give you perfect color accuracy on test patterns locally. But if it's for youtube, it will get converted to YUV 4:2:0 .
    That's what I've been doing. Take a look at my command line and it's all encoded in x264 and bt.709, and still color errors on local playback.

    But if it's for youtube, it will get converted to YUV 4:2:0.
    I find it hard to believe that with millions of users, YouTube has the CPU capacity to re-encode everyone's home movies. I would suspect encoders and browsers first.

    there are problems such as browser type /configuration, OS, HW accel on vs. Off , If GPU on, then GPU settings (levels), HTML5 vs. Flash . You will never get 100% consistency across all client configurations. It's a bloody mess right now.
    You're right about it being a bloody mess. They probably aim to get the colors "close enough for home movies", quality be damned.

    One of the Firefox programmers shared this with me:

    When using hardware accelerated video decoding the conversion is left to the GPU and we don't control it.

    We will use hardware accelerated video decoding for H264 when available but not for VP8/VP9
    Quote Quote  
  23. Originally Posted by chris319 View Post
    You can encode RGB with x264 as well. This will give you perfect color accuracy on test patterns locally. But if it's for youtube, it will get converted to YUV 4:2:0 .
    That's what I've been doing. Take a look at my command line and it's all encoded in x264 and bt.709, and still color errors on local playback.
    Nope, you 're converting to YUV444 using Rec601, then converting again to Rec709 but in YUV with that commandline . Also, there is a double conversion because of the colormatrix filter (there would be "less" loss converting only once to YUV using 709 directly, because it's only 1 8bit conversion)

    RGB using libx264 in ffmpeg would use "-c:v libx264rgb -pix_fmt rgb24"

    Code:
    ffmpeg -y -loop 1 -i test_pattern.bmp -t 10 -c:v libx264rgb -pix_fmt rgb24 -preset slow -crf 18 test_pattern_rgb.mp4



    But if it's for youtube, it will get converted to YUV 4:2:0.
    I find it hard to believe that with millions of users, YouTube has the CPU capacity to re-encode everyone's home movies. I would suspect encoders and browsers first.
    Sure they do. In fact, each video gets converted to about a dozen different versions, including different video formats and audio formats. Different browsers and OS's can preferentially call a specific type. For example Chrome typically gets VP9 recently, not h264




    Originally Posted by chris319 View Post
    Originally Posted by jagabo View Post
    Originally Posted by chris319 View Post
    Color #942525 appears as #932623. Not the exact color but an approximation.
    That's perfectly normal. The conversion from RGB to YUV and back to RGB will typically give 1 or 2 digit differences when dealing with 8 bit components.
    I'm sure that's true but it needn't be. I've written code to go from RGB to YCbCr in bt.709 space and back to RGB. The math is quite straightforward and I get perfect colors every time.

    It's possible that the programmers are taking shortcuts to speed up their code. That's understandable when you're doing real-time playback, but if you're encoding a file not in real time it's questionable.

    99.99% of distribution video is currently 8bit YUV. This includes streaming content, DVD, Blu-ray. There is no way to go back to original 8bit RGB values with 8bit YUV . In addition, 99.99% of distribution video is chroma subsampled (4:2:0) so there is no way to get exactly the same RGB values.

    (But consumer 10bit video is right around the corner being more commonplace with HEVC, for example UHD BD supports it)
    Quote Quote  
  24. Originally Posted by chris319 View Post
    Originally Posted by jagabo View Post
    Originally Posted by chris319 View Post
    Color #942525 appears as #932623. Not the exact color but an approximation.
    That's perfectly normal. The conversion from RGB to YUV and back to RGB will typically give 1 or 2 digit differences when dealing with 8 bit components.
    I'm sure that's true but it needn't be. I've written code to go from RGB to YCbCr in bt.709 space and back to RGB. The math is quite straightforward and I get perfect colors every time.
    Not with 8 bit integer RGB and 8 bit integer YUV you didn't. Especially not with limited range YUV. There are only about 1/6 as many YUV values that map to RGB values. So 16 million RGB colors map to about 2.5 mllion YUV values. So several RGB values will map to the same YUV value and most colors will be changed on the round trip from RGB to YUV to RGB.
    Quote Quote  
  25. Originally Posted by poisondeathray View Post
    (But consumer 10bit video is right around the corner being more commonplace with HEVC, for example UHD BD supports it)
    Yes, 8 bit RGB can be converted to 10 bit YUV and back without losses. I posted ANSI C code that does it here:

    https://forum.videohelp.com/threads/376996-Lossless-Workflows-using-Premiere-Pro-Virtua...=1#post2446709

    That's rec.601 but rec.709 isn't too different in that respect.
    Quote Quote  
  26. @jagabo - yes, I saw that. I don't understand the math or the code, but it sure looks pretty Nice to get another confirmation as others have shown the mathematical proof as well with matlab . Hopefully things will shape up better when 10bit becomes more common for end user

    But in current reality, in most professional video programs, you do get losses with 10bit and higher precision conversions. I think it's primarily from dithering for bit depth conversions - there is no way to turn it off or adjust it.
    Quote Quote  
  27. Code:
    ffmpeg -y -loop 1 -i test_pattern.bmp -t 10 -c:v libx264rgb -pix_fmt rgb24 -preset slow -crf 18 test_pattern_rgb.mp4
    Perfect colors all around, but only VLC plays it. None of the browsers (Firefox, Opera, Chrome, IE) can handle it.
    Quote Quote  
  28. Originally Posted by chris319 View Post
    Code:
    ffmpeg -y -loop 1 -i test_pattern.bmp -t 10 -c:v libx264rgb -pix_fmt rgb24 -preset slow -crf 18 test_pattern_rgb.mp4
    Perfect colors all around, but only VLC plays it. None of the browsers (Firefox, Opera, Chrome, IE) can handle it.
    heh - that's why YT (and other streaming sites like vimeo, etc...) convert everything to a format that is "playable" in a browser. Namely 4:2:0 either h.264 for flash or HTML5, or VPx for HTML5
    Quote Quote  
  29. At least with the old flash (not HTML5), you had some resemblance of control if you hosted your own webpage (not a re-encoding site like YT, which discarded flags and didn't put new ones in). Because flash player payed attention to flags embedded in the stream that governed the YUV back to RGB trip - it was a predictable system that you could work with all client configurations , browsers, OSes to get consistent results. HW on meant Rec601 was used. Always. ; HW off meant user flag, otherwise Rec709. Always.

    Now it's a bloody mess. There are 100's of different permutations, and not just Rec601 vs 709

    For example YT pays attention to the full range flag now, and clamps the re-encode to 16-235
    Quote Quote  
  30. Not with 8 bit integer RGB and 8 bit integer YUV you didn't.
    Ach! You found the fly in the ointment! It works with 16-bit words but not 8 bit.

    That explains a lot.
    Quote Quote  



Similar Threads