Re: Video Controls

On 01/04/2013 06:41 PM, Cullen Jennings (fluffy) wrote:
> On Jan 4, 2013, at 9:11 AM, Harald Alvestrand <harald@alvestrand.no> wrote:
>
>> On 01/04/2013 08:12 AM, Stefan Håkansson LK wrote:
>>> On 2013-01-03 02:32, Cullen Jennings (fluffy) wrote:
>>>> Here are roughly what I think we need  - yes there are lots more but
>>> What is not in v6 is the the bitrate stuff. It has been argued that this is not that relevant in a local use scenario - only when transported over a network and therefore should be associated with PeerConnection instead.
>> Bitrates don't really exist until a codec is chosen. I think the appropriate place to set bitrates is on the transmission path, not on the device; those constraints should trickle back if needed.
> The cameras have hardware encoding chips, and they compress the data before sending it over bus like the USB bus. If you are trying to control multiple cameras on the same USB bus, this becomes very important. It's the same with other bus technology, such as firewire, but the USB issues are the most common. If you look at the USB Video profile you will see it has this. ( you might also notice that a camera company I am co-founder of has been active, along with google and others, in making sure there is a VP8 profile for USB cameras but that is a side point ). Even if the video is never going to a PeerConnection, we need to be able to manage bus bandwidth issues and have a clue what is happening. My proposal might not be the right way to do this, but you do need to be able to deal with rue resource allocation to the camera if you want to successfully deal with more than one camera.
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?
>
>
>>> What is meant by "pan/tilt/roll"?
>> Move left/right, move up/down; I guess roll is turning the camera around the lens axis; I've never seen a remote-control camera mount that can do that, but I guess they exist.
>>
> +1.
>
> 3 axis are very common for surveillance cameras because they allow you to easily mouth the camera on either the ceiling or the wall. Google "3-axis camera".
>
> In addition, some times the pan/tilt/zoom are settable so you can control them but on a device like a mobile phone, you can use the 9 axis initial measurement unit (IMU) to produce a read only version so that as the users moves the camera, you can get the values. This makes it much easier to take a stream of video and process it into a tiled photograph or be able to integrate the video into an augmented reality scene. Rumor has it google glass does this.
>
>
>

Received on Friday, 4 January 2013 20:21:35 UTC