CFFPP: linux.conf.au 2010

The call for papers for linux.conf.au 2010 has been open for a few weeks, and closes soon (July 24).

I really want to encourage some talks about functional programming! The conference has a pretty strong developer focus, and most talks are about a practical topic. More importantly, we're looking for talks that inspire people to try new techniques, to approach design and troubleshooting with clarity and vigor (yarr!), to boldly consider that they should perhaps spend some time honing their craft before writing yet another application that inexplicably fails at runtime -- all in a friendly and entirely non-condescending environment of hackers having fun hacking.

Here's some suggestions for the kind of talks that I think could be interesting:

• systems programming in Haskell/OCaml/whatever: how you wrote an interface to some hardware, handled lots of IO, controlled a robot, whatever
• functional programming for kernel development: verification, security etc.
• game programming: higher order design for 3D, AI etc.
• proof vs. testing: (can anyone do a tutorial on proof without greek letters? not that Patryk Zadarnowski's talk about the Curry-Howard Isomorphism a few years ago wasn't *awesome*, but as a result of that people are clamoring (clamoring!) for some advice about how to prove their programs have no bugs).
• some ... other ... practical benefit of functional programming!

The conference is in Wellington in January. January! it'll be windy, and it's in New Zealand!

Syndicated 2009-07-15 03:53:00 (Updated 2009-07-15 03:58:02) from Conrad Parker

Release: libfishsound 0.9.2

Fishsound has moved to Xiph.org! The new home page is at http://www.xiph.org/fishsound/. <h2>New in this release</h2>

This release contains security and other bugfixes:

• Security fixes related to Mozilla bugs 468293, 480014, 480521, 481601.
• Fix bounds checking of mode in Speex header
• Handle allocation failures throughout due to out of memory
• Added support for libFLAC 1.1.3
• Add conditional support for speex_lib_get_mode() from libspeex 1.1.7 If available, this function is used in place of static mode definitions. For ticket:419
• Check for Vorbis libs via pkgconfig, required for MacPorts etc.

Syndicated 2009-04-07 22:48:00 (Updated 2009-04-07 22:56:53) from Conrad Parker

A proposal for generalizing the byte-range referral HTTP Response header

Re: the Media Fragments WD. Here I am using the term "byte-range referral" for multiple concatenated HTTP requests, for the purpose of improving cacheability; this is called a "4-way handshake" in the current working draft.

Shortcomings of the existing byte-range referral scheme

The above WD, and the current Annodex scheme, are specified to allow sharing of non-header data between different temporal views of media resources. They limit the positioning of custom data to the media headers. different segments to have different headers, which is useful for Ogg but not necessarily so for other formats.

Even for Ogg, it could be useful to refer to the codebooks separately from the Skeleton for more finely-grained data re-use. Then a client can locally cache the codebooks and know not to bother retrieving them over and over; but to get the updated skeleton and keyframe data for temporal segment requests.

Hence, I am proposing that we should specify an ordered list of tuples of (URI, byte range) which the concatenation of is byte-wise identical to the byte contents of the requested URI

This response can also contain data, so if you want to refer to this response you can include a tuple of (this, range) where this is the literal string "this", and refers to the body of the current response.

This syntax then allows the server to include parts from many different URLs. The custom data is then centralized in this response, and can be used for any parts of construction of the response so that it can be used for tail data (such as ID3 tags, divx seek tables etc.)

List and tuple separator characters

The list separator should be commas, as this then allows the list to be separated over HTTP response lines (without re-ordering).

Hence the tuple separator should not be commas; it can simply be whitespace:

Range-Referral: http://www.example.com/video.ogv?headers 0-1280
Range-Referral: http://content1.example.com/video.ogv 5380-48204
Range-Referral: this 0-950
Range-Referral: http://content1.example.com/video.ogv 60880-238382

By comma replacement, this set of headers is equivalent to the single header:

Range-Referral: http://www.example.com/video.ogv?headers 0-1280, http://content1.example.com/video.ogv
5380-48204, this 0-950, http://content1.example.com/video.ogv 60880-238382

Interpretation of other response headers

The body of this request is simply all the custom parts for this view, concatenated bytewise. The Range-Referral header explains how to use this data.

Content-Length: is the length of the body.

A Range request is made relative to the body. So for example a client could just do a HEAD request to get the Range-Referral headers, and then do multiple Range requests to retrieve the reqired parts in sequence (rather than locally caching all the data for tailers etc.). Coherence of the concatenated responses can be assured by the use of existing HTTP/1.1 caching identifiers.

So, this constructed response is only special in that a user agent knows how to use it in conjuction with other URI response data to display a media segment. Otherwise it is standard HTTP, and can have caching headers/tags attached, be cached by intermediate proxies, and itself be the subject of range requests.

Generalization to other segment types

This mechanism allows a complex sequence of byte-ranges to be specified. It explicitly marks data ranges which are re-usable, allowing them to be cached. It generalizes so that any complex data subview can be served, where re-usable data is keyed canonically and can be cached on the network.

For example, it may be useful for specifying the data for a spatial subrange of video.

Syndicated 2009-04-07 16:32:00 (Updated 2009-04-07 16:44:06) from Conrad Parker

liboggplay, liboggz, libfishsound migrated to git.xiph.org

The source repositories for some Ogg libraries developed as part of the Annodex project have moved from from svn.annodex.net to git.xiph.org. These libraries are:

• liboggplay, an Ogg Theora playback library used by Mozilla Firefox;
• libfishsound, a simplified API for using audio codecs, used by liboggplay and the by the DirectShow Oggcodecs; and
• liboggz, a library for seeking, reading and writing Ogg (used by liboggplay), and tools for managing Ogg streams. This includes oggz-chop, which is used by various sites including the Internet Archive to serve Ogg files.

Reasons for the migration

Xiph.org, which develops free codecs (Ogg Vorbis, Theora, Dirac, Speex, CELT, FLAC), already provided the hosting for Annodex.net projects. The move to the xiph.org domain reflects that these libraries are recommended for general use by projects requiring Ogg support.

The move from Subversion to Git allows for distributed development, letting developers without write access to the central Subversion repository develop code using a version control system, and making it easier for developers and packagers to track multiple independent changes. Among distributed version control systems, Git was chosen for its flexibility and popularity. It is already used within Xiph.org for Speex, the ultra-low latency, high quality audio codec CELT, and the experimental text overlay codec Kate.

Checking out the sources

To do a fresh checkout of the code, make a new git repository This assumes that you begin with an empty working directory:

$ git clone git://git.xiph.org/liboggz.git

Adding a remote to an existing git-svn checkout Many developers already used git-svn to access the previous svn repositories. In this case you will already have a local git clone of the sources, perhaps with your own local changes. In that case, simply add a new remote to your existing repository, eg.:

$ git remote add xiph git://git.xiph.org/liboggz.git

Syndicated 2009-04-03 06:13:00 (Updated 2009-04-03 06:17:52) from Conrad Parker

Discovery and fallback for media segment addressing over HTTP

This post concerns the use of queries or fragments in the URI specification for accessing segments of media over HTTP. We outline the user-visible differences between the two approaches, including the form of the URIs seen by users in each scenario and the consequent user interface activity, and then explain the HTTP request and response mechanisms that result. The purpose of this analysis is to better understand the trade-offs in usability and the impact on network performance, with reference to existing implementations rather than hypothetical scenarios.

I will make the case that the user-visible differences between the two syntaxes are immaterial, and that a more important distinction is that they induce different protocols. I will also claim that the use of the fragment syntax introduces unnecessary complexity in that it lacks a discovery mechanism and has no useful fallback to existing HTTP.

User-visible differences

We are constructing a URI syntax for addressing segments of media data. Taking the simple case of addressing some video content beginning at an offset of 10 seconds, we consider the two forms:

• Query syntax: http://www.example.com/media.ogv?t=10
• Fragment syntax: http://www.example.com/media.ogv#t=10

For simplicity here we are using a shortened segment identifier t=10; I touched on the topic of segment identifiers in a recent article about pretty printing durations.

Regarding the direct HTTP semantics of these two forms, if the user is already viewing the specified media.ogv, the query syntax reloads the portion from 10 seconds as a new resource, whereas the fragment syntax modifies the view of the current resource.

Although developers are rightly wary of a page refresh due to the time required to render complex HTML, in practice no visible change occurs when reloading a video. The query syntax has been used to control video seeking in JavaScript (using the Java cortado video player plugin, or an earlier Oggplay plugin), and also natively in the current Firefox 3.5 implementation.

In any case, this distinction is only user-visible if the video is the top-level resource. In the common case of a web page that embeds a video, the user-visible resource is the HTML page. In this case, the mechanism for controlling video is under the control of the embedding web page via JavaScript.

For example, URIs to YouTube pages allow a time segment to be appended using a fragment syntax. However, this fragment is used by JavaScript to control the embedded Flash video player; the mechanism for then retrieving video data is then managed by the Flash player. Similarly, in HTML5 Ogg <video> implementations, a fragment identifier appended to the HTML page may be interpreted by JavaScript to control seeking in the <video> source using a non-fragment mechanism, like query syntax.

Differences in request mechanisms

Either way we introduce a new behaviour that user agents can use to retrieve media segments over HTTP.

When handling a media segment which is specified by a query, the user agent initiates a standard HTTP request. It connects to port 80 on the specified host, and uses the entire path, including the query specifer, in the GET request. The server then begins transferring the required data representing that segment of the media.

To retrieve the URI http://www.example.com/media.ogv?t=10:

GET /media.ogv?t=10 HTTP/1.1
Host: example.com

However the proposed request mechanism for handling a segment specified by a fragment is not standard HTTP. In conventional HTTP, a fragment specifier is stripped by the user agent and not sent to the server at all; rather, the server sends the requested response (representing the entire resource), and after retrieval, the user-agent uses the fragment specifier to select the view shown to the user.

A recently proposed behaviour for handling media segments involves placing the segment specifier into the Range HTTP Request header, with a new units of seconds.

To retrieve the URI http://www.example.com/media.ogv#t=10:

GET /media.ogv?t=10 HTTP/1.1
Host: example.com
Range: seconds=10-

Response mechanism: byte-range redirection

The byte-range redirection response mechanism involves identifying parts of the segment view which are byte-wise identical to the original resource, and specifying redirections to those.

How discovery works

A user-agent will only receive a byte-range redirection response if it has indicated that it is capable of interpreting that, by including an extra HTTP request header. For example, here using a media segment URL specified with a query parameter:

GET /media.ogv?t=10 HTTP/1.1
Host: example.com
X-Accept-Range-Redirect: bytes

If the server is capable of handling the byte-range redirection mechanism, it will do so and indicate that it has done so explicitly in its response headers.

Query syntax has a sensible fallback to standard HTTP

However if the extra request header is not present, the server will simply send an entire response corresponding to the requested segment. Similarly if the header is present but the server is not capable of this new mechanism, it will simply continue with a standard HTTP response. The client can tell if the response is a segment response or not by the presence of an acknowledging response header.

If either client or server does not understand the byte-range redirection protocol, the request falls back to standard HTTP and the required segment is correctly returned. The cost of this fallback, compared to the case where both client and server understand the new request/response headers, is a loss of cacheability for subsequent overlapping segment requests.

Fragment syntax has a high cost of failure

The mechanism involving the fragment specifier does not have a fallback to standard HTTP: if the client does not understand that it should add the Range header with newly defined units, then it will end up simply requesting the entire resource. Similarly, if the server does not understand the new header then it will simply respond with the entire resource. If the cost of failure is to download some number of hours of extra video, as it would be in the case of MetaVid's congress proceedings, that is a prohibitive cost. Summary

• The distinction is one of protocol mechanism
• For the common case of video displayed in HTML, the distinction is not user-visible
• The use of fragment specifiers do not have a fallback to standard HTTP
• The cost of discovery failure for fragments is high (retrieval of entire resource)

Actions

• To clarify within the Media Fragments WG how queries can be used effectively, for both considered user scenarios.
• To consider how the byte-range redirection mechanism can be generalized for other segment specifiers, such as spatial regions.

Syndicated 2009-04-01 06:56:00 (Updated 2009-04-01 07:04:27) from Conrad Parker