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

________________________________________
From: public-web-and-tv-request@w3.org [public-web-and-tv-request@w3.org] On Behalf Of Alexander Adolf [alexander.adolf@me.com]
Sent: Saturday, February 19, 2011 3:24 PM
To: Georgios Gardikis
Cc: public-web-and-tv@w3.org
Subject: 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.

JLI> Not sure what is the scenario. The content/service provider has the control of the metadata and what content is available and in which format. I do not see the problem with providers that are on-line. The question is if we need to cater for scenarios that the client has a means to register future consumption of content. In OIPF DAE spec we have a mechanism for including a Content Access Descriptor which does some of the points raised. This assumes the content provider has initially released the playout to the client.


> [...]
> 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.

JLI> I would suggest to seperate the scenarios of real time transmission and those that require the client to track the validity. The example with FLUTE is a controlled delivery to the client similar to caching. The application will control which files are to be expected to be transmitted over multicast. In DAE we have the mechanism for registration of such delivery but it is up to the application to register and then use that content. The client is simply caches the files. The support of FLUTE is yet another scenario. 


Thanks a lot and cheers,

  --alex

Received on Monday, 21 February 2011 09:31:39 UTC