Slashdot Mirror
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.
If it were just as easy to kill off someone to "solve" an issue like this then the bitcoin scaling debate would have been resolved a long time ago...
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.
Sheesh, evil *and* a jerk. -- Jade
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".
Dewey, what part of this looks like authorities should be involved?
In the same way that millennials are able to compress two or more genders into a single body.
Information theory stablishes what is really possible and that kind of compression is simply to much, even considering its lossy nature. Infomation entropy has very real limits no matter the encoder used in the data compression.
Do you think he considered mean jerk time to solve this problem?
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.
Anons need not reply. Questions end with a question mark.
That really says a *lot* about the quality of today's movies.
Mimetics Inc. Twitter
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.
What the world wants (although they are now mpeged into submission) is lossless compression. Lossless compression needs large files, no matter how much fancy maths you might throw at the problem.
I'm not sitting through an 11 minute video to see if there are any examples of his compression - in particular the output compared to the input.
But the proof is in the pudding - what was the output quality like?
Specialist Mac support for creative pros, Melbourne
Sloots are gonna sloot!
If the video is 11 minutes then there is no concept of compression
What was that file format that was parts of sampled songs that were played back like a midi? It was "popular" in the late 90s I think. Maybe earlier. Pre MP3.
Sounded like a chopped up version of the original song. Much larger than midi but much smaller than wav.
Do not meddle in the affairs of sysadmins, for they are subtle, and quick to anger.
Let's say you want to transfer an image on a coin - you could pass it by the flat side into a circular opening, which means that the amount of area needed to transfer the coin is Pi*r^2 where "r" is the radius of the coin.
BUT, if you were to rotate it in space 90 degrees, and this is where the genius lies as it doesn't matter what part of the disk you rotate, then you can slip the coin into a thin rectangle which has much less area than the circular opening. In this case, the area required is 2r*thickness.
To give you an idea of how amazing this is, look at what happens if the thickness of the coin is 1/10th the radius of the coin - the amount of area required is 314.159 times *less* if you were to use the rectangular opening (which we call a "slot"). The less the thickness of the coin, then the better the improvement in area (which is the amount of space needed to transfer the coin).
Sloot's genius was figuring out, in software, how to represent video data as a circular disk, rotate it 90 degrees and transfer it using very little bandwidth to a receiver which could reverse the process.
Mimetics Inc. Twitter
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?
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.
excitingthingstodo.blogspot.com
Back in the day when Dr. Dobb's Journal and other computer magazines were a thing, one editorial writer was reflecting on how allowing multiple levels of an analog signal could encode more than one bit per symbol or cell or splotch or what have you. The idea was extended to a very hard, dimensionally accurate ruby rod upon which a very thin scribe line was made, and the writer mused that a very large number of bits of data could be encoded on that one physical object.
Since Claude Shannon's insights, Information Theory is also a thing. The number of bits goes linearly with the number of symbols or cells or optical splotches, but it only increases with the logarithm of the number of signal levels represented by those physical objects. A 16 bit unsigned integer can encode 2^16 or 65536 levels, 32 bit encodes about 4 Gig whereas a 64 bit unsigned integer encodes a number of levels exceeding most counts of objects in the known Universe -- think of tale of the king wanting to reward the inventor of the game of chess with anything he wanted, and the dude asked for 2^64 grains of wheat (one grain on the first chessboard square, two grains on the second, four grains on the third, and so on).
Turning this relationship around, scribing that ruby rod to the precision of, dunno, the Planck Length, gets you what, only a 100 bits of storage or something like that?
You are finding a related fallacy in this super video compression scheme?
I had a similar idea to develop an algorithm that would follow through and propagate successive frames of motion in a video, first analyzing it to create certain required textures and meshes, then applying it to various meshes that would be created by tracking the individual characters, objects, and sets in a video. I always believed it could work but it's a huge undertaking.
Twinstiq, game news
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.
Bruce Perens.
It's not pratical even in your example. Multiple data samples will end having the same hash, unless you create a really, really big hash. You see were it's going? Compression is a difficult problem even with use of a lot of computational power.
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".
Marketeers and viral promotion dept. working the narrow channel on this one. Right audience, of course.
The problem is that you would also discover a very large number of character strings having nothing to do with Shakespeare which would hash to the same value.
You can't do that without collisions.
What you throw away, you cannot get back. Think of compression as a plastic bag filled with snow and maybe a little air at the top. Assume air represents '0' and water represents '1'. A snowflake can be said to be represented then by a sequential pattern of 0's and 1's. The more you squeeze the bag, the more air (0's) you throw away. Initially you're merely squeezing the air at the top out but as you continue to squeeze this bag, you start throwing away the 0's contained within the snowflakes themselves, in so doing the shape of the snowflakes becomes less and less defined. Squeeze all of the air out and you're left with water and absolutely no notion that the original defining shapes of the snowflakes.
Lossless compression in a sense only squeezes the air at the top out. Lossy compression continues on and erodes the actual pattern defining the snowflake. No matter how clever your algorithm is at deflating the bag, there are very real limits to how much you can squeeze before you stop being able to recognize the contents as the snow you once put into the bag. Procedural generation is a form lossy compression. Minecraft worlds are procedurally generated from small seed strings. These generated worlds are very impressive in their complexity and expansiveness. However, from those seed strings you have precious little control over what is generated. You cannot simply change the seed from "aaaaaa" to "aaabaa" and lower the height of a hill by 2 meters at coords 100,50 without very drastic changes propagated elsewhere throughout the entire world.
If someone killed Sloot it wasn't to suppress his invention, it was to save face for being conned by him.
Two of my imaginary friends reproduced once
First of all, the guy who made the documentary didn't invent black bordered subtitles, and white on white is not easy to read.
Then, people who actually saw Sloot's invention talk about "movies" without any more details, like length or quality. Not much convincing. So, maybe Sloot invented a device that simply uses a kind of wifi?
Slashdot, fix the reply notifications... You won't get away with it...
Reminds me of KGB Archiver.
This level of compression translates to AI vision.
... interesting to say the least, as the hallucinated playback would heavily reuse "stage props", just as human brain does.
While retina and optic nerve run roughly at 8Mbits (retina already does a lot of pre-processing), visual cortex reduces this to 10kbit/s per eye and feeds it further into brain. Which is the same ballpark claimed by this kook.
It's obviously possible with *heavy* post processing to make very high representation of objects perceived. To replay, you need to hallucinate it back (akin to dreams). Problem is you need something as good as humans visual cortex, while modern ML vision is on the level of a fruit fly. Also, the fidelite would be
[1] Anderson, C.H. et al. (2005) Directed visual attention and the dynamic control of information flow. In Neurobiology of Attention (Itti, L. et al., eds),
[2] Norretranders, T. (1998) The User Illusion, Viking
None view.
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,
They discovered compressed Sloot footage of Seth Rich faking the Apollo moon landings.
Except that most people answer are like thinking HDTV in 1080p,
back then you are talking about doing video compression
for like Windows 95 or Windows 98 SE
in 640x480 x 16-bit video...
or maybe 800x600 x 16-bit video...
or maybe 1024x768 x 16-bit video
If you are using something like LPAQ (which is quite faster than normal PAQ compressor)
and some adaptive neural network and lots of pre-trained data for a specific color palette,
maybe you could get away with it in such low resolution.
For example, PAQ8K works with binary data and PAQ8PX works with WAV audio data files,
but it's extremely slow.
Also, in the case of ZPAQ, you do not really encode data, you encode a neural net machine byte code
that will produce the actual data...
"Decompression algorithms are written in a language called ZPAQL and stored as a byte code which can either be interpreted or converted directly to 32 or 64 bit x86 code and executed. "
However, back then with like a Pentium 166 MMX you would not go far about doing anything crazy,
it would be way too slow.
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.
Custom electronics and digital signage for your business: www.evcircuits.com
does this mean Comcast will start cramming an order of magnitude more TV channels down my
pipe?
If this is the one i remember, it worked by caching a absolute s#!& ton of data to the end devices. Once the 'index' was cached you could play SD video over dialup.
But you need to download a 370 Mb CODEC for each one.
Have gnu, will travel.
Well i'm not a fan of fat Sloots so I would prefer them to be compressed. By what means they get compressed I care not.
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.
I have a friend who invented an alternative to tracking time in place of the proposed time_t. Just 24 hours before he was to present it at a conference he was found murdered. I'll never forget the day it happened - January 1st, 1970.
There's already a way to compress a movie down to a few KB. You simply post it as a torrent and let other people store it on their computers. After it's been well-shared, you can simply delete it from your machine. Can't beat that level of compression. See, I've included Big Buck Bunny in this post:
magnet:?xt=urn:btih:88594AAACBDE40EF3E2510C47374EC0AA396C08E&dn=bbb_sunflower_1080p_30fps_normal.mp4&tr=udp%3a%2f%2ftracker.openbittorrent.com%3a80%2fannounce&tr=udp%3a%2f%2ftracker.publicbt.com%3a80%2fannounce&ws=http%3a%2f%2fdistribution.bbb3d.renderfarming.net%2fvideo%2fmp4%2fbbb_sunflower_1080p_30fps_normal.mp4
---
DRM is like antifreeze, to the MPAA/RIAA it's sweet, to the consumers it's poison.
Here's my 100kB solution for any movie ever made: The 100kB is an integer index into the base16 digits of pi, and a length.
The decoder is really simple, but the encoder currently takes longer than we have left until the heat death of the universe.
Please fund my compression/encryption library π-coder!
512kb seems a bit crazy. I don't think that it can be done in that little space. That being said, I would not be surprised if someone came out with something 10 to 30 times better than what we have now.
i want to show you dwitter. It's a website where people make graphics demos using 140 characters of javascript.
If you think about it from the prespective of compression, then yes, dwitter could be thought of as a compression/decompression system. you give it 140 utf8 characters and it can produce hundreds of different video streams each containing many megabytes of data.
Most 'demoscene' environments are like this. Someone came out with a demo for the IBM PC 5150, using an 8 bit intel 8088 processor, a few years back, and its several minutes of video and audio. now remember that old machine had like a few hundred K of RAM and floppy disks were 360Kilobytes.
---
the problem is that give these systems any old video stream, it's not going to spit out 140 characters of javascript. that is where the genius of encoders comes in. They have figured out what the 'average any old video' tends to have and they have created generalized algorithms that work pretty well.
however. given an extraordinary amount of clevernes and time, you might be able to create a system that could take a given video, and produce 140 characters of javascript that, when fed through dwitter, would create the original video. dwitter here, along with your browser, and it's javascript interpreter, would be the 'decompressor'. now, on a lot of videos it might look like garbage. For example i dont think a full length movie is going to be encodable in 140 characters of javascript. But there would be a lot of stuff in there that might surprise us - just as i have been surprised dozens of times on dwitter at what is possible with a bit of human imagination.
the number of possible distinct video streams in this sysetm is on the order of 64000^140th power. (64000 being a rough idea of how many utf8 characters there are, with 140 of them).
Here is the thing. People decry the 'magic box'. But if you read about the new machine learning algorithms... nobody knows how they actually come to their decisions. So they are literally magic boxes. I dont know if Smoot had such a thing back then, but today... who knows?
----
i also want to discuss anger and condescension. in other words, skepticism vs belief.
skepticism is important, but so is belief. you must find a balance between these two.
When I insisted that the null set should be included the enumeration of subsets in answering a problem on an Information Theory homework, the professor was reminded that his colleague and author of our textbook once asked for "the null license plate" (i.e. a blank plate) for his personalized license plate but was turned down as I was about to be in my request for points back on the assignment.
Whereas there are certain plates you cannot have -- obscenities along with "1" or "A1" or similar license numbers reserved for high government officials or whatever the excuse -- the colleague insisted that a blank plate was not excluded by the rules.
DMV stood firm in rejecting this request, but if anyone, anyone at all in the State of California should have been permitted to have the blank license plate, don't you think they should have granted it to the author of a graduate-level textbook in Information Theory, especially with so many high-ranking academic institutions in math and engineering in that state?
My professor's take on why his colleague should have been granted the null plate is that it could have made it easier for the CHiPs seeing his colleague speeding down the Foothill Freeway, "Quick, get that car's license number! (partner to that officer rips off a blank sheet from a notepad) Here it is!"
1/ Never heard of it before thus no opinion - odd question to ask since so many will also have no opinion.
2/ If it is lost then it's technically irrelevant even if historically interesting.
This sounds like a cross between Guetzli, an AI-optimized jpeg encoder, and Brotli, a zlib encoder with a predefined library. And Google loves looking for ways to compress YouTube videos.
(T>t && O(n)--) == sqrt(666)
Sloot jokes are whoreable.
I have read the book "de broncode" some 10 (?) years ago. It read like a very exciting detective/mystery. The weird thing was that the book ends with lots of pictures and copies of documents that prove it's existence. In the end you really get the feeling that there was some foul play by some mayor company. It's not that difficult to make someone have a heart attack...
Offtopic maybe, but I had a guy with something like that bring it in to the University where I worked for independent testing. He was an artist with not a lot less technical skill than a mechanic, and paranoid as anything, but he couldn't hide what he'd done. The trick (on the perpetrator more than anyone else) is to tune the engine for maximum efficiency at idle - thus it uses very little fuel on a test bed with no load. Once you attempt to get it to do something useful it actually uses more fuel than if you hadn't messed around with it in the first place.
Those people "knew it was real" - they had seen it in action in a test, and in their minds there was only some tiny little glitch that was keeping it from working in practice. Anyone with an actual clue about engines that attempted to point out problems was apparently part of a conspiracy.
You're forgetting that it's 8kB ... plus the 370MB of data preloaded in the de/compression engine.
look. it doesn't MATTER if it's 370mb of data or if it is 1000 terabytes of data. given a random movie file it would have to be able to tell apart the same movie but lets say a 10 seconds of it is just blacked out in the other version or replaced with a random text(this is to take out possibility of having the whole movie already in the 1000 terabytes of data). you cannot index chunks with such a little data to go match there. IT CANNOT BE DONE. if it could be DONE THEN THIS WOULD REVOLUTIONIZE HARDDRIVES AND ALL DATA TRANSFER - not just videos.
besides 8000 bytes / 120 min is about 66 bytes per minute. thats like a byte per second.
so basically, at least the claims are an order of magnitude more ludicrous than is possible at all.
also a few years ago I ran into some startup guys who were claiming that (among other things) they had a new compression algorithm that could do 1gig to 100kb or some such... I tried to explain them the theoretical maximum they could attain is way worse what they were claiming (due to simple logic)... they never did anything with it or showed it of course - even if it would have been 1000000x more valuable than what their current company was doing. kind of lost faith in that then.
furthermore you could embed 50 megs of data easily visually on a normal vcd movie of 650 megs. what this is suggesting is that you could embed any random data of 100 megs into 8 kilobytes. it doesnt add up. it cannot add up.
world was created 5 seconds before this post as it is.
Never heard of Sloot and, this being /., didn't bother with TFA...
What I read is "Sloot Compression is a Rainbow table"
-T
Long ago there was a tech maybe around VCU who figured out how to compress JCL job instructions so the lengthy description of a tape could be generated on the fly from a small string fragment which replaced the tape number in a JCL deck. Had something to do with quadraoctal numbers. Recreating the text was fast, but the initial compression could kill a mainframe. Data is data. You could do the same thing with pictures or video, but you better have a super computer sitting around for the initial compression.
1. We use PDF's today which when compressed are relatively small.
2. We have a commercial entity called ScanSoft that also compresses PDFs
3. PDFs generated by ScanSoft are incredibly much smaller than any other PDFs
4. Scansoft PDFs use a compression algorithm called QMax
5. Nuance which now sells the Scansoft PDF products have access to the same technology
6. No other PDF technology in the marketplace has a compression algorithm that uses STANDARD decompression and unique COMPRESSION to achieve the ridiculous PDF sizes (try converting one of the PDFs and you will see)
Sloot didn't HAVE to have a good DECODER, but even a BETTER ENCODER would do. If you add a better DECODER as well, then things get really interesting and the compression factor suggested becomes visible as a possible end goal.
Find a person talking in front of a not moving background.
Try a resolution from the vcd or vhs years.
Take time to look at every frame in great detail. Keep working on the data in each frame for a much longer time.
Use a good cpu and gpu to really work the math per frame and each next frame, all frames.
Then have an artist correct each frame by hand for movement or areas that should have not moved.
Alter any code as needed.
Try again.
Code could be optimized for a set background and a talking presenter. Let good code, many gpu's and cpu's try again.
Have the artist look at every frame again.
Once some interesting results can be repeated try many different backgrounds. Some issue between the human moving and a different background might be more successful.
If the gpu's and cpu's need a day to work on a very short series of frames but produce a good result, keep trying.
Better cpu and gpu support can be added. A new idea about what code can do and what the artist suggests will take time.
Try every method and theory that can be found per frame and for every frame.
Also consider film, digital or other capture methods and how each frame is created.
A very different, emerging or old and unexpected way of working with each frame might be better for the math per frame.
Domestic spying is now "Benign Information Gathering"
I've compressed 27 years of 401K retirement fund down to something that fits comfortably into a coin purse with room left over for a couple fentanyls. I wish investing was as easy as ingesting.
The Russians have won. They have made the world a cesspool of distrust, greed, fear and hate.
no no no..
demoscene demos work because they work within the limits of the machines - the machine is part of the creation. it's limits dictate the creation. it's not for reproducing arbitrary input and that would lead to a logic loop.
you can agree that a video can have 140 characters? or 100x140 characters? basically the slooth claimed algorithm was so good that you could make a little logic play and include an infinite amount of hollywood movies(not just noise) in a chain of compressed links(any full lenght movie would have enough of sidechannel extra data visually in the video stream to include 2+ other compressed movies).
the claims were just too good. and it is strange anyone would have thought of giving him the money without running the idea through some mathematician or two which would have claimed bullshit on it.
like your scheme would work only if the movies were made for dwitter or some old pc or whatever. you can have pretty nice 64kbyte demos with music but that doesn't mean that you can reproduce any music video in 64kbytes, which was basically what slooth was claiming.
world was created 5 seconds before this post as it is.
I am actually not bragging, when I say I have put my penis into a bunch of women. I am actually a wee bit alarmed at the number. It's a lot. I was a man whore for a long time. Really, it's a lot.
I'm not sure if this makes me an authority, however. So, call this an anecdote...
Not one woman, with whom I have conferred, has ever used that nomenclature. Yoni is my favorite, if you're curious. I've even dated professionals who were involved in women's reproduction health. None have used that term. Not even farm girls, or chicks with horses, have used that terminology. They even are from diverse global locations., but none have.
It must be my lack of exposure...
"So long and thanks for all the fish."
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: :D
http://www.bizjournals.com/sac...
http://jacksonville.com/tu-onl...
http://jacksonville.com/tu-onl...
Magic video compression turned out to be buried cable
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.
Who logs in to gdm? Not I, said the duck.
If the Internet is the CODEC and a URL is the compressed data.
According to the linked Wikipedia article on Jan Sloot, the guy he signed the deal with was named Roland "Roel" Pieper; so that's a point in favor of the Pied Piper theory.
by Cyphase ( 907627 )
if you don't care about quality.
Sloot's compression figures mean nothing unless we can evaluate how good the result is.
Which we can't, since is no such codec actually exists.
I once spoke with a retired GM engineer who was in on the corporate show-and-tell for that specific part.
It would only get ~150 MPG in the heavy cars of that era, and used a low frequency RF source (15-35-ish Mhz I think) around the float bowl (I think), which helped atomize the fuel a lot better, or something (I think)
In all other ways, it was a bog-standard carburetor of the era.
Soon after, he asked around the department why nobody was talking about that carburetor and was advised to avoid asking further questions.
My humble guess is that if the 300MPG carburetor was snake oil, the company men would have told him so.
Instead, he was invited to "not ask questions."
I once spoke with a retired GM engineer who was shown one of those magic carburetors during a corporate show-and-tell.
It would only get ~150 MPG in the heavy cars of the era, but it worked by having an RF source mounted around the float bowl, emitting at a frequency of 14-35 MHz. (I forget the exact frequency he told me)
In all other ways, it was a totally bog standard carburetor.
He asked around the office a while later about it and said he was invited to avoid asking further questions.
My humble opinion is; If the 300 MPG Carburetor was snake oil, the company men would have just told him it was BS.
Consider the extreme case of "compression" where the "codec" is actually all the movies, and the "file" is just the catalog number of the movie. Compressors lie on some kind of continuum between that and raw uncompressed files where the "codec" size is zero and the "file" is the file.
If you had enough computing power and had analyzed a large body of data from the films, it seems possible that you could build a very large codec and have fairly small file sizes... but... I think it's unlikely that his compressor was real because it seems like the analysis and a practical decoder were out of reach for anything marketable in the late 90s.
For example, it seems like your typical Pixar animation would have data files relatively small compared to the final rendering; but a reasonable rendering of the film takes massive computing power, even today. I might even be wrong about the size of the data files, since they could be using massive poly counts. In that case, he'd also have to have invented a very efficient format from which to render frames, or have some very sophisticated analysis which, IMHO, were out of reach at the time.
Back in the mid-90s, the "VP" of engineering (given that he supervised a team of two programmers the "VP" title was more than a little ridiculous -- of course I was the more "senior" of the two programmers, and my title was "Director of Engineering") of the startup I was working for told me he had a great idea for incredibly-efficient video compression, which would make full streaming video practical over dialup. When I asked for details, he told me the key was to find an optimal representation of the video stream, then send that. Since that statement was somewhere between blindingly obvious and utterly stupid, I pushed some more. His answer, delivered in hushed tones, after looking over his shoulder to check the empty room for spies, was:
"Here, do a thought experiment: Imagine a whole room full of transputers, all cranking away to find that one minimal representation of a frame of a movie. Now imagine a building full of them... can you imagine how optimalist the result would be?"
I laughed out loud, couldn't help it, which pissed him off so much that a few minutes later when the other programmer came in and greeted the "VP" with "Good morning, sunshine", he threw his very expensive headphones at him. He missed, so they shattered against the wall. Then the VP went running to one of the co-founders to complain about being disrespected by the staff. Nothing came of it.
That was far from the weirdest thing that happened at that place. My few months there ended abruptly one day when I arrived at work to find 20-foot flames shooting out of my office window. We're pretty sure that one of the co-founders torched the place to cover his theft of the ridiculously-expensive servers he'd purchased with the other co-founder's money, but nothing was ever proven.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
A 46.25 MB decoder doesn't sound too massive to me.
i read when i was a network fanatic :
https://www.amazon.de/Supercode-Eine-Erfindung-die-brachte/dp/3431036325/ref=sr_1_3?ie=UTF8&qid=1496994005&sr=8-3&keywords=supercode
For me it always had a pretty fictional aspect to it.
Something like this has already been demonstrated; The most famous example I know of is the demoscene 64k entry fr-08, which uses procedural generation to fit in 64k what other programs would use GBs of space, and even procedurally generating the music, which even if compressed as an MP3 would alone have taken up far more space than 64k.
And although it is procedurally generated, it is not randomly generated (Which is what most people think of 'procedural' these days) so it runs the same way every time, consistent as MP4 playback.
An MP4 of that demo would be far larger, and also would not scale infinitely to any resolution you chose like this tiny 64k program does!
do you know why simply having vast amounts of more memory in a computer doesn't make zip algorithm much better? it just doesn't help. you can't just make the dictionary larger and larger and expect benefits from it with arbitrary data, pointing to that dictionary is going to start taking the same amount of bytes as you're getting out from there, because otherwise your pointer to the dictionary would point to multiple entries and that just doesn't work if you want to decompress.
same with the hash. it would be even expected that you would find a false match before the right one.
world was created 5 seconds before this post as it is.
No.
This is basically mathematically impossible. The problems is that even though fractals, random generators or any other formula that can produce every possible combination of output for some input, for example if you can find the value x for f(x) = y where y is the resulting file.In theory you only need to store x to generate the whole file. The problem is that you either end up with having to search through almost infinite space of numbers which means it takes the age of the universe to compress a single file or if you find the correct number x it is always larger than y making the whole thing useless.
What Sloot likely had was an algorithm that was specially designed for some limited input of files, which the algorithm could reproduce from very small input since most of the input was stored in the codec itself. This is usless because the algorithm can't handle general files.
Also any statement that says that the algorithm can always compress any input is false by definition. Because if that was true you could just re-compress the output until you end up with a single byte, which obviously wouldn't work unless there where only 256 distinct files in the whole world.
No? No opinion then, thank you.
20 years without a backup?
Must have been using PC's.
Backup software bundled with the OS is too painful to use.
As it turned out, even death was preferable to trying.
The yt video doesn't actually say anyone watched all 16 vids to the end. Anyone can easily make a very short video file holding sixteen movies together as one. It's a bit different to actually prove each is independent all complete and a full movie.
The video talks too much about big money and lost dreams and nothing about facts from technologists. The people who talk don't appeR to be able to spot bullshit.
Of course he didn't want others to touch his
Magic box, because anyone who tried to skip to a random spot and watch for
Five mins would see it was just something like a 30sec clip and that's it.
Total, unmitigated bullshit.
I'll leave it to others to post the mathematical proof, but there is a limit to lossy compression and kilobyte output from gigabyte inputs isn't anywhere near the realm of possibility.
Why? Lossy compression is, at its core, the removal of redundant information, and its replacement with a smaller description of how to recreate what was removed. You can immediately see that your compression algorithm has to be able to efficiently (in fewer bits than what it took originally) describe what's been removed *so that it can be regenerated* (this is the tricky part).
Secondly, and very important, different inputs will have different amounts of redundant information. This affects their compressibilities. A totally random waveform can't be compressed, because every bit of information is important. So, saying that *any* film can be compressed to kilobytes is a red flag.
I am actually not bragging, when I say I have put my penis into a bunch of women. I am actually a wee bit alarmed at the number. It's a lot. I was a man whore for a long time. Really, it's a lot.
I'm not sure if this makes me an authority, however. So, call this an anecdote...
Not one woman, with whom I have conferred, has ever used that nomenclature. Yoni is my favorite, if you're curious. I've even dated professionals who were involved in women's reproduction health. None have used that term. Not even farm girls, or chicks with horses, have used that terminology. They even are from diverse global locations., but none have.
It must be my lack of exposure...
I am actually not bragging when I say I have put my penis into your mother a lot of times. I am actually a wee bit alarmed at the number. It's a lot. She was a whore for a long time. Really, it's a lot.
If you 've got a good imagination you can turn a book into a movie in your mind.
this seriously reminds me of http://www.theproduct.de/
a 64KB file that provided fully 3d rendered graphics and high quality music. this was obviously a static designed presentation so its easy to tune to that level, as well as being 3d graphics versus video frames.
i see it being possible, but more as a post-content encoding method, than an on-the-fly method.
Probable, MAYBE. Practical, prob needs high CPU/GPU acceleration to be able to encode on the fly, and possibly on decode too.
Probably the same shadowy cabal that did in Iron Butterfly drummer Philip Taylor Kramer
the preceding comment is my own and in no way reflects the opinion of the Joint Chiefs of Staff
it's in the band.
I think I've seen this movie before.
"A plan fiendishly clever in its intricacies"- Homer Simpson
Yes it applies for lossy compression too.
Wasn't it Iliza Shlesinger who used that term? At work and can't confirm it was for a vagina though.
With my 20TB decoder engine, i can compress movies down to 4 bytes! (ok, you may have to update the decoder engine once new movies come out, but hey...).
Years ago I became familiar with a company called eTreppid that was making some crazy claims about compression technology while securing investment. The "Trepp" part is Warren Trepp (https://lasvegassun.com/news/2006/nov/19/trepp-often-seems-to-be-in-the-wrong-place-at-the-/).
Anyway, see here for information about the compression:
http://endlesscompression.com/
Note that they reference Sloot and describe his methodology.
Do you have ESP?
If you have "video compression" that can procedureally generate any video, you can also generate any secret document from anywhere, ever. That makes some people nervous.
Of course, they miss the point that you also can generate a magnitude more garbage. The hard part is discerning wheat from the chaff. Given a sufficiently advanced AI, this becomes trivial. Yeah, you see what I did there.
the preceding comment is my own and in no way reflects the opinion of the Joint Chiefs of Staff
I'm seriously considering cashing in my investment in the company perfecting it's pill which turns water into gasoline and investing in this video compression. They've amazingly discovered that an entire 3D panorama can be reduced to fit onto a 2D representation, which sounds like magic to me! 1920 x 1080 at a color depth of 8 bits and sampled at 30 Hz is ~224GB per hour. The clever bastards've gotten that down to 3 DVD disks ! Just think! You'll only have to change disks twice to watch an entire episode of Game of Thrones! Whoo Eee! Yeah, definitely time to make the move.
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).
I think we will get a lot of research into that direction if VR catches up. Sending high-quality 360 degress videos is already a pain bandwidth-wise, allowing 3d + some/lot lateral head movement would make it even worse. With real time rendering, you get most of these things for free, at same time opening door to things like at least basic interactivity, nudity/gore censorship (which is not neccesarily bad thing as long as it is a receiver-side option), content customization (tailoring avatars to specific audience) etc.
mental illness doesn't prevent someone from writing reams and reams of code.
Video and sound aside, I be astonished if you could compress just the text of the script of a full length film in 8k. Bottom line, impossible. Not even worth a more detailed analysis.
He was a fraud.
The idea here is to store a complete movie in a few kB.
If we are talking about an actual movie as made by a director, this is impossible. There is simply too much entropy. The 8 kB stated size is just sufficient to encode an already dense screenplay to the theoretical limit. You probably can't even keep the original dialogue intact at that point.
In theory, one could imagine an analyst AI able to turn a movie into such a script and forward it to a director AI which is able to recreate the movie. But it won't be the original movie but an interpretation of it. In the same way that a single play can change drastically depending on the performers.
What is possible however is to make a movie especially designed to fit in a few kB. In fact, if you look at some demoscene productions, this is exactly it. Some 64k or less intros could qualify as small movies.
Yes.
Listen to my music.
It is like that the source code of P = NP is lost forever!.
yada-yada: you better NOT (re-)invent this or (re-)discover this algo else you will find that the first movie that it spits out is exactly the same movie this sloot guy saw: the ring.
anyways, there are more (random) neurons in the brain then stars in the universe and it all came from mom and dad watching the second movie that came from the algo: "how to make babies from two (half) cells".
and to be a bit honest, it is totally possible to encode a huge (whole) number with a few prime numbers and symbols. the problem is how to "chop up" a huge number into the prime constituents? ... for example (viz. goedel).
note: a (one) movie could be interpreted as one huge binary number. the non compressed movie file is say "500 MB". this could be interpreted as a YUGE binary number that needs "500 MB" to be stored. if this number could be chop-up into binary prime constituents then it could be represented by a number that only takes maybe "20 KB" to represent and thus only needs 20 KB of storage space
end: i am confident that all kinds of axiomatic system could be invented that would allow this kind of compressions?
Likely regional. See 'South Park', Hillary Clinton's Snuke, for a mass media example of this use.
He was killed by a man who evaded suspicion by driving away in an auto powered by the 100 mile per gallon carburetor, so he didn't have to stop for gas until he was far enough away to avoid suspicion! /The above is purely my own twisted sarcasm and contains no know factual basis - as I suspect do the accounts of this super-incredible compression algorithm
Rumor has it he ran into a problem when his water injector failed on the way, but he was able to use backup power from the perpetual motion generator to complete his escape. Finally he used use his anti-gravity ship to return to a secret lair.
What a fookin' sloot.
Why on earth would anyone
1) work on this project
2) kill someone for working on this project
Too many of the tinfoil hat wearing crowd on slashdot methinks
The trick is to map the eyeball position and tracking of a person watching the film for the first time. Then you only encode the parts of the film that were watched with acceptable compression, to be decoded when a film is being watched by someone else for the first time. The rest of the scene can be efficiently rendered as shifting low-res shapes vaguely following the action. This scheme has the advantage of allowing the film to only be viewed once, as a repeat viewer would likely try to focus on parts of the scene not viewed the first time.
Snatch and another AC pointed out a similar word used in South Park. (I've only seen a few episodes.)
Not one woman, that I've ever known, has used that word. Snootch? I have heard "gooch." (Spelling?) Never snootch, however, and I've put my penis into a bunch of women.
"So long and thanks for all the fish."
My father said you should watch out for Sloots.
I say we compress the hell out of sloots. That will show them!
Nice. Thanks for paying for my shoes.
"So long and thanks for all the fish."
It could recreate Homestar Runner videos.
If you know and really understand the context, and are willing to throw a lot of compute at the effort, a context specific compression approach is quite possible. Resulting in significant size reduction. Even more if this is a lossy compression.
I make ZERO claims about the veracity of the approach.
it's on a USB boot in the back of a prototype sedan running a secret carburetor and getting 100mpg on a 454 V8.
Machine learning data compression algorithms will probably beat it.
Of course what you see at the other end of your 1kb/sec byte stream might be closer to what your parents think you said than what you actually said.
What if Sloot found a way to rapidly Godelize and deGodelize huge files? Maybe he didn't realize that this would make encryption obsolete? I'm sure our guys (if not THEIR guys) would make all that go away.
'kilobytes' I'm assuming means less than a megabyte. Let's round up and say 8 million bits of information. At 24fps there are about 130,000 frames in a 90 minute movie. That means each frame is encoded in about 61 bits, less than 8 bytes, 0x0000000000000000 to 0x1FFFFFFFFFFFFFFF in hex. That's about 1.4 kilobits per second, 1/8th what you need for quite horrible sounding audio only compression. Someone isn't thinking straight...