Slashdot Mirror
Theora 1.1 (Thusnelda) Is Released
SD-Arcadia writes to tell us that Theora 1.1 has officially been released. It features improved encoding, providing better video quality for a given file size, a faster decoder, bitrate controls to help with streaming, and two-pass encoding. "The new rate control module hits its target much more accurately and obeys strict buffer constraints, including dropping frames if necessary. The latter is needed to enable live streaming without disconnecting users or pausing to buffer during sudden motion. Obeying these constraints can yield substantially worse quality than the 1.0 encoder, whose rate control did not obey any such constraints, and often landed only in the vague neighborhood of the desired rate target. The new --soft-target option can relax a few of these constraints, but the new two-pass rate control mode gives quality approaching full 'constant quality' mode with a predictable output size. This should be the preferred encoding method when not doing live streaming. Two-pass may also be used with finite buffer constraints, for non-live streaming." A detailed writeup on the new release has been posted at Mozilla.
Maybe now Google will use Theora instead of the patent-encumbered H.264 in their new HTML5 Youtube.
That is if the issues have been addressed.
From the FAQ on the website:
Theora is an open video codec being developed by the Xiph.org Foundation as part of their Ogg project (It is a project that aims to integrate On2's VP3 video codec, Ogg Vorbis audio codec and Ogg multimedia container formats into a multimedia solution that can compete with MPEG-4 format).
Theora is derived directly from On2's VP3 codec; currently the two are nearly identical, varying only in framing headers, but Theora will diverge and improve from the main VP3 development lineage as time progresses.
Why? If the video and audio are compressed already, are you really gaining much by trying to compress them again? As for subtitles, aren't you better off with a container that supports them (i.e.: mkv)?
I'll just have to ask... why? Except for some holdouts from Usenet I think pretty much everyone uses torrents without any rar/zip compression. And even those are automatically decompressed if you set up something like hellanzb. It certainly doesn't save you any space, it's just for grouping files together and intgrity checking. Except torrents already do that, same with PAR on the Usenet side. It's completely redundant these days.
Live today, because you never know what tomorrow brings
What's the point? It's free, in both senses of the word.
Unlike H.264, you do not have to pay to use Theora.
Unlike H.264, you can use Theora in open-source software without worrying about being sued or shut down overnight.
Sure, if you don't care about freedom and don't mind paying for the privilege, go ahead and use H.264. But why would you want to, when you can use Theora however you want to, and without paying a cent?
Dirac strikes me as another codec worth following. It's available to all developers, high-quality, and in production use by the BBC during the Olympics (they said so in their Dirac promotional video). VLC has support for playing back Dirac streams. I'd guessing other players do as well.
I expect Theora and Dirac to be of interest to all who want high-quality free video codecs.
Digital Citizen
You could try mounting the archive(s) using FUSE, and then play the contents with whatever you want.
Unless it becomes popular, in which case the so-called "submarine" (actually they may not even be submarine) patents will come to the fore, and you'll have to pay.
I don't trust Xiph having read their comments about what exactly they mean by "Patent free", and having seen the silence over, say, Vorbis's apparent infringement of US Patent 5,214,742. Is Theora "safer" than Vorbis? Well, it's another DCT-based codec, just like 99% of the video codecs in use since H.261, and it's essentially doing stuff where everyone else is doing stuff. The chances of it not violating some patent somewhere is minimal to non-existent, as everyone and their brother is trying to come up with ways to improve DCT based algorithms that they can patent and then submit to MPEG or VCEG for incorporation into the next MPEG or H.26* video standard.
There are really only three standards that could be considered free of patent issues, and even then it's not entirely 100% certain. H.261 dates back to the mid eighties. The ITU lists no current patents applying to MPEG-1. (It's worth pointing out that Theora's predecessor, VP3, is considered to be somewhere between H.261 and MPEG-1 in terms of quality.) And finally, the BBC did an extensive search for anything that might hit their Dirac codec and came up blank, as well as proposing (and then withdrawing once published, so they count as prior art) some patents themselves, so Dirac is in the running too.
Theora? If I was a commercial concern, I would avoid it. I'd go for the predictability of a licensable codec ahead of one that almost certainly would be a target for patent lawsuits if it ever achieves critical mass, and possibly earlier.
I might feel differently if Xiph didn't play word games with the term "Patent free", and gave a straight answer on the issues of actual patents people have found, rather than turning around and saying "Yeah, we ran it by a lawyer, and they said we're OK, but we're not going to tell you why because it's our super secret defense we'll use if we're ever sued", which doesn't exactly inspire confidence, especially as nobody will ever sue Xiph anyway (Xiph just writes the software, they leave the packaging, compiling, possible selling, and actual using to everyone else.)
You are not alone. This is not normal. None of this is normal.
But does it have hardware acceleration for .mkv out of the box?
You don't understand what MKV is... it's not a codec, it's a container format for holding the video & audio stream along with assorted other information. This could mean multiple video and audio streams as is common for many movies dubbed in different languages or alternate video scenes. The hardware acceleration applies to whatever codec is used to create the streams held within the MKV file.. and that could be many different things from MPEG2, h.264, VC1, etc. etc.
AntiFA: An abbreviation for Anti First Amendment.
The first claim of 5,214,742 states (in part): "the improvement comprising selecting the length of the respective window functions as a function of signal amplitude changes", all the other clauses are dependent on this one.
Libvorbis lib/envelope.c, line 87:
The code goes on to NOT select the window length based on a function of the signal amplitude.
Never mind the fact that block switching transform codecs pre-dated that patent significantly and that switching based on amplitude changes is the most obvious criteria since the primary purpose of block switching is to reduce movement of signal energy from high amplitude parts into previous low amplitude parts.
So, how much do they pay you to spread bullshit? Are there openings available? My soul is also for sale, at the right price...
You don't understand how acceleration works.
It's up to the media player to ensure the streams are accelerated by picking a proper codec. It's also up to the media player to understand the container format. These things aren't very difficult, because of the codec frameworks that exist. On Windows, the most common one is DirectShow. (or whatever they've renamed it in Vista/Win7)
The media player has to pipe the stream data through to wherever it has to go - the Codec handles this, so once the media player picks a hardware accelerated codec, you're set!
VLC usually just sends it to its own CPU-based codecs, but other media players (like MPC, loaded up with directshow codecs for different formats) will send parts of it to the GPU to be decoded/accelerated. MPC-HC also has GPU shaders that can enhance the quality, regardless of the codec.
H.264 will be accelerated in .MKV, .MOV, and .MP4 unless your media player doesn't know what to do, which is unlikely because of the codec frameworks. The biggest issue is either going to be a missing codec(solved by using a pack like the klite mega codec pack) or your media player of choice(VLC) favouring compatibility over performance. VLC likes to choose CPU-decode codecs rather than GPU-decode ones. As far as I know, it also lacks GPU shaders.
Side-note: Recently I was uploading H.264/AAC to Youtube. There was a glitch on Youtube's end that it thought VBR-AAC was longer than it really was, so it rejected the video. After switching to .mp4(h.264/mp3), I had problems with audio desyncing. Then I switched to .mkv(h.264/mp3), and it worked fine. Seems like youtube has solid mkv support, just like most desktop software I've tested.