Linked by Thom Holwerda on Fri 26th Feb 2010 13:12 UTC, submitted by poundsmack
Multimedia, AV The debate about HTML5 video is for the most part pretty straightforward: we all want HTML5 video, and we all recognise it's a better approach than Flash for online video. However, there's one thing we just can't seem to agree on: the codec. A number of benchmarks have been conducted recently, and they highlight the complexity of video encoding: they go either way.
Order by: Score:
isn't VP-7 > H.264?
by google_ninja on Fri 26th Feb 2010 13:18 UTC
google_ninja
Member since:
2006-02-05

Why would beating Theora make something the "the most powerful video format in existence"? I thought there were several formats that were better then both.

Reply Score: 2

RE: isn't VP-7 > H.264?
by Fettarme H-Milch on Fri 26th Feb 2010 13:54 UTC in reply to "isn't VP-7 > H.264?"
Fettarme H-Milch Member since:
2010-02-16

isn't VP-7 > H.264?

No. Nobody except On2 ever claimed that.

Reply Score: 2

RE[2]: isn't VP-7 > H.264?
by google_ninja on Fri 26th Feb 2010 14:22 UTC in reply to "RE: isn't VP-7 > H.264?"
google_ninja Member since:
2006-02-05

What about VC-1?

Reply Score: 2

RE[3]: isn't VP-7 > H.264?
by Ford Prefect on Sat 27th Feb 2010 19:45 UTC in reply to "RE[2]: isn't VP-7 > H.264?"
Ford Prefect Member since:
2006-01-16

VC-1 sucks against H.264 but it may be better than Theora.

http://forum.doom9.org/showthread.php?t=128498

Nobody really cares about VC-1, as it is a direct competitor to H.264 in terms of licensing scheme, has similar licensing costs but is less widely adopted and performs poorer.

Other codecs may strike against H.264 because they are free, cheaper or easier to implement.

Edited 2010-02-27 19:47 UTC

Reply Score: 1

RE[4]: isn't VP-7 > H.264?
by google_ninja on Sat 27th Feb 2010 19:55 UTC in reply to "RE[3]: isn't VP-7 > H.264?"
google_ninja Member since:
2006-02-05

Wow, you learn something new ever day :-)

I thought most Blu-Rays were VC-1, and that meant it was probably a better codec.

Reply Score: 2

RE[5]: isn't VP-7 > H.264?
by Ford Prefect on Sat 27th Feb 2010 20:05 UTC in reply to "RE[4]: isn't VP-7 > H.264?"
Ford Prefect Member since:
2006-01-16

It is true that many BluRay's use VC-1. This is a question of industry backing and MS has important ties to the content industry.

Some early BluRay releases even used MPEG-2. The adoption of a format in this segment does not tell much about the format's performance.

There is also one important detail to note (and you can also see this in the benchmark figures regularly). The best codecs really shine in the low bitrate segment. If the bitrate is high enough, the relative quality differences today become very narrow. BluRay disks have a high bitrate, up to 32 MBit/s. On that level, mastering quality and tuning have a far more significant impact than general format performance. On the web however, you have low bitrate content and H.264 is a clear winner (also in adoption) against VC-1.

Edited 2010-02-27 20:07 UTC

Reply Score: 2

Flawed comparison
by qbast on Fri 26th Feb 2010 13:28 UTC
qbast
Member since:
2010-02-08

Maxwell's comparison is flawed as well. He compared Theora at its best to H.264 Baseline profile - it does not even use B-frames not to mention more advanced features like B-pyramid, different modes of motion estimation or CABAC. There is nothing to brag about if Theora cannot even beat that. Now let's look at Theora features ( http://wiki.xiph.org/Theora ). "intra frames (I-Frames in MPEG), inter frames (P-Frames), but no B-Frames (as supported in MPEG-4 ASP/AVC)" - seriously? It does not matter how long you tweak Theora encoder when it is generations behind H.264 .
Well, it is free but it is still dead end.

Reply Score: 7

RE: Flawed comparison
by Wrawrat on Fri 26th Feb 2010 14:46 UTC in reply to "Flawed comparison"
Wrawrat Member since:
2005-06-30

Sure, H.264 has more potential than Theora, but it comes at the cost of complexity: current encoders don't even use half of the features provided by the standard. It will only get better, just like MPEG-2/H.262, but the Internet community want something right now. Theora is good enough right now for the web and it's free.

That said, I do agree that it's a dead end. I am definitely more interested by Dirac.

As for the benchmarks, I'm not sure it would be wise to use an High Profile for a web encode, as many handheld devices cannot decode them.

Reply Score: 6

RE[2]: Flawed comparison
by qbast on Fri 26th Feb 2010 15:05 UTC in reply to "RE: Flawed comparison"
qbast Member since:
2010-02-08

Sure, H.264 has more potential than Theora, but it comes at the cost of complexity: current encoders don't even use half of the features provided by the standard.


x264 has quite good support for advanced features these days. And is developed way faster than Theora.

It will only get better, just like MPEG-2/H.262, but the Internet community want something right now. Theora is good enough right now for the web and it's free.


'Right now' Google could flip some switches on their h264 encoder.

That said, I do agree that it's a dead end. I am definitely more interested by Dirac.

Me too, at least it is not yet another variation of DCT+MC+some tweaks theme.

As for the benchmarks, I'm not sure it would be wise to use an High Profile for a web encode, as many handheld devices cannot decode them.


As opposed to wide Theora support?

Reply Score: 3

RE[3]: Flawed comparison
by phoudoin on Fri 26th Feb 2010 16:19 UTC in reply to "RE[2]: Flawed comparison"
phoudoin Member since:
2006-06-09

As opposed to wide Theora support?


Considering his *cost*, I fail to see why Theora support will not be widely available on any handled device as soon as supporting it would become a must-have, if such thing ever happened.

On the contrary, I can see why some royalty-bound codec support could not be widely available on handled device but only on big manufacturers's ones...

It's not just a quality vs quality debate. There *is* other criteria to considerer. I'm glad to have Vorbis support in my pet-operating system *and* digital music player for isntance, and it's totally due to Vorbis being patent+royalty-free, nothing else.

I'm not ready to trade everything just for the best quality ATM.
Are you?

Reply Score: 4

Open is a must
by darknexus on Fri 26th Feb 2010 13:37 UTC
darknexus
Member since:
2008-07-15

I don't really care, in the end, what codec gets used so long as it's a completely open codec. Be it Theora, Dirac, Snow, or another one I've not heard of yet, so long as it can be freely implemented by anyone with no patents or royalties and will remain that way forever it is fine with me. H.264 is a dangerous path to walk, the MPEGLA hasn't removed the danger just delayed it by five years. We don't know what they'll do when the licensing terms come around again in 2016, and if web video is entirely dependent on H.264 by then we've effectively handed control of online video not to the open web as it should be, but to a set of corporations. Think where we'd be if HTML wasn't an open standard.

Reply Score: 20

RE: Open is a must
by danieldk on Fri 26th Feb 2010 16:45 UTC in reply to "Open is a must"
danieldk Member since:
2005-11-18

Well, except that Theora is probably 'covered' by many of the same patents. In video codecs, there is barely patent-free, just 'not patented by its designers' or 'unclear which patents exactly cover the codec'. In the end, patent-wise using Theora or H.264 via ffmpeg probably does not make much of a difference, except that for H.264 OS X and Windows users at the very least have a license to use those patents in client software. Once a Theora implementation becomes popular enough, companies will come after their patents.

If patents patents bug you, kill software patents!

Let's just add the possibility to embed videos in HTML, and have popularity decide. If you prefer Ogg, make sure that you offer Ogg.

Reply Score: 5

RE[2]: Open is a must
by nt_jerkface on Fri 26th Feb 2010 22:42 UTC in reply to "RE: Open is a must"
nt_jerkface Member since:
2009-08-26

MP3 is a good example of when software patents make sense. It was created in a lab with teams of engineers and the parties that funded the research deserved to be compensated. Intellectual property laws exist to create a market for this type of development where the product cost is in the R&D, not the duplication.

That being said as cheaper and viable codecs came along like WMA portable music companies were still obligated to pay the MP3 license due to its popularity. Everyone had music collections stored in MP3 and a lot of the music services only sold MP3. Sure you could convert your files or you could just pay 10 dollars more for an mp3 player and not have to mess with multiple formats.

So there is a legitimate concern with being locked into a commercial codec. An open source codec makes inclusion within hardware and software products much easier which in turn benefits consumers.

Edited 2010-02-26 22:45 UTC

Reply Score: 4

RE[3]: Open is a must
by iaefai on Sat 27th Feb 2010 01:58 UTC in reply to "RE[2]: Open is a must"
iaefai Member since:
2009-12-14

How long should that investment be protected, and what if that investment is not anything especially remarkable?

The current system has these sorts of issues.

Reply Score: 4

RE: Open is a must
by Fettarme H-Milch on Sun 28th Feb 2010 13:51 UTC in reply to "Open is a must"
Fettarme H-Milch Member since:
2010-02-16

H.264 is a dangerous path to walk, the MPEGLA hasn't removed the danger just delayed it by five years. We don't know what they'll do when the licensing terms come around again in 2016

In 2016 the next batch of h264 patents expire. Some patents already expired.

Reply Score: 2

Wrong conclusion..
by renox on Fri 26th Feb 2010 13:53 UTC
renox
Member since:
2005-07-06

Your conclusion "it takes experts to do this stuff." is quite flawed, sure if (say) YouTube choose a codec for its video, it'll be a team of experts who will select the best mode for the codec, but do you think that all the users which will encode video will hunt the latest codec in the branch foo?

Now they won't, they'll use the latest packaged codec with its default options: if Theora developers aren't able to provide a good packaged codec then Theora is (currently) truly inferior to other one which are properly packaged.

Reply Score: 4

Comment by Kroc
by Kroc on Fri 26th Feb 2010 14:11 UTC
Kroc
Member since:
2005-11-10

YouTube did not get where it is because it offered the best video quality...

In my own test (downloaded the PNG/FLAC data for 360p BigBuckBunny), Theora 1.1 was plenty good enough, just a hair short of H.264.

The next version of the Theora encoder appears equal, if not better than H.264.

What matters is the tools to work with Theora formats, and they're hardly great. The QT plugin is a year out of date and doesn't include Theora 1.1 meaning that individuals exporting using their regular tools on the Mac are not getting anything better than H.263. The QT plugin also provides too few options. You are almost forced to use the command line, and that's frustrating when you want to just get stuff done.

Reply Score: 4

RE: Comment by Kroc
by bnolsen on Fri 26th Feb 2010 15:13 UTC in reply to "Comment by Kroc"
bnolsen Member since:
2006-01-06

One test. A month ago I nplayed around with reencoding ben-hur from a 3GB xvid at 800x288. I used avidemux to encode h264/aac to 800MB (96kbps audio).

Then I used handbrake to do the same with theora/vorbis (again 96kbps audio).

The opening scene shows the nativity with the star surrounded by a thin halo travelling through the night sky over bethlehem, then shining a light beam down on the manger. The h264 encode the detail on the star is very acceptable.

The vorbis encode: the star moving through the sky is visibly blocky, the shining beam is also a block fest. Both the star affects actually "snap" into being sharp 3-5 seconds after being displayed. Other scenes with dark natural backgrounds have no detail, the are very blocky. I re encoded the vorbis to 1GB file, and although better, the star scene was still no match for the h264.

Reply Score: 3

RE[2]: Comment by Kroc
by Kroc on Fri 26th Feb 2010 15:29 UTC in reply to "RE: Comment by Kroc"
Kroc Member since:
2005-11-10

So you encoded from an already compressed source, and you’re complaining about quality? (And using Handbrake which has depreciated Theora support anyway and it’s massively out of date).

Sorry Mario, the princess is in another castle.

Reply Score: 5

RE[3]: Comment by Kroc
by DeadFishMan on Fri 26th Feb 2010 15:39 UTC in reply to "RE[2]: Comment by Kroc"
DeadFishMan Member since:
2006-01-09

So you encoded from an already compressed source, and you’re complaining about quality? (And using Handbrake which has depreciated Theora support anyway and it’s massively out of date).


I was thinking the same thing but it doesn't change the fact that H.264 performed better in his tests.

But nonetheless if Theora 1.1 is just slightly worse than H.264, I don't see why it can't be adopted as the reference standard codec for HTML5 video. Imagine the mess if HTML were in the same patent hell...

Reply Score: 4

RE[4]: Comment by Kroc
by darknexus on Fri 26th Feb 2010 16:36 UTC in reply to "RE[3]: Comment by Kroc"
darknexus Member since:
2008-07-15

I was thinking the same thing but it doesn't change the fact that H.264 performed better in his tests.


No, but it does call the validity of his test into question. If you use a current H.264 encoder versus an outdated Theora encoder, it's not surprising the results are skewed. It doesn't change the results of his test, but it does invalidate the test if you're going for a fair comparison.

Reply Score: 3

RE[5]: Comment by Kroc
by bnolsen on Fri 26th Feb 2010 17:31 UTC in reply to "RE[4]: Comment by Kroc"
bnolsen Member since:
2006-01-06

I built this handbrake myself from latest subversion sources. It absolutely uses theora 1.1 as the encoder. I used avidemux on the h264 because the default settings are more aggressive than handbrake's.

Comment about already compressed input:

A 3GB xvid at 800x288 is very high quality already (greater than 1400kbps). It's obvious to see the degradations to vorbis and far less degradation to h264.

I'll see about clipping out the small offending piece.

More information about my background: I'm totally against using h264 because of it's patent problems. However I'm not impressed with the theora folks IMHO over selling their technology.

Someone who doesn't have a dog in this fight, does encoding and lots of it should get lots of samples and do a thorough test. They should try to limit the subjectiveness.

Edited 2010-02-26 17:31 UTC

Reply Score: 3

RE[3]: Comment by Kroc
by memson on Fri 26th Feb 2010 15:41 UTC in reply to "RE[2]: Comment by Kroc"
memson Member since:
2006-01-01

Show me a source video uploaded to youtube, etc, that isn't already compressed.. you are completely missing the point. From the same source, the results must be similar to prove that the codec is an acceptable alternative. I concede that he might not have used a recent enough Theora encoder, but his results echo my own observations on Daily Motion. Theora under preforms on the same clip vs the H.264 version. I assume they are using the original source when re-encoding. If not, that in itself is another reason not use use Theora. You absolutely *must* re-encode from the same original source clip, else it negates everything.

Reply Score: 4

RE[4]: Comment by Kroc
by bnolsen on Fri 26th Feb 2010 18:27 UTC in reply to "RE[3]: Comment by Kroc"
bnolsen Member since:
2006-01-06

I've cut out just that scene and am playing with some encode settings. Sadly this *is* just a cherry picked scene and not a battery of tests. This type of encoding might be more difficult because the camera is slightly shaking left/right (probably not uncommon with these old movies).

I don't have a youtube account, any good suggestion of place to dump a <10MB file?

Edited 2010-02-26 18:45 UTC

Reply Score: 2

RE[5]: Comment by Kroc
by phoenix on Fri 26th Feb 2010 20:04 UTC in reply to "RE[4]: Comment by Kroc"
phoenix Member since:
2005-07-11

deleted

Edited 2010-02-26 20:05 UTC

Reply Score: 2

RE[3]: Comment by Kroc
by StephenBeDoper on Fri 26th Feb 2010 20:47 UTC in reply to "RE[2]: Comment by Kroc"
StephenBeDoper Member since:
2005-07-06

So you encoded from an already compressed source, and you’re complaining about quality?


Eh? If the input is the same, then why not compare the relative quality of the output?

Reply Score: 2

RE[4]: Comment by Kroc
by Kroc on Fri 26th Feb 2010 21:03 UTC in reply to "RE[3]: Comment by Kroc"
Kroc Member since:
2005-11-10

Because mathematically speaking, some codecs fare worse with certain inputs than others and the existing compression may be triggering off an algorithmic limitation of Theora. H.264 is equally susceptible to bad re-encodes and I’ve seen it make a mess of some videos based on the original encode.

His example is too narrow to be a fair test.

Reply Score: 1

RE[5]: Comment by Kroc
by StephenBeDoper on Fri 26th Feb 2010 22:03 UTC in reply to "RE[4]: Comment by Kroc"
StephenBeDoper Member since:
2005-07-06

Because mathematically speaking, some codecs fare worse with certain inputs than others and the existing compression may be triggering off an algorithmic limitation of Theora. H.264 is equally susceptible to bad re-encodes and I’ve seen it make a mess of some
videos based on the original encode.


Are those issues that occur when the source video is highly-compressed? I would think that, at that point, it would be difficult to distinguish those effects from plain old generation loss. At least (again, FWIW), I've never seen those issues when using high-bitrate source video.

A few weeks back, lemur2 mentioned the same thing in response to a post I'd made. Admittedly, I'd never heard that before, so I did some some quick tests with video files I had on hand. I used a 500MB DV file (SD) and a 175MB MPEG2 file (encoded from the DV file @ 35mbps) as the source files - then I encoded h.264 and Theora files from each of the two sources. FWIW, I couldn't see any appreciable difference (I can send you the URL of the test page, if you like - it even uses VFE).

His example is too narrow to be a fair test.


Yeah, just from a basic statistical standpoint, a single test is much too small a sample-size to draw wider conclusions from.

Reply Score: 3

does it?
by cocoliso on Fri 26th Feb 2010 14:31 UTC
cocoliso
Member since:
2005-11-26

does it have to be the best of the best?, i mean even if Theora isn't the best of all the encoders it is completely free and probably good enough, most videos on youtube look like crap anyway, there few HD videos that actually look good.

Reply Score: 3

Cobain
Member since:
2006-03-21

It is actually up to provider of the information what is best codec. It could be done by checking what codecs the client support, if the server does not support the codecs installed on the client it sends a "install right codec" message to the client.

Why should the browser hard code the codec? Some sites might want to broadcast live HD TV while others want to put on short clips in low quality, one codec does not suit all!

Edited 2010-02-26 14:59 UTC

Reply Score: 4

nt_jerkface Member since:
2009-08-26

Half the point of HTML5 video is so the browser can play basic video without having to install a codec, especially one that is wrapped up with all kinds of other crap that has nothing to do with playing videos.

Some old lady who occasionally watches pbs news video in sd shouldn't have to Flash; not just for convenience but also security reasons.

HTML5 + h.264 would still be an improvement over the current situation but I think Theora would be better choice for its flexibility.

Reply Score: 3

Bad comparison
by unavowed on Fri 26th Feb 2010 15:55 UTC
unavowed
Member since:
2006-03-23

The comparison is looking at the wrong criteria. *Everyone* knows that H264 is better than Theora, nobody disputes that.

The *only* problem with H264 is the patent licensing. Because of it, it's *impossible* for all browsers to implement H264; the problem is greatest in freely-licensed browsers where derivatives would not be covered by the patents even if the authors paid for a license (Firefox, Seamonkey, Chromium, Midori, etc).

If you consider this, that single problem disqualifies H264 *completely* as a codec to be used with HTML5 video. Currently, if you use it, only a minority of HTML5 video-supporting browser users will be able to view it, and you will *never* be able to support all your users.

This means that if there ever will be a codec that will work on all HTML5 video-supporting browsers, it will *not* be H264. The question is, what could it be instead? Currently the best candidate is Theora. The quality is worse than H264, but so long as it's good enough, it's acceptable. The most important feature of Theora is freedom from patent claims, maning that *all* browsers could implement it freely if the authors wanted to.

This does not mean that you should never host H264 content. You can always provide it as a first choice, and fall back to something that is universally supported.

The issue is, it would be nice if there were one codec that worked *everywhere*, making it easy for content publishers. As you can see, this *cannot* be H264. With what's currently available it *should* be Theora, until someone comes up with something better.

(edit: chromium, not chrome)

Edited 2010-02-26 15:56 UTC

Reply Score: 12

RE: Bad comparison
by Kroc on Fri 26th Feb 2010 15:59 UTC in reply to "Bad comparison"
Kroc Member since:
2005-11-10

The img tag supports multiple codecs, shouldn’t the video tag too?

If the img tag only supported the one format that was prevalent and patent-free at the time then we’d all still be viewing XBMs.

OGG is not the be all and end all of free formats, and that’s what most annoys me about the HTML5 spec. This insistence that a war _must_ be waged so that only one may win.

Reply Score: 5

RE[2]: Bad comparison
by Thom_Holwerda on Fri 26th Feb 2010 16:03 UTC in reply to "RE: Bad comparison"
Thom_Holwerda Member since:
2005-06-29

OGG is not the be all and end all of free formats, and that’s what most annoys me about the HTML5 spec. This insistence that a war _must_ be waged so that only one may win.


The difference is that every operating system can read jpeg, bmp, png, and so on, while not every operating system and/or browser can read the same video files.

Reply Score: 2

RE[3]: Bad comparison
by phoudoin on Fri 26th Feb 2010 16:26 UTC in reply to "RE[2]: Bad comparison"
phoudoin Member since:
2006-06-09

Legally, should have you added.

Which is the actual issue here. Anyone caring that much about best quality already knows that today internet bandwidth don't allow full HD best quality. The others, the largest set, can't really tell what a codec is...

Reply Score: 0

RE[3]: Bad comparison
by danieldk on Fri 26th Feb 2010 16:47 UTC in reply to "RE[2]: Bad comparison"
danieldk Member since:
2005-11-18

"OGG is not the be all and end all of free formats, and that’s what most annoys me about the HTML5 spec. This insistence that a war _must_ be waged so that only one may win.


The difference is that every operating system can read jpeg, bmp, png, and so on, while not every operating system and/or browser can read the same video files.
"

Are the days with proper PNG support in Internet Explorer (transparency!) so soon forgotten?

Reply Score: 5

RE[3]: Bad comparison
by memson on Fri 26th Feb 2010 17:25 UTC in reply to "RE[2]: Bad comparison"
memson Member since:
2006-01-01

Now maybe, not always. GIF used to not ship with a lot of browsers - BeOS for example, required a third party plug in for Net+. Until recently PNG was poorly supported in IE.

Edited 2010-02-26 17:28 UTC

Reply Score: 3

RE[4]: Bad comparison
by aliquis on Fri 26th Feb 2010 18:08 UTC in reply to "RE[3]: Bad comparison"
aliquis Member since:
2005-07-23

And the usage of png came from the patent issues with gif to or something such, didn't it? And still gif was more popular ..

I also assume many of the current web videos use audio encoded as mp3 which isn't open either.

Reply Score: 3

RE[3]: Bad comparison
by aliquis on Fri 26th Feb 2010 17:52 UTC in reply to "RE[2]: Bad comparison"
aliquis Member since:
2005-07-23

Bullshit. Back in the days not all OSes (or browsers?) could render PNG, and Internet Explorer for instance couldn't render transparent PNGs.

Worked just fine anyway.

Personally I think it should just be as local videos is, that is if you got the codec good, if not well then that's up to you to fix .. Just load the freaking video no matter what format.

There will most likely become a defacto standard that way anyway depending on what most people can see and encode with, and it will most likely be H264 no matter what ... Sure it may be sad for the Linux people who only want open stuff but then on the other side how many mac and Windows people got support for Theora in their OSes?

And who are the majority?

Reply Score: 1

RE[4]: Bad comparison
by darknexus on Fri 26th Feb 2010 18:11 UTC in reply to "RE[3]: Bad comparison"
darknexus Member since:
2008-07-15

if you got the codec good, if not well then that's up to you to fix


Great, we're back to 1999 again. And how many viruses are going to come with the codec packs this time? Doesn't anyone remember what it was like when we had codec hell to deal with?

Reply Score: 3

nt_jerkface Member since:
2009-08-26

codec installed successfully from ivancodecs.ru server.

thank you and have a nice day.

Edited 2010-02-26 22:49 UTC

Reply Score: 4

RE[5]: Bad comparison
by aliquis on Fri 26th Feb 2010 23:59 UTC in reply to "RE[4]: Bad comparison"
aliquis Member since:
2005-07-23

Troubles? Yes.
Viruses? No, not afaik.

Anyway, the people who knows anything would probably upload in H.264 so no-one would complain, the nerds in Theora just because they could and the people who don't know shit just in whatever format it already has, such as motion JPEG.

Reply Score: 2

RE[3]: Bad comparison
by cerbie on Sat 27th Feb 2010 01:49 UTC in reply to "RE[2]: Bad comparison"
cerbie Member since:
2006-01-02

Every operating system could not read all those image formats, back then they started getting used. Do you not recall browsers not loading PNGs, and Windows not having any included PNG viewer? I do.

They got to be ubiquitous because people were using them anyway, and that helped to create client demand.

Reply Score: 3

RE: Bad comparison
by Lennie on Sat 27th Feb 2010 00:45 UTC in reply to "Bad comparison"
Lennie Member since:
2007-09-22

"The most important feature of Theora is freedom from patent claims, maning that *all* browsers could implement it freely if the authors wanted to."

But they won't, Apple said, the will not add it to Safari. Although it's share isn't really big.

Reply Score: 2

RE[2]: Bad comparison
by larwilliams2 on Sat 27th Feb 2010 01:10 UTC in reply to "RE: Bad comparison"
larwilliams2 Member since:
2009-12-02

"The most important feature of Theora is freedom from patent claims, maning that *all* browsers could implement it freely if the authors wanted to."

But they won't, Apple said, the will not add it to Safari. Although it's share isn't really big.

Yes they will. They just need Theora to become popular and supported in the major browsers, then they have no choice by to support it.

Reply Score: 3

RE[3]: Bad comparison
by arpan on Sat 27th Feb 2010 04:14 UTC in reply to "RE[2]: Bad comparison"
arpan Member since:
2006-07-30

Unfortunately, reality is that h.264 has greater support since it is already supported in most browsers via Flash.

The same h.264 video can be played in Safari & Chrome using the video tag, and in all other browsers using Flash, and it can also be played on most smartphones including iPhone, Symbian and Android phones and I'm sure Windows Phone 7 will support it (since the Zune already does) etc.

Theora support is currently limited to Firefox, Chrome & Opera.

Something drastic needs to change for Theora to be supported in all browsers.

Reply Score: 2

RE[4]: Bad comparison
by darknexus on Sat 27th Feb 2010 04:31 UTC in reply to "RE[3]: Bad comparison"
darknexus Member since:
2008-07-15

Well, mandating it or another open codec for HTML 5 could very well qualify as that "something drastic."

Reply Score: 2

RE[2]: Bad comparison
by daveak on Sun 28th Feb 2010 11:37 UTC in reply to "RE: Bad comparison"
daveak Member since:
2008-12-29

Apple don't need to add it to Safari. All that is needed is a Quicktime codec and it works. Install the (outdated) Xiph codec on a mac now and Safari plays Theora vids just fine.

Reply Score: 1

RE[3]: Bad comparison
by StephenBeDoper on Sun 28th Feb 2010 19:08 UTC in reply to "RE[2]: Bad comparison"
StephenBeDoper Member since:
2005-07-06

Apple don't need to add it to Safari.


Except on the iPhone, iPod Touch, and iPad, where end users don't have the option of installing additional codecs.

Reply Score: 2

The differences are exaggerated
by StephenBeDoper on Fri 26th Feb 2010 16:06 UTC
StephenBeDoper
Member since:
2005-07-06

All things being equal (input source, encoding settings, etc), and at typical web video sizes/quality settings, I highly doubt that most users could tell the difference between h.264 video and even MPEG1 - let alone h.264 and Theora. Maybe the gulf widens at higher resolutions/quality settings, but the output of the two codecs is largely-indistinguishable for web video.

It also seems that the existing benchmarks focus mainly on technical analysis, which is interesting from a technical standpoint - but doesn't tell us much about real-world factors like subjective perception of visual quality. I think that some simple double-blind testing would give results that are much more relevant to real-world usage.

Reply Score: 2

RE: The differences are exaggerated
by aliquis on Fri 26th Feb 2010 17:55 UTC in reply to "The differences are exaggerated"
aliquis Member since:
2005-07-23

It's retarded to speak of "web video", things won't be as they are now forever. Hardware get more powerful, bandwidth wider, storage space cheaper and so on.

Youtube standard format looked like shit, forced high quality for the iPod way better and now they offer HD. Vimeo offered HD before that.

Consumer cameras used to record low-end 320x200, now kind of all of them record HD.

Only fools would keep on comparing freaking low-end images with no details between each others and say "omg I can't see much of a difference!", get some quality material and compare on that.


If shitty encoded low-bandwidth 320x200 is fine for you, then fine, keep it. Personally I've had 10/10 mbps bandwidth since 9 years ago and 100/10 mbps the last couple of years and I would definitly both upload and view HD content when given the option. So will everyone else, in some time.

Edited 2010-02-26 17:56 UTC

Reply Score: 1

StephenBeDoper Member since:
2005-07-06

It's retarded to speak of "web video", things won't be as they are now forever.


At the risk of stating (what should be) the obvious, going into "attack mode" and tossing out juvenile insults is not really the most persuasive way to present your argument.

It also doesn't help that your first sentence is both a non-sequitur AND a false dichotomy at the same time.
Increases in the quality of web video will not magically make it something other than web video. "Web video" is a colloquialism that merely describes the typical way video is used on the web. If, tomorrow, the typical web video settings became 3500kbps @ 1920x1080, it would still be web video.

Only fools would keep on comparing freaking low-end images with no details between each others and say "omg I can't see much of a difference!", get some quality material and compare on that.


In other words:

"I have observed that those who disagree with me on the next point tend to be unsophisticated, and those who quickly recognize the validity of the point to be more educated. The point is..." -The Guide to Conversational Terrorism

If shitty encoded low-bandwidth 320x200 is fine for you, then fine, keep it.


Why would you assume that I'm talking about 320x200 video? One, in 20 years I've never once encountered a video file with that resolution. Two, that's not a proper 16:9 or even 4:3 aspect ratio - perhaps you meant 320x240? And third, that's less than half the dimensions of typical videos even on youTube, which is generally considered to be the lowest common denominator as far as web video goes.

The last time I put a 320x240 video online, Bill Clinton was still the US president.

Personally I've had 10/10 mbps bandwidth since 9 years ago and 100/10 mbps the last couple of years and I would definitly both upload and view HD content when given the option. So will everyone else, in some time.


The key words being "in time." Even on the production side, there is still a large amount of SD content being professionally shot & produced. If you want to know why, just take a look at the price difference between Panasonic's DVX100B cameras, and their comparable HD cams.

Reply Score: 3

Kroc Member since:
2005-11-10

320x200 is the resolution of the Commodore 64 (in monochrome mode) ;)

Reply Score: 2

Chaos_One Member since:
2005-07-18

The Commodore 64 has all its 16 colors in 320x200 mode.

Reply Score: 1

aliquis Member since:
2005-07-23

Yeah dipshit but in this case it's obvious with "bla bla works ok for web video" means that it works ok for the low quality crap they currently watch, if not it wouldn't be necessary to add "web" to begin with.


Go look at a photo camera with video capability instead. People won't be shooting their clips with dedicated movie cameras, atleast not the huge majority of video clip uploaders, that is private persons.

Reply Locked Score: 1

StephenBeDoper Member since:
2005-07-06

Yeah dipshit


Classy. Maybe you should just go back to 4chan and leave technical discussions to the grownups.

but in this case it's obvious with "bla bla works ok for web video" means that it works ok for the low quality crap they currently watch


Too bad you have a ridiculously-outdated notion of what "web video" typically means, as you've already demonstrated

if not it wouldn't be necessary to add "web" to begin with.


I'd point out the tautological nature of that statement - but as you've displayed the maturity of a junior high schooler so far, I doubt you know what the word "tautology" means.

Go look at a photo camera with video capability instead. People won't be shooting their clips with dedicated movie cameras, atleast not the huge majority of video clip uploaders, that is private persons.


...so your contention is that, because amateur/consumer video is shot with lower-quality cameras, it should therefore be put online using higher-quality formats? Ever hear the old robot expression "does not compute"?

Reply Locked Score: 2

ugliness can be cured
by jabbotts on Fri 26th Feb 2010 16:30 UTC
jabbotts
Member since:
2007-09-06

An ugly person can have plastic surgery.
An ugly personality is much harder to change.

In like fashion, Theora can be improved and would evolve quickly if it got the focus of being the html5 prefered code. H.264 has it's ugly personality to contend with even if it is prettier; patents.

Relying on a patented and closed bit of code for something meant to be completely open and platform agnostic like the Internet is just madness. I say H.264's owners move the patent into the OSS patent partnership or bugger off with there "first hit is free" drugs.

Reply Score: 6

RE: ugliness can be cured
by StephenBeDoper on Fri 26th Feb 2010 20:54 UTC in reply to "ugliness can be cured"
StephenBeDoper Member since:
2005-07-06

An ugly person can have plastic surgery.
An ugly personality is much harder to change.


I've always like the way Winston Churchill put it:

"I may be drunk, but you, madame, are ugly! And in the morning, I shall be sober."

Reply Score: 2

RE[2]: ugliness can be cured
by jabbotts on Fri 26th Feb 2010 21:19 UTC in reply to "RE: ugliness can be cured"
jabbotts Member since:
2007-09-06

ha.. never can claim Mr Churchill didn't have a way with words (or a stick to carry when walking softly).

Reply Score: 2

picture
by evert on Fri 26th Feb 2010 17:27 UTC
evert
Member since:
2005-07-06
Open does not Mean Patent Free
by dindin on Fri 26th Feb 2010 17:27 UTC
dindin
Member since:
2006-03-29

I keep hearing people say that Theora is Patent Free. How do we know that? No one is suing because there is no monetary damage to prove or money to collect.

There are so many algorithms in video codecs, almost one part or another (especially new techniques like optimal bit coding, motion vector search mechansims, etc) are patented by many universities and companies. Microsoft had to go through this process when they tried to standardize VC-1 in SMPTE.

I personally would like to have both codecs supported and let the market decide based on needs, applications, cost, and quality. I am sure there is room for both.

Reply Score: 1

RE: Open does not - legality
by jabbotts on Fri 26th Feb 2010 19:16 UTC in reply to "Open does not Mean Patent Free"
jabbotts Member since:
2007-09-06

The best general outcome would be for the market to decide. The problem here is that we have patent issues to content with so large parts of the market are legally banned from being involved in that decision. This is like calling a diplomatic vote fair while discounting votes from women and minorities.

Reply Score: 4

Need Dirac and VP8 to.
by aliquis on Fri 26th Feb 2010 17:40 UTC
aliquis
Member since:
2005-07-23

See my comment title.

Also please both low-end such as 480x320 30 fps (320x240 is kinda lame now) and high-end say 1920x1080 60 fps.

Edited 2010-02-26 17:40 UTC

Reply Score: 3

RE: Need Dirac and VP8 to.
by PLan on Sat 27th Feb 2010 19:06 UTC in reply to "Need Dirac and VP8 to."
PLan Member since:
2006-01-10

Agreed. Talking about Theora and H.264 would be fine except that many people believe VP8 will be the 800lb gorilla if Google make it available to use on favourable terms.

Reply Score: 2

RE[2]: Need Dirac and VP8 to.
by lemur2 on Sun 28th Feb 2010 23:49 UTC in reply to "RE: Need Dirac and VP8 to."
lemur2 Member since:
2007-02-17

Agreed. Talking about Theora and H.264 would be fine except that many people believe VP8 will be the 800lb gorilla if Google make it available to use on favourable terms.


If we are talking about the future, the current development branch of Theora is called Ptalarbvorm (the previous development version which has now become Theora 1.1 the codename was Thusnelda). Weird names, I agree.

http://en.wikipedia.org/wiki/Theora

Like Thusnelda before it, Ptalarbvorm is optimisation of the Theora encoder only. Current Theora 1.1 players, such as the one embedded in Firefox 3.6, can play Ptalarbvorm-encoded Theora videos.

Anyway, the current experimental version of Ptalarbvorm is very promising, and initial results are finally getting better performance for Theora than h264 as currently used on the web. Theora Ptalarbvorm (experimental) at 376 kbit/s is approximately the same subjective quality as Youtube's current h264 implementation at 499 kbit/s.

If we are talking about the future, it may well not be either h264 or VP8 that yeilds the best performance for web video. It could well be the next version of the free and open Theora, already playable by current player software, that beats all comers.

Edited 2010-02-28 23:50 UTC

Reply Score: 2

RE[3]: Need Dirac and VP8 to.
by darknexus on Mon 1st Mar 2010 10:30 UTC in reply to "RE[2]: Need Dirac and VP8 to."
darknexus Member since:
2008-07-15

Very possible. To quote a well-known little green alien: "Always in motion, the future is." Don't forget though that other codecs are also going to be concentrating on improvements. This is as it should be. Don't expect the rest to stand still as Theora improves.

Reply Score: 2

RE[4]: Need Dirac and VP8 to.
by lemur2 on Mon 1st Mar 2010 10:51 UTC in reply to "RE[3]: Need Dirac and VP8 to."
lemur2 Member since:
2007-02-17

Very possible. To quote a well-known little green alien: "Always in motion, the future is." Don't forget though that other codecs are also going to be concentrating on improvements. This is as it should be. Don't expect the rest to stand still as Theora improves.


Well, Theora 1.0 was a fair way behind the state of play. To some extent, Theora carries some of that reputation still.

In Jan 2009, Mozilla funded a project to improve Theora. The resulting Thusnelda project began to achieve good results in October 2009, and the resulting release of Theora 1.1 had all but caught up to h264 as used over the web. This was a very significant improvement indeed.

It was achieved without having to change the format or update the player. Thusnelda was an improvement to the encoder only.

Now, the new Ptalarbvorm experimental branch is rumoured to be even more of a jump that Thusnelda was. It too is an improvement to the encoder only, involving no change to the format or the player. Existing Theora players will still work.

That is an incredible improvement in less than a year (after admittedly many years of not much improvement at all). It is amazing what a little bit of funding and support can achieve. Mind you, having said that, Theora was starting from a low standard in the first place, so it required a huge improvement to even catch up.

Meanwhile, h264 was "design by committee". Apparently there is a list of the patents involved, it is 47 pages long. To get the better performance out of h264 there is endless complexity involved, and much of it is of no use for delivery over the web anyway. I personally can't see any useable easy-to-achieve performance gains for h264 that haven't already been explored, but I could easily be wrong about that.

Edited 2010-03-01 10:54 UTC

Reply Score: 2

Comparison didn't use new Theora.
by stickster on Fri 26th Feb 2010 19:19 UTC
stickster
Member since:
2008-10-02

As pointed out in the comments, the KeyJ article didn't use Theora from the new development tip. I don't think that Theora developers contend it should beat x264 everywhere, but it's quite a bit more competitive that his article indicates. Naked eye test here shows as much:

http://people.xiph.org/~maikmerten/youtube/

Reply Score: 3

Blind test?
by stanbr on Fri 26th Feb 2010 19:49 UTC
stanbr
Member since:
2009-05-22

I think a blind test would be really cool. A bunch of videos using both encodeing head to head (at random location of the screen) and the user should pick witch one he thinks looks best. Check the results and you will have a fair winner. Of course the enconding should be done at the same conditions.

Reply Score: 2

RE: Blind test?
by mckill on Fri 26th Feb 2010 19:57 UTC in reply to "Blind test?"
mckill Member since:
2007-06-12

well except one of them will need a desktop or high end laptop to play while the other can be hardware decoded on just about anything.

Reply Score: 3

RE[2]: Blind test?
by darknexus on Fri 26th Feb 2010 20:47 UTC in reply to "RE: Blind test?"
darknexus Member since:
2008-07-15

Hardware will inevitably follow the demand. If a codec were mandated for HTML 5 and everyone began to use HTML 5 video, you can bet the hw companies would start producing hardware accelerator chips for that codec. To do otherwise would just be a bad business decision. We have a lot of h.264 hardware right now because that's where the trend was at the time, if the trend shifts the hardware will shift along with it. Remember when most devices expected Mpeg 4/DivX?

Reply Score: 2

RE[2]: Blind test?
by pgeorgi on Sat 27th Feb 2010 15:23 UTC in reply to "RE: Blind test?"
pgeorgi Member since:
2010-02-18

The ARM SoCs I work with have a codec accelerator subsystem. It's basically a coprocessor that you initialize with some opaque piece of (non-ARM) code, which does h.263, h.264 and VC1 decoding and encoding (to various degrees).

The total size of this driver (that you upload) is about 80KB, so I guess they'd have the space to add another codec in there (given that address spaces are usually in powers-of-two).

Once there's a demand, this coprocessor will gain an updated firmware (that is uploaded on boot), and supports whatever codec the demand is for.

I just looked for a number of ARM codec support options, and all I found are advertized with "Upgradeable with new codecs" and similar statements.

With that in mind, "hardware acceleration" is a non-issue for new contenders in video.
Other than with MP3 players which actually used special MP3 decoding chips, video decoding is too complex to be done "in silicon" - I'd guess it's always software.

Reply Score: 1

Comment by kvarbanov
by kvarbanov on Fri 26th Feb 2010 20:48 UTC
kvarbanov
Member since:
2008-06-16

I saw something about MP3, which someone says it's not open ? Of course it's not, but its license is slightly more forgiving than H264's. People, why you are comparing a piece of software that it's paid and one that's free and open source ? Hence, my question - if tomorrow HTML5 gets implemented by Google's Chrome and they want you to pay money to watch videos encoded with the H264 codes, will ya ? Personally I won't - I will want the same free video playback as it was with Flash. So, bottom line - H264 wants money - they don't care about where they will come from - the users or the provider.

Reply Score: 2

Something that should be mentioned.
by shadoweva09 on Fri 26th Feb 2010 20:56 UTC
shadoweva09
Member since:
2008-03-10

It's just like VHS versus Beta, you need to get the Porn sites to adopt it... Of course they would only adopt it if they are actually paying royalties in the first place. That's pretty much the only way Theora could ever take off.

Edited 2010-02-26 20:57 UTC

Reply Score: 1

nt_jerkface Member since:
2009-08-26

In this case YouTube is the equivalent of the porn industry.

Reply Score: 3

shadoweva09 Member since:
2008-03-10

No, I believe right now that there are no royalties if the content if free to end users, the porn sites do not fit this rule and therefore must pay royalties.

Reply Score: 1

nt_jerkface Member since:
2009-08-26

My point was that YouTube has the biggest hand to play.

Even if IE9 ships with a dozen codecs the only one that will matter will be the one that YouTube uses.

Web publishers are not going to keep video files in multiple codecs. Even if 80% of users have codec A installed it won't matter if YouTube uses codec B since B will have a higher install rate.

Reply Score: 3

shadoweva09 Member since:
2008-03-10

Youtube has no reason to change though, they could either spend money on a system that can do both, or reduce quality of already low quality video by re-encoding. Google's looked into it with their resources, the licensing terms for h264 being free for their use is set for more than a decade, Asking youtube to change over when there is no benefit to them is just a waste of time.

Also a bunch of talk is nothing compared to success stories, case studies, etc. that would be generated by smaller companies and Google might listen to those.

Reply Score: 1

popper
Member since:
2006-02-24

"All this illustrates two things: first, it takes experts to do this stuff. Video encoding is hard, with all those options and tweaks you can apply "

what you talking about ?

whats hard about clicking http://x264.nl/
downloading the current latest version there to your videos dir , opening a cmd and typing
x264.exe --help or
x264.exe --fullhelp

x264 -o output.mp4 input.whatever
or
x264 --crf=20 -o output.mp4 input.whatever

nothing thats what, and providing your actual input.whatever video file isnt totally shite to start with theres not any problem.

crf= a number between 18 and 26 Constant Quality rate is all you really need today.

if AVC/H.264 is good enough for your world cable/sat/terrestial and google providers etc, than x264 is good enough for you, and OC you have the advantage that current x264 AVC defaults are already set for high profile, auto level, quality settings so You dont have to set them.

google could tune to that 'high profile' higher quality too if they didnt have to downgrade their realtime x264 encoding backend to the lesser capable baseline etc only capable HW PMP's and phones etc to keep it simple for support.

if you really ,really cant do without a GUI then use this http://forum.doom9.org/showthread.php?t=151272
good as any

simples.

and dont forget to keep checking the http://x264.nl/ every other day sometimes as they are adding new and improved options to it all the time seriously.

Edited 2010-02-26 21:42 UTC

Reply Score: 2

Uhm, no.
by deathshadow on Fri 26th Feb 2010 21:25 UTC
deathshadow
Member since:
2005-07-12

we all want HTML5 video, and we all recognise it's a better approach than Flash for online video.


SPEAK FOR YOURSELF!

Honestly, declaring any one codec as what is 'officially supported' or the 'default' is complete and utter BULL, since again that defeats the entire point of HTML... Device and capability independence!

What codec is used in the tag should NOT be dictated or hard-coded into the damned browser. You want a codec supported, have a method for installing it (like say... a plugin) just like this existing tag which works JUST ***** FINE called 'object'.

OBJECT, which was supposed to replace IMG, APPLET and the proprietary IE 'EMBED' property!

But as I wrote in my "Why I hate HTML 5" rant
http://my.opera.com/deathshadow/blog/2010/01/09/why-i-hate-html5

That's a hefty part of my problem with the whole HTML5 video thing, is it shouldn't be a new tag and they are undoing ALL the progress STRICT doctypes were supposed to give us. They are adding all these new unnecessary tags to do things we can already do.

"We want to make audio and video easier" - so we ride the browser makers case about having object work right? **** no, instead we introduce two new tags undoing the POINT of STRICT (simpler code with less tags! Less code you use less there is to break) and then hardcode support for our pet project codecs instead of just CALLING WHATEVER CODECS ARE INSTALLED/AVAILABLE ON THE HOST OS!

Whiskey Tango Foxtrot!!!

Makes me want to bitch slap the people behind HTML5. Across the board it's all this unneccessary extra bullshit that results in MORE code, not less.

Take "NAV" for example - which by HTML5 you end up wrapping UL with like the retards who wrap DIV's around their UL's for no good reason... Here's an idea, how about instead of making a new tag to wrap your UL for god knows what reason, you undeprecate MENU, a tag that works just LIKE a UL with a semantic meaning on it - that way boom, browsers going back to HTML 2.0 would have support since it works JUST LIKE A UL. NO extra tags needed, no changes to the browser engines needed.

I guess that would be too easy.

Worse, most of the nimrods already churning out stuff in these DRAFT specifications, especially HTML5 are vomiting up the same crap they did when they didn't embrace strict - apparently simple ideas like only having a single H1 on a page, not skipping heading levels going down (I see one more H1 H5 pairing I'm gonna barf) images off graceful degradation, putting lists around lists (like say a pagination menu), and then they often STILL end up resorting to a div with a class on it inside tags like 'article' at which point what the hell was the point?

The saying when tables were abandoned for layout was that the people who made crappy endless nested tables for no good reason now just made crappy endless nested DIV for no good reason. Now I guess it's endless crappy extra allegedly semantic tags for no good reason.

More stuff changes, the more it stays the same.

Edited 2010-02-26 21:41 UTC

Reply Score: 2

RE: Uhm, no.
by daveak on Sun 28th Feb 2010 11:49 UTC in reply to "Uhm, no."
daveak Member since:
2008-12-29

Well said, although embed is Netscape isn't it?

The problem with object is of course that IE didn't implement it correctly and so we ended up with COM GUIDs being stuck in attributes to state the exact plugin that must be used instead of the mime type being used to decide how to deal with it.

This horrible mess is not going to go away either. Now instead of the ugly javascript to insert the appropriate tag, or the equally ugly object embed tag nesting we will now get video object embed nesting or yet more horrible javascript to handle things when we had a workable standard in HTML 4.0 back in 1997

Reply Score: 1

nt_jerkface
Member since:
2009-08-26

It isn't as if making Theora the default codec would forever ban h.264 from the web.

In the cases where publishers are selling streamed video they can require a plug-in like Netflix does with Silverlight.

It really seems to make more sense to have the default codec be license free for the flexibility and let people who want to stream 1080p video use a plug-in.

Reply Score: 4

HTML 5 Is faster than flash on loading
by silencer07 on Sat 27th Feb 2010 01:53 UTC
silencer07
Member since:
2010-02-27

I dont know but HTML5 Videos on youtube loads faster than flash videos. I am from third world country. My average download speed during peak hours is 30kbps

Reply Score: 3

Comment by cerbie
by cerbie on Sat 27th Feb 2010 02:16 UTC
cerbie
Member since:
2006-01-02

To further prove just how incredibly difficult this whole video encoding business is: Maxwell commented on Fiedler's benchmark, and together they found out that Fiedler was using the wrong Theora branch, which negatively affected Theora's performance. It turns out that the branching scheme for Theora isn't particularly intuitive.
Getting the most out of a given codec aught to take some work, and that's fine. But, if getting good results takes more than a, "-vcodec theora" added to the ffmpeg command line, then it has a very long way to go. H.264 is there, and does a good job. A two-pass encode, with fairly basic options, works great with both ffmepg and mencoder. If you even have to know about the existence of dev/release branches of the software, it is, at best, beta quality. That is on top of screenshots showing the same things I've found, myself: that the differences are not actually subtle, authors of the comparisons just want to push Theora, so they say that.

I don't like the possible royalties-after-X-years hanging over H.264, but Theora does not look ready for prime time.

Theora can be the best web format (for that, it dies not need the video quality performance of H.264), but it needs usability first and foremost, with sensible defaults for good quality all-around. If the current stable Theora included for 3rd-party encoders/transcoders is not good enough, then Theora, as a whole, is not good enough. The version that matters is the one I get from the stable repo with my package manager (Linux), or with the stable version installer (Windows). That, in itself, is a major part of usability that many FOSS projects don't think about.

I think it's silly to dictate a single format for HTML 5 video. While I don't have the quite the vitriol, I generally agree with deathsadow. But, if you want Theora to succeed, you should change its development process and goals. All the talk about needing to mess with what should be minor details tells me that Theora is currently broken, regardless of its potential, or of version XYZ's performance. If Theora XYZ (or better) is not in every stable repo of every popular desktop Linux distro, and every popular Windows transcoding package, it is completely irrelevant. H.264 has had that bit taken care of for at least two years, now. If the Theroa devs and maintainers do not make that their number 1 priority, Theora will not be ready for prime time for years to come. I don't care if they move to an always-in-dev system like ffmpeg, or a merge-stable-stuff-every-few-months like LLVM, but they need to make it where Theora is Theora is Theora, and everyone's Theora is not too far behind the most advanced development versions.

Edited 2010-02-27 02:25 UTC

Reply Score: 2

RE: Comment by cerbie
by nt_jerkface on Sat 27th Feb 2010 06:50 UTC in reply to "Comment by cerbie"
nt_jerkface Member since:
2009-08-26

I think it's silly to dictate a single format for HTML 5 video.


It's called setting a standard for publishers to depend on and browsers to follow.

Multiple codecs will just result in Flash being used.

What I think is silly is that people have forgotten that HTML5 Video was supposed to rid the web of Flash for basic video.

With multiple browsers supporting multiple codecs web publishers will look towards Flash as way of avoiding competing codecs. Flash would once again win by default (cue back to the future theme song).

Reply Score: 2

RE[2]: Comment by cerbie
by cerbie on Sat 27th Feb 2010 07:54 UTC in reply to "RE: Comment by cerbie"
cerbie Member since:
2006-01-02

It's called setting a standard for publishers to depend on and browsers to follow.
Which is a major change in direction for the web, and a good way to get this long-term tug of war going on. It's a pissing contest, pure and simple, and undermines the web's history as much as the byzantine modular XML ideas did (which is kind of sad, as XHTML was one of the few excellent uses of XML, IMO).

A codec that can be freely used, with no risk of licensing costs, is the only viable option, if there is going to be one codec in the standard. It's not really much of a choice. H.264 is a non-option. It can be allowed, but without a properly free option as an alternative, it is not a truly open standard, and, once again, this all becomes a MPEG LA v. freetards pissing contest, with no work being done. In this scenario, the freetard side is way more correct than they are wrong.

I contend Theora is not ready, but that is point for H.264 v. Theora quality and performance comparisons. For standards, it is not valid: whatever is chosen, H.264 cannot be it, unless there are clear licensing terms that exempt at least an overwhelming majority of uses involving the web, in perpetuity. "We're not going to do anything for a few years, but after that, we could change our minds," is simply not acceptable.

Edited 2010-02-27 07:57 UTC

Reply Score: 3

RE[3]: Comment by cerbie
by deathshadow on Sun 28th Feb 2010 03:01 UTC in reply to "RE[2]: Comment by cerbie"
deathshadow Member since:
2005-07-12

if there is going to be one codec in the standard.

Which is why there SHOULD NOT BE a codec defined as part of the standard.

Device neutrality, plugin neutrality - the HTML specification should not say one way or the other what codecs are valid, invalid or even default. JUST as it does NOT say how much larger a H1 should be compared to normal text, what the default text size should be, etc, etc...

Reply Score: 2

Is it so hard to support two codecs?
by transami on Sat 27th Feb 2010 02:36 UTC
transami
Member since:
2006-02-28

Doh!

Reply Score: 1

Versioning...
by tomcat on Sat 27th Feb 2010 05:55 UTC
tomcat
Member since:
2006-01-06

I'm actually less concerned about the choice of a standard codec now than I am about how we move forward, beyond the standard one. Because, obviously, video technology is going to advance, and we're not going to want to use H264 or Theora forever. So, no matter how you slice it, we have to understand and get the versioning story for video codecs right before we make any choice.

Reply Score: 2

RE: Versioning...
by deathshadow on Sun 28th Feb 2010 02:29 UTC in reply to "Versioning..."
deathshadow Member since:
2005-07-12

I'm actually less concerned about the choice of a standard codec now than I am about how we move forward

Exactly why there should be no 'default' codec, and it should use the codecs installed on the host OS. Then people could have the CHOICE... You know - what freedom REALLY means.

GOD FORBID. But don't look for freedom of choice from the FLOSS zealots who want to shove their choice down everyone's throat.

Reply Score: 2

RE[2]: Versioning...
by ba1l on Sun 28th Feb 2010 11:57 UTC in reply to "RE: Versioning..."
ba1l Member since:
2007-09-08

Exactly why there should be no 'default' codec, and it should use the codecs installed on the host OS. Then people could have the CHOICE... You know - what freedom REALLY means.


No, that won't work.

First, support for h.264 is far from universal. Most notably, neither Windows XP nor Windows Vista include an h.264 codec. Installable h.264 codecs for these systems are either commercial (the end user has to pay for them) or, thanks to software patents, not legally distributable in the US.

If web browsers only supported video codecs that were installed on the system, anyone providing HTML5 video would need to provide it in h.264 (Mac OS X, Windows 7) and WMV (Windows XP, Vista) formats, at minimum.

You need a baseline codec - something that you can rely on being there.

Second, what about other platforms? There are no (licensed) h.264 codecs for Linux systems, or for pretty much any embedded OS. Many embedded systems (think phones, PDAs, set-top boxes) do not have their own video codecs at all, so portable web browsers (everything except IE) would have to include their own codecs anyway.

Third, not all h.264 codecs are equivalent. Some support all base profile and high profile features. Others support only base profile. Others support base profile, and bits of high profile (but usually not the same bits). How can you fix a problem with the web browser not displaying a video correctly, when it's the fault of the OS?

Fourth - security. Video codecs are not built with security in mind. What happens when a security vulnerability is discovered in the system codec? Any web browsers running on that platform are vulnerable until the codec provider updates the codec, and they won't be able to do anything about it.

Reply Score: 2

RE[3]: Versioning...
by deathshadow on Tue 2nd Mar 2010 08:51 UTC in reply to "RE[2]: Versioning..."
deathshadow Member since:
2005-07-12

First, support for h.264 is far from universal. Most notably, neither Windows XP nor Windows Vista include an h.264 codec.

Unless you upgrade to the latest DirectX. It's in the damned DXVA spec for DX9!

Installable h.264 codecs for these systems are either commercial (the end user has to pay for them)

Oh you mean like Flash Player 10 - oh wait, you don't have to pay for that, and it does H.264... at least for playback... and anyone doing video generation as anything more than a hobbyist isn't going to bat an eyelash at paying pennies on the video when they drop over a grand on CS4 suite (or $800 JUST for Premier), a grand for Final Cut Studio, and three or four grand on the Apple to run them on.

Besides, SEE YOUTUBE. They don't seem to have any problem using h.264 via flash or HTML5... So that's pure FUD.

or, thanks to software patents, not legally distributable in the US.

For free - god forbid anyone try to pay their coders.

If web browsers only supported video codecs that were installed on the system, anyone providing HTML5 video would need to provide it in h.264 (Mac OS X, Windows 7) and WMV (Windows XP, Vista) formats, at minimum.

Or use flash which works on both those platforms and many others. Much less I don't know where you are getting that it's not available on XP or Vista since it's part of most every directX upgrader.

**** sake my PSP can manage H.264, half the damned MP4 players in pipe have hardware level H.264 decoder chips now.

You need a baseline codec - something that you can rely on being there.

There are no (licensed) h.264 codecs for Linux systems

... and yet VLC seems to play them just fine. Flash seems to play them just fine.

Many embedded systems (think phones, PDAs, set-top boxes) do not have their own video codecs at all, so portable web browsers (everything except IE) would have to include their own codecs anyway.

Hmm... My PSP does it. If a six year old game console can manage it out of the box... REAL companies like Sony aren't going to have slightest problem PAYING for including something - it's what they're in business to do so why the hell would they listen to the FLOSS fringe whackos with their rabid 'corporations are evil' malarkey.

How can you fix a problem with the web browser not displaying a video correctly, when it's the fault of the OS?
Fix the damned OS.

Fourth - security. Video codecs are not built with security in mind. What happens when a security vulnerability is discovered in the system codec? Any web browsers running on that platform are vulnerable until the codec provider updates the codec, and they won't be able to do anything about it.

Now that on the other hand is a valid concern - but it shouldn't be ANY concern of the browser makers as if there's that much interaction between the codec and the browser, they didn't sandbox their plugins very well.

Something Google determined they wanted from day one on their browser.

The anti H.264 retoric screams of the same 'down with the evil corporations' bullshit as all of the FSF's outright lies. People expect to be paid for work - people who can do the same thing often get together to form corporations or work for them. Corporations who make products that people buy typically expect to be paid for their products so they can pay their employees, pay for the resources, so everybody is happy.

This naive pipedream dirty hippy bull about everything being 'open'...

Reply Score: 2

RE[4]: Versioning...
by lemur2 on Wed 3rd Mar 2010 01:56 UTC in reply to "RE[3]: Versioning..."
lemur2 Member since:
2007-02-17

For free - god forbid anyone try to pay their coders.


The coders of h.264 have been paid ... years ago.

The anti H.264 retoric screams of the same 'down with the evil corporations' bullshit as all of the FSF's outright lies. People expect to be paid for work - people who can do the same thing often get together to form corporations or work for them. Corporations who make products that people buy typically expect to be paid for their products so they can pay their employees, pay for the resources, so everybody is happy. This naive pipedream dirty hippy bull about everything being 'open'...


The coders have been paid years ago. Development costs of h.264 can't have been more than a few tens of millions. Ongoing royalties being collected worldwide would amount to several times that per year. ROI would have been over 100% in the first year, and pure gravy (since there is virtually zero ongoing investment) every year after that.

You know, when I purchase a TV, once I have paid for it, it is mine. The makers of the TV may well have embedded some patented technology in the TV's design, but despite that fact they still don't ask me for an ongoing fee every time I watch the TV.

Reply Score: 2

RE[2]: Versioning...
by ichi on Sun 28th Feb 2010 17:07 UTC in reply to "RE: Versioning..."
ichi Member since:
2007-03-06

Exactly why there should be no 'default' codec, and it should use the codecs installed on the host OS. Then people could have the CHOICE... You know - what freedom REALLY means.


But can't we have both?

Like, a default open codec implemented in the browser (theora, dirac or whatever, as long as it's royalty free and implementable on every platform), and then the possibility of using other codecs available on the OS?

You would then have both the freedom of streaming your videos on any codec you see fit, and the possibility of using a codec that you can be sure will be available on absolutely every platform.

Reply Score: 1

RE[3]: Versioning...
by StephenBeDoper on Sun 28th Feb 2010 19:47 UTC in reply to "RE[2]: Versioning..."
StephenBeDoper Member since:
2005-07-06

But can't we have both?

Like, a default open codec implemented in the browser (theora, dirac or whatever, as long as it's royalty free and implementable on every platform), and then the possibility of using other codecs available on the OS?

You would then have both the freedom of streaming your videos on any codec you see fit, and the possibility of using a codec that you can be sure will be available on absolutely every platform.


Agreed. While I understand the objections to completely deferring video decoding to DirectShow/QuickTime/GStreamer, it would be nice if they could still fallback when the browser doesn't have built-in support for a particular video format.

Reply Score: 2

v Trolls comment
by Karitku on Sat 27th Feb 2010 19:52 UTC
H.264 doesn't specify encoder
by _h4m_ on Mon 1st Mar 2010 14:26 UTC
_h4m_
Member since:
2010-03-01

When you talk about H.264 you should be aware that the specification is only about the input stream of the DECODER. This means that the encoder is left mostly open to various implementations.

So when you compare H.264 to other algorithms you are only comparing one possible implementation of it. There are all kinds of links to benchmarks and stuff, but they don't actually tell you anything if you don't know what encoder and what Qp value was used.

And also if some algorithm performs better than some version of H.264 encoder, it is practically always possible to write even better version of H.264 encoder. I'm not sure about other algorithms but when you do better encoder for H.264 you don't need to change the decoder at all.

Reply Score: 1