Re: [Moderator Action] Range Responses of Indeterminate Length: Draft

On 7/04/2015 11:39 p.m., Rodger Combs wrote:
> Yup; we use that for some platforms, but not all devices support it,
> and it limits us to the codecs supported by MPEG-TS (or that the
> platform supports in it). We use MPEG-DASH on some platforms, but it
> has similar issues. Both also require either knowledge of the segment
> durations beforehand (here, before they're generated), or the ability
> to force them to be consistent (which is impractical if remuxing
> streams a user's existing video files), though HLS implementations
> tend to be a fair bit more forgiving on this point than DASH ones.
> When it's possible, we've found that a single live-generated MKV file
> streamed over chunked HTTP is both compatible with a very wide
> variety of codecs, and very flexible about the sizes of a stream's
> GoPs and the like.
> 
> One thing I've had success in some experiments with lately is writing
> the MKV header to a single file, writing individual segments to
> separate files, and keeping track of their start timestamps. Then,
> when a request comes in for time T, I can return the header
> concatenated to the segment with the greatest start time <= T, and
> all segments after it. This approach is somewhat similar to how
> MPEG-DASH works, but with the work of preparing a fully-valid MKV
> file handled by the server instead of the client. The downside is
> that implementations often refuse to make any kind of seek in a
> resource that doesn't support range requests (and you can't properly
> support them when the content length is unknown), so I end up limited
> to seeks to the nearest on-server chunk boundary.

Please do not do that to generate payload streams without some
indicators in the headers or request-URL to distinguish the different
responses. It screws cacheability both in proxies and browsers which are
unaware of how the body is generated.

YouTube partial .swf responses used to do this when the user selected a
custom offset to start playing. There were a lot of problems and
complaints about truncated videos and even wrong codecs being delivered
to users, where one user selecting a late start would make other users
receive truncated videos for a while.


Nasty as they are multipart payloads would be better for HTTP as a whole
to deliver this type of service.

Or dare say it; chunked extensions would have been a perfect solution to
present a kind of multipart payload where the chunk extension headers
are teh multipart prefix. But that ship has sailed for 1.1. We might be
able to get something defined with HTTP/2 extensions or perhapse
PUSH_PROMISE that serves the use case nicer.

Amos

Received on Tuesday, 13 October 2015 09:37:20 UTC