Linked by Kroc Camen on Fri 1st Jan 2010 15:36 UTC
Opera Software HTML5 Video is coming to Opera 10.5. Yesterday (or technically, last year--happy new year readers!) Opera released a new alpha build containing a preview of their HTML5 Video support. There's a number of details to note, not least that this is still an early alpha...
Order by: Score:
KHTML too
by emilsedgh on Fri 1st Jan 2010 16:09 UTC
emilsedgh
Member since:
2007-06-21

KHTML users will get html5 video and audio on KDE SC 4.4 too.

khtml uses kde's phonon technology, which means mac users will get get output from QuickTime, windows users will get output from direct media and linux users will get output from gstreamer, xine, or any other available backend availble. i guess third party vlc and mplayer backends are there.

happy new year.

Reply Score: 4

s/depreciate/deprecate/
by ephemient on Fri 1st Jan 2010 18:21 UTC
ephemient
Member since:
2009-03-11

depreciate: To fall in value; to become of less worth; to sink in estimation; as, a paper currency will depreciate, unless it is convertible into specie.

deprecate: To pray against, as an evil; to seek to avert by prayer; to seek deliverance from; to express deep regret for; to desire the removal of.

Reply Score: 1

RE: s/depreciate/deprecate/
by Kroc on Fri 1st Jan 2010 19:05 UTC in reply to "s/depreciate/deprecate/"
Kroc Member since:
2005-11-10

Ah, thank you. Fix’d. You _can_ use Depreciate in British English, but this has all but died out now because of programming terms coming primarily from America. (Program instead of Programme &c.)

Edited 2010-01-01 19:05 UTC

Reply Score: 1

RE[2]: s/depreciate/deprecate/
by tyrione on Fri 1st Jan 2010 20:26 UTC in reply to "RE: s/depreciate/deprecate/"
tyrione Member since:
2005-11-21

Ah, thank you. Fix’d. You _can_ use Depreciate in British English, but this has all but died out now because of programming terms coming primarily from America. (Program instead of Programme &c.)


How does reduced in value have similar meaning to that of obsolete in British English?

Reply Score: 1

RE[3]: s/depreciate/deprecate/
by Kroc on Fri 1st Jan 2010 21:59 UTC in reply to "RE[2]: s/depreciate/deprecate/"
Kroc Member since:
2005-11-10

It’s hard to find details on the web (very Americanised), the two words have merged to a certain extent http://dictionary.reference.com/browse/deprecate

Reply Score: 1

RE[3]: s/depreciate/deprecate/
by memson on Tue 5th Jan 2010 13:03 UTC in reply to "RE[2]: s/depreciate/deprecate/"
memson Member since:
2006-01-01

The first time I came across the term "deprecate" in programming was in Java. Before that I'd been using ADA, Pascal and [Visual]Basic.

For me "depreciating", as in "belittling/making less important" works just as well as "deprecating", as in "belittling/making obsolete". The difference is semantics, either way it points me to the fact the construct "we" are about to use may not be a good idea and may be destined for removal.

Reply Score: 2

RE[2]: s/depreciate/deprecate/
by memson on Tue 5th Jan 2010 12:57 UTC in reply to "RE: s/depreciate/deprecate/"
memson Member since:
2006-01-01

I've always thought that depreciate makes more sense, as most deprec[i]ated methods/functions seem to hang about like a bad smell for a number of years anyway.

Reply Score: 2

Opera....
by modmans2ndcoming on Fri 1st Jan 2010 18:41 UTC
modmans2ndcoming
Member since:
2005-11-09

Seriously... I don't think Opera has a chance in snot of moving out of the basement. The world is moving to webkit/khtml... Browser makers would be well advised to use webkit for rendering and focus on innovating features for the browser like faster JS, more scripting languages, content management features, etc.

Reply Score: 1

RE: Opera....
by helf on Fri 1st Jan 2010 18:51 UTC in reply to "Opera...."
helf Member since:
2005-07-06

Why?

I love how people will go on and on about choice and all then claim others should give up on *their* implementation of something and go with the more popular ones. Webkit isn't the be all, end all.

Reply Score: 4

RE: Opera....
by mtzmtulivu on Fri 1st Jan 2010 19:00 UTC in reply to "Opera...."
mtzmtulivu Member since:
2006-11-14

consumers always wins when there is competition in the market. Opera may not "move out of the basement", but it plays a critical role in shaping where the web is going

If you read the article linked, you will see that opera was the browser that suggested the "video" tag, if the the browser that gave us tabs, it was one of the first browsers that scored high in acid tests and being web compliant and embarrass those that are already "out of the basement" and we, the consumers of the web are the beneficiary



the web stagnated when IE was the only dominant browser, the web will stagnate if web browsers are reduced to only one or two ..let there be many, let them compete on how to best serve the web and let us enjoy the benefits of the competition

you may not use opera as your browser, my it simply being in existance is putting pressure on your browser of choice and you should be thankful for that because you are indirectly benefiting from it

Reply Score: 11

RE[2]: Opera....
by g0nad on Fri 1st Jan 2010 20:14 UTC in reply to "RE: Opera...."
g0nad Member since:
2009-02-22

well said

Reply Score: 1

v RE: Opera....
by wumip on Fri 1st Jan 2010 20:12 UTC in reply to "Opera...."
RE[2]: Opera....
by mckill on Fri 1st Jan 2010 20:24 UTC in reply to "RE: Opera...."
mckill Member since:
2007-06-12

sorry. but you're way off. WK doesn't need to actually be mobile, that's why it's getting so popular, a full browser that can run on mobiles.

webkit isn't tied to apple, they do dedicate a lot of money to the project with their coders, it also hasn't stopped a number of other companies using webkit and releasing things on their own schedule.

there is a clear difference between webkit's release cycle and Safari's release cycle.

Reply Score: 2

RE[3]: Opera....
by wumip on Fri 1st Jan 2010 21:55 UTC in reply to "RE[2]: Opera...."
wumip Member since:
2009-08-20

sorry. but you're way off. WK doesn't need to actually be mobile, that's why it's getting so popular, a full browser that can run on mobiles.

You are missing the point. I didn't say it needs a mobile version. I said there's no WK for mobile. That is, there is no single WK engine for mobile. It's all a bunch of incompatible forks.

webkit isn't tied to apple, they do dedicate a lot of money to the project with their coders, it also hasn't stopped a number of other companies using webkit and releasing things on their own schedule.

The Webkit project is mostly run by Apple. Other companies have released WK based browsers, such as Nokia. And guess what, they created a fork which ended up miles away from Apple's WK, so they had to go back to the drawing board and do it all over again.

there is a clear difference between webkit's release cycle and Safari's release cycle.

You are missing the point again. Apple runs the WK project. As an example, Nokia forked WK and made their own mobile browser. But it was so troublesome to both work on their own fork and implement all the changes Apple added to the main WK code, so Nokia's browser ended up a completely separate fork which they had to throw away and start from scratch because all their changes were impossible to merge back since WK and Nokia's fork had evolved far away from each other.

The "one mobile engine to rule them all" is the wet dream of ignorant people who think it's just a matter of checking out the codebase and making a browser. It's much, much harder than that because Apple is moving WK in a certain direction, and if your plans deviate even a tiny bit from that, you'll end up with an incompatible fork.

Reply Score: 3

RE[4]: Opera....
by KugelKurt on Fri 1st Jan 2010 23:38 UTC in reply to "RE[3]: Opera...."
KugelKurt Member since:
2005-07-06

Apple runs the WK project.

Totally wrong.

As an example, Nokia forked WK

Wrong. Nokia's Qt and S60 ports are maintained in the main WebKit repository.

it was so troublesome to both work on their own fork and implement all the changes Apple added to the main WK code, so Nokia's browser ended up a completely separate fork which they had to throw away and start from scratch because all their changes were impossible to merge back since WK and Nokia's fork had evolved far away from each other.

You have a colorful imagination.

Reply Score: 4

RE[5]: Opera....
by wumip on Sat 2nd Jan 2010 00:04 UTC in reply to "RE[4]: Opera...."
wumip Member since:
2009-08-20

Totally wrong.

They do in practice. Sorry.

Wrong. Nokia's Qt and S60 ports are maintained in the main WebKit repository.

As forks, then. Nokia had to start all over again because their fork became too different and unmanageable.

Reply Score: 2

RE[6]: Opera....
by KugelKurt on Sat 2nd Jan 2010 00:35 UTC in reply to "RE[5]: Opera...."
KugelKurt Member since:
2005-07-06

They do in practice.

No.

Sorry.

You should be.


As forks, then.

No.


Nokia had to start all over again because their fork became too different and unmanageable.

No.

Reply Score: 2

RE[7]: Opera....
by wumip on Sat 2nd Jan 2010 11:47 UTC in reply to "RE[6]: Opera...."
wumip Member since:
2009-08-20

No.

Keep telling yourself that. You clearly have now idea how this works.

Reply Score: 0

RE[4]: Opera....
by Delgarde on Sat 2nd Jan 2010 08:38 UTC in reply to "RE[3]: Opera...."
Delgarde Member since:
2008-08-19

The Webkit project is mostly run by Apple. Other companies have released WK based browsers, such as Nokia. And guess what, they created a fork which ended up miles away from Apple's WK, so they had to go back to the drawing board and do it all over again.


Nokia is the first "other company" that comes to mind as a user of WebKit? How about, you know, Google? Maker of that Chrome browser people occasionally mention here?

Reply Score: 2

RE[5]: Opera....
by wumip on Sat 2nd Jan 2010 11:49 UTC in reply to "RE[4]: Opera...."
wumip Member since:
2009-08-20

Nokia is the first "other company" that comes to mind as a user of WebKit? How about, you know, Google? Maker of that Chrome browser people occasionally mention here?

Nokia is just a good example because they have been at it for a long time. It shows what happens over time. What you get is a bunch of incompatible forks:

http://www.quirksmode.org/blog/archives/2009/10/there_is_no_web.htm...

Reply Score: 1

RE[6]: Opera....
by KugelKurt on Sat 2nd Jan 2010 12:40 UTC in reply to "RE[5]: Opera...."
KugelKurt Member since:
2005-07-06

What you get is a bunch of incompatible forks:

http://www.quirksmode.org/blog/archives/2009/10/there_is_no_web.htm...

Nowhere in that article it's claimed that they are forks.

Reply Score: 2

RE[7]: Opera....
by wumip on Sat 2nd Jan 2010 13:08 UTC in reply to "RE[6]: Opera...."
wumip Member since:
2009-08-20

Just read the article. You will see what it says about there not being just one single Webkit implementation.

Reply Score: 0

RE[2]: Opera....
by daveak on Fri 1st Jan 2010 20:43 UTC in reply to "RE: Opera...."
daveak Member since:
2008-12-29

Yes they will all be ruled by Apple, Google will have no so whatsoever.

Reply Score: 1

RE[3]: Opera....
by wumip on Fri 1st Jan 2010 21:56 UTC in reply to "RE[2]: Opera...."
wumip Member since:
2009-08-20

If Google wants a say, they will be forced to fork Webkit, and that will create a separate and eventually incompatible and totally different engine which is no longer Webkit.

Reply Score: 1

RE[2]: Opera....
by KugelKurt on Fri 1st Jan 2010 23:31 UTC in reply to "RE: Opera...."
KugelKurt Member since:
2005-07-06

Also, browsers using webkit will always be "owned" by Apple since Apple basically runs the WK project. So anyone who goes for WK will either be a slave to Apple's release cycles


WebKit has no release cycles. Each port (Cocoa, Qt, GTK, Chrome) has its own cycle. Each port is managed separately. Apple only manages the Cocoa port.

Reply Score: 3

RE[3]: Opera....
by wumip on Sat 2nd Jan 2010 00:05 UTC in reply to "RE[2]: Opera...."
wumip Member since:
2009-08-20

Apple basically owns the Webkit project, so they add whatever they need whenever they need it. So yes, Webkit basically follows Apple's needs and release cycles.

You are talking about the wet dream theory. I'm talking about the cold, hard realith.

Reply Score: 2

RE[4]: Opera....
by KugelKurt on Sat 2nd Jan 2010 00:40 UTC in reply to "RE[3]: Opera...."
KugelKurt Member since:
2005-07-06

Apple basically owns the Webkit project

No.

so they add whatever they need whenever they need it.

Every contributor (Apple, Nokia, GNOME, Google) does. WebKit makes no releases. The main development branch in never frozen for any release. WebKit makes no releases.


Webkit basically follows Apple's needs and release cycles.

No.

You are talking about the wet dream theory. I'm talking about the cold, hard realith.

You are talking like an Opera fanboy without any connection to reality.

Reply Score: 2

RE[5]: Opera....
by wumip on Sat 2nd Jan 2010 11:48 UTC in reply to "RE[4]: Opera...."
wumip Member since:
2009-08-20

"Apple basically owns the Webkit project

No.
"
Actually, yes. Just look it up.

"so they add whatever they need whenever they need it.

Every contributor (Apple, Nokia, GNOME, Google) does. WebKit makes no releases. The main development branch in never frozen for any release. WebKit makes no releases.
"
The problem is that in practice, Webkit based browsers are a bunch of incompatible foreks:

http://www.quirksmode.org/blog/archives/2009/10/there_is_no_web.htm...

Reply Score: 1

RE[6]: Opera....
by KugelKurt on Sat 2nd Jan 2010 12:35 UTC in reply to "RE[5]: Opera...."
KugelKurt Member since:
2005-07-06

The problem is that in practice, Webkit based browsers are a bunch of incompatible foreks:

http://www.quirksmode.org/blog/archives/2009/10/there_is_no_web.htm...


You have no idea what you are talking about. That are not forks.

Reply Score: 2

RE[7]: Opera....
by wumip on Sat 2nd Jan 2010 13:07 UTC in reply to "RE[6]: Opera...."
wumip Member since:
2009-08-20

I recommend that you read the link instead of continuing to ignore the facts.

Reply Score: 1

RE[2]: Opera....
by modmans2ndcoming on Sun 3rd Jan 2010 07:07 UTC in reply to "RE: Opera...."
modmans2ndcoming Member since:
2005-11-09

Google and Apple and KDE produce webkit code. It is not an apple project. When Mozilla jumps on to the web kit engine, it will be all but over.

Seriously... the focus of competition should be on end user features and scripting engines.

Reply Score: 2

RE[3]: Opera....
by wumip on Sun 3rd Jan 2010 15:11 UTC in reply to "RE[2]: Opera...."
wumip Member since:
2009-08-20

WK is basically an Apple project, run by Apple.

Just one engine would be devastating to the browser market. There should be multiple engines out there competing to force sites to code to standards instead of engines.

Reply Score: 1

RE: Opera....
by tyrione on Fri 1st Jan 2010 20:27 UTC in reply to "Opera...."
tyrione Member since:
2005-11-21

Seriously... I don't think Opera has a chance in snot of moving out of the basement. The world is moving to webkit/khtml... Browser makers would be well advised to use webkit for rendering and focus on innovating features for the browser like faster JS, more scripting languages, content management features, etc.


The world isn't moving to Webkit/khtml.

The world is moving to WebKit.

Reply Score: 2

RE[2]: Opera....
by wumip on Fri 1st Jan 2010 21:56 UTC in reply to "RE: Opera...."
wumip Member since:
2009-08-20

The world is moving to a bunch of hard-to-manage forks of Webkit.

Reply Score: 0

RE[3]: Opera....
by KugelKurt on Sat 2nd Jan 2010 13:49 UTC in reply to "RE[2]: Opera...."
KugelKurt Member since:
2005-07-06

You keep posting wrong things about WebKit over and over again.
As proof for your accusations, you post links to an article, that merely states the varying degrees of WebKit port quality on different platforms.
I don't know if you don't know better of if you're lying on purpose.
No matter what, here are some facts:

Fact 1:
WebKit is not controlled by Apple.
Apple initiated WebKit and provides the hosting infrastructure. Other than that Apple has no special role in WebKit these days. Apple engineers work together with Google, GNONE, and Nokia ones.
They all have equal rights.
Anyone who reads http://webkit.org/blog/ sees postings about new source code reviewers (with full commit rights) quite regularly.

Fact 2:
Ports are not forks.
You claim that every port equals an fork.
That's not true. The main development branch can be accessed via http://trac.webkit.org/browser/trunk
Platform-specific code is in subfolders http://trac.webkit.org/browser/trunk/WebCore/platform and http://trac.webkit.org/browser/trunk/WebKit
The core code is located in JavaScriptCore and WebCore directories. That one is generic and not platform-specific.

Fact 3:
Quality varies from port to port.
When a vendor releases a browser based on WebKit, it works like this: the main trunk is branched and the vendor focuses his work (bug fixing) on that branch. That's the same for every vendor. Newer ports or branches by smaller vendors may not get as much bug fixing as e.g. the Chrome port by Google.
There may also be bugs in the used toolkit. Those bugs are out of scope to fix for the WebKit project.
Branches are made on a regular basis from the main trunk. A branch does not serve as primary development place for a port.
All big software projects use the trunk/branch development model. It's a proven model and does not equal unmanageable forks.

Fact 4:
Rendering capabilities depend on the graphics library.
WebKit does not have a single, unified graphics library. Gecko for example uses Cairo. Opera uses something proprietary.
If a vendor decides to port WebKit to a new graphics library instead of adapting the graphics library to the platform, regressions may occur.
No vendor is forced to port WebKit to a new graphics library. WebKit has already been ported to Cairo. If a vendor wants to improve on that one, he is free to do so.
Still, most vendors prefer porting to new/native graphics libraries. This reduces memory footprint -- especially important in mobile space. Vendors may see this as more important than 100% compatibility with existing ports.

Reply Score: 2

RE[4]: Opera....
by wumip on Sat 2nd Jan 2010 17:53 UTC in reply to "RE[3]: Opera...."
wumip Member since:
2009-08-20

You keep thinking that things work in the real world as they do in rosy-red theory land.

Fact 1: Apple does control the project in practice. Even if this changes, Webkit will still only be controlled by a couple of major contributors, most likely Google and Apple. Despite Nokia's size, they ended up with a broken fork, and had to start from scratch. For smaller players, Webkit will never be within their control. When even Nokia can't pull it off, how would others be able to?

Fact 2: You end up with forks in practice. Look at Nokia again.

Fact 3: Not only does the quality vary depending on the port, but each port will eventually either have to become fully forked, or work will have to be thrown away to be aligned with the main Webkit project, which is run by at most a couple of major players. Right now, Apple is basically the owner.

Fact 4: Indeed, there is more to a browser than the browser engine. Webkit is a not at all easy to work with, and when you start integrating with platforms, creating your own UI, etc. you quickly end up with a separate and incompatible fork.

So as you can see, Webkit is no easy solution. It's hard, requires a lot of work, and unless you are a giant like Google or Apple, you will forever be at the mercy of the Webkit "owners".

Reply Score: 1

RE[5]: Opera....
by KugelKurt on Sat 2nd Jan 2010 22:17 UTC in reply to "RE[4]: Opera...."
KugelKurt Member since:
2005-07-06

Did you even look into the WebKit repository? Those ports are not forks!

Why do you insist on your claims even after being proved wrong?

Nokia never put much effort into the S60 port of WebKit. They are only now putting effort into a port and that's the Qt port.

Even if Apple controlled WebKit: What exactly would be bad about it?

Edited 2010-01-02 22:28 UTC

Reply Score: 2

RE[6]: Opera....
by wumip on Sat 2nd Jan 2010 23:21 UTC in reply to "RE[5]: Opera...."
wumip Member since:
2009-08-20

Did you even look at the real world, and how the various ports are doing? Either your Webkit browser moves further apart from Apple's Webkit (the main WK development), or you become a slave of Apple's needs and release cycles. Maybe one or two major companies (Google is a good candidate) can wrestle some control away from Apple, but even Nokia failed miserably, ended up with a crappy fork, and had to throw away their work and start all over.

I didn't say there's necessarily anything bad about Apple controlling WK. It probably is if you need a mobile browser and want to compete against Apple, though.

There are tons of smaller players who will be at the mercy of the main WK maintainer (Apple).

WK is not the answer to your mobile browser wet dreams.

Reply Score: 1

RE[7]: Opera....
by KugelKurt on Sat 2nd Jan 2010 23:57 UTC in reply to "RE[6]: Opera...."
KugelKurt Member since:
2005-07-06

So, if Apple controls WebKit....
1.) How is the competition hurt by it?
2.) Which features, put into WebKit by Apple are bad?
3.) Which rendering engine should the competition use?
4.) Why is everybody using WebKit anyway, if by your great insight, WebKit is just bad for Nokia, Palm, GNOME, etc.?


And while you at it:
A.) Give proof that Apple is controlling WebKit. Which special rights to Apple committers have compared to others?

B.) Give proof that the WebKit ports are forks. Show that Nokia is not committing directly to the WebKit repository. The article you are linking to all the time does not give proof that different ports are forks.

C.) Give proof that there is a power struggle between Google and Apple over WebKit control.

Edited 2010-01-03 00:08 UTC

Reply Score: 2

Adobe Flash is a security hole
by ozonehole on Sat 2nd Jan 2010 00:15 UTC
ozonehole
Member since:
2006-01-07

I look forward to the death of Adobe Flash - it's a well-known cross-platform security hole. I'm amazed that we've put up with it this long.

Reply Score: 3

darknexus Member since:
2008-07-15

I look forward to the death of Adobe Flash - it's a well-known cross-platform security hole. I'm amazed that we've put up with it this long.


The sad thing is that we put up with it this long for one major reason: No one's come out with anything better and as cross-platform as Flash. It's quite sad, actually. HTML 5 video is only recently even beginning to catch on, and that's only one use case for Flash though a very common one. We'll still see Flash around for other things such as rich media games and the like until HTML 5 has equivalent designer tools. A good many Flash designers wouldn't know what to do with web code if it came out and bit them, yet they can design Flash applets easily with Adobe's tools and never have to touch code. That's what we'll need for HTML 5 before we see the Flash-centric sites begin to move to it and, even after that happens, inertia will keep Flash alive a good long time.

Reply Score: 6

Comment by cerbie
by cerbie on Sat 2nd Jan 2010 10:04 UTC
cerbie
Member since:
2006-01-02

I hope we get more people going with H.264, instead of Theora (where are the patent hounds coming after all the poor x264 users? *crickets*). This looks very good: "We don't care what codec it is, as long as Gstreamer can demux and decode it."

Reply Score: 2

RE: Comment by cerbie
by Kroc on Sat 2nd Jan 2010 10:56 UTC in reply to "Comment by cerbie"
Kroc Member since:
2005-11-10

That was sarcasm, right? You would actually prefer a 'Web where if you want to put a video on your own website, the legal eagles have the full right to swoop down on you and demand money for it? Yeah, that'll be just great for everybody. We already have the audio-police suing people for having a radio on within earshot of a human being, the last thing we need is the video police targetting bloggers.

Reply Score: 2

RE[2]: Comment by cerbie
by modmans2ndcoming on Sun 3rd Jan 2010 07:14 UTC in reply to "RE: Comment by cerbie"
modmans2ndcoming Member since:
2005-11-09

last I checked, h264 licenses costs were made against the tool makers, not the tool users.

If I make an h264 video, I don't have to worry about licensing costs... the browser vendor does.... and now that windows, Mac and Linux support h264 playback, I think it is moot.

Reply Score: 2

RE[3]: Comment by cerbie
by lemur2 on Sun 3rd Jan 2010 07:18 UTC in reply to "RE[2]: Comment by cerbie"
lemur2 Member since:
2007-02-17

last I checked, h264 licenses costs were made against the tool makers, not the tool users.

If I make an h264 video, I don't have to worry about licensing costs... the browser vendor does.... and now that windows, Mac and Linux support h264 playback, I think it is moot.


You didn't check very well.

Beginning in 2011, you will apparently have to pay a yearly royalty fee if you make a website that includes any h264 video. The more video data you send to more users, the higher the royalty fee will be. Sites such as Youtube are already looking at alternatives, to the extent that Google has purchased On2 (owners of the VP6, Vp7 and VP8 codecs).

http://newteevee.com/2009/08/05/google-buys-on2-now-controls-vp6-co...
http://en.wikipedia.org/wiki/On2_Technologies

Edited 2010-01-03 07:25 UTC

Reply Score: 2

RE: Comment by cerbie
by lemur2 on Sat 2nd Jan 2010 11:22 UTC in reply to "Comment by cerbie"
lemur2 Member since:
2007-02-17

I hope we get more people going with H.264, instead of Theora (where are the patent hounds coming after all the poor x264 users? *crickets*). This looks very good: "We don't care what codec it is, as long as Gstreamer can demux and decode it."


Why would you hope for h264? I think it is next year (2011) when the patent owners of h264 have said they will start charging everyone for each "transmission" (their word) of data encoded using a h264 encoder. The intent is apparently for a charge to be applicable not just each time someone uses the h264 codec to compress a video stream ... but rather every time someone "transmits" a h264-encoded stream!

http://www.streaminglearningcenter.com/articles/h264-royalties-what...

According to the “Summary of AVC/H.264 License Terms,” which you can download from the MPEG LA site (www.mpegla.com/ avc/avc-agreement.cfm), there are no royalties for free internet broadcast (there are, however, royalties for pay-per-view or subscription video) until Dec. 31, 2010. After that, “the royalty shall be no more than the economic equivalent of royalties payable during the same time for free television.”

...
So the most likely result will be a yearly fee per broadcast market, which may be the internet as a whole, but, logically, it could also be applied on a per-country basis. In the case of my multinational equipment manufacturer client, which has more than 25 international subsidiaries, each with its own website, the potential royalty charge exceeded $250,000. When I outlined my findings with the client, it was clear that this would be a major factor in its decision to change over to H.264.


Theora 1.1 (previously codenamed Thusnelda) achieves virtually the same performance as h264, but it is utterly free to use by anyone, anytime, for encoding, decoding or streaming, forever.

http://www.theora.org/news/
http://hacks.mozilla.org/2009/09/theora-1-1-released/

Edited 2010-01-02 11:25 UTC

Reply Score: 3

RE[2]: Comment by cerbie
by silix on Sat 2nd Jan 2010 12:16 UTC in reply to "RE: Comment by cerbie"
silix Member since:
2006-03-01

what's with this craze about Theora? it's not like it' s able to give such a better visual quality than other codecs, and it' not the only open and royalty free one, either (at least Dirac comes to mind)

so why force one particular format onto the web, instead of letting content distributors choose whether "transmitting" in a recognized industry standard format (and pay the royalties), or going the free and open route (but forcing viewers to transcode in order to see the same content -people often uses content grabbers like Orbit, you know- on their standalone player -many a players fully support H264, they don't do theora instead)

after all, it's them who will actually be the one charged for the aforementioned royalties, not those surfing the web...

Edited 2010-01-02 12:17 UTC

Reply Score: 1

RE[3]: Comment by cerbie
by wumip on Sat 2nd Jan 2010 13:10 UTC in reply to "RE[2]: Comment by cerbie"
wumip Member since:
2009-08-20

There is no craze about Theora. It was just consdered to be the best choice. Dirac had some limitations (something about not being streaming-friendly or something).

There should be a baseline format to make sure video works everywhere.

Reply Score: 1

RE[3]: Comment by cerbie
by lemur2 on Sat 2nd Jan 2010 14:24 UTC in reply to "RE[2]: Comment by cerbie"
lemur2 Member since:
2007-02-17

what's with this craze about Theora? it's not like it' s able to give such a better visual quality than other codecs, and it' not the only open and royalty free one, either (at least Dirac comes to mind)


Theora 1.1 has performance roughly equivalent to h264. No other open and royalty free codec comes close.

so why force one particular format onto the web, instead of letting content distributors choose whether "transmitting" in a recognized industry standard format (and pay the royalties), or going the free and open route (but forcing viewers to transcode in order to see the same content -people often uses content grabbers like Orbit, you know- on their standalone player -many a players fully support H264, they don't do theora instead)

after all, it's them who will actually be the one charged for the aforementioned royalties, not those surfing the web...


No other public access transmission standard (such as TV or radio) has a choice of standards. There is just one mandated standard for transmissions, it is open and royalty free, and all comers may implement it and compete in the market for making both transmitters and receivers.

Why should video over the web be different?

Edited 2010-01-02 14:27 UTC

Reply Score: 3

RE[2]: Comment by cerbie
by cerbie on Sat 2nd Jan 2010 19:33 UTC in reply to "RE: Comment by cerbie"
cerbie Member since:
2006-01-02

I did not know that. Well, screw H.264, then. I rather think the way Fraunhofer did MP3 was awfully good, and promoted wide use. Royalties per transmission will be a good way to choke it off, and doing so after it's been out and become popular will foster only the best PR.

I think it's insane that we have IP law systems that will even allow that sort of licensing, too. A cost for an encoder and/or decoder, if you're out to sell it to somebody, is entirely fair. A cost for that, and for making content and/or using it? No. Participation costs BAD. It is not analogous to something like TV, where there is ongoing content creation, and service maintenance, that basically doesn't exist on the side of the video format guys.

Edited 2010-01-02 19:44 UTC

Reply Score: 2

RE[2]: Comment by cerbie
by cerbie on Sat 2nd Jan 2010 19:41 UTC in reply to "RE: Comment by cerbie"
cerbie Member since:
2006-01-02

"Theora 1.1 (previously codenamed Thusnelda) achieves virtually the same performance as h264, but it is utterly free to use by anyone, anytime, for encoding, decoding or streaming, forever."

This, though, is still a bit of an issue, and will remain one. That statement is 100% false. Any modern nVidia card can even show that to be false under Linux+X with common software (AMD as well, in Windows). I'm not sure how that hurdle will be handled, in the future (GPGPU decoder programs?).

Reply Score: 2

RE[3]: Comment by cerbie
by lemur2 on Sun 3rd Jan 2010 07:34 UTC in reply to "RE[2]: Comment by cerbie"
lemur2 Member since:
2007-02-17

"Theora 1.1 (previously codenamed Thusnelda) achieves virtually the same performance as h264, but it is utterly free to use by anyone, anytime, for encoding, decoding or streaming, forever."

This, though, is still a bit of an issue, and will remain one. That statement is 100% false. Any modern nVidia card can even show that to be false under Linux+X with common software (AMD as well, in Windows). I'm not sure how that hurdle will be handled, in the future (GPGPU decoder programs?).


It is not false. It used to be the case that h264 was well ahead of Theora in performance, but recent advances in Theora have seen it catch up.

This is why I specifically mentioned Theora 1.1. H264 is well ahead of Theora 1.0 or earlier, but it is only marginally different in performance to Theora 1.1.

http://tech.slashdot.org/story/09/06/14/1649237/YouTube-HTML5-and-C...

Check it out for yourself here:
http://people.xiph.org/~greg/video/ytcompare/comparison.html

Same bitrate, same filesize, imperceptible difference in quality.

As for video cards playing the videos ... there are several stages in video rendering. Decoding the data stream is merely the first step. It takes perhaps two or three seconds for a CPU to decode a minutes worth of video data, so the codec decoding function is NOT the determining factor in replay performance.

Even if a given video card does not have a hardware decoder for a particular codec, once the bitstream is decoded from the codec format by the CPU, the rest of the video rendering functions can still be handed over to the video card hardware.

Edited 2010-01-03 07:41 UTC

Reply Score: 2

RE[4]: Comment by cerbie
by darknexus on Sun 3rd Jan 2010 09:49 UTC in reply to "RE[3]: Comment by cerbie"
darknexus Member since:
2008-07-15

It depends on what one means by the word "performance." If you mean video quality and encoding speed, then yes I'd say Theora 1.1 and H.264 seem to be just about even. When H.264 jumps ahead though is decoding performance, and the reason is simple. There are video accelerator chips for H.264, and at the moment there are none for Theora. It's sort of a catch 22 situation: there are no accelerator chips for Theora so we won't see any major content producers use it, but until one of them does start using it there won't be any demand for accelerators. Right now, all Theora decoding is done in software by the CPU. It's not an issue on desktops or set top boxes, but on laptops and portable devices it's a mother of a battery guzzler. To be fair, so is H.264 without hardware video acceleration, but that makes little difference to content producers and providers. Currently, H.264 delivers in a huge area where Theora does not, and if I had to bet on a codec that eventually replaces H.264 over licensing I'd bet on VP8 or whatever Google ends up naming it and not Theora. I can only say one thing for certain: next year is going to be very interesting in this area.

Reply Score: 2

RE[5]: Comment by cerbie
by lemur2 on Sun 3rd Jan 2010 11:06 UTC in reply to "RE[4]: Comment by cerbie"
lemur2 Member since:
2007-02-17

It depends on what one means by the word "performance." If you mean video quality and encoding speed, then yes I'd say Theora 1.1 and H.264 seem to be just about even. When H.264 jumps ahead though is decoding performance, and the reason is simple. There are video accelerator chips for H.264, and at the moment there are none for Theora. It's sort of a catch 22 situation: there are no accelerator chips for Theora so we won't see any major content producers use it, but until one of them does start using it there won't be any demand for accelerators. Right now, all Theora decoding is done in software by the CPU. It's not an issue on desktops or set top boxes, but on laptops and portable devices it's a mother of a battery guzzler. To be fair, so is H.264 without hardware video acceleration, but that makes little difference to content producers and providers. Currently, H.264 delivers in a huge area where Theora does not, and if I had to bet on a codec that eventually replaces H.264 over licensing I'd bet on VP8 or whatever Google ends up naming it and not Theora. I can only say one thing for certain: next year is going to be very interesting in this area.


It depends on what you mean by decoding performance. Certainly it is true to say that a video decoding and rendering in hardware is far faster than doing it in software, but that is NOT by any means a codec-dependant observation.

As I said in the grandparent post:
Even if a given video card does not have a hardware decoder for a particular codec, once the bitstream is decoded from the codec format by the CPU, the rest of the video rendering functions can still be handed over to the video card hardware.


Decoding the video data from the codec-compressed format into raw video data is but a small part of the problem of rendering video. This part of the task requires only a few seconds of CPU time for every minute of video. The amount of spare CPU time then is over 50 seconds per minute. If the decompressed video from a Theora-encoded video bitstream is passed on at that point to the graphics hardware, the CPU need be no more taxed than that.

The actual savings from having the video codec decoder function also implemented in the graphics hardware is not much at all ... all that one saves is a few seconds per minute of CPU time.

As you say:
If you mean video quality and encoding speed, then yes I'd say Theora 1.1 and H.264 seem to be just about even.


That is true. And when it comes to playing video, if the decoding is done in hardware (say for h264, which some graphics cards do have a decoder for), then the only savings is a few seconds per minute of the clients CPU.

However, be advised that a number of programs that play Theora perform the entire rendering of the video stream in software (i.e. in the CPU rather than the GPU), and so they do not use the graphics hardware at all. However, be advised that these programs also tend to do the same for h264, and the playing performance once again will be no better for one over the other.

Edited 2010-01-03 11:15 UTC

Reply Score: 2

RE[6]: Comment by cerbie
by cerbie on Mon 4th Jan 2010 01:09 UTC in reply to "RE[5]: Comment by cerbie"
cerbie Member since:
2006-01-02

H.264 offloading from AMD and nVidia offer 1/2 to 1/8 CPU use of doing it in software, allowing playback on machines that are otherwise not capable, and allowing post-processing on machines that are. If codec Y can use that kind of hardware, and get better playback than coded Z, which can't, then it is absolutely codec-dependent, regardless of how much of the time is spent just decoding the video stream.

Meanwhile, if they had all had to settle on a common toolset to program their chips, we might have software-based helper programs in Brook or OpenCL by now, and not be worrying about it so much.

Reply Score: 2

RE[5]: Comment by cerbie
by Ed W. Cogburn on Sun 3rd Jan 2010 13:10 UTC in reply to "RE[4]: Comment by cerbie"
Ed W. Cogburn Member since:
2009-07-24

and the reason is simple. There are video accelerator chips for H.264, and at the moment there are none for Theora.


If MPEG-LA decides to get greedy this year, then this could and almost certainly will change rapidly.

Note that one can make a hardware Theora encoder/decoder completely royalty-free, so for hardware makers, making such a thing would be cheaper than making the H264 equivalent. Then its just a matter of baking the silicon. The only thing stopping this is the current lack of demand.

At this point we seem to be repeating the same mistakes of history over and over. Remember the GIF fiasco of the early Internet? If MPEG-LA were smart, they'd lay low, not push their license fees higher later this year, and give the Internet & gadget makers more time to get hooked on their drug. They should wait 3 or 4 years, and *then* stiff everyone using H264 with a huge bill.

I personally hope they're more greedy than smart, so this would-be 'GIF fiasco 2.0' repeat doesn't even get off the ground.

Reply Score: 1

RE[5]: Comment by cerbie
by wumip on Sun 3rd Jan 2010 15:14 UTC in reply to "RE[4]: Comment by cerbie"
wumip Member since:
2009-08-20

When H.264 jumps ahead though is decoding performance, and the reason is simple. There are video accelerator chips for H.264, and at the moment there are none for Theora.

That's the crappiest argument ever. There WILL be acceleration for Theora if Opera, Chrome and Firefox all support it on all platforms. I can promise you that.

Reply Score: 1

RE[6]: Comment by cerbie
by Damnshock on Sun 3rd Jan 2010 16:42 UTC in reply to "RE[5]: Comment by cerbie"
Damnshock Member since:
2006-09-15

There WILL be acceleration for Theora if Opera, Chrome and Firefox all support it on all platforms. I can promise you that.


Well, I believe you need more than "support" for the acceleration to happen: you need the *CONTENT* to be in that format.

My bet is that if youtube encodes the videos in an open format, that's the one that will win the "battle".

Just an opinion though ;)

Reply Score: 1

RE[4]: Comment by cerbie
by cerbie on Mon 4th Jan 2010 00:52 UTC in reply to "RE[3]: Comment by cerbie"
cerbie Member since:
2006-01-02

"It is not false. It used to be the case that h264 was well ahead of Theora in performance, but recent advances in Theora have seen it catch up."

It is false. Nvidia, Intel, AMD, Imagination, and Broadcom, just off the top of my head have H.264 offloading in designs with their names on them. You can give a nice GPU (and drivers, and playback software) to an Atom to get flawless 1080P H.264 playback. Theora has some Google Summer of Code entires doing it on an individual level.

It's not an easy hurdle to get over, though if a, "everyone pays for every product, and every use of that product," license system goes into effect, it may have a chance.

Edited 2010-01-04 00:54 UTC

Reply Score: 2

RE[5]: Comment by cerbie
by wumip on Mon 4th Jan 2010 06:02 UTC in reply to "RE[4]: Comment by cerbie"
wumip Member since:
2009-08-20

Nvidia, Intel, AMD, Imagination, and Broadcom, just off the top of my head have H.264 offloading in designs with their names on them.

Good for H.264! Since doing the same for Theora is absolutely free, and since it is in the intersest of some of the biggest tech companies in the world (Google, Vodafone, Sony, etc.), Theora will be supported by hardware soon enough.

Reply Score: 1

RE[6]: Comment by cerbie
by cerbie on Mon 4th Jan 2010 06:55 UTC in reply to "RE[5]: Comment by cerbie"
cerbie Member since:
2006-01-02

It's no good if no one uses it, though. It's also no good if it is a moving target, which is a problem for many FOSS projects. H.264 was pretty much guaranteed wide use, and the format was set in stone some years ago, which is how it got to where it is.

As long as it stays in such wide use, it will be the one to choose. Even as royalties start hitting, the availability of H.264-enabled hardware and software will help keep it going.

It may not cost royalties, but it is not going to be free as in beer to add Theora support. If they get too greedy, though, it could happen. Not because Theora is, "free," but because H.264 would become too expensive.

Having a totally free initial period is not going to be good, if they turn around and start charging everyone, even if it's a nickel here and dime there.

Reply Score: 2

RE[7]: Comment by cerbie
by wumip on Mon 4th Jan 2010 07:30 UTC in reply to "RE[6]: Comment by cerbie"
wumip Member since:
2009-08-20

Theora will be supported by Firefox, Chrome and Opera. That's a growing part of the browser market.

What makes you think Theora is a moving target?

Royalties will hopefully help kill H.264. We need an open web, not a patented, expensive web.

Theora will be free to support, and with several major players pushing for it there's no reason for hardware vendors not to.

Reply Score: 1