Ogg codecs dropped from HTML5
| From: | Ian Hickson <ian-Y1JINVRCvcs-AT-public.gmane.org> | |
| To: | WHATWG <whatwg-J+okeHRe8Dwdnm+yROfE0A-AT-public.gmane.org> | |
| Subject: | Codecs for <audio> and <video> | |
| Date: | Tue, 30 Jun 2009 04:50:31 +0000 (UTC) | |
| Message-ID: | <Pine.LNX.4.62.0906292331380.1648@hixie.dreamhostps.com> | |
| Archive‑link: | Article |
[This message is bcc'ed to around 100 people who at some point or other
sent comments to the WHATWG list on this topic.]
After an inordinate amount of discussions, both in public and privately,
on the situation regarding codecs for <video> and <audio> in HTML5, I have
reluctantly come to the conclusion that there is no suitable codec that
all vendors are willing to implement and ship.
I have therefore removed the two subsections in the HTML5 spec in which
codecs would have been required, and have instead left the matter
undefined, as has in the past been done with other features like <img> and
image formats, <embed> and plugin APIs, or Web fonts and font formats.
The current situation is as follows:
Apple refuses to implement Ogg Theora in Quicktime by default (as used
by Safari), citing lack of hardware support and an uncertain patent
landscape.
Google has implemented H.264 and Ogg Theora in Chrome, but cannot
provide the H.264 codec license to third-party distributors of
Chromium, and have indicated a belief that Ogg Theora's quality-per-bit
is not yet suitable for the volume handled by YouTube.
Opera refuses to implement H.264, citing the obscene cost of the
relevant patent licenses.
Mozilla refuses to implement H.264, as they would not be able to obtain
a license that covers their downstream distributors.
Microsoft has not commented on their intent to support <video> at all.
(Sorry if I've mischaracterised any positions above; the positions are
relatively subtle and so it's likely that I have oversimplified matters.)
I considered requiring Ogg Theora support in the spec, since we do have
three implementations that are willing to implement it, but it wouldn't
help get us true interoperabiliy, since the people who are willing to
implement it are willing to do so regardless of the spec, and the people
who aren't are not going to be swayed by what the spec says.
Going forward, I see several (not mutually exclusive) possibilities, all
of which will take several years:
1. Ogg Theora encoders continue to improve. Off-the-shelf hardware Ogg
Theora decoder chips become available. Google ships support for the
codec for long enough without getting sued that Apple's concern
regarding submarine patents is reduced. => Theora becomes the de facto
codec for the Web.
2. The remaining H.264 baseline patents owned by companies who are not
willing to license them royalty-free expire, leading to H.264 support
being available without license fees. => H.264 becomes the de facto
codec for the Web.
When either of these happen, I will reconsider updating HTML5 accodingly.
The situation for audio codecs is similar, but less critical as there are
more formats. Since audio has a much lower profile than video, I propose
to observe the audio feature and see if any common codecs surface, instead
of specifically requiring any. I will revisit this particular topic in the
future when common codecs emerge.
I would encourage proponents of particular codecs to attempt to address
the points listed above, as eventually I expect one codec will emerge as
the common codec, but not before it fulfills all these points:
- is implementable without cost and distributable by anyone
- has off-the-shelf decoder hardware chips available
- is used widely enough to justify the extra patent exposure
- has a quality-per-bit high enough for large volume sites
This topic received hundreds of e-mails. Most covered the same points, and
I have not replied to each one individually. I include below a small
sample of some of the more interesting e-mails that were sent on this
topic, along with some comments.
On Wed, 21 Mar 2007, Asbj?lsberg wrote:
>
> I think that specifying a mandatory baseline codec is so valuable that
> it will be more gained than lost from doing it. It will enable authors
> to use one baseline format in all of their videos without thinking about
> browser support. Only if they choose another codec will they have to
> test for support in browsers, because its support isn't required by the
> HTML specification.
I agree in principle. Sadly it seems that we are unable to force the issue
through the spec.
On Thu, 22 Mar 2007, Thomas Davies wrote:
>
> Having been pointed at this discussion by Christian, I thought I'd let
> you know a bit more about where Dirac is as a royalty-free open source
> codec. We're certainly very keen for Dirac to be considered as one of
> the supported video formats.
It's unclear to me why Dirac hasn't received as close investigation as
Theora and H.264. I encourage you to approach the browser vendors directly
and discuss it with them. I expect, however, that the situation is
basically the same as with Theora (some UAs would be happy to support it;
others would cite lack of off-the-shelf hardware decoders and an unclear
patent landscape).
> We have been developing Dirac hardware as well. Hardware for the
> professional applications will be on sale in a very few weeks, and we're
> developing a prototype hardware HDTV encoder too.
Is the hardware support something that could be used by Apple in iPods?
On Sat, 31 Mar 2007, Martin Atkins wrote:
>
> If there is no baseline codec in the specification, I firmly believe
> that one of the following will happen:
>
> * Everyone will end up implementing whatever Microsoft implements.
> * Microsoft won't implement <video> anyway, so no-one will use it.
>
> In practice, everyone's just mimicking whatever Microsoft does. At least
> when they violate the spec they can be called on it; if what they do is
> allowable by the spec, then everyone will have to copy it or they'll
> have a useless browser.
I think this gives the spec more power than it actually has.
On Tue, 11 Dec 2007, Christian Montoya wrote:
> On 12/11/07, ryan <ryan-3V+t11F4wGbwvR0lvYjcXw@public.gmane.org> wrote:
> > On Dec 11, 2007, at 11:28 AM, Christian Montoya wrote:
> > > If even just 3 browsers, IE, Firefox, and Opera, supported OGG as a
> > > de facto HTML standard, and Safari did its own thing, that would
> > > still be a thousand times better than the crap we web developers
> > > deal with now.
> >
> > Even though the spec doesn't require these vendors to support OGG,
> > they can still do so.
>
> Yes, but if it is not required, then there is no way of telling whether
> or not that support will be permanent.
Sadly, even if the spec does require something, it's no guarantee that
it'll remain implemented. The spec doesn't force browsers to do anything.
Implementors only do the parts they want to do.
> > How do you propose that the WHATWG help web developers without browser
> > makers?
>
> By making OGG part of the spec.
Unfortunately, it seems that this would not force Apple to implement it.
On Tue, 11 Dec 2007, Dan Dorman wrote:
> On Dec 11, 2007 9:06 AM, Joseph Harry <jharry-8JqBueIXdYodnm+yROfE0A@public.gmane.org> wrote:
> > One thing to remember, HTML is created by people who can be bought,
> > and it is clearly what has happened here.
>
> Hey, let's not get carried away. Ian et al. have been working tirelessly
> and scrupulously on this spec; there's no reason to cast aspersions on
> anyone's character.
Joseph is right that I can be bought... but sadly for me this has never
happened with HTML5. :-( I guess I picked the wrong area to work in if I
wanted to make money through bribes!
On Tue, 11 Dec 2007, Fernando wrote:
>
> Please reconsider the decision to exclude the recommendation of the
> Theora/OGG Vorbis codec in HTML 5 guidelines.
>
> I expect that in a sophisticated group such as this one:
>
> * skepticism with how well the interests of powerful corporations match
> those of individuals that are not their employees or shareholders;
>
> * an understanding of the economic and civil rights damage being done to
> the rights of individuals by proprietary formats; and
>
> * an understanding of the wisdom behind the original wording of this
> portion of the document;
>
> Will enable you to see the need to readmit common sense and wisdom into
> HTML 5 by including OGG.
The problem is that at this point whether the spec requires Ogg or not
won't affect which browsers support it. All the browsers that would
support it do support it; the other browsers would just ignore that part
of the spec, which seems like a bad precedent to set.
On Tue, 11 Dec 2007, Jeff McAdams wrote:
>
> Wait...Apple and Nokia posit an potential patent threat as justification
> to remove the text, but patent and other "Intellectual Property" reasons
> aren't justification for putting it back?
The text was removed not because of any specific reason Nokia or Apple
gave, but because they won't implement the requirement. It actually
doesn't matter what the reason is in terms of editing the spec. Mozilla
could say "we don't want to support H.264 because numerology says that 264
is an evil number", the end result would be the same -- if a browser
refuses to implement something, then we can't require it.
(The reasons are relevant when trying to convince them to change their
mind, of course, or when trying to find a solution that they would agree
to instead -- I'm not saying we should ignore the reason altogether.)
On Tue, 11 Dec 2007, Manuel Amador (Rudd-O) wrote:
> >
> > Actually those are pretty much the only reasons being taken into
> > account here. Sadly, Ogg doesn't keep the Web free of IP licensing
> > horrors, due to the submarine patent issue -- as Microsoft experienced
> > with MP3 and with the Eolas patent over the past few years, for
> > instance, even things that seem to have well-understood patent
> > landscapes can be unexpectedly attacked by patent trolls.
> >
> > This does suggest we need patent reform, but in practice this is out
> > of scope for HTML5's development. We can't design our spec on the
> > assumption that the patent system will be reformed.
>
> Interesting. Finally patents have brought free multimedia innovation to
> a standstill. Two quite long paragraphs to say "we admit defeat".
No, that was just a tactical withdrawal. This e-mail here is the one that
admits defeat. :-)
> > In the absence of IP constraints, there are strong technical reasons
> > to prefer H.264 over [Theora]. For a company like Apple, where the
> > MPEG-LA licensing fee cap for H.264 is easily reached, the technical
> > reasons are very compelling.
>
> [...] Sure, Theora simply can't compress as good as 264. But Theora is
> free and its related patents have been irrevocably granted to the world.
"In the absence of IP constraints" was a very important phrase. :-)
> > The problem is that if the big players don't follow the spec, even the
> > SHOULD requirements, then the spec is basically pointless. What we
> > want isn't that some people support Ogg, what we fundamentally want is
> > that _everyone_ support the same codec, whatever that may be.
>
> Therefore, put Ogg Vorbis/Theora in the spec, and let everyone implement
> it.
Putting Ogg Theora in the spec doesn't lead to Apple implementing it, it
just leads to them ignoring that part of the spec.
> The two bullies that don't want to implement it simply don't get
> the content delivered to their machines
YouTube isn't going to not support the iPhone just because Apple doesn't
follow HTML5. They're just going to send the iPhone H.264 content (as they
do now), leading to Apple's products using less bandwidth or having higher
quality video that the implementations that did follow the spec. That
doesn't sound like a particularly good win for the spec.
> OR authors who would like to cater to bullies could use the JavaScript
> posted in the News section of Ogg Theora that automatically turns
> standards-conformant VIDEO into legacy crap. Brilliant and gracefully
> degradable.
<video> itself supports multiple sources, so there's no need for
JavaScript to do this. But it does mean we end up with exactly the
situation we're in now, with different implementations supporting
different codecs and the spec not having any power over this.
I would rather the spec not say anything than say something that will be
ignored.
> > I don't see how this affects Apple's stance here. Today they can get
> > significant traction with just H.264 (for example, Google is also
> > moving to H.264 and Apple can therefore implement YouTube applications
> > on iPhone without using anything but H.264). With Ogg, they get very
> > little traction, yet significant financial risk.
>
> That's no reason to NOT SUGGEST Ogg Vorbis / Theora. No one here is
> saying that HTML5 should forbid proprietary codecs -- all we're claiming
> for is the judicious and well-deserved mention of two free technologies
> in a document that will be read by MILLIONS of people to come. And you
> just killed that.
HTML5 is not an advertising platform for free codecs. It's a description
of what browsers (and other user agent classes) implement.
> > Small companies aren't targetted by patent trolls. Only big (really
> > big) companies are.
>
> And therefore they're deserving of more protection? Sounds like a
> racket to me.
I believe patent trolls pretty much are the definition of a racket, yes.
> > I am sorry you perceive them this way.
>
> Be honest, don't tell me you're sorry because you are not.
I am incredibly sorry about the state of video codecs in HTML5. Truly, I
am. This is a terrible situation for the spec to be in. I wish we had good
answers instead of this quagmirish deadlock.
> You're sorry when something personally sad happens to someone you know,
> not when there's a perfectly valid disagreement on an action you took.
I really am sorry in this particular case. Possibly, having worked on
HTML5 for the past few years, it has become like a person I know. :-)
> [...snip text about fear and bad-faith tactics...]
>
> > If we require Ogg, then what will happen is the big players will
> > support something else, then that will become the de-facto standard,
> > and you will get screwed. What we _want_ is for everyone to support
> > the same codec. We don't get that by having a SHOULD-level requirement
> > for Ogg.
>
> Well, tough luck, you can't.
That is indeed my conclusion also, at this time.
> The next-best option is Ogg, that favors small independent content
> producers.
That seems to be what Opera, Mozilla, and Chrome are implementing.
> But no-siree, we can't have that, can we?
Well we can have the implementations, but there's not much point having
the spec require it if it's not going to be followed by everyone.
> > At the end of the day, the browser vendors have a very effective
> > absolute veto on anything in the browser specs,
>
> You mean they have the power to derail a spec?
They have the power to not implement the spec, turning the spec from a
useful description of implementations into a work of fiction.
> That's something I would have considered before the advent of Mozilla
> Firefox.
Mozilla also has the power of veto here. For example, if we required that
the browsers implement H.264, and Mozilla did not, then the spec would be
just as equally fictional as it would be if today we required Theora.
On Thu, 13 Dec 2007, Shannon wrote:
>
> Ian, are you saying that not implementing a SHOULD statement in the spec would
> make a browser non-compliant with HTML5?
> Are you saying that if a vendor does not implement the OPTIONAL Ogg support
> then they would not use HTML5 at all?
No, I'm just saying that there's not much point requiring a codec unless
everyone implements it. We don't gain anything saying "you can do Theora,
or you can do something else, you know, whatever you feel like".
Generally speaking, we don't specify what other formats are to be
supported by an HTML implementation, the only reason to make an exception
would be if we could get uniform support across all implementations.
> What will it take to get this (apparently unilateral) change revoked?
I would be happy to change the spec as soon as all the implementors are
willing to implement a common codec.
> Finally, what is Google/YouTube's official position on this?
As I understand it, based on other posts to this mailing list in recent
days: Google ships both H.264 and Theora support in Chrome; YouTube only
supports H.264, and is unlikely to use Theora until the codec improves
substantially from its current quality-per-bit.
On Mon, 31 Mar 2008, Robert J Crisler wrote:
>
> I notice that HTML5's video section is incomplete and lacking.
>
> The text under 3.12.7.1 could have been written ten years ago:
>
> "It would be helpful for interoperability if all browsers could support
> the same codecs. However, there are no known codecs that satisfy all the
> current players: we need a codec that is known to not require per-unit
> or per-distributor licensing, that is compatible with the open source
> development model, that is of sufficient quality as to be usable, and
> that is not an additional submarine patent risk for large companies.
> This is an ongoing issue and this section will be updated once more
> information is available."
>
> The time has come for the W3C to swallow a bit of pride and cede this
> control, this area, to the Motion Picture Experts Group. While MPEG does
> not produce a codec that is free of any licensing constraints, the
> organization has produced a codec, actually several, that are world
> standards. You may have a digital cable or satellite service (that's
> MPEG-2 or MPEG-4). You may have a DVD player (MPEG-2), or a Blu-Ray
> player (MPEG-4). You may have an iPod (MPEG-4). And you may have heard
> of MP3.
>
> The time has come for the W3C, despite misgivings, to support an ISO/IEC
> organization that is charged with the development of video and audio
> encoding standards. We can't have a separate set of standards for web
> distribution. It simply complicates workflows and stunts any potential
> transition to the web as the dominant distribution mechanism for such
> media.
>
> Whatever the misgivings, it's time to say that the ISO/IEC standards are
> preferable to proprietary codecs (Windows Media, Flash), and that MPEG-4
> AVC is recommended over other codecs for video. It would be really great
> if an intrepid group of smart people were to come up with something
> technically superior to MPEG-4, make it a world standard for encoding
> audio and video, and make it available without any patent or royalty
> constraints. That has not happened, despite some strong efforts
> particularly from the OGG people, and it's time to acknowledge that fact
> and stop holding out.
>
> Again, the W3C should cede these issues to the ISO/IEC standards
> organization set up for the purpose of defining world standards in video
> and audio compression and decompression.
Unfortunately, the organisation to which you refer does not create a
standard that can be implemented in and distributed by free and open
source software projects, so it doesn't really solve the problem at all.
On Tue, 1 Apr 2008, David Gerard wrote:
>
> The actual solution is a large amount of compelling content in Theora or
> similar. Wikimedia is working on this, though we're presently hampered
> by a severe lack of money for infrastructure and are unlikely to have
> enough in time for FF3/Webkit/HTML5.
Having significant content using Theora would definitely be one way to
address this logjam, in that it would encourage hardware manufacturers to
support Theora, and would encourage companies like Apple to support Theora
despite the increased patent exposure.
On Fri, 4 Apr 2008, Robert J Crisler wrote:
>
> The W3C, by offering no actionable advice on standards support in this
> area, is implying by omission that any of the existing formats is just
> as good for interoperability as any other. I think in general principle
> that it would be better to "bless" (great word, and that's just it)
> MPEG-4 AVC for the present, despite its legal encumbrances, and to
> continue to press for a technically-excellent format that does not have
> those encumbrances.
At this point, if a video publisher wants his video to work with existing
<video> implementations, Theora and H.264 are the two codecs that are the
most effective in each implementation. I don't think we need to provide
much guidance at this point. People aren't going to use, say, RealPlayer's
format, because it's not supported and so wouldn't work.
> The W3C is not only about web standards. It's also the road map. Right
> now, that road map, where video is concerned, says the following: "User
> agents may support any video and audio codecs and container formats." It
> might as well say "Here be dragons." I think it's time, at the very
> least, to say goodbye to single-company proprietary dreck. To say both
> that existing international standards are OK for now, but the ideal as
> currently expressed in the boxed copy under 3.12.7.1 is still not met.
Why is this the case for video but not images? We don't require a
particular image format for <img> either, but people know you can just PNG
and JPEG.
On Fri, 29 May 2009 jjcogliati-whatwg-/E1597aS9LQAvxtiuMwx3w@public.gmane.org wrote:
>
> I propose that a MPEG-1 subset should be considered as the required
> codec for the HTML-5 video tag.
>
> == MPEG-1 Background ==
>
> MPEG-1 was published as the ISO standard ISO 11172 in August 1993. It
> is a widely used standard for audio and video compression. Both
> Windows Media and Apple Quicktime support playing MPEG-1 videos using
> Audio Layer 2. MPEG-1 provides three different audio layers. The
> simplest is Audio Layer 1 and the most complicated is Audio Layer 3,
> usually known as MP3. Since MPEG-1 includes MP3, a full implementation
> of a MPEG-1 decoder would not be royalty free until either all the
> essential MP3 patents expire, or a royalty free license is granted for
> all the essential MP3 patents.
>
> == MPEG-1 PRF ==
>
> I propose the following subset of MPEG-1 as the MPEG-1 Potentially
> royalty free subset (MPEG-1 PRF):
>
> MPEG-1 Video without:
> forward and backward prediction frames (B-frames)
> dc-pictures (D-frames)
>
> MPEG-1 Audio Layers 1 and 2 only (no Layer 3 audio)
>
> This subset eliminates the currently patented MP3 portion of the
> MPEG-1 Audio. It also eliminates the non-needed B-frames and D-frames
> because there is less prior art for them and this has the side effect
> of simplifying MPEG-1 PRF decoding.
>
> == Patents ==
>
> To the best of my knowledge, there are no essential patents on this
> MPEG-1 PRF subset. I have discussed this on a kuro5hin article, a
> post on the gstreamer mailing list and the MPEG-1 discussion page at
> Wikipedia, and no-one has been able to definitively list any patents on
> this subset.
>
> http://www.kuro5hin.org/story/2008/7/18/232618/312
>
http://sourceforge.net/mailarchive/message.php?msg_id=257...
> http://en.wikipedia.org/wiki/Talk:MPEG-1#Can_MPEG-1_be_us...
>
> That said, "absence of evidence is not evidence of absence". There
> still may certainly be patents on MPEG-1 PRF. Next I will discuss
> some prior art that exists for this subset.
>
> == Prior Art for MPEG-1 PRF ==
>
> The H.261 (12/90) specification contains most of the elements that
> appear in MPEG-1 video with the exception of the B-Frames and
> D-frames. H.261 however only allows 352 x 288 and 176 x 144 sized
> video. H.261 is generally considered to be royalty free (such as by
> the OMS video project). There are no unexpired US patents listed for it on
> the ITU patent database.
>
> http://www.itu.int/rec/T-REC-H.261
> http://www.itu.int/ipr/IPRSearch.aspx?iprtype=PS
> http://blogs.sun.com/openmediacommons/entry/oms_video_a_p...
>
> As for MPEG-1 Audio Layer 2, it is very close to MASCAM, which was
> described in "Low bit-rate coding of high-quality audio signals. An
> introduction to the MASCAM system" by G. Thiele, G. Stoll and M. Link,
> published in EBU Technical Review, no. 230, pp. 158-181, August 1988
>
> The Pseudo-QMF filter bank used by Layer 2 is similar to that
> described in H. J. Nussbaumer. "Pseudo-QMF Filter Bank", IBM technical
> disclosure bulletin., Vol 24. pp 3081-3087, November 1981.
>
> The MPEG-1 committee draft was publicly available as ISO CD 11172 by
> December 6, 1991. There is only a few year window for patents to have
> been filed before this counts as prior art, and not have expired.
>
> This list of prior art is by no means complete, in that there
> certainly could be patents that are essential for a MPEG-1 PRF
> implementation, but can not be invalided by this list of prior art.
>
> In the US, patents filed before 1995 last the longer of 20 years after
> they are filed or 17 years after they are granted. They also have to
> be filed within a year of the first publication of the method. This
> means that for US patents, most (that is all that took less than three
> years to be granted) patents that could apply to MPEG-1 will be
> expired by December 2012 (21 years after the committee draft was
> published.).
>
>
> == Brief comparison to other video codecs ==
>
> Motion JPEG with PCM audio is the only codec that I know of that can
> be played in a stock Windows, Linux and Mac OS X setup. On the other
> hand, since it is basically a series of JPEG images and a 'WAV' file,
> the compression is much poorer than MPEG-1 PRF.
>
> Ogg Theora and Ogg Vorbis are newer standards than MPEG-1. My guess
> is that they can do substantially better at compression than MPEG-1.
> Assuming there are no submarine patents, I think the OGG codecs would
> be a better choice than MPEG-1. If you think that MPEG-1 PRF is not
> royalty free, but Ogg Theora and Ogg Vorbis are, you may find that
> comparing Theora to H.261 or Theora and Vorbis to MPEG-1 PRF is an
> enlightening exercise. Much of what is in MPEG-1 PRF is also in Ogg
> Theora and Ogg Vorbis.
>
> MPEG-2 is the next MPEG standard. It mainly adds error correction and
> interlacing. Neither of these features is particularly important for
> streaming video to computer monitors using a reliable data transport.
> MPEG-2 definitely is patented, and will be until at least the 2018
> time-frame. I don't think that this buys much over MPEG-1 PRF, and it
> definitely adds more patent issues.
>
> MPEG-4, H.264 have better codecs than MPEG-1, but these have a long
> time till the patents expire, so are unsuitable for use royalty free.
>
> == Remaining Work ==
>
> I am not a lawyer. In order to use MPEG-1 PRF, patent lawyers will
> have to investigate the patent issue and publicly report on the
> patent status. Unless there is a report sitting around that can be
> published, this will likely be expensive.
>
> As well, the prior art review is not complete. The biggest missing
> piece is synthesis window for the audio layer.
>
> It would be useful if there is any large company that uses MPEG-1 who
> does not have a MPEG-2 or MPEG-4 license. One possible example of
> this might be a software only video CD player.
>
> I created a wikia page to put up information on MPEG-1 status:
> http://scratchpad.wikia.com/wiki/MPEG_patent_status
>
> == Satisfaction of requirements ==
>
> >From 4.8.7.1 HTML 5 draft:
> 1. does not require per-unit or per-distributor licensing
> Probably. There does not seem to be anyone requesting this kind of
> licensing right now.
>
> 2. Must be compatible with the open source development model.
> Probably. There does not seem to be any identified patents for MPEG-1 PRF.
>
> 3. Is of sufficient quality as to be usable
> Yes. Much better than the next best option of Motion JPEG. Probably
> worse than Ogg Theora or H.264.
>
> 4. Is not an additional submarine patent risk for large companies.
> Probably. It has been widely implemented (in DVD players, in Apple
> Quicktime and Microsoft Media Player) Note that these example uses
> have either a license for MPEG-2 or MPEG-4 however.
>
> == Conclusion ==
>
> The MPEG-1 PRF subset defined here seems to fit all the requirements
> of a codec for video for HTML5. It seems to be patent free. A final
> conclusion will depend on whether or not patent lawyers can sign off
> on this proposal and if the quality of MPEG-1 PRF is deemed
> sufficient.
>
> == Disclaimers ==
>
> I am not a lawyer. These are my own views. I probably made
> mistakes. Please correct me where I am wrong.
Thank you for this detailed proposal.
The only point I would make, and probably the reason why this proposal
hasn't been implemented by browser vendors, is in the following:
> 3. Is of sufficient quality as to be usable
> Yes. Much better than the next best option of Motion JPEG. Probably
> worse than Ogg Theora or H.264.
MPEG-1 is nowhere near good enough at this point to be a serious
contender. There have been suggestions that even Theora isn't good enough
yet (for example, YouTube won't use Theora with the current state of
encoders), an it _far_ outperforms MPEG-1.
--
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Posted Jul 6, 2009 21:01 UTC (Mon)
by drag (guest, #31333)
[Link] (5 responses)
Everybody else and their mom supported Ogg Theora/Vorbis. Opera, Google, Mozilla, etc.
Posted Jul 6, 2009 21:30 UTC (Mon)
by flewellyn (subscriber, #5047)
[Link] (3 responses)
Posted Jul 6, 2009 23:36 UTC (Mon)
by khim (subscriber, #9252)
[Link] (1 responses)
Microsoft does what it wants and when it wants. Sometimes documentation
drop occurs and is called "standard" (if you are lucky it'll be even
"international standard"). Since it's impossible to have any dialog with
Microsoft about standards it's useless to even wait for their offers. Better
to treat world like it is: Microsoft on the one side (necessary evil so
unavoidable - but the less you use it the better) and everyone else on the
other side (where there are small hope of consesus).
Posted Jul 6, 2009 23:55 UTC (Mon)
by JoeBuck (subscriber, #2330)
[Link]
Posted Jul 7, 2009 0:28 UTC (Tue)
by drag (guest, #31333)
[Link]
Posted Jul 8, 2009 17:30 UTC (Wed)
by petegn (guest, #847)
[Link]
Very well put if Apple dont want to conform screw them (it's about time they got crapped on anyhow) they got no interest in anything they cant make money out of and using a free codec just aint pleasing old S .Jobbs bank manager screw em
Pete
Posted Jul 6, 2009 21:16 UTC (Mon)
by dwmw2 (subscriber, #2063)
[Link] (4 responses)
We should have just mandated Ogg support, and then ensured that if Apple ever claim to support HTML5, they are sued for false advertising.
Posted Jul 6, 2009 21:24 UTC (Mon)
by job (guest, #670)
[Link]
Posted Jul 6, 2009 21:47 UTC (Mon)
by midg3t (guest, #30998)
[Link] (1 responses)
I think the strength in Apple's argument was suggesting that Theora has an uncertain patent landscape. The core of the argument is that every codec has an uncertain patent landscape (remember the trouble with MP3?), so standardising on any codec would put every implementor at risk if there turned out to be patent claims on it. While the result of not standardising on a single codec results in continued codec hell for all internet users, it keeps the lawyers settled.
Posted Jul 7, 2009 21:41 UTC (Tue)
by hingo (guest, #14792)
[Link]
Posted Jul 9, 2009 16:13 UTC (Thu)
by lambda (subscriber, #40735)
[Link]
Actually, part of the point of the HTML5 standards process was to move away from this, and
actually try and write standards that
would be implemented. The W3C tried to move HTML to XHTML (which in practice doesn't
achieve much more than pages
completely failing to render if you have one syntax error), and then write backwards-
incompatible standards (XHTML 2) that did
very little that anyone actually wanted while making a few architecture astronauts happy.
The WHATWG groups was started by Mozilla, Opera, and Apple to try to actually improve HTML in
ways that would benefit the web
and be implemented by browsers. This involved "paving the cowpaths," or writing specs for all of
the things that had become de-
facto standards like
Now, Microsoft has not been very involved in the HTML5 process. They have actually
implemented some new HTML5 features in IE
8, but there are a lot of issues (like the
If Microsoft committed to Theora, I'm sure that you could turn the heat up massively on Apple,
and probably get them to implement it. However, given that Microsoft already licenses H.264,
and hasn't said anything, it's more likely that they fall on the other side of the debate. With two
major implementations refusing to support Theora, it means that writing it into the spec is just
wishful thinking, and wishful thinking is one of the things that HTML5 is explicitly trying to
avoid.
Posted Jul 6, 2009 21:40 UTC (Mon)
by liljencrantz (guest, #28458)
[Link] (4 responses)
I see the political and technical reasons why Apple and Google prefer h.264, but their failure to see the bigger picture, and how much more they have to lose than they have to gain is disappointing.
Posted Jul 6, 2009 22:55 UTC (Mon)
by bcombee (subscriber, #40068)
[Link] (3 responses)
Posted Jul 7, 2009 6:47 UTC (Tue)
by rahulsundaram (subscriber, #21946)
[Link] (2 responses)
http://people.xiph.org/~greg/video/ytcompare/comparison.html
Posted Jul 7, 2009 13:42 UTC (Tue)
by jond (subscriber, #37669)
[Link] (1 responses)
Posted Jul 7, 2009 16:16 UTC (Tue)
by davide.del.vento (guest, #59196)
[Link]
Posted Jul 6, 2009 21:41 UTC (Mon)
by midg3t (guest, #30998)
[Link] (10 responses)
Can anyone expand on Apple's citation of "lack of hardware support". Is it impossible to port the Theora decoder to some architecture that Apple uses?
Posted Jul 6, 2009 22:01 UTC (Mon)
by joedrew (guest, #828)
[Link] (9 responses)
Posted Jul 6, 2009 22:53 UTC (Mon)
by timschmidt (guest, #38269)
[Link]
Posted Jul 6, 2009 22:56 UTC (Mon)
by leoc (guest, #39773)
[Link]
Posted Jul 6, 2009 23:14 UTC (Mon)
by moxfyre (guest, #13847)
[Link] (6 responses)
Indeed, but that's irrelevant.
Basically no one does hardware decoding of audio or video anymore. The iPod/iPhone? Software decoding on an ARM-core processor. TiVo? Software decoding on x86 I think. Sandisk MP3 players? Software decoding on ARM. Some DVRs? Software decoding on MIPS.
Software decoding is sooooo much more flexible (allowing bugfixes, new codecs, etc.) and faster-to-market that there's no reason to use hardware decoders anymore... now that it only costs a few $ to integrate a 100MHz ARM-core system-on-a-chip into a product.
It's true that hardware acceleration of mathematical operations is still important to efficient software decoding. Which is why all the major processor families offer SIMD instruction sets for fast, parallelizable math operations (e.g. SSE1/2/3/4 for x86, NEON for ARM, AltiVec for PPC, MDMX for MIPS).
The Theora encoders/decoders aren't (yet) totally optimized for all hardware, but that's cause it's a volunteer-run project with very little financial support. I personally patched Theora to use SIMD instruction sets on the x86_64 architecture, and it was about a day's work with no previous experience on the project. So Theora implementations can get a lot more efficient--quickly--if the adoption is there. The power of open source :-)
Posted Jul 7, 2009 0:27 UTC (Tue)
by pphaneuf (guest, #23480)
[Link]
Posted Jul 7, 2009 0:39 UTC (Tue)
by joedrew (guest, #828)
[Link] (3 responses)
Wrong - the iPod has hardware for decoding AAC, MP3 and H.264. They *also* have a general-purpose ARM core.
Posted Jul 7, 2009 4:58 UTC (Tue)
by gmaxwell (guest, #30048)
[Link]
Okay, so perhaps it would have lower battery life on that device. And? The proposal is a baseline. If the user and the content provider prefer something else, they are free to use something else.
Posted Jul 7, 2009 11:16 UTC (Tue)
by robert_s (subscriber, #42402)
[Link] (1 responses)
This 'hardware' will actually be a relatively general purpose DSP which is almost certainly reprogrammable to decode theora.
Posted Jul 7, 2009 17:57 UTC (Tue)
by joedrew (guest, #828)
[Link]
Nope - it's a specialized block of functionality added to Apple's Samsung-fabbed ASIC, the chip that also includes the ARM core.
Some iPods, the iPod video in particular, did include a DSP, but all recent ones are specialized hardware.
Posted Jul 7, 2009 1:26 UTC (Tue)
by xoddam (subscriber, #2322)
[Link]
Thankyou; your work is very much appreciated.
Posted Jul 6, 2009 23:19 UTC (Mon)
by bojan (subscriber, #14302)
[Link] (36 responses)
Posted Jul 6, 2009 23:31 UTC (Mon)
by jordanb (guest, #45668)
[Link]
Posted Jul 6, 2009 23:49 UTC (Mon)
by khim (subscriber, #9252)
[Link] (34 responses)
But the video support can be shown as pro-patent example as well!
Patent-encumbered formats were developed faster then totally free ones -
and
diffirence is sizable: years, not days or months. So this controversy is not so clear-cut as you want to show. If anything
is supports IBM's position: that some form or software patents can
be
good for progress, but at the same time they can slow down progress
to
so we need to balance the system, not destroy it totally... Software
patents do increase number of innovations creation (like any
other patents), but the do slow down rate of innovations
adoption (the same: like any other patents) and currently the score
is totally skewed to the "creation" side and it's stupid: innovations are
only useful when they are are adopted and integrated in real
products...
Posted Jul 6, 2009 23:59 UTC (Mon)
by JoeBuck (subscriber, #2330)
[Link] (16 responses)
Posted Jul 7, 2009 0:33 UTC (Tue)
by khim (subscriber, #9252)
[Link] (15 responses)
You mean: by the 1990 we had some form of "free" codec and it was
unreleased just because "hundred of patents" crippled the development and
it was unusable? Hard to believe, you know... Remember: H.261 was already
standard in 1990! And H.264 is it's direct descendant... The fact remains true: development of many patent-encumbered codecs was
finished before development of free codecs even started! The reason you
cite is excuse for slower development, but as free codecs development
started as response to existence and wide usage of patent-encumbered codecs
it can be argued that without patents there will be no codecs - free or
encumbered ones! This is extreme position but it's kinda hard to
refute.
Posted Jul 7, 2009 0:48 UTC (Tue)
by bojan (subscriber, #14302)
[Link] (14 responses)
The reason patented codecs were invented before the non-patented ones is simple. What proprietary software company would not apply for a patent when they could? Why would such a company want to minimize their profits?
If software patents were not available, those wanting to bring digital video the market would do it just the same. Their implementations would be copyrighted, which would give them decent market advantage. If their implementation was constantly improved, this would keep their market advantage for a while.
Asking proprietary software industry whether they like software patents or not is like asking a used car dealer if the car you are pointing at on his lot is good. It's the best, of course! The credibility of the one making the statement is what should be questioned, though.
Posted Jul 7, 2009 1:06 UTC (Tue)
by khim (subscriber, #9252)
[Link] (13 responses)
Why are you so sure this is the only outcome? There are another,
simpler and cleaner solution: introduce some analog component. You can do
a lot of transformations using less transistors in their analog mode
for cheap. Sure, the quality may suffer, but this implementation is clearly
patentable (it's physical thing like radio, right), so why not? Industry was at crossroads back then. Before that all processing was in
analog. Industry wanted to switch to digital - but they wanted the same
form of protection they had in "real" world! You assume that without that
protection switch was unavoidable too - perhaps but it can be pushed back
for many-many years (think mobile and VoIP). Will it be better outcome? I'm
not so sure...
Posted Jul 7, 2009 1:45 UTC (Tue)
by bojan (subscriber, #14302)
[Link] (8 responses)
Industry understands volume. If you produce enough of things and over long enough time, the initial development cost is insignificant. Your customers get better things to replace their old things. You make sales. You make profits. That's all there is to it.
Industry also understands monopolies. These are licences to print money. Generally, the attitude is "get yourself one of those, if you can". Of course, nobody gives a crap about the next guy as long as the profits are all that much higher.
If you take away (partially) the ability to do the second one, the industry will continue doing the first one. And they'll make a ton of money in the process.
Posted Jul 7, 2009 3:32 UTC (Tue)
by khim (subscriber, #9252)
[Link] (7 responses)
If and only if you have monopoly. Otherwise your own chinese
partners will kill all your profits before you can recompense your
development cost. Patents are not the only way to achive monopoly - there
are trademarks, exclusive contracts and so on. But patents are important
part of the whole. Even if they close just one market (US one) for would-be
contenders - it's important market. The more secure your monopoly the better. And industry does not
understand that well enough - that's why they are losing money with
ineffective DRM (like DVD or Blu Ray). But certain level of future
monopoly's security is a requirement - or the development will not even
start. If you take the monopoly away significant part of the industry will go
bankrupt - this is exactly what is starting to happen to a lot of firms in
last few years. Is it any wonder that industry fights for its survival
tooth and nail? Note: I'm not saying we need to keep raising monopoly to the more and
more ridiculous levels for the sake of the industry. After all well-being
if the industry is not an end in itself. But to say that without patents
we'll have the same technological landscape we have today is equally
naive. You don't need to push everything to the analogue part. Just enough to
make effective unauthorized use of your gadget impossible. Sony did this
even without analogue today (Ok, they did it three years ago, not today),
but it was not an option 20 years ago.
Posted Jul 7, 2009 23:32 UTC (Tue)
by bojan (subscriber, #14302)
[Link] (6 responses)
It's called capitalism. Meaning, you have competitors. Meaning, you cannot stay on top forever. It's no picnic, but that is how it works.
In the end, it is not about the industry. It is about the public and if they are getting the goods at the most competitive price. Monopolies of any kind create price increases, so if you like paying more for goods, then keep advocating software patents.
And let's not forget, the software industry already has a monopoly protection awarded to them - copyright (which includes the most draconian law there is: DMCA). And it's been awarded patent protection at the time when development and competition was fierce and there was no good reason to give them another monopoly. Now that they do have it, of course they don't want to give it up. They'll be screaming bloody murder for a long time. We've seen it all before.
Would things develop down a different path? Sure. Would we get similar results? Most likely. In the end, people develop and use things that work well and are cheap to produce. Just look at non-patented landscape of IP devices and web. Absolutely amazing what kind of software and devices evolved around this. But I'm sure you've heard all these before - no need to repeat them here.
Posted Jul 8, 2009 1:26 UTC (Wed)
by khim (subscriber, #9252)
[Link] (5 responses)
And this was my initial point. Please read again the statement I objected to again. I
never said world is better for software patents. I never said innovations
induced by software patents system are worth it. I just said software
patents encourage innovations but they discourage adoption - and you never
convincingly disproved this point. Yes, but this system only works if rules are not changing. If you were
offered one deal (monopoly for 20 years) and later this deal is changed
(let's abolish the software patents after 2010, for example) - it's fraud. Just like
copyright extensions were transgression of "big boys" (like Disney) against
public (when Mickey Mouse was created the reasonable expectation was that
this character will be available to everyone in 1984) - just in opposite
direction. Of course Congress is entitledto change rules "on the fly" (otherwise
you can not ever change rules at all), but this is not something to be done
at the drop of hat. And when this change is contemplated it's good to
consider both sides of the software patents coin...
Posted Jul 8, 2009 1:42 UTC (Wed)
by bojan (subscriber, #14302)
[Link] (4 responses)
Short memory - that's what we all have. Software was being developed just fine without patents. Plenty of innovation. I mention that before. But, you claim this does not disprove your theory of software patents. Back in the 90's just about everyone in the thriving proprietary software industry was _against_ software patents. Now they are for them, because they want to protect status quo. This is monopolies 101.
> Yes, but this system only works if rules are not changing.
Rules (laws) are constantly changing. Otherwise, parliaments would be out of business. The deal is that there are always transition periods. You tell people that what they have will be respected, but going forward after some point in the future, rules will be different. So, they adjust the expectations and continue. This is standard legislative practice.
Posted Jul 8, 2009 3:00 UTC (Wed)
by khim (subscriber, #9252)
[Link] (3 responses)
And it's now what I'm talking about at all. I'm not saying (and never
said) lack of software patents will bring number of innovations down to
zero. Just like lack of copyright will not bring number of stories down to
zero. Suuure. IBM was against patents? Or may be Philips was against software
patents? Microsoft was against software patents because it had none - but
to say that the whole industry was against them is just... how come they
were ever created and used (including in audio/video codec standards) if
everyone was against them?
Posted Jul 8, 2009 4:21 UTC (Wed)
by bojan (subscriber, #14302)
[Link] (2 responses)
And Oracle. And Autodesk. And Adobe. And Borland. And Lotus. All innovators at the time.
As usual, there is always enough of the established players that want to retain status quo for a greedy proposal to go through. Just think of that used car salesman again. Do you really need to ask him what he thinks of the car you're pointing at?
Have it your way. Software patents are just peachy and everybody loves them. Let's have more of them. Then we'll have to have even more stupid workarounds like the recent VFAT kernel stuff. Awesome. And we have digital video today because we had software patents. Otherwise, we'd still be stuck with the old analogue gear.
PS. BTW, any idiot working at USPTO or any other patent office that sees fit to approve moronic things like Microsoft's "computer bolted to the car that has wireless" should be immediately fired and words "patently stupid" tattooed on his/her forehead.
PPS. When we entrust patents to the morons that come up with rationales like this: http://www.ipaustralia.gov.au/strategies/case_kambrk.shtml, all kinds of things go wrong. Note: the company is alive and well, despite the fact it didn't get that patent, when it supposedly should have.
Posted Jul 8, 2009 5:30 UTC (Wed)
by khim (subscriber, #9252)
[Link] (1 responses)
All? You mean Apple or AT&T were against software patents too?
Industry
was divided back then like it was now. World is not white and black - there
are other colors. Again: don't oversiplify things. I never said software patents "are just
peachy" - on the contrary I think they must be abolished. Not because they
are pure evil, but because benefits are not big enough and fallout is way
too big. But when you are starting the whole "software patents have no good
sides to them at all" you just show yourself as someone totally detached
from reality - and so make all your other argument suspicious too. Today? Nope. Not even close. We had diginal video 20 years ago because
of the patents and now we have huge mess in this area related to said
patents. Was the advantage of getting digital video sooner rather then
later worth it? Hard to say, but probably not. But it's no
coincidence that this area is so heavily patented - and to ignore the
fact is to throw out the baby with the bath water... Nope. The system is designed in such a way as to punish honest worker
(lost royalties! waaah!) and reward hustlers (Ok - this patent was thrown
out by court... let's try the other 100 patents we have available). If the problem was moved to courts - it should be fixed there. Right now
the patent litigation process is designed in such a way as to make it great
for patent trolls and disaster for honest guys. Even if you win patent
litigation and prove that patent was frivolous - you get nothing in return!
May be pat on the head... If we know that a lot of patents are
bogus - why not introduce something like "reverse treble damages" for
litigator? I mean: Microsoft is free to claim it lost $100'000'000 because
TomTom refused to buy license patents in question - but then it should be
ready to pay $300'000'000 if the patents are reexamined and invalidated.
This will make 99% patents useless - but the rock-solid ones will be kept
around. I'm not the sure it's the best way to fix the patent mess. May be, may
be not. But we should think in this direction and not in direction of deus
ex machine which can remove all frivolous patents from existence after the
fact...
Posted Jul 8, 2009 21:36 UTC (Wed)
by bojan (subscriber, #14302)
[Link]
Oh, there are good sides to software patents. For the patent holders, that is.
Once again, history is forgotten. Software was being developed _without_ patents just fine. But, as usual, lawyers have found an angle, so they pursued it. And now we have the mess, as you said yourself.
> But it's no coincidence that this area is so heavily patented - and to ignore the fact is to throw out the baby with the bath water...
Coming back to your original remark:
> Patent-encumbered formats were developed faster then totally free ones - and diffirence is sizable: years, not days or months.
The only question here is this: if software patents were not available, would the same companies develop digital video at the time?
Your answer to this question is "probably not" (i.e. maybe there is something to having software patents after all).
I'm pretty sure they would. Said companies would licence their product differently - using just copyright - but they'd do it just the same. Even 20 years ago people understood Moore's law. They knew processing power in the future would make digital players cheaper than analogue ones. The also knew that storage would improve, making it practical to have a superior digital recording on a medium that can actually hold it. And they knew that if they didn't keep improving their products, nobody would want to buy them.
So, yeah, I _really_ do think that software patents are a terrible idea. Digital video included. If this makes me a lunatic, then fine.
Posted Jul 7, 2009 14:17 UTC (Tue)
by pboddie (guest, #50784)
[Link] (3 responses)
By asserting that patents were the crucial factor in making digital video a reality in a timely fashion, you're confusing at least two different things: hypothetical incentives and technical readiness. You actually touch upon the real reasons for the rapid availability of digital video solutions in your own comments. In fact, the people already doing "proto-digital" video (such as Philips - a known patent cartel member - with their laserdisc solutions) were obviously in a position to leverage their existing expertise in video, regardless of whether patents might be offered as incentives. Such companies could obviously introduce hardware components at will in order to retain monopoly control over certain solutions, mostly because this was already what was happening (although one could argue that their motivation was to sell boxes to consumers, as seen with the multitude of failed CD-based formats and units). Even so, other companies with limited experience of pre-digital video were able to deploy digital video solutions (such as Acorn, with their Replay codecs), demonstrating that capable innovators were actually able to enter the market satisfactorily. These days, such innovators would be excluded by the kind of innuendo and veiled threats that sees open video standards excluded from open Web standards by, naturally, members of the existing patent cartels. Meanwhile, well-researched (technically and legally) open codecs, such as Dirac, are the elephant in the room: Apple and friends would rather that people didn't hear about something that quite probably isn't encumbered at all (and BBC Research are probably the people most likely to know); it's best for Apple and company that the proprietary status quo persists and that they can blame some mystery third party for restricting the user's freedom, rather than owning up to their role in the whole affair.
Posted Jul 7, 2009 17:33 UTC (Tue)
by khim (subscriber, #9252)
[Link] (2 responses)
Yup - and where this enterprise went? Right: nowhere - to the
extinction. The same people founded another enterprise (heavily-based on
patents) and it's thriving today (I mean ARM Ltd). 1. That's what I'm talking about when I talk about adoption oproblems Not really. There are very few ways to produce Dirac (do you know a can
which can save files in Dirac format?) while H.264 can be produced easily. There are a lot of
hardware and software to play H.264 - not so with Dirac. Typical case of sunk costs. Thus I'm
pretty sure dirac will not displace H.264 (like vorbis failed to displace
MP3). It's good to have all these backup plans but you can be pretty sure
mainstream will continue to be MP3 and H.264. And in the long run it's
irreleant: by 2024 (may be earlier) all H.264-related tools will be free
for anyone to use, so this particular was is lost. MP3 tools will be free
by 2012 - do you still believe in future of vorbis?
Posted Jul 8, 2009 11:09 UTC (Wed)
by nye (subscriber, #51576)
[Link]
Absolutely. Vorbis eclipses MP3 in technical quality, which is really the only thing that matters in cases where you control the player.
All the world is not an iPod, and the uses for compressed audio stretch far beyond personal music players.
Posted Jul 8, 2009 11:13 UTC (Wed)
by pboddie (guest, #50784)
[Link]
Careful: the people who did Replay may have had a lot to do with the ARM architecture, but that doesn't mean that they wrote ARM Ltd's business model. Moreover, ARM is a hardware design licensing business, albeit with dubious aspects which probably get people into trouble even for making stuff that interprets their instruction sets. So it isn't as simple as saying that patentability makes for good business in all/any fields, even if Acorn made the mistake of not licensing their software in any sense to other people. In fact, had Acorn merely made their software available for other platforms and relied on good old copyright, it would have helped them a lot more than letting them have software patents. Do I still believe in the future of Vorbis? Yes. The quality was better than MP3 ten years ago, at least with the tools I had available, although I really prefer lossless formats. Likewise, the myths about Theora's quality compared to the cartel formats are being put to bed as I write this. Sure, "sunk costs" ensure that there's little incentive for established companies to adopt other formats, but it's the effect on everyone else that needs addressing, at the very least. It's easy for people to argue for more patents on the basis of giving people incentives because that's what patents are supposed to be about, but it's far from accepted that patents have been the vehicle for stimulating innovation that such people claim. Instead of going along with such claims, I suggest that the burden of proof is shifted onto those making such claims because there's plenty of evidence of the negative aspects of imposing patents on a domain. My point about Replay undermines the assertions that people need patents to develop such stuff and that large teams in large corporations are also required. Not only are those two supposed factors independent of each other, they are also independent of whether innovation actually occurs.
Posted Jul 7, 2009 0:27 UTC (Tue)
by bojan (subscriber, #14302)
[Link] (3 responses)
If anything, global financial crisis has shown how short memories we all have. Market will never crash again, house prices will never go down, blah, blah. Same thing here. Software was being written before it was protected by patents just fine. Innovation aplenty. The rest is just greed.
Posted Jul 7, 2009 0:35 UTC (Tue)
by bojan (subscriber, #14302)
[Link]
And the ultimate irony is that many of the financial instruments that spurred the crisis along were - you guessed it - patented! Such valuable intellectual property ;-)
Posted Jul 7, 2009 0:55 UTC (Tue)
by khim (subscriber, #9252)
[Link] (1 responses)
As patentable hardware solution, perhaps? Sure if the history went this
way free software we'd all used some form of hardware video/audio encoders
today (with analog and digital parts). Whole different world... Better then
current one? I'm not so sure...
Posted Jul 7, 2009 13:20 UTC (Tue)
by job (guest, #670)
[Link]
Posted Jul 7, 2009 1:08 UTC (Tue)
by PaulWay (guest, #45600)
[Link] (12 responses)
In reality, swift development is caused by large, well-funded teams, not by patent licenses. (And it's still not a guarantee of smooth sailing - look at all the companies now claiming to own patents on parts of the MP3 decoding or playback process...) Patent licenses are just coincident with well-funded teams.
Another counterexample: the CELT codec developed by Xiph.org is an excellent low-latency codec that competes with the best high-latency codecs in quality, and it was developed over two years by a very small team. Its core mathematics is unpatentable as the main paper covering the idea was written in 1975...
I agree with you on the point that patents improve the landscape for creators at the expense of technology adopters. Other organisations and governments are realising this too and I think we are starting to see a shift in the landscape away from encouraging pure creation to encouraging adoption.
(We need to keep the balance, however, because it's easy to argue that adoption is best served by a monopoly on who can create new software, and that's just what Apple and Microsoft would be happy to support.)
Posted Jul 7, 2009 3:13 UTC (Tue)
by dwheeler (guest, #1216)
[Link]
Posted Jul 7, 2009 3:51 UTC (Tue)
by khim (subscriber, #9252)
[Link] (10 responses)
Bingo! Sure, but patents are one way
to make large, well-funded team possible. Not the way to do, but
a way to do it. If it's the best way - that's the question. And that's it's probably why it
was not use in H.26x standards. Patents are two-edged sword, and that
is my point. It's not easy at all. Sure, it's easy to push one new idea if you
have the monopoly, but then the temptation is high to stifle all other
ideas (again: think mobile phones and VoIP), so monopoly is not an answer.
I can not see how you can ever argue it's the best way: problems with
adoption of patented/copyrighted solutions are the monopoly (that's what
the patents and copyrights grant the creator). To try to fix this problem
of excessive monopolization by introduction of another monopoly is like the
advice to extinguish a fire with gasoline...
Posted Jul 7, 2009 5:01 UTC (Tue)
by wblew (subscriber, #39088)
[Link] (2 responses)
The argument fails to hold water.
Posted Jul 7, 2009 5:14 UTC (Tue)
by gmaxwell (guest, #30048)
[Link]
Posted Jul 7, 2009 5:17 UTC (Tue)
by khim (subscriber, #9252)
[Link]
1. How many codecs developed in Europe without help from US companies do
you know? How successfull they are? 2. MPEG-LA does have patens in other countries besides US. The
full
list is not easy to find (why the hell do we have "open standards" which
unclude closed list of patents), but here are list of MPGE-audio-related
from
a
single Learn the facts before writing the answers. It's not clear what role
patents played in audio/video codecs development, but to claim that the
fact
that some codecs can be used in some small parts of the world without fear
changes the situation totally is to fool yourself.
Posted Jul 7, 2009 5:08 UTC (Tue)
by gmaxwell (guest, #30048)
[Link]
There is an effort underway to get the IETF to allow an (audio) codec working group which would focus on the creating and standardization of royalty free (audio) codecs for the Internet.
If you're interested in this I strongly suggest you read the archives and get involved: http://www.ietf.org/mail-archive/web/codec/current/mail9....
Posted Jul 7, 2009 14:11 UTC (Tue)
by madscientist (subscriber, #16861)
[Link] (5 responses)
For what it's worth I've worked on a LOT of software projects for companies both big and small, and never once in all those years was ANY decision about what to build or whether or not to build something EVER based on whether we could get a patent or not. It's just not true that that this is something companies think at all about, or depend on in revenue forecasts etc., before they commit resources. Similarly, I've NEVER been involved with or even heard about a situation where development was stopped because it was discovered that the work was not patentable after all (obviously stopping or changing work because it was discovered that the work was or might have been already patented is quite another thing).
What really happens is that mid-to-late in the software development cycle managers ask the more senior developers to consider whether anything they've been working on might be patentable, and if so to help the legal department fill out a patent application. Most of the time you don't hear anything about the patent until you've already moved on to completely new things.
Posted Jul 7, 2009 17:12 UTC (Tue)
by khim (subscriber, #9252)
[Link] (4 responses)
There are no differences if we are talking about "just a codec" (things
like Theora, Vorbis or Dirac). There are big differences if we are
talking about "media format" (be it VHS, CD, DVD or MPEG4). Not at all. Videocodecs are not unique: there are audio codecs too. That's because
it's place where software development mets content distribution. CD,
VHS, DVD, ATRAC, MPEG, etc - all these developments are heavily influenced
by future royalties and huge firm create and break huge alliances in fight
to control future markets. The latest such battle was HD-DVD vs Blu-Ray -
have you already forgotten about this? Questions about patents and future
royalties figured prominently in the fight. How many of these projects were about collaborative development by
fierce competitors? The fact that as result of this collision we've got all this patent mess
is unfortunate, but it's quite obvious that we only get these standards
(H.261, MPEG1 and all others) as early as we did is because software
become patentable at this point.
Posted Jul 7, 2009 23:50 UTC (Tue)
by bojan (subscriber, #14302)
[Link] (3 responses)
This is by far the biggest pile of crap big copyright holders are peddling. Even if there was not a patent in site, these would still hold true:
- many people would go and watch films in theatres
It is not about whether they can make good money on all this. Oh, no! It is about whether they can rip you off for _more_ than they would normally be able to. That's why they want patents - no other reason.
Posted Jul 8, 2009 3:15 UTC (Wed)
by khim (subscriber, #9252)
[Link] (2 responses)
Nice new collection of straw mans you have here. Again: we are talking not
about guys who develop DRM and sell movies, but about guys who develop
codecs for these movies. Some (but not all!) of them have one and only
one incentive: future royalties from associated patents. Kinda like Rambus.
People may hate them, people may love them but it does not change the fact
that such firms do exist.
Posted Jul 8, 2009 11:39 UTC (Wed)
by pboddie (guest, #50784)
[Link]
I too am struggling to see what is being discussed now: Plus... Then... If I understand you correctly, you're saying that a significant incentive for people to develop codecs is the ability to patent them, although that incentive doesn't exist for other software. But then you suggest that a patent isn't really an incentive for developing a codec after all, but it's the ability to bundle the patent in a standard which is the incentive, and by insisting on everyone using that standard, a nice little tax is imposed on a whole domain. Again, there's an assumption that one thing follows from another: in this case, that patents lead to standards. Yet we know that standards quite happily emerge without people asserting patents on those standards: various Web standards have convincingly demolished the top-down, patent-heavy, pay-per-copy standardisation model. If anything, patents merely lead to standards cartels and that pernicious little tax I mentioned above that becomes impossible to avoid. Meanwhile, I think it's disingenuous to claim that the people who want DRM are distinct from those making the standards. An insistence on the most egregious DRM mechanisms is a well-known excuse used to discourage people from using open formats on an open Web, all under the banner of standardisation.
Posted Jul 8, 2009 21:57 UTC (Wed)
by bojan (subscriber, #14302)
[Link]
For something to be distributed, it has to exist (i.e. you need to make a movie, music etc.). So, without these folks (the content providers), there is no mass distribution. If they want to distribute this in digital format, one has to exist. If software patents exist and one technology corners the market, royalty collection is not just from the content, but also from the patents enabling the content to be seen (in some cases it is the same company collecting both: see Sony). That would be the double dipping.
Now, if software patents didn't exist, digital media still would (same reason as before: smaller, faster, cheaper, better). Content producers would make sure someone develops the codecs for them, so they can sell the content. Everyone still gets paid, just not in perpetuity.
Posted Jul 7, 2009 4:59 UTC (Tue)
by iabervon (subscriber, #722)
[Link] (5 responses)
If there's anyone who could effectively push open standards in this area, it's the people who do the "Acid" browser tests. If they decided to dock a browser points in Acid4 if it didn't support either Dirac or Theora, or didn't support Vorbis, or didn't support Ogg, then Apple would be pretty likely to come around.
Posted Jul 7, 2009 5:13 UTC (Tue)
by gmaxwell (guest, #30048)
[Link] (2 responses)
You do realize that the point docking on those tests is directly based on the standards, right?
Posted Jul 7, 2009 5:58 UTC (Tue)
by iabervon (subscriber, #722)
[Link]
Posted Jul 8, 2009 6:10 UTC (Wed)
by khim (subscriber, #9252)
[Link]
Yup - but which ones? ACID3 tests: DOM, ECMAScript, SVG (and SVG fonts),
SMIL... These are not HTML5 by any stretch of imagination... I think Theora and Vorbis fit nicely in the "list of things we need to
see in future browsers"...
Posted Jul 7, 2009 7:20 UTC (Tue)
by njs (subscriber, #40338)
[Link] (1 responses)
Ian Hickson, the HTML5 editor and author of the email you're posting on, is from the (co-)author of Acid2 and Acid3.
I hope Apple comes around, but whatever it is they're trying to achieve by avoiding Theora (legal risk? something strategic?), they may well consider that more important than Acid4 compliance. And if Apple makes some loud and vaguely plausible argument about how Acid4 is so unfair -- they can't possibly comply -- and ignores it, then that runs the risk of making *the Acid tests* irrelevant, not Apple.
HTML5 has a similar problem -- it attempts to make a practically relevant standard (which job the W3C has completely abdicated), but that means that it can't just go around declaring reality to be other than it is. One can see this logic in the email -- it's being dropped from the spec because putting it in the spec wouldn't make a difference either way.
I think Jon's summary is overly pessimistic. This announcement doesn't change anything. The strategy for forcing Apple to bundle Theora was always to create web developer by shipping it in Firefox, and legal confidence by shipping it in Chrome.
Posted Jul 7, 2009 15:59 UTC (Tue)
by iabervon (subscriber, #722)
[Link]
The best solution is probably to test, first, that the <video> tag is handled and the browser will, if offered H.263 and Theora, pick one it supports; then to test that, if only offered a single file, it will be able to use it. Of course, there's the question of whether web designers wish everyone could handle Theora or whether web designers wish everyone could handle H.263. I personally wish Theora was what web designers would prefer, but I don't know if that'll be true. I expect the actual answer is that some designers want each.
Posted Jul 7, 2009 8:25 UTC (Tue)
by YangBaxter (guest, #25377)
[Link] (4 responses)
Posted Jul 7, 2009 9:42 UTC (Tue)
by jamesh (guest, #1159)
[Link] (3 responses)
That said, your suggestion really just pushes the patent problem on to content producers. To make sure the video would be viewable by the maximum audience, producers would need to provide both formats. Now they've got to deal with patents on the H.264 encoders.
Posted Jul 7, 2009 13:11 UTC (Tue)
by gmaxwell (guest, #30048)
[Link] (2 responses)
The killer is that MPEG-LA demands royalty payments from content distributors. Though 'your first try is free' for the web until 2010, future pricing will depend on exactly how viable distributing only in unencumbered formats is at that time.
If everyone feels that they must offer H.264 or be incompatible they'll be no reason for that price to be especially low.
Even if you hate Theora and never intend on using it it's strongly in your best interest to encourage its robust adoption, unless you are one of the few companies participating in the MPEG-4 patent pool.
Specifying "one or the other" is a complete non-starter as the W3C's own IPR rules take H.264 out of consideration. Moreover, it would be short sighted: Ten years from now both H.264 and Theora will be considered old and lame compared to H.266 and Theora-III or whatever, as this is still a rapidly developing area. Legacy support is a fact of life, but having to carry around twice the legacy support is just double-uncool, especially since H.264 will still require licensing even when it is no longer anywhere close to the cutting edge and for a long time to come.
Posted Jul 7, 2009 17:19 UTC (Tue)
by tzafrir (subscriber, #11501)
[Link] (1 responses)
ffmpeg's implementation has no issues other than patent rights, AFAIK.
Posted Jul 26, 2009 14:44 UTC (Sun)
by jrincayc (guest, #29129)
[Link]
US MPEG-LA patent list:
I think there is some possible justification for software patents (assuming that some way of distinguishing good patents can be found) but I have never seen a good justification for why software patents should last 20 years from filing date.
Ogg codecs dropped from HTML5
Ogg codecs dropped from HTML5
Microsoft? HTML standards? Dream on...
Had Microsoft gone along, and had Apple been the only holdout, my guess is Ogg would have stayed in.
Microsoft? HTML standards? Dream on...
Ogg codecs dropped from HTML5
Ogg codecs dropped from HTML5
I don't understand the logic that just because Apple won't implement it, it can't be part of the standard. The HTML 'standards' have always been mostly theoretical, and it's naïve to think that this is going to change with HTML5.
Ogg codecs dropped from HTML5
Ogg codecs dropped from HTML5
Submarine patents could affect any codec
Also note that this is not Apple's argument alone, but also Nokia's, who uses webkit in their phones. (The no off-the-shelf hw could also come from there, don't know.)
Submarine patents could affect any codec
Ogg codecs dropped from HTML5
The HTML 'standards' have always been mostly
theoretical,
and it's naïve to think that this is going to change with HTML5.
XMLHttpRequest or contenteditable (which
helps make the job of new
implementations easier, as you don't have to reverse engineer what the other browsers do), as
well as specifying new features that
authors actually want and vendors are willing to implement.
<video> issue) that they haven't made
any statement one way or the
other on. Apple has been highly involved, has helped invent features like
<canvas> that have become very
popular. Apple saying that they cannot implement something carries some real weight with the
WHATWG, and Ian Hickson really
does not want to go down the path of previous HTML versions in which features are added to the
spec just because they make the standards committee feel good while having no chance in hell
of actually being implemented by several major browser vendors.
Ogg codecs dropped from HTML5
Ogg codecs dropped from HTML5
Ogg codecs dropped from HTML5
Ogg codecs dropped from HTML5
Ogg codecs dropped from HTML5
Lack of hardware support
Lack of hardware support
Lack of hardware support
Apple has their own in house chip design capability.
Lack of hardware support
There is currently no hardware implementation of a Theora decoder, which means that the CPU has to be used, which drains battery life faster.Lack of hardware support
You need quite the solid machine to decode 1080p HD content. See the other recent article about VA API, for example, and the strong return of all sorts of video acceleration hardware to graphic cards.
Lack of hardware support
Lack of hardware support
Lack of hardware support
Lack of hardware support
Lack of hardware support
software support right here
Software patents
Software patents
Unfortunatelly this argument does not fly
I think this episode will be quoted in the future as an example
of how software patents stand in the way of progress.
The reason the patent-free codec development has been slower is not that patent incentives speed development. Rather, the need to work around hundreds of patents cripples development.
you're confused
Are you sure?
The reason the patent-free codec development has been slower is
not that patent incentives speed development. Rather, the need to work
around
hundreds of patents cripples development.
Are you sure?
Again: why are you so sure?
If software patents were not available, those wanting to bring
digital video the market would do it just the same. Their implementations
would be copyrighted, which would give them decent market advantage. If
their implementation was constantly improved, this would keep their market
advantage for a while.
Again: why are you so sure?
Volume vs monopoly? Does not work...
Industry understands volume. If you produce enough of things
and over long enough time, the initial development cost is
insignificant.
Industry also understands monopolies. These are licences to
print money. Generally, the attitude is "get yourself one of those, if you
can".
If you take away (partially) the ability to do the second one,
the industry will continue doing the first one.
Analogue? Yeah, that'd be cheaper, faster and more flexible.
Not. There is a very good reason we are in a digital age right now. Many
things are done with "smaller, faster, cheaper, better" gizmos -
computers.
Volume vs monopoly? Does not work...
Glad we agree in the end...
Would things develop down a different path? Sure.
It's called capitalism. Meaning, you have competitors. Meaning,
you cannot stay on top forever. It's no picnic, but that is how it
works.
Glad we agree in the end...
Straw man attack - here we come!
Software was being developed just fine without patents. Plenty
of innovation. I mention that before.
Back in the 90's just about everyone in the thriving
proprietary software industry was _against_ software patents.
Straw man attack - here we come!
Now you are just bitter...
And Oracle. And Autodesk. And Adobe. And Borland. And Lotus.
All innovators at the time.
Have it your way. Software patents are just peachy and
everybody loves them. Let's have more of them. Then we'll have to have even
more stupid workarounds like the recent VFAT kernel stuff.
Awesome.
And we have digital video today because we had software
patents. Otherwise, we'd still be stuck with the old analogue
gear.
BTW, any idiot working at USPTO or any other patent office that
sees fit to approve moronic things like Microsoft's "computer bolted to the
car that has wireless" should be immediately fired and words "patently
stupid" tattooed on his/her forehead.
Now you are just bitter...
Again: why are you so sure?
Why are you so sure this is the only outcome? There are another, simpler and cleaner solution: introduce some analog component. You can do a lot of transformations using less transistors in their analog mode for cheap. Sure, the quality may suffer, but this implementation is clearly patentable (it's physical thing like radio, right), so why not?
The means are different, the result is the same...
Even so, other companies with limited experience of pre-digital
video were able to deploy digital video solutions (such as Acorn, with
their Replay codecs), demonstrating that capable innovators were actually
able to enter the market satisfactorily.
These days, such innovators would be excluded by the kind of
innuendo and veiled threats that sees open video standards excluded from
open Web standards by, naturally, members of the existing patent
cartels.
2. Acorn was easily excluded by other means back when Acorn Replay was
relevant.Meanwhile, well-researched (technically and legally) open
codecs, such as Dirac, are the elephant in the room.
The means are different, the result is the same...
The means are different, the result is the same...
Yup - and where this enterprise went? Right: nowhere - to the extinction. The same people founded another enterprise (heavily-based on patents) and it's thriving today (I mean ARM Ltd).
Unfortunatelly this argument does not fly
Unfortunatelly this argument does not fly
Why are you so sure?
If that wasn't a possibility, they would still get invented just
fine.
Why are you so sure?
Unfortunatelly this argument does not fly
Creators are harmed by software patents, too. If there were only a few dozen software patents, it'd be easy to determine if some software you wanted to create was patented. But there's such a forest of patents that no one has a good idea of what's in there. In the software field, patents have created disincentives, not incentives, for creativity.
Creators harmed by software patents too
Huh? What are you talking about?
But your example misses the obvious detail that the companies
working on patent-free technologies (e.g. Xiph) are small, relatively low-
budget groups - even the Dirac project has been slow simply because it's a
very small part of the BBC and has about three developers over its
lifetime.
Miss? What miss? This is central part of my example:
wave smell of future royalties - and "big boys" will come and make
everything swiftly and effectively. Remove this smell - and development
takes years because only small groups of enthusiasts are doing it.This is probably related to the fact that these groups don't
charge for licenses for using their products.
In reality, swift development is caused by large, well-funded
teams, not by patent licenses.
Another counterexample: the CELT codec developed by Xiph.org is
an excellent low-latency codec that competes with the best high-latency
codecs in quality, and it was developed over two years by a very small
team. Its core mathematics is unpatentable as the main paper covering the
idea was written in 1975...
(We need to keep the balance, however, because it's easy to
argue that adoption is best served by a monopoly on who can create new
software, and that's just what Apple and Microsoft would be happy to
support.)
Huh? What are you talking about?
Huh? What are you talking about?
Are you sure?
patent troll firm. I presume video patents
include
equally impressive list.Huh? What are you talking about?
Huh? What are you talking about?
There are similarities, there are differences...
I don't see what makes video codecs so much different/more
special than other areas of software development.
Surely you're not suggesting that software development was
stymied and slow before patents?
So why are video codecs unique in this way?
For what it's worth I've worked on a LOT of software projects
for companies both big and small, and never once in all those years was ANY
decision about what to build or whether or not to build something EVER
based on whether we could get a patent or not.
There are similarities, there are differences...
- many people would rent media
- many people would buy media
Huh? What are you talking about?
It is not about whether they can make good money on all this. Oh,
no! It is about whether they can rip you off for _more_ than they would
normally be able to. That's why they want patents - no other
reason.
Huh? What are you talking about?
I don't see what makes video codecs so much different/more special than other areas of software development.
There are no differences if we are talking about "just a codec" (things like Theora, Vorbis or Dirac). There are big differences if we are talking about "media format" (be it VHS, CD, DVD or MPEG4).The fact that as result of this collision we've got all this patent mess is unfortunate, but it's quite obvious that we only get these standards (H.261, MPEG1 and all others) as early as we did is because software become patentable at this point.
Again: we are talking not about guys who develop DRM and sell movies, but about guys who develop codecs for these movies.
Huh? What are you talking about?
Ogg codecs dropped from HTML5
Ogg codecs dropped from HTML5
Ogg codecs dropped from HTML5
Sure, but which standards?
You do realize that the point docking on those tests is directly
based on the standards, right?
Ogg codecs dropped from HTML5
Ogg codecs dropped from HTML5
Ogg or H.264
Couldn't there be compromise in specifying that one should
implement ( Ogg or H.264 or both ) and the browser tells
the server which codec it is supporting?.
Ogg or H.264
Ogg or H.264
Ogg or H.264
Ogg or H.264
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-...
based on
http://www.mpegla.com/avc/avc-patentlist.cfm