Using the camsource and vlc packages as an example. If camsource is configured to use a given dev/video[n] device with a choice of resolution in the width and height fields of a camsource conf file then if camsource is the first application to access the device captured images are as-expected. However, if an application like vlc is used for the same device (and exited) before starting camsource (e.g. to check the view from the camera before starting camsource) and if the camera supports higher resolutions than used in the camsource configuration what occurs is that camsource will not setup the camera to use the configured resolution and has a broken view of the camera output based on the vlc chosen resolution chopped to the camsource configuration. For example, with camsource configuration set to use 640x480 on a camera that supports 720x480 and vlc is used and exited before camsource is started then the captured camsource images contain two non-continuous partial image blocks with a horizontal border dividing them. I assume either vlc fails to fully reset the device configuration when exiting or camsource fails to initialize the device "from scratch" when starting. The two applications use different video device APIs but the setup and cleanup for the camera in each case is a very limited part of the application's functionality.

Looking for hackers with the skills:

vlc camsource co-operation video

This project is part of:

Hack Week 19


  • over 4 years ago: dmair liked this project.
  • over 4 years ago: dmair added keyword "vlc" to this project.
  • over 4 years ago: dmair added keyword "camsource" to this project.
  • over 4 years ago: dmair added keyword "co-operation" to this project.
  • over 4 years ago: dmair added keyword "video" to this project.
  • over 4 years ago: dmair started this project.
  • over 4 years ago: dmair originated this project.

  • Comments

    • dmair
      over 4 years ago by dmair | Reply

      Note, the problem does not occur in vlc if the order of execution (following USB camera plug-in) is as follows:

      • Start camsource
      • Exit camsource
      • Start vlc

      It occurs in camsource if vlc has run after the camera plug-in and before camsource is started.

    • dmair
      over 4 years ago by dmair | Reply

      I just found the cause of this.

      When camsource opens and initializes the video source it gets the configured frame size and sets the width and height in a struct videowindow (v4l1). It continues as far as making the channel settings with a VIDIOCSCHAN ioctl. If that succeeds it does a VIDIOCGWIN ioctl to "Get the video overlay window" into the same structure as it previously set the configured width and height in. Thus, replacing the width and height with the current settings on the device (rendering the configuration settings of no value). It then performs a VIDIOCSWIN ioctl to "Set the video overlay window" using the structure it just filled using VIDIOCGWIN, IOW the set is redundant it sets the overlay window to it's current value. The configured frame size wanted in the struct videowindow (and any other populated in it before the VIDIOCGWIN) need to be retained and set in the struct video_window between the VIDIOCGWIN and VIDIOCSWIN operations.

      • dmair
        over 4 years ago by dmair | Reply

        The described behavior occurs if setting the channel using VIDIOCSCHAN is used and succeeds, if it fails then VIDIOCSWIN is used without first using VIDIOCGWIN on the struct video_window containing the values from the configuration.

    • dmair
      over 4 years ago by dmair | Reply

      Yes, I have a working fix that is littered with debug code but I'll clean it up and have a package fix shortly.

    • dmair
      over 4 years ago by dmair | Reply

      The description above explains the loss of configuration settings and use of previous application's settings from the video device but there's more to it as well. There are two attempts to make video channel settings in opendev(). The first one is based on device features. The second one just repeats the previous VIDIOCSCHAN ioctl. But the second one is followed by a failure path starting with the message "ioctl set grab window failed: ...Trying again without the fps option...". Which is immediately followed by a VIDIOCSWIN ioctl setup with the fps removed from the struct video_window. The message claims this VIDIOCSWIN is the "again without fps" behavior of a VIDIOCSCHAN which has no fps setting anyway. According to the potential output messaging, what was intended was a VIDIOCSWIN with fps set and if it fails, another VIDIOCSWIN without fps. If implemented that way then the success block of the VIDIOCSCHAN (now replaced with a VIDIOCSWIN) isn't needed to perform a VIDIOCGWIN/VIDIOCSWIN that overwrites the loaded configuration and the block can be removed. Placing VIDIOCGWIN before the loading of configuration means the current settings are replaced by configuration settings, a set grab window using any fps setting is performed, if it fails it is repeated without the fps. It matches the runtime behavior described by the messaging the code can generate and it now uses the configured grab window size regardless of what was run before on the same camera.

    Similar Projects

    A frameblending filter for OBS Studio well-suited to do game streaming by mschreiner

    Project Description

    To experiment and pos...

    Open Source ONVIF Camera Implementation by nbelouin

    [comment]: # (Please use the project descriptio...