Theora 1.1 (Thusnelda) Is Released 184
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.
Q. What is Theora? (Score:5, Informative)
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.
Re:Maybe now Google will change their mind. (Score:5, Informative)
This page seems to say they have been addressed : http://people.xiph.org/~greg/video/ytcompare/comparison.html [xiph.org]
Re:What every player is missing (Score:3, Informative)
And I mean good support, not just something that works like a stream, but where you can seek and do everything like you can do with actual files.
Afaict the only way to read a portion of a file in a zip is to read and decompress the whole file up to the portion wanted so seeking is going to be pretty damn slow.
Re:Q. What is Theora? (Score:5, Informative)
Re:What every player is missing (Score:5, Informative)
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.
Re:What every player is missing (Score:4, Informative)
Re:Maybe now Google will change their mind. (Score:3, Informative)
Also of note, the comparison you said, actually doesn't say what you claim... It says that it beats the h263 youtube version at a lower bit rate. Read the conclusions - they admit that the h264 version on youtube is better quality.
smplayer allows arbitrary name subtitles (Score:4, Informative)
Just wanted to let you know that SMplayer [sourceforge.net] lets you load any file as the subtitle file. Of course, Mplayer itself does, too, but some people get intimidated by the command-line. With SMplayer, you go to the Subtitles menu, click on Load, and then pick whichever file you want.
In case anyone doesn't know yet, SMplayer is a user-friendly front-end for the powerful Mplayer program. Mplayer is probably the next best thing to an omnipotent video (and audio) player, but it's a command-line program with a bewildering array of options guaranteed to intimidate the weak of heart. SMplayer is a very well done user interface, just as easy to use as VLC but allows use of most of the features of Mplayer. SMplayer is to Mplayer what Ubuntu is to Debian.
Now, it still doesn't work on zip files. I wish someone had written SMplayer with the KDE toolkit instead of GTK+; then you could use the zip Kpart and just dive right into the Zip file (or even specify the subtitle filename as "fish://mylogin@myhomemachine/mypath/mysubtitlefile" and just pull it off another machine on the SOHO net).
Re:Maybe now Google will change their mind. (Score:1, Informative)
Why would 1.1 be worse than 1.0? Such senseless results are usually an indication that the people who conducted the benchmarks did something wrong.
In that particular case it seems they've been testing a theora built from theora's svn revision r15534, whereas the current revision is 16583 http://svn.xiph.org/trunk/theora/ [xiph.org]
This benchmark seems outdated.
Re:Dirac isn't shabby (Score:5, Informative)
That said, most handhelds can handle Theora, so providing both Theora and Dirac should cover most clients. Not the iPhone, of course, but if people will buy into a closed platform then they can't expect things to always work...
VLC has support for playing back Dirac streams.
The OS X builds prior to 1.0 had Dirac support, but 1.0 didn't and neither have any of the subsequent ones. No word on whether this is intentional or not from the VLC team, but playing a Dirac file now pops up an error saying 'dirac' is an unrecognised CODEC ID.
Re:What every player is missing (Score:4, Informative)
Re:What every player is missing (Score:3, Informative)
Re:Great, but... (Score:3, Informative)
Encoders such as Theora, DVD rippers, and GUIs for these are pretty much separate things. Normally an end user doesn't even end up in any kind of direct interaction with a Theora encoder, or an H.264 encoder implementation such as x264. The article is about encoders, not GUI applications that use them.
While I don't know much about MediaCoder, judging from screenshots on the site it's clearly a front-end that binds together these features -- ripping, decoding, processing (scaling etc.), and re-encoding, and gives end users a GUI for using them. It might use open source ripping and encoding libraries in its back-end for actually implementing these technical tasks, or it might have its own implementations (which I doubt). How it presents that functionality and workflow to the user in its GUI is independent of the details of how exactly the encoding etc. have been implemented -- or at least it should be.
It's true that most F/OSS GUIs for DVD ripping and encoding suck, Handbrake probably being the closest one I've seen so far to being both featureful and providing a reasonably humane GUI for general video transcoding. However, for actual encoder implementations efficiency is indeed the prime focus. (How easy the actual encoders are to use also has some importance, but that's mostly a direct concern only to power users who use the encoders directly and for developers who write software that uses the encoders as a back-end.)
Re:smplayer allows arbitrary name subtitles (Score:1, Informative)
"I wish someone had written SMplayer with the KDE toolkit instead of GTK+"
SMplayer is written using Qt and can be compiled with KDE options enabled. I do not know if it enables streaming from kioslaves, but there's bound to be some zip FUSE module for that.
Re:What every player is missing (Score:5, Informative)
But does it have hardware acceleration for .mkv out of the box?
You don't understand what MKV [wikipedia.org] 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.
Re:What every player is missing (Score:4, Informative)
But does it have hardware acceleration for .mkv out of the box?
No, because mkv is a container format. Hardware acceleration for a container format makes no sense. Other than to demonstrate that you don't know the difference between containers and CODECs (or between Gb and GB) was there a point to your rant?
Re:What every player is missing (Score:4, Informative)
No. On Mac OS X best shot is the the MPlayer OSX Extended [mplayerosx.sttz.ch]. At H.264 playback it's better than vanilla CCCP, but not as good as commercial CoreAVC.
VLC sadly is as hopeless as it was before. When I heard that they finally supported ASS subtitles I was excited to try it out - only to find that it still sucks at any contemporary media job.
What does being an astroturfer pay? (Score:4, Informative)
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...
Re:You know.. (Score:4, Informative)
The MPEG-LA license only protects you against the MPEG-LA members. In no way does it provide any sort of guarantee that someone who isn't in MPEG-LA won't start suing at any point in time. The argument against Theora in this regard can really be made against any codec.
As for your "safe" codecs, MPEG-1 may not be patentable my MPEG-LA's standards anymore, but that doesn't mean someone hasn't patented some part of the format at a later time than the standard came out, thus making the patent still valid today. Would such a patent pass the test of prior art? It depends on what they patented, but even if it didn't all it takes is for a patent grant by the USPTO to allow a lawsuit, and the patent must be invalidated afterwards. You still can get sued, even if the claim can be found baseless.
The BBC may have done research about Dirac and came up with nothing, but are they more open about what exactly they did than Xiph? If they are, please give a link showing what you considered acceptable for Dirac but not for Theora.
Re:Q. What is Theora? (Score:3, Informative)
However, "misappropriated unpaid-for format" is about a hair's width away from "stolen"
Which, like it or not, is still not a terribly inaccurate way of describing what's going on here. You could say "illegal unlicensed format", if you like, but I don't think it changes the tone significantly.
Unless you can provide evidence of widespread usage of "misappropriated" in anything but a negative way
Are you going to argue that patent infringement is a positive thing?
I'm not necessarily saying I disagree, but let's be clear, because it sounds like that's what you're advocating.
a better codec is better even if it's impractical or even impossible to use it given current hardware.
It's come down to a semantic argument, but this seems pretty blatantly wrong to me. It's "better" even if it's impossible? In that case, might I suggest a codec that assumes we've solved the halting problem?
Most people would agree that Crysis has better graphics than Pong
BIG GIANT KEY FUCKING WORD there. Try it again like this:
Most people would agree that Crysis is better than Pong
I think many people would agree with you, still, but it becomes a lot less clear-cut -- for some people, Pong really is a better game. Here, let me make it even simpler:
Most people would agree that Crysis has better graphics than World of Warcraft. Most, not all.
How many people would agree that Crysis is automatically a better game?
Do you get it yet? "Better" is by definition subjective, and only has meaning relative to other concerns. There is no such thing as a "best" video codec, at least not yet. I'll give you another consideration: not only price of an encoder or decoder, but the ability to produce a file which anyone can develop a decoder for, for free.
The fact that you don't consider a concern to be important doesn't make the concern go away, because like it or not, Virak on Slashdot is not the arbitrator of What's Best for Everyone.
I'm surprised you consider shoving words in my mouth a reasonable thing to do.
To abuse the rhetoric even more, I'm surprised you thought I was doing that. I was merely interpreting what you said. Specifically:
I was objecting to you greatly exaggerating how important patents are to users of video codecs. I never said anything about commerical usage being significant or not significant.
I was pointing out that commercial usage is significant to users of video codecs -- therefore, focusing on users and ignoring commercial usage is distorting the picture, even if you only care from a user's perspective.
The most popular ripping tools are open source and use open source codecs and nobody gets paid a cent over patents.
These open source tools are illegal in the US, as I understand it -- that's why, for example, Audacity requires you to install an mp3 plugin, after clicking through something.
This significantly hampers distribution of these tools -- for example, Dell can't distribute open source implementations of codecs, or even of DVD playback, with their Linux boxes. Instead, they license from Fluendo.
Or maybe an example you'd care about: Firefox cannot legally distribute any non-free codecs. They basically have these options:
Re:What every player is missing (Score:5, Informative)
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.
Re:What every player is missing (Score:3, Informative)
Your question is just as stupid the second time around... MKV is a container, just like AVI, MOV/MP4, etc. You can put any codec in it that you want, including H.264.