[GStreamer][WebRTC] increase size of apps max-bytes for video tracks #1595
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The default 200'000 is not enough and leads to frame drops during pipeline buildup.
Member
|
Reviewing this... |
eocanha
reviewed
Jan 15, 2026
| { | ||
| m_src = makeElement("appsrc"); | ||
| g_object_set(m_src, "is-live", TRUE, "do-timestamp", TRUE, "max-buffers", 2, "max-bytes", 0, nullptr); | ||
| g_object_set(m_src, "is-live", TRUE, "do-timestamp", TRUE, "max-buffers", static_cast<gint64>(2), "max-bytes", static_cast<guint64>(0), nullptr); |
Member
There was a problem hiding this comment.
Note that this isn't actually increasing anything, just tidying up the argument types. Is this intended?
Member
There was a problem hiding this comment.
Also, both casts should be done to guint64, since that's the type used both for max-buffers and for max-bytes in appsrc.
I'm already correcting this in the version that I'm submitting for review upstream.
Collaborator
Author
There was a problem hiding this comment.
Hi @eocanha , this is intentional. It is needed on arm32, or it might pick up random data from the stack.
The increase is needed on the media stream source side only.
Also, both casts should be done to guint64
Yes, you're right. I guess I confused it with the type of 'max-latency'.
eocanha
added a commit
to eocanha/WebKit
that referenced
this pull request
Jan 15, 2026
https://bugs.webkit.org/show_bug.cgi?id=305576 Reviewed by NOBODY (OOPS!). The default value for max-bytes in 200000 is not enough and leads to frame drops during pipeline buildup. See: WebPlatformForEmbedded/WPEWebKit#1595 This patch increases the buffering size of the appsrc element used for video tracks in GStreamerMediaStreamSource so that it can handle enough buffering to allow for the rest of the pipeline to be built before buffers start to be lost. Types fo max-buffer/max-bytes args in GStreamerVideoDecoderFactory are also enforced as guint64. This seems to be the recommended way to do it according to the GObject documentation[1], [1] https://docs.gtk.org/gobject/method.Object.set.html#description Original author: Eugene Mutavchi <Ievgen_Mutavchi@comcast.com> * Source/WebCore/platform/mediastream/gstreamer/GStreamerMediaStreamSource.cpp: Increase buffering size for video tracks. * Source/WebCore/platform/mediastream/libwebrtc/gstreamer/GStreamerVideoDecoderFactory.cpp: Properly type guint64 parameters.
eocanha
added
the
upstream
Member
|
Submitted for review upstream as https://bugs.webkit.org/show_bug.cgi?id=305576 |
eocanha
added a commit
to eocanha/WebKit
that referenced
this pull request
Jan 16, 2026
https://bugs.webkit.org/show_bug.cgi?id=305576 Reviewed by NOBODY (OOPS!). The default value for max-bytes in 200000 is not enough and leads to frame drops during pipeline buildup. See: WebPlatformForEmbedded/WPEWebKit#1595 This patch increases the buffering size of the appsrc element used for video tracks in GStreamerMediaStreamSource so that it can handle enough buffering to allow for the rest of the pipeline to be built before buffers start to be lost. The right types are used for the parameters, according to GObject best practices[1]. Aa an opportunistic cleanup task, types for max-buffer/max-bytes arguments in GStreamerVideoDecoderFactory are also enforced as guint64. This seems to be the recommended way to do it according to the GObject documentation[1], [1] https://docs.gtk.org/gobject/method.Object.set.html#description Original author: Eugene Mutavchi <Ievgen_Mutavchi@comcast.com> * Source/WebCore/platform/mediastream/gstreamer/GStreamerMediaStreamSource.cpp: Increase buffering size for video tracks and use proper types for the parameters. * Source/WebCore/platform/mediastream/libwebrtc/gstreamer/GStreamerVideoDecoderFactory.cpp: Cleanup by properly typing guint64 parameters.
webkit-commit-queue
pushed a commit
to eocanha/WebKit
that referenced
this pull request
Jan 16, 2026
https://bugs.webkit.org/show_bug.cgi?id=305576 Reviewed by Xabier Rodriguez-Calvar. The default value for max-bytes in 200000 is not enough and leads to frame drops during pipeline buildup. See: WebPlatformForEmbedded/WPEWebKit#1595 This patch increases the buffering size of the appsrc element used for video tracks in GStreamerMediaStreamSource so that it can handle enough buffering to allow for the rest of the pipeline to be built before buffers start to be lost. The right types are used for the parameters, according to GObject best practices[1]. Aa an opportunistic cleanup task, types for max-buffer/max-bytes arguments in GStreamerVideoDecoderFactory are also enforced as guint64. This seems to be the recommended way to do it according to the GObject documentation[1], [1] https://docs.gtk.org/gobject/method.Object.set.html#description Original author: Eugene Mutavchi <Ievgen_Mutavchi@comcast.com> * Source/WebCore/platform/mediastream/gstreamer/GStreamerMediaStreamSource.cpp: Increase buffering size for video tracks and use proper types for the parameters. * Source/WebCore/platform/mediastream/libwebrtc/gstreamer/GStreamerVideoDecoderFactory.cpp: Cleanup by properly typing guint64 parameters. Canonical link: https://commits.webkit.org/305705@main
eocanha
pushed a commit
that referenced
this pull request
Jan 16, 2026
https://bugs.webkit.org/show_bug.cgi?id=305576 Reviewed by Xabier Rodriguez-Calvar. The default value for max-bytes in 200000 is not enough and leads to frame drops during pipeline buildup. See: #1595 This patch increases the buffering size of the appsrc element used for video tracks in GStreamerMediaStreamSource so that it can handle enough buffering to allow for the rest of the pipeline to be built before buffers start to be lost. The right types are used for the parameters, according to GObject best practices[1]. Aa an opportunistic cleanup task, types for max-buffer/max-bytes arguments in GStreamerVideoDecoderFactory are also enforced as guint64. This seems to be the recommended way to do it according to the GObject documentation[1], [1] https://docs.gtk.org/gobject/method.Object.set.html#description Original author: Eugene Mutavchi <Ievgen_Mutavchi@comcast.com> * Source/WebCore/platform/mediastream/gstreamer/GStreamerMediaStreamSource.cpp: Increase buffering size for video tracks and use proper types for the parameters. * Source/WebCore/platform/mediastream/libwebrtc/gstreamer/GStreamerVideoDecoderFactory.cpp: Cleanup by properly typing guint64 parameters. Canonical link: https://commits.webkit.org/305705@main
Member
|
Landed upstream as WebKit/WebKit@7a0c687 and backported to wpe-2.46 as 6dc7dda. Closing PR. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The default 200'000 is not enough and leads to frame drops during pipeline buildup.
Also, this PR adds an explicit type cast for max-buffers/max-bytes arguments set in GStreamerVideoDecoderFactory.cpp