Lossless annoyances

Hello everyone, I recently started video editing on Windows using Shotcut based on a recommendation, and so far it’s been great to use. However I’m having great trouble exporting lossless videos. I did a little test where I imported a losslessly-encoded video into Shotcut then re-exported it using “lossless” presets, only to get lossy output, and with huge file size too… I already checked the tutorials, FAQ, and this forum. I’m sharing my findings here to know if I’m doing something wrong, and hopefully get some advice.

First off, this is my source file: https://u.teknik.io/6SrK4.mp4 [0.4 MB, lossless]
It’s a 7 seconds long recording of a screen at 60fps. Originally encoded using the ScreenPressor codec, then losslessly re-encoded to H.264 using VirtualDub, with the color space set to “same as source” (rgb), then uploaded to the link above. Take good note of the duration, and the file size…

Here are the results of a simple Shotcut export at various “lossless” presets.

lossless/H.264                      10.4 MB, lossy, with minor glitches.
lossless/H.264 & codec=libx264rgb   10.1 MB, lossy, with major glitches.
lossless/FFV1                       14.8 MB, lossy.
lossless/FFV1 & pix_fmt=rgb24       12.7 MB, lossy.
lossless/HuffYUV                    170  MB, lossy.
lossless/Ut Video                   92.9 MB, lossy.
intermediate/DNxHR HQ               139  MB, lossy.
intermediate/MPEG-2                 24.8 MB, lossy.
intermediate/MPEG-4                 25.1 MB, lossy.
intermediate/ProRes 422             51.3 MB, lossy.
intermediate/ProRes HQ              59.1 MB, lossy.

And here are the results of alpha presets, which produced lossless output, at ridiculous file size.

alpha/Quicktime Animation           76.4 MB, lossless.
alpha/Quicktime Anim. & pix_fmt=rgb 59.6 MB, lossless.
alpha/Ut Video                      178  MB, lossless.
alpha/Ut Video & pix_fmt=gbrp       138  MB, lossless.

Visual comparison:

“lossless” in Shotcut export does not imply the image goes through the engine untouched. It simply means that the codec is lossless or in lossless mode. The engine does not support every pixel format and color space in existence – only a few. Often sources get converted going through the engine. In your case, the source is RGB, but the engine defaults to yuv422 unless it has an mlt_image_format specified in Export > Other. For your 6SrK4.mp4, you would need mlt_image_format=rgb24 Also, in order to avoid image changes, you must use a Video Mode that matches the source and must not use any effecs (multiple video tracks, transitions, filters). (A mismatching video mode can cause automatic deinterlace, colorspace conversion, scaling, and padding).

lossless/H.264 & codec=libx264rgb 10.1 MB, lossy, with major glitches.

Yes, obviously this mode is broken and a bug. We would appreciate your help to debug it.

intermediate/DNxHR HQ 139 MB, lossy.

Intermediate is not lossless. So, skipping those.

alpha presets, which produced lossless output

These all use mlt_image_format=rgb24a as mentioned above.

I reproduced this one. First, I check what ffmpeg does since we are using its codec:
ffmpeg -i 6SrK4.mp' -codec:a copy -codec:v qtrle -pix_fmt argb qtrle.mov
It shows 7.4 MB
Then, I made an export in Shotcut from the Source player with Video Mode Automatic, but in Export > Audio I disabled the audio to prevent that from being a cause: 80.1 MB. Why? I compared the output of mediainfo against both and found this:
Bit rate : 8 343 kb/s
Bit rate : 91.3 Mb/s
Not sure what that is about. I tried changing some rate control options, but they did not affect it.

In any case alpha is not your target. How about Ut Video? Choose that preset, disable audio again, and in Other change:


And I get lossless (as far as I have determined) but 144 .5 MB. Next, I use ffmpeg for comparison:
ffmpeg -i 6SrK4.mp4 -an -codec:v utvideo -pix_fmt gbrp 'ffmpeg utvideo gbrp.mkv'
I get lossless 144.5 MB. So, the same! But still not small like you want. Not all lossless codecs are designed for maximum compression, but FFV1 should be much better. Pick that preset in Shotcut, disable audio, and in Other:


(rgb24 is not a supported pix_fmt for ffv1).
24.7 MB. Now, that is much better. And ffmpeg, for comparison, 24.7 MB:
ffmpeg -i 6SrK4.mp4 -an -codec:v ffv1 -pix_fmt bgr0 -g 1 -coder 1 -context 1 'ffmpeg ffv1 bgr0.mkv'

I had to add -g 1 to make the file sizes match. Otherwise, ffmpeg was slightly less. Maybe that is the reason for big difference on Quicktime Animation. Yes, I return to that ffmpeg command line and add -g 1 and now the size is slightly more than Shotcut’s at 80.2 MB. So, again, the same.

I found that changing GOP to 250 for FFV1 also reduces the size further, but I suppose all these are inferior to x264rgb. I did verify that using ffmpeg with libx264rgb lossless and long GOP does produce a small file: 405.2 kB.

In summary,

  • libx264rgb in Shotcut is a real bug
  • as a workaround, use FFV1, but
    • increase GOP to 250
    • remove intra=1
    • add pix_fmt=bgr0
    • add mlt_image_format=rgb24

That worked, thank you very much. 18 MB is manageable.

Just to be clear, you mean that the project must have the same resolution/orientation/fps…etc as the source, right? If so, this was true in my case.

Sure thing, what do I need to do?

That’s new to me. From what I understood online, intermediate formats were lossless because they’re used for editing. Like when you edit one video and need to export it lossless because you’ll edit it further.

The article glosses over a few distinctions for sake of brevity. There is a difference between “intermediate process step” and “intermediate file format”.

She used the word “intermediate” to represent a workflow step, for which any number of file formats could be acceptable depending on quality requirements. Her article chose to focus on lossless formats because they have the highest quality. So that’s technically described as a “lossless format for the intermediate step”.

But a true “intermediate file format” (also called mezzanine format in some places) is only visually lossless, which means some color information that the eye can’t detect (even after a pretty hard color grade) is thrown away to get file sizes down, and the decompression algorithm is optimized for speed to make editing smoother. These formats (with ProRes and DNxHR being examples) are frequently used in studios for speed and space reasons. For most practical purposes, they are indistinguishable from a true lossless file. They are also popular because lossless files have a tendency to not play back fast enough at 4K.

The Shotcut export presets are properly categorized by whether they are truly lossless (mathematically bit-for-bit exact) or visually lossless (technically lossy, but undetectable change to the human eye).

One other note… if your videos are screencasts, you might find these two presets useful when ready for the final export. The file sizes are ridiculously small:

1 Like

Beware these do not output RGB and are not lossless. However, a lot of screen and video conference capture tools record in YUV, or a person is more interested in a more compatible output (i.e. YUV) and willing to accept loss, where these certainly do make sense.

I took a brief look into the libx264rgb bug last night, but I did not find anything. I suspect there is something wrong with the colorspace conversion. The code (mlt/src/modules/avformat/consumer_avformat.c) is using libswscale, of course, but perhaps some argument is wrong for this particular conversion (i.e. colorspace, range). I will bookmark this bug to revisit this, but in the meantime, for the next release, I am removing libx264rgb from the list of available codecs in Shotcut UI.

I just fixed the bug with libx264rgb for the next version 20.06!

323 KB


Thank you very much for the explanation, and for the 2 Slide Deck presets. I took some good ideas from them to use in my ffmpeg batch files also.

This is great news! Thank you very much. :clap:

I did a little test yesterday where I tried converting a video using ffmpeg (latest version) with libx264rgb, and noticed major glitches in the output similar to what I was getting with Shotcut… But then I tried an older version of ffmpeg (2.8 from 2015) and the conversion completed successfully with no glitches, so maybe the issue originally came from ffmpeg? Just sharing this information here in case it’s useful to anyone, the command I used was this:
ffmpeg -i input.mkv -c:v libx264rgb -preset veryslow -crf 0 output.mp4

Do we care much about multi-generational loss?

It’s intuitive that lossy compression will degrade the content with each successive pass, such as when video is resampled by YouTube, etc. Is this concern realistic? I have uploaded “lossless” videos which are large and thus take a long time to upload. If the final destination is YouTube and no further resampling is anticipated, I can see where lossless has its disadvantages.

Color fanatic that I am, I’m concerned about color fidelity as well as motion artifacts, and audio too.

Sorry to necro-bump the thread, but libx264rgb still glitches. :worried:
I’m pretty sure this issue is related to ffmpeg, as I mentioned earlier in the thread.

On a related note, a better alternative to lossless FFV1 is VP9. The output has a file size similar to libx264rgb, albeit with slower encoding speeds. Drawing inspiration from Dan’s answer, here’s my preset for lossless VP9 with RGB color space: https://u.teknik.io/iEtlh
For faster encoding speeds at the expense of file size, add these two lines to the preset:


Update: the libx264rgb glitch persists only on Windows.

I ran the Shotcut appimage on linux and it exports perfectly through libx264rgb, ffmpeg seems to have no issues either. I’m not sure why this is a Windows-only problem, but it’s not that big of a deal to me as I can use linux anytime.
Just writing this here so other Windows users are aware of this issue.

weird. I do not know if this is a x264 or FFmpeg issue. The next version of Shotcut upgrades FFmpeg to version 4.3, and that might make a difference.

This topic was automatically closed 182 days after the last reply. New replies are no longer allowed.