RE: Comments on Media Capture and Streams Specification

Harald,

Thank you for your feedback and suggestion.

We will take the approach of extending MediaStream API in our spec as you suggested.

Thank you and have a good weekend
Bin

-----Original Message-----
From: Harald Alvestrand [mailto:harald@alvestrand.no] 
Sent: Friday, June 12, 2015 1:19 AM
To: HU, BIN; public-media-capture@w3.org
Cc: Chris Needham (chris.needham@bbc.co.uk); Paul Higgs (paul.higgs@ericsson.com); Sean Lin (selin@mozilla.com); ashimura@w3.org; Dan Burnett; public-tvapi@w3.org
Subject: Re: Comments on Media Capture and Streams Specification

Thanks for the feedback!

The biggest change you're asking for to the model is to make a
MediaStream seekable.
I don't know if this can be accomplished at reasonable cost; the
implementations are heavily committed to the concept of a MediaStream as
a "fire and forget" mechanism - one generates media, one ships it, and
one forgets about it.

I would like to ask you to consider whether you should rather define a
new class, which builds on MediaStream's API, and extends it with a
buffering mechanism that would allow (I assume limited) seekability.

This API could then live wholly within the context of your
specifications, and browsers could choose to support (or not support)
that construct independently of their support for vanilla MediaStreams.

Would that be an acceptable path to consider for your group?

Harald



Den 11. juni 2015 22:53, skrev HU, BIN:
> Hello folks,
> 
>  
> 
> How are you? I am Bin Hu, Chair of TV Control API Community Group. Sean
> Lin is our Editor, and Chris Needham and Paul Higgs are our active
> contributors and SMEs in our group.
> 
>  
> 
> We are working on an API to integrate broadcast TV into HTML, allowing
> playback of video and audio streams from a TV tuner, channel selection,
> program information, and so on.
> 
>  
> 
> In our draft specification [1] we've currently used MediaStream as the
> way to attach the TV tuner source to an HTMLMediaElement, using the
> srcObject attibute.
> 
>  
> 
> One of our requirements is buffering of the video and audio streams,
> which is needed to support use cases such as pausing and resuming of the
> media, seeking within the buffered region after pausing, and returning
> to the current 'live' position.
> 
>  
> 
> In [2] we've compiled a detailed list of the areas we've found in
> MediaStream that we'd want to change to adapt it for our use cases. In
> other respects MediaStream looks suitable for use with TV streams, such
> as the changes to the HTMLMediaElement's resource loading algorithm, and
> the support via the srcObject attibute.
> 
>  
> 
> We realise that we've passed the deadline for comments on the Media
> Capture and Streams spec, but we wanted to let you know about our work,
> and invite feedback on how to proceed, for example, would our
> requirements might be considered in a future version of Media Capture
> and Streams, should we propose an extension specification, or produce
> our own stand-alone specification?
> 
>  
> 
> Please let us know, and your guidance and feedback is greatly appreciated.
> 
>  
> 
> With warmest regards
> 
>  
> 
> Bin Hu
> 
> Chair, TV Control API Community Group
> 
>  
> 
> [1] https://w3c.github.io/tvapi/spec/
> 
> [2] https://lists.w3.org/Archives/Public/public-tvapi/2015Jun/0000.html
> 
>  
>

Received on Friday, 12 June 2015 15:46:18 UTC