Slashdot Mirror
Video Codec Comparison
FonkiE writes "Doom9 wrote a good article: After more than 3 weeks of work and no free time during that period it has been done: The latest codec comparison is online. 7 codecs have been put through one of the hardest tests in the history of codec testing. The results: find out on your own ;) I had planned to change the presentation somewhat but certain events (forum problems and such) prevented me from completing this for the release. I plan to eventually supply an updated version of the comparison."
Though it does require that you use a commercial mpeg2 encoder, possibly an outdated one which can probably only be acquired illegally at this point.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
DivX is still where it's at.
In conclusion: When encoding regular movies, if you look for a quick and dirty average solution DivX5 is your fix. If you're an SBC guru, want maximal details at high speed you can still stick to SBC, if you want details and are not worried about the alpha status and speed you should give XviD a shot. DivX5 and XviD also offer standalone playback capability on selected devices. If you don't worry about details too much and prefer to remain almost blockfree you should give RV9 a shot, or alternatively WMV9. Interestingly, the lead developer of XviD has offered to send me a build that would perform just like RV9.. I might take up that offer one day when I'm bored.
For animated features, the two proprietary solutions deliver good results with XviD pulling slightly ahead.
I've really only found mpeg2 to be "good." I haven't really gotten mpeg4 to look as well as mpeg2 even with the lowest compression setting. I'm not sure if mpeg4 was simply designed for streaming or whatnot. Anyone know what the major differences between mpeg2 and 4 are?
-gabe
Proper ettiquette would have been to post a mindless blurb referencing FP, or First Post. But you wouldnt have gotten it anyway so youd just look stupid.
test 1: The Matrix
test 2: Saving Private Ryan
test 3: Futurama
Heh, the pinnacle of humankind's moving image creations
In conclusion: When encoding regular movies, if you look for a quick and dirty average solution DivX5 is your fix. If you're an SBC guru, want maximal details at high speed you can still stick to SBC, if you want details and are not worried about the alpha status and speed you should give XviD a shot. DivX5 and XviD also offer standalone playback capability on selected devices. If you don't worry about details too much and prefer to remain almost blockfree you should give RV9 a shot, or alternatively WMV9. Interestingly, the lead developer of XviD has offered to send me a build that would perform just like RV9.. I might take up that offer one day when I'm bored.
Comment removed based on user account deletion
Yeah and you had to go and ruin it, good job.
and the search for better porn continues! with higher bit encoding and even smaller file sizes we can all be happier with more porn per gigabyte. hopefully the prevailing codec (regardless of the best quality) will be license free & open source for more cross platform compatability. but seriouslly, ive been sitting around for 3 days compressing raw video and anyone who's done this knows what a pain in the ass it is. better codecs hopefully will mean more compatability in the future. ever wanted to show your kpop musicvideo to your friend on your cellphone?
im flamebait for pushing for size but its true about size not being everything.
Along a few of the pictures he says along the lines of "jpeg helped this codec. In this one it hurt this codec.." Granted he probably wanted to save bandwidth but why couldnt he post zipped up uncompressed files to download? Also, I think a single image with side by side comparisons of parts of each scene would be nice as I cant flip back and forth between all the pictures and remember what I liked and disliked about them all.
what is odd is that while the final mp3 shows only 12% rms distortion (actually that's a fair bit if you're an audiophile) the intermediate AIFF shows massive added noise when I convert by imovie. this added noise is spread over the spectrum but has significant components at 10Khz. the final mp3 converted by method 1 or 2 are simmilar and show the same level of distortion 12% rms.
being a signals processing expert but not a codec expert I'm totally at a loss to explain how distortion can show up in the aiff then vanish when reconverted to mp3 (or back to ACC). this makes no sense, and is actually impossible from an information from a (naive) signal/noise point of view unless the noise/distortion is either predictable or out of band form the codec's point of view. never-the-less this is reproiducible.
I'd like to publish this analysis on slashdot but first want to clear this up.
anyone got a clue?
Some drink at the fountain of knowledge. Others just gargle.
for those short on time:
In conclusion: When encoding regular movies, if you look for a quick and dirty average solution DivX5 is your fix. If you're an SBC guru, want maximal details at high speed you can still stick to SBC, if you want details and are not worried about the alpha status and speed you should give XviD a shot. DivX5 and XviD also offer standalone playback capability on selected devices. If you don't worry about details too much and prefer to remain almost blockfree you should give RV9 a shot, or alternatively WMV9. Interestingly, the lead developer of XviD has offered to send me a build that would perform just like RV9.. I might take up that offer one day when I'm bored.
For animated features, the two proprietary solutions deliver good results with XviD pulling slightly ahead.
(because you all read the article right...)
To avoid Slashdotting the poor server, a mirror is available here:
mirror.
|/usr/games/fortune
From the site...
Conclusion
Once again we've come to the last page of a codec comparison and are asking the dreaded question "which is best?". I think we can rule out two codecs right away: mpegable AVI because it's currently unusable, and 3ivX because it returned clips with serious quality degradation. So we're left with 5 out of 7.
I cannot shake off the feeling that DivX5 hasn't made so much progress since the last comparison. It still has a tendency to smooth out details and the only major news is an application that allows you to manually adjust bitrate settings and multipass encoding (the benefits if this is still under dispute if you follow the discussions in the DivX5 forum). DivX5 is certainly a stable product and is rather easy to use and the fact that there are DivX certified hardware devices will certainly help to increase its proliferation, but it fails to claim first place in any scenario. It also didn't deliver a too impressive performance in the animated movie scenario.
RealVideo9 has not made any significant progress since the last test, either. I did never notice the bugs they were having during my last test, so the new release mostly came down to speed improvements for me, and the first test on animated materials. Personally I prefer codecs that retain more details than RV9 but that's just a personal preference. If "no blocks" is all you care about RV9 might just be your thing. Don't forget that it's proprietary (chances that any standalone player will eventually play it are extremely small), that it's not very editable and that your audio format choice is rather limited as well. Last but not least its rate control still leaves a lot of room for improvement.
SBC seems to finally have found its match. It has to share the "most details" throne with XviD while clearly being beaten when it comes to animated features.
With WMV9 Microsoft has finally managed what they've tried for almost 3 years (I still recall my first codec comparison... I tested WMV7 and found that it did not perform better - in fact rather worse - than plain DivX3 at the time), that is join the top league. With its financial power Microsoft might be able to get some hardware support, but I still think it's more likely that a real standard (MPEG-4) will make the race. In any case, WMV9 delivered a reasonable performance in all scenarios, except for rate control and speed.
Last but not least, XviD has made a big step forward. It was able to catch up with DivX3 on the detail level and the only things I can criticize are QPel effects (which really aren't that visible when you use the built-in postprocessing, which by the way requires that you get the best CPU available), the two glitches I found (and which I've already submitted to the developers, hoping that they will soon be fixed) and that fact that its new features have decimated encoding speed. XviD playback is also supported by most hardware DivX/MPEG4 players so you might be able to play your rips on a standalone device which is certainly a bonus (make sure not to use any modulated quantizers though, they are not specs compliant).
In conclusion: When encoding regular movies, if you look for a quick and dirty average solution DivX5 is your fix. If you're an SBC guru, want maximal details at high speed you can still stick to SBC, if you want details and are not worried about the alpha status and speed you should give XviD a shot. DivX5 and XviD also offer standalone playback capability on selected devices. If you don't worry about details too much and prefer to remain almost blockfree you should give RV9 a shot, or alternatively WMV9. Interestingly, the lead developer of XviD has offered to send me a build that would perform just like RV9.. I might take up that offer one day when I'm bored.
For animated features, the two proprietary solutions deliver good results with XviD pulling slightly ahead.
there is lots of things left out like bitrate/quality comparisons, some codecs, like realvideo do a much better job at low bitrates (200k/s) then say xvid at the same bitrate.
there are a lot of common codecs left out of here, for example Sorenson. (yeah yeah, can't view on Linux, but it's popular and quite good)
I keep hearing good things about Bink. Anyone have any experience with it, one way or the other? Seems to be used in a lot of games.
A signals-processing attempt to measure audio quality isn't useful in general, and especially when dealing with lossy codecs. The various measured distortion values aren't really interesting -- the only relevant result is audio quality. As such, the only interesting tests are blind listening tests.
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
Maybe hell froze over and everyone read the long and detailed article..?
Nah.
Well, if you have read the article, you can see that 3ivx (not 3ivX as the article states :) ) does not fare well. However, 3ivx does have one thing that the others do not have whatsoever... it was built from scratch for QuickTime compatability. The reason that this is a good thing is the versatility you can achieve with a QuickTime movie. I have personally ripped and encoded an anime movie, and was able to put both English and Japanese, as well as English subtitles, all controlled by a flash menu. The few OGMs I have seen have similar capabilites, but nothing quite as nice as QuickTime.
The video quality is actually pretty damn good, IMO. I suggest trying it out for yourself. Check my webpage for more relevant information.
I wish they tested that too, the encoder isn't free, but it is cheap. Then the question is, is the price worth it?
GPL Deconstructed
If you wanted to make video files that will have the best chance of being viewable in 10 or 20 years, what are the best file formats and codecs?
Are any file formats and codecs likely to be visible?
original AVI!
Vonal Declosion
try vogg
social sciences can never use experience to verify their statemen
All these years and MPEG1 is still the only truly universal video format.
.mov or .avi you downloaded requires a codec you don't have.
1. MPEG1 is not encumbered by patent problems as MPEG2 and 4 are. http://www.mpegla.com Thus it is effectively free-as-in-beer by default.
2. MPEG1 is playable everywhere from the old Solaris and SGI boxen to the newest PCs.
3. No finding out after the fact that the
4. It is not a tool to let Microsoft, Sorenson, or Real dominate all online video and divide the web into gated communities.
I think mencoder favours ffmpeg for Mpeg4 encoding and the mplayer docs suggest it as better quality and faster than Xvid ?
Pity it wasnt tested too.
libavcodec is actually just as good as divx5, and certainly better than xvid. While it's true that it produces stuff that's compatible with divx decoders (theoretically all MPEG4s should be compatible with each other, but that's only the theory), it is certainly not subsumed by divx5. It also has many of the codec features of divx5 pro - e.g. B-frames, Trellis quantizer (which improves quality / reduces bitrate big time(tm))
The Raven
If a author warns us of a future update thats sure to be posted on slashdot and surely will contain links to the old story does that still make it a dupe?
Wow I get to hear about stories to be posted before their even written and I'm not even a subscriber!
It seems that everyone is worried about encoding and what I would like to know is which format takes the least cpu to decode. I'm running on a rather weak laptop and even mpg1 gives me mismatched audio. Are the mpg4/SBC decoders less cpu intensive?
Was this test violation of the DMCA? Someone circumvented the copy protection of the respective DVDs.
I have a problem with re-compressing an already compressed source. MPEG-2 for DVD can run between 2Mb and 9Mb (8Mb realistically). I have always been a believer in the garbage in/out theory of compression (please don't make me explain). Each of these titles I am sure were encoded at diffrent bit-rates. I dare to say, the cleaner the source, the better the compression. In this instance I believe the best compressor is the one that can best smooth out the errors of MPEG2, not necessarily the best compressor. I would like to see how these do off of uncompressed source media.
I've been semi-following XivD for about a year, occasionally compressing one of my DVDs to see how it's doing. (which always seems to be: Great, but better the next week (i.e. a severe double-edged sword!).
One thing you know about Xvid is that those problems (the ones Doom9 found) will get addressed. Cheers XviD team.
This is my Sig, this is my Gun. One is for Slashdot and one is for Fun.
To be sure, he's comparing the performance of the codecs against content that is popular (and typically difficult to compress...)- but he's pulling it from a lossy format, namely the MPEG2 stream off of a DVD.
.OGG's or something like them instead of pulling them from MP3's as source. With a lossy format, you're deliberately losing content, introducing hopefully un-noticable distortions into the reproduction of the sound. Unfortunately, the varying formats use different assumptions, which produce differing kinds of distortions into the result. Because of this, re-encoding from MP3's, your sound files end up with distortions on top of distortions- the quality and compression suffers as a result.
There's a reason why you're really supposed to re-encode from the CD when you're producing
The same applies to video files.
This is not to say that what Doom9's doing isn't important or relevant- it is if you're using the codecs to space shift (i.e. Put several movies on your laptop so you're not carrying the DVD's on your business trip...) or pirating movies. The reality is that the codecs he's reviewing are largely designed for previously untouched video feeds- someone ought to test that as well.
Anything else is not really a proper review- unless you're only caring about ripping and re-encoding DVDs. To me, that's something useful to know about, but I'm as or more interested in the intended usages of this stuff as well.
I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
I can explain quantizers.
To compress a sample of audio or video data, you want to throw away details that don't matter. So you transform the data using a function, and then you apply a quantizer to throw away some of the data. The whole point of the transform function is to make a data set that is "safer" to quantize.
Most audio and video codecs use the DCT function, which decomposes an image into a series of waves. If you throw away some of the wave data, you get a similar series of waves, and hopefully humans won't notice the differences.
Applying the quantizer is the "lossy" step in lossy compression. Here's how you do it:
You divide the output data (from the transform function) by some integer number, the quantizer, and you use integer division. (Because you want to simplify the data, you actually want the fractional part discarded!) The bigger the quantizer, the more data is thrown away. A quantizer of 1 would give perfect quality, but very poor compression.
Here is a semi-real example:
You have some data to compress. Let's say it's eight bytes (maybe an audio sample for Ogg Vorbis).
After the DCT, it looks like this (using decimal numbers because it's easier):
355 244 33 192 43 9 3 8
Quantize with a quantizer of 8:
{8} 44 30 4 24 5 1 0 1
The {8} is intended to show that the quantizer has to be stored with the quantized data stream, so we know what quantizer was used so we can dequantize.
On dequantization, we just multiply by 8 again:
352 240 32 192 40 8 0 8
Then we feed these resulting numbers into the inverse DCT, and get back some data that is hopefully not full of artifacts.
When you are encoding, you quantize, and then you encode the resulting stream of numbers. Because the values of the numbers are smaller (e.g. 24, instead of 192) you can encode the values with fewer bits. And you can apply run-length compression to the quantized values; in my example it wouldn't buy you much, but in real examples you will often have a bunch of zeroes in a row.
Video compression dialogs (such as the JPEG options in "Save As" in The GIMP) often give you a slider for a quality percentage. This is actually controlling the quantizer. For JPEG, you have 31 possible settings for the quantizer, so there is no difference between 80% and 81%.
By the way, my personal experience with video compression is that a quantizer of 8 gives pretty good compression with very few visible artifcats. An 8 quantizer corresponds with about a 75% in the quality sliders (such as Save As in The GIMP).
Some afternoon when you are bored, save the same JPEG image over and over with different quality settings, and watch what happens with the artifacts. When you set the quality down to 2% (corresponding to a 31 quantizer) you get ugly, coarse blocks. The GIMP under Linux is particularly good for this because you can drag the quality slider and the preview updates instantly, so you don't have to save and re-open.
steveha
lf(1): it's like ls(1) but sorts filenames by extension, tersely
No, there is nothing missing from this review. You were apparently unable to grasp the content. Note the title of the website: "The definitive DVD backup resource." This review is about which codecs are useful for compressing DVDs for "backup." Nothing more.
Myself I get most of my anime thanks to the existance of these compression formats. I'm a fan of DivX 5 simply because it's easy to get a hold of the codec and it works for all my historical DivX 3.x movies. I have nothing against the Xvid team but it's a bit annoying when I get the occational anime that won't play on anything else but the Xvid codec, requiring me to find it and install it into my system. And as the reviewer noted it's got a few bugs still. DivX 5 may not be the best but it's certainly the most convenient and standard to an end-user.
I rip all my DVDs to WMV so none of you linux lusers can watch it.
I'm looking for the "definitive" way to back up my LDs. Laser rot and all.
http://sourceforge.net/project/showfiles.php?group _id=53761
use the latest alpha version.
This is my Sig, this is my Gun. One is for Slashdot and one is for Fun.
IANAL but looking at the Helix binary EULA there seems to be a clause disallowing this sort of thing.
c kw rap/eula-clickwrap
https://reguseronly.helixcommunity.org/2002/cli
Entry 2(a)(vii)
You may not make available to any third party the results of any evaluation or testing of the Software by You under this License. Any such forbidden use shall immediately terminate Your license to the Software.
Just a thought
I think that videolan and mplayer are much better than Quick Time
The main issue missing here is that the various video codecs, conversion tools, and audio processing tools are not easy enough to use.
Ease of use should be the focus of new releases of virtualdub, tmpenc, flaskmpeg, avisynth, etc.
We can watch wmv 7,8, and 9 in Linux, both with xine or mplayer. Even videolan can be used for some wmv files.
The format war continues, but ultimately the majority of the codecs are trying to implement the mpeg4 standard. Surveys and comparisons aside, if you trawl around you'll find that most "users" (ie not companies) are using either DivX3/5 or XviD.
Some clever individual has come up with ffdshow, which you can get off doom9.org, which will play either DivX or XviD without having either codec installed on your system. And at around 500k, it's a smaller download than either of those codecs
"By Grabthar's Hammer, what a savings."
sorry to be an arse, but the article discusses video codecs and this has really no relation.
This is my Sig, this is my Gun. One is for Slashdot and one is for Fun.
You make a good point but it's not just DVDs that use compressed video. Digital cable, satellite, digital video cameras, etc. are all pretty common sources for people using these codecs and they're all compressed. Heck, most of the stuff I encode has been through compression/decompression twice allready, once by Directv (mpeg2)and once by my pvr (mjpeg) and when I want to store it long term I use mpeg4.
See article (unfortunately only its beginning, and without illustrations) if you understand German. Reading the full thing (very thorough) in the print version, you'll learn that WM9 'wins', closely followed by Real's latest codec.
For whatever reason, some programs mess up the spacing of the video and sound streams, for example, Variable Bit-Rate Audio often gives problems. The thing is that it isn't the video codec itself, just the delays getting sound and vision to run concurrently.
See my journal, I write things there
Why not Ogg Theora?
I was a little disappointed with the review as they we're already reviewing an alpha status codec and could've given some indication about how well will Theora fare against it's more patent-burdened codecs.<br><br>
I for one am excited about the idea of getting my movie files on a really freely usable codec as well.
I know the Ogg people isn't done with Theora yet, but I would have loved to see it included. Im really interested in seeing how it will perform.
I don't know about anyone else, but for the most part (with the exception of 3ivX) I didn't notice enough image degrigation to matter. Especially at 24fps.
Don't believe me? Try this: scroll through the screenshots (at about the rate of 1 image going from the bottom of the screen to the top per second - 1fps) and tell me if you can pick out the glitches in most of these codecs.
What's more, if anyone was walked into several rooms in sequence, all playing the same movie, but one being DVD, one being DivX3, one being WMV9, etc. I suspect nobody would be able to distinguish one from the other, provided they're encoded at one of the higher quality settings - even if they're intimately familiar with the film.
This is a load of garbage. DVD is a broken codec to begin with.
~/ssh slashdot.org ssh: connect to host slashdot.org port 22: too many beers
"Check my webpage for more relevant information."
It's down. Like, not up. It's this one, right?
One of the major sources of quality degradation in transcoding is re-quantization. Almost all (all?) lossy compression algorithms do some sort of quantization, whether it be in the frequency or time domain, to save space where it seems possible; for example, taking a 16-bit quantity and storing it in 12 bits (2^16 gets mapped to 2^12, 0 gets mapped to 0, and everything in between gets rounded to its nearest corresponding 12-bit value). Now say you transcode, and the new algorithm uses 10 bits on the same quantity. Now you have 16->12->16->10, which is really horrible.
Now if you could determine which quantities were quantized in what way, you could try to minimize these effects; 16->12->16->12 shouldn't really introduce any additional errors, for example. But your resulting file will still be lower-quality than a WAV->xxx encode, since you're restricting the codec's options. In, say, an MP3->AAC transcoding, you'd be forcing AAC to use quantization granularities tuned for MP3, not allowing it to use what it determines as optimal in the context of its AAC encoding.
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
... whether artifacts in the screenshots are down to the video codec, or down to the fact that the author has jpeg compressed them? This is one of the few places where it really would have been a good idea to use a non-lossy format.
I can't see how this test say anything? Why use compressed crapmaterial to start with? It is pointless. Or as a compressionguru said in a lecture. Garbage in, megagarbagee out. Use an uncompressed source!
- To understand recursion, we must first understand recursion -
Who is compressing video from DVD, consumer digital cameras, PVRs, etc. So it's a real world comparison.
99.99% of people don't have the hardware necessary to do uncompressed video, either their camera can't do it, their video card can't do it, or their hard drive can't write it without dropping frames.
640x480[low res]x30[fps]x3[bytes per pixel]= 27.6 MB/sec sustained writing. Or you can try doing HDTV resolutions at 83 (720p) to 186 (1080p) MB/sec.
DivX will do multiple passes, and the Gordian Knot that he was using will do six by picking it from a drop-down.
An increase in quality has been debated, but DivX with six passes has, at least for me, always come within 1MB of the target size and never over.
That is a valid point, but in terms of really clean, complex footage, there aren't many places to go for uncompressed, digital content. Professionally published DVDs of high bitrate provide nearly artifact-free video, and I would say that is certainly 'good enough' for the purposes of showing off a codec.
What I don't agree with is the use of JPEG to encode captures of the footage for demo purposes. PNG would have been a far far better choice. I know still images alone are never a good indication of a codecs performance with respect to motion and such, but lossless stills would have at least been more indicative than lossy stills.
XML is like violence. If it doesn't solve the problem, use more.
Get a real .mp4 file and rename it to .mov and see what your quicktime player makes of it ... it wont work, cause they aint the same.
If it doesnt help quality I have a better idea ... Ill make a codec which pretends it does a wicked fast 6 pass encode, but it really just padds a couple of extra 0s to the bitstream on each pass.
... more than 2 pass is stupid, exact size targets are not something to go after.
Without a quality difference, what difference is there? None
He should have used PNG, which is lossless RGB 24-bit.
Of course, encoding in JPEG @ 100% quality would have been effectively as good. There really isn't any excuse for having still image artifacts on top of the source artifacts in this kind of article.
My video compression blog
Actually, MPEG-1 also supports aspect ratio switching. Not all players do, but most of the modern software ones do.
While all of the above are important for digital broadcasting applications, for storing progressive-scan content, MPEG-1 is pretty much identically good, and players are much more widely distributed (it still costs $2.50 to distribute a MPEG-2 decoder legally).
My video compression blog
In MPEG-2, any particular implementation is defined by a Profile and a Level. A profile defines the tools available to a particular bitstream (like interlaced video, or B-frames), and levels define the parameters of those tools (like maximum resolution and data rate).
.mp4 is extremely overloaded, since it doesn't indicate the Profile@Level used for any of its parts. So it's easy to make a file that won't play in the player that automatically takes .mp4 when a file is opened.
For an encoder Profile@Level defines the maximum features you can use to make a compliant bitstream (so it's okay not to use all the tools and still claim to make an Advanced Simple stream - the encoder is compatible, just not maximum quality). For a decoder, Profile@Level defines the minimum level of support - it's always okay to play back illegal streams, but at a minimum all legal streams of the targeted Profile@Level need to be supported.
So our problem is that
My video compression blog
Actually, the codec is too late in the process. The internal workflow is:
Decode -> Filter -> encode
The filter step includes cropping, scaling, inverse telecine, etcetera. ideally, deblocking should be done at the decode stage, where the codec knows where the macroblock boundaries are, and so can better discriminate between artifacts and image elements. If it's done at the codec stage, the encoder won't know anything about the original source, and must use much more ham-fisted filters.
My video compression blog
I write a lot of codec review articles for DV Magazine. My editors tell me not to worry about those EULA's. Not only are the "no review" clauses considered largely unenforceable, there are any number of magazines out there who whould love to be the test case on this stuff.
Disregarding the legal issues, it's be a huge PR nightmare if a company actually started suing users for discussing how the products work. I can't imagine why they put the clauses in there. It's alienates users without actually gaining any real protection.
My video compression blog
You make a good point but it's not just DVDs that use compressed video.
Good point, but it would have been nice to have multiple sources for the tests, not just DVDs. It could be that particular codecs are tripped up more by the compression techniques of DVDs vs. DV, etc., so your choice of codec might be influenced by your input source.
Ooh, a sarcasm detector. Oh, that's a real useful invention.
When the ground truth (in this case the source dvd) is known, why wouldn't these results be presented as difference images? It would make the artifacts much easier to see.
word.
I just proposed a faster method of doing more than 2 passes which gives indistuingishable quality ... to me it seems like a win win scenario.
...
If you are anal an exact size target matters, if you are not
So now only copyright laws apply to your usage of the software. I which all the restrictive licenses had clauses like that.
Except where you get to the part that the disclaimer of warranty, limitation of liability, ban on reverse engineering, etc. "survive termination of this License." Is this enforceable?
Will I retire or break 10K?
http://www.matroska.org/
Support the future of video and audio encoding : matroska as container ( http://matroska.org )
- extensability for future use
- menues ( like DVDs have )
- chapter entries
- selectable subtitle streams
- selectable audio streams
- fast seeking in the file
- high error recovery
- streamable over internet ( both HTTP and RTP )
And best of all, the sourcecode of all the libraries developed by the matroska developement team will get licensed under GNU GPL and QPL license types. How can you go wrong?
Instead of a movie being 10MB too short, it can use that 10MB to add to the quality
Raise your hand if you actually notice the difference between a 689 MB video and a 699 MB video during normal viewing.
(less than 0.5% of hands go up)
I'd rather lose 10 MB so that I can include extras such as the necessary codecs, a .lrc file for captioning, etc.
Will I retire or break 10K?
http://www.matroska.org/
It was made to be more extensible for the future. (This is subjective as the future isn't here, but it was a top priority to ensure nearly anything could be stored in Matroksa for the next 10 years.)
Support the future of video and audio encoding : matroska as container ( http://matroska.org )
- extensability for future use
- menues ( like DVDs have )
- chapter entries
- selectable subtitle streams
- selectable audio streams
- fast seeking in the file
- high error recovery
- streamable over internet ( both HTTP and RTP )
And best of all, the sourcecode of all the libraries developed by the matroska developement team will get licensed under GNU GPL and QPL license types. How can you go wrong?
I just d/led the latest rev of Gordian Knot and low and behold it installs Gator among other things. Did an Adaware check to remove it. So beware of "free" software.
I would gladly encode material from the digital master tapes but my chances of getting access to those are pretty slim :/
What I really don't understand is why he reviewed the videos on an LCD monitor, LCD's that are known to have inferior color to CRTs. CRT's can't reproduce the range of colors that a CRT can.
3ivx at QP 12 would look like crud. Use QP 5 or higher. In numbers, that's 85%.
Kid tested, Mother approved.
- Zav - Imagine a Beowulf cluster of insensitive clods...
phrase: A sequence of words intended to have meaning.
eyeball.com has a codec that kinda blows all these away, check it out http://www.eyeball.com/
Gamblers Forum
It is all well and good to give the codec an ideal place to be run. My favorite tourture test (and which curently Windows Media v9 is by far in the lead) is a live encoding test.
I'm just a college student with little room, and so my computer is an all in one. As such, it is my pvr. I use the ATI All-In-Wonder 8500 DV.
While i have a 30 Gig drive dedicated for pvr purposes, it sucks recording in mpeg1 or mpeg2 because of the massive file sizes it creates.
I set out to find the codec that works best for live recordings of TV. Divx seems to do well video wise, but the audio gets out of sync fast. Xvid sucks on a live recording. I am able to do a 800x600 capture of live tv with WMV9 and not lose sync, and when viewed at a slight distance (4 feet) is good enough to watch what i missed.
The main benifit is that this translates my 30 gig drive into aprox 30 hours of storage. Get the other codecs to let me record live and not consume all my resources and i'll be happy as a clam.
Don't waste time... procrastinate now!
I haven't read the standard. Is this really so?
Point taken. But, you might also, as someone else that responded to me pointed out, use other sources than just DVD's. Satellite, captured NTSC, etc. would also be very good comparisons. What you're checking is something useful- which does the best job under the conditions provided by DVD's. I want more info than that (yeah, I know, do it yourself- if I had time, I might...
I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas