Le mercredi 30 janvier 2019 à 12:38 +0900, Tomasz Figa a écrit : > > Yes, unfortunately, GStreamer still rely on G_FMT waiting a minimal > > amount of time of the headers to be processed. This was how things was > > created back in 2011, I could not program GStreamer for the future. If > > we stop doing this, we do break GStreamer as a valid userspace > > application. > > Does it? Didn't you say earlier that you end up setting the OUTPUT > format with the stream resolution as parsed on your own? If so, that > would actually expose a matching framebuffer format on the CAPTURE > queue, so there is no need to wait for the real parsing to happen. I don't remember saying that, maybe I meant to say there might be a workaround ? For the fact, here we queue the headers (or first frame): https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/blob/master/sys/v4l2/gstv4l2videodec.c#L624 Then few line below this helper does G_FMT internally: https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/blob/master/sys/v4l2/gstv4l2videodec.c#L634 https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/blob/master/sys/v4l2/gstv4l2object.c#L3907 And just plainly fails if G_FMT returns an error of any type. This was how Kamil designed it initially for MFC driver. There was no other alternative back then (no EAGAIN yet either). Nicolas p.s. it's still in my todo's to implement source change event as I believe it is a better mechanism (specially if you header happened to be corrupted, then the driver can consume the stream until it finds a sync). So these sleep or normally wait exist all over to support this legacy thing. It is unfortunate, the question is do you want to break userspace now ? Without having first placed a patch that would maybe warn or something for a while ?
