Yes, I considered that, but then the most technically-correct solution would be to create two Ut Video presets, one for YUV422 and one for RGB. I had not seen two presets created for other codecs, so I went with the one that is likely to get used the most. If you’re open to adding a RGB preset, I’ll research the lines that need to be added.
Good work, Austin.
For anyone noticing color problems with ffmpeg scripts, I’ve now noticed shifts in ffmpeg 4.0.2 with codecs other than Ut Video when using zscale to change a JPEG-range video to MPEG-range. Even libx264 shifted colors in one scenario, but was fixed with the same “-colorspace 1 -color_primaries 1 -color_trc 1” hack I did for Ut Video. I’m thinking of leaving those three switches in there all the time just to be safe. Something to be aware of, as this issue may be more related to zscale output than to specific codecs.
What is the difference between scale and zscale? The docs are not very clear on this.
The zscale filter references an external library called z.img that has only recently been compiled into ffmpeg as standard. Meanwhile, scale is internal to ffmpeg and has been around forever.
A seemingly large number of people online prefer zscale over scale because it does a better job with colors if any RGB-YUV or 601-709 conversions take place. I haven’t used it enough to verify this claim myself, but what I like about it so far is the addition of dithering options during a downsample. This helps reduce banding when making small proxies from 4K sources.
I upgraded to ffmpeg 4.1 and still having the problem. Same hack still fixes it.
Thanks for the explanation.
@shotcut, what do you think about Austin’s suggestion about having one Ut preset for YUV422 and another for RGB?
And great work on that post, @Austin.
Is 4:2:0 supported by UtVideo? Add that too because it is so common.
I am not going to add a bunch of variants of many of the presets for different pixel formats. It would start with Ut Video and then requests will follow for others; that always happens. But that proliferation is too cumbersome or confusing for most users. I may be willing to change the existing Ut Video presets to use RGB.
I understand wanting to avoid cluttering things up but isn’t this Ut Video color situation a unique problem? Are all of the DNxHD and HDV preset variants needed? Unless I am missing something the only differences among them seem to be the resolution and frame rates which are already handled by what the video mode is set to.
I agree about clutter and confusing new users with too many presets. DNxHD is a perfect example. I never use that format, so all the variants are clutter to me. Granted, I understand their convenience when submitting video to TV stations where the settings have to be absolutely right, so I wouldn’t lobby to remove them. But to the point, lots of people will never use Ut Video, so there’s no reason it should clutter their list either.
Fortunately, Shotcut already has YUV422 and RGB versions of the Ut Video preset. When I made that comment about a second preset for RGB, I forgot that Dan created a Ut Video preset under the “alpha” section too, which by nature is already in RGBA. I think RGBA would be sufficient for non-alpha RGB users too. The alpha channel, if unused, is a solid color and therefore compresses really well. In my tests, having the unnecessary solid alpha channel added just under 10% to the exported video’s file size compared to RGB.
May I suggest renaming the lossless preset to “Ut Video 422” and renaming the alpha preset to “Ut Video RGBA”? (I feel 422 is too important to forfeit completely to RGB.) Those two presets should cover the bulk of export cases from Shotcut. After all, Ut Video is for pretty specialized purposes.
The 4:2:0 situation is more interesting. Ut Video does support 4:2:0 and it does create a smaller file than 4:2:2. However, Lossless H.264 (CRF 0) will create a file that is 33% smaller than even Ut Video 4:2:0. The major advantage Ut Video 4:2:0 has over CRF 0 is decoding speed for smoother editing and playback of multiple tracks. But if I’ve got that many tracks going on, I’ll be in proxy mode anyway. And when it comes to generating proxies, there are massive benefits from transcoding directly with ffmpeg because it becomes possible to specify a spline36 scaling filter with ordered dithering then follow it up with an unsharp mask and zscale colorspace conversion to make that proxy video clear and sharp as possible. I’m typing up a post for the Proxy Generation topic detailing exactly how this all works, but the takeaway is that going the extra mile with ffmpeg processing yields a perceptual sharpness gain of about 3x without having to increase resolution or bitrate or compromise colors. But you can’t get that processing chain from a Shotcut preset. All that to say, I’m not sure a Ut Video 4:2:0 preset brings anything to the party when Lossless H.264 makes smaller files and ffmpeg makes better-looking videos.
I agree that Ut Video 4:2:0 could have some useful specialized purposes. But power users will know how to tweak their presets if they want this or other formats. New users, meanwhile, wouldn’t know what to do with so many lossless variants anyway. Sounds like a “less is more” situation to me.
Ah, so that takes care of that.
Looking forward to it!
How do you come by this 3x figure?
Any word on the results for ProRes and/or other codecs?
Sorry for the delay.
Here are my test results for ProRes using the preset in Shotcut 18.11.18:
Did you check out the new beta? I’m wondering what you make of the color improvements on it.
No, but I’ll test it when it’s out of beta. Please remind me when the upcoming version is out of beta. Did he do any changes to color in the next version, such as export presets?
Yeah. His notes are here for the beta:
Fixed color accuracy of lossless/Ut Video preset and use yuv422p format
You should test both the Ut presets (the one in the Alpha category as well as the one in Lossless) as well as anything else while it is in beta so that if there are any issues he could makes the fixes before the final release.
The whole point of having the beta version, is to address issues so they can be fixed.
agreed. @chris319 if you find issues with the beta they can potentially be resolved prior to release.