The best strategy to render yuv (mpeg, limited range) from yuvj (jpeg, full range)?
So, my sources are in yuvj, and my target (youtube) is yuv. I want to find the best strategy to minimize color banding and maximize dynamic range available. My current settings for this are: - JPEG in "preferences"; - RGBA-float in "format" (color correction in YUV leads to a lot of color banding). The problem is: I couldn't render this RGBA-float into YUV. No matter what render settings I use, it renders in full range. Putting color_range=mpeg doesn't help, because it just flags the file to be in limited range, leading to increased contrast of image. So, I'm a little confused. What I am really supposed to do? Using ColorSpace filter is not convenient with filter like histogram, for example.
On Tue, Aug 27, 2024 at 11:17 PM Tarantas via Cin <[email protected]> wrote:
So, my sources are in yuvj, and my target (youtube) is yuv. I want to find the best strategy to minimize color banding and maximize dynamic range available. My current settings for this are: - JPEG in "preferences";
Unfortunately, this setting controls both input and output color range (swscaler, part of ffmpeg). So I think you need to put some kind of filter either doing full-range -> limited range on input media, or full range-> limited range for whole file on output ....
- RGBA-float in "format" (color correction in YUV leads to a lot of color banding). The problem is: I couldn't render this RGBA-float into YUV. No matter what render settings I use, it renders in full range. Putting color_range=mpeg doesn't help, because it just flags the file to be in limited range, leading to increased contrast of image. So, I'm a little confused. What I am really supposed to do? Using ColorSpace filter is not convenient with filter like histogram, for example. -- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
One attempt might be to try high-quality formats (ProRes; DNxHR, CineFormHD); they are compatible with YT.
ср, 28 авг. 2024 г., 10:13 Andrea paz <[email protected]>:
One attempt might be to try high-quality formats (ProRes; DNxHR, CineFormHD); they are compatible with YT.
I tried to find how limited/full range works with youtube, and may be it was changed recently (post 2015)? Also might depend on browser ... https://www.vegascreativesoftware.info/us/forum/computer-rgb-now-looks-bette... https://forum.videohelp.com/threads/375799-Youtube-upload-16-235-30-218 I think advice still can be boiled down to "compress range at last step if you need so", but I am not familiar with color correction in general, may be for full range sources you better do it in full range, too? ffmpeg seems to insert some filters automatically: https://www.canva.dev/blog/engineering/a-journey-through-colour-space-with-f... OBS has their own guide too ... I think better way to see what is best today is to upload two short variations (one full range, one limited, with same footage) and see how they come out in browsers .......
On Wed, 28 Aug 2024 10:33:41 +0300 Andrew Randrianasulu via Cin <[email protected]> wrote:
I tried to find how limited/full range works with youtube, and may be it was changed recently (post 2015)? Also might depend on browser ...
Youtube re-encodes everything it gots. If case of video in yuvj (full/jpeg/pc range) youtube re-encodes it into yuv (limited/mpeg/tv range) by compressing 8 bits into 7.77 bits, which doesn't mess with the image contrast, but leads to extra color banding. What I am trying to do is to find a way to skip this extra step by doing the compression into 7.77 bits of dynamic range by myself from the cinelerra's 32-bit float RGB.
On Wed, 28 Aug 2024 02:35:56 +0300 Andrew Randrianasulu <[email protected]> wrote:
- JPEG in "preferences";
Unfortunately, this setting controls both input and output color range (swscaler, part of ffmpeg).
By the way, do "F_" video filters works with 32-float RGB? It looks like they do, but I'm not sure.
So I think you need to put some kind of filter either doing full-range -> limited range on input media, or full range-> limited range for whole file on output ....
For now figured out this way: - in render options, "color_range=mpeg"; - at the top of ready project - "F_colorspace" filter. Interestingly enough the native "ColorSpace" filter doesn't work properly and cuts the dynamic range not where it supposed to. I don't know why. This deserve a bug report. But this way with the extra filter sucks. You could forgot about it and receive the result with an increased contrast. You could forgot about it being enabled and wonder why your histogram tweaking doesn't work. Wait, could I just type "vf=colorspace" into render settings?..
ср, 28 авг. 2024 г., 20:27 Tarantas via Cin <[email protected]>:
On Wed, 28 Aug 2024 02:35:56 +0300 Andrew Randrianasulu <[email protected]> wrote:
- JPEG in "preferences";
Unfortunately, this setting controls both input and output color range (swscaler, part of ffmpeg).
By the way, do "F_" video filters works with 32-float RGB? It looks like they do, but I'm not sure.
as far as I understand ffmpeg filters themselves does not do fp 32bit filtering ... so it converted to 16bit per channel stage buffer, see cinelerra/pluginfclient.C and function in cinelerra/ffmpeg.C AVPixelFormat FFVideoConvert::color_model_to_pix_fmt(int color_model) { switch( color_model ) { case BC_YUV422: return AV_PIX_FMT_YUYV422; case BC_RGB888: return AV_PIX_FMT_RGB24; case BC_RGBA8888: return AV_PIX_FMT_RGBA; case BC_BGR8888: return AV_PIX_FMT_BGR0; case BC_BGR888: return AV_PIX_FMT_BGR24; case BC_ARGB8888: return AV_PIX_FMT_ARGB; case BC_ABGR8888: return AV_PIX_FMT_ABGR; case BC_RGB8: return AV_PIX_FMT_RGB8; case BC_YUV420P: return AV_PIX_FMT_YUV420P; case BC_YUV422P: return AV_PIX_FMT_YUV422P; case BC_YUV444P: return AV_PIX_FMT_YUV444P; case BC_YUV411P: return AV_PIX_FMT_YUV411P; case BC_RGB565: return AV_PIX_FMT_RGB565; case BC_RGB161616: return AV_PIX_FMT_RGB48LE; case BC_RGBA16161616: return AV_PIX_FMT_RGBA64LE; case BC_AYUV16161616: return AV_PIX_FMT_AYUV64LE; case BC_GBRP: return AV_PIX_FMT_GBRP; default: break; } and for ffmpeg's colorspace filter it advertizes { "format", "Output pixel format", OFFSET(user_format), AV_OPT_TYPE_INT, { .i64 = AV_PIX_FMT_NONE }, AV_PIX_FMT_NONE, AV_PIX_FMT_GBRAP12LE, FLAGS, .unit = "fmt" }, ENUM("yuv420p", AV_PIX_FMT_YUV420P, "fmt"), ENUM("yuv420p10", AV_PIX_FMT_YUV420P10, "fmt"), ENUM("yuv420p12", AV_PIX_FMT_YUV420P12, "fmt"), ENUM("yuv422p", AV_PIX_FMT_YUV422P, "fmt"), ENUM("yuv422p10", AV_PIX_FMT_YUV422P10, "fmt"), ENUM("yuv422p12", AV_PIX_FMT_YUV422P12, "fmt"), ENUM("yuv444p", AV_PIX_FMT_YUV444P, "fmt"), ENUM("yuv444p10", AV_PIX_FMT_YUV444P10, "fmt"), ENUM("yuv444p12", AV_PIX_FMT_YUV444P12, "fmt"), I can't see floating-point formats here .... ffmpeg/libavfilter/vf_colorspace.c
So I think you need to put some kind of filter either doing full-range -> limited range on input media, or full range-> limited range for whole file on output ....
For now figured out this way: - in render options, "color_range=mpeg"; - at the top of ready project - "F_colorspace" filter. Interestingly enough the native "ColorSpace" filter doesn't work properly and cuts the dynamic range not where it supposed to. I don't know why. This deserve a bug report.
well, file it then ?
But this way with the extra filter sucks. You could forgot about it and receive the result with an increased contrast. You could forgot about it being enabled and wonder why your histogram tweaking doesn't work.
you can try to chain cingg's video output to external ffmpeg binary via y4m filetype, but then you need separate pass for audio .... Historically cinelerra was avoiding making decisions for users, may be partially because making everything fully automatic and working in all cases is not really trivial ?
Wait, could I just type "vf=colorspace" into render settings?..
never tried that ..... --
Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
Aside from how CinGG works, from what I understand YT recompresses the original video even if it is set similarly to the way they compress. In short, YT's compression goes over whatever settings we make, whatever programs we use (from https://support.google.com/youtube/answer/4603579?hl=en: "Note that YouTube always re-encodes videos to optimize their playback quality"). So compression on compression leads to banding. Ideally, you should start with a poorly or uncompressed original so that YT compression leads to better results (less banding). The downside is that a poorly compressed file (Prores, DNx, ...) is about 10 times larger than an h264...
On Thu, 29 Aug 2024 08:20:22 +0000 Andrea paz via Cin <[email protected]> wrote:
Aside from how CinGG works, from what I understand YT recompresses the original video even if it is set similarly to the way they compress. In short, YT's compression goes over whatever settings we make, whatever programs we use (from https://support.google.com/youtube/answer/4603579?hl=en: "Note that YouTube always re-encodes videos to optimize their playback quality"). So compression on compression leads to banding. Ideally, you should start with a poorly or uncompressed original so that YT compression leads to better results (less banding). The downside is that a poorly compressed file (Prores, DNx, ...) is about 10 times larger than an h264...
I understand the fact youtube re-encodes everything it gets. But, h264->h264 re-encoding usually makes your video more blockly. The "color banding" is a different thing. Yes, it makes these blocks more visible, but it's a different problem. Sometimes color banding has a fundamental cause of "not enough colors in 8bit pallete". Tom Scott has a great explanation of this: https://youtu.be/h9j89L8eQQk And sometimes color banding comes from crappy video processing, which is my case, unfortunately. What I'm trying to do is to eliminate the last step of color palette compression, which is being performed by youtube during 8bit (full/jpeg/pc range) to 7.77bit (limited/mpeg/tv range) conversion. To do this, I need to make sure a video I upload to youtube is already in 7.77bit. Therefore, youtube will re-encode my h264 and add more blocks, but at least it won't compress the color palette.
I don't think YT skips color compression if set directly as YT wants it. Anyway it's a complicated and interesting topic and if you do tests and find an optimal solution please let me know and I'll put it in the manual. However, this is a different matter from what you were asking. You could try using ffmpeg from the command line using the option: -vf "scale=in_range=jpeg:out_range=mpeg" -pix_fmt yuv420p and compare with the result obtained in CinGG to see if there are any differences. Question: In CinGG, what format and preset do you use for the rendering to export to YT?
On Thu, 29 Aug 2024 22:12:38 +0000 Andrea paz <[email protected]> wrote:
I don't think YT skips color compression if set directly as YT wants it. Anyway it's a complicated and interesting topic and if you do tests and find an optimal solution please let me know and I'll put it in the manual.
Well, here's my draft if I would write such a manual. """ Title: [the subject of this thread actually] For a historical reasons, almost every piece of video software uses limited range [...] But, sometimes you have to deal with files encoded utilizing the full range. For example, some video cameras encode full range files. The simplest way to deal with them is just to re-encode in limited range: ffmpeg -i input.mp4 -c:v libx264 -preset fast -crf 19 -c:a copy \ -pix_fmt yuv420p output.mp4 But, this is not an option for you if you're either a perfectionist or trying to fight color banding. Color banding is a video artifact that could be visible in smooth areas of the video. Here's an example: https://youtu.be/KL8CIZej19o If you don't see the ugly background, then you don't need to worry about the whole issue. Color banding is different from compression artifacts. You can't fight it just by increasing the bitrate of your video. Color banding comes from color correction performed too much or in inaccurate way. And it stacks, so if you faced it, then you should get rid of dynamic range compression at every step it happens. Cinelerra has a native full color range support, and you can enable it via: Settings -> Preferences -> Appearance -> YUV color range: JPEG Note how everything will loose contrast and become grey-ish. But, in this mode, Cinelerra will also render full range video files. There are two reasons why it could be a bad thing: - some video players don't understand what full range is and will play these resulting videos with the increased contrast; - some image processing software (like YouTube) will re-encode full range videos into limited range by compressing the dynamic range and making the color banding issue even worse. That's why you should make a couple of hacks. First, after your project is done, apply F_colorspace filter at the end (bottom) of the stack with these options: - range: 1 - irange: 2 Second, in File -> Render -> Video, place this line at the end of big textfield: color_range=mpeg Since you're already fighting color banding, the good thing is to 32-bit colors in Settings -> Format -> Color model: RGB(A)-FLOAT. Note this could slow down your playback and rendering. """ By the way, if anyone is wondering "why is this guy so obsessed with such a rare issue" - well, I shoot blurry asphalt, usually misexposed: https://www.youtube.com/watch?v=B6QukURw_Og This was the good example where I was clever and minimized the damage. I have worse and don't want to look at them. By the way^2 - I just notice the cinelerra manual is the first result for googling "mpeg color range". Cool!
However, this is a different matter from what you were asking. You could try using ffmpeg from the command line using the option: -vf "scale=in_range=jpeg:out_range=mpeg" -pix_fmt yuv420p and compare with the result obtained in CinGG to see if there are any differences.
Question: In CinGG, what format and preset do you use for the rendering to export to YT?
Nothing fancy really. File -> Render: File format: FFMPEG mp4 Audio: bitrate 0, quality 5 (an overkill really, produces ~450 kbit/s AAC, but it's still noting compared to video) Video: bitrate 0, quality -1, pixels yuv420p, in a big field for options: crf=25 (for a 4K, must be lower for 1080p) preset=fast This provides a nice gently compressed video for long-time storing and uploading to YouTube.
By the way^2 - I just notice the cinelerra manual is the first result for googling "mpeg color range". Cool!
Actually I find this a little "scary". One time I was writing up CinGG Porter-Duff information for the manual and it was the first google search and I was not even sure it was 100% correct.
I have changed the manual, see if it is okay. I also attach the txt so you can check and correct the text. But I have a doubt: I thought that the Color Range setting only affects the playback in the Compositor window and not the rendering. Am I wrong?
On Sun, Sep 1, 2024 at 12:05 AM Andrea paz via Cin <[email protected]> wrote:
I have changed the manual, see if it is okay. I also attach the txt so you can check and correct the text. But I have a doubt: I thought that the Color Range setting only affects the playback in the Compositor window and not the rendering. Am I wrong?
well, it affects decoding via ffmpeg libs AND encoding via same ..so depend on how your decoders configured you may not get its effect even in viewer/compositor, from my understanding. But if both decoding and encoding done via ffmpeg libs ...it should affect encoding as far as i can read code.
-- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
вс, 1 сент. 2024 г., 02:00 Andrew Randrianasulu <[email protected]>:
On Sun, Sep 1, 2024 at 12:05 AM Andrea paz via Cin <[email protected]> wrote:
I have changed the manual, see if it is okay. I also attach the txt so you can check and correct the text. But I have a doubt: I thought that the Color Range setting only affects the playback in the Compositor window and not the rendering. Am I wrong?
well, it affects decoding via ffmpeg libs AND encoding via same ..so depend on how your decoders configured you may not get its effect even in viewer/compositor, from my understanding.
hm, it seems I was wrong in that jpeg/mpeg color range setting affects *all* decoders/encoders? there is funny bug if I set project to yuv8 and output to Open-GL, subtracting two sources on timeline - I got big green tint over all picture, visible on compositor's scope. Probably another bug, but even with x11 output I see vectoroscope green segment jumping as I switch preferences = > color range.
But if both decoding and encoding done via ffmpeg libs ...it should affect encoding as far as i can read code.
-- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
Hi ALL! I don't know if it can help. An old project of mine uses footage by old NIKON D90 photocamera. This camera record video to 720p 16/9 yuvj422p, pc (jpeg), bt470bg (MJPG) in a AVI container. I would like to point out that my Laptop monitor is calibrated to sRGB with an external Probe. For the Edit in Cinelerra-GG the Settings/Preferences/Appearance was: Color: - YUV color space: BT709 - YUV color range: JPEG (0-255) and the Settings/Format was: 1280x720 (720p) HD @24fps 16/9 yuva420p - Color Model: YUVA-8bit The Rendering by Cinelerra-GG were two, using MP4 and WEBM settings; I manually set some value for "color_primaries=bt709", "color_trc=bt709", "color_range=mpeg", "colorspace=bt709", "pixel_format=yuv420p". Below the settings for the the two output: ======================================================= Render_MP4: - Filename: ADifferentGold_HD_yuva8bit.mp4 - File Format: FFMPEG - mp4 - Audio: - Preset: h264.mp4 - Bitrate: 128000 (128k) - Quality: -1 - Samples: fltp - Video: - Compression: h264.mp4 - Bitrate: 2000000 (2M) - Quality: -1 - Pixels: yuv420p - Video Options*( * means changed by me)*: color_primaries=bt709 (*) color_range=mpeg (*) color_trc=bt709 (*) colorspace=bt709 (*) ======================================================= Render_WEBM: - Filename: ADifferentGold_HD_yuva8bit.webm - File Format: FFMPEG - webm - Audio: - Preset: vorbis.webm - Bitrate: 128000 (128k) - Quality: -1 - Samples: fltp - Video: - Compression: h264.mp4 - Bitrate: 0 - Quality: -1 - Pixels: yuv420p - Video Options*( * means changed by me)*: # 20171119-2100 # based on https://developers.google.com/media/vp9/settings/vod/ # for explanations reference the Cinelerra Manual # 1280x720 (24, 25 or 30 frames per second) b=1024k minrate=512k maxrate=1485k tile-columns=2 g=120 (*) threads=8 quality=good crf=32 speed=4 color_primaries=bt709 (*) color_range=mpeg (*) color_trc=bt709 (*) colorspace=bt709 (*) ======================================================= The ffprobe command says that renderings are: yuv420p, tv (mpeg; range=16-235), bt709. The Title of the short video is "A Different Gold", and you can see it at http://www.visi1.org/Igor-sPortfolio_NLE.html IgorBeg
Tarantas, thank you very much for working through a solution for this issue and providing the "real world" example. Andrea, thank you for the Latex version for the manual which has been checked into GIT and will appear in the September 30th manual. As usual, I changed a few trivial things; for example "loose" to "lose". On Fri, Aug 30, 2024 at 4:39 PM Tarantas via Cin <[email protected]> wrote:
On Thu, 29 Aug 2024 22:12:38 +0000 Andrea paz <[email protected]> wrote:
I don't think YT skips color compression if set directly as YT wants it. Anyway it's a complicated and interesting topic and if you do tests and find an optimal solution please let me know and I'll put it in the manual.
Well, here's my draft if I would write such a manual.
""" Title: [the subject of this thread actually]
For a historical reasons, almost every piece of video software uses limited range [...]
But, sometimes you have to deal with files encoded utilizing the full range. For example, some video cameras encode full range files. The simplest way to deal with them is just to re-encode in limited range:
ffmpeg -i input.mp4 -c:v libx264 -preset fast -crf 19 -c:a copy \ -pix_fmt yuv420p output.mp4
But, this is not an option for you if you're either a perfectionist or trying to fight color banding.
Color banding is a video artifact that could be visible in smooth areas of the video. Here's an example: https://youtu.be/KL8CIZej19o If you don't see the ugly background, then you don't need to worry about the whole issue.
Color banding is different from compression artifacts. You can't fight it just by increasing the bitrate of your video.
Color banding comes from color correction performed too much or in inaccurate way. And it stacks, so if you faced it, then you should get rid of dynamic range compression at every step it happens.
Cinelerra has a native full color range support, and you can enable it via: Settings -> Preferences -> Appearance -> YUV color range: JPEG Note how everything will loose contrast and become grey-ish.
But, in this mode, Cinelerra will also render full range video files. There are two reasons why it could be a bad thing: - some video players don't understand what full range is and will play these resulting videos with the increased contrast; - some image processing software (like YouTube) will re-encode full range videos into limited range by compressing the dynamic range and making the color banding issue even worse.
That's why you should make a couple of hacks. First, after your project is done, apply F_colorspace filter at the end (bottom) of the stack with these options: - range: 1 - irange: 2 Second, in File -> Render -> Video, place this line at the end of big textfield: color_range=mpeg
Since you're already fighting color banding, the good thing is to 32-bit colors in Settings -> Format -> Color model: RGB(A)-FLOAT. Note this could slow down your playback and rendering. """
By the way, if anyone is wondering "why is this guy so obsessed with such a rare issue" - well, I shoot blurry asphalt, usually misexposed: https://www.youtube.com/watch?v=B6QukURw_Og This was the good example where I was clever and minimized the damage. I have worse and don't want to look at them.
By the way^2 - I just notice the cinelerra manual is the first result for googling "mpeg color range". Cool!
However, this is a different matter from what you were asking. You could try using ffmpeg from the command line using the option: -vf "scale=in_range=jpeg:out_range=mpeg" -pix_fmt yuv420p and compare with the result obtained in CinGG to see if there are any differences.
Question: In CinGG, what format and preset do you use for the rendering to export to YT?
Nothing fancy really.
File -> Render: File format: FFMPEG mp4 Audio: bitrate 0, quality 5 (an overkill really, produces ~450 kbit/s AAC, but it's still noting compared to video) Video: bitrate 0, quality -1, pixels yuv420p, in a big field for options: crf=25 (for a 4K, must be lower for 1080p) preset=fast
This provides a nice gently compressed video for long-time storing and uploading to YouTube. -- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
Since you're already fighting color banding, the good thing is to 32-bit colors in Settings -> Format -> Color model: RGB(A)-FLOAT. Note this could slow down your playback and rendering.
Guys, hold on a second. Unfortunately I just discovered the RGB color model is required for this recipe. The YUV model causes big color shifts for an unknown reason. Moreover, I found JPEG mode completely incompatible with YUV color mode, even without any filters or hacks, and I lost the track of what's going on already. Must be just a bug because nobody tested JPEG mode in years. Could you please advise me any tool to detect shifts in color channels in order to compose a proper bug report? All I could do now is just to screenshot the difference between the compose window and render results.
вт, 3 сент. 2024 г., 20:13 Tarantas via Cin <[email protected]>:
Since you're already fighting color banding, the good thing is to 32-bit colors in Settings -> Format -> Color model: RGB(A)-FLOAT. Note this could slow down your playback and rendering.
Guys, hold on a second. Unfortunately I just discovered the RGB color model is required for this recipe. The YUV model causes big color shifts for an unknown reason. Moreover, I found JPEG mode completely incompatible with YUV color mode, even without any filters or hacks, and I lost the track of what's going on already.
Must be just a bug because nobody tested JPEG mode in years.
Could you please advise me any tool to detect shifts in color channels in order to compose a proper bug report?
one technique from https://news.ycombinator.com/item?id=20037013 make all-white png in say gimp (so each point reads as 255 in all channels) then convert it via tool in question (cinelerra-gg in our case) then measure colour values during playback (via colorpicker). it may be that bt709 conversion does not allow full range by definition? (comment from that thread). you can also try non-default pix-fmt (non yuv420p) for final encoding ? cingg use 4:4:4 non-subsampled YUV in YUV mode, may be swscale lib having trouble doing its job here? All I could do now is just to
screenshot the difference between the compose window and render results. -- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
вт, 3 сент. 2024 г., 21:10 Andrew Randrianasulu <[email protected]>:
вт, 3 сент. 2024 г., 20:13 Tarantas via Cin <[email protected]>:
Since you're already fighting color banding, the good thing is to 32-bit colors in Settings -> Format -> Color model: RGB(A)-FLOAT. Note this could slow down your playback and rendering.
Guys, hold on a second. Unfortunately I just discovered the RGB color model is required for this recipe. The YUV model causes big color shifts for an unknown reason. Moreover, I found JPEG mode completely incompatible with YUV color mode, even without any filters or hacks, and I lost the track of what's going on already.
Must be just a bug because nobody tested JPEG mode in years.
Could you please advise me any tool to detect shifts in color channels in order to compose a proper bug report?
one technique from
https://news.ycombinator.com/item?id=20037013
make all-white png in say gimp (so each point reads as 255 in all channels) then convert it via tool in question (cinelerra-gg in our case) then measure colour values during playback (via colorpicker).
it may be that bt709 conversion does not allow full range by definition? (comment from that thread).
you can also try non-default pix-fmt (non yuv420p) for final encoding ?
cingg use 4:4:4 non-subsampled YUV in YUV mode, may be swscale lib having trouble doing its job here?
I also found two possible sources of full range video -Playstation 5 (at least back in 2023) and some GoPROs and other modern h264 based cameras https://forum.shotcut.org/t/questions-about-color-range/38647/3 https://github.com/HandBrake/HandBrake/issues/2561 but may be sticking with artificial images is easier for debugging full => full encoding, then with full = > limited conversion step added on top of that.
All I could do now is just to
screenshot the difference between the compose window and render results. -- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
вт, 3 сент. 2024 г., 21:36 Andrew Randrianasulu <[email protected]>:
вт, 3 сент. 2024 г., 21:10 Andrew Randrianasulu <[email protected]>:
вт, 3 сент. 2024 г., 20:13 Tarantas via Cin <[email protected]>:
Since you're already fighting color banding, the good thing is to 32-bit colors in Settings -> Format -> Color model: RGB(A)-FLOAT. Note this could slow down your playback and rendering.
Guys, hold on a second. Unfortunately I just discovered the RGB color model is required for this recipe. The YUV model causes big color shifts for an unknown reason. Moreover, I found JPEG mode completely incompatible with YUV color mode, even without any filters or hacks, and I lost the track of what's going on already.
Must be just a bug because nobody tested JPEG mode in years.
Could you please advise me any tool to detect shifts in color channels in order to compose a proper bug report?
one technique from
https://news.ycombinator.com/item?id=20037013
make all-white png in say gimp (so each point reads as 255 in all channels) then convert it via tool in question (cinelerra-gg in our case) then measure colour values during playback (via colorpicker).
it may be that bt709 conversion does not allow full range by definition? (comment from that thread).
you can also try non-default pix-fmt (non yuv420p) for final encoding ?
cingg use 4:4:4 non-subsampled YUV in YUV mode, may be swscale lib having trouble doing its job here?
I also found two possible sources of full range video -Playstation 5 (at least back in 2023) and some GoPROs and other modern h264 based cameras
https://forum.shotcut.org/t/questions-about-color-range/38647/3
https://github.com/HandBrake/HandBrake/issues/2561
but may be sticking with artificial images is easier for debugging full => full encoding, then with full = > limited conversion step added on top of that.
and a bit more, apparently (at least in 2021) ffmpeg's prores encoder was able to stuff full range yuv data, but official apple decoders might assume tv range anyway ... https://www.liftgammagain.com/forum/index.php?threads/full-range-or-head-ran... so, while prores in general might be good idea, for full range workflow it may not work with official decoders?
All I could do now is just to
screenshot the difference between the compose window and render results. -- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
Are you using Xorg or Wayland? One possible source of problems could be Wayland still not handling colors. Another possible test is to use rec 2020ncl (with RGB-FLOAT and 10-bit color depth) instead of rec709 or 601, because it is definitely with wide gamut colors (But the color range is still limited; from 64 to 940). True that the color range of bt 709 is “limited”; from wikipedia: "Rec. 709 defines an R’G’B’ encoding and a Y’CBCR encoding, each with either 8 bits or 10 bits per sample in each color channel. In the 8-bit encoding the R’, B’, G’, and Y’ channels have a nominal range of [16..235], and the CB and CR channels have a nominal range of [16..240] with 128 as the neutral value. So in limited range R’G’B’ reference black is (16, 16, 16) and reference white is (235, 235, 235), and in Y’CBCR reference black is (16, 128, 128) and reference white is (235, 128, 128). Values outside the nominal ranges are allowed, but typically they would be clamped for broadcast or for display (except for Superwhite and xvYCC). Values 0 and 255 are reserved as timing references (SAV and EAV), and may not contain color data (for 8 bits, for 10 bits more values are reserved and for 12 bits even more, no values are reserved in files or RGB mode or full range YCbCr digital modes like sYCC or opYCC). Rec. 709's 10-bit encoding uses nominal values four times those of the 8-bit encoding, to ease the conversion it uses simple padding for reference values, for example 240 is just padded by two trailing zeroes and gives 960 for 10 bit maximum chroma.[22] Rec. 709's nominal ranges are the same as those defined in ITU Rec. 601.[23]" User DeJay did tests that are shown here at the bottom of the page: https://cinelerra-gg.org/download/CinelerraGG_Manual/Color_Space_Color_Range... PS: I would like to ask how long moderation lasts for a new user. It is now more than a week (with 7 posts) that Tarantas has been registered...
On Tue, 3 Sep 2024 18:52:35 +0000 Andrea paz via Cin <[email protected]> wrote:
Are you using Xorg or Wayland? One possible source of problems could be Wayland still not handling colors.
Xorg, under Debian stable.
On Tue, 3 Sep 2024 18:39:04 +0300 Tarantas via Cin <[email protected]> wrote:
Since you're already fighting color banding, the good thing is to 32-bit colors in Settings -> Format -> Color model: RGB(A)-FLOAT. Note this could slow down your playback and rendering.
Guys, hold on a second. Unfortunately I just discovered the RGB color model is required for this recipe. The YUV model causes big color shifts for an unknown reason. Moreover, I found JPEG mode completely incompatible with YUV color mode, even without any filters or hacks, and I lost the track of what's going on already.
Must be just a bug because nobody tested JPEG mode in years.
I filled my bug report here: https://www.cinelerra-gg.org/bugtracker/view.php?id=665
On Tue, 3 Sep 2024 18:39:04 +0300 Tarantas via Cin <[email protected]> wrote:
Could you please advise me any tool to detect shifts in color channels in order to compose a proper bug report? All I could do now is just to screenshot the difference between the compose window and render results.
I finally remember: it's called signalstats. https://ffmpeg.org/ffmpeg-filters.html#signalstats-1
чт, 29 авг. 2024 г., 11:20 Andrea paz <[email protected]>:
Aside from how CinGG works, from what I understand YT recompresses the original video even if it is set similarly to the way they compress. In short, YT's compression goes over whatever settings we make, whatever programs we use (from https://support.google.com/youtube/answer/4603579?hl=en: "Note that YouTube always re-encodes videos to optimize their playback quality"). So compression on compression leads to banding. Ideally, you should start with a poorly or uncompressed original so that YT compression leads to better results (less banding). The downside is that a poorly compressed file (Prores, DNx, ...) is about 10 times larger than an h264...
I also read somewhere in comments you can trick YT into giving more bitrate for your vid if you pretend its HDR (so 10 bit + some metadata). Not sure if it still true ...
On Thu, 29 Aug 2024 16:29:10 +0300 Andrew Randrianasulu via Cin <[email protected]> wrote:
I also read somewhere in comments you can trick YT into giving more bitrate for your vid if you pretend its HDR (so 10 bit + some metadata). Not sure if it still true ...
I've tried rendering in 10 bit, and it's even worse. The problem is: with the "jpeg" mode in "preferences", cinelerra renders in full 10 bit range, where the "industrial standard" is actually limited range of 9.67 bit. YouTube doesn't understand what full-range-10-bit is, and cuts the dynamic range of a video leading to increased contrast of resulting image.
participants (5)
-
Andrea paz -
Andrew Randrianasulu -
Igor BEGHETTO -
Phyllis Smith -
Tarantas