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.

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

[Anonymous Coward]

https://rogerjohansson.blog/2008/12/07/genetic-programming-evolution-of-mona-lisa/

You were saying?

Re:It's not a thing

[wierd_w]

For any given number of any given complexity, there are adjacent numbers that have significantly lower complexity.

I have toyed with the idea of using "indexing" between two points on a number line, where the two points are very low complexity, but the number you want is somewhere between-- With a high precision percentage of the now clearly defined space between the points on the line, we can skip over and start playback of the number we want, if we also state how many digits this number is.

Say, the number we want is between 10^23 and ((10^23)+(10^10)). Those are both impossibly huge numbers, but they can be defined very easily because they are not complex. We will then say that the number we want is found 10% of the distance between those two numbers, and that it is 10^6 digits long.

Just using some fun math with the natural logarithm, we can produce that number, from those modest ingredients.

Video files are just very very large numbers. They could be found on the infinite number line in exactly the same way.

A complex encoder that has broken the file to be searched into a series of smaller (and thus easier to compute/derive) numbers that get concatenated together, and has a working knowledge of number space for numbers of those data block sizes, could reduce hundreds of megabytes into a few kb of metadata. The decoder would have to compute very large numbers (or have very large numbers already stored statically, and just crawls along...) to initialize the playback, but it could easily do so using nothing but lots of RAM and brute force CPU.

I have considered looking into creating a compression system of this type myself, which is why I find it kinda spooky that it would need a huge decoder.. because my theoretical system would need a huge decoder too.

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.

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.

You don't know what you're talking about

[Anonymous Coward]

The presumption isn't that it actually stored images but more likely that it contained numerous generators. It's entirely plausible is that similar to the way a neural net uses a combination of several algorithms to classify images, a similar approach could be taken to constructing them.

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.

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.

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.

Anything is possible. Practical though?

[LostMyBeaver]

I theorized that the Mandelbrot is capable of generating any string of data of any size given a high enough resolution, high enough iterations and enough time to process it. I haven't retested my theory on scale since 1998 (significant because of general availability of GPUs... if you count Voodoo2 as a GPU), but processing on a 486DX-50 with 16 megs of RAM and Linux allowed me to search for simple strings (kilobytes in size) within reasonable time.

What I found was that every 4KB sequence I randomly generated as part of a set was able to be located within the Mandelbrot set. Results generally were found in the nautilus or horse tail areas. I used several search methods.
1) Linear
2) Rectangular spiral clockwise (variable width, variable height)
3) Rectangular spiral counter-clockwise (variable width, variable height)
4) Zig-zag in 45 degree rotations and variable width and variable height)
5) Elliptical Spiral (clockwise and counter-clockwise, variable width, variable height)

I also experimented with added dimension which included iteration as a 3rd dimension when pattern searching allowing strings to extend across multiple iterations in cubical, spheroidical, etc... footprints. I had to abandon this effort due to computational complexity.

I also experimented with experimenting with adding bit layers as a 3rd dimension when searching, but this added even greater computational complexity than the previous method described above but certainly promised greater results.

The algorithms I used were exhaustive. So where a video motion vector search algorithm would abandon searching a given direction for performance reasons when the delta values in said direction were not yielding results, I searched every pattern type for every pixel for every parameter... etc...

Now, given my computational capacity and limitations of the time, the average seek time per 4KB string before finding a result was 1-2 weeks. All my code was heavily optimized to exploit memory as it was used on the architecture. Consider a combination of Michael Abrash style coding/optimizations with more specific knowledge of the specific CPU and memory it would run on. I also spent a great deal of money getting memory with 60ns response time (though I never measured better than 64ns on the scope). I also used a Micronics motherboard which at the time meant something as Intel had yet to enter the chipset market and as ECC memory was far too expensive... for pretty much anyone on that scale, and the memory controller was not yet part of the CPU, I needed a reliable and documented chipset to work with.

Ok, so here's the summary of all the results
1) It is worth investing greater effort in scientifically proving that absolutely any string can be found in the Mandelbrot Set given enough iterations, resolution, search creativity and of course CPU power.
2) It is believed (though through non-thorough experimentation, not mathematically proven) that any 4KB string can be found in the Mandelbrot Set
3) Once found, depending on the resolution and number of iterations provided as a coefficients for identifying the set, the data can be retrieved in a reasonable period of time (deterministic, though variable) on any device. The real computational cost was the search itself.
4) This method of compression has no value for video as the data sets are too large.
5) It is most common that longer string lengths searched for often requires higher resolutions and higher iteration counts to be found. This is common, not a rule. Depending on the search pattern, often strings with a more level histogram distribution could be found as bit patterns in lower resolutions and iterations.
6) The size of the strings found increased far more rapidly than the size of the coefficients required to represent the find. Meaning without employing additional methods such as entropy coding the :
- resolution of the Mandelbrot image,

Re:Anything is possible. Practical though?

[guruevi]

You can take any irrational number and find any value in it. The problem is that you can't truly compress anything that way, your coefficients will be the same size or larger than any number you're trying to get as a result (the optimum compression can never be better than 2:1). If you're looking for "lossy" compression (basically, some values (but no more than x %) can change, you'd still have to look through the nearly infinite space for possible values and at best you'll get some compression close to whatever entropy allows.

To encode all data that's currently being stored or generated this way by humankind, your encoder would have to work through ~2000 exabytes.

Re:Of course it didn't work

[Anonymous Coward]

This is how literature works... a short story is in effect a full movie highly compressed down to a few kilobytes. 'Reading' is decompressing the data.

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.