10 ms·
Extreme video compression with prediction using pre-trainded diffusion models
- holoduke 3y agoBack in 2005 there was a collegue at my first job writing video format converters software. He was considered a genius and the stereo type of an introvert software developer. He claimed that one day an entire movie could be compressesed on a single floppydisk. Everybody laughed and thought he was weird. He might be right after all.
- fasa99 3y agoI used to work with a guy like that in 1997, during the bubble, Higgins was his name. He'd claim you could fit every movie ever onto a CD-ROM, at least one day in the future it would be possible. Higgins was weird. I can still recall old Higgins getting out every morning and nailing a fresh load of tadpoles to that old board of his. Then he'd spin it round and round, like a wheel of fortune, and no matter where it stopped he'd yell out, "Tadpoles! Tadpoles is a winner!" We all thought he was crazy but then we had some growing up to do.
- djmips 3y agoA deep thought.
- HarHarVeryFunny 3y agoWell, as a reality check, even the soundtrack of a 1hr movie would be 50x floppy size (~50MB vs 1MB) if MP3 compressed. I guess where this sort of generative video "compression" is headed is that the video would be the prompt, and you'd need a 100GB decoder (model) to render it. No doubt one could fit a prompt to generate a movie similar to something specific in a floppy size ("dude gets stuck on mars, grows potatoes in his own shit"). However, 1MB is only enough to hold the words of a book, and one could imagine 100's of movie adaptations (i.e. visualizing the "prompt") of any given book that would all be radically different, so it seems a prompt of this size would only be enough to generate one of these "prompt movie adaptations".
- hoseja 3y agoMiddle-out.
- smerik 3y agoDoes anyone remember the https://en.wikipedia.org/wiki/Sloot_Digital_Coding_System https://en.wikipedia.org/wiki/Sloot_Digital_Coding_System?
- hulitu 3y ago> Extreme video compression with prediction using pre-trainded diffusion models Is this more extreme than youtube ?
- zaptrem 3y agoCan you share example videos?
- yonixw 3y agoGoogling gave me the article: https://www.arxiv.org/abs/2402.08934 https://www.arxiv.org/abs/2402.08934 Which have examples in it.
- az226 3y agoImages are hard to evaluate the quality of a video compression. Because it’s diffusing, will it have a bunch of diffuse-jitter.
- resolutebat 3y agoDirect link to HTML article: https://arxiv.org/html/2402.08934v1 https://arxiv.org/html/2402.08934v1 Unfortunately it only contains still images with teeny thumbnails: https://arxiv.org/html/2402.08934v1/x2.png https://arxiv.org/html/2402.08934v1/x2.png
- mjevans 3y agoI wonder how effective a speed focused variation could be for quality among 264, 265, and AV1.
- IshKebab 3y ago> It can be observed that our model outperforms them at low bitrates It can? Maybe I'm misunderstanding the graphs but it doesn't look like it to me?
- astrange 3y agoGraphs (especially PSNR) aren't a good way to judge video compression. It's better to just watch the video. Many older/commercial video codecs optimized for PSNR, which results in the output being blurry and textureless because that's the best way to minimize rate for the same PSNR.
- userbinator 3y agoMany older/commercial video codecs optimized for PSNR, which results in the output being blurry and textureless because that's the best way to minimize rate for the same PSNR. Even with that, showing H.265 having lower PSNR than H.264 is odd --- it's the former which has often looked blurrier to me.
- adgjlsfhk1 3y agoat equal bitrate?
- kookamamie 3y agoAt equal bitrate H.265 typically is considered twice as efficient as H.264. The graphs look all wrong to me - they show "ours" at a lower PNSR compared to both H.264 and H.265.
- ThisIsMyAltAcct 3y agoSomeone should train a model to evaluate video compression quality
- astrange 3y agoThat wouldn't work forever due to Goodhart's law.
- Animats 3y agoExtreme compression will be when you put in a movie and get a SORA prompt back that regenerates something close enough to the movie.
- kzrdude 3y agoThe compression competitions include the decompression program size in the size of the output. Must be a large series of movies compressed to win, then.
- 4gotunameagain 3y agoIf one model can "compress"/"decompress" all movies and series, its fraction of the size becomes negligible, but yes I agree with you since it still has to be distributed.
- jebarker 3y agoThis isn't really any different to what they've done is it?
- squokko 3y agoI can imagine that in under 5 years, the movie's script plus one example still photo for each scene could do the job.
- IgorPartola 3y ago“Alexa show me Star Wars but with Dustin Hoffman as Luke”.
- sbalamurugan 3y agoIt’s uncanny how much of the current stuff has been predicted by the sitcom -“Silicon Valley”
- xxs 3y agothat prize goes to zstandard, though.
- iwontberude 3y agoYeah curious to hear what the Weissman score of this latest algorithm is going to be.
- userbinator 3y agoHow fast is this and how big is the decoder/encoder? The model weights are not accessible. From the description, it looks like it's only being tested with 128x128 frames, which implies that the speed is very low.
- newaccount7g 3y agoWhy would you expect those kind of details in a paid commercial?
- resolutebat 3y agoIt's a link to a Github repo, not a "paid commercial".
- ToJans 3y agoAhhh, Sloot's digital coding system [1] is finally here ;). [1] https://en.m.wikipedia.org/wiki/Sloot_Digital_Coding_System https://en.m.wikipedia.org/wiki/Sloot_Digital_Coding_System
- CamperBob2 3y agoIn the [Sloot Digital Coding System], it is claimed that no movies are stored, only basic building blocks of movies, such as colours and sounds. So, when a number is presented to the SDCS, it uses the number to fetch colours and sounds, and constructs a movie out of them. Any movie. No two different movies can have the same number, otherwise they would be the same movie. Every possible movie gets its own unique number. Therefore, I should be able to generate any possible movie by loading some unique number in the SDCS. Guy named Borges already patented that, I'm afraid.
- numlock86 3y agoYou just need an index and length within Pi's digits, duh.
- didntcheck 3y agoIt sounds almost like someone explained content-addressed storage to him and he misunderstood (where you can uniquely identify a movie by number, down to some hopefully a negligible collision likelihood, but you're merely indexing known data)
- resolutebat 3y agoHere's the research behind this: https://arxiv.org/html/2402.08934v1 https://arxiv.org/html/2402.08934v1 As a casual non-scholar, non-AI person trying to parse this though, it's infuriatingly convoluted. I was expecting a table of "given source file X, we got file size Y with quality loss Z", but while quality (SSIM/LPIPS) is compared to standard codecs like H.264, for the life of me I can't find any measure of how efficient the compression is here. Applying AI to image compression has been tried before though, with distinctly mediocre results: some may recall the Xerox debacle about 10 years, when it turned out copiers were helpfully "optimizing" images by replacing digits with others in invoices, architectural drawings, etc. https://www.theverge.com/2013/8/6/4594482/xerox-copiers-randomly-replacing-numbers-in-documents https://www.theverge.com/2013/8/6/4594482/xerox-copiers-rand...
- sdenton4 3y agoIt turns out that compression, especially for media platform, is trading off file size, quality, and compute. (And typically we care more about compute for decoding.) This is hard to represent in a two dimensional chart. Furthermore, it's pretty common in compression research to focus on the size/quality trade-off, and leave optimization of compute for real-world implementations.
- lifthrasiir 3y ago> [S]ome may recall the Xerox debacle about 10 years, when it turned out copiers were helpfully "optimizing" images by replacing digits with others in invoices, architectural drawings, etc. This is not even AI. JBIG2 allows a reuse of once-decoded image patches because it's quite reasonable for bi-level images like fax documents. It is true that similar glyphs may be incorrectly groupped into the same patch, but such error is not specific to patch-based compression methods (quantization can often lead to the same result). The actual culprit was Xerox's bad implementation of JBIG2 that incorrectly merged too many glyphs into the same patch.
- daemonologist 3y agoI believe they're using "bpp" (bits per pixel) to indicate compression efficiency, and in the section about quality they're holding it constant at 0.06 bpp. The charts a bit further down give quality metrics as a function of compression level (however, they seem to indicate that h.264 is outperforming h.265 in their tests which would be surprising to me).
- LeoPanthera 3y agoIt's important to remember that any compression gains must include the size of the decompressor which, I assume, will include an enormous diffusion model.
- ec109685 3y agoCan’t that be amortized across all videos (e.g. if YouTube had a decompressor they downloaded once)?
- LeoPanthera 3y agoYes, absolutely, it's just important to keep in mind when thinking of these decompressors as "magic". If every laptop shipped with a copy of Wikipedia, then you could compress Wikipedia, and any text that looks similar to Wikipedia, really well.