MPEG LA Extends H.264 Royalty-Free Period

Sir Homer writes "The MPEG LA has extended their royalty-free license (PDF) for 'Internet Video that is free to end users' until the end of 2016. This means webmasters who are registered MPEG LA licensees will not have to pay a royalty to stream H.264 video for the next six years. However the last patent in the H.264 portfolio expires in 2028, and the MPEG LA has not released what fees, if any, it will charge webmasters after this 'free trial' period is over."

Comments

From TFS

[Pojut]

However the last patent in the H.264 portfolio expires in 2028, and the MPEG LA has not released what fees, if any, it will charge webmasters after this 'free trial' period is over.

I would SERIOUSLY hope there are new protocols by 2028...

Re:From TFS

[olsmeister]

By 2016 would be better.

Re:From TFS

[poetmatt]

By 2010 would be better.

Re:From TFS

[biryokumaru]

You know, Theora video doesn't suck.

Re:From TFS

[jeanph01]

I copy pasted this info from here: http://lwn.net/Articles/372416/

These three Nokia patents look like they could be enforced against Theora:

http://www.google.com/patents/about?id=Ic0CAAAAEBAJ
http://www.google.com/patents/about?id=ieIVAAAAEBAJ
http://www.google.com/patents/about?id=zGWBAAAAEBAJ

Re:From TFS

[Fahrvergnuugen]

Until the patent submarine surfaces, then it's really going to suck!

Re:From TFS

[Duradin]

Device support for Theora does suck. And for me, that's the deal breaker.

Yes, yes, I know there's $obscure_bad_interface_linux_based_device that supports Theora and Ogg.

Re:From TFS

[biryokumaru]

The devil you say!

Re:From TFS

[alvinrod]

H.265 has an estimated release of 2012. We're just trading on MPEG LA standard for another, but they may offer free licensing of it for a while as well. Personally, I don't think they should be able to charge content providers squat. They can sell users an encoder and charge for decoders in products, but what anyone does after that shouldn't be any business of the MPEG LA.

Re:From TFS

[nxtw]

This comparison shows that Theora is close to Google's speed-optimized H.264 encoder at 500 kbit/sec. Not better. The author of the page tries to confuse the issue, but admits, "In the case of the 499kbit/sec H.264 I believe that under careful comparison many people would prefer the H.264 video."

Re:From TFS

[Anonymous Coward]

The results are quite different if you compare Theora to a good H.264 encoder like x264.

Some recent comparisons:
Videos Difference especially noticeable on the "The Island" trailer because of the high motion scenes.
Metrics Animated content. Relatively new.
Metrics By one of the Xiph guys. A little older. Huge lead for x264.

Re:From TFS

[pbhj]

Why is Theora more susceptible to submarine patents, or indeed granted patents that simply have not yet been enforced, over the technology of h264?

Re:From TFS

[pbhj]

Device support for Theora does suck. And for me, that's the deal breaker.

[Bad?] car analogy: There are less mechanics that can properly service a Skoda than a Ford. If you give away Skoda's to everyone on the internet then very shortly you'll find that the after "sales" market and the support services for Skoda soon outstrip those for Ford (at least in quantity!). Indeed you'll find that modders develop optimisations too.

Re:From TFS

[Anonymous Coward]

Animation is inherently better suited for small transform size codecs. Measuring animation quality is important, but the results are not going to be relevant for other video.

As to how relevant numbers like PSNR are to codec comparisons: "It is shown that as long as the video content and the codec type are not changed, PSNR is a valid quality measure. However, when the content is changed, correlation between subjective quality and PSNR is highly reduced. Hence PSNR cannot be a reliable method for assessing the video quality across different video contents." (see
"Scope of validity of PSNR in image/video quality assessment" by Huynh-Thu).

I do believe x264 is usually better than Theora that and sometimes the difference is significant. It's just that linking references like that looks like they support your point in an objective and relevant manner: they don't.

Re:From TFS

[delt0r]

There has been litigation attempts against h.264 and mpeg2. A license agreement specifically states that its not MPEG LAs problem and they don't promise that someone else out there wont have a patent over their codecs.

Fact is no software is safe with software patents. Especially in the US where everything is just let though.

Re:From TFS

[LBt1st]

>You know, Theora video doesn't suck at 400x226.

Fixed that for you.

Re:From TFS

[Anonymous Coward]

Yes, metrics aren't a perfect representation of what humans perceive as quality. In other news water is wet.

I posted these metrics comparisons because one of them is from xiph and the other is recent enough to use a prerelease of Theora 1.1. People are always complaining when you link older comparisons. I also linked actual videos, encoded with the release version of Theora 1.1 so that people could see the difference themselves. Theora isn't even able to encode the perfectly still "This preview has been approved..." warning in front of the trailer, which is by the way real life content and not animation, without introducing clearly visible artifacts, let alone the trailer itself where it turns into a blocky mess. If you throw 50% to 100% more bitrate at it then Theora is on par and that's not bad for a codec based on old technology (VP3).

The reason I post is that whenever the topics of codecs comes up somebody pulls that one comparison between Theora and the Youtube H.264 encoder out of the depths of the internet, post it as proof that Theora is just as good as H.264 and gets modded +5 when in reality it just shows how abysmal the implementation Youtube uses is. Comparing Theora to an especially crappy implementation of an other standard and claiming comparable quality is intellectually dishonest and while I'm totally for open standards* I think they should be promoted on their merits (Free/open, low CPU usage on encoding/decoding, good enough quality) and not on some made up claims (just as good as the non free stuff).

*) Theora should have been mandated in the HTML5 Standard as a baseline, but the option to use other codecs should have been left open IMO.

Re:From TFS

[discord5]

You know, Theora video doesn't suck.

<sarcasm>

Oh boy oh boy, a comparison on xiph.org. I'm sure that this will be unbiased in any way. From the conclusion:

The primary challenge is that all files at these rates will have problems, so the reviewer is often forced to decide which of two entirely distinct flaws is worse. Sometimes people come to different conclusions. That said, I believe that the Theora+Vorbis results are substantially better than the YouTube 327kbit/sec. Several other people have expressed the same view to me, and I expect you'll also reach the same conclusion.

I'm totally convinced with such strong arguments. He's clearly gone his way to show flaws in both codecs, instead of just encoding a video with two codecs and letting the audience decide.

</sarcasm>

Re:From TFS

[blueZ3]

I don't think it's possible to "optimize" a Skoda. :-)

Re:From TFS

[Anonymous Coward]

Dirac is better than theora and is roughly equal to h.264. There are no patents associated with it (the patent applications from the BBC lapsed and it doesn't infringe on any patents).

Re:From TFS

[drinkypoo]

[Bad?] car analogy: There are less mechanics that can properly service a Skoda than a Ford.

That is totally false. Almost every wrecker has a car crusher.

You also forget that Skoda is just an ugly Volkswagen now...

Re:From TFS

[poetmatt]

I was quite intentionally implying that we should be using Theora and not H264.

Re:From TFS

[Anonymous Coward]

incompetence in the patent office has fucked us all

Re:From TFS

[CSMatt]

I don't understand patentese or codecs, but could they not also be enforced against H.264/AVC as well?

Re:From TFS

[mcrbids]

Sorry to say this, but This just isn't true. Ogg/Theora holds up quite competitively against H.264, demonstrably, TODAY. I don't know why this FUD gets spread around, but having the Internet move to H.264 as a "standard" is akin to shooting ourselves in the collective foot.

Ogg/Theora is here today, it's competitive with H.264, and isn't encumbered like H.264. The extension of "free" is just MPG group trying to submarine it into widespread use before they come in with terms. I swear, sometimes, we all live with the battered wife "Stockholm" syndrome. We've seen this before, and we're about to get it again.

Re:From TFS

[BikeHelmet]

Nokia likes OSS. They're constantly releasing stuff for free. QT... Maemo...

Nokia makes money off hardware sales.

I don't believe Nokia is a patent troll, but they would likely keep these in their arsenal in case some other company (like Apple) sues them.

Re:From TFS

[Thinboy00]

Fact is no software is safe with software patents. Especially in the US where everything is just let though.

Not for much longer

Re:From TFS

[Myen]

That particular comparison keeps getting reposted as the proof that Theora is feasible.

Theora may or may not be comparable in quality to H.264, but that comparison doesn't tell me either way. It completely ignores the H.264 encoding process, which means that Theora has the advantage of taking however long it needs to compress things. Lots of things involve a time/space (memory or disk) trade off, that needs to be taken into account too.

I don't particularly like the licensing issues around H.264 / MPEG*, but that doesn't mean I am willing to take an unfair comparison either.

Re:From TFS

[LostMyBeaver]

Implemented the first two. Now that I read this, I implemented the first one in a way which was more efficient and possibly better quality (though I'd have to spend a week in Matlab to prove it) and even better wouldn't infringe. This patent definitely wouldn't be an issue for Theora given its specificity. It's made to get Nokia a cut of the licensing pie.

Second one... that's the prediction patent. I'd love to own this one since it is practically the foundation of the greatest improvement made in H.264 over previous incarnations. Don't know how Theora does it, but it practically covers all modern forms of prediction that I've seen. It's a hell of a well written patent also since it can be easily interpreted to cover pretty much any modern CODEC (except wavelet ones which are nailed by a thousand other patents).

Third one, I got lost in the lawyer gibberish, but from what I read, it would probably not survive a court case, I think practically the entire thing is covered in MPEG-2 patents. It's really just a matter of transmitting quantization values as part of the stream to the decoder. The only thing "new" about it is the issue of the "default values", and I'm pretty sure a good lawyer would get that tossed out as being obvious. But I'm almost 100% sure that all the tech of interest in it is covered in H.262 under the quantizer extension.

I'm really not a lawyer, but of the 3 patents you mentioned, the first is avoidable and the third has to be easy to get tossed out, but could awaken the exercise of the H.262 patent for the quantizer extension (if it's still alive). The second one could pretty much force the world to a wavelet based model, but motion compensation for wavelet compressions is UGLY.

Re:From TFS

[Anonymous Coward]

The extension of "free" is just MPG group trying to submarine it into widespread use before they come in with terms.

My thoughts exactly...

Re:From TFS

[Anonymous Coward]

I watched that comparison the last time it was posted here. Theora may be okay compared to H.264, but it still isn't as good as H.264. For example, go to 1:05 in the Theora and the H.264, pause the videos and compare the detail in the tree in the background, the h.264 video clearly has more detail.

Now, I'd like Theora to be as good as H.264, but it just isn't.

Firefox Bait

[Anonymous Coward]

The trial period will need to last just long enough to get it adopted as the HTML5 standard.

Hopefully,

[Anonymous Coward]

We'll be using free codecs by then.

Re:Hopefully,

[petermgreen]

Unfortunately I don't have much confidence of that happening, gif still remains pretty common despite how long the superior png format has been arround.

With video and audio things are even worse with major vendors outright refusing toe support the unencumbered option (unlike png which has wide support).

Personally I think there is more chance of internet bandwidth increasing to a level where we can revert back to a format where the patents expire sooner than there is of a new unencumbered format taking hold.

Re:Hopefully,

[zippthorne]

Correct me if I'm wrong, but I thought that was due to the extremely short window between when compuserv started going after gif offenders and when the patent for gif actually ran out. IIRC, png wasn't even supported in IE until after the patent on gif ran out, further hampering its adoption.

Re:Hopefully,

[fuzzyfuzzyfungus]

Luckily, patents are not(yet) subject to the absurd lengths given to copyrights, so it is possible to move to free formats simply by standing still.

My understanding is that, somewhere in the 2006-2008 region, all credible .gif patents had finally expired. The format still sucks compared to .png; but it doesn't have to pay unisys for the privilege.

Re:Hopefully,

[Anonymous Coward]

Nitpick.

UNISYS held the patent. Not Compuserve.

Re:Hopefully,

[petermgreen]

png wasn't even supported in IE until after the patent on gif ran out
I'm pretty sure it was supported in the sense that non-transparent images and palleted images with binary transparency were supported even as far back as IE4 long before the patent ran out.

Full support took a lot longer (it was finally added in IE7) and unfortunately while that wasn't really a problem for those replacing gifs with pngs misunderstandings and exaggerated claims about it almost certainly did impact png adoption.

Re:Hopefully,

[petermgreen]

Luckily, patents are not(yet) subject to the absurd lengths given to copyrights, so it is possible to move to free formats simply by standing still.
Indeed and that is what I predict will happen with audio, mp3 is "good enough" and only has a few years left to run on the patents it's a bit of a minefield working out exactly when because of the sheer number of patents surrounding it, the problem of identifying which of them are likely to hold up in court,the issue that the legal status will vary by jurisdiction and the issue that more modern encoders may use techniques not listed in thr original patent*.

With video things are less clear, the patents on the currently most popular video format still have a long time to run. With networks increasing in capacity going back to an older codec may be a way to get support from both sides.

*mp3 like many mpeg family standards is built on the principle of defining the behaviour of the decoder but leaving the details of how the encoder decides what aspects of the sound to encode and with what level of accuracy to the individual encoder, this allows encoder performance to be improved without breaking the standard.

Data transfer?

[FlyingBishop]

How does a patent license allow you to charge for transmitting data over the Internet? I get that the encoder requires a patent license, and the decoder requires a patent license, but sending an encoded file over the Internet? That's just absurd.

Re:Data transfer?

[sakdoctor]

Software patents? That's just absurd.

Re:Data transfer?

[Overzeetop]

Decoding per byte. It's a simple rental model, like the old processor charges in the 60s & 70s on mainframes.

Re:Data transfer?

[Looce]

How does a patent license allow you to charge for transmitting data over the Internet?

Simple: it doesn't. However, it's a good measure of how much revenue MPEG LA expects you to be bringing in from your use of their standards, and as such is a nice way to scale up licensing fees according to your revenue.

Think of it as a way of implementing this rule: You give us X % of the revenue you bring in from your use of our standard, and in exchange, you can use our standard. If the main use of your company is to deliver solutions based on our standard, this will be X % of your revenue. If you only make incidental use of our standard, your license is going to cost you lower.

(And, of course, if you find something else that's good enough for your purposes and is free or costs less than our standard, you're free to use it.)

Re:Data transfer?

[BZ]

The H.264 patents are method patents, not software patents.

Re:Data transfer?

[pbhj]

Semantics. This is just one of the tricks one uses in writing patent applications. The method is performed using software (or possibly hard coded in a special chip) on a computer.

Re:Data transfer?

[BZ]

Well, hold on. How is performing a method using wires carrying electrons to carry a digital signal different from performing a method using wires carrying electrons to carry an analogue signal (e.g. an FM radio receiver)?

Should a mechanical device that performs a task be patentable but an integrated circuit that peforms the same task not be patentable?

But in any case, the point is that the patents involved have been granted in all sorts of jurisdictions that don't allow "software" patents. This is bad from the point of view of open-source projects that want to use H.264, for sure. But it seems to me that the fundamental idea of patenting the methods used in H.264 is sound, assuming the idea of patents is sound at all. This last is up for debate, of course.

Re:Data transfer?

[delt0r]

Then software decoders and encoders would be in the clear. But they are not. Not even in the EU....

Re:Data transfer?

[BZ]

> Then software decoders and encoders would be in the clear.

Why? The point is that anything that uses the method, whether it's "software" or "hardware" (whatever those even mean in practice) is covered by the patent.

Re:Data transfer?

[delt0r]

In the EU where software patents are granted but currently untested as enforceable in the courts. I can legally use h.264 in software (still lawyers squirm). In the US where software patents are enforceable i cannot.

In the EU if i make a hardware player, then yes i need a license for H.264. Its needs to be more than just hardware that *could* play with the instillation of software.

Its tricky with when/who installs the software onto the hardware and lawyers don't want to give you a straight answer. But there is a legal distinction.

Re:Data transfer?

[delt0r]

By making you agree to these terms before giving you a license for an encoder/decoder. So the contract to encode, is that you pay to upload what you have produced.

So if I make a better chip maker, i can license it with fees on the total number of chips produced rather than a fixed fee on the device.

Patents in this cases cut far further than just the cost of getting a license. Its the fine print that can be put into this license.

Just look at apples products. The terms and conditions means you are not permitted to encode anything with h.264 without an extra license from MPEG LA if you are doing for commercial reasons.

Re:Data transfer?

[BZ]

> In the EU if i make a hardware player, then yes i need a license for H.264

See, the thing is.. what makes a hardware player? Is an FPGA programmed to decode H.264 a "hardware player"? What about an FPGA not thus programmed that comes with the software to so program it?

I'm not quite seeing how one can draw a legal distinction here given that I can't even draw a _technical_ distinction.

Re:Data transfer?

[delt0r]

And thats why the lawyers don't want to say either. And they seem to take a long time to say "not sure", bloody billable by the hour.

However a PC with software is software, and no one has had problems with that here... ie they can't be covered by patents.

Re:Data transfer?

[Draek]

Well, hold on. How is performing a method using wires carrying electrons to carry a digital signal different from performing a method using wires carrying electrons to carry an analogue signal (e.g. an FM radio receiver)?

Because the method for using wires carrying electrons to carry a digital signal can be accurately described as a Turing Machine (given that it has a software implementation) and therefore, per the Church-Turing thesis, also as a lambda function and a recursive function as well. And some of us feel particularly strongly about bringing patent bullshit to the realm of Mathematics, which the latter two models are a part of.

To put it in layman's terms, anything written for a computer can be described in math, and I (well, and many others) believe anything that can be described in math shouldn't get a fucking patent in the first place.

I'll leave to the physicists in the crowd the matter of seeing whether a similar argument can be made for other kinds of patents as well, though I'd initially say 'no' as I'd say assuming otherwise would imply the universe is deterministic, which is still an open question. But dunno really, I'm no physicist.

Re:Data transfer?

[Anonymous Coward]

damn you're a dumb shit. i bet you use linux too huh?

Re:Data transfer?

[BZ]

You didn't answer my question. The specific case of an FM radio receiver can in fact be described in math; in fact it's just an implementation of certain mathematical operations if you want to view it that way. The wave equation and the behavior of EM waves are pretty damn deterministic to a first approximation (if you ignore multipath issues; if you want to take them into account then you have to worry about why you have multipath).

It's not clear to me why you think building a clever mechanical device to carry out a simple mathematical operation should be patentable while building a clever mathematical device to carry out a "it looks simple" operation like "make the video take up less space" shouldn't be. Seems to me the same arguments would apply to both.

Also of note: the key to a patent is usually not a specific piece, it's how you put them together. You don't patent a wheel or a gear (in most cases); you patent a specific way of putting together wheels and gears. The H.264 parents are not on basic building blocks like FFTs; they're either on clever modifications to these building blocks (think "lighter but just as strong wheel") or on specific ways of combining these blocks.

Now maybe you're arguing there should be no patents at all, period. That would be self-consistent. What you said above is not, so much.

Re:Data transfer?

[Draek]

It's not clear to me why you think building a clever mechanical device to carry out a simple mathematical operation should be patentable

I don't. I specifically said that a physicist should answer that question, as I don't know enough about the subject matter to provide something more than an uninformed opinion. I do know, however, enough about mathematics and software to state that if we hold mathematics to be unpatentable, then it logically follows that software should be equally so. Whether things that can't be described by math should be patentable or not, or whether they exist at all simply isn't my business, nor does it matter as far as the h.264 codec is concerned.

The H.264 parents are not on basic building blocks like FFTs; they're either on clever modifications to these building blocks (think "lighter but just as strong wheel") or on specific ways of combining these blocks.

Let me restate my position a bit simpler and more strongly: if a piece of software, *ANY* piece of software, can theoretically infringe on your patents, your whole patent should be thrown out as far as I'm concerned. How it affects patents on lighter wheels or stronger gears I don't know nor particularly care. I do know, however, that it specifically means goodbye for anything covering h.264.

Re:Data transfer?

[BZ]

> I specifically said that a physicist should answer that question,

I do have a BS in physics. Doesn't make me a physicist, of course.

> to state that if we hold mathematics to be unpatentable, then it logically follows that
> software should be equally so

Why are we holding "mathematics" (whatever that is in this case; the definition is pretty fluid, and I say that as someone with a good bit of experience with the subject) to be unpatentable?

> if a piece of software, *ANY* piece of software, can theoretically infringe on your
> patents, your whole patent should be thrown out as far as I'm concerned.

So you keep saying, but WHY? I realize this is how you personally feel. What's not clear to me is what the argument for your feelings is that would actually convince someone, as opposed to you just repeating that you feel that way over and over again.

As far as I can tell, either you're saying we should have no patents at all (why or why not?) or you're applying a double standard based on some criteria you haven't bothered to define.

Re:Data transfer?

[Draek]

Why are we holding "mathematics" (whatever that is in this case; the definition is pretty fluid, and I say that as someone with a good bit of experience with the subject) to be unpatentable?

First off, because it's the underlying assumption I made. It also works the other way, if you prefer it: if software can be patentable then so is mathematics and, therefore, any judgement as to the validity of software patents should be made under that assumption. Secondly, because it makes sense, polluting mathematics in particular and science in general with patents goes against the whole concept of collaboration and open share of knowledge.

But most importantly, because that's the law in a huge part of the world, the US included. It's not a radical change as far as legalities are concerned, it's merely reinforcing old ideas already put in practice.

As far as I can tell, either you're saying we should have no patents at all (why or why not?) or you're applying a double standard based on some criteria you haven't bothered to define.

Again, wrong. I'm merely stating "this is the criteria we should use to define whether something is unpatentable, and if we assume it then at least this entire field would be unpatentable, including the patent in question on this thread". I believe my criteria to be reasonable and well within both the letter and the spirit of current laws on the matter (as per above), and it's a fact that if my criteria were applied, software patents in general and the h.264 ones in particular would have to be thrown out.

If patents in general are affected or not simply isn't my concern, nor relevant for the matter at hand.

Re:Data transfer?

[BZ]

> But most importantly, because that's the law in a huge part of the world, the US included

Ok, so you're saying the existing law already has a double standard and your quibble is with where the boundary the law draws in applying this double standard lies? I can buy that.

That said, I see no inherent issue with being able to patent a clever way of combining mathematical operations to, say, extract a signal from a noisy data stream, if we're ok with being able to patent combining spiky bits and a roller to separate cotton seeds from cotton fibers.

See http://www.paulgraham.com/softwarepatents.html for some more thoughts on this (I just ran into it when I searched on "patent algorithm", and it eerily echoes exactly what I was saying earlier).

Now there is an important point here: If you're going to have patents, they must be granted for specific inventions, not overbroad descriptions. Patenting "a roller with teeth" would never fly; patenting a roller with teeth being used in a particular way to get a particular effect is a different issue entirely. Similarly, patenting a mathematical technique may or may not make sense depending on what exactly is being patented. This is, sadly, somewhat subjective, but that's inherent in the patent system.

> polluting mathematics in particular and science in general with patents goes against the
> whole concept of collaboration and open share of knowledge.

Does it, though? If I come up with a new way of doing signal processing that has interesting applications, I have two obvious options for monetizing it: keep it a trade secret and start a closed-source company to sell products based on it, or get a patent on the method, which involves sharing the method with others. That's the premise of the patent system, in fact. Perhaps you feel that this is not a good enough argument for patents; I might buy that. But then that's true for all patents, not just algorithm patents (whatever one might want to call them).

Re:Data transfer?

[Anonymous Coward]

By making you agree to these terms before giving you a license for an encoder/decoder. So the contract to encode, is that you pay to upload what you have produced.

Which makes me wonder if you could get around this by having one company doing the encoding and a separate company doing the distributing.

Nice

[jvkjvk]

What a charming business model.

Oh well, I guess webmasters could have always used something else, right?

It's particularly nice that web masters are giving billing information 6 years early, so the company doesn't have to do much to track down the first round of suck^H^H^H^H customers to bill them for use.

There's nothing like getting your IP embedded deeply into everyones processes (with their complete acknowledgement of that fact) and then seeking rent against the cost of changing it.

I would expect that many companies don't have migration plans in place, I don't know, not my business.

Regards.

Re:Nice

[qoncept]

And all while giving you an additional 6 years on your contingency plan for a technology that will be obsolete by the time you could potentially be charged for it. How do they sleep at night?

Re:Nice

[Threni]

Google seems to be changing video on Youtube to use HTML 5 pretty quickly. Why can't other people?

Re:Nice

[BadAnalogyGuy]

Google seems to be changing video on Youtube to use HTML 5 pretty quickly. Why can't other people?

I don't think Google would let them...

Re:Nice

[TheRaven64]

Six years? Six years is a very long time in CODEC evolution. Six years makes computers sixteen times faster. Network connections will be much faster. By 2016, I doubt there'll be many computers around that can't play back VC-2 (based on Dirac, patent free) in use and VC-2 hardware acceleration, which is just starting to be deployed, will be much more widespread. Remember the CODECs we were using six years ago?

MPEG-1 didn't last six years as a standard for Internet video. Neither did RealVideo. Neither did Sorenson (in QuickTime or Flash containers). I'd be surprised if H.264 does.

Re:Nice

[slim]

Google seems to be changing video on Youtube to use HTML 5 pretty quickly. Why can't other people?

Because they feared the charges in 2011.

Now they can fear the charges in 2016 instead.

Re:Nice

[glop]

They are using H.264 to do the encoding. I think they are using the free trial and that might be why they are buying On2. They want so be sure that Youtube can free itself from H.264 some day.

Re:Nice

[slim]

In 6 years time, there'll be an awful lot of iPhones/iPads (and their descendants) in the wild.

Expect H.264, and maybe some other patent-encumbered standards, to be the only video format a web site can use in order to be viewed on these devices.

The options for video websites in 2016? Pay up, or abandon iPhone/iPad users. Plus who knows how many other closed platforms.

Re:Nice

[NNKK]

You're a bit confused. HTML 5 is a markup language, not a codec. YouTube's HTML 5 site is still in H.264, it's just not using Flash to play it.

Re:Nice

[iainl]

In 6 years are bound to add something else to Quicktime. If that then isn't supported by the iPad and iPhone, I'd be shocked.

Re:Nice

[Anonymous Coward]

I'd be willing to bet that in six years time, computers will be only twice as fast (per dollar).

Re:Nice

[Hurricane78]

Please, dude... I know you loooove Apple more like your (non-existing? this is /. after all ;) girlfriend. And that’s all good. Do whatever makes your happy.
But please keep it down with using the Apple brand name for every type of product out there. Ok? :)
I hate to tell you, but: Reality does not equal Apple! ;)

You could just as easily have said the factually correct thing:
In 6 years time, there’ll be an awful lot of smart phones / mobile computers in the wild.

Frankly, I doubt that even in the US many people will still care about Apple that much in 6 years, when the reality distortion bubble (the one that lets their products look like they could compete) will become its first gaping holes.
And that is not meant as as offense. Even though religious people will see it like that anyway. (See Mohammad caricatures.)

Re:Nice

[Anonymous Coward]

Pay up, or abandon iPhone/iPad users.

Its 2016. Why haven't you upgraded to the iPhone 5GSXFi?

Re:Nice

[slim]

Why would they?

Apple will be raking in the royalties when MPEG LA (of whom they are members) start charging.

Re:Nice

[Sir Homer]

It's worth noting none of those formats where ever pushed as an Internet standard. We still use JPEG/GIF even though there are better formats out there for over a decade. Sometimes being "industry accepted" is more important then being "the best".

Re:Nice

[BZ]

> Remember the CODECs we were using six years ago?

You mean H.264 (standardized in 2003)?

Re:Nice

[nxtw]

The options for video websites in 2016? Pay up, or abandon iPhone/iPad users. Plus who knows how many other closed platforms.

It's much more than just Apple's portable devices; they just happened to include H.264 first. H.264 decoders exist in:

• all Blu-ray players
• many new PCs, including just about all with NVIDIA or ATI GPUs and many Intel GPUs
• nearly all HD satellite receivers, and many countries' terrestrial HD receivers (Europe)
• IPTV systems
• portable media players / cell phones with video players, including Android and BlackBerry devices
• videoconference systems

Re:Nice

[slim]

Please, dude... I know you loooove Apple more like your (non-existing? this is /. after all ;) girlfriend. And that’s all good. Do whatever makes your happy.

Way to completely miss my point that Apple's choices in the client world -- where they do have a lot of influence -- will be forcing the hands of web site owners. For this reason I do not "looooove" Apple.

But please keep it down with using the Apple brand name for every type of product out there. Ok? :)
I hate to tell you, but: Reality does not equal Apple! ;)

You could just as easily have said the factually correct thing:
In 6 years time, there’ll be an awful lot of smart phones / mobile computers in the wild.

Currently Safari Mobile has ~60% of the mobile browser market. . Even if that drops to, say, 20%, do you reckon web sites would feel empowered to drop H.264 support, if that meant abandoning those users?

Plus, as I said, other popular mobile platforms are just as likely to be closed and locked down to H.264

Re:Nice

[Rockoon]

Not all of it is H.264. Some of it appears to be Theora or some other codec that Opera supports natively.

I was thinking that maybe the stuff posted to Google Video was encoded in Theora and it gets cross-posted to YouTube, while the stuff posted directly to YouTube gets encoded in H.264, but thats just a guess (it could also be that it doesnt bother to covert theora encoded uploads of the correct size)

Re:Nice

[slim]

I was thinking that maybe the stuff posted to Google Video was encoded in Theora and it gets cross-posted to YouTube, while the stuff posted directly to YouTube gets encoded in H.264, but thats just a guess

Don't guess. In HTML5:

To support Safari, you have to use H.264 (OK, you can add Theora support to Quicktime, but let's assume very few users do this, and nobody wants to be the arsehole site that forces them to do so)
To support Mobile Safari, you have to use H.264
To support Firefox, you have to use Theora. (hence YouTube currently doesn't support HTML5 for Firefox)
Chrome handles both formats.
Opera: definitely handles Theora, not sure about H.264

To be viewable in all HTML5 browsers, you're going to have to encode twice. The Theora encoding/streaming is going to be free. The H.264 encoding/streaming is going to be gratis until 2016. But once you've started, it's going to be awfully difficult to stop.

Re:Nice

[TheRaven64]

Just because it was standardized doesn't mean it was in use. MPEG-1 was standardised in 1993, but it wasn't until around '98 that people were recommending it as the de-facto standard for Internet video (it was the thing all browsers could play at the time). The computer I had in 2003 was brand new and couldn't even play 720p H.264 without dropping frames, especially with the decoders available at the time. It wasn't until around 2008 that most computers were fast enough for H.264 playback. A few people were using it before then, but not many.

Re:Nice

[slim]

Though some of those are relevant too, the important point about the Apple devices is not so much that they support H.264, but that they don't support anything else (at least, nothing else relevant to the Web)

Outside of the Web, I care less. The Web is meant to be somewhere where creating/publishing is free to all (ignoring physical hosting costs).

Re:Nice

[nine-times]

...Plus who knows how many other closed platforms.

It's not really about "closed platforms". iPhone/iPads have hardware for decoding h264. They don't have hardware support for Theora.

Re:Nice

[Kjella]

Remember the CODECs we were using six years ago?

If you count DivX ;-) 3.11 alpha as MPEG4 ASP compliant which isn't quite true but later DivX/Xvid versions were, we've been using the same codec since 1998 only slowly phasing it out with H.264. As for VC-2, there's no wikipedia page for it, the first hit on google has nothing to do with it, the fifth hit is a blog post from 2008 where the last comment says it'll be a near lossless production/archival codec unsuitable for Internet use. So if you ignore all the evidence to the contrary, I guess you could be surprised but none of the rest will be surprised if H.264 lasts...

Re:Nice

[nxtw]

Though some of those are relevant too, the important point about the Apple devices is not so much that they support H.264, but that they don't support anything else (at least, nothing else relevant to the Web)

Most of these devices have the same limitations as Apple devices; they decode a few things in hardware and nothing else:

• all Blu-ray players: support MPEG-2, VC-1, and H.264
• many new PCs, including just about all with NVIDIA or ATI GPUs and many Intel GPUs: have at best MPEG-2, VC-1, and H.264 hardware decoding support
• nearly all HD satellite receivers, and many countries' terrestrial HD receivers (Europe): support MPEG-2 and H.264
• IPTV systems: support H.264 usually
• portable media players / cell phones with video players, including Android and BlackBerry devices: support H.263 and H.264
• videoconference systems: support H.263 and H.264

Apple devices use the same hardware decoders as other companies do.

Re:Nice

[Kohlrabi82]

People still use Xvid, which is nearly 8 years old.

Re:Nice

[arose]

Most of those are not relevant in regards to HTML5. Apple's portable devices are, since they can browse the web.

Re:Nice

[pbhj]

HTML4 has been with us since 1997. There's not much reason to think that HTML5 will be around for less than 6 years.

Re:Nice

[nxtw]

Most of those are not relevant in regards to HTML5. Apple's portable devices are, since they can browse the web.

All of these devices are relevant. The same H.264 program can be streamed by a HTML5 client, by Flash, by a video player program, etc. It would be wasteful to have two separate copies of video for devices that support HTML5 and devices that do not.

Many devices supporting video playback share hardware; for example, the chips found in many standalone media streamers were designed for use in Blu-ray players.

• Blu-ray players have Internet connectivity and many already have video streaming
• PCs have Internet connectivity and web browsers
• Many new digital television receivers have internet capability; in the USA, DirecTV receivers can stream video over the internet
• IPTV systems are by definition connected to an IP network and probably the Internet
• Portable media players and cell phones are often connected to the internet via cellular and/or wifi networks
• Videoconference systems are usually connected to IP networks as well

And if you limit the discussion to mobile devices with web browsers, there's more than Apple. There are Androids, BlackBerries, Windows Mobile, WebOS, etc. - and most of these devices already have H.264 support.

Re:Nice

[tepples]

Six years makes computers sixteen times faster

No, it makes computers sixteen times denser. Denser was correlated with faster until CPU speeds hit 3 GHz, after which density just meant more cores. Future codecs will need to be more parallel.

Re:Nice

[tepples]

The options for video websites in 2016? Pay up, or abandon iPhone/iPad users.

Then charge only iPhone/iPad users, and you might be able to count only this revenue as "related revenue".

Re:Nice

[TheRaven64]

Video decoding is an example of an embarrassingly parallel problem. If you've got enough RAM (which you almost certainly will in six years, even if you don't now) then even a naive serial implementation can decode a sequence of frames between two key frames in parallel. Then you just buffer these. Each core can decode at 1/16th of realtime, as long as you have 16 cores. There'll be a slight delay at startup and when you seek, but that's all. Most CODECs, however, make it trivial to decode regions of the frame in parallel, so you don't need to do anything that ugly.

Re:Nice

[Anonymous Coward]

If H.264 becomes the standard, or defacto standard, for HTML5, we're going to be *lucky* to extricate it and its licensing costs from our browsers within 15 years. Standards evolve very slowly. HTML5 still isn't finalised. When it is finalised, it'll still be a year or so before all browsers more-or-less support it completely.

By the time the free trial expires, there'll be no easy way to remove H.264. That's the danger of willing admitting a patented codec into a standard which will should last decades.

Re:Nice

[Svartalf]

Considering that each and every iPhone is using a DSP to decode...all Apple has to do is cave and give out a firmware update to whatever the new thing ends up being.

Re:Nice

[Rockoon]

Did you even read what I wrote, and what I replied to?

Some of the stuff on YouTube is most definitely NOT H.264 because Opera plays some of it while using YouTube's test HTML5 mode.

Re:Nice

[Jeremy Visser]

Some of the stuff on YouTube is most definitely NOT H.264 because Opera plays some of it while using YouTube's test HTML5 mode.

Because your personal testimony counts for...oh wait. Nothing. You've already been told not to guess once. Take this as your second warning.

I'll believe it when I see it. Until you provide some sort of proof (URL to non-H.264 and non-FLV YouTube video would be nice), I won't believe that.

Opera uses GStreamer as a backend, and 'will also be able to use "anything that Gstreamer can handle,"'. What quite likely actually happened was that the video in fact was H.264, and was using the H.264 decoder in your system's GStreamer.

Re:Nice

[Rockoon]

I'll believe it when I see it. Until you provide some sort of proof (URL to non-H.264 and non-FLV YouTube video would be nice), I won't believe that.

Already did that the last time this subject came up on slashdot.

Did you think that you were going to impress us by linking to something that wasnt even under debate, as if it was under debate?

I mean COME ON.. you linked to something that essentially says "CODEC (A) NOT COMPATIBLE WITH CODEC (B)" .. are you fucking serious? This is SLASHDOT.. did you REALLY think that anyone here didn't know that?

For the record, I do not hate you. I just hate the tremendous stupidity that you have shown.

Re:Nice

[elmartinos]

It might be that H.264 is good enough. Look at JPEG, this standard was issued 1992, and it is still extremely popular, with no good successor available. The same thing might happen to H.264.

Re:Nice

[Hurricane78]

LOL. Only on Slashdot are you getting modded down for saying that “Reality does not equal Apple”, and that Apple is not even close to being a monopoly where you use the brand name instead of the real name.

Dear trollerators / Apple fanbois. I hope I meet you face-to-face, some time. Cause I’m go punch you a big “i” in the face!
Go ahead. Write me a mail, pussies! I’ll give you and address too meet. And bring your apple-branded toys!

Re:Nice

[jrincayc]

Is this the comment you ment?
http://tech.slashdot.org/comments.pl?sid=1519324&cid=30847608

Re:Nice

[Anonymous Coward]

I think that maybe a bigger look at the issue is needed. We geeks look at the specs and think only of the potential uses. We don't generally look at how it impacts the tech ecosystem on the whole (legally or financially). On the other hand, the C Team (CEO, CFO, COO, etc.,...) don't see the tech issues - they only care about cost and productivity. Is it any coincidence that these days, the marketing teams send stuff directly to the C Team, bypassing the technical vetting process? (think of it as bypassing the whole meet the parents thing) The C Team gets a nice powerpoint (misspelled, apparently, I supposed to capitalize the Ps - I refuse) file explaining how such and such will benefit them in the next year or so. In their wisdom, they make a decision based on how the next quarterly report (will I get laid now or not?) will look without considering what happens 6 years from now after such and such has become so critical (now there are three kids, a dog and a house... because back then, all I wanted was to get laid), it can't be scrapped... because there have been followup marketing initiatives designed to deepen the the dependency (blowjobs when your a good boy).

I got a word document via email the other day. The format was Word 97-2003 &6.0/95 -RTF (*.doc) - well over 6 years old.

Once something sticks, its hard to change because it requires huge amounts of people to make changes to huge amounts of content that are not calculated as profitable on the balance sheet for THIS YEAR so no matter what year it is, it never happens.

That's format wars in a nutshell - it doesn't matter about cost, it matters about market share. Once you have the market share, the cost the market will pay (ie, what the vendor can charge) is essentially limitless.

Its the art of creating an addict. The same rules apply regardless if it's drugs or software - give it away until dependency is established and then charge one penny below what will kill the customer.

In my case, I HAVE to have something that will open that document in the same way as the creator of the document - that means I need MS Office (macros, silly extensions, etc.,...). Sure, I suppose I could use OpenOffice, but then again, I don't know what MS specific crap is in the document when I get it. Even if OpenOffice might open the document, I still need MS Office because there might be some obsure feature used in it that OpenOffice doesn't support.

Did the document really need that single feature only MS provides? No. Was that single source feature used anyway? Yes, because MS told the C Team it was the most cost effective in the short term regardless of the pleas from those who know about considering the long term.

We all know this is why NO vendor likes open formats if they sell a product. We all know this is why ALL vendors like open formats if they sell services based on that format rather than the software itself.

Sorry - where I said 'sell', I meant 'license' - another case in point.

Lets have more "You are not allowed to make a dime unless I make a dollar - after all, your lot in life is to make sure I continue to become exponentially more wealthy than you. By the way, to even think about being upset violated my patent and with this new legislation, is a felony. Welcome to jail because you didn't just hand over your lunch money when I asked - how dare you!

I love computers. I loath anything related to the software/hardware industry (particularly licensing, related patent/copyright law and current/proposed legislation). I know I'm not alone in that sentiment.

The entire industry reminds me of the idea of of a bad marriage. A phrase I heard sums it up nicely. "Have you ever heard a lawyer tell you to divorce your wife because your standard of living would go up?" (please apologize - this is not meant to be sexist, its just a metaphor that is understandable regardless of opinion, thought with the other portions of my comment, it's sure to seem sexist) Sure, Microsoft is sexy and is al

Re:Nice

[crdlb]

If you right click on one of the videos that works in Opera, you will most likely find that it is running in flash even though you're in HTML5 mode. Youtube is still using flash for videos containing ads.

Re:Nice

[kyrre]

The first video you link to is Flash. The other one is HTML5. If the first video play and the other does not I think it is pretty clear that the reason should be pretty clear.

Re:Nice

[Jeremy Visser]

For the record, I do not hate you. I just hate the tremendous stupidity that you have shown.

Such as my ability to determine that in one of your aforementioned videos, they are actually still serving the Flash widget, despite being opted-in to the HTML5 beta. (I suspect that videos that they haven't transcoded to H.264 get served as Flash still, but that's just a guess.) Right-click on it and see.

Could have double-checked that before flinging the word "stupid" at me, but hey -- takes one to know one.

Open video

[Skatox]

I'm against this patent, HTML should support only open standarts

SS H.264 submarine patent

[denis-The-menace]

2010: DIVE! DIVE!
It's free, come and get it

2016: Up periscope. Look there's someone using it without paying the $799/Stream licensing fee.
-Arm MPEG LAwyer Torpedoes, FIRE!

looks like a ambush in slow-motion.

Re:SS H.264 submarine patent

[BlueBoxSW.com]

It's Compuserve GIF all over again.

Re:SS H.264 submarine patent

[Fahrvergnuugen]

Except that in this case X.264 is technically superior to the open alternatives, unlike PNG vs GIF.

Re:SS H.264 submarine patent

[Logibeara]

2016: Quick drop the FOSS depth charges

2018: The movie MPEG-571 is released

Re:SS H.264 submarine patent

[Anonymous Coward]

It was common knowledge among implementers that h.264 was free[*] for some time.
Wiki first mentioned licensing restrictions around 2004:
Like many other versions of MPEG, H.264/AVC implementors and users have to pay royalties for the use of it.

And anyone not expecting the Moving Picture Experts Group (MPEG) to cash in somehow is just fooling themselves.

Re:SS H.264 submarine patent

[Anonymous Coward]

Does anyone know when the patents expire?

With GIF they only started chasing it a couple of years before expiry, so it was a hassle, but we got over it in the end. How long are they giving themselves to rake in the money after their "free" period?

Re:SS H.264 submarine patent

[Killer Orca]

I thought x264 encoders were free? Of course this is only based on the casual observation that many of the videos at certain websites are encoded that way.

Re:SS H.264 submarine patent

[organgtool]

You hit the nail on the head. MPEG-LA is simply trying to fatten the cow of H264 marketshare so that they can slaughter it with charges in 2016.

And for those claiming that another codec will be dominant in six years, while that may be possible, MPEG-2 has been around since 1996 and is still one of the most popular video formats 14 years later.

Re:SS H.264 submarine patent

[Hurricane78]

Hey, don’t mod him troll! He’s right with what he meant.

Even though he got H.264 (the patented codec) and x264 (the open implementation) mixed up.

PNG was a problem back then. Since it could not do any animation. Which was important back then. Other than that it did not have any relevant size or transparency improvements is 8 bit mode, and just was too large in 24 bit (lossless) mode.

Also, H.264 factually is the best codec out there right now.

But frankly, I think it will be just like with GIF: NOBODY will care whether it’s patented. We will all say: “Sooo... Do you plan to sue the whole planet?? LOL.”
I also think, that MPEG LA knows this, even better than we do.
The engineers who designed it, will not get anything from the licenses anyway. They just feel pride when it’s used. Which they deserve.

Re:SS H.264 submarine patent

[Anonymous Coward]

So you're saying the ambush will be even more successful.

Re:SS H.264 submarine patent

[Anonymous Coward]

The issue is patents, not copyright. x264 is GPL'd, but it is illegal to distribute/use it with the MPEG LA's permission due to their patents on H.264. They currently do not charge for the patents, but say they will starting in 2016.

Re:SS H.264 submarine patent

[pbhj]

So your argument is that whilst MPEG LA are going to screw everyone over and demand money to license their codec we should continue and use it but just not pay them.

Nothing wrong with that argument provided you can get it embodied in the law that people/companies are immune to prosecution for non payment of license fees wrt the relevant patents.

Unisys did collect money on LZW use in GIF if they'd not been bothered about PR they could have collected far more extensively.

Re:SS H.264 submarine patent

[Anonymous Coward]

someone please tag this story "itsatrap"

Re:SS H.264 submarine patent

[Anonymous Coward]

GIF - 1987
PNG - 1996 (9 years later)

Soo, how is that different from H.264 in 2010? Yeah, they are at a time of GIF when PNG didn't exist.

http://en.wikipedia.org/wiki/Gif
http://en.wikipedia.org/wiki/Portable_Network_Graphics#Comparison_with_Graphics_Interchange_Format_.28GIF.29

Re:SS H.264 submarine patent

[PinkyGigglebrain]

Superior or not it doesn't change the fact that its not free.

MPEG LA can start charging as much as they think they can get away with in 2016, or sooner if they choose, as they can likely change their license when and as the choose.

Re:SS H.264 submarine patent

[Anonymous Coward]

ACTA is coming, and could well make thing very different from the GIF era

Re:SS H.264 submarine patent

[david_thornley]

If x264 is patent-encumbered, then it cannot be distributed under the GPL, version 2 (the first one with the "liberty or death" clause) or later.

A lot of fallout

[BadAnalogyGuy]

I've been personally touched by MPEG LA's patent witch hunt. And not in the good way like Kathleen Fent does.

My brother in law is the CEO of a small LCD monitor company that uses H.264 decoder chips. He buys these chips from a Taiwanese maker who in turn licenses the patent for H.264 decoding from MPEG LA.

But MPEG LA has been spamming everyone and anyone vaguely connected to H.264 encoding or playback or even (in this case) sending files across the intarweb. He is expected to succeed if MPEG LA ever takes this to court since the patent is already licensed by the chip vendor and his agreement with them covers him under its indemnity clause.

However this is a really plain-as-day example of how patent trolls are ruining business for everyone.

Re:A lot of fallout

[jo_ham]

The MPEG LA are hardly patent trolls. The term is so often applied to "anyone who has a patent and dares to enforce it" when it really doesn't mean that at all.

Re:A lot of fallout

[BadAnalogyGuy]

The manner in which they are pursuing sublicensees is very much in the pattern of a patent troll.

Re:A lot of fallout

[onefriedrice]

However this is a really plain-as-day example of how patent trolls are ruining business for everyone.

Please don't dilute the term "patent troll." It has a specific meaning and certainly doesn't apply to a patent pool packager like MPEG-LA. Everybody adopted h.264 with full knowledge that it was covered by several patents. This is certainly not a case of some junk firm patenting prior art and suing everybody. Nobody coerced anyone into using h.264; it just happened to actually be a good codec, so it was adopted by the industry. Nor is it "ruining business for everyone," so I'm not even sure what your point is. Your own anecdotal evidence doesn't lead to this conclusion.

Is it disappointing that we didn't have a comparable patent-free codec at the time when people started adopting h.264? Yeah, it's too bad. Unfortunately, no amount of sour grapes is going to change what happened.

Re:A lot of fallout

[countertrolling]

However this is a really plain-as-day example of how patent trolls are ruining business for everyone.

Really, what's your beef? This is precisely what the system was designed to do.. to keep the small fry independents from muscling in on the big boys' territory. I must say, it's working marvelously. Patent trolls are part of the show. Don't blame them for exploiting a corrupt system. You don't get rich without stepping on some peoples' toes. It's the nature of the beast.

Re:A lot of fallout

[raynet]

In my books anyone having software patents are patent trolls, fortunately software patents aren't valid here, yet..

Re:A lot of fallout

[Onymous Coward]

Patent pusher? "The next six years are free..."

Re:A lot of fallout

[jo_ham]

The H.264 patents are not software patents.

Re:A lot of fallout

[raynet]

Humm, checked the patents and it seems all of them have expired at where I live. Oh, and method patents are trollish in my book too.

Re:A lot of fallout

[Anonymous Coward]

Nor is it "ruining business for everyone,"

Beyond not ruining business for everyone, it's actually helping make business easier for everyone. People seem to think that the MPEG-LA is just a patent-holding organization that licenses its patents without creating any products. But it's really just a bulk licensing organization that's a front for many large companies that do make products. They've set themselves up as the single entity that both deals with licensing and litigation from other patent holders if they feel that H.264 infringes on a patent not included in the license.

By allowing bulk licensing of the patents in question, the MPEG-LA makes it simple for people who need to use the technology to do so legally. If it were not for them, you'd need to individually license all the patents in question and you'd still run the risk of being sued for infringing on patents that you didn't license. But with a license from the MPEG-LA, you're completely covered and can go about your business without fear of patent litigation.

As much as people here like to promote the Ogg family of codecs, the above cannot be said for choosing to use these codecs in your product. There's a reason why large companies that have the resources to make themselves attractive targets to patent-holders are choosing to license H.264 rather than use the free option. As soon as the potential payoff makes it worthwhile, that company will be sued and will be forced to defend itself. Whether it does so successfully or not is anyone's guess, but it will happen.

Going the MPEG-LA route means choosing fixed, predictable costs and using technology that is currently the best available. As a business, those are the characteristics you look for, even if the cost is a bit higher than it's likely to be going a different route.

Re:A lot of fallout

[jo_ham]

Ha! So, what you really mean is "any patent/company/organisation I do not agree with is trollish"

Re:A lot of fallout

[raynet]

Well, not really. I just don't agree with imaginary patents, those I think to be non-valid, thus trollish. For me, a patent has to be a thing and it should be possible to engineer around someones patent. By that I mean, one shouldn't be allowed to patent a general idea of a lift, but instead allowed to patent a specific way to create a lift.

Re:A lot of fallout

[jo_ham]

And a method patent is exactly what you have just described.

So, where's your problem? You said that method patents are trollish.

I don't agree with obvious software patents either, like one click shopping or "doing (some thing) but in the internet", but method patents are a different entity entirely.

Re:A lot of fallout

[raynet]

A method patent still is not a thing, which is why I really don't like it. I don't think anyone should be allowed to patent a process/method of doing something, but instead they should only be allowed to patent the device that does the process. And the broader the method is, the worse it gets. And just add internet to it, and you get really silly patents.

An (bad?) example of my view would be something like this:

You should not be allowed to patent method of transforming liquid fuel into locomotion. Or even transforming liquid fuel into combustable mist.

Instead you should be allowed to patent specific design of a carburetor. This would allow other people to learn from your invention and strive to invent a better carburetor, or maybe even invent fuel injection etc.

Re:A lot of fallout

[Rogerborg]

Nope, apparently not. You guys are just so cute.

And even if sucked

[DrYak]

You know, Theora video doesn't suck.

And even if it sucked, that wouldn't matter anyway :
most of video today consist of short snips on social websites of dancing cats filmed with a camera phone with crappy sensors and low quality MJPEG compression.

Arguing that Theora would need more bits to achieve the same quality as other codec is akin to arguing that Youtube should spend more bits to be better faithful to all the compression artifacts.
Theora opponents say that, for the same bits bandwidth, Theora video is blurrier. I'm saying that this blur won't hide any critical detail. It will only blur out the noise from the camera phone's crappy sensor and from the MJPEG'S 50% compression. I personally *can* live without them, if it is what it takes to have a open free/libre standard.

Re:And even if sucked

[nine-times]

most of video today consist of short snips on social websites of dancing cats filmed with a camera phone with crappy sensors and low quality MJPEG compression.

...and TV shows and movies.

Besides, have you seen the output from decent consumer-grade camcorders recently?

Re:And even if sucked

[delt0r]

At the lower bit rate end of the spectrum Theora is not bad, and would be competitive if it had the same development effort that the "Open Source" H.264 codec encoders get. Personally I think both theora and h.264 look like complete crap at you tube bandwidths.

However Theora is working. Its mere existence is forcing MPEG LA to address license concerns. If Theora wasn't around, we would even be having a serious "open codec" debate, we be asking how much is licensing html 5.0 going to cost.

Re:And even if sucked

[jank1887]

obligatory: Abstraction
http://www.xkcd.com/676/

Re:And even if sucked

[Anonymous Coward]

Besides, have you seen the output from decent consumer-grade camcorders recently?

Not very often, no. Mostly because the vast majority of the videos made publicly available on the internet (that is, the ones we'd actually see) are short snips on social websites of dancing cats filmed with a crappy camera phone with crappy sensors and low quality MJPEG compression, like the GP said, and most people don't film dancing cats with the same attention to detail and memorable preservation that they do for things they would use their digital camcorders for.

Why do sprite comics still exist? I mean, have you seen what's possible from even cheap, low-end drawing tablets?

Re:And even if sucked

[TheRaven64]

most of video today consist of short snips on social websites of dancing cats filmed with a camera phone with crappy sensors and low quality MJPEG compression.

By volume, sure. By amount of time people spend watching? I'm not so sure. The two places I mainly stream videos from are iPlayer and the company I rent DVDs from. Both of these have DVD-quality or better sources. YouTube comes a distant third after these two. These aren't short clips, they're episodes of TV shows or films, so 30 minutes is about the minimum length and 45 minutes to two hours is fairly common.

Re:And even if sucked

[Kohlrabi82]

At the lower bit rate end of the spectrum Theora is not bad

This is completely wrong, Theora is *escpecially* bad at low bitrates, I recently made a small comparison of Theora/Thusnelda and H264/x264 encoded 1080p videos, both looked very watchable at 4Mbit, but at 2Mbit problems for Theora/Thusnelda started, and at 1Mbit it was just plain awful. 2Mbit Theora/Thusnelda couldn't nearly reach H264/x264 quality at 1Mbit.

Re:And even if sucked

[PitaBred]

I've got a 61" TV, and playing stuff back from my Canon HF-100, you can't see any pixellation. You can barely even make out individual pixels when it's paused.

Re:And even if sucked

[Anonymous Coward]

It seems that we have different definition of low bitrate. I did previously some comparison for very low bitrate encoding for low resolution and low framerate video. Theora was equal and sometimes better than x264 when recording live 400x300/10fps video at about 40 Kbit.

Re:And even if sucked

[delt0r]

2Mbit 1080p? whats the point? Its like a 700MB "blu ray" rip.

Re:And even if sucked

[Kohlrabi82]

It was just for testing purposes, it's much easier to see artifacts at that low bitrates.

Re:And even if sucked

[appleprophet]

You need to back up your assumptions. I would actually assume the opposite. YouTube has long since supported 720P and now even supports 1080P (if your computer can handle it). I would assume that a large percent of video consumed on the internet is actually HD quality television shows and other media, e.g. Hulu. Furthermore, it is almost impossible to buy a modern device that does not record in HD -- even cellphones.

If this is not already the case, trends overwhelmingly point to the fact that consumers want high quality video. It's fine to argue that we don't need this quality in favor of open standards, but don't pretend like people don't want HD.

Re:And even if sucked

[node 3]

This is absurd. You're arguing in favor of the inferior codec on the grounds that, "for 90% of the video, it won't matter." What about the 10% for which it does?

Or, put differently, if YouTube and Hulu gave users a choice between h.264 and Theora, everyone (except the freetards (I normally don't use that term, but in this case it really does apply)) would choose h.264.

Re:And even if sucked

[drinkypoo]

Or, put differently, if YouTube and Hulu gave users a choice between h.264 and Theora, everyone (except the eople who care about freedom) would choose h.264.

There, fixed that for you. (I normally don't use that phrase, but in this case you really did drink the kool-aid.)

Re:And even if sucked

[wintercolby]

Artifacts at low bitrates, you must be kidding!

Re:And even if sucked

[Sapphon]

Is the TV on?

Re:And even if sucked

[randallman]

I just downloaded the latest version of ffmpeg2theora because I wanted to see how it fared with the new lib (Thusnelda) and let me say I'm impressed. I've been encoding my home DV movies using the default settings. These movies are 720 x 480 and my bitrates tend to be about 1400kbps with quality that is virtually indistinguishable from the source material. I encoded a few at 800 kbps. At that lower bitrate artifacts become noticeable, but quality is still quite good. My source material is a bit grainy in low light so I think encoding will perform even better in bright scenes.

If you haven't checked out theora in a while, have another look. It seems there's been some real progress made lately.

Re:And even if sucked

[node 3]

Or, put differently, if YouTube and Hulu gave users a choice between h.264 and Theora, everyone (except the eople who care about freedom) would choose h.264.

There, fixed that for you. (I normally don't use that phrase, but in this case you really did drink the kool-aid.)

I care about freedom. I like the idea of Theora, but the reality of it is far less compelling.

I used 'freetard' deliberately because it's a case where someone uses a free technology, which is both inferior to the non-free technology (in every way, with the sole exception of being non-free), and is not, in practice, any more free for the end-user.

I can respect sticking to one's values, and I can *totally* respect advocating freedom, but something like this is *total* freetard territory.

Re:And even if sucked

[drinkypoo]

and is not, in practice, any more free for the end-user.

That is provably false. I would go ahead and prove it, but it's been done to death. But the short form: If you encode video with h264 today, in 2016 you may be getting a bill. For my own safety, I can not use h264 video on my website. And if I don't, then iPhone users won't be able to view videos on my website. Etc, etc.

Re:And even if sucked

[BikeHelmet]

I agree with your post.

But H.264 really does rock when you have a high quality source.

And for low-bitrate video (512kbit or lower), it really is the king of preserving detail.

Re:And even if sucked

[BikeHelmet]

I consider low bitrate to be about 256kbit - 1024kbit, depending on the resolution of the video.

I've noticed that for specific situations - like conferences where a speaker is talking for an hour with very little movement - H.264 does okay with ~64kbit. Aside from that, I wouldn't go lower than 256kbit.

My experience with 856x360 29.97 video (technically 480p, but the video had black bars encoded, which I removed) was H.264 doing fine with just 512kbit. "Fine" means few noticeable artifacts, but an obvious lack of detail when comparing to DVD side by side.

Re:And even if sucked

[Thinboy00]

and is not, in practice, any more free for the end-user.

That is provably false. I would go ahead and prove it, but it's been done to death. But the short form: If you encode video with h264 today, in 2016 you may be getting a bill. For my own safety, I can not use h264 video on my website. And if I don't, then iPhone users won't be able to view videos on my website. Etc, etc.

By 2016 In re Bilski will have eliminated software patents entirely.

Re:And even if sucked

[cheftw]

Have you tried putting on your glasses?

Re:And even if sucked

[Draek]

One assumes, however, that for such things you'd be better off downloading the damn thing instead of watching it inside your browser, as per the HTML5 video tag is meant to be used.

But by amount of time spent watching, I'd say "no quality at all" ought to be a strong contender. Most of the people I know who use Youtube regularly do so to listen to music videos on demand, and couldn't care less about how the thing looked, which is why so many of said music videos on Youtube are nothing more than a static image with the music playing on the background. And last time I checked Ogg Vorbis was fairly comparable with AAC on low-bitrate audio quality, if not outright superior.

Re:And even if sucked

[drinkypoo]

By 2016 In re Bilski will have eliminated software patents entirely.

Do you believe in Santa Claus, Jesus, and the Easter Bunny too?

Re:And even if sucked

[node 3]

and is not, in practice, any more free for the end-user.

That is provably false. I would go ahead and prove it, but it's been done to death. But the short form: If you encode video with h264 today, in 2016 you may be getting a bill.

All you've done is proven that it's true for now, and that, maybe, in 2016, it won't be true.

For my own safety, I can not use h264 video on my website. And if I don't, then iPhone users won't be able to view videos on my website. Etc, etc.

Yes, you can use it. No, you won't get a bill. Not until, *maybe*, 2016.

And what happens in 2016? *If* the bill ever comes, you can just pull the h.264 videos offline (or even, gasp!, pay the bill). I'm not saying to not also encode and offer the videos in Theora as well. I'm just suggesting that pre-emptively limiting your potential audience, and limiting the quality of your web site on the grounds of something that *might* happen in six years is a bit extreme.

Re:And even if sucked

[Philip_the_physicist]

This is the intended purpose of Dirac. Unfortunately I don't think the Schrödinger implementation is fast enough for anything above 720p yet, but it is getting better, and IIRC that the BBC want to make it their primary codec for both internal use and iPlayer, which would drive fairly widespread adoption, given how many companies use iPlayer.

Schrödinger already supports ffmpeg and gstreamer, and is included with VLC. There is a directshow filter for it as well.

Re:And even if sucked

[drinkypoo]

And what happens in 2016? *If* the bill ever comes, you can just pull the h.264 videos offline (or even, gasp!, pay the bill).

So my choices are to pay the license fee, or remove content from my site? Neither of those sound appealing when there are Free/free alternatives which will work just as well for my purposes — if I can get my users to install support for them, anyway. And which will never work on the iPhone...

I'm not saying to not also encode and offer the videos in Theora as well.

So the solution is to consume additional disk space and deprecate caching as well as spend more encoding time to avoid the tyranny of a patent-licensed standard?

I'm just suggesting that pre-emptively limiting your potential audience, and limiting the quality of your web site on the grounds of something that *might* happen in six years is a bit extreme.

I can take a stand. I probably don't need iPhone users to view my videos.

Re:And even if sucked

[Hadlock]

It might be a little hard to make out individual "pixels" of video when your display's pixel pitch already is more than 0.7mm. To use an old term in reverse, it's hard to see a tree from the forest satellite photo. It would probably be easier to see on a display in the 22-35" range, where the pixel pitch is about half that (or less).

Re:And even if sucked

[Firehed]

Well, six years from now when you have to start worrying about it, we'll probably have come up with some superior format. If it's that much of a concern to you, write a better codec and make sure it stays as FOSS. (That's meant to come across much less douchey than it probably will)

Of course, MPEG-LA will do the same thing in 2016 that they've done now, provided the codec is still even in use by then. It doesn't make any business sense to try and extract money from ten million websites that are using video with their codec when they can just license out the encoder to a select few companies for a huge amount of money. Legally they could try, but it would just be stupid.

Re:And even if sucked

[Firehed]

Neither of those sound appealing when there are Free/free alternatives which will work just as well for my purposes — if I can get my users to install support for them, anyway. And which will never work on the iPhone...

Maybe I'm not understanding your website's goals, but it sounds like those alternatives in fact do not work just as well for your purposes.

Don't get me wrong - I'm all about Free, free, and open standards. But as someone in control of websites, I'm going to use what gives the best experience for my visitors. For better or worse, that's h264 - a closed, but de facto standard. It's not ideal, but I'm not willing to sacrifice a large portion of desktop visitors and nearly 100% of mobile visitors. If you are, more power to you.

Re:And even if sucked

[X0563511]

... and what if one wasn't using shitty equipment? What about digital content? When I press "Render" there certainly isn't a lowest-bidder CCD sensor involved.

Re:And even if sucked

[emanem]

Here is the discussion and some tests.
Actually is true, on HD content between 4mbps and 2mbps H.264 is way better than Theora.
But at YouTube quality (eg SD if you're lucky) the difference is not that much.
Cheers,

Re:And even if sucked

[logixoul]

No, it's not obligatory.
Look, I love xkcd as much as everybody else, but stop pasting it everywhere, that cheapens it.

Re:And even if sucked

[Anonymous Coward]

Because 99% of people can't draw their way out of a paper bag, and sprites are nostalgically stylish.

documenting H.264 on http://en.swpat.org

[H4x0r Jim Duggan]

    The MPEG patent thicket is a prime example of the real problem of software patents. If I want to write a video player, it has to play the formats that people encode videos in. The veto power of patents equates to the right to prohibit me, and everyone, from writing a functional video player. I think I already have pretty good info, but there's loads more of this story to tell. Help really appreciated in documenting this:

• MPEG video formats (including H.264)
• Harm to standards
• HTML5 and video patents

    swpat.org is a publicly editable wiki.

Re:documenting H.264 on http://en.swpat.org

[Dachannien]

The veto power of patents equates to the right to prohibit me, and everyone, from writing a functional video player.

Yep, that's pretty much what patents are for.

Re:documenting H.264 on http://en.swpat.org

[Waffle Iron]

Yep, that's pretty much what patents are for.

Not really. Back in the day, if somebody patented a cotton gin, that didn't stop me from making another machine that cleans cotton which works on a different principle. The existence of the original machine in the market was irrelevant to new competitive entries.

Today, a good deal of software is subject to the "network effect". That makes it just about impossible to operate in many software markets without being compatible with the most popular protocols, formats or standards. If those things happen to be patented, you have no alternative but to pay the licenses or give up, regardless of what new innovations you may bring to the game. Products that don't interoperate with the existing installed base are simply not viable in the market.

Today's patents can be much mor powerful than originally envisioned. They can wall off an entire marketplace, not just a single clever idea.

Re:documenting H.264 on http://en.swpat.org

[BZ]

Thing is... the H.264 patents are method patents, not software patents.

And the methods used seem eminently patentable to me: novel, non-obvious, etc, etc.

The only issue is that the setup doesn't play well with cases where the marginal unit cost of an encoder or decoder is very close to 0. This is not a software-specific problem, per se; if we had star-trek-like synthesizers available for physical items it would be a problem there too.

Re:documenting H.264 on http://en.swpat.org

[Grond]

Right, that's why there are no functional video players that support H.264. Except for Windows Media Player, which comes free with Windows. And Quicktime/iTunes, which comes free with OS X and are free for Windows. And VLC, which is free and usually comes free with Linux distributions. And MPlayer. And PowerDVD. And Totem. In fact there are at least 20 such players, some free, some proprietary. Every modern OS comes with a free, functional video player and there are several options if you don't like the one that comes in the box.

Software patents on video codecs didn't start with H.264. MPEG-1 was patented, so was MPEG-2. Royalties were sought in both cases. That didn't stop free and open source encoders and decoders from being produced, and nobody got sued or shut down.

The existence of a patent does not mean that the patent will be enforced in all cases. Patent owners, like other property owners, ignore low-value infringements all the time. It's generally not economically rational to sue free and open source software projects for patent infringement. There are several reasons:

1. Patents are territorial but FOSS development is international. If you get an injunction in one country, development and hosting will continue in others. Even if you had a patent in every single country in the world, enforcement would be incredibly expensive and not at all worth it.

2. You generally can't get money damages and an injunction--assuming you can get one--would be useless. The baseline for patent damages in the US is a reasonable royalty. But a FOSS project would never pay a royalty. So the reasonable royalty is $0. Lost profits are arguable, but even if you can get a judgment, good luck collecting it from free software developers. An injunction may be obtainable, but the code is out there; you can't delete something from the internet, and development will be continued by others either in this country or another one.

3. The cost is prohibitive. Assuming the defendants put up even the slightest fight it would cost the patentee tens of thousands of dollars to sue. And if the EFF/SFLC/RedHat/etc get involved it would probably cost the patentee's millions and risk invalidating the patents. Even if the patentee wins it's doubtful it could collect enough in damages or increased licensing revenue to offset the cost of litigation.

4. The PR is terrible. Suing volunteer developers is a great way to get a terrible reputation among the very people who decide what formats to use on websites. Start suing open source developers and expect to see IT workers all over the world recommend moving to unencumbered or at least litigation-free formats.

All of these reasons and more are why, despite tens of thousands of software patents having issued over the past couple of decades, the Open Source Software Patent Apocalypse has failed to materialize. It's just not a significant risk. The SWPat wiki has only incredibly weak sauce examples, most of which are merely potential dangers, not actual lawsuits or even threats of suits.

Re:documenting H.264 on http://en.swpat.org

[Anonymous Coward]

Except we aren't talking about the complicated mechanism of a film projector and potential patents on that physical implementation, we're talking about patents on a bunch of MATHEMATICS.

It's like patenting Newton's method for solving equations.

Re:documenting H.264 on http://en.swpat.org

[denis-The-menace]

Re:Software patents on video codecs didn't start with H.264. MPEG-1 was patented, so was MPEG-2. Royalties were sought in both cases. That didn't stop free and open source encoders and decoders from being produced, and nobody got sued or shut down.

Back then DMCA was not in existence and ATCA was something the RIAA and MPAA would dream about and forget the next morning. Once ACTA comes to life, They will find a way to kill VLC and anyone who dares to slowdown their cash flow.

Re:documenting H.264 on http://en.swpat.org

[tlhIngan]

The MPEG patent thicket is a prime example of the real problem of software patents. If I want to write a video player, it has to play the formats that people encode videos in. The veto power of patents equates to the right to prohibit me, and everyone, from writing a functional video player. I think I already have pretty good info, but there's loads more of this story to tell. Help really appreciated in documenting this:

That's why there are patent consortiums. MPEG-LA is one, 3C Entity (and 5C Entity) are another, etc. If you want to write a h.264 decoder, you license the h.264 patents, and you're free and clear because your royalty payment pays for ALL the patents in h.264 - it's all RAND licensing. Most working groups for various technologies form consortiums because navigating the patent minefield is such a pain. Instead, you get to license all the patents you need for one small fee. Need to do a Blu-Ray player? Blu-Ray Association will point you to the consortium that licenses (and sub-licenses - stuff like h.264) all the patents needed.

Ditto stuff like RAM, media (DVD/Blu-Ray/etc), communications technologies (WiFi/802.11 is covered by tons of patents), etc. Many consortiums license to other consortiums so you can do a one-stop shop for licensing (otherwise instead of dealing with 1,000,000 ocmpanies and patents, you deal with 1,000 consortiums, which isn't much better, so a one-stop shop means you deal with a 1 or 2).

Re:documenting H.264 on http://en.swpat.org

[nine-times]

Personally I think that we should consider whether the government should be able to exercise eminent domain for patents in cases like this. The purpose of patents was to encourage people to invest in devising new technology, and so I don't think it's horrible to think the people behind the technology in H264 deserve to have their investment pay off to some degree. On the other hand, H264 being the defacto standard while being patent encumbered is an unacceptable situation.

Re:documenting H.264 on http://en.swpat.org

[Grond]

Back then DMCA was not in existence and ATCA was something the RIAA and MPAA would dream about and forget the next morning. Once ACTA comes to life, They will find a way to kill VLC and anyone who dares to slowdown their cash flow.

The DMCA has nothing to do with patents. It's the Digital Millennium Copyright Act. Furthermore, decoding H.264 has nothing to do with circumventing DRM, so the DMCA wouldn't apply anyway.

As for ACTA, well, because of the secret nature of the negotations we don't know what exactly will come of it, but from what we do know it doesn't seem to have much to do with patents either. For example, a lot of ACTA has to do with international cooperation on the prosecution of criminal intellectual property rights infringement. But patent infringement is not a crime anywhere in the world that I know of (certainly not the US or Europe).

The parts of the draft dealing with civil liability do not significantly alter the existing law of patents. Furthermore, comments on the leaked draft from Australia, Singapore, and Canada suggest that different areas of IP should be treated differently, with Singapore and Canada explicitly calling for limiting the scope of ACTA to copyrights and trademarks. And since most of the text explicitly refers to 'pirated or counterfeit' goods, it's unlikely that patents will be substantially affected by the final version of the treaty.

Re:documenting H.264 on http://en.swpat.org

[Grond]

Personally I think that we should consider whether the government should be able to exercise eminent domain for patents in cases like this.

Exercising eminent domain in a patent case is usually a bad idea. The compensation the government has to pay for the taking is the value of the patents over their entire term, which in this case is likely to be billions of dollars (for example: Thomson, which is just one member of the MPEG LA patent pool, receives a few hundred million dollars a year in licensing revenue).

The end result is that the cost is spread over the entire tax base instead of being concentrated among the actual users of the technology. So someone who owns a single TV and doesn't watch much web video will end up paying far more than their share while someone who watches tons of web video and runs a video streaming service pays far too little. Ultimately it acts as a transfer of wealth from those who do not produce or consume H.264 video to those who do, which is kind of an odd basis on which to redistribute wealth.

Re:documenting H.264 on http://en.swpat.org

[Waffle Iron]

The compensation the government has to pay for the taking is the value of the patents over their entire term, which in this case is likely to be billions of dollars (for example: Thomson, which is just one member of the MPEG LA patent pool, receives a few hundred million dollars a year in licensing revenue).

I've got a better idea. Since the government made up this "patent value" out of thin air in the first place, how about let the government decide how much it's worth.

Since without a doubt it did *not* cost billions of dollars to come up with a couple of tweaked codec algorithms, the government shouldn't have to pay billions of dollars to buy them out. Just give the patent holders a reasonable return on their actual investments and call it a day.

That way we won't be stuck with another 20 years of redistributing wealth from the general public to a monopolistic corporate cartel.

Re:documenting H.264 on http://en.swpat.org

[Grond]

I've got a better idea. Since the government made up this "patent value" out of thin air in the first place, how about let the government decide how much it's worth.

That would probably require a constitutional amendment. The Fifth Amendment states "nor shall private property be taken for public use, without just compensation." Theoretically the Supreme Court could reinterpret 'just compensation' to mean 'whatever the government feels like,' but that would be an enormous break with precedent and would open the door to the government taking other kinds of property without paying for it or only paying a pittance.

Re:documenting H.264 on http://en.swpat.org

[Waffle Iron]

You seem to be self contradictory: On the one hand espousing libertarian babbling about how the Constitution limits the government; but on the other accepting intrusive government programs that redistribute rights from the people at large to certain favored supplicants at the whim of unaccountable bureaucrats, then calling these entitlements "property".

Re:documenting H.264 on http://en.swpat.org

[Dachannien]

Then it sounds like the issue you're complaining about (aside from, perhaps, a general "patents are bad" argument, which is certainly a respectable opinion in its own right) is that standards are often developed in a way that allows the participating companies to receive patents on the related technology. This is a problem with the way that the standards are developed rather than an inherent problem with the patent system.

Re:documenting H.264 on http://en.swpat.org

[Waffle Iron]

This is a problem with the way that the standards are developed rather than an inherent problem with the patent system.

Not necessarily. Take Microsoft's VFAT patents, for example. Microsoft is currently shaking down camera manufacturers and other OEMs for royalties on this filesystem. This is depsite the fact that in the 21st century, that filesystem has zero technical merit, and the patents only cover techniques that were kludges to interface with a 16-bit OS from the 1980s that nobody has used in over a decade.

However, VFAT became a defacto standard (through no merit of its own). Everyone must be compatible with it to compete in the removable storage device market, and Microsoft reaps windfall profits. However, there was no "standards process" to abuse. The problem is that patents are allowed to exist even after the improvements they protect are no longer useful. That's one problem with patents themselves.

its...

[nimbius]

a trap.

Tried & True business model...

[PPalmgren]

The first hit is free.

New protocols for 2028?

[H4x0r Jim Duggan]

Problem is, do you think that protocols using only ideas from before 2008 will be optimal for whatever hardware and software systems we'll be using in 2028?

While you're thinking about that, please support campaigns to abolish software patents.

Re:New protocols for 2028?

[Pojut]

No need to try and recruit me...I despise software patents already ;-)

not it isn't. a trap is hidden

[SmallFurryCreature]

This is a rake, lying on the ground in plain sight with red markers all over it and a big sign.

Step on it at your own risk, but don't come crying when the rake hits you in the face.

After the gif debacle, you would think people would learn.

Re:not it isn't. a trap is hidden

[DinDaddy]

This is the rake you describe lying completely across a narrow path, where to by pass it, you must scramble up some very steep rocky embankments to proceed around it.

Re:not it isn't. a trap is hidden

[gmuslera]

Define "people". Big media providers would win big if the "standard" in internet in is forced to a format that take out any potential low-budget competitor. They WANT that it gets massively adopted,so will dump every kind of content that way. Then you have normal people that just use a browser without knowing about the technology behind. And developers of open and closed browsers, plugins and devices that could show those videos, and of open and close apps/devices that could produce somewhat that kind of videos. And the people that want to show their work in internet.

It is something dangerous. A lot of people won't recognize it as danger till they get caught, and for them is a trap, Some will try to take profit of it (either forcing us in, or putting a trap in the alternate path), others will try to avoid it and try to help people to see it.

Chumming the waters

[Anonymous Coward]

Maybe I'm a pessimist this morning, but my first reaction to TFS was that it seems like a insidious (but brilliantly profitable) plan to encourage the adoption of their codec as a cornerstone of the next generation of Internet media. When the patent expires, they'll have a feast of (presumably) successful websites and brand names they can draw royalties and other fees from, who are willing to lay exorbitant amounts to keep their infrastructure up rather than forcing redesign and coding.

Easy way to oblierate anyone they suddenly "disagree" with, too.

Noname brand player

[DrYak]

Yes, yes, I know there's $obscure_bad_interface_linux_based_device that supports Theora and Ogg.

Go to the nearest electric/computer parts shop.
Go to the shelf where all the multimedia player/harddisk enclosure are. You know : black box, you buy one, optionally slap a harddrive into it, optionally plug an ethernet cable and put it under the TV set (Kiss, Tvix, etc.).

Chance are :
- almost all of them will run some (hidden and un-advertised) Linux kernel under the hood.
- almost all of them will support Ogg Vorbis and FLAC (not always advertised)
- a huge proportion can do software Theora decoding (Theora is an older and much simplier codec. It requires less resources than H264 and can be done in software or DSP/SIMD assisted software). It's not always advertised, it might only come in a firmware upgrade. But lot's have it.
- not all of them will have painfully ugly interfaces

So the situation is a bit more easy than "there's one single model which plays it". Lots of asian noname devices manufacturer are implementing it, because it comes for free and because they can thus add an additional bullet point to the feature list.

Want hardware support ?
- There exist open theora core.

Don't want to make a custom chip ?
- There also exist a GPGPU implementation.
Given that ARM and both PowerVR (maker of the GPU core on the hyper-popular OMAP chipsets) and nVidia (maker of the GPU core on the upcoming Tegra) are members of the OpenCL committee, you can expect that hardware accelerated OpenCL-written video codecs will be the solution for lots of future devices.

The situations is similar as with Ogg Vorbis a few years before :
- it's doable.
- big brand doesn't do it, yet. because their lasy.
- noname brand are starting to pick it up. after a couple of years it will have a huge market share among the brandless device, to the point that anything except Apple's device can play it.

Re:Noname brand player

[nxtw]

Go to the nearest electric/computer parts shop.
Go to the shelf where all the multimedia player/harddisk enclosure are. You know : black box, you buy one, optionally slap a harddrive into it, optionally plug an ethernet cable and put it under the TV set (Kiss, Tvix, etc.).

The market for these devices is quite small compared to that for Blu-ray players, HD satellite receivers, Android/BlackBerry/Apple mobile phones, full-size PCs, etc.

Re:Noname brand player

[LBt1st]

Does any of that help me run video on my cellphone (or whatever device) today? H264 is already supported in hardware. Why should I or anyone else go through a bunch of fuss to get Theora to work (likely only in software)?

Sure maybe in the future Theora will be common.. That does nothing for us now. By the time it does happen it'll be too late.

Re:Noname brand player

[Spliffster]

Mod parent up.

It's really about the embedded devices (like smartphones) nowadays which need hardware de/-encoding support for better battery life. h.264 is well supported, theora/vorbis is not. These are the gadgets which non-geeks buy (the masses).

On the other hand, the existence of theora/vorbis and it's good quality is a threat to commercial codecs which positively influences the licensing terms of these for the consumer/developer.

Re:Noname brand player

[node 3]

Yes, maybe some of them support Theora. But *ALL* of them support h.264. And this completely ignores devices that use batteries. Hardware h.264 wins hands down in this regard.

Re:Noname brand player

[Bert64]

A lot of HD satellite receivers are actually Linux based, look at the Dreambox series for example...
And there is nothing stopping anyone from adding Theora support to an android device...

Re:Noname brand player

[nxtw]

A lot of HD satellite receivers are actually Linux based, look at the Dreambox series for example..

A lot of HD satellite receiver models may use Linux, but is this meaningful to the end user? Can the software be replaced on popular models?

It might be possible with receivers outside of North America, but not in the US or Canada.

And there is nothing stopping anyone from adding Theora support to an android device...

Designers will be hard-pressed to find an existing SoC/GPU with Theora hardware decoding or encoding. Not so for H.264.

By 2016

[calibre-not-output]

we'll be using a different format. Yes, it will be encumbered by patents, DRM and a bunch of other shit we don't even know yet - but it will not be H.264. I don't really see how this extension of free licensing could be profitable to them.

Re:By 2016

[aristotle-dude]

we'll be using a different format. Yes, it will be encumbered by patents, DRM and a bunch of other shit we don't even know yet - but it will not be H.264. I don't really see how this extension of free licensing could be profitable to them.

You are missing the forest for the trees. The MPLA makes money on licensing fees for encoders and decoders. By offering royalty free streaming for a time, the format becomes popular which means that more encoders and decoders are sold which generates more income.

It is possible that they may continue to offer free licensing of for distribution through further extensions. Doing it this way rather than just offering blanket permission to stream give them a few advantages:

1. It allows them to track how many sites are using their technology.

2. They can still go after webmasters who have not registered for the free license to stream.

3. They can revoke a license from someone deliberately distributing pirated video.

They're like drug pushers

[Anonymous Coward]

"the first hit is free..."

Good enough

[otuz]

This should be good enough to buy some time for alternative codecs. In my opinion the tag should be treated just like the tag, essentially allowing more or less any video file to be specified as the source. How often do you see xpm images as the src of img tags nowadays? It was one of the original image formats.
A few years will buy some time for the open source communities to develop some really good codecs.
Ogg Theora doesn't really have any benefit over mpeg4/h264 except its license. Its competition is mainly avi/xvid and such previous generation codecs and containers.
Let's not hang up on this issue, initial h264 support for video is better than flash and the associated licensing issues of the flash authoring tools and the drawbacks of such a closed proprietary format.

Won't matter much anyway

[kill-1]

Google will open source VP8 from On2 in a few months, and H.264 will soon be history.

HTML5 is a dangerous "standard".

[Anonymous Coward]

Yeah, but it's not encumbered by patents and other legal bullshit.

Keep in mind that the HTML5 effort is much unlike the past HTML and XHTML standardization efforts. While the past efforts were driven by the W3C, HTML5 is a product of Google, Apple, Opera, Mozilla and other corporations, masquerading as a "community effort" just because their browsers are open source.

With HTML5 being implemented to suit the needs of media distribution companies like Apple and Google (ie. YouTube) who have shown a propensity towards using DRM and undocumented formats, it's not surprising at all that a better and much more open video standard would be passed over in favor of proprietary, encumbered "alternatives".

HTML5 will be one of the worst things to hit the Web in years. Sure, it'll let some folks create dinky demos using the canvas element, but it'll also be the platform through which the Googles and Apples of the Internet force DRM and proprietary media technology on basically everyone, thanks to it HTML5 being a "standard".

Re:HTML5 is a dangerous "standard".

[tepples]

HTML5 will be one of the worst things to hit the Web in years. Sure, it'll let some folks create dinky demos using the canvas element, but it'll also be the platform through which the Googles and Apples of the Internet force DRM and proprietary media technology on basically everyone, thanks to it HTML5 being a "standard".

What makes <video> of HTML 5 any worse than <object> of HTML 4 in this respect?

Re:HTML5 is a dangerous "standard".

[Anonymous Coward]

Google undocumented formats and DRM? I can't think of much DRM of Google's except for the long extinct Google Video DRM. A few of the services like Youtube/Google Books deliberately chose not to make it easy to save copies, but they are hardly DRM, since there are still multiple ways to get the video, they are just undocumented, and unsupported.

I'm having real trouble thinking of any file formats that Google uses that are exposed to end users that would qualify as proprietary.

Re:HTML5 is a dangerous "standard".

[spinkham]

Google supports Theora in Chrome. It's only apple who doesn't, probably because iPhone/iPods do H.264 in hardware and not Theora.

Also, HTML5 does not standardize on either Theora, H.264, or any other format. And I fail to see how that standards bring DRM into the picture at all...
Both google and Apple have been heavily anti-drm in the past.

I'm cynical about large companies, but you make me look downright cheerful ;-)

Re:HTML5 is a dangerous "standard".

[Kjella]

The web has never had a free video format, ever. This is an effort by the web browsers to take the market back from Adobe with the same codec used in most flash videos, minus flash. At least H.264 has many good open source implementations in ffmpeg and x264 whereas flash has none, gnash is an utter failure in my experience. So it's much better than it was but because it's not good enough we'd rather crash this project and go back to using flash.

It's really this simple, if it works with YouTube and without flash, I'm switching to it. In my case on Linux there's chromium-browser + chromium-codecs-ffmpeg-nonfree = YouTube without flash, all open source. Firefox? Opera? Freewheeling off the road, thinking their market share can't leave as suddenly as it came for something better. If Google chooses to tank Firefox by not renewing the deal and promoting Chrome as the best way to watch YouTube, the battle would be over before it started.

Re:HTML5 is a dangerous "standard".

[Xest]

I'm glad to see someone posted this, a lot of people seem to be jumping on the HTML5 bandwagon without having actually bothered to look much into it. They've heard it's some special spec that somehow fix everything that's wrong in the world.

It wont, it's quite a horrible spec in so many ways and as you say, has been developed with a select few interests in mind, whilst outright ignoring others.

In terms of video, I made the point that if we're going to implement a whole new tag specific to video, then we should take the opportunity to improve accessibility, something that's been sorely missing from web video. I suggested that a parameter allowing the element to specify a subtitle file or similar would be an awesome step forward for web accessibility- not just for people who are deaf, but even for people using systems with no sound, or who want to watch a video in silence but still understand what's going on.

Accessibility has been a key foundation in teaching better web development for years, it's been good practice to try and make sure your site adheres to WCAG and so forth for example, and yet the HTML5 team seem to be throwing the whole idea of accessibility out the window.

But it gets worse, with a push back towards HTMLs more sloppy SGML based syntax, and a push away from a stricter XML based syntax, whilst a parser exists to handle both, it does not exist, and will not likely exist in many major frameworks quite like XML does. This leaves us with a web that's much more hassle to parse, much more of a headache to interoperate with, to transform for different display mechanisms and technologies and so forth.

From a development point of view a lot seems to have been thrown in the face of good practice there also- there's countless new tags which are worthless, we have tags like header and footer now, we're told because they're popular div ids anyway based on an older study at Google of the most common tag ids. The problem is, the web isn't static, and specs actually are (or at least should be!!), where is the tag for comments to articles that have become so prominent with the rise of web 2.0 for example? The fact is, you'll end up having to use divs anyway for half your blocks. The argument for these new tags is to make the web more semantic, but this means we're breaking separation of concerns- we realised it was beneficial to separate content with server side scripting languages and databases, dynamic actions with Javascript on the client side, and style information off into separate files where possible. Is it so hard to realise that moving semantics out of HTML like CSS into a semantic definition language would be by far the best option? We'd have the ability to define semantics for old, no longer maintained sites, we'd have the option of separating semantic definition for a site away from programmers to people better suited to it, we'd be given a system that allows the HTML spec to do what it should do- look after document structure, and we wouldn't find ourselves stuck in the situation where we need to pre-define a set of fixed blocks like header and footer, which will rapidly find themselves short as we need new blocks adding or old ones become obsolete. You'd just attach a semantic definition to whichever id or class you wanted to- flexible, dynamic, sensible.

This is not to say HTML5 doesn't bring great new stuff, canvas for example is great, but it's pretty clear as the parent says that HTML5 was developed with a very narrow vision of the web- certainly assisting good practice for web developers and accessibility are two things that were largely ignored. Even with the likes of canvas though I have to question the logic of

HTML5 really takes one step forward and two steps backwards as it brings to the forefront bad ideas and practices, and undoes many useful move sforward that we were finally getting underway with XHTML. I don't pretend XHTML didn't have it's problems either and I agree with XHTML2 a lot of bad decisions were taking, but HTML5 is most definitely

Re:HTML5 is a dangerous "standard".

[Anonymous Coward]

Both google and Apple have been heavily anti-drm in the past.

So, you actually bought into that bullshit about Apple being anti-DRM, and it was just because the big-bad media companies made them. Jobs just said that to make Apple look good, but I really can't believe them when they go out of their way to lock iPod users into only using iTunes with them (particularly their efforts with the Touch and iPhone). Face it, Apple likes DRM because it helps facilitate their platform lock-in and were happy to use it for music as long as they could get away with blaming the Music companies for "requiring" it.

Patents expire before and after 2028

[jbeaupre]

Keep in mind that the H264 standard and how it is implemented are two different things. Which is good, and bad, as we'll see. First, patents must be filed within 1 year of public disclose in the US, or before disclosure with PCTs. So any information you find will be unencumbered no more than 21 years after it was disclosed. Since H264 was finalized May 2003, the specification cannot be encumbered after 2024. And many aspects of it (draft specs, for example) will be available to anyone, license free, years before that. Probably some parts of it even now (though possibly such narrow, arbitrary steps that no one would care).

So the spec is available before 2028, but how about implementing it?

Well, certain implementations will be covered for many years. In fact, if you come up with a new way to encode or decode H264 today, you can still file a patent. For example: if you discover that by connecting two wires to a squirrel and sending uncompressed video into the squirrel through one wire results in H264 video out the other wire, that's patentable. Freaky, weird, but damn well worth a patent. If you figure out how to do it with a genetically altered squirrel 5000 years from now (hey, you've already go a digital squirrel, let's keep the weirdness going), then you could still get a patent. 5000 years after all the other implementations are free.

What this means is that over time, people will still file new implementations, but the older ones will also be opening up. Come 2016, there might be a way to do H264 without a patent license if someone clever figures out what pieces are free to use and figures out an alternative to the parts still under patent.

Re:Patents expire before and after 2028

[unix1]

What this means is that over time, people will still file new implementations, but the older ones will also be opening up. Come 2016, there might be a way to do H264 without a patent license if someone clever figures out what pieces are free to use and figures out an alternative to the parts still under patent.

That's not good enough because you can be sure that by 2016 MPEG-LA with their co-conspirators (Apple et al.) will have come up with new patents, like you said, and incorporate it into the "standard". H264 implementation the way it exists today may not be adequate by 2016. Therefore, the argument that today's H264 implementation might be implemented in a way to avoid patents by 2016 is not good enough as that will likely be useless by that time.

The problem here is not which patents expire when. The problem is the motivation behind standardizing on H264. It is not in MPEG-LA's advantage to license the H264 for free forever, or they would have done so already. It is to their advantage to be as liberal as possible now in order to hit a larger jackpot few years down the road. And, the road of patents is never-ending - just introduce a new patented software "feature" into the standard every few years and, as long as you get the major licensees on board (Apple, Youtube), you can keep the format locked up forever.

Re:Patents expire before and after 2028

[jbeaupre]

Slashdot is famous for not understanding patents and often shouts "the sky is falling." My commentary was just to provide facts and a bit more understanding of how things really work.

I'm not going to disagree with your conclusion. But your first paragraph is off on several counts. First off, H264 is already a published standard. Doesn't matter if new material is incorporated into it. The old stuff still hits public domain the same time it always was. Now maybe if there is an H264v2 and everyone switches to that, you might have patents to deal with. And only on the differences.

But H264(v1) is unaffected. If someone finds a way to implement it by 2016 (meaning write software, engineer a squirrel, etc) based on public domain knowledge, no amount of fiddling with the H264 standard can prevent it.

Re:Patents expire before and after 2028

[unix1]

Slashdot is famous for not understanding patents and often shouts "the sky is falling." My commentary was just to provide facts and a bit more understanding of how things really work.

I don't know about the "my knowledge is above all" attitude.

I'm not going to disagree with your conclusion. But your first paragraph is off on several counts. First off, H264 is already a published standard.

That's right.

Doesn't matter if new material is incorporated into it. The old stuff still hits public domain the same time it always was. Now maybe if there is an H264v2 and everyone switches to that, you might have patents to deal with. And only on the differences.

That was my point! It doesn't matter how you label it (H264v2, H264 extended, H264-drm, H264+, take a pick). For example, if H264 becomes standard for all video, by 2016 you can be reasonably certain there will be some sort of DRM and other "features" tacked on to it. The problem is - today's implementation will not be sufficient to decode and "play" the content that will become "standard" in 2016.

There are more than one ways to do this - one of them it's not inconceivable that MPEG-LA, Apple, Nokia, YouTube, etc. will have cross-licensing agreements and will be pushing the standard forward together, making sure the format stays locked up along the way.

Sure, it's only the "differences" that are the issue, but those differences will not be backward compatible - e.g. DRMed content will not be playable in a non-DRM player.

But H264(v1) is unaffected. If someone finds a way to implement it by 2016 (meaning write software, engineer a squirrel, etc) based on public domain knowledge, no amount of fiddling with the H264 standard can prevent it.

I like the optimistic thinking though.

Re:Patents expire before and after 2028

[jbeaupre]

I make my living with patents. I can either be pissed off at the level of ignorance on Slashdot, or try to educate. I still haven't given up hope on you.

You're right, there are problems. But you're looking under the wrong rocks.

I would argue that:

1) 2016-2024 is THE danger zone (again, not 2028 as the original summary said). Not hopeless, but a danger zone.
2) 7+ years of royalty free production of h264 videos to the standard published in 2003 is going to be a pretty big install base. It will be hard to suddenly switch away.
3) The best implementations may be patented well beyond 2024.

You keep bringing up what-ifs that are tangential to the video codec as it is today. If someone changes the standard, then they have to get people to adopt the new standard. That will always be the case. Hell, you could wrap DRM around AVI-RAW and patent the crap out of it. But that's a whole different issue.

Re:Patents expire before and after 2028

[jrincayc]

I generally agree with what you are saying, (See my original email on the 2028 year), but 2003 is not the date that matters, since H.264 continues to add substantial amendments:
http://en.wikipedia.org/wiki/H.264/MPEG-4_AVC#Versions

Re:Patents expire before and after 2028

[jbeaupre]

Yeah, I'm partial to the AVC version myself. For simplicity, I confined my comments to just the baseline. And that's murky enough. I wonder when AVC technology was first discussed openly (spec drafts, white papers, graduate thesis, whatever).

Re:Patents expire before and after 2028

[jrincayc]

Well, being able to encode and transmit H.264 baseline in 2024 would be a good start. I agree it would be interesting to know when much of the AVC technology was first discussed.

Just say no!

[woboyle]

Just say NO! to H264.

We keep repeating the same mistakes

[adipocere]

Streaming video needs an Apache. By that, I mean a very standardized server and set of protocols for delivering files encoded in a non-proprietary, free-to-use, free-to-decode, unrestricted-in-every-imaginable-sense manner.

The source of what has held this back, in my opinion, is that taking giant video files (and you should see how big raw video is) and cramming them down into small, chunkable files which can decode at the end into recognizable images is hard. Hard in the sense of "takes people with a great deal of math knowledge and computer science knowledge to pull off." It's not like HTML, where you are pushing around what are basically text files that you can open in Notepad. It takes a great deal of intellectual know-how and deep domain knowledge to pull this off on the encoding end in some reasonable fashion that doesn't take a lot of CPU cycles.

The few people who can do this take a long time to figure out a new scheme, and they have to test the living hell out of it. You can write a primitive webserver without too much fuss, it's just a specialized server which kicks out text and binary files on command, after all. Encoding video and serving it, though, is not easy. That's why so much goes into protecting the intellectual property; it was not trivial to create. Wade around in the fifteen profiles for MPEG-4 Part 10 aka AVC aka H.264 for a while and realize that this is not trivial. Hell, it had to be jointly developed by two groups, ITU's video group and MPEG. Take a look at Theora -- even its codebase is descended from something that once took real money to make.

If streaming media is to have its Apache, an investment of money must be made in finding these highly talented individuals and paying them to make a new, open standard. And code must be made available for an end-to-end implementation on many platforms, everything from encoding to serving (with authentication fun, to boot) to decoding, on Windows, on Unix/Linux, on Macs. With regression tests and tutorials. Plug-ins to be written for the top, say, ten browsers. And a decoder library for Flash. While this is going on, political battles will have to be fought to keep Microsoft, Apple, and other companies out of the loop, or they'll pull the usual and destroy or cripple the product before it reaches market, just as they managed to poison HTML5's video standards.

None of this is technically impossible, but it will be hard, and it will cost money and political tokens and time and real effort. Can it be done?

Re:We keep repeating the same mistakes

[seandiggity]

Streaming video needs an Apache. By that, I mean a very standardized server and set of protocols for delivering files encoded in a non-proprietary, free-to-use, free-to-decode, unrestricted-in-every-imaginable-sense manner.

I have to wonder how important streaming media in Flash-based or HTML5-based players would be if the content producers (e.g. Hulu and its investors) would give up the ghost and just let us download the video in a traditional manner. To me, it seems like what you're proposing is unnecessary. Correct me if I'm wrong.

Example:
I just finished watching these videos, available in Theora or H.264. When I click on any of those links, my browser fires up the mplayer plugin for Mozilla. The videos stream, and the bulk of the work is being done by my CPU and GPU. I could just as easily not watch the video in my browser, and just download the video and open it when it finishes. Or, I could have mplayer or xine or vlc or gstreamer or who-knows-what open the video automatically in a new window when I begin downloading such a file. Would any of these ways of watching the video, which seem perfectly fine to me and put the bulk of the burden on my CPU and GPU, necessitate a new "video Apache"? Serving up video doesn't seem that different than serving up any binary file, if the users just open the files in their own client programs instead of watching through a Hulu-like web player.

Re:We keep repeating the same mistakes

[Anonymous Coward]

You mean like Icecast, from the makers of Theora and FLAC?

Re:We keep repeating the same mistakes

[adipocere]

Streaming is not downloading. At all.

Downloading sends the whole file. It might as well be over FTP. Streaming is completely different.

First off, your media player and the streaming server negotiate a good bandwidth.

Next, the streaming server selects either the file or a stream within the file (as with RealMedia's SureStream) which suits the bandwidth of your media player.

This gets handed off by the server to your media player in a packetized fashion, little chunks of video. If you want to skip to a minute before the end, you may do so, even if you have not downloaded the whole file.

If a few packets get dropped along the way, if the buffer on your media player fails to take care of it, there can be a resend.

Or if your pipe gets clogged up, the streaming server can renegotiate the bandwidth. Or switch to a different server on the cluster, without you knowing about it.

Then there's a bonus for the people who are concerned with piracy (or those fearful of being sued for enabling it), which is that a whole copy of the file is not left on your hard drive. (You can get one by using a "stream ripper," but this is due diligence we're talking about here)

There's a lot of other stuff involved, and I'm drastically over-simplifying, but Streaming is not Downloading.

Re:We keep repeating the same mistakes

[evilviper]

Streaming video needs an Apache. By that, I mean a very standardized server and set of protocols for delivering files encoded in a non-proprietary, free-to-use, free-to-decode, unrestricted-in-every-imaginable-sense manner.

There is one big problem with this. Every video provider WANTS their walled-garden. I've worked in the business, I'm certain this is (almost exclusively) the case.

You could have the 100% free format in-hand, hand it to the Hulu management, and the #1 question will be "Does that mean people will be able to download our videos?" Near-sighted as it is, control of the viewer is paramount. You don't get ad views if the user can download the video once, and watch it 100 times, or if they can access it via Boxee, or some other direct feed. RealMedia was popular for years precisely because their (inferior) proprietary format offered that kind of control to the provider.

Encoding video and serving it, though, is not easy. That's why so much goes into protecting the intellectual property; it was not trivial to create. Wade around in the fifteen profiles for MPEG-4 Part 10 aka AVC aka H.264 for a while and realize that this is not trivial.

That's partially true, but largely a complete misunderstanding of the history of video encoding...

Video really started with the JPEG. Sub-sample the chroma, break it into blocks, run it through DCT, quantize it, then huffman-code it. At high bitrates, as found on DVDs, MJPEG (just a series of JPEG images) is actually surpisingly competitive with real video standards. Then you go to MPEG-1, which added the concept of differential images (P/B-frames), and motion compensation on top of JPEG compression. Once the world got to that point, video compression was pretty much done... all the low-hanging fruit were taken, and the sum total gives us something like 75% (educated guess) of the theoretical maximum possible compression without discernible visual artifacts.

That was over 20 years ago. Since then, MPEG-2, MPEG-4 ASP (Divx) have been rehashes of the same old tech, with absolutely trivial changes. The same is true for just about all proprietary codecs as well, from RealVideo codecs, to WMV, to Flash video, and yes, even Theora, all are based on the same thing. Somewhat complex and difficult in it's inception, but ever since, a solved problems so easy a 10 year-old could write-up a new video format.

With H.264, there are a few minor tech improvements that allow you to perhaps squeeze 10% better efficiency out of it, at the expense of massive CPU usage on both ends, and even that only at low bitrates. But that's really all it offers. Sure, it was a lot of work for the committee to all agree, and to do the testing to prove everything out, but really, all it added was deblocking, which allows you to make a low-bitrate video that's just fuzzy instead of breaking apart at the seams with blockiness, so it looks less terrible when used by those who don't know what they're doing...

In short, writing a video standard is not remotely as complex as you make it out to be. In fact the real magic is in the numerous parties around the world who go to great lengths to write a codec based on the format that squeezes every last possible bit of efficiency out of the format, and that can be done just as well with MPEG-1 as it can with JPEG. And Xvid, libavcodec, and x264 show the "free" world is at least as good at it as companies with a truck-load of money to throw at it. And even more significantly, early codecs like MPEG-1 have lost their patent protection, and so can just be used directly. In fact it's been royalty-free to implement an MPEG-1 decoder for so long, that practically all video player software supports it by default, and most hardware supports it as well. If your browser has ANY plugin that can play video, 99% chance one or all of them also handle MPEG-1. Why the horribly inefficient and CPU-heavy Theora was tossed around for the HTML video

Re:We keep repeating the same mistakes

[seandiggity]

Streaming is not downloading. At all.

Right, I know that. I think you're missing the point.

As long as a user's bandwidth is good, the effect is the same, right? So if I'm hooked up to Abilene/Internet2 then I can download high-quality video without the server doing jumping-jacks to accommodate me and other users. Furthermore, if I'm using a clever protocol like BitTorrent, network performance can be close to optimal and the community of sharing actually strengthens network performance. So, improving Internet access/bandwidth worldwide and building upon/innovating protocols for sharing are much more important than worrying about streaming.

It seems to me that the only ones who should be concerned about the current state of streaming technology are the media corporations and their organs like Hulu, as well as Google (the gatekeeper of much, if not most, of the web's video). Their motivation to develop newer streaming technology is to keep video content locked up, serve up advertising, or both, with higher quality as the bait.

For those who care about freedom and don't care about the ability of NBC Universal/Comcast to restrict viewers from saving video to their computers, why would improving streaming technology be an urgent priority (as the post I was responding to suggests)? The software now available seems to suffice for things like live webcasts...there is plenty of room for improvement and real-world limitations, just like in every other area, but I just don't see any urgency here.

Let me suggest something I do think is urgent: The preservation of all the videos that are currently in Google's hands, locked up inside the YouTube and Google Video Flash players. We should be ripping these videos, archiving them, and sharing them if we care about the permanancy of our cultural artifacts.

Re:We keep repeating the same mistakes

[jrincayc]

First of all, in the US, decoding MPEG-1 is not yet patent free, since some of the MPEG-1 layer 3 audio (MP3) patents are still around. I suppose you might be able to challenge them based on prior art.

I did propose that a MPEG-1 subset without MP3 could be used for the common base format for HTML5 but it basically did not go anywhere because 1. If a subset is used, then enough people will probably start using a full version of MPEG-1 (with MP3 audio) that free and legal software cannot support, and 2. Ogg Theora and Vorbis have better quality.
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-May/019991.html

I figure MPEG-1 support is useful once full MPEG-1 can be supported (Dec 2012 maybe?) if there still is no base format (or at least no base format better than Motion JPEG).

Re:We keep repeating the same mistakes

[Thundersnatch]

Streaming video needs an Apache

Per Slashdot tradition, I will pick on your analogy a bit, because I can't argue with most of the rest you wrote. We already already have the Apache for video... and it is: Apache. And IIS. And nginx, lighttpd, etc.

Move Networks and Microsoft have shown that the best way to do streaming in today's internet is via HTTP, while chunking the video into variable bit-rate segments. This allows easy caching of video fragments via CDNs or even Squid-style caching proxies at ISPs, universities, etc. Yes, you can do live streaming this way, and the Move Networks/Limelight Oprah event streamed to something like 1M viewers simultaneously.

Of course Move Networks has this patented this up the wazzu, and I imagine Microsoft has some of their implementation patented as well. But the actual chunking of video files is pretty obvious, and there's lots of prior art, so I imagine their specific patents can be avoided by an open standard.

So we don't really need an Apache for video, the distribution problem isn't hard, and we already have Apache.

What we need is the content generation toolchain, as you describe later. So we really need the Eclipse/gcc/Spring analogues for video. A free-and-open codec, file formats, and widely distributed players. As you state, the hardest of all these is the codec. I took a fair bit of maths and even some CG and DSP classes back in the day, and I can barely understand how MPEG-2 works, let alone something like H.264.

Re:We keep repeating the same mistakes

[adipocere]

You're right, I completely ignored the hardware decoding aspects. Every time I look at video/audio encoding/decoding, I end up adding at least one more link in the chain. I don't know if video encoding is all that easy. I don't know personally anyone who does it and I know a fair bunch of programmers in disparate knowledge domains. Maybe I just don't know the right guys.

I'm not completely ignorant of serving video over HTTP, I'm just not a huge fan of it. I know it's what the cool kids are doing right now, but it overloads the protocol in a way it wasn't meant to be. Traffic shaping alone kills the issue for me. I would much rather have my lightweight text delivered to me over HTTP and then someone else's bandwidth hoarking video over another protocol. I know everyone talks about the coming bandwidth utopia, but where I am at, we're having significant issues with certain folks (ahem, students) absolutely slamming the Teh Tubes with torrent traffic and videos, so much so that people are having trouble checking email and reading webpages.

Re:We keep repeating the same mistakes

[evilviper]

jrincayc (22260) writes:

Small world (guess who!). I try not to be too pedantic here on /. as it all too often overwhelms the real point, and adds far to little to the conversation.

1. If a subset is used, then enough people will probably start using a full version of MPEG-1 (with MP3 audio) that free and legal software cannot support,

This is extremely unlikely. MPEG files are MPEG-1 (or MPEG-2) video, and layer-1 or layer-2 audio. You will never see MP3 audio in MPEG files, though it's technically allowable, it never happens.

and 2. Ogg Theora and Vorbis have better quality.

Vorbis does have better quality, just by virtue of being VBR while MP2 is CBR. If MP2 had been VBR in the standard, the difference would be minimal, but that's not the case, so my dreams fall flat. Never the less, audio bitrate is perhaps 1/10th of the overall bitrate, so it may not be significant.

For video, I will say unequivocally, no, Theora is NOT any better than a good MPEG-1 video encoder (see mencoder or ffmpeg/libavcodec). As I said in my previous post, there are nominal differences between the underlying standards of MPEG-1 video, and MPEG-4 (part-2/ASP) video. MPEG-1 is much maligned only because encoders weren't very good 15 years ago, that same junk continues to propogate, and even if it didn't, people's experiences watching an old VCD 10 years ago is all they know of MPEG-1.

That thread merely shows most people don't have much grasp of audio/video encoding, have borderline superstitious beliefs with such subjects they do not understand, and are therefore quite vulnerable to marketing tripe thrown at them, such as On2's PSNR comparisons, combined with "easy" videos which aren't difficult to make look good at low bitrates.

Re:We keep repeating the same mistakes

[evilviper]

but where I am at, we're having significant issues with certain folks (ahem, students) absolutely slamming the Teh Tubes with torrent traffic and videos, so much so that people are having trouble checking email and reading webpages.

As a matter of fact, I can suggest prioritizing ACKs. This will greatly improve the responsiveness of interactive network access, while not noticeably slowing down such bulk-traffic. It simply needs to be done by your network admin on the routed directly connected to your internet pipe(s). Just about all relevant network devices support such configuration. It's not a utopia (won't be as fast as if nobody else was on), but it will help quite tremendously, changing browsing from "impossible", to "a bit slow".

Re:We keep repeating the same mistakes

[jrincayc]

I would like to see a good comparison of Theora and MPEG-1 video. If there is one online, I will certainly link it to the wikipedia MPEG-1 article. After US 5,214,678 expires (which was the only patent listed in the discussion (besides my list of H.264 patents)) on May 31 of this year, I might be willing to try and do another discussion on the whatwg list (or somewhere else).

P.S. I don't have good guess as to who you are.

No, you can’t do that with H.264

[c0d3g33k]

This should probably be its own story so more people get to see it, particularly those who are defending H.264 or are not aware of all the implications of standardizing on it.

http://bemasc.net/wordpress/2010/02/02/no-you-cant-do-that-with-h264/

Here is the lead paragraph:

A lot of commercial software comes with H.264 encoders and decoders, and some computers arrive with this software preinstalled. This leads a lot of people to believe that they can legally view and create H.264 videos for whatever purpose they like. Unfortunately for them, it ain’t so.

The article goes on to discuss the limitations on H.264 use in actual practice using examples of actual licenses. As I read it, the authorized software used to encode H.264 videos places strict limits on the use of the resulting video. This seems to be a problem not mentioned much in the context of royalty-free streaming of H.264 over the web, and infringement may actually be facilitated by the latter (by making these videos more ubiquitous).

This is in contrast to Theora, whose license has none of the same restrictions, whether or not the video is streamed over the internet.

Note: As I read this, it has nothing to do with the question of royalties themselves, but rather with the terms of use dictated by the actual license, royalty free or not.

Assured destruction of rogue NPEs

[tepples]

Imagine a nonpracticing entity discovering that it holds a patent that covers part of a widely used video codec, and it sues a major user of the codec for infringement of this patent. If this codec is one of the H.264 codecs, you'd get every MPEG LA member scrutinizing this patent and threatening to sue the rogue NPE for infringement of other patents that cover H.264 if it doesn't join MPEG LA. But if this codec is Theora, there isn't much of a way for patent holder On2 to retaliate against the rogue NPE because its VP3 patents underlying Theora are under a permissive license. (Well at least there wasn't before Google bought On2.)

Re:Assured destruction of rogue NPEs

[roca]

If it's a nonpracticing entity, then you *can't* sue them for infringements of other patents. That's exactly the point of being a non-practicing entity (i.e., a patent troll).

Re:Assured destruction of rogue NPEs

[tepples]

Then you sue the NPE in an area where it is practicing. And if it practices nowhere, you play the laches card.

Re:Assured destruction of rogue NPEs

[Thinboy00]

Then you sue the NPE in an area where it is practicing. And if it practices nowhere, you play the laches card.

Judge in Eastern Texas: "Let's see, he sued you, so he must be right [awards large amount of money]"

That's literally how it works. Do you really think he's going to listen to, of all things, the laches card? (Grammar Nazis:Commas do not belong but were added for clarity)

Want to see Dirac uptake!

[Lemming Mark]

I tried out Dirac for some of my private video collection last night and was quite impressed by the size of files output whilst still having reasonable quality. I shall be trying it out as my own preferred format for ripped DVDs but it is a standard it would be really interesting to see more uptake of. It's worth remembering that Theora is not the only open source and patent free codec out there, nor necessarily even the highest quality one.

Re:Want to see Dirac uptake!

[delt0r]

Dirac is pretty CPU expensive. Even more so than h.264, and thats saying something.

Re:Want to see Dirac uptake!

[Lemming Mark]

For just encoding, or for decoding too? The encode job did seem quite compute intensive but for the (admittedly low res) video that I did encode the CPU usage is not tremendously high although I can see it might perhaps be a problem on mobile devices. I should try on my netbook perhaps, see if it can keep up ...

Plan to sue the whole planet

[tepples]

We will all say: "Sooo... Do you plan to sue the whole planet?? LOL."

The response of major multinational record labels to the same question was as follows: "Yes. We will sue Jammie Thomas, and we will sue Joel Tenenbaum, and then we will sue you."

Videos with GOP structure IPPPPP...

[tepples]

If you've got enough RAM (which you almost certainly will in six years, even if you don't now) then even a naive serial implementation can decode a sequence of frames between two key frames in parallel.

You're thinking of B frames, which refer to the previous I or P frame and the next I or P frame. But a lot of less sophisticated encoders, especially low-cost encoders and live-stream encoders, generate only I and P frames. P frames depend on the most recent I frame and all intervening P frames. So for movies encoded in IPPPPPP... like a lot of DivX (MPEG-4 Part 2) videos in the wild, you'd have to decode one whole group of pictures on each core, which could mean buffering 16 groups of 120 pictures, unless you can find some intraframe parallelism.

There'll be a slight delay at startup and when you seek, but that's all.

Which will make it take even longer to flip through channels.

Bait & Switch

[Bert64]

Now that people are starting to wake up to how encumbered h.264 is and demanding theora for html5 video, they are just delaying the royalty payments to try and lessen the criticism and discourage people from moving to an open format...

How???

[Tangent128]

Have you read the HTML5 standard? It makes things more open than the Flash mess we have now. They don't define any open codecs, no, but neither do they mandate closed ones.

Nor are HTML5 browser.

[DrYak]

Does any of that help me run video on my cellphone (or whatever device) today? H264 is already supported in hardware.

But not on software. Your current phone is probably designed to play H264 video file from flash, but doesn't necessarily have a HTML5 ready browser.

So if the developers have to push an update once they write a HTML5 browser, why not cram some DSP/GPGPU accelerated Theora codec too ?

And the alternative solution is... ?

[DrYak]

Or, put differently, if YouTube and Hulu gave users a choice between h.264 and Theora, everyone (except the freetards {...}) would choose h.264.

Yes, and ? Your point being ?
At least, we freetards would get something to run on opensource such as Firefox, on other Theora-browsers such as Opera, and on our hobbyist and community projects. One bad solution (even more if it is only bad in 10% of situations in fact) is better than no solution at all.

Freetards running Firefox, Opera or other Theora supporting web-browser (F/LOSS version of Chromium) will have something, in a dual H.264/Theora world. In a h264-only world, they would be forced to switch to the binary Google Chrome and Internet Explorer, or go back to using BLOBs such as Flash or system codecs.

Say, I'm a freetard. Say that I happen to work on a community project. Like developing the OpenPandora, the TouchBook, or the Beagleboard - well just about anything which is not a x86 device.
Such project use rather custom hardware for which no software exist. Using open-source solution is the only way to go. (these examples use derivative of Angstrom Linux).

In a world were h264 is the only solution, users in jurisdictions where MPEG-LA's patent can be enforced are left in the mud.
Using ffmpeg would be considered illegal (and a community project might be big enough to attract the wrath of a patent troll). Packing Flash or some other binary software is not an option, for lack of support from vendors.

In a world were Theora is also available, the users of such device would be happy to at least have this, even if in 10% of situation the quality is worse.

By luck, the 3 devices I mentioned have hardware for decoding h264 inside their OMAPs, so they won't probably suffer from this problem (is there a VA-API or whatever released to that chip ?).
Other community project might not have this chance.

Re:And the alternative solution is... ?

[node 3]

At least, we freetards would get something to run on opensource such as Firefox, on other Theora-browsers such as Opera, and on our hobbyist and community projects. One bad solution (even more if it is only bad in 10% of situations in fact) is better than no solution at all.

Look, if you run solely 100% free software, (so, Opera is out, and Firefox on Windows and Mac is out), you may have a leg to stand on. Except you really don't, as you can *right now* play h.264 with completely free software.

There's no legal or technical reason that Firefox can't support h.264 across Mac, Windows and Linux. The only reason it's left out is for blatantly political reasons.

Freetards running Firefox, Opera or other Theora supporting web-browser (F/LOSS version of Chromium) will have something, in a dual H.264/Theora world. In a h264-only world, they would be forced to switch to the binary Google Chrome and Internet Explorer, or go back to using BLOBs such as Flash or system codecs.

Not true. First off, I'm just fine with sites providing both h.264 and Theora. The problem is that Firefox wants no h.264 option at all. In other words, they do not want people to be able to use the superior codec. But more to your specific claim, you can use x264 or ffmpeg, no BLOBs, Flash, or system codecs required. It's possible Mozilla may wish to avoid bundling x264 with Firefox in the US, but it can be easily supported as a completely open source plugin the user can install themselves (it can even be integrated in a "click here to install" link just like it does with Flash currently).

In a world were Theora is also available, the users of such device would be happy to at least have this, even if in 10% of situation the quality is worse.

So, a 10% worse solution, for far, far less than 10% of the users? Doesn't sound like a net win to me.

By luck, the 3 devices I mentioned have hardware for decoding h264 inside their OMAPs, so they won't probably suffer from this problem (is there a VA-API or whatever released to that chip ?).

So in other words, it's not even a problem for those less than 10%! Wow.

So, for some other community project that doesn't happen to use hardware that can decode h.264, they'll just have to use ffmpeg, x264, or do without. I can't fathom avoiding a technology that works absolutely wonderfully for myself, for fear that some potential minute group of people who might want to make some hobby box won't be able to stream YouTube. It's absurd. It's so absurd that I pulled out the term 'freetard' specifically, because no other term so succinctly conveyed the absurdity of the situation.

Re:And the alternative solution is... ?

[Thinboy00]

Not true. First off, I'm just fine with sites providing both h.264 and Theora. The problem is that Firefox wants no h.264 option at all. In other words, they do not want people to be able to use the superior codec. But more to your specific claim, you can use x264 or ffmpeg, no BLOBs, Flash, or system codecs required. It's possible Mozilla may wish to avoid bundling x264 with Firefox in the US, but it can be easily supported as a completely open source plugin the user can install themselves (it can even be integrated in a "click here to install" link just like it does with Flash currently).

ffmpeg is of questionable legality in the US thanks to the DMCA (and/or ACTA?); a simple "click to install" button isn't enough; they would have to have a "click here to install, but don't click here if you live in the US" button or something similar (cf. Ubuntu's "multiverse" repository).

Re:So how many are involved in this attack?

[node 3]

Is it just one with multiple accounts with modpoints, or is there a group? There's no way that my comment is flamebait if the parent comment isn't.

I get the same thing from time to time. Just shrug it off, there's really nothing else you can do.

the person who called FoSS users "freetards"

I never once called F/OSS users "freetards". I even made it explicitly clear to the contrary, that I'm using it in this particular case specifically.

Re:So how many are involved in this attack?

[Thinboy00]

[snip a lot]called FoSS users "freetards"[snip some more]

I believe by "freetard" he meant FSF-like, not Linux-Foundation-et-al.-like.

No, sorry, you don't convince me.

[DrYak]

(so, Opera is out, and Firefox on Windows and Mac is out)

Nonetheless, both FireFox and Opera are currently in the Theora camp.
If I want to use them (and I do. I use Firefox) I need Theora videos.
So Dailymotion and Thevideobay work for me. But not Youtube.

Except you really don't, as you can *right now* play h.264 with completely free software.

Free Software : yes.

Legal Software : that's a completely different can of worms. Some jurisdictions *DO* recognise software patents, and in such places - x264, ffmpeg and the like *are illegal*.

There's no legal or technical reason that Firefox can't support h.264 across Mac, Windows and Linux. The only reason it's left out is for blatantly political reasons.

Legal reason : Software patents. They happen to valid in some countries (USA and some
European countries).

Technical reasons :
- you need to be able to distribute the code, if you want a GPLv2/v3 license. But h264 decoding code might be illegal (see legal reason).
- supporting system codec is out of the question. the whole VIDEO/HTML5 idea was to escape from the dependence of binary 3rd party plug-ins. Opting for 3rd party codecs it, at best, a return to the statu quo (you replace a Flash proprietary BLOB with a codec proprietary BLOB. Meet the new master, same as the old master) and at worse, a huge step back (at least current 3rd party proprietary plugins were designed for the web (supposedly). Whereas some codecs might not be able to do proper stream/seeking nor be able to cope with malformed data without getting exploited).
- this assumes that system codec exists. whereas, such codec might be missing because no-one produces them on such a platform (all the non-x86, non-windows platforms) or because they are not packaged with the system (older windows versions, like XP)

Political reasons: someone has to do the fight for open standard. Why not the fastest growing browser with 1/4 of the market share, and the most popular embed browser ?

In short : Do you want to imagine what internet would have looked like if everyone writing or displaying HTML pages had to pay a tax to the CERN ? Mozilla and Opera are fighting so that doesn't happen in the future regarding video. I think that this is a valid reason.

Not true. First off, I'm just fine with sites providing both h.264 and Theora.

Me too, and almost everyone else.

The problem is that Firefox wants no h.264 option at all. In other words, they do not want people to be able to use the superior codec.

[citation needed]

I haven't seen a message from mozilla saying they want to forbid completely h264. The only thing I've read is about they wanting Theora to be supported, be part of the standard, and be mandatory on all browsers for html-5 compliance, so that the future web can be built on open standard. I've never seen anything saying that proprietary solution should not be offered as an alternative.

you can use x264 or ffmpeg {...} It's possible Mozilla may wish to avoid bundling x264 with Firefox in the US, but it can be easily supported as a completely open source plugin the user can install themselves

There are other countries besides the USA which recognise software patents. Sadly, this is starting to appear in Europe too (luckily, not all member states already).
And Mozilla are incorporated in the USA, which means, the law their are subjected to makes it illegal to do it.

And between trying to find contrived ways to circumvent complex patent law, and simply going for a solution which is not patented at all, I too think that the second approach is more sensible.

So, a 10% worse solution, for far, far less than 10% of the users? Doesn't sound like a net win to me.

It's a win compared to no solution at all due to broken p

Seems like a good investment.

[Merakis]

Admiral Ackbar might disagree.

Python Patent Expiration Script

[jrincayc]

Well, you could read the fine post, and notice that it says 2028. Or you could download the python program that I wrote and use it to find expiration dates on any list of US patents that you want:
http://en.wikipedia.org/wiki/User:Jrincayc/Patent_utils