Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Return the correct number of bytes #435

Closed
wants to merge 1 commit into from

Conversation

DemiMarie
Copy link

@DemiMarie DemiMarie commented Jun 3, 2021

This is needed for Firefox to play more than one frame. This applies
the fix from #190 (comment).

This is needed for Firefox to play more than one frame.  This applies
the fix from umlaeute#190 (comment).
@umlaeute
Copy link
Owner

umlaeute commented Jul 13, 2021

i'm still unsure whether this isn't a bug in gstreamer.

the kernel docs say:

The number of bytes occupied by the data in the buffer. It depends on the negotiated data format and may change with each buffer for compressed variable size data like JPEG images. [...] Applications [must set it when type] refers to an output stream. If the application sets this to 0 for an output stream, then bytesused will be set to the size of the buffer (see the length field of this struct) by the driver.

and further on i think clarifies what "number of bytes occupied" is supposed to mean (although this is then in the docs for the struct v4l2_plane, which is not what we are talking about here):

The number of bytes occupied by data in the plane (its payload).

i'd argue that the payload doesn't include any page-padding.

@hverkuil could you shed some light on this?

@hverkuil
Copy link
Contributor

hverkuil commented Jul 13, 2021 via email

@mzihlmann
Copy link
Contributor

for me the underlying issue is now fixed on HEAD 845cea0
i have not yet binary searched for which commit actually does the fix.

jwrdegoede added a commit to jwrdegoede/v4l2loopback that referenced this pull request May 8, 2023
Gstreamer's v4l2sink is known to submit buffers with bytesused set to
the length of the buffer instead of the size of the actual image-data
within the buffer which is typically smaller due to buffer sizes
being rounded op to a page-size:

https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2532

Despite this being a long standing issue and their being 2 merge-reqs:

https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3713
https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4527

to try and fix this it looks like this is not going to get fixed
in gst's v4l2sink anytime soon and even if once it is fixed many users
will likely be using an older v4l2sink which still has this bug.

These buffers with a too large bytes used value are causing issues
with various apps which reject these buffers when reading from
the v4l2loopback device, such as e.g. ffmpeg and firefox.

Add a pix_format_has_valid_sizeimage flag which gets set from
vidioc_s_fmt_out() if dev->pix_format.sizeimage is known to have just
been set to a valid, fixed size (so this e.g. won't be set for MJPG).

And then fix this issue by making vidioc_qbuf() truncate
V4L2_BUF_TYPE_VIDEO_OUTPUT buffer's bytes_used value to
dev->pix_format.sizeimage when this flag is set.

Closes umlaeute#190
Closes umlaeute#448
Obsoletes umlaeute#435
@umlaeute
Copy link
Owner

closing as obsolete

@umlaeute umlaeute closed this May 10, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants