What Lib-Ray is All About
When we looked for a good choice for releasing a free-culture film in high-definition, we were really disappointed by the options. We could release on Blu-Ray, of course, but there's a whole raft of objections to the DRM, region-coding, and closed/proprietary nature of that standard. Everything about Blu-Ray is antithetical to our business model and way of thinking about media.
On the other hand, just dropping a multimedia file on a flash drive comes nowhere near the rich experience of a DVD or Blu-Ray disk. But it's not really that hard to create that experience using open standards. There are multimedia codecs which are free (Theora, VP8, and Dirac -- with VP8 being a clear technical leader in this area), and the web has given us HTML5, which certainly has everything you need to create the sort of menu features you're used to on DVD and Blu-Ray disks.
There is a little bit of development work to make it happen, of course: we've got to
- write a standard in the sort of unambiguous (but highly technical) format that engineers use to check compatibility;
- create an easy-to-use program to help people master their own videos in the format;
- build a reference implementation of a player that can play the format back on computers, portable devices, or "Home Theater PCs" (later, it might be possible to make a dedicated player);
- master a couple of test releases;
- and document it all with a formal spec and tutorials.
This can all be done on a tiny shoestring budget compared to what was spent on Blu-Ray, because we're doing everything in the open with open source software and open standards. And we're not wasting our time on elaborate schemes of "copy-protection" or "region-coding" or "DRM" -- which are all about preventing playback, not enabling it.
Still, it's more work than I can afford to do in my spare time, especially when I'm working on producing and directing my own project, "Lunatics", and I did not want to burden the Lunatics production budget with being the sole sponsor of this project. If it came to that, we'd probably be better off just dumping MKV files on a flash memory card, and releasing the high definition video that way.
But that would really lack style -- I don't want to offer a technically inferior product in order to keep it free. So I decided to run a separate Kickstarter campaign for Lib-Ray to see if I could attract some interest in developing it as a standard.
And it has attracted quite a bit of interest: the project has been mentioned in Linux Pro Magazine; I've been interviewed by Ars Technica; and I've been supported enthusiastically by Question Copyright's Karl Fogel (who actually suggested the name "Lib-Ray" for the standard). Nina Paley (creator of "Sita Sings the Blues") has been an enthusiastic supporter, mainly because she wants to release her own movies in this format -- she's contributed her film, with her endorsement as one of the reward releases we are offering in the Kickstart. Michael Tiemann, who you may know as one of the founders of Red Hat, supported Lib-Ray with a generous $5000 Corporate Sponsorship in the name of his current business, Manifold Recording. Richard Stallman of the Free Software Foundation has said that it "sounds very good" and has offered design advice to meet our goals of preserving user freedoms with the format.
In fact, I think this is the most popular project I've ever proposed. I don't think I'm the only one dissatisfied with Blu-Ray.
As a result, we've raised over $14,000 in pledges (as I write this, we've just passed 78%, though we only have 5 days left). But we won't see any of it unless we make the $19,000 that we've bid to do this project (there's an explanation of the costs in the FAQ below). That's just how Kickstarter works.
To fund it, we are offering as backer rewards, two releases: Nina
Paley's (creator endorsed) "Sita Sings the Blues" and a "Blender Open
Movies Collection" which will contain all three of the
currently-finished Blender Open Movies: "Elephants Dream", "Big Buck
Bunny", and "Sintel". All will be in a very-high quality high-definition
format (1920x1080 or "1080P" resolution). Like any good movie release
these days, they'll have extras -- information about the
filmmakers, alternate audio in some cases, and subtitle
tracks in many languages ("Sintel" has subtitles in 44 languages; "Sita
Sings the Blues" in at least 18).
These special releases will also contain complete copies of the player software and wizard in their data directories (which is why the releases don't come with the CD-R -- the same data will be on the movie card).
We're close -- there's a decent change we'll make it. If we don't, we might be able to regroup and try again, of course, but it'd likely not be in time for our own release, and it could drag out for a long time after that.
So, if you're willing to pitch in a little on Lib-Ray, we'd really appreciate it. What would really help, though, is if you can just tell everybody you know who might care about a project like this -- because it's really the number of supporters that counts at this point.
- Lib-Ray Home Page
- Lib-Ray Open Source Player Project (Newly minted, there's not a lot there yet)
- Lib-Ray Google Group (for discussing the design of the standard)
Lib-Ray: An Open HD Video Standard for Free Culture and Independent Film
In April of 2011, after exploring the options for releasing a free culture film project in HD Format and finding it wanting ("Five ideas for escaping the Blu-Ray blues"), I started this project to establish a basic standard for HD video that used existing open standards and would give all of the benefits of DVD or Blu-Ray videos (menus, extras, alternate audio tracks, subtitles, and so on) with none of the restrictions. It would also provide some nice features that DVD and Blu-Ray expressly do not provide, such as metadata for easy integration into archival systems (because the old content industry wants to block that kind of use).Karl Fogel, of QuestionCopyright.org, suggested the name "Lib-Ray" for this standard, and so the project was born. After going through some initial prototyping cycles, I now have a very solid idea of what this format will look like:
- Physical Media: MMC/SDHC Flash memory cards
- Video File Format: MKV container file with VP8 video and FLAC or Vorbis audio (this standard is similar, but a little more permissive than WebM, and is optimized for use on fixed media rather than downloads).
- Typical Bitrates: 12-24 Mbps (similar to Blu-Ray or HDTV transmission rates)
- Video Quality: "Full HD" (1920x1080 at up to 30fps (future releases may extend this to 60fps, 3D video, and eventually "4K" video at 4096x2048 pixels -- I'm offering a 4K release of "Sintel" -- 'experimental' because you may have a hard time finding hardware to play it back on).
- Experiments suggest that we can exceed a PSNR of 45 and an SSIM of 95% at these rates -- making this an extremely high-quality format
- Menu system is based on HTML5 -- it's possible to do everything needed by disk menus and then some
- The player will use the Gstreamer and Webkit libraries for video playback and menus, respectively
- The player will be written in Python with the python-gst, pywebkitgtk, and python-gtk
Now All We Have to Do is Build It
At this point, I no longer have any doubt that this format will work. What remains is simply the time it takes to put it all together.
Here's what I propose to create with your help:
- Example releases of free-culture videos in Lib-Ray format: "Sita Sings the Blues" and a "Blender Open Movie Collection" ("Elephants Dream", "Big Buck Bunny", "Sintel")
- A reference-implementation software player (in Python) to provide playback with menus, supporting all of the core features of Lib-Ray. This should be fairly simple since most of the needed functionality is provided by Gstreamer and Webkit libraries, which both have excellent Python APIs available.
- A GNU/Linux-based reference-design Home Theater PC system to run this software and act as a player (could also play DVDs or Blu-Ray with the right software).
- A GTK application wizard to automate the process of mastering a simple Lib-Ray video from your video masters
- A reference book documenting all of the above, including: the technical details of the Lib-Ray standard, the process for creating a Lib-Ray release using existing command-line tools, and how to use the simple GUI-based wizard and player software, as well as the spec for the hardware player
Where Will the Money Go?
The breakdown of the costs on this project are basically:
- about 10% or $1900 for Kickstarter and Amazon Payments
- about 40% goes into materials/manufacturing costs for rewards
- about 50% is the "development budget" of about $9500
Most of the development budget is a stipend for me to cover the estimated three months of work I feel this will represent. I am moderating a design review, making the appropriate design trades, and then writing all of that up in a formal document describing the standard so that engineers can understand it and make sure their own implementations will work. I will then write a reference implementation of a player for this format (a simple python application -- it's basically a customized browser) and a wizard application for creating compliant releases (a python script, using command line tools, with a PyGTK graphical user interface). And then of course, I'm going to write and self-publish a book including the specification and separate tutorials written for developers, filmmakers, and users of Lib-Ray -- it'll be called the "Complete Guide to Lib-Ray".
That's a lot of work, but I can do it in three months.
Since this started as a technical project to support my own free-culture movie release, it should probably not be surprising that I am also going to be working on the production of "Lunatics" during this year. So, there may be some significant pauses in production of Lib-Ray. However, there are gaps which will allow me to work on it.
I actually think I can most likely get this Lib-Ray project finished before the end of 2012 if all goes well, but I am adding an extra six months to the expected dates on the rewards just to allow for unforeseen (but frankly expected) delays or roadblocks in the development process. I'd rather estimate long and deliver early!
This was the idea I originally had for Lib-Ray. However, I researched it, and I found out that even BD-ROM (pressed Blu-Ray data media, as opposed to the same media containing a Blu-Ray video filesystem), required some degree of DRM.
The Blu-Ray standard for DRM has battlements within battlements. They've erected fortifications in the player, along the cable from the player to your monitor, in the software that reads the disk, in the hardware it runs on, in the manufactured disk, and in the encrypted filesystem on the disk.
The only way to completely escape the actual DRM is to burn your data onto blank BD-R media. Even here, though, you are still paying for DRM development. As a result, using any kind of Blu-Ray technology in Lib-Ray is a compromise, and if you're going to start making a lot of compromises, it starts to seem kind of pointless -- I don't want to build something "that only tries to kill you a little bit."
Also, the BD-R is technically inferior to BD-ROM. Many of the advantages, including cost are much diminished. Being a dye-based medium, BD-R is intrinsically more fragile. It has a more limited shelf-life and sensitivity to heat and light.
To some degree, these drawbacks also apply to Flash media, but the point is the gap is reduced to the point where other considerations become important.
User confusion will result if Lib-Ray disks, which promise the same high-definition / high-profile advantages as Blu-Ray disks are available on the market. Many people will assume they are a drop-in replacement, and will then be disappointed when dropping a Lib-Ray disk in their Blu-Ray player doesn't work. Although this wouldn't really be a fair criticism ("I never promised a drop-in replacement!"), it would still damage Lib-Ray's reputation -- probably fatally.
Flash being a writable format allows for some intriguing options of interest to crowd-sourced free-culture and independent film producers and fans. For example, it is often the case that fans will create subtitles for movies for other fans to use -- this is very popular with anime, for example. The "Stia Sings the Blues" DVD has just a few options for subtitles, but fans have produced more than a dozen additional subtitle tracks for the fim. With read-only optical media, including such additions means a new press run, and the old media are not improved. With writable flash media, you have the option to release a post-release patch for your movie. This also works for fixing the occasional menu bug, which is more likely with lower-circulation / lower-budget titles.
And, of course, flash memory based modules have been very successful for distributing other media, such as video games.
Also, although the BD-R standard stores up to 50GB, well above the 16GB-32GB flash cards size I expect to be useful for the current generation of Lib-Ray, that is a hard limit. For Flash media, it is not. You can already buy flash modules as large as 128GB or even 256GB if you are willing to pay a premium price. In the future, those sizes will probably become common and the prices will fall more in line on a per-GB basis.
Such larger media offer the possibility of expanding to even higher profile video in the future -- such as the "Lib-Ray 4K" experimental release I'm going to do with Sintel as part of this work. Other possibilities include higher frame rates, stereo 3D, or lossless video compression.
Finally, the cost of Flash memory is dropping rapidly -- by the time Lib-Ray actually has a chance of being a popular medium, they will already cost half of what they cost today. So, whatever price advantage BD-R still has is fading fast.
And lastly, Lib-Ray is intended to be flexible about medium. Although I plan to make flash media a de-facto standard for the near term, it is expected that Lib-Ray can be migrated to different physical media in the future.
Actually, this is true. SD media as such does have DRM. It's also a closed, proprietary standard -- technically. This did bother me, but a very simple solution exists (and thanks to Carlos Solis for suggesting this):
In practice, the proprietary "SD" standard is a thin layer of added-on DRM provisions above an open standard for flash modules called "MMC". SD cards were actually designed as a drop-in replacement for MMC, and are therefore pin-compatible with them.
So the fix is fairly simple: in the formal standard for Lib-Ray, we'll call for the open "MMC" standard, and simply acknowledge that SD is compatible with this standard so long as the DRM features are not used.
To be considered "Lib-Ray compliant", players will only have to implement MMC support and can ignore the SD extensions. Therefore, they will not have to pay the patent-licensing fees for the SD drivers.
At the same time, though, the ubiquitous consumer hardware that supports SD cards and the cheaper, more-easily available SD blank media can still be used for Lib-Ray.
So basically: require MMC support, tolerate SD support.
Several different questions (or assertions phrased as questions) have been asked along these lines -- ranging from the choice of name to the use of more-widely-supported proprietary codecs.
The bottom line is that the mainstream chose Blu-Ray. I can't do anything about that. If you want mainstream and don't care about DRM restrictions or patent problems, then go be with Hollywood and Blu-Ray. You have my blessings, or at least my disinterest. :-)
The only realistic future for Lib-Ray is as a niche medium for people who don't want the DRM -- either for ethical reasons or because they just don't want the hassle and cost.
My concern is that there should be an option for such people, and by focusing on their needs, I can make Lib-Ray very useful to them. So that's my strategy.
I also wrote an update about this (specifically about using Raspberry Pi):
If I were in the position of an OEM manufacturer, producing millions or even hundreds of thousands of units, the answer would be an emphatic "Yes!"
In fact, the solid-state SD reader required for this is intrinsically cheaper to make than the optical disk drive needed for Blu-Ray players.
However, the reality of a niche market is that I may only be making dozens or at most hundreds of players. More people will use their computers as players, or home-build HTPCs that can play Lib-Ray.
As such, it's harder to drive down the costs. I probably can't afford to pay someone to design and manufacture a run of player mainboards, for example. Nor even to mass-produce snazzy-looking plastic or metal cases for them. Instead, I have to use off-the-shelf components and that costs more.
This has nothing to do with the nature of the standard, it's just the reality for any niche electronic product.
Of course, the more people there are who are interested in Lib-Ray, the more likely it will be that a cheaper player will be made available, and even the prices on off-the-shelf components can be expected to drop. So the players will get cheaper, though probably never as cheap as the Blu-Ray player you can pick up from Walmart.
I haven't made a final decision on this. My preference is to just use the GNU/Linux ext2 filesystem. If I can't find any compelling reason not to, that's what I'll use.
FAT filesystems are more common on Flash media, and would probably be the least surprising choice, but I can't find any other compelling reason to stick to them, and they have some annoying limitations.
ISO filesystems (as used on CD, DVD, and Blu-Ray) are not very practical because they are designed to be read-only. They basically pack the data in with no gaps to allow for extensions as data is written to the disk. There may be some workarounds for this (such as the multi-session standards), but it's probably not worth the trouble.
There are more recent standards like ext3, which supports journaling. However, journaling is only really useful for frequently-written disks (caches, home directories, and so on), as the point of the journal is to ensure stability if power is lost during a write operation. Lib-Ray needs very little re-writing, so why waste the space on a journal?
There's a number of troubling possibilities when getting into HTML5 because it's a huge standard, serving many purposes. But the truth is that I do not plan to use a very large range of HTML5 options. The idea is to use just that part of HTML5 needed to implement the menu system.
My first prototype ("0.1") was based on the concept of using HTML as a menu-system only and actually launching a separate "helper app" everytime we need to play a video. This possibility is still on the table for the current prototype.
The second version ("0.2"), instead embedded the video inside of a video object in HTML5 pages. This had the great advantage that it (almost) worked in the Chromium browser I tested it with as-is. In fact it did about 80% of what it was supposed to do. But subtitles did not work, I could only play one soundtrack, and it only supported Vorbis sound. Plus, it arbitrarily limited the number of tracks in the video file (video, audio, or subtitle) to 20. I have no idea why.
Things got fairly baroque fairly quickly.
So, I decided that it was probably going to make more sense to make a custom player.
I will be using Webkit to handle the menus and the menus will be in HTML. However, I do not intend to rely on any of Webkits internal extensions, nor do I plan to use more esoteric parts of HTML5. What I will be focusing on is just the bits that apply to embedding video in the menu system -- and if that becomes too complicated, then I will return to the "bridge" approach I was working with in the 0.1 prototype.
Also, Lib-Ray will never be a standard for serving video over the internet. I am using HTML as a menu system, not implementing a new general-purpose web browser. In fact, I will probably be implementing a security/privacy feature which is to block external contacts and links from the pages that form the Lib-Ray menu system.
The "Extra" part of the disk will allow for a little more leniency, but even here, I plan to have an option to shut down external contact.
Absolutely! This is open-source / free software.
I do not yet have a project hosting site. At present there's a website that still needs some love and a rather anemic wiki. Most of the documentation is still in articles in my Free Software Magazine column -- http://www.freesoftwaremagazine.com/articles_by/5
But if the Kickstart succeeds (and maybe even if it doesn't), I will be creating one. Most likely it will be on either Sourceforge or Google Code (because I already have accounts on both of these). I don't anticipate this being a huge codebase, and quite a bit of what is needed are actually contributions to other, existing projects, so I don't know if we should host those as patches or just contribute them directly to those projects.
I expect the project to be small and focused on the concrete goal of creating a reference implementation. I do not want to get into the business of maintaining a distribution or a general purpose media center. Rather, I would like to create something that can be plugged into existing distributions and media centers to add Lib-Ray support to them.
GNU General Public License, version 3 (or later).
Creative Commons Attribution-ShareAlike, version 3.0.
This is what Wikipedia uses, and is pretty much my default choice of license for my writing in any case.
In general, no. It's included for both domestic and international shipping. Of course this means I have a thinner margin on international orders, and so if you want to voluntarily add another $10 for the shipping, I appreciate that. But it's not required.
I decided to keep things simple and set single prices for the items offered on this Kickstarter. This partly works because they are relatively lightweight for their cost, so the shipping won't be terribly high, even for international addresses.
The only serious exception to that would be the PLATINUM sponsorship levels with players. Although I believe I can send these to any address, there may be some issues or costs relating to customs (because these are large electronic items and may be subject to customs tariffs in some countries). If so, you will need to pay for these -- but we can make separate arrangements if problems come up.
Depends on how you look at it. First of all, you need to remember that that's the "top line" not the "bottom line". I don't get to keep all of that money -- quite a bit of it will have to be spent on the project materials or on fulfilling the specific rewards.
About 10% goes to Kickstarter and Amazon Payments for the Kickstart service.
The raw materials for the "deluxe" Lib-Ray releases with card, packaging, and labeling will cost in the neighborhood of $15 to $25. For the economy/compact case, it'll be more like $10-$15. Then I have to pay for shipping -- possibly to the far corners of the Earth and/or sales tax (at least for backers who live in Texas). That means the margin on those (how much I actually make to support development) is just around 50-60% -- similar to a retail mark-up.
A similar situation applies to the HTPC builds I offer at higher reward tiers -- computer parts can be pricey. And even if I don't get orders for those, I will still have to build a couple of them to do performance testing and demonstrations of the technology.
Of course, when people simply donate money directly for no reward or for purely digital rewards like "backer credit", then the margins are much higher and I can put more money directly into development, but I can't control that -- it was entirely possible that the project would be funded completely by people choosing deluxe editions of "Sita Sings the Blues".
When you take all of that away, what's left is about $8000 to $9000 for the minimum successful Kickstart. That's enough to fund me working full time on the project for about 3 months (or half-time for six months). I have bills to pay, and $3000/month is about what they cost. Some people will find that high, some will find it low -- I'm not going to apologize for that either way. It's just my actual cost of living.
As for it taking me three months, I think that is a reasonable and possibly even very conservative figure. In that time, I have to moderate and/or design a specification process, develop not one, but two software applications (a reference player and an authoring wizard) as well as creating necessary patches in dependent libraries to support them, write a specification document and tutorials for both software apps (basically a short book), and build and test computers to be sure everything plays as advertised. Then I have to do the artistic design and authoring of two separate Lib-Ray titles. That's a lot of detailed work that would normally be done by a team of specialists, and I'm proposing to do it all myself. So, I think I'll actually be getting off lucky if I really manage to do it in just three months -- which is why I padded the deadline a bit to make sure I wouldn't run over.
If on the other hand, I do want expert support on some of those phases, then I may have to turn around and pay someone else to do those things. I don't expect them to work for free. So I planned in some contingency funds for that.
I did initially go the route of doing this in my spare time and trying to attract the interest of open source developers. I didn't get much response, so I figured it was up to me, and I estimated what it would cost to justify the time I would need to take to do it myself. And then I added the overhead costs. And that's where the $19,000 comes from.
The thing is: taking the money from a Kickstart is a legal obligation to deliver on what you promise. I want to make sure I can actually do that. So I stand by my estimate.
A number of people have pointed out that at the sizes we are talking about it would be entirely possible for the SD/MMC card to contain an entire Linux distribution and that the menus could just be a program playing off of the media.
There are a few reasons this is not such a good idea -- for example, "it's complicated to author", or "there would be compatibility issues with different players".
But they're all trumped by one major objection I can put in just two words: "Trojan horse".
If you run code on the movie volume from your computer, you are putting a lot of trust in that volume. It would be a really tempting target for malware.
It would also support DRM or other anti-features like unskippable previews or warnings and the like, which is all part of what I'm trying to get away from.
So I want Lib-Ray to be more of a declarative standard -- that is, a data structure, with the software running on the player, in full control of the user. It's not clear if I will be able to do this perfectly or not, but any code on the disk is at least going to run in a sandbox on the player. I want to make sure the user stays in control.
Support this project
- (30 days)