Broadcast Content References

I’ve been doing a whole bunch of work on referencing in the TV/iTV area, so I thought I’d share, plus it means I look this back up later šŸ™‚

Over the past 10 or so years there has been various activities to create a URI scheme for referencing and locating content on a broadcast network. This has become particularly useful in the Digital TV area. Digital TV (DTV) has also brought together interaction layers (Interactive TV or iTV) together with the broadcast content. This has meant the emergences of applications that allow additional functionality to the DTV world. From an application developer’s point of view it is useful to be able to refer to a particular programme or “event” on a broadcast channel.

Various groups have worked on this over those years, and there have been a number of proposals. The common element linking those groups however is that the work has come to an end and most have moved on or closed down.  The frustrating thing is picking up the paper trails…

Anyway, the use of the locator is required by meta-data schemes such as TV Anytime which need a physical location of the media to be indicated, other schemes maybe used and are also also required by Tapeless Production systems, DVRs, Media Centers and the like.

The two main schemes that I can find specifications for are:

The main reason I’ve been looking at this is because of the requirement of TV Anytime have some way of resolving content references down to a location. Most references in TV Anytime (now ETSI standards TS 102 822-1…TS 102 822-7) are actually using the Content Reference Identifier (CRID) scheme ‘crid://’, which now specified by RFC4078 (Informational – NOT standard). This level of references is high level and does not take into account any physical asset location. Eventually you have to determine if your content is on a broadcast stream or on a disk somewhere.

The TVWeb idea

Personally, I quite like this idea, it’s obvious (‘tv:’) and simple, albeit with some issues around name collisions. It was possible to specify “tv:4” for instance, which was the “4th” channel. This doesn’t make a lot of sense in the current world. The history merges with that of SMIL, and in fact the Television and the Web group has since closed and been folded into the Device Independence Activity. Which in turn has moved on to be part of the Ubiquitous Web Applications group. So apart from the RFC2838 for this scheme, there isn’t much going for it, as it seems that SMIL is the plan for the future. Which as a function of the W3C, does make sense, as they are after all looking at the web. The only cross-over here is the pre-dominance of XML and thus URI structures to reference content, which brings us to…

The DVB locator

This was created by DAVIC, and proposed in their 1.3.1 standard, which is now an ISO standard (ISO/IEC 16500). This is slightly worrying as people have felt the need to change and extend the original so there was a 1.5 release from DAVIC which covered the extensions, building on those introduced in 1.4.1.

So what are you getting in the ISO document ? Unfortunately I won’t know as I’m not currently furnished with spare Swiss francs to buy it, but if we take the 1.5 version then a DVB locator is of the following form:

   1: dvb://<original_network_id>.[<transport_stream_id>][.<service_id>[.<component_tag>]][;<event_id>]@<start_time>D<duration>][/<...>]

(Unwrapped form below)


Implementing this

Now for the more interesting aspects of this specification when we try to implement this:

  1. There are a lot of examples where people try to use a dvb locator that looks like this: dvb://123.5ac.3be;3e45~20011207T120000Z–PT02H10M. technically this is a valid URI, but does not match the DAVIC (ETSI) specification. IT also cause the .Net validation to break as it thinks ‘~’ is invalid. This example is prevalent in the TV Anytime documents. Which is a pity as the TV Anytime group came from DAVIC
  2. The other set of examples are of this form: dvb://233a.4000.4700;b0cb@2007-07-25T05:00:00ZPT03H00M, this is NOT a valid URI (the colon fails on the ‘port’ rule, and the address is not IPv6 so this is not open to alternatives) according to RFC3986. The solution is to change the timestamp to use the simplified form of ISO 8601 which is just the timestamp and no separators.
  3. Validating the TV Anytime schema under .Net threw an error for dvb locators in point 1… which is not correct (bugs to be filed before people look). To figure this out I had to build my own URI grammar to determine if the dvb:// locator was invalid or the schema was invalid. It turns out that xs:anyURI does not actually have to be validated by any processor implementing Schema Validation – for sensible reasons. So quite what .Net is complaining about, we’re not sure. Validating in oXygen simply checks that it’s a sensible string. Hmm, anyway, examples such as those in 1, aren’t correct, move on šŸ™‚

I also found out the wonderful things you can do to host names, most of which should result in capital punishment.


A couple of things:

  1. I’d have preferred to see the Timestamp before the location, so a format of: dvb://20081223T140000:DT01H05M@5f.8ec.6df1;345 – which to me reads better from a semantic point of view, i.e. “On 23/12/2008, at 14:00 for 1 hour and 5 minutes on/at (@)  this location; with this event.
  2. dvb is kind of specific to a particular broadcast system, thankfully the prevalent one.
  3. It’s seems to have taken a while for people to pick up on some of this work, and it feels like I needed to do similar work to a patent lawyer to figure out where it all is and what state it’s in, there must be a better way.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s