Even if you have some sort of personal vendetta against the xiph crew
and want to encode just once, using the <video> tag (with fallback to
using a flash player to render your h.264 file) has plenty of
benefits, so any perceived or real shortcomings of Ogg Theora aren't
too relevant to danger that the <video> tag presents to flash.
So, why would you double-encode:
1. (MAJOR): Because you're going to piss off firefox users. Firefox
has taken a stand and will not, as far as I understand, run <video>
tags unless there's an ogg theora source in there.
2. (ARGUABLE): Licence-free means its much easier to gain some
ubiquity; you're essentially future-proofing your content. Whether
this matters to you, or if its even a sound argument is a complex
issue that's being debated all over the interwebs and is probably not
too relevant for this forum.
However, just reason #1 (no firefox) is more than enough to spend the
extra harddisk space. harddisk space is at about 50 bucks a terabyte
these days. Unless you're youtube or vimeo, I'm having a hard time
seeing how 'I wanna save space' is going to fly as an argument. Maybe
the encode CPU time, where, last time I checked, Ogg Theora is quite a
bit slower. A lot of the patents Ogg Theora has to swerve around
involve efficient encoding tricks. That's not relevant for static
Submarine patents: Yes, that's a problem, but note that Opera HAS gone
for it, and they are a company as well. If there are submarine patents
out there, they are expiring, and the longer you wait to come forward,
the less legal standing you have. It becomes kind of hard to honestly
claim in front of a judge that you had no clue all this stuff was
happening, and (IANAL!) there's some onus on the patent owner to
defend the patent when infractions are noticed. That's not too
relevant in a legal culture where tossing enough greenbacks on the
scales of Lady Justice will tip em, of course.
quality-per-bit: Ogg Theora is very close. Google doesn't close their
body and html tags on their pages because browsers can handle it and
it saves them 8 bytes per transfer. Sounds ridiculous until you
realize the crazy amount of traffic google's servers have to handle,
so every bit counts for them. That's a _very_ niche argument for
everybody else, though. Bandwidth isn't exactly going to bankrupt you,
these days. It's not Ogg's fault: They can't use certain tricks
because there are some bullshit patents on common techniques that they
nevertheless avoid for lack of legal funds and a solid dedication to
playing it as safe as they possibly can.
Long story short, though: Okay, then don't encode ogg. The <video> tag
is still going to put a serious dent in actual flash usage. Especially
on the fastest growing segments of the market, users will get annoyed
at lack of <video> tag based sources (netbooks and phones, which run
with non-windows OSes and have either no flash player or a very sucky
one, and Mac OS X, which as mentioned has a flash player that eats CPU
for no good reason).
I'm really interested in how google is going to roll with this. They
played ball with Apple and released an API for them to get at the
underlying sources (that's what powers the iPhone YouTube app -
obviously not a flash player). This means there's a 640x480 non-
streaming h.264 copy (or that's the actual source of all youtube
videos, I haven't checked, and it doesn't matter) for ALL youtube
videos. Why NOT stick that in a <video> tag that falls back to a flash
player? Google goes out of their way to support HTML5 and promote the
vanilla web as the app platform of the future. I'd be confused if they
don't add <video> tags to youtube soon.