Something that can be done with GUdevDevice:


  device_file = g_udev_device_get_device_file (udevice);
  if (device_file == NULL)
  {
    GST_WARNING ("Error getting V4L device");
    return;
  }

  /* vbi devices support capture capability too, but cannot be used,
   * so detect them by device name */
  if (strstr (device_file, "vbi"))
  {
    GST_INFO ("Skipping vbi device: %s", device_file);
    return;
  }

  v4l_version = g_udev_device_get_property_as_int (udevice, "ID_V4L_VERSION");
  if (v4l_version == 2 || v4l_version == 1)
  {
    const char *caps;

    caps = g_udev_device_get_property (udevice, "ID_V4L_CAPABILITIES");
    if (caps == NULL || strstr (caps, ":capture:") == NULL)
    {
      GST_WARNING ("Device %s seems to not have the capture capability, (radio tuner?)"
                   "Removing it from device list.", device_file);
      return;
    }

Thanks for reporting this bug. In order to submit patch you should clone git master of gst-plugins-good, do the changes and commit them to your local branch. The patch can be produce with "git format-path -1". This is the format we accept for review.

Any update ? I realize that radio device in V4L2 are not well integrated, as V4L2 only do the tuner part, while the actual stream is within alsa/pulse.

Is there still an interest in getting this ?

There is someone who can create a patch and implement this option?

According to the spec, a V4L2 radio device can be recognized through the
capability flags

"Devices supporting the radio interface set the |V4L2_CAP_RADIO| and
|V4L2_CAP_TUNER| or |V4L2_CAP_MODULATOR| flag in the /|capabilities|/
field of struct v4l2_capability
<http://linuxtv.org/downloads/v4l-dvb-apis/vidioc-querycap.html#v4l2-capability>"

So you'll get |(V4L2_CAP_RADIO| | |V4L2_CAP_TUNER) for tuners, and
(V4L2_CAP_RADIO || |V4L2_CAP_MODULATOR) for modulator.| Modulators are
not (yet?) supported in GStreamer.

This filtering is relatively trivial and should be added to
gst-plugins-good/sys/v4l2/gstv4l2deviceprovider.c

This is for sure trivial, please go ahead if you have a interest and are going to use that.

How would this be used via device monitor then? If the actual audio has to be captured using alsasrc then I'm not sure if it really makes sense to advertise a v4l2src element with radio capabilities. Perhaps one needs to create a bin of sorts that plugs an alsasrc configured with the right device?

I think you are right, it's not that trivial. Would make sense to use v4l2 to enumerate, cause the information is mostly there. But to be useful, the radio element should become a GstBin. In a way that the radio can dynamically find and use the proper (pulsesrc or alsasrc) element and configure it the way the device monitor is designed. I'd like to keep that bug open still, as I think it's not impossible and probably wanted feature. On don't need a radio device, since we got vivid that simulate all of it now.

Now can use GstCaps to monitor webcam via caps, for example:

caps = gst_caps_new_empty_simple ("video/x-raw");
gst_device_monitor_add_filter (priv->monitor, "Video/Source", caps);

but here there are no options to filter out devices with radio.

With actual API, can monitor a v4l2 tv and webcam devices but do not know if exist GstCaps (capabilities) describing media types for radio device.

Currently the radio device only have a "Tuner" class. We can add more when this element is fixed. For the caps, with the Bin design, that should just work, note that caps are optional in the filter, radio caps will be an audio/x-raw in most cases (unless we decide to expose SDR signal that is not demodulated).

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/issues/152.