Bug 56459 - Implement the HTML5 Media Streaming API
: Implement the HTML5 Media Streaming API
Status: ASSIGNED
: WebKit
HTML DOM
: 528+ (Nightly build)
: All All
: P2 Normal
Assigned To:
: http://www.whatwg.org/specs/web-apps/...
:
: 56458 56586 56587 56666 56949 58147 58459 58550 60177 60184 60205 60260 60387 61068 61069 61537 61539 62798 63122 64525 64791 64794 65101 65669 65925 66045 66940 67843 67946 68171 70897 71008 71458 71657 71678 71895 72116 73010 73130 73816 74598 76436 76614 77438 77954 79114 80589 83143 83167 84723 84850 84942 85794 85796 85798 85992 86087 86210 86459 90171 90180 92106 95193 95721 97095 97456 97540 97559 97673 97779 98003 98149 98416 98753 99080 99308 99435 99460 99593 99713 99714 101586 101730 101733 101751 102382 102386 104543 106017 106564 106568 106660 106781 106782 106791 107120 107128 108173 108179 108458 109296 109688 111079 111311 111437 112258 112314 112350 112792
:
  Show dependency treegraph
 
Reported: 2011-03-16 05:28 PST by
Modified: 2013-11-22 12:08 PST (History)


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


------- Comment #1 From 2011-03-16 11:28:24 PST -------
That spec is very much a moving target still.
------- Comment #2 From 2011-03-17 08:56:21 PST -------
Sure, I understand it's a moving target as we have closely followed the relevant standards mailing lists. At the same time, Chromium is very interested in implementing and maintaining this spec and we're fully committed to keeping the WebKit code as close to the standard as possible.

I was wondering if you had any advice about this: do you feel it's premature to add this API to WebKit? Or would you be ok with us adding it already now and committing to keeping it up to date?

(In reply to comment #1)
> That spec is very much a moving target still.
------- Comment #3 From 2011-03-17 14:10:18 PST -------
(In reply to comment #2)
> Sure, I understand it's a moving target as we have closely followed the relevant standards mailing 
> lists. At the same time, Chromium is very interested in implementing and maintaining this spec 
> and we're fully committed to keeping the WebKit code as close to the standard as possible.
> 
> I was wondering if you had any advice about this: do you feel it's premature to add this API to WebKit? 
> Or would you be ok with us adding it already now and committing to keeping it up to date?
> 
  While I agree that this is an important feature, and I definitely think that there is nothing like real implementation experience to make sure an API does everything it should, I am concerned that shipping a feature before an API settles can have a bad effect on both the web and on WebKit's ability to implement the final spec. 

  We implemented and shipped <video> very early, but the element had been in the spec for more than six months and there had very extensive debate on the mailing list. We shipped it knowing that we *would* break existing content if the spec changed, and it indeed it has changed significantly several times since we shipped our first implementation - and we updated and broke existing content when it did. 

  Are you willing to commit to breaking early adopters when the spec changes? It will change.

  Because this is a JavaScript-only API at this point, wouldn't it be possible to implement this in an application and inject the JavaScript API into WebKit at runtime?
------- Comment #4 From 2011-03-17 17:31:58 PST -------
Hi Eric!

Many thanks for the comments!

(In reply to comment #3)
> (In reply to comment #2)
> > Sure, I understand it's a moving target as we have closely followed the relevant standards mailing 
> > lists. At the same time, Chromium is very interested in implementing and maintaining this spec 
> > and we're fully committed to keeping the WebKit code as close to the standard as possible.
> > 
> > I was wondering if you had any advice about this: do you feel it's premature to add this API to WebKit? 
> > Or would you be ok with us adding it already now and committing to keeping it up to date?
> > 
>   While I agree that this is an important feature, and I definitely think that there is nothing like real implementation experience to make sure an API does everything it should, I am concerned that shipping a feature before an API settles can have a bad effect on both the web and on WebKit's ability to implement the final spec. 
>

Totally agreed. It is not in our intention to ship this API before it is ready but rather get the implementation experience you mentioned and provide feedback to the standardisation effort. We were thinking of keeping this API behind a 'webkit' prefix (and in Chromium, it would also be behind a runtime flag).

>   We implemented and shipped <video> very early, but the element had been in the spec for more than six months and there had very extensive debate on the mailing list. We shipped it knowing that we *would* break existing content if the spec changed, and it indeed it has changed significantly several times since we shipped our first implementation - and we updated and broke existing content when it did. 
> 
>   Are you willing to commit to breaking early adopters when the spec changes? It will change.
> 

Yep, it will definitely change. However, there have been precedents of APIs that WebKit implemented despite the standard being a moving target (e.g. IdexedDB). In these cases, using the 'webkit' prefix for the API method names made it clear to the early adopters that the API may change quite dramatically.

>   Because this is a JavaScript-only API at this point, wouldn't it be possible to implement this in an application and inject the JavaScript API into WebKit at runtime?

The API is meant to interact with existing elements such as <video> or APIs, while it's methods are meant to return types such as Blob. I am therefore not sure how feasible it would be to implement it as you suggest. Rather, I feel it would be more beneficial to try and implement it properly in WebKit, provide feedback to the standard and iterate.

What do you think?

All the best,
Andrei
------- Comment #5 From 2011-03-17 22:46:41 PST -------
(In reply to comment #4)
> (In reply to comment #3)
> > (In reply to comment #2)
> > > I was wondering if you had any advice about this: do you feel it's premature to add this API to WebKit? 
> > > Or would you be ok with us adding it already now and committing to keeping it up to date?
> > > 
> >   While I agree that this is an important feature, and I definitely think that there is nothing like real implementation experience to make sure an API does 
> > everything it should, I am concerned that shipping a feature before an API settles can have a bad effect on both the web and on WebKit's ability to 
> > implement the final spec. 
> >
> 
> Totally agreed. It is not in our intention to ship this API before it is ready but rather get the implementation experience you mentioned and provide feedback 
> to the standardisation effort. We were thinking of keeping this API behind a 'webkit' prefix (and in Chromium, it would also be behind a runtime flag).
> 
I think keeping it behind a 'webkit' prefix is definitely a requirement until the spec is much more mature.

> > Because this is a JavaScript-only API at this point, wouldn't it be possible to implement this in an application and inject the JavaScript API into WebKit 
> > at runtime?
> 
> The API is meant to interact with existing elements such as <video> or APIs, while it's methods are meant to return types such as Blob. I am therefore not 
> sure how feasible it would be to implement it as you suggest. Rather, I feel it would be more beneficial to try and implement it properly in WebKit, 
> provide feedback to the standard and iterate.
> 
Good point.

> What do you think?
> 
As I said, there is nothing like real implementation experience to help shape a new API, so I think this is a useful effort. As I also noted the spec is still very young and it will likely change after we have an implementation, but as long as we use a 'webkit' prefix and acknowledge that it is very likely we may have to break early adopters I don't have a problem with proceeding.
------- Comment #6 From 2011-03-18 08:39:17 PST -------
(In reply to comment #5)
> (In reply to comment #4)
> > (In reply to comment #3)
> > > (In reply to comment #2)
> > > > I was wondering if you had any advice about this: do you feel it's premature to add this API to WebKit? 
> > > > Or would you be ok with us adding it already now and committing to keeping it up to date?
> > > > 
> > >   While I agree that this is an important feature, and I definitely think that there is nothing like real implementation experience to make sure an API does 
> > > everything it should, I am concerned that shipping a feature before an API settles can have a bad effect on both the web and on WebKit's ability to 
> > > implement the final spec. 
> > >
> > 
> > Totally agreed. It is not in our intention to ship this API before it is ready but rather get the implementation experience you mentioned and provide feedback 
> > to the standardisation effort. We were thinking of keeping this API behind a 'webkit' prefix (and in Chromium, it would also be behind a runtime flag).
> > 
> I think keeping it behind a 'webkit' prefix is definitely a requirement until the spec is much more mature.
> 
> > > Because this is a JavaScript-only API at this point, wouldn't it be possible to implement this in an application and inject the JavaScript API into WebKit 
> > > at runtime?
> > 
> > The API is meant to interact with existing elements such as <video> or APIs, while it's methods are meant to return types such as Blob. I am therefore not 
> > sure how feasible it would be to implement it as you suggest. Rather, I feel it would be more beneficial to try and implement it properly in WebKit, 
> > provide feedback to the standard and iterate.
> > 
> Good point.
> 
> > What do you think?
> > 
> As I said, there is nothing like real implementation experience to help shape a new API, so I think this is a useful effort. As I also noted the spec is still very young and it will likely change after we have an implementation, but as long as we use a 'webkit' prefix and acknowledge that it is very likely we may have to break early adopters I don't have a problem with proceeding.


Great, thank you! Any help reviewing this stuff will be greatly appreciated :)

All the best,
Andrei
------- Comment #7 From 2011-03-23 13:19:00 PST -------
Updating the bug platform settings (had the default ones).
------- Comment #8 From 2011-03-23 13:19:54 PST -------
Updating the bug platform settings (had the default ones). -- Fixed.
------- Comment #9 From 2011-09-07 23:05:19 PST -------
Hi,

We are very much interested in this feature. We have started implementing it and would like to contribute for Gtk port.

Please let me know if the overall architecture/design documents are shared at any place? if the design is not published then I think it may be posted as a webkit blog and/or on a webkit-dev list. That way other people can also share thoughts. I had read old dev-list thread on <device> element implementation but I think design is now changed with the new video conferencing and p2p spec.

Thanks,
Arun
------- Comment #10 From 2011-09-09 09:34:50 PST -------
Hi Arun

We have developed a GStreamer backend for MediaStream and PeerConnection for the GTK port. However, it doesn’t fit in to well with the WebKit client based design currently used in WebKit since we are using WebCore platform abstractions for everything except the getUserMedia requests. The good thing is that we’re currently talking to Tommy Widenflycht (Google’s main contributor in this area) about this and he also believes that we should move over to a WebCore platform approach since it suits most platforms best. When this is in place, we plan to contribute our implementation for GTK.
------- Comment #11 From 2011-09-13 00:31:42 PST -------
(In reply to comment #10)
> Hi Arun
> 
> We have developed a GStreamer backend for MediaStream and PeerConnection for the GTK port. However, it doesn’t fit in to well with the WebKit client based design currently used in WebKit since we are using WebCore platform abstractions for everything except the getUserMedia requests. The good thing is that we’re currently talking to Tommy Widenflycht (Google’s main contributor in this area) about this and he also believes that we should move over to a WebCore platform approach since it suits most platforms best. When this is in place, we plan to contribute our implementation for GTK.

Ok, Thanks Adam! Could you guys move your discussions to webkit-dev list please so that other people can also contribute to it.
------- Comment #12 From 2011-09-13 03:05:28 PST -------
(In reply to comment #11)
> Ok, Thanks Adam! Could you guys move your discussions to webkit-dev list please so that other people can also contribute to it.

I've created a bug to discuss this: http://webkit.org/b/67946
------- Comment #13 From 2011-12-22 13:22:47 PST -------
Any estimate on when this feature will be available to developers in experimental webkit/chrome builds?