Share this project

Done

Share this project

Done
Lib-Ray: Non-DRM Open-Standards HD Video Format's video poster
Play

A free software fixed media format for HD video, based on open standards, with metadata and localization but no DRM restrictions Read more

Grandview, TX Software
Share this project
467
backers
$21,421
pledged of $19,000 goal
0
seconds to go

Funded!

This project was successfully funded on June 3, 2012.

A free software fixed media format for HD video, based on open standards, with metadata and localization but no DRM restrictions

Grandview, TX Software
Share this project

Recent updates

Photos

34942c0cb0db485098d2ca0220e40ca3 original
3efcdefe7fde0131c2553db814eae247 original
183ec337be7d999e586d1bdc19dad12a original

Rocket/VLC-Standalone Python Extension Module Completed

7 likes

Last year, I announced the decision to use the Rocket library for menus rather than WebKit, primarily for security reasons, although it's also worthwhile to make the package simpler to write and easier to read -- which is important if it's to do a good job as a reference implementation.

Rocket solves these problems by being a much simpler, thinner interface layer (it really is just the renderer -- actually following links will be handled by callbacks to my code, which allows me to completely control the browsing process, making it both easier to write and more secure).

What I did not mention in my previous post (because I did not realize it until I started running tests in early December), was that Rocket is actually not a complete Python extension module. This is not really clear from the documentation (I may have to do something about that!), and I just figured I was having some trouble initializing it correctly (after all, the demos ran fine). Well, it turns out that, for me, "Rocket is only half a rocket-ship". The other half has to be provided by a backend rendering library -- something like OpenGL or SDL2. And that work has to be done in C++, you can't fix it from Python.

So I needed to get the other half of the rocketship built.

I was stuck on that for awhile, but ended up commissioning Tom Mason, who is the author of "Freeablo" (a free-software alternative to the Diablo game engine), and who therefore has C++ experience with Rocket and the SDL2 backend, which is what I wanted to use.

He released this to me just last week, and I've been running tests with it. Everything seems to be working exactly as it should, and it even works in the same logical X Window as VLC, so integration of menus and playback is very smooth and quick.

So this part is now done.

I wish I could do justice to how much better and easier this makes my situation!

There is still quite a bit of Python code to write, but it is much simpler, more familiar to me, and all focused on getting the desired Lib-Ray player behavior.

This will become a new "ichinose" branch in the SVN, as soon as I get the source organized. Here's a block diagram of this new Rocket-based architecture:

Rocket-Based Lib-Ray Player Architecture
Rocket-Based Lib-Ray Player Architecture

The orange "Rocket-Standalone" is what Tom Mason just completed, which allows all of the C++ stack to fit together. The Python layer above that are existing Python bindings for these libraries. The Lib-Ray Player Python application sits on top of that -- and that's what I'll be working on over the next month. Some pieces of this, like the Volume Object Model and the Localization code can be used with little or no re-writing. The "Menu-Browser" and "Video" modules will pretty much have to be completely re-written (although they will now be a lot simpler and easier to understand).

I will add support for infrared remote controls (probably based on "liRC") as well as mounting and automounting the UDF volume file-systems after the basic stack is all working with pre-mounted volumes and keyboard/mouse control.

I guess the stickiest part now is that I'm going to have to do some translation to go from a more standard XHTML+CSS markup on the Lib-Ray volume to the RML+RCSS markup that Rocket understands. This is mostly a subset, which I could just declare to be standard for Lib-Ray. But there are some oddities that need to be seen to:

1) Background images are handled in a non-standard and more complex way. This is undesirable since Lib-Ray menus will probably use them extensively. So I'll need to fix this in the filtering process.

2) Rocket doesn't actually understand hyperlink ( A-HREF ) tags at all, it just allows you to set event handlers on any element. So my filter will need to find the tags, read the URLs, and assign handlers.

Those are simple, easy-to-test text-filtering tasks. Very familiar territory.

After that, I'll need to implement hyperlink navigation, including dispatching my special URLs for sending messages to the VLC video player. Of course, this fine control over navigation was one of the main reasons to choose Rocket.

I'm hesitant to make projections because of all the ones I've made that have fallen through on this project, but I really do think I'll be done with the player by the end of March now.

Menu Internationalization Testing

2 likes

I've completed the primary work on internationalization tests for Lib-Ray. After much searching for a better alternative, this is a combination of using ElementTree and simple regular-expression-based corrections to the output. The result works very neatly, as you can see (these are from the test example included in the module -- I'm not quite sure if I can or should try to convert this to a self-checking unit test or not).

BTW, the translations are mostly by me at this point, using online resources, and I obviously don't speak all of the 12 key "language system" languages that will be included in all Lib-Ray players. So I will be soliciting corrections from native speakers sometime soon!

The mechanism is very simple. The most important thing to internationalize in Lib-Ray are the functional button labels. This context allows for unambiguous vocabulary-based translation. An attribute is added to an HTML element, and if recognized, the text within the element is replaced with the localized text. At present, the attribute is "label", although I'm reviewing whether that's the best choice in terms of HTML and XML standards (other possibilities: "id", "libray:label", etc).

One nice thing about this is that it really is not dependent on the author of the release to do the internationalization. The button text is changed by the player itself, so the internationalization and localization is just done there. As long as you have a language pack for your locale installed, all Lib-Ray volumes will have their buttons correct for your locale.

There is one issue for authors to consider: the length of words may be quite different. You can see here that the Russian and Chinese for "PLAY" differ by a lot in size on screen, for example. This will be something to take into account in designing your menus.

A secondary mechanism for authors to provide alternate text for different languages is yet to be developed, but should be possible using the same ElementTree-based manipulation of the source menus (and I think there is already a standard way to do this in HTML, so we'll just honor that, if that's true). However, I'll probably defer that until after we have a working player released.

Testing Menu Localization
Testing Menu Localization

Switching the Lib-Ray HTML/CSS Menu Rendering Engine

7 likes

After much deliberation and quite honestly, a bit of quiet whimpering, I have made the decision to remove WebKit from the menu part of the player, and replace it with a different solution based (probably) on librocket. This has been bugging me for a really long time, and I think it has to be done.

Although I have just about got it working, I have realized that I really am afraid to release it. There's way too many potential security holes introduced by using a full-fledged browser engine for our menus, because a modern browser can generate calls out to the internet in so many different ways. And I'm not likely to feel any better about it later, which is the thing I had to work around to. I've been thinking this could be a supremely stupid thing to do. Lib-Ray has enough PR trouble from running this late, not to introduce more by making it into an infamous malware vector!

Sometimes, I have realized, those nagging doubts are telling you something real, and you should listen to them.

The Lib-Ray menus are supposed to be a "safe" environment, so you shouldn't have to worry about exploits that reach out to the web from your movie's player menus. I knew this, but I was very worried about the extra difficulty of re-developing the HMTL rendering capabilities, as I feared the alternative was to develop the renderer from scratch (or try to extract it from WebKit, which would be no small task for me).

However, I'm now investigating a library called "librocket", which provides HTML/CSS-based rendering, but only that -- it was originally targeted at producing user interfaces for games. It will take some evaluation to decide for certain that it can do all of the things that Lib-Ray requires, but the more I look at it, the more I think this is a much better deal than the mass of work-arounds that is currently my WebKit-based solution for menus.

Librocket is an HTML/CSS based GUI library targeted mostly at games, and looks like a better option for Lib-Ray menus.
Librocket is an HTML/CSS based GUI library targeted mostly at games, and looks like a better option for Lib-Ray menus.

This also means a switch from an "opt out" approach to network security to an "opt in" approach. In other words, any calls made to the internet will have to be added by me, rather than me having to patch every possible unwanted connection and behavior. Metaphorically, using WebKit is like taking a basket and trying to tape up all of the holes, whereas using librocket will be like taking a metal bucket and punching any holes I find I need. This is a MUCH safer approach.

I'm a little sad to be throwing away months of tinkering with WebKit, and I might not ditch it entirely. It could for example be a good way to handle the unsecured "Extras" parts of volumes or for actual web-browsing (easier than implementing a browser back-end for librocket, certainly). But using different software for menu-browsing versus web-browsing creates a much better firewall between the two activities. So that's probably a much better approach.

There are a few tradeoffs with librocket. It has not been available as free software for as long (re-released under MIT license, 2010), and so distribution packages are not available. Thus, I will probably have to provide packages for it myself as well as build it from source for development. It expects menus to be defined in an XML-compatible syntax, which means a partial move to a more XHTML-based format for Lib-Ray menus (not actually sure this is a bad thing, especially given the acceptance of DRM video into HTML5, but it's a change from the proposal). I'm not sure yet how limiting that is likely to be.

However, the librocket library also has other advantages besides security. The documentation is much better, especially for the Python bindings (because those are basically non-existent for WebKit). The code will be much simpler, as I can now get rid of the horrendous "fake client-server architecture". Librocket has a simple callback architecture, like most GUI libraries. That's a big advantage, since the point of this code is largely to be read by other developers who want to create new implementations. Since it was designed to overlay menus on game graphics, it may make it feasible to create animated menus and other effects that are awkward with WebKit.

As for the impact on delivery, I actually think a complete librocket implementation is going to take less time than making the WebKit version safe enough to release. Certainly it will allow me to concentrate on what should be the top priority, which is defining the allowed menu language -- something that has been dragging considerably because of the relative inflexibility of the WebKit approach. I know this has been a long time in coming already and it's long overdue, but I strongly feel that the security and quality concerns have to come first.

Progress: Lib-Ray Player

5 likes

Progress for this week on the Lib-Ray Player software:

  • Continued writing doctest unit tests in model.py
  • Session, Volume, Archive tests passing
  • Volume now recognizes and reads test volume, with necessary paths and metadata for playback
  • Archive can copy or delete volumes from player's on-disk Lib-Ray volume archive
  • Added vocabulary.py with a starter set of labels in the 12 "language system" languages (English, French, Portuguese, Spanish, Russian, German, Arabic, Swahili, Chinese, Japanese, Hindi, and Indonesian/Malay). This is needed to test Menu, Server, and Browser objects.

No doubt I've made translation errors (I used a combination of VLC's po files and Google Translate to try to figure out the correct context-specific words for the function labels that Lib-Ray needs, but obviously I don't speak all of these languages). The real system will need to have a .pot/.po import/export script so that the formats are gettext-compatible, since that's what most open-source translators are used to. But I wanted a starting set for testing, and a fallback to begin with.

I will have to make a decision this week about how to do the actual language label substitution. I was considering trying to use SimpleTAL for this, but the downside is that it would restrict the syntax used in the actual menu HTML files, and I'm not sure the TAL format is appropriate in the Lib-Ray standard.

I'm currently favoring using the Python html5lib module to parse an "ElementTree" from the HTML and re-write it that way. Another approach is to inject Javascript to make the changes (note, this Javascript would be part of the player, not the Volume -- it doesn't violate the declarative/no-code-on-disk paradigm).

The nice thing about either of these approaches (as opposed to TAL) is that they don't constrain the syntax in the actual menu HTML -- so I can just choose that to maximize clarity. I need to check namespace issues, but something like "label=" or "lr:label=" is likely how it will look.

The downside is that they are more manual and require a bit more than a simple template library call (I will have to create a tree iterator and do text-substitution in the ElementTree object, then regenerate text to be served by the Server object). It may actually be faster than a SimpleTAL call, though, because ElementTree is more widely used and has been optimized more.

This next week should see me adding the localization and finishing up model.py.

After that is integration with the existing Player/Browser/Server/Cinema object system that encapsulates the technical interfaces to the WebKit and VLC libraries (these were tested earlier with hard-coded links to the volume -- now the paths will be found by making calls into the model objects, which allows for loading and switching volumes, etc).

At that point, the player should work on PCs with keyboard or mouse input, and the focus will shift to input methods and compatibility with IR remote controls.

Update for 2014

2 likes

Hello,

This is Rosalyn Hunter, co-producer of the Lib-Ray project with an update.

This last December, the Lib-Ray facility suffered a fire that damaged some equipment and set back our production. Luckily, our prototype machine and our main computer was salvageable. We are in the process of reassessing our assets and backing up data. We will update soon .

The Lib-Ray project is NOT dead. Unfortunately, we have not proceeded at the optimistic rate that we first expected, but we hope that you will bear with us. The climate for free media production and distribution has gotten no better since we introduced this project. The news that the MPAA has joined the W3C and introduced DRM into HTML5 was not welcome, and we need Lib-Ray more than ever. Please believe that we have not given up on an internet where producers of content can distribute their work without restriction. We are continuing to believe in that dream.

I wish to thank all of you for your support and your patience. We will be posting more frequent updates, and I will try to reply to your requests as soon as I can.

Thank You.

Rosalyn Hunter

Some technical progress notes from Terry Hancock:


  • There is a branch called "otonashi" on the Google Code server which is what I am currently working against.
  • After many attempts, putting the "test fixtures" into Subversion was a lost cause. Subversion (or Apache or my Browser or whatever) doesn't like the large file sizes. This is a problem we had on "Lunatics!" as well, and since I operate the SVN repo for that project, I did some tests there as well. I think I finally know what I'm doing with it.
  • In the end, I decided to simply provide the fixtures as a downloadable package (there's little to no code in it anyway).
  • Google Code discontinued the package download option for projects this month.
  • Long story short: I'm now hosting the fixture package on our own server (see Lib-Ray Software page). Keep this software page rather than the deep link in case we change where the files are hosted. The software package releases will be here as well when they are ready.
  • With this package finished, I have started writing unit tests for the "model" module, which contains the abstract object model (or object database if you like) for the player.
  • Although the test package won't be much use until I've checked in these tests, you might enjoy the 1-minute "Free Culture Sampler" video it contains. We need about a minute to test the quality-testing parts of the wizard software.
  • The technical modules have been tested and working for some time now, but aren't very interesting because all of the paths are hard-coded for testing only.
  • After "model.py" passes unit tests, all the hard-coded paths will be converted to model calls to get the correct information.
  • The first released version probably will not auto-mount Lib-Ray partitions, but have to be told the location of a mounted partition.
  • Of course, that will be fixed in later releases (code will be added to scan the USB bus for new devices, mount UDF filesystem devices, and then check to see if they are indeed Lib-Ray volumes by looking at the contents).