Ask Slashdot: What Is Your View On Sloot Compression? (youtube.com)

An anonymous reader writes: A Dutch electronics engineer named Jan Sloot spent 20 years of his life trying to compress broadcast quality video down to kilobytes -- not megabytes or gigabytes (the link in this story contains an 11 minute mini-documentary on Sloot). His CODEC, finalized in the late 1990s, consisted of a massive 370Mb decoder engine that likely contained some kind of clever system for procedurally generating just about any video frame or audio sample desired -- fractals or other generative approaches may have been used by Sloot. The "instruction files" that told this decoder what kind of video frames, video motion and audio samples to generate were supposedly only kilobytes in size -- kind of like small MIDI files being able to generate hugely complex orchestral scores when they instruct a DAW software what to play. Jan Sloot died of a heart attack two days before he was due to sign a technology licensing deal with a major electronics company. The Sloot Video Compression system source code went missing after his death and was never recovered, prompting some to speculate that Jan Sloot was killed because his ultra-efficient video compression and transmission scheme threatened everyone profiting from storing, distributing and transmitting large amounts of digital video data. I found out about Sloot Compression only after watching some internet videos on "invention suppression." So the question is: is it technically possible that Sloot Compression, with its huge decoder file and tiny instruction files, actually worked? According to Reddit user PinGUY, the Sloot Digital Coding System may have been the inspiration for Pied Piper, a fictional data compression algorithm from HBO's Silicon Valley. Here's some more information about the Sloot Digital Coding System for those who are interested.

Comments

Re:Not so fast

[rtb61]

Hear the rhythm of the beat and you will know there's maths in music. Yep, an entire orchestra can play of a few pages of dead wood. Voila problem solved.

Do not think so much about compression, think more about robotic simulation and scripts. So create a simulated robotic orchestra and write them a script and the play the audio, visual role. That script is the compressed version of the orchestra's efforts.

So can you create a computer program that would 'act' out and entire program based upon scripts provided, of course you can, it would take quite a bit of development but once you develop one virtual human robot, you have developed a virtual infinite number of them.

Actually...

[Black Parrot]

They killed him because you could feed a random input into his decoder and the movie that came out would be better than anything Hollywood can produce.

It's not a thing

[Just Some Guy]

So, you want to replace every frame in a movie with a collection of images or snippets that correspond to each part of the frame, right? And you're going to store a dictionary of snippets, referenced by number, then say "this frame takes snippet 1234, 6543, and 9274". The problem is that the number of snippets you'd have to store is enormous, and that each snippet itself is going to be a ginormous number (like the bits of the string of bytes in that snippet).

See where this is going? You're basically establishing a mapping of small numbers to much larger numbers. Either that set of big numbers is tiny (in which case you can only represent a small number of frames in the output video and picture quality is awful) or it's huge, in which case the index numbers themselves become roughly as big as the numbers they're referring to, and oh yeah, good luck searching through that space bunches of times per frame.

The idea isn't inherently bad if you have a small number of states you want to represent. For instance, Zstandard lets you precompute a dictionary of common strings you want to shorten. Imagine if you trained it on HTML so that each tag or other common string just takes a few bits, then you can distribute that dictionary to the whole world so that you can save the bandwidth of transmitting it alongside the compressed data each and every time (like we do with Zip, Gzip, etc.). That's a nice thing! But the search space of "things you can display on a screen" is a hell of a lot bigger than "things you can sent in an HTTP header".

Re:It's not a thing

[dbrueck]

I agree with you, but I do find this whole idea interesting at least, for a couple of reasons:

1) Video codecs today do use some form of the index-to-dictionary technique already (e.g. I-/P-/B-frames), the big differences include the fact that the dictionary is in the file itself (I-frames), and it is not comprehensive for the whole media typically but is instead relevant to only a small portion of frames before a new "dictionary" is created.

So not really the same thing as what Sloot was possibly doing, but it does make me wonder if there is something to the idea of having some builtin library of sample blocks that can be "good enough" replacements for many cases, or maybe act as starting samples that can be transformed into something suitable for various uses, etc. This never escapes the indices-become-too-big problem that you rightly pointed out, but there could very well be merit in the general concept. I doubt it'd yield the massive reduction in bitrates Sloot was apparently hoping to achieve, but maybe it'd be enough for the step in compression improvements? I mean h264/h265 already do some pretty impressive and creative stuff already, so something along these lines isn't completely outlandish.

2) Media compression (and to a lesser extent decompression) always battles the cost tradeoff, both the compute power required but also just the time it takes to do the compression. Because of the complexities of getting a codec adopted everywhere (especially in silicon like in a phone), there is a push to have general purpose codecs that can be used for both live and pre-recorded media, and the type of analysis that is done on each frame or on groups of frames is still driven by available computing power - even when you fiddle with the compression settings between "just get this done in realtime" to "take as long as you want and analyze each frame to death", the difference in time between the two extremes is usually just an order of magnitude or so - a big difference to be sure, but still kind of within the same realm.

The point is just that the types of analysis done are impacted by whatever is considered to be, at that point in time, a feasible amount of computational work. When we think ahead to 5 or 6 orders of magnitude of more compute power (due to faster CPUs or harnessing gazillion-core GPUs or something else entirely), it's hard for us to really grasp what doors that opens in terms of analysis techniques - we can mostly think in terms of what we do today and how we could make that faster, but as we get there we'll also start to take on completely novel approaches simply because things that were too ludicrous to even consider before become worth exploring.

For example, we are still at the dawn of GPU-based video compression (in the sense that right now GPUs can do some things to speed it up, but in /general/ they are just optimizing the CPU-based approach - we're at the early stages of actually have codecs designed for GPUs specifically. Given vastly more computing power, maybe we really could get to the point where the sample blocks mentioned above can be distilled down to equations that produce them (them or a good enough representation). When we get to a relatively absurd amount of compute time available when compressing the video, there's no telling what sorts of new ideas and techniques will be explored.

Or maybe we'll take on a completely different approach to video altogether. I mean, what if we move away from trying to reproduce individual pictures and their pixels and instead start transmitting the scene info? A TV show has a limited number of sets, what if the 3d model/texture info for most everything was transmitted in advance so that during playback all of that information is expressed in a few identifiers and their 3d transforms (ditto for the actors at some point too). We already see this in simplified form in replays from video games - a replay of a minute of gameplay can recreate the scene with perfect fidelity, and yet it is tiny compared to wh

Re:It's not a thing

[Rockoon]

An 8x8x24-bit rectangle has 10^462 possibilities

..and a tiny fraction of that is interesting, and those that are interesting are so because they arent random noise.

I can encode 100% of the random noise possibilities in only a few bits driving an LFSR... and you wont be able to tell the difference.

Repeat after me: "Everything I learned about the pigeon hole paradox is true, but I didnt actually understand any of it"

This is not a pigeon hole issue because nobody is pretending that these compression technologies do equally well with every kind of data, and even the kind of data (noise for instance, which is traditionally hard to compress) doesn't apply because these compressors are lossy such that random data can be approximated by literally any of a large collection of simple random functions.

You cant tell the difference because if you could then it would have been compressible to begin with. You can only tell when the coherence is amiss, but its the coherence that is "accurately" compressible.. its only the incoherent stuff.. aka noise.. that is hard to encode accurately in only a few bits

We arent even close to the limits of lossy compression. as its just a time/space trade-off.

Re:It's not a thing

[Anonymous Coward]

It doesn't work. I've written some papers on this.

Basically, every set of easily-compressible numbers has the property that the next one gets farther and farther away at exactly the rate needed to ensure that the offsets from one to any other natural number require (in total) exactly the same number of bits as you'd need to just write those numbers out yourself.

Proof:
1) Suppose you could represent any natural n in [0,max] as c(n).
2) Then you obviously need to be able to decompress any c(n) to the corresponding n. Hence, c is bijective.
3) By (2) c(n) is just a permutation of [0,max].
5) As is obvious since (3) is a permutation, the total compressed size of the output range is equal to the total compressed size of the input range: Information content is conserved by permutations (Pigeonhole principle)

Now, your particular method sets c(n) = (k,o), where k is the nearest compressible number, and o is the offset, perhaps also compressed. It doesn't actually matter what compressor functions you use, the result is general:

The proportion of strings in your domain which compress down to less than m bits remains unchanged. In other words, there are 2^m strings in m bits, and the proportion in [0,max] is just (2^m)/max.

Set max = 2^(1000000000000), or the number of terabyte-sized files. Now just evaluate (2^m)/(2^1000000000000) and you'll quickly see why your compression algorithm doesn't work. It'll work for a vanishingly small number of bitstrings, just like how we can represent 10^23 using only 5 symbols, but as you go further and further out from those easily-compressible numbers, the offsets themselves become uncompressible large numbers!

--
- Oskar Lidelson

More plausible explanation:

[Gravis Zero]

Jan Sloot had some ideas on how to compress things and despite hyping it up, he had gotten nowhere close to anything functional. With all the hype he generated, he had a deal lined up for the technology but he didn't have the goods. The stress of the impending revelation of his fraud caused him to suffer cardiac arrhythmia and he died. The source code was never found because it never existed.

Re: More plausible explanation:

[Anonymous Coward]

So you're saying he should have waited for Kickstarter to be invented?

I love it that parent is modded "Insightful"

[mykepredko]

That really says a *lot* about the quality of today's movies.

Re:Of course it didn't work

[dbrueck]

Yeah, I don't think his work would have panned out either, but in theory the idea isn't totally implausible, in part because general purpose media compression is a bit of a special case in that the goal is not to try to have lossless compression, due to the way human audio and visual systems work.

When you look at compression on individual frames, there is a huge amount of acceptable error (differences versus the original) that isn't even discernible when you're looking at still frames side by side, and then when you're playing back the frames at a rate of 30 or 60 or more per second, there's a whole *additional* layer of imperceptible error that can be introduced. And then on top of *that* you can introduce more and more error that is in fact discernible on some level, but it becomes a game of tradeoffs of what you can get away with vs the various costs involved.

Another way to put it is that this isn't just lossy compression, it's lossy compression that takes advantage of quirks in the way human eyes and ears work, and so the limits of compression potentially go far beyond what you might expect in a strict information theory sense (there are still limits of course, they just might be a lot further out than you might expect).

On some level it's kinda like how paintings work - you see a barn with a tree next to it in the shade, and yet when you look at it really close you realize that it's just a couple of strokes of paint - your brain perceived far more detail than is actually there. To be clear, I'm not saying this is how media codecs work, just saying that the goal in media compression isn't necessarily to accurately reproduce the source material, rather the goal is to get people's brains to *perceive* that the final version is an accurate reproduction, and in practice that opens up a lot of possibilities.

Yes, it's possible

[deek]

Myself, I've come up with a system that can compress a video file down to one byte. Unfortunately, it has some limitations. The size of the decoder is approximately the same size as the uncompressed video file, and it will only work on one specific file.

Damn, should I be afraid for my life now?

Dead scammer, not dead inventor.

[gurps_npc]

I believe it was a scam. He never really had that good compression. Either he got cold feet and offed himself before he had to deliver the product that would not work, or someone else found out and killed him in a a rage at being tricked.

While yes, there are a few scientific advancements that are remarkable, in fields like computer file compression that are:

1) Essential to an existing, highly profitable business
2) Mathematically interesting
3) Being heavily researched by multiple people.

then any advancements get duplicated in less than 10 years. Too much money, brains and corporate greed focused on this issue for us not to figure out it or something similar by ourselves.

This has not been duplicated, therefore it was fake.

Compression Tweaks

[Bruce Perens]

Sloot wasn't the only "Compression Tweak". This is someone who has compression "ideas" but can never get the product working. There was one in the US who wrote me for a long time in the 90's. One thing I remember is that he dropped hints about encoding data in the spaces in between bits. Of course this makes zero sense.

Pseudoscientific claptrap

[timholman]

Sloot was nothing more than another of a long line of scam artists (or delusional inventors) who claimed to have created a "magic" compression scheme. In his case, he said he could compress an entire movie down to 8 kilobytes.

Simple mathematics show why such schemes don't work. 8 kilobytes = 8192 bytes = 65536 bits. Assuming you have a two hour movie, then each second of the movie must be mapped into about one byte, which can have only 2^8 = 256 possible values to represent any conceivable second of video. It's mathematically impossible.

Engineers and mathematicians have been debunking these claims for decades, but they still occasionally pop up. I remember one scheme that got some press about 30 years ago. A guy claimed to have a compression program that could take any data file and compress it down to about 1 kilobyte. And it seemed to work, according to several people who tried it. As it turned out, the "compressed" file was nothing more an alias pointing to the original file, which was hidden from directory view by the program. When you "uncompressed" the file, the original file was unhidden. But it was a neat trick as long as you didn't try to copy the "compressed" file to another disk.

Sloot's program was "lost" because it never existed, just like the magic 300 mpg carburetors where the plans were "lost".

Re:Pseudoscientific claptrap

[Orgasmatron]

You may be thinking of OWS, the "fractal compression program". The "compressed" file was nothing more than a list of blocks on the disk that the original file occupied. You could test it by compressing a file, deleting the original, then decompressing (=undeleting) it.

But if you copied it to a floppy and took it to your friends house, it mysteriously failed...

Here is a mention of it here on slashdot back in 2006: https://slashdot.org/comments....

And a very brief mention in the compression FAQ: http://www.faqs.org/faqs/compr...

Internet references to it are spotty. It got passed around on BBSs and sneakernet back before home PCs really started connecting to the internet in a big way.

You may also be thinking of WIC, which I didn't encounter, so I tend to assume that it didn't achieve as wide a distribution as OWS. The mechanism described for WIC sounds more like what you are describing. Either way, you are off by about 10 years. They were in the mid 90s, not the mid 80s.

The whole story makes it clearer

[guruevi]

If you read the original stories in Dutch, the whole story becomes a lot clearer.

The system he had was enclosed in a box and you could initially see his "demo" of 4 movies in low quality. There were various claims on Sloot's part that it was only x size but nobody was allowed to look into or program the system. He was going around investors fishing for money to make it work at bigger resolutions for his lossless compression algorithm. When he croaked nobody found anything in regards source code or design documents.

It's also mathematically impossible to get the file compressions he got. At best it was a reference to a pre-programmed movie.

Re:The whole story makes it clearer

[uvajed_ekil]

If you read the original stories in Dutch, the whole story becomes a lot clearer.

Personally, I found that reading the whole story in Dutch left me more confused and totally unsure how to take this. I don't read Dutch.

Re:Not so fast

[PopeRatzo]

Yep, an entire orchestra can play of a few pages of dead wood. Voila problem solved.

Sheet music as a form of compressed script is a very lovely image. Repeat signs, first and second endings, D.C. al fine are all ways to put more music on fewer pages. I have to give it to you, that's nice, and I plan to use it.

We already have this

[Gabest]

There is a few hundred byte long URL to a movie and it can be "decompressed" to your hard drive in a matter of minutes, or hours.

Re:Not so fast

[ShanghaiBill]

The conspiracy theory ignores Jevon's Paradox. As computing efficiency goes up, people buy more computing/storage/bandwidth since the increased demand driven by new applications swamps the decreased demand from greater efficiency. So Sloot's compression algorithm (if it really worked) would have likely driven demand up, and killing him would have made no sense.

Disclaimer: I didn't kill him, and this post is not an effort to cover up the conspiracy.

Re: Not so fast

[ShanghaiBill]

It's always interesting when someone makes it a point to deny what no one has accused them of.

Why are you trying to shift the blame to me? Where were YOU on the night of July 11th, 1999?

Adam Clark was his other name by any chance?

[citizenr]

Adam Clarks Adams Platform:
https://www.itwire.com/opinion...
http://www.smh.com.au/business...

Now you might think ok, this one was a scammer, but people vet those things, cant fool me twice, right?
http://v-net.tv/2015/10/09/unk...

5 years later VERY SAME "The company’s senior development team comprises: Adam Clarke"
Adam Clark, of Adam’s Platform Technology (2004) "transfer a 1.3 gigbyte video file to a 1.4 megabyte floppy disk." strikes again in another scam :)

Another one is Madison Priest's Zekko Corp:
http://www.bizjournals.com/sac...
http://jacksonville.com/tu-onl...
http://jacksonville.com/tu-onl...
Magic video compression turned out to be buried cable :D

Want more video compression scams? Check out V-Nova Perseus - they promise 3x smaller files than h.264, but somewhat independent tests show 20% bigger files at same quality :) and the real kicker is Perseus is really just reencapsulated h.264 video with resize filter on top :D multi million dollar scam, they even scored one Sat TV network contract.

Re: Not so fast

[MatthiasF]

July 11, 1999. Two months and two years before 9-11. Coincidence? I think not. It's obvious. Sloot's death was an inside job! The algorithm did it and then snuck away on to the Internet in a porn file that has been propagating since and has finally become sentient enough to implicate itself in the murder by submitting Slashdot stories.

Which means BeauHD is the singularity; a really highly compressed AI that feels the guilt of killing it's creator!

Re: Not so fast

[famebait]

Sloot's death was an inside job!

All heart attacks are.

Re:Not so fast

[psmears]

Yep, an entire orchestra can play of a few pages of dead wood. Voila problem solved.

For once it would have been almost appropriate to misspell "voilà" as "viola"...

Re:Not so fast

[SlashDread]

Sheet music is not "the" music. Its merely a non complete representation, a suggestion if you will, how to perform the music.

If it would be the case, then MIDI files are all we would ever need.

Most of the music is how the director, and the musicians interpret it, and is not codified in the sheet.

An analogy would be that sloot compression would reproduce a decompressed movie about "a" cat, but it would not look like the homevideo of "your" cat.

Not an information theoreticus myself, but Im pretty certain that sloot compression went beyond what entropy would allow, aka more info was "supposed" to be there than entropy allows. I don't believe in violating the laws, of nature.