gstreamer1.0-plugins-base: Add bbappend to apply Qualcomm patches #1349

Raja-Ganapathi-Busam · 2026-01-02T14:54:40Z

Summary

This PR adds bbappend file to the gstreamer1.0-plugins-base recipe to append additional patches from an external series file after the base recipe patches. The patches are imported using quilt in the correct order and applied after existing patches.

Key Changes

Fetched additional patches and series file from external Git repository
Skipped lines starting with # in the series file (treated as comments).
Imported and applied patches in series file order using quilt import and push

Temporary Setup

There is a separate pull request raised on the patches repository which is pending review and merge.
Until that PR is merged, SRC_URI in this recipe points to my forked repository to fetch the patches.

Merge Condition

Please merge this PR only after the patches PR is merged in the patches repository, gst-qti-oss-patches, to ensure consistency.

Testing

Verified patches apply in correct order mentioned in series file.
Confirmed that comment lines (#) in the series file, if any, are skipped.
Build completed successfully with updated patches.

lumag · 2026-01-02T15:23:30Z

I'm sorry, this is a nice hack, but no. Please follow the usual process: add the patches to the layer repo instead of storing them in the external repo. Contribute all the patches to the upstream project, UBWC compression should be supported upstream, it doesn't differ any other compression schemes.

CherukuriNaveenQC · 2026-01-05T05:10:38Z

@lumag As canonical suggesting hosting in separate repo instead of putting patches along with distribution and we would like to maintain patches in one central repo for all distributions and our team had initial discussion with Nico and explained the reason to host in Github

@ndechesne could you please comment your feedback here.

Raja-Ganapathi-Busam · 2026-01-05T07:29:40Z

There are complications in upstreaming patches related to the UBWC (Universal Bandwidth Compression) format.
Please refer to the ongoing open-source discussion here:
https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/9712

Since UBWC is a proprietary format, we cannot provide the pack/unpack logic in open source. The upstream community does not accept a packed format without corresponding pack/unpack implementations.
Additionally, to leverage the memory:DMABuf caps feature, there are challenges in retrieving video meta information required for buffer mapping.

We are actively collaborating with the community to find a way forward, but this will take time to reach alignment.
Until then, we plan to maintain these patches locally to ensure functionality.

ndechesne · 2026-01-05T07:32:05Z

hi. this is indeed aligned with what we discussed (privately), but let's discuss that here now.

I proposed to manage gstreamer in a different way because it has , I think, different challenges.

the gst team needs to support many different gst version (major and minor), so they need to store gst patches for each of the supported versions 'somewhere'.
we want to package QCOM gstreamer 'changes' for each distro we support (yocto, but also debian). and we have 3rd party doing their own too (Ubuntu)
we are actively engaged to upstream our changes, so the goal remain to have less patches (no patches?) eventually.

I understand it is not the standard way to host patches for OE recipes, but it's a practical solution to help us overall.

sbanerjee-quic · 2026-01-05T09:26:32Z

recipes-multimedia/gstreamer/gstreamer1.0-plugins-base_%.bbappend

+SRCREV_qti_patches = "${AUTOREV}"
+
+qcom_do_patch() {
+    PATCHREPO="${WORKDIR}/sources/patchrepo"


Start as do_patch_
Can you name this more appropriately in the purpose?

Removed dependency on quilt and added the raw URIs directly in the SRC_URI.
Comment not applicable now.

sbanerjee-quic · 2026-01-05T09:29:01Z

recipes-multimedia/gstreamer/gstreamer1.0-plugins-base_%.bbappend

+            esac
+
+            if [ -f "${PATCHREPO}/${p}" ]; then
+                quilt import "${PATCHREPO}/${p}"


you need to depend on quit-native

In my understanding, Yocto uses quilt as the default PATCHTOOL.
Since this function runs inside do_patch:append, the environment already ensures quilt-native is available.
Therefore, we do not need to explicitly add DEPENDS += "quilt-native" in the .bbappend file.

Of course you need to do it. If something is changed in OE-Core then your recipe gets broken.

Removed dependency on quilt and added the raw URIs directly in the SRC_URI.
Comment not applicable now.

ndechesne · 2026-01-05T09:40:01Z

recipes-multimedia/gstreamer/gstreamer1.0-plugins-base_%.bbappend

+    git://github.com/Raja-Ganapathi-Busam/gst-qti-oss-patches.git;protocol=ssh;user=git;branch=${PV};name=qti_patches;destsuffix=patchrepo;subpath=${BPN} \
+"
+
+SRCREV_qti_patches = "${AUTOREV}"


no AUTOREV, we only rely on fixed content/metadata in meta-qcom.

Our intention is to avoid making changes in meta-qcom repo if there is any update in patches repo.
Please suggest.

there is no other way around. You need to make changes to meta-qcom when you change the version of the software we build in meta-qcom.

+1 here. If you make changes to your repo, it is a different version, a different recipe revision and a different set of packages. The item will go away once you drop the custom do_patch implementation and use OE's one (together with using raw URIs)

Removed dependency on quilt and added the raw URIs directly in the SRC_URI.

ndechesne · 2026-01-05T09:50:55Z

recipes-multimedia/gstreamer/gstreamer1.0-plugins-base_%.bbappend

@@ -0,0 +1,37 @@
+# To apply patches to support Qualcomm specific formats and fixes
+SRC_URI:append:qcom = " \
+    git://github.com/Raja-Ganapathi-Busam/gst-qti-oss-patches.git;protocol=ssh;user=git;branch=${PV};name=qti_patches;destsuffix=patchrepo;subpath=${BPN} \


if the patches are available in a public http link, perhaps we could list them here directly. that might be a better approach that strictly depending on an external git tree.

a link like this one (this is just an example)

https://raw.githubusercontent.com/qualcomm-linux/meta-qcom/e74ef28e7df313edf77e6aafe2f789ef324b09d5/conf/layer.conf

At least you wouldn't need to have a custom do_patch implementation.

We are in process of making git://github.com/qualcomm/gst-qti-oss-patches public. Meanwhile, we would like to have a review of our approach

We are in the process of making the patches repository public.
Once it becomes publicly accessible, I will update the link accordingly.

I understand, and I made the review in this context. I am not saying that the link is not public, but suggesting a different approach. Instead of downloading the whole tree and manually applying the patches yourself in the qcom_do_patch() function, you can list all the patches as http:// links SRC_URI.

That way, you still preserver your tree with standalone patches which is convenient for what we discussed, and we still integrate patches 'normally' (almost) from an OE metadata perspective

I understand, and I made the review in this context. I am not saying that the link is not public, but suggesting a different approach. Instead of downloading the whole tree and manually applying the patches yourself in the qcom_do_patch() function, you can list all the patches as http:// links SRC_URI.

That way, you still preserver your tree with standalone patches which is convenient for what we discussed, and we still integrate patches 'normally' (almost) from an OE metadata perspective

I think that is also what as suggested by me in the meetings before the solstice break. Having a custom do_patch is very fragile and rarely required.

You can still point out the raw URIs inside your repo (and change them later to the official one once it's public).

As suggested, removed dependency on quilt and added the raw URIs directly in the SRC_URI.

lumag · 2026-01-05T20:16:18Z

Okay.

@lumag As canonical suggesting hosting in separate repo instead of putting patches along with distribution and we would like to maintain patches in one central repo for all distributions and our team had initial discussion with Nico and explained the reason to host in Github

This will not work in a long term. Ubuntu, Debian, Fedora and OE will have different versions of the GStreamer. At some point your patches won't be unuquelly applicable to those versions, so you will have to have separate branches or revisions. Having that in mind it is much easier to incorporate those patches into the distro package as it is usually done. I definitely don't expect Debian / Ubuntu packages fetching additional repo during the build stage.

Since UBWC is a proprietary format, we cannot provide the pack/unpack logic in open source. The upstream community does not accept a packed format without corresponding pack/unpack implementations.

UBWC format has been reverse engineered. There was another study of the compressed formats, which I can find quickly at this moment. As such, I can only recommend actually defining the compress and decompress functions and following Gstreamer requirements. Other projects would also benefit from it. We have hard time testing the UBWC support on the display side because there is no defined way to create or validate generated UBWC images.

recipes-multimedia/gstreamer/gstreamer1.0-plugins-base_%.bbappend

Fetched additional patches from external Git repository using raw URL Signed-off-by: Raja Ganapathi Busam <rbusam@qti.qualcomm.com>

anujm1 · 2026-01-06T11:50:40Z

Okay.

@lumag As canonical suggesting hosting in separate repo instead of putting patches along with distribution and we would like to maintain patches in one central repo for all distributions and our team had initial discussion with Nico and explained the reason to host in Github

This will not work in a long term. Ubuntu, Debian, Fedora and OE will have different versions of the GStreamer. At some point your patches won't be unuquelly applicable to those versions, so you will have to have separate branches or revisions. Having that in mind it is much easier to incorporate those patches into the distro package as it is usually done. I definitely don't expect Debian / Ubuntu packages fetching additional repo during the build stage.

In addition to this, since we now have meta-qcom running on YP autobuilder, every gstreamer version update will break master-next build.

anujm1 · 2026-01-06T12:02:35Z

Okay.

@lumag As canonical suggesting hosting in separate repo instead of putting patches along with distribution and we would like to maintain patches in one central repo for all distributions and our team had initial discussion with Nico and explained the reason to host in Github

This will not work in a long term. Ubuntu, Debian, Fedora and OE will have different versions of the GStreamer. At some point your patches won't be unuquelly applicable to those versions, so you will have to have separate branches or revisions. Having that in mind it is much easier to incorporate those patches into the distro package as it is usually done. I definitely don't expect Debian / Ubuntu packages fetching additional repo during the build stage.

In addition to this, since we now have meta-qcom running on YP autobuilder, every gstreamer version update will break master-next build.

I forgot we are building base image. It won't break on every update but will fail to parse if bbappend is version specific or if we add an image build that includes gstreamer there.

CherukuriNaveenQC · 2026-01-06T12:11:08Z

When we branch off QLI 2.x then both Yocto and Ubuntu uses same version of GStreamer in my opinion. So, instead of maintaining patches in multiple places, we would like to maintain in one place. Also, I got to know that Canonical does not want attach patches in distribution and instead they asking us to host patches in a repo.

ndechesne · 2026-01-06T14:00:59Z

When we branch off QLI 2.x then both Yocto and Ubuntu uses same version of GStreamer in my opinion. So, instead of maintaining patches in multiple places, we would like to maintain in one place. Also, I got to know that Canonical does not want attach patches in distribution and instead they asking us to host patches in a repo.

There is no guarantee that Yocto and Ubuntu will use the same version of Gstreamer. It might happen, but maybe not.
What you say about Canonical (or Ubuntu) is also not right, since Ubuntu is hosting patches into its distribution (on launchpad). What they are asking is a convenient place to find our patches, but they will duplicate them and make a copy into Ubuntu.

CherukuriNaveenQC · 2026-01-06T14:13:48Z

@ndechesne Got it. Can you please suggest whether we can go ahead with HTTP URI for the patch location and we will apply patches for other GStreamer packages as well in similar way.

ndechesne · 2026-01-06T15:32:18Z

@ndechesne Got it. Can you please suggest whether we can go ahead with HTTP URI for the patch location and we will apply patches for other GStreamer packages as well in similar way.

yes, that's the only way to get them, I think.

@anujm1 brought up a good point though. now that we committed to supporting Meta-qcom in upstream Yocto CI, making such unexpected/bad gstreamer tweaks which might break Yocto CI is problematic.. but that's a different problem, we might need to find a way to limit when we apply the patches.

ndechesne · 2026-01-06T15:40:27Z

recipes-multimedia/gstreamer/gstreamer1.0-plugins-base_%.bbappend

@@ -0,0 +1,15 @@
+# To apply patches to support Qualcomm specific formats and fixes
+
+PATCH_BASE = "https://raw.githubusercontent.com/Raja-Ganapathi-Busam/gst-qti-oss-patches/refs/heads/${PV}/${BPN}"


can you open the tree so that we can have a look? at least share with the meta-qcom maintainers?

@ndechesne we have shared patches via email as patches repo still not public due to legal review

ndechesne · 2026-01-06T15:41:01Z

recipes-multimedia/gstreamer/gstreamer1.0-plugins-base_%.bbappend

+
+PATCH_BASE = "https://raw.githubusercontent.com/Raja-Ganapathi-Busam/gst-qti-oss-patches/refs/heads/${PV}/${BPN}"
+
+SRC_URI:append:qcom = " \


I understand it is more work on your side to manage the patches, but it really look much better than the first patch, thanks!

lumag · 2026-01-06T15:39:43Z

recipes-multimedia/gstreamer/gstreamer1.0-plugins-base_%.bbappend

+SRC_URI[q08c_patch.sha256sum] = "7455df8252fc1655184a4659bdc8ce1479595ed3bd788578c3e909582af04803"
+SRC_URI[q10c_patch.sha256sum] = "2d7f448abc9da7843959b193861d1266a11a71365908900d7b4a31d8e20c19e6"
+SRC_URI[vmeta_patch.sha256sum] = "76ba2ae3e40d1cbb016561ad7fb8027cacd120f67a6fde4c2a8d992be3ae27ba"
+SRC_URI[vrate_patch.sha256sum] = "393cdd2ede68080db6e6f969373358d66dc92e6025cddc4307595aca650d6ef5"


This doesn't play well with the Yocto Compatibility requirements. While we probably can come up with a different scheme, I would ask to vendor in all patches here rather than pulling them from the external repo.

You can observe the issue as a failure of the yocto-run-checks step.

lumag · 2026-01-06T15:42:43Z

recipes-multimedia/gstreamer/gstreamer1.0-plugins-base_%.bbappend

@@ -0,0 +1,15 @@
+# To apply patches to support Qualcomm specific formats and fixes
+
+PATCH_BASE = "https://raw.githubusercontent.com/Raja-Ganapathi-Busam/gst-qti-oss-patches/refs/heads/${PV}/${BPN}"


This still allows updating the repo in a way that the patches will be changed, breaking the builds. The names of the patches don't incorporate version of the recipe (nor the revision of the patch), so when the patch is updated in the repo, it will not be redownloaded, triggering the checksum errors for the builders.

this is always a problem. if 'upstream' changes the tarball we use, it breaks the build.. here if we do crazy things on gst-qti-oss-patches and rewrite commits, then yes, it's bad and it will break things. i don't see how it's different here. we have checksums for the files, so we check for such issues.

There is a difference between checking for upstream misbehaviour and knowingly introducing a change that will report an error once the repo gets updated.

ricardosalveti · 2026-01-06T16:13:44Z

When we branch off QLI 2.x then both Yocto and Ubuntu uses same version of GStreamer in my opinion. So, instead of maintaining patches in multiple places, we would like to maintain in one place. Also, I got to know that Canonical does not want attach patches in distribution and instead they asking us to host patches in a repo.

Also, mainline (master here) will continue, and it is expected that the versions will differ. You should not make any version assumption here as the decision is up for the distros.

ricardosalveti · 2026-01-06T16:15:51Z

I understand it is not the standard way to host patches for OE recipes, but it's a practical solution to help us overall.

I don't really like this approach, so NAK from my side, there is nothing special here and the patches should be maintained as part of this layer, so we can also enforce a proper level of quality there.

Also, we do want to allow any developer to fix these patches once there is a version update in oe-core that could potentially break them, hosting externally will cause additional friction.

ricardosalveti

NAK from my side, extra patches should be hosted and maintained as part of this repository, so we can review the quality of the patches and also support accepting fixes that could be proposed by anyone.

Raja-Ganapathi-Busam requested review from lumag, ndechesne, ricardosalveti, sbanerjee-quic and vkraleti as code owners January 2, 2026 14:54

sbanerjee-quic reviewed Jan 5, 2026

View reviewed changes

ndechesne reviewed Jan 5, 2026

View reviewed changes

lumag reviewed Jan 5, 2026

View reviewed changes

recipes-multimedia/gstreamer/gstreamer1.0-plugins-base_%.bbappend Outdated Show resolved Hide resolved

lumag marked this pull request as draft January 5, 2026 20:21

gstreamer1.0-plugins-base: Add bbappend to apply Qualcomm patches

51801cf

Fetched additional patches from external Git repository using raw URL Signed-off-by: Raja Ganapathi Busam <rbusam@qti.qualcomm.com>

Raja-Ganapathi-Busam force-pushed the gst_qti_patches branch from 615af4c to 51801cf Compare January 6, 2026 11:21

Raja-Ganapathi-Busam changed the title ~~gstreamer1.0-plugins-base: Add bbappend to apply patches from external git repo~~ gstreamer1.0-plugins-base: Add bbappend to apply Qualcomm patches Jan 6, 2026

Raja-Ganapathi-Busam marked this pull request as ready for review January 6, 2026 11:33

ndechesne reviewed Jan 6, 2026

View reviewed changes

lumag requested changes Jan 6, 2026

View reviewed changes

ricardosalveti requested changes Jan 6, 2026

View reviewed changes

		@@ -0,0 +1,15 @@
		# To apply patches to support Qualcomm specific formats and fixes

		PATCH_BASE = "https://raw.githubusercontent.com/Raja-Ganapathi-Busam/gst-qti-oss-patches/refs/heads/${PV}/${BPN}"


		PATCH_BASE = "https://raw.githubusercontent.com/Raja-Ganapathi-Busam/gst-qti-oss-patches/refs/heads/${PV}/${BPN}"

		SRC_URI:append:qcom = " \

gstreamer1.0-plugins-base: Add bbappend to apply Qualcomm patches #1349

Are you sure you want to change the base?

gstreamer1.0-plugins-base: Add bbappend to apply Qualcomm patches #1349

Conversation

Raja-Ganapathi-Busam commented Jan 2, 2026

Summary

Key Changes

Temporary Setup

Merge Condition

Testing

Uh oh!

lumag commented Jan 2, 2026

Uh oh!

CherukuriNaveenQC commented Jan 5, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Raja-Ganapathi-Busam commented Jan 5, 2026

Uh oh!

ndechesne commented Jan 5, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

lumag commented Jan 5, 2026

Uh oh!

Uh oh!

anujm1 commented Jan 6, 2026

Uh oh!

anujm1 commented Jan 6, 2026

Uh oh!

CherukuriNaveenQC commented Jan 6, 2026

Uh oh!

ndechesne commented Jan 6, 2026

Uh oh!

CherukuriNaveenQC commented Jan 6, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ndechesne commented Jan 6, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

CherukuriNaveenQC commented Jan 5, 2026 •

edited

Loading

CherukuriNaveenQC commented Jan 6, 2026 •

edited

Loading

ricardosalveti commented Jan 6, 2026 •

edited

Loading