Re: Web/TV services and media delivey protocols - is DASH sufficient?

Dear Georgios,
Dear Colleagues,

On 2011-02-18, at 17:15 , Georgios Gardikis wrote:

> [...]
> I agree that, as an HTTP/TCP mechanism, DASH should be fine for Web/TV
> service access over the Internet. But the TV world is much broader; it also
> includes "fenced" IPTV, corporate and also digital broadcast networks -
> which use multicast/broadcast delivery for linear content. In this case,
> HTTP cannot be used.
> 
> IMO, since we are talking about Web and TV, we need solutions that are also
> consistent with the requirements of broadcasters and their (IP/D)TV systems.
> For this purpose, IP multicast support is essential.

While the odds of multicast being introduced at large scale are admittedly debatable, I fully concur with your conclusion that the range of delivery mechanisms needs to be broader than HTTP/TCP. A minimal example without any new transport mechanism at all would the the one I used in my slides in Berlin: a clickable link to a live broadcast (of course supposing you have a USB-tuner of some sort).

To enable this, I proposed an intermediate level of indirection. If we had a type of link which would be indicative of the fact that there is more information available about what what awaits you at the end of the link (metadata about the content), and more information about ways of obtaining the link target (metadata about the available sources and transport mechanisms). Not only is this design the consequence of operational lessons learned in broadcast and IPTV, it also happens to agree with a couple of issues TBL points out in his metadata design issues discussion (http://www.w3.org/DesignIssues/Metadata).

Also, the source list and available transport mechanisms may vary over time for a given piece of content. While the metadata describing the story, cast, etc. may always come from the same source, the audiovisual content may be available on digital broadcast for the next hour, for the next seven days after that it may be available from the broadcaster's catch-up archive in some proprietary format, and after that it may only be available from a P2P network which may be an Open Source implementation.

> [...]
> Maybe we should initiate a discussion on Web/TV service delivery scenarios -
> over DTV, over IPTV, over the Web or hybrid access (HbbTV-like, e.g. receive
> the video over DTV and the Web/HTML content over the Internet, "pushing" of
> HTML content etc.) in order to clarify the requirements. What do you think?
> [...]

Such a discussion would certainly help. FLUTE - as Mark pointed out - can be used to re-use HTTP/TCP resources in unidirectional broadcast environments, and in fact this is used widely in Mobile TV.

At the risk of repeating myself ;-)) the answer that the broadcast, IPTV, MobileTV folks, and TBL have found to this is the above mentioned additional level of indirection. Instead of giving several links with different validity periods into the future (effectively forecasting from where a certain content will be available at any given point), the client asks a resolution server "from where can I get this *now*." This would save us from having to make assertions about the future, and would allow for long-lived links to content.


Thanks a lot and cheers,

  --alex

Received on Saturday, 19 February 2011 14:24:48 UTC