Linked by David Adams on Fri 20th Apr 2012 01:31 UTC, submitted by fsmag
Multimedia, AV "When I started working on a no-DRM, open-standards-based solution for distributing high-definition video on fixed media ('Lib-Ray'), I naturally thought of Theora, because it was developed as a free software project. Several people have suggested, though, that the VP8 codec would be a better fit for my application. This month, I've finally gotten the necessary vpxtools and mkvtoolnix packages installed on my Debian system, and so I'm having a first-look at VP8. The results are very promising, though the tools are somewhat finicky."
Thread beginning with comment 514927
To read all comments associated with this story, please click here.
WereCatf
Member since:
2006-02-15

First off, here's two links that were not included in the submission and that I think should have been: http://lib-ray.org/ explains what Lib-Ray is, and http://lib-ray.org/spec.html explains what the spec is like.

Now, my own take on this: it's a generally rather good idea, but the spec is not well-defined enough.

Problem one: there is no file defined with a clear enough name that would immediately indicate that the media contains a Lib-Ray product. "meta.cnf" is just too ambiguous, I've already seen ".cnf" -files used by multiple different applications and games, and "meta" is.. well, clearly meta. A more clearly-defined file present on the media should be included and would make it very easy to determine if there is a Lib-Ray product on the media or on another location. My suggestion would simply be "Lib-Ray.media" - file, containing information such as what codecs are used, number of titles, chapters, audiotracks and so on included, and most importantly, the Lib-Ray specification version the media adheres to so that the specification can in the future be extended without breaking support for older media.

Second problem: the specification defines a combination of VP8/Vorbis as mandatory, whereas a much more flexible and future-proof approach would list VP8 - and Vorbis - support in the player mandatory in this version of the specification and the VP8/Vorbis combination the default, but would allow for the use of different codecs at users' own discretion. This would obviously give users some flexibility on these matters if they have one or another specific need for using a different combination of codecs, and it would make it simple to extend the spec in the future; you'd only need to bump the spec version up and define a new set of codecs that must be supported in order to be compliant with that new spec.

Basically there's plenty things in the spec that are mandated instead of mandating the support for atleast those values presented and making them the default, but allowing for values outside that range in future versions of the spec.

I am also somewhat uncertain if the way the menus are done is all that good and flexible enough, but I suppose that remains to be seen. One thing that springs to mind at first is that I do not see anything that would allow for multiple full titles, each with their own subtitle and audio settings, on one media. Personally I would like such a feature to be added to the spec, it would allow for the creation of collections where the titles are in one way or another related to each other, but do not share the same characteristics when it comes to audio and subtitling.

Reply Score: 5

Alfman Member since:
2011-01-28

Isn't this going to be kind of limited use without support for 0x10c programs? ;)

http://www.osnews.com/story/25765/Notch_unveils_0x10c_space_sim_wit...


Hehe, more seriously, I appreciate that benefit we all get from open technologies, but I don't see this gaining much traction. It just seems like the proposed media format doesn't offer a compelling advantage over existing technology that's been in use for years.

I'd be more interested in an open spec for running some arbitrary unlocked apps on a media center PC. Media centers like Tivo, xbox, etc are powerful, if only they weren't so locked down. Adding more advanced programming features would help set this apart from "just another DVD player", for example.

Reply Parent Score: 2

WereCatf Member since:
2006-02-15

Hehe, more seriously, I appreciate that benefit we all get from open technologies, but I don't see this gaining much traction. It just seems like the proposed media format doesn't offer a compelling advantage over existing technology that's been in use for years.


I suppose the aim is for people who like to keep a physical copy of all their movies and whatnot in such a format that will be readable far into the future, and for Indie filmmakers and such who may not wish to or who may not be able to afford all the various kinds of license fees needed to make BluRay - and/or DVD - discs. The license fees can apparently be really costly and as such a media format that is free of such seems like a rather good idea and will allow these people to use their budget for actual filming instead.

Reply Parent Score: 5

bassbeast Member since:
2007-11-11

Well I'd say there is another problem that will be a real elephant in the room which is why Google refuses to indemnify VP8 which is the patents on H.264 are so wide and so numerous that frankly it would be extremely difficult to do much of anything with video without walking right into that minefield.

This is why I had hopes that developers would refuse to support HTML V5 unless a FOSS codec was chosen as baseline as that might finally bring this thing to a head but sadly it looks like the lure of iMoney nixed that and with Google refusing to step up to the plate frankly trying to get any kind of FOSS high def format adopted by the mainstream (and to get that crucial hardware support) is gonna be nearly impossible as the hardware manufacturers won't dare risk the wrath of MPEG-LA.

So I just don't see any FOSS format gaining any real traction as long as the specter of being buried in lawsuits by MPEG-LA hangs over the manufacturers. instead they will pay their MPEG-LA license fees and then since they have already paid why not just use H.264? What we need is the FSF and EFF to get together with several developers of software like this and have it out in court with MPEG-LA. Because as long as they can drop the patent bomb on any company at any time nobody is gonna risk going against them, their patent pool is just too vast.

After all the ONLY way for this format to gain any real traction is to have players manufactured (probably by small companies at first) and then build grass roots support but if MPEG-LA drops the patent bomb nobody will touch this with a 50 foot pole. And you can rest assured that there is NO WAY that MPEG-LA is gonna give up becoming the de facto standard for high def video without a nasty legal battle, there is simply too much profits involved.

Reply Parent Score: -1

Vanders Member since:
2005-07-06

Well I'd say there is another problem that will be a real elephant in the room which is why Google refuses to indemnify VP8 which is the patents on H.264 <snip>


That load of crap again? I thought the trolling had moved on. Oh well. No doubt Google will indemnify users of VP8 once MPEG-LA indemnify users of h.264. Until that time, any talk of indemnification is just double standards and can safely be ignored.

Reply Parent Score: 4

0brad0 Member since:
2007-05-05

Well I'd say there is another problem that will be a real elephant in the room which is why Google refuses to indemnify VP8 which is the patents on H.264 are so wide and so numerous that frankly it would be extremely difficult to do much of anything with video without walking right into that minefield.

This is why I had hopes that developers would refuse to support HTML V5 unless a FOSS codec was chosen as baseline as that might finally bring this thing to a head but sadly it looks like the lure of iMoney nixed that and with Google refusing to step up to the plate frankly trying to get any kind of FOSS high def format adopted by the mainstream (and to get that crucial hardware support) is gonna be nearly impossible as the hardware manufacturers won't dare risk the wrath of MPEG-LA.

So I just don't see any FOSS format gaining any real traction as long as the specter of being buried in lawsuits by MPEG-LA hangs over the manufacturers. instead they will pay their MPEG-LA license fees and then since they have already paid why not just use H.264? What we need is the FSF and EFF to get together with several developers of software like this and have it out in court with MPEG-LA. Because as long as they can drop the patent bomb on any company at any time nobody is gonna risk going against them, their patent pool is just too vast.

After all the ONLY way for this format to gain any real traction is to have players manufactured (probably by small companies at first) and then build grass roots support but if MPEG-LA drops the patent bomb nobody will touch this with a 50 foot pole. And you can rest assured that there is NO WAY that MPEG-LA is gonna give up becoming the de facto standard for high def video without a nasty legal battle, there is simply too much profits involved.


Although adoption has been a bit slow there is a lot going on. Android/Chrome/Firefox/Opera have support for WebM. A whole slew of SoCs used by phones and various appliances are going to be released over the next 6 months and some existing ones had upgraded DSP code as part of their SDK to allow HW accelerated VP8 decoding as well. My Boxee Box even has WebM support. IMO if this was such a big deal you would not have so many big name companies from across various industries commiting to WebM support.

Reply Parent Score: 4

Digitante Member since:
2012-04-21

Well I'd say there is another problem that will be a real elephant in the room which is why Google refuses to indemnify VP8 which is the patents on H.264 are so wide and so numerous that frankly it would be extremely difficult to do much of anything with video without walking right into that minefield.


If you can't avoid a risk, then it doesn't affect your choice. You just hold your breath and leap. As far as I can tell, the risks associated with Theora and VP8 are similar and both are better than any other available choice. H.264, on the other hand, is clearly off-limits.

After all the ONLY way for this format to gain any real traction is to have players manufactured


Depends a bit on what the goal is. I don't expect to put Blu-Ray out of business, just give the free-culture/indie-film community a better option than we've got now.

Casual viewers will probably be happy with DVDs, while serious movie fans will probably pop for an inexpensive HTPC anyway, which is becoming increasingly attainable. Lib-Ray is designed with the idea of being more convenient in that environment than Blu-Ray (or even DVD).

Meanwhile, anybody with an Android tablet or a desktop PC will probably be able to watch Lib-Ray without buying any new equipment. (At least I hope this will be true). Choosing SDHC as a hardware medium will help with that, as almost all of these devices already have a reader for it (and if they don't, they have USB which allows a reader to be attached easily).

Reply Parent Score: 3

galvanash Member since:
2006-01-25

Well I'd say there is another problem that will be a real elephant in the room which is why Google refuses to indemnify VP8 which is the patents on H.264 are so wide and so numerous that frankly it would be extremely difficult to do much of anything with video without walking right into that minefield.


Google doesn't indemnify WebM users for the same reason that MPEG-LA doesn't indemnify H.264 users... No one licensing codecs (either commerical or OSS) does that.

Considering MPEG-LA makes people pay to use H.264 you would think that there might be a wee bit more outrage about them failing to indemnify their licensees, but nooooooo... everyone grills Google over it, even though they give there stuff away for free.

This is why I had hopes that developers would refuse to support HTML V5 unless a FOSS codec was chosen as baseline as that might finally bring this thing to a head but sadly it looks like the lure of iMoney nixed that and with Google refusing to step up to the plate frankly trying to get any kind of FOSS high def format adopted by the mainstream (and to get that crucial hardware support) is gonna be nearly impossible as the hardware manufacturers won't dare risk the wrath of MPEG-LA.


Google refusing to step up to the plate? What else do you want them to do for goodness sake...?

And why is hardware support so crucial - I still don't get this. WebM doesn't have to become a dominant format to "win" - it just has to exist. If companies want to use H.264 and pay for licences that is fine - why should I care? If I'm buying a little box to play netflix movies, why should I care what format they are in?

That isn't at all the point of WebM - the point is to have a video distribution format for the web that can be used without having to pay for licensing. All it needs to accomplish that is get widespread browser support and a little time...

Reply Parent Score: 3

westlake Member since:
2010-01-07

I just don't see any FOSS format gaining any real traction as long as the specter of being buried in lawsuits by MPEG-LA hangs over the manufacturers. instead they will pay their MPEG-LA license fees and then since they have already paid why not just use H.264?


For almost all practical purposes, the manufacturers you are talking about are H.264 licensors.

There are about thirty them, global industrial giants like Mitsubishi, Philips, Samsung and Toshiba.

H.264 fees are capped. The maximum bite is 20 cents a unit for a harware encoder/decoder. 10 cents a unit on sales of more than 5 million units a year.

The Enterprise Cap is $6.5 million a year.

Reply Parent Score: 1

Digitante Member since:
2012-04-21

First of all -- thanks very much for the input, and for inviting me to this thread.

and http://lib-ray.org/spec.html explains what the spec is like.


Mind you, I'm rewriting that now. That's what the FSM articles are about:

http://www.freesoftwaremagazine.com/articles/libray_video_standard_...

http://www.freesoftwaremagazine.com/articles/libray_video_standard_...

http://www.freesoftwaremagazine.com/articles/libray_video_standard_...

Which I'm writing as I go through the development of my third prototype design.

Now, my own take on this: it's a generally rather good idea, but the spec is not well-defined enough.


Thus far, I agree. Hence, the "0" version numbers. :-)

I'll release a version "1" when I think I've got past that point.

Problem one: there is no file defined with a clear enough name that would immediately indicate that the media contains a Lib-Ray product. "meta.cnf" is just too ambiguous, I've already seen ".cnf" -files used by multiple different applications and games


Not a problem. It's not just the 'meta.cnf' file that defines it as a Lib-Ray volume, it's the contents of the file, e.g.:

[Lib-Ray]
# Mandatory fields
LibRayVersion: 0.2
LibRayID: 1 # ID for the producer (sign up for this with lib-ray.org)
DiskID: 2 # ID for this disk (you assign this number)
Cover: cover.jpg
Title: Sintel


Second problem: the specification defines a combination of VP8/Vorbis as mandatory


Currently trying VP8 + FLAC/Vorbis + SRT. Was originally Theora + FLAC + Kate.

whereas a much more flexible and future-proof approach


Future-proof versioning is addressed above.

Bear in mind that "VP8-only" constrains the disk/card format, not the player. The point is that a player developer need only support this format.

(And AFAIK, the only choices for free/open formats are VP8 and Theora at this time. Allowing proprietary standards like H.264 would defeat the purpose).

I am also somewhat uncertain if the way the menus are done is all that good and flexible enough, but I suppose that remains to be seen.


Well, I'll be revisiting that issue. The thing is, I don't like the idea of creating a whole new menu format when there are perfectly good free software HTML engines and lots of developers already know how to write HTML.

One thing that springs to mind at first is that I do not see anything that would allow for multiple full titles, each with their own subtitle and audio settings, on one media.


That's definitely going to happen, though. I'm still considering the best way to organize it -- and at the moment I'm trying to get the basics dealt with first.

it would allow for the creation of collections where the titles [...] do not share the same characteristics when it comes to audio and subtitling.


That's a good point that I haven't given a lot of thought to. However, I think it gets covered by using the already-specified HTML5 Javascript approach, where the subtitle and audio options are properties of the video objects.

Reply Parent Score: 2