LWN.net Weekly Edition for October 15, 2015

A simpler playback tool for GStreamer

The 2015 GStreamer Conference was co-located with LinuxCon Europe in Dublin. As usual, the sessions consisted of a mix of development updates, experiments, and reports from GStreamer users about new or interesting uses for the framework. In his talk, core developer Sebastian Dröge introduced the new GStreamer "simple playback" API, which he has designed to increase GStreamer adoption by other free-software projects and to appeal to end users who may think of GStreamer solely as a lower-level component.

The problem, Dröge explained, is that more applications should be using GStreamer—but real-world experience has shown that many developers find it too complex to use. In particular, one job that GStreamer should make simple is the no-frills, no-special-mixing-or-processing task of playing a standard media file.

Dröge then proceeded to examine the GStreamer support currently implemented in several popular media players. Totem's GStreamer back end is 6,000 lines of code. Rhythmbox's GStreamer support takes 7,000 lines of code. Banshee's support requires 5,500 lines. And those are applications that can already take advantage of GStreamer's existing high-level playback element, playbin. Clearly, there was room for improvement.

Thus, Dröge set out to develop a simple playback component akin to Android's MediaPlayer, iOS's AVPlayer, or QML's QMediaPlayer. The goal, he said, was to make it possible "to write a media player in four lines of code." The result of that effort is the gst-player API—and, just for good measure, a cross-platform media-player application named GstPlayer.

The API intentionally masks away as many GStreamer internals as it can. No sources, sinks, pads, pipelines, or elements. Developers see only a set of GObject interfaces: functions, objects, and signals. gst-player offers four operations: play, pause, stop, and seek (to a specified time in the media). There are setters and getters for the current position in the stream, the duration of the current media, and the URI of the media. GObject signals are emitted for end-of-stream (EOS), errors, successfully jumping to a new position, and for updating the buffering status.

Internally, gst-player handles network access, buffering media streams, and synchronizing clock sources. The API is totally asynchronous, he said, and supports integration with all of the major toolkits on the platforms that GStreamer itself supports (currently Linux, Android, Windows, OS X, and iOS). The code also supports GObject introspection, so language bindings are automatically available for most languages.

Also included in gst-player is a simple API for accessing information about the media file or stream being played, such as frame rate, resolution, tags, and whether there are multiple streams embedded (e.g., several audio tracks). Dröge added support for a handful of other functions, such as fast forward and rewind, controls for adjusting brightness, contrast, and saturation, and hooks for displaying a visualization when playing an audio-only file.

The feature set is designed to support what a desktop media player would need, and the GstPlayer application is, in essence, its built-in test case. There are front ends to the program for GTK+, QML, and the Linux command line, as well as Android and iOS apps. The interface is intentionally minimal: one uses it to open and play a file. But it is modern in its styling—for instance, the Linux version uses transparent overlays for its playback controls, rather than static GTK+ or Qt menu bars.

Dröge said that the plan was to merge gst-player into the GStreamer 1.8 plugins collection, starting out in gst-plugins-bad (where most experimental work debuts), then moving to gst-plugins-base once it has stabilized. He encouraged everyone to test it out and file bugs for all missing features.

On that front, the Q&A period at the end of the session was filled largely with audience members asking about specific features (gapless playback, setting rate-limits for streaming, etc.), almost all of which Dröge said were already on the to-do list. Despite the fact that gst-player is still experimental, there has evidently already been quite a bit of interest from developers. For one thing, Totem maintainer Bastien Nocera has filed tickets for more than a dozen missing features, and plans to migrate Totem to gst-player once they are implemented. Furthermore, Samsung has developed a media-playback back end for Chromium that uses the API.

Further work remains even outside of that to-do list, though. Dröge said that the GstPlayer front-end applications will probably need to graduate to their own repositories once they reach maturity; he hopes to get them packaged individually. The Android and iOS apps, he said, need UI work and perhaps more before they can be submitted to their platform's respective app store.

But making those apps available to the public is the end goal. Dröge noted that the playback application can automatically play any file format and any codec that GStreamer itself supports—which is a lengthy list. He challenged GStreamer developers to view GstPlayer as something that can take on VLC for regular users—a sentiment that came up more than once during the conference. Tim-Philipp Müller, in the conference's opening "state of GStreamer" talk, also raised the point that GStreamer is not the go-to choice of users who need to play an arbitrary media file and expect it to "just work."

VLC currently fills that role for many, even on those platforms where GStreamer is most robust, like the Linux desktop. Evidently the GStreamer project has finally decided to tackle that disparity head on. In the past, GStreamer's powerful pipeline-processing capabilities have been a major selling point, but may have proven intimidating, too. A simple interface—both in the sense of the API for developers and a media player for users—could go a long way toward changing that dynamic.

No firm timeline for GStreamer 1.8 has been published yet, but the project did announce at the conference that it will be trying to move to a more rapid, roughly six-month release cadence, which means a stable version of gst-player could arrive early next year.

[The author would like the thank the Linux Foundation for travel assistance to attend GStreamer Conference.]

Comments (14 posted)

What Linux developers need to know about UEFI 2.5

This year's LinuxCon Europe included a "mini-summit" about working with the Unified Extensible Firmware Interface (UEFI). The UEFI specification defines the modern replacement for BIOS and handles hardware initialization before the operating system boots. Therefore, many of its features can impact how an OS functions. At the mini-summit, Jeff Bobzin presented a session on "what Linux developers need to know" about the new 2.5 revision [PDF of considerable size] to the UEFI specification.

Bobzin described himself as being "literally an old BIOS guy: the companies that I sold my first BIOSes to have been gone so long that no one even remembers the names." He got interested in UEFI ten years ago, he said, specifically because of its ability to adapt to the needs of a wide range of computing platforms, from embedded to large clusters. The next version of UEFI includes features requested by computer manufacturers, silicon suppliers, and BIOS companies, but it also contains features requested by OS vendors, which are likely of use to Linux developers.

Bobzin briefly sketched out how the UEFI specification is made and amended. It starts with input from the various member companies (from the categories listed earlier), then proceeds with multiple rounds of draft writing and proposals, followed by edits and reviews. By the time the final update is published, hopefully, working implementations are ready to follow right behind.

This time, during the input phase, the UEFI committees heard three things from OS vendors. First, while the security features of Secure Boot (SB) are working well, provisioning keys to SB-enabled machines is not—it is particularly painful for large enterprises provisioning multiple machines at once. Second, the device firmware-update process is confusing and painful enough that many important firmware updates are being left unapplied, which poses security risks. Third, there are low-level tools like whole-disk encryption that are difficult to write because the UEFI bootloading process gets in the way. All three issues are being addressed in UEFI 2.5.

Provisioning

The SB provisioning problem is addressed by adding a new "audit mode" that the system can be placed into. In previous versions of the specification, a system can only be in Secure Boot mode (meaning that it is locked down) or in administrative mode (meaning that anyone at the console has full power to remove or add SB keys). The all-or-nothing security this offers was problematic for installers trying to provision many machines at once, who had to manually work through the UEFI setup screens (which vary by BIOS vendor) one at a time.

Audit mode is an intermediate boot mode, in which the booting system essentially performs a dry run of Secure Boot: all of the cryptographic checks are performed, but their results are simply logged rather than applied. A second, related new mode called Deployed mode has also been added. Deployed mode is locked down as in Secure Boot mode, but the system can still be re-provisioned if necessary.

The goal is that installers can at least partially automate key deployments; in Audit mode, systems can be tested en masse, but cannot accidentally be put into an unbootable state. Deployed mode allows one final opportunity to fix mistakes before putting a machine into service. Bobzin noted that UEFI considers this bulk-deployment scenario a high priority, but that it would not be releasing any mass-provisioning tools itself.

Audience members inquired about where the Audit mode logs are stored and about how vulnerable machines in Audit or Deployed mode were to potential attackers. The Audit logs, it seems, are only required by the specification to be stored in memory; BIOS vendors may choose to provide other options (such as saving to attached storage), but that is not required. As to the prospect of attackers interfering with Audit- or Deployed-mode machines, he said that provisioning must absolutely be done in a secure environment—as is the case today. If attackers are permitted to access the machines before they are provisioned, there is nothing UEFI can do.

Firmware

The firmware problem is shared by administrators of large deployments and by individual users alike. The root issue is while BIOSes have long allowed the user to install firmware updates (for the system motherboard and for attached peripherals), the process for doing so is inconsistent and manual. Users only learn about new firmware if they visit the OEM's web site and see an announcement; they then have to decipher the OEM's firmware version-numbering scheme to make sure that the firmware they download matches their hardware and is, indeed, newer than what they have. Finally, they have to navigate through the arcane screens of their BIOS to apply the update. The end result is that many firmware updates—including security-sensitive ones—are accidentally or intentionally skipped.

UEFI 2.5 addresses this by defining a standardized table (called the EFI System Resource Table or ESRT) that holds information on the firmware used in the main board, peripherals, and most expansion cards. Each device is identified by a globally unique ID and each firmware update uses a standardized version number. The ESRT table tracks the firmware version of each device and it stores the date and status of the last attempted update. This allows the possibility of automated updates, although the requisite security measures for such automation are still in development, starting with a verifiable "update capsule" package format.

ESRT requires manufacturers to participate, of course—making their firmware updates queryable and accessible in standardized fashion. But ESRT has already been deployed by several vendors, Bobzin said; making it part of the formal UEFI specification is designed to let the OS (and above) access the feature. The goal is to allow an OS to verify that the latest firmware update has been applied (such as one that closes an important security hole) or check that an organization's approved firmware version is in use. A Linux ESRT support framework is currently in development. Still to come, however, are user-space tools for downloading and installing new firmware releases, although some work has been started within Fedora.

System prep

The final OS-related problem addressed in the new specification is support for what are called "system prep" applications: low-level third-party code that needs to run after the BIOS but before the OS. Bobzin gave three examples: certain whole-disk-encryption implementations, set-up routines for disk-docking stations, and enterprise firmware verifiers. When developers tried to implement these applications in the past, they were stuck: when implemented as drivers, the code could not sufficiently interact with the user; when implemented as boot-order components (like a bootloader or the SB shim), the code was frequently trapped and disabled by OSes that viewed it as an attempted security breach.

UEFI 2.5 defines a "system prep" list of code to execute in the boot order; it is a different list than the OS bootloader list. System prep applications have access to some of the same hardware as the bootloader (notably the network, displays, and keyboards). There is an optional API for the application to request access to this hardware, so the BIOS can prompt the user to enter an access code or key before proceeding. How that "ask for permission" API will be enabled or disabled will likely vary between vendors. So far, these system-prep applications have not been widely deployed on Linux systems, but the OS still needs to be made aware of the change to avoid interfering with them.

Feedback

There are plenty of other changes in UEFI 2.5 (at least a dozen); enough that Bobzin said he had to choose only the most relevant to fit into the presentation slot. The specification was released in April, he said, but it can still be updated in response to real-world implementation experience. As a practical matter, it can be hard to find hardware shipping with UEFI 2.5 features so soon after the release of the specification, but for Linux to properly take advantage of the new capabilities, tests need to be done. He encouraged attendees to test the new features and to bring their feedback to the UEFI committee. "We don't exist in a vacuum; we need input from you OS developers, so let's figure out how to roll this out together." Some of the new features will likely be of greater use than others, of course, but Linux will at least need to be aware of all of them.

[The author would like the thank the Linux Foundation for travel assistance to attend LinuxCon Europe.]

Comments (none posted)

Permissive licenses, community, and copyleft

On the final day of LinuxCon Europe 2015, HP's Chief Technology Officer Martin Fink delivered a bold keynote about software licensing. Fink recapped the negative effects of license proliferation and addressed projects that use their choice of license as hostile act against the competition. He then ended the session with an extended appeal to move the open-source software industry away from permissive licenses like Apache 2.0 and toward copyleft licenses like the GPL. Not doing so, he said, puts the FOSS community at just as much risk of collapse as license proliferation threatened to in years past.

Fink started out by addressing HP's just-announced launch of the OpenSwitch project, a new "network operating system." HP is doing the project because it believes open source has "won"—at least in general—but that there are a few isolated hold-outs, including high-end network operations. OpenSwitch code is released under the Apache 2.0 license, he said, because the other partner companies viewed that as a requirement. That was a decision that he promised to return to in a few minutes.

Looking back to 20 years ago, though, Linus Torvalds chose to release the kernel under the GPL, rather than under a "permissive" license. That was a really big deal, he said, in light of the many alternatives. Fink asked the audience to guess, by a show of hands, how many "open source licenses" they believed there are. The correct answer is about 70, he said—depending on how one counts. One curse of the term "open source" is that it can gloss over all of the critical complexities involved, such as license details. But, he added, it was almost much worse.

The proliferation problem averted—mostly

License proliferation was so rampant ten years ago that Fink made a public plea at Linux World 2005 for the Open Source Initiative (OSI) to stop adding new licenses to its approved list. The problem, of course, is that each additional license increases the complexity of the ecosystem and, thus, creates a legal maze that makes it hard to participate. "If I had been Steve Ballmer, trying to kill Linux, I would have just encouraged people to make more licenses."

To its credit, Fink said, IBM responded to his call by stopping its practice of crafting new licenses. But not everyone did, he added. Oracle, in fact, is still creating new licenses: in 2014 it unveiled the Universal Permissive License (UPL). But the UPL does nothing new, Fink said. "If Oracle asks you to use it, tell them you will as soon as they license their own stuff under it. You'll find that conversation coming to a stop."

Another license used by Oracle, the Common Development and Distribution License (CDDL) originally written by Sun, is intentionally incompatible with the GPL, Fink said. So there are CDDL-licensed projects like ZFS and DTrace that "are great, but they can't be used" by the community.

The GPL incompatibility of the license demonstrates that some people have a residual fear of copyleft, he said, which is left over from the Steve Ballmer days. "So now I'm trying to get people over that. Copyleft is a simple, good thing: share and share alike." People who gravitate toward "permissive" licenses do so because "it feels safe." But what "safe" means in this case is that it allows them to go produce proprietary software. "So, in a way, we're enabling the very thing that we are trying to undo."

Permissiveness and community building

The Apache 2.0 license is currently the most widely used "permissive" license. But the thing that developers overlook when adopting it, he said, is that by using Apache they are also making a choice about how much work they will have to put into building any sort of community around the project. If you look at Apache-licensed projects, he noted, "you'll find that they are very top-heavy with 'governance' structures." Technical committees, working groups, and various boards, he said, are needed to make such projects function. But if you look at copyleft projects, he added, you find that those structures simply are not needed.

The difference stems from the fact that in Apache-licensed projects, "you've always got people who are trying to go off and do their own proprietary thing." That makes their contributions to the open-source project difficult to integrate and often at odds with other participants. In a copyleft project, such as the kernel, "there is no incentive to try and carve out your own little area." As a result, contributors just do their work and the project advances.

In the past few years, Fink said, the industry's default option has swung toward permissive licenses. "I'm calling out that you should change your default to a copyleft license like the GPL." Copyleft is good, he added; copyleft is what enables community. Fink did not distinguish between the different versions of the GPL in his comments; presumably because they are both strong copyleft licenses. The audience responded to the call for a copyleft default with a lengthy round of applause.

That brought his talk back to the OpenSwitch release. HP wanted to get networking companies and hardware suppliers on board. In order to get all of the legal departments at all of the partners to sign on to the project, he said, HP was forced to go with a permissive license. "But I hope that with some more education, people will see the self-governing, overhead-avoiding nature of copyleft, and we can get the pendulum to swing back to copyleft as the industry default."

Fink ended by making a charge directly to the audience. "Do everything you can to avoid license proliferation. When someone proposes a new license, resist it. If you need help, there are people like Eben Moglen who will engage them directly to change their minds." As for existing licenses, he had another charge to deliver. "All of you are enabled to change things. You can take an Apache-licensed project and go make a GPL version of it. Some of you will start new projects. When you do that, start them with the GPL."

Fink's comments, no doubt, will draw some ire from people who reside on the "permissive" side of the fence—either on the particulars of Fink's assessment of the Apache license or on the directness with which he encouraged attendees to take action in promoting copyleft licenses.

Regardless of where one falls on the spectrum, though, it was certainly refreshing to hear sharp critique of licensing issues, and to hear it from the main stage of a large open-source conference. Keynotes at industry conferences can easily lapse into cautious or bland territory that focuses on promoting one's new product line. Whatever else it did, Fink's keynote raised hard questions and challenged the listeners to take action; surely keeping licensing questions at the forefront of the FOSS community's conversation can only be good.

[The author would like the thank the Linux Foundation for travel assistance to attend LinuxCon Europe.]

Comments (162 posted)