●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
Slashdot is powered by your submissions, so send in your scoop
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?
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.
Parent
twitter
facebook
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.
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...