Hokay, taking a slightly different tack—rather than moaning about the
bits of the proposal which appear incongruous, here’s something more
tangible (and arguably useful).
This is how I reckon it -should- work (and, obviously, is what I’m
speccing for Baird):—
Assuming the technical specs for actual content formats and over-IP
transport protocols have been settled upon, what we’re left with is
delivery of metadata and the UI to make it useful. Essentially, there
are two ways that metadata can arrive on a box; one is over the air,
the other is via an Internet connection. The same information’s
carried in both cases. The supplier of the box would naturally be able
to predefine some subscriptions to metadata sources, but the principal
initial source in most cases would be OTA (whether it’s carried by
Freeview, Freesat, Virgin, or Sky).
This basic metadata would consist in the first instance of a set of
services. There’s some potential for duplication here, of course, as
the same service metadata might arrive by way of different sources,
and a service might be listed both in the context of a service
offering (e.g., Freeview) or a broadcaster (e.g., the BBC).
Identifying the dups is fairly straightforward, though, assuming the
format of the metadata is sane. Each service listing contains a
location for the actual service metadata itself, as well as:
• the various delivery mechanisms for the service and what form they
take, accounting for regional variations
In the case of BBC 1, this would list each of the dvb:// URLs
applicable to the various regional broadcasts, as well as the
simulcast URL, the mobile SDP URL
• preferred channel numbering
This is a straightforward order-of-preference list, which may be
constrained by the STB vendor. BBC 1 could, for example, indicate a
preference for “1” and “101” in that order. In addition, for each
regional variant, there’s a second list, so it might also indicate
that 974 is the preferred variant channel for “BBC 1 London”.
In terms of variations, the two tie up with one another: if there are
no available delivery mechanisms for BBC 1 Scotland, for example, no
attempt to assign channel 971 to it would be made.
The service metadata carries the above, as well as details of the
programmes carried, which may include links to poster frames in
various resolutions, links to microsites and HTML-based interactive
apps, rich descriptions, and so on. The programme _may_ be an OTA
broadcast, or purely on-demand, or both. In either case, the metadata
can include information about when the programme is available
according to the different delivery media. This would allow a range of
different scenarios, from a programme which is aired but never
available for catch-up viewing, to the usual iPlayer-style setup where
catch-up is available for a limited period shortly after airing, the
less common scenario where the programme is available to download
immediately but will be aired at some point in the future, right down
to on-demand-only programmes which can be streamed or downloaded as
required, depending upon the available transports and protocols.
In addition, an OTA broadcast could well include extensions to the
metadata in the transport stream—which could well be useful for
commercial broadcasters wishing to add additional features to
advertising, as well as correcting last-minute errors or omissions in
the previously-obtained metadata.
Subscribing to a service manually would involve some kind of user
entry. DNS-SD would be used to reduce the typing required, though, so
if you were to subscribe to “freeview.co.uk”, the STB would query for
PTRs to SRV records matching _msdf._tcp.freeview.co.uk (or whatever),
which work not dissimilarly to the _http._tcp DNS-SD discovery
mechanism. Fallback methods are trivial, though (e.g., HTTP request to
the root with a specific Accept: header).
If you’re a content-provider, it’s mostly a matter of publishing the
metadata in the right place in the right formats.
Unless I’m being dim, this—if specified properly, in technical terms,
plus some “thou shalt provide xxx feature in order to be able to call
yourself compliant and use the logo” would encompass Canvas’s aims
without requiring:—
a) a joint venture and the associated costs, ramifications, entry
requirements, and risk of accusations of gatekeeperism;
b) a mandated UI
(sidenote #1: if it doesn’t appear to encompass Canvas’s aims, it
means I’ve either missed something in my reading of them, or in the
description above).
(sidenote #2: obligatory mock-ups of what it could look like, but
noting that the specs don’t define this: http://emberapp.com/nevali/collections/nxtv-stb-mock-ups/
)
What I can’t figure out is why the above isn’t sufficient. I realise
the BBC folks aren’t going to be able to give an answer to that
question _but_ if there are any glaring errors or omissions in the
above, I would really appreciate it being pointed out!
Answers on a postcard to the usual address…
M.
--
mo mcroberts
http://nevali.net
iChat: [email protected] Jabber/GTalk: [email protected] Twitter:
@nevali
Run Leopard or Snow Leopard? Set Quick Look free with DropLook -
http://labs.jazzio.com/DropLook/
-
Sent via the backstage.bbc.co.uk discussion group. To unsubscribe, please
visit http://backstage.bbc.co.uk/archives/2005/01/mailing_list.html.
Unofficial list archive: http://www.mail-archive.com/[email protected]/
