W3C home > Mailing lists > Public > public-media-capture@w3.org > January 2013

Re: Video Controls

From: Martin Thomson <martin.thomson@gmail.com>
Date: Wed, 16 Jan 2013 16:08:16 -0800
Message-ID: <CABkgnnWV5R34MfxKQ5nNeUCuEuUowvnwkLg5ZwQyikWk0Cy-ZA@mail.gmail.com>
To: Harald Alvestrand <harald@alvestrand.no>
Cc: "public-media-capture@w3.org" <public-media-capture@w3.org>
On 4 January 2013 12:20, Harald Alvestrand <harald@alvestrand.no> wrote:
> Aha - you're talking about the bitrate of the link between the camera and
> the browser.
> For the JS to make intelligent decisions about this, we may need to expose a
> slew of other detail, such as connection technology (USB 2, USB 3,
> Firewire.... possibly we can abstract this to simply "available bitrate",
> but in multiple cameras on the same bus, we would even have to expose the
> bus topology), available codec options (some HD cameras with USB 2
> interfaces use an on-camera H.264 codec simply to get the bitrate low
> enough) and so on.
> I'm not sure JS can do a good job here in picking choices without a quite
> complex API to expose the information. Perhaps we should leave this
> particular choice to the browser?

I always imagined that any specifics on how video was transported from
its source, through the browser, and to the network would be left to
the browser.  Bitrate in that space is largely invisible to the user,
so the browser can choose the configuration that best meets its
desired goals, within its constraints.  That might mean that the local
playback window shows a degraded image because it has to use the same
encoded stream that traverses a narrow network link.  That might
degrade user experience a little, but not to the point that would
bother me.
Received on Thursday, 17 January 2013 00:08:44 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:24:38 UTC