After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 776936 - v4l2videodec: bufferpool size is fixed to 2
v4l2videodec: bufferpool size is fixed to 2
Status: RESOLVED NOTABUG
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
git master
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2017-01-06 10:40 UTC by Michael Tretter
Modified: 2017-03-05 15:10 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
v4l2videodec: Use negotiated bufferpool size when activating pool (1.40 KB, patch)
2017-01-06 10:41 UTC, Michael Tretter
needs-work Details | Review

Description Michael Tretter 2017-01-06 10:40:12 UTC
When the videodec element activates the v4l2 bufferpool, it sets the size of the input internal pool to a fixed value of 2. However, the videodec element already configured the bufferpool size according to the minimum required by the v4l2 driver.

Instead of using the fixed value, the videodec element should ask the bufferpool for its configured size and use that one.
Comment 1 Michael Tretter 2017-01-06 10:41:45 UTC
Created attachment 343003 [details] [review]
v4l2videodec: Use negotiated bufferpool size when activating pool

The bufferpool size is already negotiated when setting the format on the
v4l2 object including the minimum bufferpool size required by the v4l2
driver.
                                                                        
Do not use a fixed bufferpool size of 2, but ask the bufferpool for its
configured size and use it.
Comment 2 Nicolas Dufresne (ndufresne) 2017-01-16 15:27:30 UTC
Review of attachment 343003 [details] [review]:

In the particular case, the buffers will be copied, there is no need to respect the negotiated number of buffers. I agree it should respect the minimum suggested by the driver though. On the other end, it's driver role to enforce this minimum through when REQBUFS is called. Maybe I'm missing something, it would be nice to clarify.
Comment 3 Michael Tretter 2017-03-01 08:49:05 UTC
(In reply to Nicolas Dufresne (stormer) from comment #2)
> Review of attachment 343003 [details] [review] [review]:
> 
> In the particular case, the buffers will be copied, there is no need to
> respect the negotiated number of buffers. I agree it should respect the
> minimum suggested by the driver though. On the other end, it's driver role
> to enforce this minimum through when REQBUFS is called. Maybe I'm missing
> something, it would be nice to clarify.

The minimum was OK, but I was more concerned about the maximum, but I missed that the buffers are copied. I now understand that the V4l2Allocator maintains an internal queue and that this prevents the allocation of additional buffers in the buffer pool. Is this correct?

Maybe a comment that explains the 2 or using GST_V4L2_MIN_BUFFERS instead of the 2 would be helpful.

Anyway, thanks for the clarification. This patch is not needed.