RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 2144557 - Rebase GStreamer stack to 1.22.1 or higher for RHEL 9.3
Summary: Rebase GStreamer stack to 1.22.1 or higher for RHEL 9.3
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 9
Classification: Red Hat
Component: gstreamer1
Version: CentOS Stream
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: rc
: ---
Assignee: Wim Taymans
QA Contact: Jiri Prajzner
URL:
Whiteboard:
Depends On:
Blocks: 1956874 2053295 2179288
TreeView+ depends on / blocked
 
Reported: 2022-11-21 16:06 UTC by Neal Gompa
Modified: 2023-11-07 09:43 UTC (History)
16 users (show)

Fixed In Version: gstreamer1-1.22.1-2.el9
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2023-11-07 08:31:50 UTC
Type: Component Upgrade
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker RHELPLAN-140059 0 None None None 2022-11-21 16:14:17 UTC
Red Hat Product Errata RHBA-2023:6411 0 None None None 2023-11-07 08:32:02 UTC

Description Neal Gompa 2022-11-21 16:06:34 UTC
Description of problem:
GStreamer 1.22 will release in December 2022, bringing significant improvements and new capabilities, especially around hardware acceleration and third-party plugins.

Notably, upgrading GStreamer will make it possible for me to build the libav plugin for ffmpeg and an up-to-date version of OpenH264 in EPEL.

Comment 1 Niels De Graef 2022-11-22 10:39:11 UTC
Looking at the upstream tracker for the schedule, it's currently targeting 22 December (https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/974) which means we can have a DTM of 17 or later only, so unsetting the current one.

Wim, since 9.2 is an LTS release I wonder if it would make sense to target 22.2.1 instead so we've gotten an initial batch of bugfixes? That would probably also mean targeting 9.3, which might then also be a better fit for QE (although that is up to tpelka to decide)

Comment 2 Wim Taymans 2022-11-22 11:47:56 UTC
> Wim, since 9.2 is an LTS release I wonder if it would make sense to target 22.2.1 instead so we've gotten an initial batch of bugfixes? That would probably also mean targeting 9.3, which might then also be a better fit for QE (although that is up to tpelka to decide)

Fine for me and 1.22 might also be delayed, we don't know yet.

Comment 3 Neal Gompa 2022-11-22 20:21:42 UTC
I should also elaborate that this is part of a push I'm working on to build up the multimedia capabilities of RHEL/CentOS for creative professionals to use. And RHEL 9.2 is likely the first release to see some serious adoption on that front, so it'd be nice to have it all there.

Comment 4 Neal Gompa 2023-01-14 14:57:38 UTC
GStreamer 1.22rc1 (1.21.90) released last night: https://gitlab.freedesktop.org/gstreamer/gstreamer/-/commit/a9ec35b1ca3193820f434fd17a71207cde19de2b

Tarballs are available now. It looks like the aim is to have GStreamer 1.22.0 released by the end of this month. That would put 1.22.1 probably in early February, which should fit in the development window for RHEL 9.2.

Comment 6 Pat Riehecky 2023-02-28 23:06:46 UTC
Having this up to date would greatly simplify my life for integration purposes.

Comment 10 Neal Gompa 2023-03-09 20:41:20 UTC
Since we're moving to RHEL 9.3 for this, could we look at GStreamer 1.24? It's supposed to arrive in June/July, which gives plenty of time to integrate it and we can also get much fuller support for AV1 (VA-API support for AV1 in GStreamer is supposed to land in 1.24).

Comment 11 Pat Riehecky 2023-03-09 20:49:55 UTC
VA-API support for AV1 in GStreamer would make my life easier!

Comment 12 Wim Taymans 2023-03-10 08:27:12 UTC
If 1.24 is not too late it can be done.

Comment 15 Niels De Graef 2023-03-10 11:39:18 UTC
Hi Neal & Pat,

I suggest we start with a rebase to GStreamer 1.22.1 first and to file a separate request for 1.24 later. We can't possibly commit to backporting that version until we have an actual release upstream (and ideally a .1 release to make sure we get an initial batch of bugfixes). Depending on the timing of that release, it could of course mean it gets targeted to a later RHEL 9 version, but that's fine. Worst case, if we were to try to backport GStreamer 1.24 and it has issues, we'll have no rebase of GStreamer *at all* anytime soon.

Comment 19 Neal Gompa 2023-03-11 02:57:57 UTC
That's very fair. I just worry about asking too much given how difficult this stuff has been...

But yes, a GStreamer upgrade to 1.22.x is better than nothing.

Comment 20 Niels De Graef 2023-03-13 10:48:12 UTC
(In reply to Neal Gompa from comment #19)
> That's very fair. I just worry about asking too much given how difficult
> this stuff has been...

I understand it's not easy. From my point of view, some tips I can give:

* It's good to make requests early, but we can't really make any promises about anything that hasn't been released yet even upstream
* Similarly, versions that haven't gone through any upstream testing (including our upstream Fedora) are less inclined to be taken in (hence why I'd like to wait for example for a .1 release)
* We try to help the CentOS Stream community when we can, but CentOS Stream != RHEL. If you're targeting a use case that is important to RHEL or its customers, please make sure to write that in the BZ as that can help teams prioritize (of course, making a case why something is important for CentOS Stream can also make a difference still)
* Any change within a major version of RHEL needs to be backported and validated by teams within Red Hat (unless they exceptionally agree on the contrary) which is a different model than distros like Fedora. It also means that any change needs to compete with other (possibly internal) requests/bug fixes/etc for resources, which makes that certain changes -even though they might completely make sense externally- still might not be taken in

Comment 22 Neal Gompa 2023-04-04 09:45:23 UTC
Shouldn't the various gstreamer1-* packages also be updated, or do I need to file BZes for each individual one to get that to happen too?

Comment 23 Wim Taymans 2023-04-04 10:33:23 UTC
> Shouldn't the various gstreamer1-* packages also be updated, or do I need to file BZes for each individual one to get that to happen too?

They should be updated, you don't need to file individual bz for those.

The problem is that I can't build them until the main gstreamer package is in the buildroot and I don't know how to build packages for rhel in their own buildroot, so my current plan is to wait until they pass gating...

Comment 31 errata-xmlrpc 2023-11-07 08:31:50 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (gstreamer1 bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2023:6411


Note You need to log in before you can comment on or make changes to this bug.