- From: Harald Alvestrand via GitHub <sysbot+gh@w3.org>
- Date: Thu, 19 Jan 2017 19:50:44 +0000
- To: public-media-capture-logs@w3.org
.... except that the entity getting the frame is a consumer of the MediaStreamTrack, not the producer as it was in the canvas case, so the model doesn't quite fit. We want to grab frames from any sort of track, without having to have the frame-grabbing travel all the way to the producer having to know that this is a track of the type you can grab frames from. Once upon a time we had separate IDL classes for VideoTrack and AudioTrack, but after a year of nobody finding any API we wanted to have different on the two, we went ahead and merged them. Separating them back out would be a pain in the posterior, I think. To me it seems simpler to have grabFrame() be a method on the object you connect a MediaStreamTrack to, just the way it's currently specified. But at the end of the day, it's all control surface. The real data travels by whatever means makes sense for the implementation. -- GitHub Notification of comment by alvestrand Please view or discuss this issue at https://github.com/w3c/mediacapture-image/issues/144#issuecomment-273879497 using your GitHub account
Received on Thursday, 19 January 2017 19:50:52 UTC