[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 #16 from Florent Thiery <florent.thiery at ubicast.eu> 2015-01-09 17:11:30 UTC ---
Indeed, the "official" way of querying the device for signal presence is
currently V4l2.VIDIOC_ENUMINPUT.status (see
http://www.linuxtv.org/downloads/v4l-dvb-apis/vidioc-enuminput.html -- which
provides details about the cause, see
http://www.linuxtv.org/downloads/v4l-dvb-apis/vidioc-enuminput.html#input-status).
However, i believe this may be driver-dependant, which means we may not rely
(only) on this. All devices we had our hands on did expose that, but may only
return 0 when signal is present and not fully provide the exact reason. I don't
know if all the drivers do implement the status properly though, any counter
examples would be interesting.

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.

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)
* 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)

Regarding the vent (custom meta or GAP event), since you can't really predict
how long the no-signal will be, is it okay if you push several contiguous GAP
events with a constant duration (e.g. defined after the retry-delay property) ?

I agree with separating the frame generation in videorate or a dedicated
element so that it can also be used with decklinksrc, dv1394src, ... As long as
they emit GAP events.

The mitigation strategy defined in the target element should be configurable
among:
* duplicate the last known frame (could be something not so nice, like an
incomplete buffer, and will require a copy per buffer or keep the previous
buffer allocated)
* black picture, or even color-selectable, with an optional user-defined text,
or even text containing details on the failure (e.g. unsupported input,
out-of-range...)
* a png picture ?
* ...

Here is a WIP list of known issues that we want to mitigate on a generic
manner:
* signal unplugged during capture (dqbuf fails)
* no signal when starting capture (requires defining a default caps negotiation
strategy -- will not work with devices/drivers that don't support scaling)
* v4l2 device disappears (USB unplugged example)
* v4l2 device driver crashes and stops responding (buggy hardware / overheating
hardware)
* random "temporary" kernel errors, which require to restart the capture after
some "quiet time"
* override device-provided fake frames by the user-defined strategy (some
devices actually do it) by querying V4l2.VIDIOC_ENUMINPUT.status 

Open questions:
* what about compressed streams ?
* is this feature generic enough to integrate into videorate or is a separate
element better ?

-- 
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.