[Bug 668018] v4l2src: Adds generate-frames option to v4l2src for better support of signal loss cases

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=668018
  GStreamer | gst-plugins-good | git

--- Comment #17 from Nicolas Dufresne (stormer) <nicolas.dufresne at collabora.co.uk> 2015-01-09 18:49:27 UTC ---
(In reply to comment #16)
> However, in some cases the device may become unresponding (e.g. you plug a USB
> webcam out during capture), so no more querying. The only reliable thing is
> whether open() and dqbuf ioctl does not return -1.

Indeed, as soon as USB device get unplugegd, ENODEV is returned and an error is
posted.

> 
> Overall, the first big step is indeed to make the loss of signal non-fatal,
> i.e. what we have done in our current patch
> * v4l2 ioctl node opening should be done with the O_NONBLOCK flag
> (http://linuxtv.org/downloads/v4l-dvb-apis/func-open.html) so that the whole
> plugin does not freeze when a call blocks (otherwise it will wait until the
> generic kernel 120s (!!!) timeout /proc/sys/kernel/hung_task_timeout_secs)

Would be nice to provide some clarification, since we should never be doing an
block ioctl(), as we poll before action. If an ioctl() blocks after polling
succeed, then it's likely a driver bug.

Note that NONBLOCK was commented out in 2006, would be nice if someone could
dig up associated bug and figure-out why before going this way:

https://bugzilla.gnome.org/show_bug.cgi?id=338818

> * v4l2src does not emit EOS in case of error, but either pushes a generated
> picture (scenario #1) or pushes down an event (scenario #2)
> * keeps trying to restart capture by closing and re-opening the device node
> every N seconds (defined by the 'retry-delay' property in our implementation)
> * whenever the device opening or dqbuf succeeds again, push the new buffers and
> stop the workaround (stop generating pictures or push down an event)

In my opinion, this is too much for an element. The element could instead
provide (if not already) ways to let application handle it. I remember Youness
Alaoui that propsed an API to transparently handle WebCAMs going away, flipping
it with a black frame generator and letting application dynamically select a
new one, or the same if it came back. This is all outdated, but if it was
possible when he did it, it should still be possible now. Except now we have
new discovery API (GstDeviceMonitor) which should help.


> Here is a WIP list of known issues that we want to mitigate on a generic
> manner:
> * signal unplugged during capture (dqbuf fails)

As there is no event from the device, application can grab the device FD and
poll for it. If signal is lost, it would swap the source, and keep polling,
when it comes back, it would swap again.

> * no signal when starting capture (requires defining a default caps negotiation
> strategy -- will not work with devices/drivers that don't support scaling)

Not sure what happen, will probably lead to no-negotiated on certain devices.
Application can catch the error on sync bus, remove it. We could have a way to
poll on the element while it's in READY state. This will always remain specific
to this element.

> * v4l2 device disappears (USB unplugged example)

That will throw an error, application can remove this error and swap.

> * v4l2 device driver crashes and stops responding (buggy hardware / overheating
> hardware)

This case might be unrecoverable, no luck, fix your driver. Per experience,
this often lead to the lost of a CPU and all attached process becomes zomby.

> * random "temporary" kernel errors, which require to restart the capture after
> some "quiet time"

Will error out, same thing.

> * override device-provided fake frames by the user-defined strategy (some
> devices actually do it) by querying V4l2.VIDIOC_ENUMINPUT.status 

Should be application side, with may be property to help.

> 
> Open questions:
> * what about compressed streams ?

There is nothing you can do, unless you are allowed to swap with something that
encode.

> * is this feature generic enough to integrate into videorate or is a separate
> element better ?

I don't think it's inline with videorate role in my opinion.

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.