Beta

Slashdot: News for Nerds

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

cancel ×

370 comments

already slashdotted ? (3, Interesting)

godrik (1287354) | more than 4 years ago | (#31349144)

I don't see any comment and the website is already down. gg /.

Re:already slashdotted ? (5, Funny)

heneon (570292) | more than 4 years ago | (#31349192)

In related news, I know technical shortcomings in hosting an article on hardwarebug.org...

Re:already slashdotted ? (4, Insightful)

sopssa (1498795) | more than 4 years ago | (#31349222)

But there was a lot of interesting points though (I read it before it got slashdotted) and it went to technical points too. But what Ogg support, along others, basically comes down to:

The third reaction bypasses all technical analysis: Ogg is patent-free, a claim I am not qualified to directly discuss. Assuming it is true, it still does not alter the fact that Ogg is a bad format. Being free from patents does not magically make Ogg a good choice as file format.

This is so true, not only with Ogg or file formats, but also Linux and open source software too. The patent-free, open source and free are very rarely any good selling points. What it can actually do is. I can only hope more open source developers would get this - you can't sell the idea outside /. people for it being open and free, it also has to be better (or even on the same level).

Not a selling point (3, Insightful)

XanC (644172) | more than 4 years ago | (#31349312)

It's not a selling point, it's a starting point. It's a sine qua non. For an application like video on the Web, nothing non-free can even enter the conversation.

Re:Not a selling point (4, Insightful)

Lunix Nutcase (1092239) | more than 4 years ago | (#31349338)

Apparently the rest of the world disagrees considering the widespread nature of flash video that has always used proprietary audio and video codecs.

Re:Not a selling point (2, Interesting)

aflag (941367) | more than 4 years ago | (#31349522)

However, do you disagree? Why? I hope it's not because of this world you talk about.

Re:Not a selling point (3, Insightful)

drooling-dog (189103) | more than 4 years ago | (#31350044)

Mindshare has more to do with advertising and promotion than raw technical superiority. Proprietary, patent-protected technologies tend to florish simply because companies are more willing to invest in promoting them if they'll reap all of the benefits when they sell. If anyone and her brother could legally make and sell Gucci-branded handbags, then there would be no incentive for Gucci to spend $millions on advertising and you'd likely never hear about them.

Re:Not a selling point (3, Insightful)

interval1066 (668936) | more than 4 years ago | (#31350082)

Apparently the rest of the world disagrees considering the widespread nature of flash video that has always used proprietary audio and video codecs.

And that will be fine so long as Adobe is always around to maintain and develop Flash, and people are always willing to use it. Personally, I can't see being married to one av format simply because it works, world opinion be damned, but it is what everyone uses. Until HTML 5 gets wider adoption, perhaps. Frankly, if I were Adoba I'd be getting out of the "Chief bottle washer and Flash maintainer" business myself, I hope for their sake they've poured money into something new that they've kept the wraps on, as I would hate to have as large a percentage of my business as they have based on 15 year old technology. I'd do that then just before I trotted the new stuff out let Flash wander out into the open source pasture.

Re:Not a selling point (5, Insightful)

maxume (22995) | more than 4 years ago | (#31349350)

And then over here in actuality (rather than the conversation), there is Youtube. And Netflix. And Hulu. And so on.

Re:Not a selling point (1)

arose (644256) | more than 4 years ago | (#31349386)

I think it's quite clear that he was talking in terms of standardization, not in what content providers would consider using.

Re:Not a selling point (2, Insightful)

maxume (22995) | more than 4 years ago | (#31349512)

In which case the standard will be impotent (because it will be completely divorced from practice).

Re:Not a selling point (1)

Draek (916851) | more than 4 years ago | (#31350114)

The same was said of HTML itself when Microsoft decided to 'fork' it with IE. Sure it took a long time for the dust to settle and Microsoft to accept defeat and finally implement the actual standard, but if we even took on Microsoft itself I doubt we'd fare any worse against the much smaller Google and Apple.

Just keep patents off the official standard. Sooner or later they'll learn the idiocy of patented standards, and its best we don't have to fork it over when they do, specially given the W3C is now the only standards body with any sort of credibility whatsoever.

Re:Not a selling point (2, Informative)

Locke2005 (849178) | more than 4 years ago | (#31349392)

Unfortunately, it can enter the conversation. Standards should be free, open, and unencumbered to allow for rapid adoption. That doesn't mean they always are. For example, Microsoft, simply because of it's size, can drive a non-open standard into widespread adoption (this isn't always a bad thing.)

Re:Not a selling point (1)

sopssa (1498795) | more than 4 years ago | (#31349440)

This is especially true with the battle over HTML5 Video. Technically H.264 is a lot better format than Theora, especially on web because you can stream a lot better quality on slower bitrate. This is why YouTube uses H.264 even with the HTML5 Video tag testing and why all Microsoft, Google and Apple support it. Maybe Google pulls some new great open video codec format still as they bought a company developing such, but until that H.264 will win over Theora too just on technical merits.

Re:Not a selling point (5, Insightful)

egamma (572162) | more than 4 years ago | (#31349414)

It's not a selling point, it's a starting point. It's a sine qua non. For an application like video on the Web, nothing non-free can even enter the conversation.

Says who? XanC? Any format (and its software requirements) can succeed as long as the users will put up with it.

RealPlayer did very well for many years (say 1995-2000).
Apple Quicktime is used on many sites.
And of course, there's Adobe Flash.
To simply say that "nothing non-free can even enter the conversation" is ridiculous. Are your clothes free or open source? Your car? Your house? Your shampoo, your radio, your computer's processor, your keyboard?

Companies can make excellent closed-source products. Communities can make excellent open-source products.

Re:Not a selling point (4, Insightful)

vadim_t (324782) | more than 4 years ago | (#31349886)

Says who? XanC?

Add me to that list

Any format (and its software requirements) can succeed as long as the users will put up with it.

It can, yes. But there's a difference between what can be done, and what should be done.

And of course, there's Adobe Flash.

Actually, as of recently the Flash spec is available without restrictions, and there's gnash, a GNU implementation.

To simply say that "nothing non-free can even enter the conversation" is ridiculous. Are your clothes free or open source? Your car? Your house? Your shampoo, your radio, your computer's processor, your keyboard?

No, but I think they should be, it'd be better if they were, and that it's a goal well worth fighting for.

Especially since we're talking about standards here, and I don't see how something with one possible implementation can be a standard. A standard is a published spec anybody can implement. "Buy from $company" isn't a standard.

Actually, I think you used quite horrible examples as well. Let's see:

Clothes: the "spec" is open. Anybody can make their own pants if they wish to, and nobody is going to come ask for license money.
Car: Also open and well documented.
House: Built according to code
Shampoo: has a very loose open spec
Radio: How to receive FM signals is well documented and not restricted AFAIK
CPU: some (though not all) are open, with complete specs and source available
Keyboard: Either PS/2 or USB, is made to fulfill an open specification.

Every single thing you picked as an example complies with an open standard, can be made by anybody without needing to pay for a license, and is interoperable (any car from any manufacturer works and is legal to drive, so long it complies with the relevant standards for instance)

Companies can make excellent closed-source products. Communities can make excellent open-source products.

It's not about the quality. It's about a principle. I reject a closed "standard" for web video on principle, no matter how well implemented.

Re:Not a selling point (3, Insightful)

sopssa (1498795) | more than 4 years ago | (#31349998)

And of course, there's Adobe Flash.

Actually, as of recently the Flash spec is available without restrictions

But Flash still uses H.264 too. I don't see too many people, either normal web users, webmasters or those making Flash applets complaining.

It's good you reject closed-source products by principles, I wish I would too. But the reality is, people just want the best performing tool for the job and frankly the older I get the more I think so too. I had these fundamentalist ideas in late teen years, but then I faced the real world. Now I pick the right tool for the job, be it open source or closed. I use Windows on desktop because I game and think the experience is better, while still giving me freedom to mess around with the system. I use Linux on servers because they perform a lot better and command line usage with servers is a lot better, and in that case and scriptability Windows doesn't come even close. But fundamentalism and closed mindset in the end is just stupid.

Re:Not a selling point (1)

Draek (916851) | more than 4 years ago | (#31350248)

But Flash still uses H.264 too. I don't see too many people, either normal web users, webmasters or those making Flash applets complaining.

That's because Adobe is the one footing the bill for MPEG's patent licenses. If it were *them*, the actual users and webmasters, the bitchfest would be simply epic (well, mostly from webmasters, users would just torrent a pirated version from TPB or something).

And if anything is "fundamentalist" in this discussion, is the idea that performance trumps everything else, regardless of circumstances. You'd think all those arguing for h.264 due to its performance would be using IBM mainframes to post on Slashdot instead of going the el-cheapo route and assembling a regular "PC", given how little regard they give to the patent royalties that's been announced already, and the plethora of practical concerns that raises. Or, most likely, they're just planning on using a pirated encoder and try to get away with it by being a small player.

Re:Not a selling point (1)

david_thornley (598059) | more than 4 years ago | (#31350142)

"Buy from $company" isn't a standard. "Get a license from $company" can be, and often is. In many cases, patents are to be licensed on a RAND (Reasonable And Non-Discriminatory licensing) basis, which really isn't better than a patent troll for free software, but works very well in the commercial and proprietary world.

As far as your car and CPU are concerned, unless they're over 20 years old they've probably got some patents that apply to some features, and so you can't just make your own legally without paying license fees. (Well, you can if the designs are old enough, but you'll find everybody else is using better stuff.)

Nor does everybody share your principles. Patents work well with standard business models, and have the desirable effect (for established enterprises) of providing barriers to entry. Because of this, companies (who dominate the standard-setting business) are not likely to care all that much about patent-free as opposed to RAND. I don't like this any more than you do, but that's the current legal and business environment.

As a result, you're likely to be in the uncomfortable position of rejecting openly published and widely used standards.

Re:Not a selling point (2, Interesting)

drtsystems (775462) | more than 4 years ago | (#31349682)

This argument is what will kill HTML5 and ensure a new era of the reign of flash, silverlight, etc. The choices are not h264 or theora. Its h.264 through an open html5 spec, or h264 through silverlight and flash. All major operating systems have support for h264 built in as it is (not to mention all the portable devices with hardware acceleration for it, including now many netbooks). The whole debate is stupid, firefox needs to just use the operating system's built in codecs to play h264. Problem solved.

Re:Not a selling point (1)

Khyber (864651) | more than 4 years ago | (#31350026)

"This argument is what will kill HTML5 and ensure a new era of the reign of flash,"

Not as long as one of the top hackers in the world continues to prove that Adobe is one of the biggest security threats to the web.

Re:Not a selling point (1)

sopssa (1498795) | more than 4 years ago | (#31350100)

Talk about missing his point.

Re:already slashdotted ? (1)

Draek (916851) | more than 4 years ago | (#31349662)

The patent-free, open source and free are very rarely any good selling points.

Really? guess somebody should tell game devs that, then, and make them pony up the cash for AAC instead of using Ogg Vorbis for their engines.

When you want to ensure your product reaches the biggest amount of people, the best thing to do is to pick a patent and royalty-free standard as the base, and *then* work around the technical details, because nothing alienates hobbyists more than a third-party going around suing your customers for unpaid royalties. For a game engine such things are important, but for a web standard as is the case here, it's vital.

Re:already slashdotted ? (1)

CronoCloud (590650) | more than 4 years ago | (#31350184)

Thanks for bringing that up, I recently picked up the PS3 version of the recent Ghostbusters game and what do I see when I start the game? A Xiph copyright notice. It's the only one I've seen it in, however. Lots of Bink video notices though.

Re:already slashdotted ? (1)

davester666 (731373) | more than 4 years ago | (#31349668)

Is there any actual way to establish something as being "patent-free"? Other than taking an implementation and/or description of the format and compare it against every single patent in force (or pending) on the date the implementation/description was published with patent lawyers in front of a patent judge? And not just US patents, but around the world, because of various trade agreements to respect other countries patents.

At best, right now, 'patent-free' just means that nobody has pressed any patent claims against Ogg.

Re:already slashdotted ? (4, Informative)

Steve Max (1235710) | more than 4 years ago | (#31349958)

However, it's not unique to OGG. AFAIK, MKV is also patent-free, and it's the standard container for torrents^Wprivate-encoded HD video. And it's a much better container anyway.

Re:already slashdotted ? (1)

drtsystems (775462) | more than 4 years ago | (#31350254)

I'd imagine container formats have far fewer patent issues to worry about compared to compression algorithms.

Re:already slashdotted ? (4, Funny)

noidentity (188756) | more than 4 years ago | (#31349204)

I don't see any comment and the website is already down. gg /.

Yes, but what format is the website in? I'm thinking something involving ashes.

Re:already slashdotted ? (5, Funny)

Jurily (900488) | more than 4 years ago | (#31349212)

Wasn't us. We don't read the articles before posting.

Re:already slashdotted ? (0)

Anonymous Coward | more than 4 years ago | (#31349264)

Mod parent as funny!

Re:already slashdotted ? (4, Funny)

Yvan256 (722131) | more than 4 years ago | (#31349422)

There's articles? Since when?!

Re:already slashdotted ? (1)

bertoelcon (1557907) | more than 4 years ago | (#31349478)

Wasn't us. We don't read the articles before posting.

Or after posting.

Re:already slashdotted ? (5, Informative)

alsaan (702884) | more than 4 years ago | (#31349230)

Re:already slashdotted ? (0, Offtopic)

dgatwood (11270) | more than 4 years ago | (#31349318)

I clicked, half expecting Kermit doing goatse [imageshack.us] , but it's legit. Mod parent up.

Re:already slashdotted ? (3, Interesting)

Nemyst (1383049) | more than 4 years ago | (#31349232)

Must be a hardware bug.

Still better than AVI (3, Insightful)

Ltap (1572175) | more than 4 years ago | (#31349150)

No matter how bad it is, it's still better than AVI. I personally use Matroska, it has all of the ideological benefits (free, non-encumbered, open-source) over stuff like MP4.

Re:Still better than AVI (2, Funny)

Anonymous Coward | more than 4 years ago | (#31349252)

You forgot the lack of general support. Definite win on the ideological front.

Re:Still better than AVI (2, Insightful)

sopssa (1498795) | more than 4 years ago | (#31349304)

Exactly this. Matroska in general is great and a lot better than Ogg or others, but it doesn't work on any device besides PC - not on 360, not on PS3, not in mobile phones.. CoreCodec should really try to push general support in other devices for it.

Re:Still better than AVI (1)

Shimdaddy (898354) | more than 4 years ago | (#31349368)

I'm not sure about the XBox360, but the excellent ps3 media server [google.com] will happily transcode matroska files for smooth playing on your ps3.

Re:Still better than AVI (0)

Anonymous Coward | more than 4 years ago | (#31349424)

nope - 360 doesn't like it. Windows 7 won't stream it either.
Have to transcode to wmv with wma if you want HD streaming with 5.1 sound

Re:Still better than AVI (2, Insightful)

sopssa (1498795) | more than 4 years ago | (#31349730)

Of course, I use that too. But that's exactly the point - it doesn't support it, so you have to transcode.

Re:Still better than AVI (1)

c_g_hills (110430) | more than 4 years ago | (#31349396)

Untrue. Matroska is now officially supported by the DivX Plus HD profile which is used by a variety of devices.

Re:Still better than AVI (1)

sopssa (1498795) | more than 4 years ago | (#31349752)

That's good to hear, but it still doesn't work with PS3, 360 or other devices I have :-)

Re:Still better than AVI (1)

Khyber (864651) | more than 4 years ago | (#31350060)

http://hubpages.com/hub/How-To-Play-MKV-Files-On-Playstation-3 [hubpages.com]

Really, googling "Play MKV on PS3" isn't that hard - it just removes the container format and puts it all back into native VOB.

Re:Still better than AVI (1)

sopssa (1498795) | more than 4 years ago | (#31350194)

You're missing the point. I know how to convert them to play on PS3, but that still doesn't make PS3 support Matroska.

Re:Still better than AVI (0)

Anonymous Coward | more than 4 years ago | (#31349400)

Actually it's quite the opposite: most stand alone digital players handle MKV just fine. Whether they have built-in storage or not (e.g. Western Digital WD-HD).

Re:Still better than AVI (0)

Anonymous Coward | more than 4 years ago | (#31349402)

I think it's important to note that MKV is very well supported (well, better supported than I expected) on set-top media player boxes like the WD TV, Popcorn Hour and similar devices from Seagate, Roku, Netgear and Asus.

Re:Still better than AVI (0)

Anonymous Coward | more than 4 years ago | (#31349480)

The NMT platform by Syabas (Popcorn Hour et al.) support it just fine, thanks.

Re:Still better than AVI (1)

CreamyG31337 (1084693) | more than 4 years ago | (#31349932)

Cowon supports it. They make MP3 players and PMPs if you've never heard of them. jetaudio.com/products [jetaudio.com]

Re:Still better than AVI (3, Informative)

Jah-Wren Ryel (80510) | more than 4 years ago | (#31350004)

Exactly this. Matroska in general is great and a lot better than Ogg or others, but it doesn't work on any device besides PC - not on 360, not on PS3, not in mobile phones..

However, matroska support is pretty much standard in any but the most proprietary set-top boxes. For example - WDTV, TiVX, Popcorn Hour - basically anything that uses any recent Sigma Designs chipset. Similarly iRiver supports matroska on their newest portable media players and Archos's latest android based pmp also supports matroska.

JVC and Phillips have currently shipping blu-ray players that play matroska. Panasonic has announced their next generation of TVs and blu-ray players will do matroska, and the specs for NEC's next gen of video decoder chipsets (which compete with Sigma Designs) say they will include matroska support.

Re:Still better than AVI (1)

Khyber (864651) | more than 4 years ago | (#31350040)

"Matroska in general is great and a lot better than Ogg or others, but it doesn't work on any device besides PC"

My AIWA DVD player can read MKV containers as long as the codec used for encoding is FourCC compatible.

Re:Still better than AVI (1)

rwa2 (4391) | more than 4 years ago | (#31349384)

I'd like to use Matroska more, I like the DVD-like features such as alternate audio tracks and switchable subtitles. Have any recommendations for encoders that can include these features? VLC appears to work pretty well on the player side.

Re:Still better than AVI (1)

greed (112493) | more than 4 years ago | (#31349906)

HandBrake can do MKV files with DTS and AC3 pass-thru audio, and DVD "image" subtitles. (MP4 can only do AC3 pass-through and "text" subtitles.)

Between HandBrake and XBMC Live, I've got some lovely Blu-Ray-sourced .mkv files; DTS sound, multiple language subtitle channels all switchable, and so on....

Re:Still better than AVI (3, Informative)

r_benchley (658776) | more than 4 years ago | (#31349936)

I use Handbrake http://handbrake.fr/ [handbrake.fr] for encoding. Handbrake will let you chose from MP4 or MKV for container, H.264 or Theora for video and MP3, AAC or Vorbis for audio.

Re:Still better than AVI (2, Interesting)

ObsessiveMathsFreak (773371) | more than 4 years ago | (#31349498)

The great thing about Matroska is that it supports (or at least can support) absolutely everything.
The main drawback of Matroska is that it supports (or at least can support) absolutely everything.

Matroska is a great container format, but unless you have a program like mplayer or vlc you can't guarantee that a Matroska file is going to be playable on your system. You can't reasonably expect browser maker to standardise on Matroska if it will mean having to include 30+ different codecs in their software, which from a practical standpoint it will. The unfortunate reality is that most of the world's population still doesn't have access to a comprehensive library of software like apt, and while our current software IP regime reigns, they never will.

Re:Still better than AVI (1)

stms (1132653) | more than 4 years ago | (#31349826)

I prefer Matroska as well... personally I think that xilph should drop the ogg container since mkv is doing such a good job then it would leave slightly more time to work on their video codec (perhaps they could even merge the projects if everyone was happy with it).

Flamebait much? (0)

Anonymous Coward | more than 4 years ago | (#31349164)

Who cares about container formats anyway? I could write ten before I get up in the morning. The codecs are the hard part.

Re:Flamebait much? (1)

91degrees (207121) | more than 4 years ago | (#31349458)

Yes, but having low overhead, low latency with efficient random access are still beneficial in a container format. Ogg doesn't have these.

Re:Flamebait much? (1)

jhfry (829244) | more than 4 years ago | (#31349658)

Sure you could... but would those 10 meet the needs of developers, content creators, and everyone else to whom the container does matter.

Most container formats are limiting on the users of the format... and they must be to ensure that someone can develop for them, if there weren't rules, then it wouldn't be a specification. The best format is the one that imposes the right limitations while remaining very flexible for future technologies and uses.

While there are a multitude of container formats, few have met the ideal balance between flexibility and restriction. I haven't read the linked article, but I suspect it will highlight how OGG is to restricting and/or not flexible enough to stand the test of time.

It would be trivial to create a completely unrestricted container format, but no one could use it as there would be no standard for reading the content contained within it.

Just complaining (4, Insightful)

Evets (629327) | more than 4 years ago | (#31349174)

"I would have done it diffferently" does not mean that the format is bad. None of these "flaws" render the format unusable. Maybe it doesn't perform as well as another format, maybe it isn't designed the way you would like, but it's implemented, it's available, and it's in use.

Re:Just complaining (4, Interesting)

TheRaven64 (641858) | more than 4 years ago | (#31349342)

Wow, did you copy that criticism of TFA from the last section, where he says:

More commonly, the Ogg proponents will respond with hand-waving arguments best summarised as Ogg isn’t bad, it’s just different. My reply to this assertion is twofold:

  • Being too different is bad. We live in a world where multimedia files come in many varieties, and a decent media player will need to handle the majority of them. Fortunately, most multimedia file formats share some basic traits, and they can easily be processed in the same general framework, the specifics being taken care of at the input stage. A format deviating too far from the standard model becomes problematic.
  • Ogg is bad. When every angle of examination reveals serious flaws, bad is the only fitting description.

And he's right. Unless the technical details of Ogg are not as he represented them, the format is stupid. I've not looked at Ogg in detail, but I have written multimedia apps and his complaints are right on the mark. Even if most of them are untrue, the point about timestamps would have been a show stopper. There is absolutely no excuse for not encoding timestamps as rationals in a fixed format in the container. Without that, you are just inviting synchronisation problems between audio and video CODEC formats that aren't explicitly designed to work together.

Which may, of course, be intentional. Vorbis and Theora are designed to work together. But if you have a Theora video stream with MP3 or AAC audio, what happens? An H.264 video stream with Vorbis? Obviously the solution is to just use Xiph formats in the Xiph container. And that's fine. I don't have a problem with Ogg as a container for Xiph formats (other than the latency issues he mentions), but claiming that it is a general purpose format is misleading.

Ogg is like XML. It defines just enough to let you define something useful, but it's not useful by itself.

Re:Just complaining (2, Insightful)

sopssa (1498795) | more than 4 years ago | (#31349352)

Uh, wtf? Just because none of the flaws make it completely unusable doesn't mean it's not bad. If it has serious flaws, it is. As the writer states, it's a complete mess for app developers and lacks some required features that other formats have.

I can implement, make available and use a format I made in a few hours without thinking about it. Maybe it misses features for seeking because I didn't think about adding timestamps, and probably only usable audio format is WAV. But in your words it doesn't make my container bad and anyone criticizing it would be just complaining.

Re:Just complaining (0)

Anonymous Coward | more than 4 years ago | (#31349446)

You know what's also implemented, available and in use? Matroska [ycombinator.com]
While it isn't perfect it has certainly seen more use than Ogg, at least in the video world. Haven't read the article, because it's slashdoted, but I assume it's about the fact that the Ogg container was initially designed as a transport stream format for audio. While that's nice for streaming most video sites use progressive download to deliver the files, so it's not an advantage in that situation. I read that Xiph is only now working on implementing a keyframe index to allow proper seeking in video. Ogg also makes it complicated to integrate support for new codecs. You basically have to rewrite the splitter to support them. See here [multimedia.cx] posts 48 to 52. The last post also has a link to an older hardwarebug article describing problems with the Ogg container.

Re:Just complaining (3, Informative)

Wildfire Darkstar (208356) | more than 4 years ago | (#31349834)

Haven't read the article, because it's slashdoted, but I assume it's about the fact that the Ogg container was initially designed as a transport stream format for audio.

The article goes considerably beyond that, arguing that the container is flawed even as an audio format. Here's the money quote (emphasis mine):

When challenged, [Ogg campaigners] will occasionally assume an apologetic tone, explaining how Ogg was only ever designed for simple audio-only streams (ignoring it is as bad for these as for anything), and this is no doubt true. Why then, I ask again, do they continue to tout Ogg as the one-size-fits-all solution they already admitted it is not?

Re:Just complaining (2, Insightful)

Aladrin (926209) | more than 4 years ago | (#31349470)

Actually, they never said 'unusable'. They said 'ill-suited'. And it is, if their technical objections are all correct.

It sounds like Ogg tried to be too much and as with any over-generalization, the specifics suffer for it.

That doesn't mean it should't be used, it just means it's not optimal.

MKV (1)

Rickz0rz (831049) | more than 4 years ago | (#31349226)

Just use MKV and be done with it already :/

The Biggest Technical Objection (1, Insightful)

Anonymous Coward | more than 4 years ago | (#31349314)

Is that the ogg container format doesn't play itself.

TFA does NOT concern THEORA vs h264 (0)

Anonymous Coward | more than 4 years ago | (#31349326)

The article complains about the container format, not about the codec actually used in the container.

Therefore, please: do not confuse ogg - the - container - format with
theora - the codec used to encode the video.

It would be rather easy to replace / reimplement the container format with something else (easy compared to replacing
the codec with a newly designed codec anyway)

Re:TFA does NOT concern THEORA vs h264 (1)

Rizz (33500) | more than 4 years ago | (#31349504)

Some people are already using Theora and Vorbis inside MKVs. That just might be the hot ticket in the future.

Re:TFA does NOT concern THEORA vs h264 (0, Troll)

Duradin (1261418) | more than 4 years ago | (#31349878)

I know. It's a right pain to stumble across an Vorbis encumbered file and then have to demux it, fix the stream to be something useful and then rebuild the file.

Why yes, I do use a device that doesn't support Theora|Vorbis. How could you tell?

Flawed reasoning... (3, Insightful)

Anonymous Coward | more than 4 years ago | (#31349382)

There's at least one obvious flaw in his reasoning. He talks about removing the 8-bit version field in the header and replacing that with a 1-bit portion of the flags field to distinguish it from a hypothetical future version. That only works if one assumes there will only *ever* be two versions (v1 and v2). Such a basic failing of analysis is a pretty good indicator that he hasn't thought it all through as completely as he thinks he has.

Re:Flawed reasoning... (2, Interesting)

sylvandb (308927) | more than 4 years ago | (#31349642)

There's at least one obvious flaw in his reasoning. He talks about removing the 8-bit version field in the header and replacing that with a 1-bit portion of the flags field to distinguish it from a hypothetical future version. That only works if one assumes there will only *ever* be two versions (v1 and v2).

No, the flaw is yours. The 1 bit merely says "this is not the original version" and anyone that only knows the original version just stops there. Anyone that knows the 2nd version has enough smarts to look at the 2nd version bit (or field).

Re:Flawed reasoning... (0)

Anonymous Coward | more than 4 years ago | (#31350234)

No, the flaw is yours. The 1 bit merely says "this is not the original version" and anyone that only knows the original version just stops there. Anyone that knows the 2nd version has enough smarts to look at the 2nd version bit (or field).

yes, that's why in ipvX packets we have a whole byte to indicate the version, isn't it? because they liked being inefficent, even with completely new standards, and even if you can specify the payload protocol in the lower level! ...or not?

Re:Flawed reasoning... (3, Informative)

0xABADC0DA (867955) | more than 4 years ago | (#31350244)

No, the flaw is yours. The 1 bit merely says "this is not the original version" and anyone that only knows the original version just stops there. Anyone that knows the 2nd version has enough smarts to look at the 2nd version bit (or field).

In which case once there is a second version you have the exact same packet format as the current ogg, except for an extra mask, test, and one fewer flag bit. So the only gain at all is if you assume there will never be another version, and if there is even one more version then you've caused a pipeline stall for no reason. Which is stupid.

This goes along with the criticism of the checksum field as 'wasted space', but it is probably put there so you can reliably find the page header if doing a random seek. Which if you can do, then you don't need a time index because you can do a binary search to find any time index with only a tiny bit of extra seeks.

I haven't looked at these formats in depth, but it sure sounds like this guy is clueless.

Re:Flawed reasoning... (0, Offtopic)

blair1q (305137) | more than 4 years ago | (#31349694)

No, he's saying that since nobody ever sets the field it's of limited current use. It can be replaced by a single bit which, when set to 1, would invoke processing of another version field. But his argument is begging the question, as the field is there clearly to allow for more than one version, so the designers had prescience in that regard. He's saying they shouldn't have bothered. But if they hadn't, he'd probably be asking what happens if someone wants to use a different version.

If they had used a single bit to indicate a version-field extension was present, he would have had nothing to complain about, but since nobody designs packet headers that way, it's almost unthinkable that anyone would have done it that way in the first place.

Most of his objections are correct in detail, but pointless in gross. It's clear to anyone watching that the inner workings of file formats are not of economic interest to the end user. They are only too happy to download files in a dozen formats, totally ignorant of these petty inefficiencies, but getting furious when the player refuses to render them.

So everyone should just shut up and implement the ogg decoder we have, along with every other decoder necessary to read every file format in existence, because to do otherwise ranks you with the weak, lame, and lazy.

Re:Flawed reasoning... (4, Insightful)

Josef Meixner (1020161) | more than 4 years ago | (#31349894)

It is not in the header, the 8-bit version field is in every single page. As according to the post a page is mostly 64K due to a strange length encoding, you send the version very, very often. I don't see any reason, why the version would have to change in the middle of a file in any case. And honestly, would you write a decoder taking that into account, if the probability of stumbling onto such a file was currently 0 (due to there being only one version) and very, very low in the future? That means it just adds to the size of the file.

The second reason is even simpler, you only need one bit to tell the current format from the future formats. As there hopefully will be a good reason for a future version the page header will probably be different, so I can add a version field there when I at least found one reason why I need it, no? That way I need one bit now and can still have different versions later.

Re:Flawed reasoning... (3, Informative)

Yokaze (70883) | more than 4 years ago | (#31350208)

> I don't see any reason, why the version would have to change in the middle of a file in any case.

It is probably not due to the fact, that the version might change in the middle of the file, but in case, you only have a part of the file.
This makes it more robust, and better suitable for streaming: You can simply start sending from an arbitrary position, and the parser should
be able to recover at some point.

Re:Flawed reasoning... (1)

Areyoukiddingme (1289470) | more than 4 years ago | (#31350214)

I would assume that redundant page level data as fundamental as the encoding version would be most helpful when streaming, especially streaming live. I can't be bothered to read the article, but it sounds like the critic isn't taking into account all of the reasonable use cases. Not everybody downloads a file and plays it from beginning to end and not everybody can start from the beginning. If the stream started yesterday and I want to start watching it today, there had better not be any indispensable data at the very beginning.

Building the data into the stream means the stream server can be fairly simple, too. It doesn't have to cache that indispensable data from the very beginning to get my stream client to figure out what's going on. It just starts sending bytes and my client can figure it out. It would be most convenient for my client if the server started transmitting at the beginning of a page, but if the redundant data at the beginning of a page is large enough (i.e. more than 1 bit), that might be unnecessary. The page header may have a distinctive enough pattern for my client to detect the beginning of a page even if the stream started in the middle of a page.

Re:Flawed reasoning... (1)

noidentity (188756) | more than 4 years ago | (#31350220)

There's at least one obvious flaw in his reasoning. He talks about removing the 8-bit version field in the header and replacing that with a 1-bit portion of the flags field to distinguish it from a hypothetical future version. That only works if one assumes there will only *ever* be two versions (v1 and v2). Such a basic failing of analysis is a pretty good indicator that he hasn't thought it all through as completely as he thinks he has.

Actually, it shows the opposite to me. You have the current version, which decoders know how to decode. You also have slight revisions that don't break current decoders. And you have a future version that does break current decoders. Thus, you have a single flag in each version, specifying whether the file is that version, or the next one.

To determine file version, you first parse the file as the first version; if its "next version" flag is set, you then parse it as the second version; if its "next version" flag is set, you parse as version 3, etc. It only makes sense for a bitstream though (I haven't looked to see which this is). And it seems mostly a theoretically-elegant approach, in that it has no limit to the number of versions, and for each new version, the change is the same.

Practically, a version field seems simpler for everyone. And this doesn't rule out the above scheme, it just means you have versions 0-254 (assuming an 8-bit version field), and then version 255 which adds a second version field. Maybe the site isn't Slashdotted anymore so I can read his comments as well.

Re:Flawed reasoning... (1)

noidentity (188756) | more than 4 years ago | (#31350294)

OK, now that I've read the portion of the article, I can comment. His main point about making the version field only one bit is that a second version might never even exist, and only when it does should more space be devoted to the version number. A one-bit version field does NOT limit future versions, as explained in my previous post.

what is the point, exactly. (4, Insightful)

theheadlessrabbit (1022587) | more than 4 years ago | (#31349448)

I'm not an expert in video or audio production, I just dabble in it as a hobby. but one thing I often wonder is, what is the point of these container formats?

I've got a miniDV camera, and a canon point and shoot that thanks to chdk can record good-enough video. Both give me ".AVI" files, even though one is miniDV, while the other is Mjpeg. Mjpeg files don't work in my editor, while miniDV does. but I didn't know this at first, all I knew was that I have a bunch of .AVI files sitting in my hard drive, some work, some don't. I dont care about file extensions, I care about having files that work. I care about codecs. If they were named "filename.minidv" and "filename.mjpg" that information would be useful to me. What good is a container format when only half of the files within that container will play on my system?
I'm not trying to knock the idea of container formats, if they exist, their must be some beneficial reason for them. Could someone please enlighten me on what that reason is?

Re:what is the point, exactly. (5, Informative)

Dragoniz3r (992309) | more than 4 years ago | (#31349674)

Because, in general, you don't only want a video stream. You want to be able to bundle multiple streams together (usually of different types, eg an audio stream and a video stream). Vorbis, for example, is audio. Theora would be video. Ogg (the container) exists to bundle them together into a single file, so you can have a movie and sound with it.

Re:what is the point, exactly. (4, Informative)

Anonymous Coward | more than 4 years ago | (#31349678)

I'm not an expert in video or audio production, I just dabble in it as a hobby. but one thing I often wonder is, what is the point of these container formats?

The point of containers is to make the contained media modular. This way, you can assemble a multimedia ("many media"... whodathunkit) file from several individual pieces of media, each with codecs that may or may not be on speaking terms, into a cohesive file that i played as a unit.

If you define a format that has a video track and two channels of audio, you might think, hey, that's great, and play stuff on your computer. But what if you want a 5.1 audio track? Make another format, one for stereo and one for 5.1. Second audio program, like an alternate language? More formats: one for stereo + stereo SAP, one for 5.1 main + stereo SAP, one for 5.1 both; up to 5 formats now. Subtitles or closed captioning? More formats: up to 20 now. A different audio codec? Even assuming the SAP tracks and main use the same codec (they might not; depends on where you got the SAP track from), add 20 formats per audio codec. Multiple video codecs? The number of formats can grow exponentially. And we haven't even gotten to things like multiple camera angles and sideband info like text commentary, HTML links to things discussed in the show, or TV listings.

Or you can define a container and then, in each of those cases, only need to define a new component to be put into the container, and you're done. Containers make things much simpler and easier to implement.

Re:what is the point, exactly. (2, Insightful)

reacocard (1043858) | more than 4 years ago | (#31349706)

But its not just one codec that's involved, it's multiple. A typical video file will have at least two, one for video, one for audio. If you have alternate audio streams or subtitles, you need a codec for each of those as well. The purpose of a container is to let you take all these streams in their individual codecs and put them together in one file for easy playback. I'll grant you that it's not optimal to have some files with a given extension playable and some not, but with such a multitude of codecs in a single file it's just not possible to condense all that information down to a single file extension.

Re:what is the point, exactly. (0)

Anonymous Coward | more than 4 years ago | (#31349708)

well without containers, you'd have to have separate files for the audio and video, and subtitles

Re:what is the point, exactly. (0)

Anonymous Coward | more than 4 years ago | (#31349764)

Because historically (and for good reason) audio and video have been encoded separately. Thus you need a master format that can wrap around both and coordinate their playback.

Re:what is the point, exactly. (2, Informative)

cheesybagel (670288) | more than 4 years ago | (#31349800)

Code reusability. You can use an MPEG-4, MPEG-2, or MPEG video codec with the same MP3 audio codec. The integration parts of the code can be reused as well. Forward compatibility: you can easily make a library so programs can use the same API to decode a variety of codecs. This means a program can support file formats which did not exist when it was written.

Of course this is mostly true for player software. Editing software sometimes wants to do more low level bit twiddling (e.g. to minimize recompression) and accesses the files in a more direct fashion, bypassing the standard OS APIs. It is also likely your programs use different OS media APIs. Windows has like two different APIs: VfW, DirectShow. There are also some apps that use the Quicktime API.

Re:what is the point, exactly. (1)

MobyDisk (75490) | more than 4 years ago | (#31349836)

There are a lot of benefits to containers. I'm sure I can't name them all.

These container formats contain multiple types of data streams. Ex: audio, video, multi-language subtitles, etc. If you don't have a container format, then the software must guess at what streams are in the file. Would a file with H264 video + MP3 audio have a different extension from H264 + AAC? What if I add subtitles, does that need another extension? The container file solves this.

Because there are multiple streams, the software could simply pass-through unknown data streams. Maybe this particular app doesn't understand subtitles. So it doesn't recognize a stream ID of 12345 - it can display a warning, but preserve the data in the container.

It makes it possible for software to support new codecs because there is a globally unique way to identify the codec. So your software opens an AVI file with an MJPG stream. What can it do? Well, it could go to it's update site, query for MJPG codecs, and download it. Without the container format, the software has to guess based on the extension. And that isn't necessarily enough to know exactly what the file contains - this relates to my first paragraph, about the multitude of extensions.

Having a container format also means a lot of code is shared. Code for buffering, I/O, handling time stamps, live data streaming, synchronizing different streams -- those things are going to vary based on how the container is put together. Some things work on time stamps, others work on integer time indexes. Some interleave data, and use different methods for doing so. There are different ways of handling variable-bitrate data. It makes it easier for the developers, and faster to add additional codecs.

Metadata such as copyright information won't get lost when transcoding the file if the container format is the same.

Having lots of containers is a pain. It would be best if we could standardize on one. You are right that it does make it harder for the user to determine if the file is supported by that particular app. Not sure what to do about that though.

Lastly -- what app doesn't work with MJPEG .AVI files???? That's like the absolute baseline most commonly, easily-supported format.

Re:what is the point, exactly. (1)

theheadlessrabbit (1022587) | more than 4 years ago | (#31350050)

Lastly -- what app doesn't work with MJPEG .AVI files???? That's like the absolute baseline most commonly, easily-supported format.

Sony Vegas 7a does not have mjpeg out of the box. The audio track opens, but no video (I will be upgrading to 9 pending the completion of one more video job. I only invest into this hobby what I make from it)

I eventually got it to work thanks to ffdshow, but it was a year before I stumbled upon that solution.

I think I understand the purpose of container formats now.
To use a non-car analogy: it's like having multiple separate channels coming at you simultaneously. if one is not recognized by the system, that one channel can be ignored while the others will continue to work.

Re:what is the point, exactly. (0)

Anonymous Coward | more than 4 years ago | (#31349842)

If you dont have a standard container then you would have to invent new ways of encoding audio video and subtitle information into one file anyways. Containers allow you to use already well developed ways of encoding this information (mp3, mpeg, ASS for example) and combine them into one file which is properly synced and aligned. If you didnt have container formats you would have to develop a bunch of new technologies to encode them all together in some new way and then play them back. Or you could just leave them seperate, but this means to play a video you would have to keep at least 3 times as many files around, and manually point your player to each, not to mention syncing issues.

Re:what is the point, exactly. (1)

ink (4325) | more than 4 years ago | (#31349938)

Think about an HTML file. It can contain embedded objects and/or alternative tags, or newer tags, all of which your browser may or may not work with. Containers are important because they provide the meta information that players need to orchestrate the various streams embedded in them. Some containers were built for instant streaming in mind (FLV). Some were simple data partitions (AVI). Some are jack-of-all-trades that do everything (MKV). Some are so simple that the user has to provide information about the video in order to interpret them (raw YUV). Some containers are horrible at seeking to key frames (WMV). Some easily get out of sync audio (AVI). Ideally, we should be using Matroska for everything -- but we don't live in an ideal world.

Re:what is the point, exactly. (1)

jhfry (829244) | more than 4 years ago | (#31349996)

A container format is a necessary evil. There is much more to any media file than just the content. Potentially in any media file there may be metadata, timing information, synchronization information, subtitles, multiple language audio streams, multiple video streams, 3d video streams, surround sound information, interactive content, etc.

A good container format is one that allows all of those things in a way that developers supporting that container format can utilize in a standard predictable way.

If you did away with the container, your issues with .avi now would be severely compounded as your software must determine how to combine several files into one complete presentation. This is what many editing packages do... and even ones costing hundreds of dollars can have a hard time of it sometimes.

Re:what is the point, exactly. (1)

JesseMcDonald (536341) | more than 4 years ago | (#31350062)

If all you have is a single video stream then you don't really need a container. However, once you start adding in audio tracks, subtitles, and interactive features (e.g. menus), you need some way to combine these streams together in a manner which minimizes the need for buffering and/or random access (seeking) during normal playback. Container formats also supply the format identification, tags/metadata, and indexing/seeking support which raw formats typically lack.

Re:what is the point, exactly. (1)

Neon Spiral Injector (21234) | more than 4 years ago | (#31350204)

You do make a good point about the name, though. A name like: filename.pcm.dv.avi, or filename.mp3.mjpg.avi would reveal a lot more information. Too bad that scheme isn't more widely used.

umm.. (1)

PPNSteve (1287174) | more than 4 years ago | (#31349488)

[flamebait]
OR, we could go back to .rm
[/flamebait]

Ogg is a nice format (0, Offtopic)

cereda (1610079) | more than 4 years ago | (#31349910)

I can't say anything about video, but for audio all my CD collection is converted to Ogg instead of MP3, you can't even spot the difference in quality, thou the filesize is smaller. BTW, my MP3 player supports Ogg playing as well.

In the long run (4, Interesting)

istartedi (132515) | more than 4 years ago | (#31350154)

"In the long run, all file formats become programming languages."

From this I draw a number of conclusions, the first being that when designing a format you need to bring a "language sensibility" to it. If you don't, it's only a question of *when*, not if, your format will become a poorly designed language. OK, "language" may not be the right word. I'd also accept, "byte code" or "executable file", but it's the same idea. JMHO.

"Everything is broken" (0)

Anonymous Coward | more than 4 years ago | (#31350218)

His website says "Everything is broken". If that were true wouldn't that, you know, mean that Ogg is no different than its competitors?

Which doesn't answer the question ... (2, Insightful)

ITMagic (683618) | more than 4 years ago | (#31350282)

... of what format *should* be used in its place.

It is all very well claiming one format is not particularly good, but overall rather pointless if you don't argue an alternative.

So the question any .ogg user will have (since they probably chose this slightly obscure format over the more 'normal' .mp3 alternative due to the reputation of being better to listen to from an audiophile POV) is what to use instead? FLAC is fine if you have the space, but sometimes you want to compromise in order to save storage space...

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Create a Slashdot Account

Loading...