eucliddiscoveries.com — Euclid Discoveries has announced they have the technology to reach video compression rates at 460% over MPEG-4, with the hardware & software available now. With this they can reduce a 23mb 30fps video down to 1519bytes. Awesome!
Mar 28, 2006 View in Crawl 4
liquidcoooledMar 29, 2006
Ok,All the folks saying its IMPOSSIBLE to do good things with such a small filesize have to remember theres a whole group of people who create demos and graphics and stuff in ridiculously small files.I realise its not quite the same as generic video decoding, but I believe them about their current very specific claims (and no I don't think its just a black screen with no audio - it will just be a very optimised sample)<a class="user" href="http://en.wikipedia.org/wiki/Demoscene">http://en.wikipedia.org/wiki/Demoscene</a><a class="user" href="http://www.256b.com/home.php">http://www.256b.com/home.php</a>
rkstarMar 30, 2006
First, I'd like to second the comment that it would be nice if everyone read the already-posted comments so it's not the same argument/conversation happening over and over again... and for people like me who read all the other posts before posting, wouldn't have to read through all that.Any way, as a professional video compressor (the person type, not the codec type) for about 10 years now, I want to make a few important points.- Different video codecs have strengths and weaknesses. I'm sure their sample video was made specifically for what would produce the best results for their product.- I don't believe any of their figures are wrong, but perhaps misleading to those who don't do a lot of video compression.- I especially note the phrase "reference video", while they may just be referring to a sample video, anyone who uses QuickTime Pro, knows that a "reference movie" is sort of like a alias, or a shortcut to one or more other movies, and don't store the video content themselves (if you have QuickTime Pro, just open a movie and go to "Save As..." to see how much smaller a reference movie is).- Another thing to note, is that this could be a new way of compressing/sharing video... not like the straightahead codecs we're used to. What if the compressed file they're talking about is a separate file to the video, which just holds all of the macroblocks needed for that video, which would be pretty small with good compression for a "talking head" sort of video.- One last thing to think about... flash animations... I have some that are 30 minutes long, are crisp in quality when played at full screen, yet are only a few megs in size. That's because they are done with vector images and objects. The fact that they're talking about using obects for the compression should be a hint that there's some sort of hybrid video-compression idea goin on here.
drdabblesMar 30, 2006
We're the only planet with April 1st.I mean, technically other planets experience time during our April 1st. However, we're the only planet in position to experience what we call April 1.Physically speaking, no other planet can occupy the same spot in space as ours. At least, not without our demise first.
geminitojanusMar 30, 2006
The problem isn't the fact that a compressor theoretically could reduce the right video by that much, the problem is that they don't tell us anything about the video that they compressed, show a demo of the compressed video, show an image taken from the compressed/uncompressed video, or do anything to prove that their algorithm has any kind of validity.I can RLE a video clip of all black pixels that's 1024x1024 and have it come out to being just bits in size (the RLE table will look like one black pixel and 1,048,576 as the repetition number, what's that come down to.. one 32-bit integer for the repetition operator and depending on how the pixels are packed, either another 32-bit integer (8-bit color, RGB+A) or a 24 bit integer (8-bit, RGB) [more if we're talking 16/24-bit colors, though they're not common in video processing due to the insane amount of bandwidth required to process them, also could be inflated by using a different colorspace or colormodel, like YUV], and one byte to mark the difference between the data.. total ~72 bits/9 bytes for the pixel data, plus however much was used in the full frames video to mark the frames (which would also be a consideration in the RLE).Quite simply, no matter what they profess, it's unlikely these kind of results are repeatable for any reasonable video test suite (and I should know, I helped develop two of them in my 11 years experience in DSP). It's quite easy to develop algorithms that work for specific videos. It's even been suggested in my company's RnD department to do something called "retrograde compressor development", where a computer during encoding of video will take a look at the entire video, break it into portions, examine each portion individually, special tailor an algorithm that works best to compress the scene, then pack the appropriate algorithms into the compressed file's header (along with any description to build uncommon filters), then compress each individual scene with those compressors and store the data. This would mean each individual video would be highly compressed and would have a compressor specially built for it that would work no matter what, but it's been proven time and again that the processor power simply isn't available (and likely won't be in my lifetime) to even consider this kind of compression, even with newer processor designs (like the 92-core external FPU chip, or any of the MIMD chips that I have stacks of information on my desk about; I've entertained that the idea could be done on an extremely limited basis, such as introducing multiple versions of MPEG compressors into one compression system, but it's likely this will only be possible with MIMD computers and not SIMD computers, as resetting the registers and Instruction caches will likely take too long for the latter).Video is extremely complex information. Innovations on how to look at that data simply do not happen overnight; compression specialists have been looking at this kind of data all of their lives and rarely does anyone come up with a truly innovative way to compress it. Most of the advances that will ever be made in compression were done 50 years ago by mathematicians working at places like Bell Labs and Texas Instruments. Hell, most MPEG standards aren't anything that's new to us, just the ways to apply the techniques we know become more available as processors become more and more powerful. Ten years ago, MPEG-4 would have been nonsense. No home computer could ever decode the frames fast enough to play anything back. Not even 15 years ago, the researchers at Fraunhofer tabled their idea for MP3 because computers at the time were nowhere near fast enough to look at that kind of data, and the institute said it was unlikely home computers would ever have that amount of power. Now we're looking at decoding multiple MPEG-4 streams simultianiously with the CELL processor.Bottom line: vaporware. Lacks evidence, lacks proof.
framitzMar 30, 2006
"Euclid can reduce a 23 MB video file to a 1,519 byte file" Yeah right, maybe a video of a pure black scene or something meaningless. 23 MB to 1.5KB is beyond ridiculous which gives them no credibility in my book. This wall fall short of vaporware it is so thin.
solorideApr 2, 2006
download without reg:<a class="user" href="http://eucliddiscoveries.com/download/">http://eucliddiscoveries.com/download/</a>
codefreakxffApr 3, 2006
I did undergraduate research in the same lab as Dr. Roy-Chowdhury (one of the people cited as creating this technology fore EuclidVision), in fact you can find our website at <a class="user" href="http://vislab.ucr.edu.">http://vislab.ucr.edu.</a> I watched an early demonstration a couple of years ago and was impressed at its ability to isolate objects from the background. I cannot vouch for compression levels, but the algorithms can definately seperate moving objects from the background. I can imagine how this would translate into compression optimizations in MPEG-4.