●Stories
●Firehose
●All
●Popular
●Polls
●Software
●Thought Leadership
Submit
●
Login
●or
●
Sign up
●Topics:
●Devices
●Build
●Entertainment
●Technology
●Open Source
●Science
●YRO
●Follow us:
●RSS
●Facebook
●LinkedIn
●Twitter
●
Youtube
●
Mastodon
●Bluesky
Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!
Forgot your password?
Close
This discussion has been archived.
No new comments can be posted.
Load All Comments
Full
Abbreviated
Hidden
/Sea
Score:
5
4
3
2
1
0
-1
More
Login
Forgot your password?
Close
Close
Log In/Create an Account
●
All
●
Insightful
●
Informative
●
Interesting
●
Funny
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
bykindbud ( 90044 ) writes:
Really? Why does the HTML5 spec care what codecs are used? Why doesn't it just provide a way to specify which codec the author used to encode the media file, and let the browser prompt the user to get it if needed?
twitter
facebook
bycastironpigeon ( 1056188 ) writes:
There can be only one!
byV!NCENT ( 1105021 ) writes:
One <video> to rule them all and in darkness bind them!
byCurate ( 783077 ) writes:
Indeed, as was done for pictures using the tag. HTML didn't specify a particular file format. You could use .bmp, .ico, .gif, .jpg, etc. Why on Earth would you WANT to standardize on a particular file format and lose that flexibility? Better file formats will show up over time and certainly you'd like to be able to use tem. The good formats will stick and become de facto standards. The not so good formats will fall by the wayside.
byJCSoRocks ( 1142053 ) writes:
Because you end up with the craptastic situation like IE6 where they sort of support PNG but not really because they don't support transparency. If there isn't universal browser support for a format it might as well not even exist / be an option because you can't use it. If you have to code for IE6 you can't use transparent PNGs can you? So what difference does it make that you can "use any format?"
If we go this route with video what options are left? Stick with flash? Encode everything in two different codecs and *hope* that the browsers all support one of the two? I don't know about you but I think those options suck.
Parent
twitter
facebook
byweicco ( 645927 ) writes:
Img-tag doesn't specify which image formats you must or must not use so I really don't understand why video-tag should be any different. Video-tag could just instruct the browser that "put the video in here and fetch stream from here or if user has no ability to play the video display whatever is inside the alt-attribute".
So when browser sees video-tag it renders it by using which ever video plugin or built-in mechanism is in use, be it Flash, Silverlight, Windows Media Player or whatever. Then it is up to
byRonald Dumsfeld ( 723277 ) writes:
No, you don't know much about video codecs - or the browser wars.
The huge headache everyone wants to avoid is content providers having to code around, and store duplicate copies of video, to cater to all the browsers.
This is before you get into all the bullshit about codecs that are really rootkits and the like. You do not want your browser saying, "I cannot cope with the computationally intensive task to render this video without 'magic software' from goatse.cx".
byJCSoRocks ( 1142053 ) writes:
The huge headache everyone wants to avoid is content providers having to code around, and store duplicate copies of video, to cater to all the browsers.
My point exactly.
Besides, WTF is the point of a standard if the people making the standard are just following whatever the browsers are already doing? Why even bother pretending like we've got a standard that everyone follows?
byweicco ( 645927 ) writes:
You are probably right but still it doesn't sound good. I've always thought that versatility is acknoledged to be a good thing. Now everyone is tied up to a single video codec. What happens to the development? Is it held back like at the time when it was said that IE was holding back the WWW (because of the lack of competition)? Or do we open up the spec when there's a better codec around? As a programmer, this is what I detest, changing the spec ;)
byrhizome ( 115711 ) writes:
If we go this route with video what options are left? Stick with flash? Encode everything in two different codecs and *hope* that the browsers all support one of the two? I don't know about you but I think those options suck.
Isn't that the way browser quirks have been dealt with so far? I don't think it's the role of the HTML5 spec to solve that problem, of differences between browser implementations. I don't say this very often, but let the market decide.
byFwonkas ( 11539 ) * writes:
If you have to code for IE6 you can't use transparent PNGs can you?
You can [google.com] -- it's just inconvenient.
bykindbud ( 90044 ) writes:
If you have to code for IE6 you can't use transparent PNGs can you?
Sure you can. If web coders used trasparent PNGs, that'd make the web look craptastic for IE6 users, and so they'd ditch their crappy browser for one that works better (or they'd just get used to a crappy-looking web, just like we've all gotten used to slashdot). Instead of making sure users knew that IE6 was a load of crap, web designers instead hid the defects and prolonged the life of IE6. You have only yourselves to blame for the IE6
byJCSoRocks ( 1142053 ) writes:
90% of users aren't going to know the difference between a browser problem and a site problem. They'll just assume your site looks like crap. Devs have no choice but to program around these problems - Just like we do with Javascript and CSS issues and everything else. It turns into a huge waste of time, energy and storage space. Video will only make it worse.
It's 2009 and we still have to program around browser differences and quirks. Doesn't that seem a bit ridiculous? If everything is going to be web ba
bykindbud ( 90044 ) writes:
It's 2009 and we still have to program around browser differences and quirks. Doesn't that seem a bit ridiculous?
Of course. It's 2009 and we still have to program around OS differences and distro quirks. Why doesn't that seem just as ridiculous?
If everything is going to be web based for the next 20 or 30 or however many years don't you think we should fix that?
By locking us into a codec that may be obsolete in 5 years? No.
byshutdown -p now ( 807394 ) writes:
The fear is that the "good format" in this case will be H.264, and once it will stick and become de facto standard, we'll have the same mess as with GIF all over again - since FOSS browsers won't be able to support it legally (at least in U.S.), nor free content creation/editing tools.
Parent
twitter
facebook
byFlammon ( 4726 ) writes:
Absolutely and it would set a terrible precedent. It's one way of making a free web a non-free web.
Mod parent up.
bydangitman ( 862676 ) writes:
since FOSS browsers won't be able to support it legally (at least in U.S.), nor free content creation/editing tools.
I don't see why FOSS browsers couldn't do it legally. It seems that what you actually mean is GPL licensed browsers couldn't do it. But there is more to FOSS than just the GPL, and there are plenty of other less-restrictive FOSS licenses out there.
byshutdown -p now ( 807394 ) writes:
It seems that what you actually mean is GPL licensed browsers couldn't do it. But there is more to FOSS than just the GPL, and there are plenty of other less-restrictive FOSS licenses out there.
It depends. One could argue that code distributed under BSDL or a similar license, which would induce patent infringement by downstream users should they try to redistribute it, is not truly FOSS. I'm not at all a GPL zealot, but I can certainly understand that viewpoint.
In any case, a more practical take on this is: are there any good browsers and/or rendering engines that are not under GPL, LGPL, or similar licenses?
bydangitman ( 862676 ) writes:
One could argue that code distributed under BSDL or a similar license, which would induce patent infringement by downstream users should they try to redistribute it, is not truly FOSS.
One could argue that, but it would be a very strange and nonsensical argument, as such licenses are actually freer than the GPL. So, you'd have to twist the meaning of "free" in any attempt to make that argument.
In any case, a more practical take on this is: are there any good browsers and/or rendering engines that are not under GPL, LGPL, or similar licenses?
WebKit is BSD licensed, is widely used, and considered one of the best rendering engines around.
Anyway, is there any need for a GPL browser to actually redistribute the proprietary code? Couldn't they simply ship without the code, and have the user install it as a plug-in, whether it be an officiall
byshutdown -p now ( 807394 ) writes:
One could argue that, but it would be a very strange and nonsensical argument, as such licenses are actually freer than the GPL. So, you'd have to twist the meaning of "free" in any attempt to make that argument.
I use the FSF definition of "Free", since it seems to be the norm in such contexts, especially on Slashdot. In any case, it was not an attempt to POV-push on my behalf (I'm not particularly fond of GPL, and I write proprietary closed-source software for a living, so my agenda, if anything, is quite opposite).
WebKit is BSD licensed, is widely used, and considered one of the best rendering engines around.
In practice it is not [apple.com]. WebKit "as a whole" is under BSDL, but its major consistuent components, specifically WebCore (the renderer) and JavaScriptCore are under LGPL. This makes perfect sense if you re
bydangitman ( 862676 ) writes:
This would effectively mean that no "true FOSS" implementation could legally support HTML5.
Only on Linux though. On Windows or MacOS, they both have media frameworks that have legally licensed support for H.264. I don't see why, say, Firefox couldn't use those frameworks on those platforms.
byshutdown -p now ( 807394 ) writes:
Only on Linux though.
You realize that your comment probably counts as flamebait on Slashdot, right? ;)
● current threshold.
bythedonger ( 1317951 ) writes:
Really? Why does the HTML5 spec care what codecs are used? Why doesn't it just provide a way to specify which codec the author used to encode the media file, and let the browser prompt the user to get it if needed?
I get the feeling there is a growing trend towards never needing to ask user input on anything. User interfaces are expected to be completely intuitive and perfectly accessible. There is no room for requiring people to read instructions of any kind.
I do some UI design at work, and I frequently find myself in a tug-of-war with a colleague because he thinks users should be able to do anything and that everything they need to do should be completely intuitive. Ask five random people and you'd be lucky to have
byevilviper ( 135110 ) writes:
Why doesn't it just provide a way to specify which codec the author used to encode the media file, and let the browser prompt the user to get it if needed?
"Mozilla strongly opposes this approach because it would heighten the risk of fragmentation. Allowing content providers to use any codec that is available on the user's computer might undermine the advantages of the HTML 5 media element because there would be no consistency guarantee and content would not be able to work everywhere."
You'll NEVER GUESS whe
bymuuh-gnu ( 894733 ) writes:
> Why does the HTML5 spec care what codecs are used?
You somehow missed the whole discussion, didnt you? If a spec shouldnt care in what way content is encoded it is trying to show, what _should_ it actually care about?
> Why doesn't it just provide a way to specify which codec the author used to encode the
> media file, and let the browser prompt the user to get it if needed?
And where should a free browser get a patented and thus non-free codec from? Or did you actually mean that a free browser shoul
byAnyoneEB ( 574727 ) writes:
Yeah, no problems at all [wikipedia.org]...
byjedidiah ( 1196 ) writes:
> And where should a free browser get a patented and thus non-free codec from?
The same place you would expect it to get ANY decoder capability from: the operating system.
Either the OS would provide it directly or some 3rd party would.
The idea that the "burden" of dealing with h264 is on Mozilla is just a big red herring.
Decoding a video mime type today doesn't create that burden so there's no good reason to
expect it to in the future.
The people behind Mozilla just want to manufacture a "need" to push Ogg.
byTheSunborn ( 68004 ) writes:
Yes but what should the Mozilla developers do when they run on a system such as Linux which can't legally support H.264 in USA and other parts of the world?
Should they just do a "Not support, please install Windows?"
byharlows_monkeys ( 106428 ) writes:
Yes but what should the Mozilla developers do when they run on a system such as Linux which can't legally support H.264 in USA and other parts of the world?
Specifying Ogg for HTML5 doesn't get rid of that problem, as it is beyond the scope of the HTML5 spec to require that the people putting videos up on the web use Ogg. Google will continue to use H.264 for bandwidth and quality reasons, and Apple will continue to use H.264 for performance reasons.
Mozilla will simply continue doing what they do now when they encounter H.264 video on Linux--play it using one of the readily available H.264 codecs commonly found on Linux systems. Whether or not that codec is leg
byLisandro ( 799651 ) writes:
> Why does the HTML5 spec care what codecs are used?
You somehow missed the whole discussion, didnt you? If a spec shouldnt care in what way content is encoded it is trying to show, what _should_ it actually care about?
Provide means to play and interact with the content? How is this any different from the IMG tag and multiple image formats? The only difference here is that video a degree of interaction a fixed image does not have (controls, position slider, etc).
Why does the standart limits to one video f
bykoiransuklaa ( 1502579 ) writes:
Why does the standart limits to one video format is completely beyond me.
Oh please. Content providers and browsers would be totally free to support any craptacular codecs they want, there would just be one that would be guaranteed to work on HTML5 compliant browsers and sites. How can this be so hard to understand?
bysaturn_vk ( 1198069 ) writes:
and why should browsers even supply codecs? why not just use whatever framework is available from the OS. IIRC, the gtk webkit port uses gstreamer for video support, so it probably can handle quite a few codecs apart from theora and h264
●our current threshold.
byclone53421 ( 1310749 ) writes:
At present, any time I'm surfing the Web and I get a popup telling me "You need to install 'X' to view this video", I assume it's a virus. I'd actually prefer to keep it that way... it's simple, at least.
Parent
twitter
facebook
bykindbud ( 90044 ) writes:
Me too. So what? If you have a H.264 codec and an Ogg codec already installed, it won't prompt you for those. How many online vids have you watched recently that weren't in one of those formats?
Is that really a problem for any site that uses common video formats? People should be suspicious of new codecs.
byDragonWriter ( 970822 ) writes:
Really? Why does the HTML5 spec care what codecs are used?
It cares because if there isn't a mandatory-supported codec in the spec, you can't provide content encoded in one codec and no that any HTML5-compliant browser will be able to deal with it. Since the big point of HTML5 is expanding the kinds of rich applicationst that can be built with complete portability between standards-compliant browsers, that's a pretty big deal.
Why doesn't it just provide a way to specify which codec the author used to encode
bykindbud ( 90044 ) writes:
It cares because if there isn't a mandatory-supported codec in the spec, you can't provide content encoded in one codec and no that any HTML5-compliant browser will be able to deal with it.
You still can't know that the browser will be able to deal with it. The browser could lie about its capabilities. The user could have disabled video support in the configuration. The user could be surfing through a proxy that renders the video tag inert. There are a zillion reasons why content won't render the way the
byDragonWriter ( 970822 ) writes:
You still can't know that the browser will be able to deal with it. The browser could lie about its capabilities. The user could have disabled video support in the configuration. The user could be surfing through a proxy that renders the video tag inert.
If the browser is lying, it isn't an HTML5-compliant browser; if the user chooses not to allow video (or chooses to access the internet through a pathway that selectively filters video) that's outside of the scope of problem the spec is seeking to deal with.
bykindbud ( 90044 ) writes:
If the browser is lying, it isn't an HTML5-compliant browser;
That won't stop the know-nothing end user from bitching at the website author because their "internet TV don't work." That's the reason you gave for wanting the codec in the spec, so the user won't whine at the site maintainers when it doesn't work. If that's the goal, it failed before it started.
byDragonWriter ( 970822 ) writes:
That won't stop the know-nothing end user from bitching at the website author
Maybe, but browsers that don't comply with the spec aren't within the scope of what the spec is attempting to address.
bymaxume ( 22995 ) writes:
This attitude was a debacle for video plug-ins using the object tag.
The idea is that if a small time content creator uses the universally supported codec, they don't get ranty email complaining that the television on their computer thingy be broke.
bykindbud ( 90044 ) writes:
The idea is that if a small time content creator uses the universally supported codec, they don't get ranty email complaining that the television on their computer thingy be broke.
You really think this is about the small-time content creator? What makes you think so? Is it all the small-time content creators who have a place at the standards-setting table, who are ethusiastically embracing patented and licenseable codecs being made mandatory by the big players? Really?
bymaxume ( 22995 ) writes:
Wait, which codec is mandatory right now?
I can't think of any other reason to put a fallback codec in the standard, a site like Youtube will have the resources to support any codec they want.
byBitZtream ( 692029 ) writes:
Cause then we'd just have a tag like OBJECT but specific to video.
So ... you're right, lets make ActiveX standard for all browsers, thats a great idea! Thats essentially what you're saying. The only difference is it would be 'for video', and of course by 'for video' I mean 'just as dangerous and capable of doing whatever it wants as ActiveX.
You specify a codec and in order for a browser to be HTML5 compliant it has to support a specific video codec, which means that a web developer can produce a specific
There may be more comments in this discussion. Without JavaScript enabled, you might want to turn on Classic Discussion System in your preferences instead.
Slashdot
●
●
Submit Story
It is much harder to find a job than to keep one.
●FAQ
●Story Archive
●Hall of Fame
●Advertising
●Terms
●Privacy Statement
●About
●Feedback
●Mobile View
●Blog
Do Not Sell or Share My Personal Information
Copyright © 2026 Slashdot Media. All Rights Reserved.
×
Close
Working...
Working...