Re: Discovery and fallback for media segment addressing over HTTP

2009/4/8 Raphaël Troncy <Raphael.Troncy@cwi.nl>:
> Dear Conrad,
>
>> there were some recent questions about discovery (how does a client
>> find out whether an HTTP segment response mechanism is available) and
>> fallback (what happens if either the client or server fails to
>> understand the mechanism). I've put together some thoughts here:
>>
>> http://blog.kfish.org/2009/04/discovery-and-fallback-for-media.html
>
> Another interesting blog post :-) ... though I disagree sometimes with what
> you say:
>
> You wrote: "I will make the case that the user-visible differences between
> the two syntaxes are immaterial, and that a more important distinction is
> that they induce different protocols.".
>
> For me, protocol = HTTP and there is no difference in protocol between the
> fragment or the query parameter.

Use of the fragment requires that the user agent takes some additional
processing steps, to turn that fragment into an HTTP request header. I
was referring to this part of the negotiation.

> You wrote: "I will also claim that the use of the fragment syntax introduces
> unnecessary complexity in that it lacks a discovery mechanism and has no
> useful fallback to existing HTTP."
>
> This needs to be counter-balance. I don't see the extra-complexity, but I do
> see the benefit: the fragment has a natural filiation with its parent
> resource. The query creates a *new* resource. How will you specify back this
> relationship between the newly created resource and the original resource
> the part comes from? I don't see the answer in your blog post.

I like Yves' idea of using a Link: HTTP response header to signify
that relationship.

> The main criticism you have for the fragment, is the lack of a fallback plan
> if the server does not handle the fragment request. In other words, the
> whole resource will be send over the networks. Yes, but I don't see that as
> a major drawback, and we can be confident that the situation will naturally
> improve as soon as more and more web servers will handle media fragments.

Also the lack of fallback if clients don't support these steps. I
think there is a good use case for user agents not supporting extra
steps (eg. a mobile browser with no on-board cache) but there being an
intermediate proxy at the ISP which does that translation and caching.

> I then like your explanation of the solution we are designing within the
> group. Could we use this text in the WD?

Of course!

> Ultimately, you wrote:
>  "* To clarify within the Media Fragments WG how queries can be used
> effectively, for both considered user scenarios."
>
> The WG has plan for using the query parameter. It will mean that a new
> resource is created, extracted from an existing resource. We still need to
> specify how the link will be made.
>
>  "* To consider how the byte-range redirection mechanism can be generalized
> for other segment specifiers, such as spatial regions."
>
> As the ISSUE-5 [1] raised by Jack shows, we are likely to have transcoding
> for the spatial cropping.

Sure, that is a different issue. The xiph guys agree that there is no
point in implementing spatial cropping on compressed video :-)

Conrad.

Received on Tuesday, 7 April 2009 22:07:35 UTC