Video Input Module
Configuring the VIM
The video source used as the VIM is defined in a preference file, named VideoInput.xml (in AL_DIR/preferences). Right now, 3 video devices are available as video source:
- NaoCam: standard NAO camera (only available on NAO)
Note: To switch between cameras, refer to the Modifying camera parameters section.
- SimulatorCam: what NAO sees in Webbot (only available on desktop)
- FileCam (beta version): replays grabbed sequences from any video device (available on NAO and desktop)
Accessing to the VIM
The VIM is unique, since it gives an access to one device, and is identified by its name (which is NaoCam by default). If the requested VIM doesn't exist, an error is returned by the broker and the GVM has to deal with this possibility. If everything is ok, a pointer to the device proxy will be returned.
States of the VIM
- By calling startFrameGrabber, the VIM can launch the acquisition of the video source stream, even if there is no GVM already registered. This allows, if needed, a faster launch of the first GVM by setting video device to the future format required by the GVM.
- As soon as a GVM has registered to the VIM, startFrameGrabber is automatically launched if it was not already running.
- When registering a new GVM or changing parameters of one of them, the VIM analyzes the minimum common requirements. It can change the video source stream format if needed. In such a case, the video source device and driver might be stopped in order to restart with their new settings.
- Once acquisition is running, an explicit call to stopFrameGrabber is required to stop it when there is no more subscribed GVM (as some might wish to keep the acquisition running in order to start faster when subscribing a module with the format of the video source).
What does the VIM do ?
The VIM manages the video source. If the video source is NAO's camera for instance, VIM will:
- open camera device through I2C bus
- launch V4L2 driver in streaming mode (the driver will create a circular buffer of n elements to grab the video stream)
- receive subscriptions from GVM's by creating for each one an ALImage for raw data and an ALImage to store converted data
- choose which image to provide to a GVM when it asks for one, depending on whether another GVM requested the same kind of image recently or not
- manage all modifications asked to the device (e.g. new gain settings), or by a GVM on its parameters (e.g. a new color space) and manage the impacts these modifications can have on video source and/or driver (e.g. when changing from QVGA to VGA)
- suppress corresponding unused ALImages when a GVM unsubscribes, and check the new optimal settings for the device and driver for remaining modules
- stop the driver and close the video device when asked to and when no more GVM are subscribed
Except there is no I2C communications and V4L2 driver for SimulatorCam and FileCam video devices, both devices are running similarly with the VIM (a circular buffer has been implemented to simulate the one of V4L2 driver and SimulatorCam video flow is converted in YUV422 for keeping an abstraction layer with the active video device).
For more explanations on how the VIM acts on video stream depending on GVM needs, please refer to the next section.