Lossless formats don't work. No optimization whatsoever

Help/How To
1

Hi. the files of my projects, including I few didn’t end up using in the timeline, weight 2.6 Go.
These are mostly tens of pictures, with a few audio tracks.
Using ffv1 with standard preset, the resulting file weighted 20.6 Go. What the f**k ?
It feelse like the engine copies pictures 25 times per second, which would be utterly ridiculous. Most pictures are between 1900x1200 to 1000x800, so upscaling them isn’t gonna add much Mos.
Utvideo codec does the same… 5 % done and already at 2 Go in size.
Kdenlive never did that so it’s clearly a bug.
I got that message, from either codec use I don’t remember:
plugin_mgr_get_object_file_plugins: error opening shared object file ‘/tmp/.mount_shotcuhevlF5/usr/bin/lib/ladspa/ladspa-rubberband.cat’: /tmp/.mount_shotcuhevlF5/usr/bin/lib/ladspa/ladspa-rubberband.cat: en-tête ELF invalide
mlt_repository_init: failed to dlopen /tmp/.mount_shotcuhevlF5/usr/bin/lib/mlt-7/libmltsox.so
(libsox.so.3: Ne peut ouvrir le fichier d’objet partagé: Aucun fichier ou dossier de ce type)
qt.qpa.plugin: Could not load the Qt platform plugin “wayland” in “” even though it was found.
[AVIOContext @ 0x559fe8c25bc0] Statistics: 78982 bytes read, 1 seeks
[AVIOContext @ 0x559fe8c2dec0] Statistics: 78982 bytes read, 0 seeks

Thanks for your help.
I’ve been using this software for a few days for several hours a day, so I’ll be reviewing my experience… I’ve seen lots of things I commend you for, and things I complain about, from just requiering some getting used-to, to mildly irritating, to outright crippling. At least nothing ever got corrupted so it’s overall a huge improvement over your rivals… By a long shot.

Archlinux (EndeavorOs), Shotcut version 21.10.31

2

Utvideo codec does the same

This is not a bug. That is the way it is for lossless ffv1 and Ut Video.

Kdenlive never did

Yes, it did. They are both based on the same technology - MLT and FFmpeg.

Here is a simple ffmpeg command line test for you:
ffmpeg -i shotcut-ffv1.mkv -c:v ffv1 ffmpeg-ffv1.mkv

shotcut-ffv1.mkv and ffmpeg-ffv1.mkv will be the same size.

It feelse like the engine copies pictures 25 times per second, which would be utterly ridiculous

It does; Shotcut only outputs constant frame rate. I doubt that will ever change, and I doubt you can find any multitrack video editor that outputs variable frame rate.

Most pictures are between 1900x1200 to 1000x800, so upscaling them isn’t gonna add much Mos.

Upscaling = more pixels = more bytes. Try using the default export settings and adjusting it from there.

3

Really ? Why is an “optimized” format stupid to the point of outputting 25 times the same exact frame per second ? That’s ridiculous to the utmost !
Is there any format that doesn’t do that ?
It’s true that on the other editor I used to have much more actual footages and few pictures in comparison, so you do have a point.
I don’t understand why it would be impossible for a codec to a little bit smart, and encode only bits (or shunks of pixels…) that do change, when it’s obvious that frames are nearly still, or for most of them, completely still.

Thanks for your explanations.

4

These codecs do exist, but you are not using them with ffv1 or Ut Video. That is why I suggested to use the defaults. This is the second thread of your’s where I mentioned that.

Also, the lossless H.264 preset DOES support what is called inter-frame compression that you are asking for while also being lossless. However, beware that many video players that are not based on FFmpeg will not be able to read it.

5

Ah !
I remember that bit about interframe compression. Honestly I did not understand that part of your message back then. Too much over my head.
So you’re saying that for my need loss h264 is actually better than the more “specialized” lossless formats ?
Ok, I try.

Interframe compression helps save space when recording onto memory cards by only recording the differences between movements rather than the entire frame

Shoot ! Exactly what I said. Funny, I do have good ideas so, eventhough others had them before… I didn’t understand this before.

ps: it’s for archiving needs, so screw video players. Youtube will get other formats.

6

I found:
**Third,** most lossless video codecs can be grouped into two families — HuffYUV descendants (they do spatial prediction like PNG or JPEG-LS and then code errors with Huffman codes or arithmetic coding) and LCL descendants (they compress frames with some LZ77 variation often doing nothing else). Exceptions are not very common. in Some Notes on Lossless Video Codecs « Kostya's Boring Codec World.
So the codec huffYUV should do the trick ?

Ahah "Is ffv1 the only option? It's basically worthless because it's intraframe and not interframe. It compressed my 15.0 GB PNG sequence down to 13.6 GB. For 8bpc, libx264rgb can do lossless interframe compression and shave off many, many more GB. I was hoping there was an analogue for 16bpc."
Sorry dear Shotcut, developper, indeed I’m not the first to complain that It’s so much more complicated than it should, and that tools should be a tad smarter in 2021…

7

Hey man, you need to make up your mind. Do you really need to use a lossless codec? Like do you need studio-quality/absolute no changes to your originals? Are you sure you’re not satisfied with x265 with a very high quality, something like crf16? What do you plan on doing with those shots, sell them/production/future reference or simply private use?

You can pretty much tweak every codec choice (in the advanced mode) to produce visually undistinguishable to the original, so unless you actually need absolute lossless you can get away with x265. And to be honest, if you need absolute maximum quality you should just keep the originals, any re-encode will either lose quality or increase file size like crazy.

By the way, what quality (codec and bitrate) is the original footage in (mediainfo screenshot or copy paste the text tab)? Is it movies or still pictures?

8

Huffyuv and Ut Video are both intraframe Huffman codecs. Huffyuv is compressed less than Ut Video. File sizes will be larger, but that also means the processor effort to decode it is smaller.

What kind of output is 16bpc without being RAW or an EXR/DPX sequence? Also, Shotcut tops out at 8bpc processing, so 16bpc storage would be massive overkill. I don’t understand the use case here.

This is a codec issue, not a tool issue. Shotcut doesn’t invent encoding standards. It uses standards agreed upon by the larger industry, of which no codec so far fits the requirements you’re requesting.

I understand that you’re wanting to do archive work. But how critical is this video that every byte must be perfect? I ask because there are three alternatives…

For 8bpc sources, DNxHR HQ will be well above visually lossless and survive many generations of transcoding. For 10bpc, ProRes 422 HQ as well as DNxHR HQX or 444 will do the same. These are intermediate (visually lossless) formats used to ship videos between various departments in studio workflows. They are high quality yet smaller than Huffyuv. They are still intraframe though, so Lossless H.264 will still get smaller files if the requirements only call for 8bpc or 10bpc. Again, since Shotcut only exports 8-bit processing, Lossless H.264 should be sufficient.

If a full 16bpc bit-exact codec is needed for some other workflow, there is FFVHuff which supports yuva444p16le. Exported files will be absolutely huge.

If your video has lots of repeating frames (like a slideshow with static images), then there may be benefit in taking a lossless export from Shotcut and re-encoding it with the Lagarith codec separately. (Lagarith is lossless but does not have an encoder built into Shotcut/FFmpeg.) The useful trick that Lagarith adds is the concept of null frames. If the “previous frame” and “current frame” are identical, then no new data gets written to the output file. There is a special frame type that simply says “reuse the previous frame” which can save a ton of disk space for slideshow-style videos. But if there is even slight variation to the previous frame, the whole thing has to be written, not just the error differential.

9

A matter of principles. Private use.
Perfect, I wondfer why still frames aren’t an automatic feature of all codecs on the face of the Earth. It seems like h264 will produce a file around 5 Go, which is fine. Apparently encoding to Lagarith on linux is not possible ?
I can’t be finicky about color space accuracy… Since I got those pictures from wherever on the internet, I think keeping perfect colorspace fidelity is out of the question.
Now that I’ve read more on colorspace, yuv etc… My head hurts like hell. Perfection is practically not possible in this area. Luckily it doesn’t infuriate me as much as the lack of still frames. I wish there simply was something like ffv1 plus that feature.

I realized how your knowledge of all these technicalities is just astounding. And you take much time to educate us users. Thanks.

h264 gave me 2.7 Go… Good.
But shouldn’t other codecs be equally lossless with libaom crf = 0 ? I mean in a bit by bit sense. Not considering the color subsampling issue. At least h265 has a lossless=1 flag…

10

Some of these codecs had their specifications written literally decades ago. The lossless formats in particular were written by individuals rather than corporations with massive R&D budgets. (Ben Rudiak-Gould released Huffyuv 1.1 in 2000, while Ut Video was released by Takeshi Umezawa in 2008.) When formats are written under the constraints of slow 20-year-old computer hardware and limited development resources, the end result is formats and encoding tools that were unable to perform every optimization possible. Everybody knew it was possible, but didn’t yet have the means to actually do it efficiently.

Yes. So, now we enter a modern era of time when massive R&D budgets and large development teams finally create formats that can do the optimizations you’re wanting. H.264, H.265, and AV1 all have interframe lossless modes that make them pretty much superior to Huffyuv, Ut Video, FFV1, FFVHuff, Lagarith, etc for the purpose of archiving.

The nuance here is that “archive” implies these formats won’t be expected to do anything more than simple playback. However, lossless H.264/H.265/AV1 are generally not preferred during the editing phase because they are computationally slow to decompress and merge into the editor’s compositing pipeline. These formats are so slow to decompress that it is common to use proxies over them during editing for performance reasons. Meanwhile, the Huffyuv/Ut Video crowd has minimal overhead for decompression, and is therefore very ideal to use during editing because playback and compositing will not be slowed down much by decompression. This is why Shotcut offers Ut Video as an optimized “Convert to Edit-Friendly” format. The main downside is the huge file sizes, which also requires very fast disks to feed data into the editor fast enough to avoid lag.

Not that I’m aware of. The last update to the official distribution was 2011. Having said that, I’m not sure that Lagarith would be a better choice than Lossless H.264 anyway.

Most likely. That’s why I offered the intermediate formats like DNxHR and ProRes. Perfection when using mixed colorspace sources is a pipe dream anyway, and intermediate formats are professionally “good enough” in this territory. DNxHR and ProRes are also highly standardized and well-supported formats. But if you’re comfortable with the incomplete player support of Lossless H.264, then it will probably give better compression and smaller file sizes.

This is normal. :slight_smile: This is also why I answer as many questions as I can for people here, because there is no fast and straight-forward path to finding these kinds of answers even in the age of the Internet.

That’s basically Lossless H.264/H.265/AV1. The nuance with these codecs is that they specialize in throwing data away (lossy compression), but we’re specifically telling them not to throw any data away. So we are severely limiting their compression toolsets by doing this. My recommendation would be trying lossless encodings of one of your sample videos using all three codecs. Compare file size versus encoding time. My guess is that the file size improvement of AV1 may not be worth the encoding time overhead compared to H.264. H.264 is simpler and therefore faster. In the case of lossless encoding where no data is thrown away, “simple” can be an asset of speed rather than a liability of efficiency.

11

That sums it up ! Thank you a lot !
Would you say an instruction like “don’t do anything, just repeat the damn frame !” was not possible with old pcs ? It should ask less resource, so in my mind still frames should be an old trick, not a new one…

Exactly, files could be a .zip for what I care. I don’t need to play huge files, just to extract informations from them, making proxies out of them in say, less than two hours.
I do what you suggest.

I wonder if mixed color space (or resolution) really is a pipe dream ? Unless it switches every frame or so, I think modern computers could handle it well ? That would avoid up/downscaling issues etc.

12

Conceptually, yes, it’s a simple trick. But this requires a software encoding framework that has the ability to look backwards to the previous frame to make that comparison in the first place. That multi-frame pipeline is a big request to make of slow hardware with limited RAM – and even moreso, of old software design methodologies and developers working independently.

Yes, one codec could write a custom encoding application for itself that could hold just the hash of the previous frame to reduce memory requirements for comparisons, but now that codec is doing super-specialized stuff that prevents it from being bundled into a tool like FFmpeg that supports multiple encoders through a unified pipeline. The big question is, “how would a multitude of codecs look at previous frames in a standardized way so we can create a unified encoding framework or tool?” It took time and standardization and lots of developers working together before that framework emerged. The devil is in the details.

Mixed color space? Yes, pipe dream. BT.709 YUV and sRGB are about as similar as two colorspaces can get, and even they have colors in one that are out of gamut of the other (look up “illegal YUV values”). If a higher colorspace is ever ingested, like BT.2020 imported into a BT.709 project, then by definition, there are colors that the BT.709 project will not be able to represent because its color gamut is not as large as BT.2020. It’s impossible to be truly mathematically lossless in those scenarios. Even YUV-to-RGB conversions have accumulated rounding errors.

Mixed resolution, by definition, is not lossless unless it is upscaling by an integer nearest neighbor amount. Any other scaling algorithm is likely to create more visible artefacts than a visually lossless codec would create.

13

Let me suggest something that may already be obvious: rather than archiving a lossless slideshow, why not archive the still pictures together with the audio files and the .mlt file that can turn them into a slideshow? Then you can generate whatever level of compression and quality that you wish “on demand” while always having the best quality originals available.

1 Like
14

Exact, I know.
Thing is I fear the .mlt project will be impossible to read in ten years or so ! I know 10 years is stupidly far ahead, but even a few versions from now I doubt Shotcut will be able to read it correctly. And there are a few effects here and there, which would be even less portable, I fear. If and only if there was a working standard for timelines or whatever you call it.

I understand. So to simplify the work there should be an effect indicating “from this time to this time, still frames” so that no guessing or comparison has to be made afterwards. That would be the “freeze” effect + nothing on top.
Otherwise, yeah, the hell of standards. It’s one of the biggest faillure of the human mind: our inability to work in grouip in a coherent way. Damn, I feel like a communist now… One colorspace, one computer model, one CPU architecture, etc… to unite them all. Can ýou hear the Internationale ? I do. I’mma off myself now, because I thought I was far right unti now…

15

If your goal is to archieve still images for the future, why the hell do you want go generate a “lossless” slide show out of them? Keep them as pictures (jpg oder RAW for quality sake) and generate the slideshow any time later you want. There will (i hope) always be possibilities to read jpg (not sure for RAW) in the next 10 - 30 years (and probably even 100 years) but not sure for an old-fashioned video codec. I concider mpg4 (h.264 and h.265) as solid as jpg for the next years but dont waste memory space for a slide show on still images! And its better to copy the images every 5 years to newer disks or whatever storage you use, than generating slideshows for the eternity :slight_smile:

16

Except it’s not static all the time, I’m seen talking as well and there are effects. A mixed bag it is.
I’m fine with h264 thus far, the sizes match my expectations.

17

o.k. when you have video snippets inbetween its something else. If you only want to combine still images you will always find a slideshow generator - with even more features in the future :slight_smile: Dont give too much on simple effects - its getting boring if seen more often :wink: And thats also true for any special video effect that you might want to add now - less is often more here in the long run!

18

I’ve yet to try the generator !
You’re right, I’ve deduced one would quickly grow weary of effects. It’s a delicate balance, isn’t it: too static is boring, but dynamism has to to vary, yet not too quickly or too much or it gets ugly or tiring in its right right.
I’ve grown to like doing these things, even though I’ve never been an artistic guy at all.

19

This topic was automatically closed after 89 days. New replies are no longer allowed.