- From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- Date: Wed, 17 Dec 2008 21:04:30 +1100
- To: "Yves Lafon" <ylafon@w3.org>
- Cc: "Geoffrey Sneddon" <foolistbar@googlemail.com>, "Media Fragment" <public-media-fragment@w3.org>
On Wed, Dec 17, 2008 at 8:24 PM, Yves Lafon <ylafon@w3.org> wrote: > On Wed, 17 Dec 2008, Silvia Pfeiffer wrote: > >> >> Ah yes, that's just the wiki page, but we will indeed put a version of >> this into the use cases and requirements section of the specification. >> >> I've added a blurb at the end of the "side conditions" section on that >> wiki page about fallback solutions. After having thought about it a >> bit more, it is probably not a good idea to do the full media resource >> download by default. For example, think about a media fragment URI to >> an offset of 15 hours into a 20 hour long video for a 2 min long >> fragment. Think about such a request on a mobile phone. With almost >> certainty, you do not want your phone to just go off and download the >> full resource instead of the 2 min excerpt. >> >> So, I think the user agent should inform the user of the failed >> fragment URI and give the user the option to get the full resource, >> but not do it by default. > > No, it would be against the "ignore what you don't know" rule. The client > will see an incoming file with a _big_ Content-Length, that let the client > decide to drop the connection to abort the transaction, but it has to be a > client-side behaviour, not a server-side one. I think that's what I said (i.e. it's dealt with client-side). Except, it was my assumption that the server will 404 a media fragment request where it doesn't understand a few extra message headers. That's probably wrong and the server would by default reply with the full resource if it cannot resolve the fragment (at least in the HTTP case - not sure what happens in the RTP/RTSP case). So, I have adapted the statement on the wiki. :) Cheers, Silvia.
Received on Wednesday, 17 December 2008 10:05:07 UTC