Camera output freeze when using pipewiresrc

[Andy Chi]

[Impact]
On Dell platform with Microdia Integrated webcam, the Cheese preview is stuck on jammy. The gst-launch-1.0 command suggested by gst-device-monitor-1.0 can reproduce it too.

[Test Plan]
1. Install Jammy on the hardware issue reported, and hardware didn't report the issue to avoid the regression
   hardware list:
   a. 0bda:58ff Realtek Semiconductor Corp. Integrated_Webcam_HD
   b. 0c45:6747 Microdia Integrated_Webcam_HD
   c. 0c45:6a14 Microdia Integrated_Webcam_HD
   d. 1bcf:28d0 Sunplus Innovation Technology Inc. Integrated_Webcam_5M
   e. 04f2:b76b Chicony Electronics Co., Ltd HP HD Camera
   f. 0408:545a Quanta Computer, Inc. HP 5MP Camera
   g. 0408:5483 Quanta Computer, Inc. HP HD Camera
   h. 174f:2459 Syntek Integrated Camera (ThinkBook 14 Gen 4)
   i. 5986:116d Acer, Inc Integrated Camera (ThinkCentre Neo 50a)
   j. 0bda:5556 Realtek Semiconductor Corp. Integrated_Webcam_FHD
2. try to install the updated pipewire packages (= 0.3.48-1ubuntu2)
3. $ sudo reboot
4. Check if gst-launch-1.0 work
   a. $ gst-device-monitor-1.0 Video/Source to get caps and suggest gst-launch-1.0 command
   b. $ gst-launch-1.0 pipewiresrc path=<id> ! <cap> ! decodebin ! videoconvert ! glimagesink
   c. Check if the result ok
5. Check the screencast function by pressing 'prt sc'
   a. the screenshot of all screen/selected region should work good
   b. the screenrecord of all screen/selected region should work good
6. Check that video recording in gnome-shell works
   - use Ctrl+Shift+Alt+R to start a recording, stop it from the indicator, verify that there is a new entry in ~/Video
7. Check that screen sharing is working
   - go to settings, screen sharing and enable the feature
   - try to connect using rdp/vnc from another client

do those steps under wayland and unset X

[Where problems could occur]
The patches try to dequeue the shared buffer, instead of pool buffer to prevent the pool buffer being corrupted. it might cause some camera preview failed if shared buffer is corrupted.
It is in upstream from 0.3.52 to 0.3.56, and there is no regression found,
so the risk is low.

[Other Info]
Upstream commits:
https://gitlab.freedesktop.org/pipewire/pipewire/-/commit/7cc509b117a6db66c395fb56ac4f17fb8cbd0c92
https://gitlab.freedesktop.org/pipewire/pipewire/-/commit/a1f33a99df5756c3dedd68f5ba2690819098d14f

[Andy Chi (andch)]

apport information

[Andy Chi (andch)]

apport information

[Andy Chi (andch)]

apport information

[Andy Chi (andch)]

apport information

[Andy Chi (andch)]

apport information

[Andy Chi (andch)]

apport information

[Kai-Chuan Hsieh (kchsieh)]

My SPM5-DVT1.1-C3 have the same problem.

Here is my camera info:
0c45:6a14 Microdia Integrated_Webcam_HD

I attach the gst log with GST_DEBUG=3 when executing the gst-launch-1.0 command.
$ gst-launch-1.0 pipewiresrc path=3 ! image/jpeg, width=1280, height=720, framerate=25/1 ! jpegdec ! queue ! videoconvert ! glimagesink

A lot of frame dropped error:
3670:gst_video_decoder_clip_and_push_buf:<jpegdec0> Dropping frame due to QoS. start:0:00:00.489951086 deadline:0:00:00.489951086 earliest_time:0:00:00.583233118

[Kai-Chuan Hsieh (kchsieh)]

I create a build https://launchpad.net/~kchsieh/+archive/ubuntu/verification, 0.3.48-1ubuntu2~lp1985057.1. Add two upstream commits:

https://gitlab.freedesktop.org/pipewire/pipewire/-/commit/7cc509b117a6db66c395fb56ac4f17fb8cbd0c92
https://gitlab.freedesktop.org/pipewire/pipewire/-/commit/a1f33a99df5756c3dedd68f5ba2690819098d14f

The results looks good on my platform. Please check if the update works for you.

[Andy Chi (andch)]

Verified on camera id [0c45:6a1b] on problematic machine with debs from comment #8.

[steps]
1. Boot into OS
2. cheese

[result]
camera output is very smooth.

[Kai-Chuan Hsieh (kchsieh)]

Upload debdiff.

[Sebastien Bacher (seb128)]

Kinetic has 0.3.56 and it's fixed in that serie

[Sebastien Bacher (seb128)]

and I've sponsored the SRU now

[Robie Basak (racb)]

This looks like a memory management bug in fairly central code in pipewire upstream that has been fixed upstream with some significant refactoring. It is only two months old so can’t have had very wide testing in the ecosystem. In this time pipewire upstream have made a significant number of releases. And there is a subsequent upstream commit that fixes a race that I’m not sure is related or not. Possibly more than one. See for example: https://gitlab.freedesktop.org/pipewire/pipewire/-/commits/master/src/gst/gstpipewiresrc.c

The above assessment comes from a quick glance, not a detailed analysis. If this analysis is wrong I welcome being corrected.

For now, it does really feel like upstream are iterating here in a way that we really want to avoid doing in an LTS.

It’s clearly necessary to fix this bug, and cherry-picking from upstream does seem appropriate. However, for the above reasons I consider the risk of regression in this case to be particularly high. In particular I think the risk is significant that this sort of change will fix one piece of hardware at the cost of regressing another.

So to mitigate the regression potential, I think a substantial test plan is required. For example, I don’t think it’s sufficient to verify the fix only on the affected hardware and only with one application.

I’m not the expert here so I don’t want to dictate the specifics here, but for example I think you should plan to test:

A variety of different hardware, where the variety tries to cover the different factors that affect why this bug affects only this hardware in the first place (for example, also include different video capture resolutions)
A variety of different apps where the variety tries to cover different configurations, behaviours or code paths, as well as key use cases. Example: Google Meet with Chromium and Firefox, Zoom, screen sharing vs. webcam etc.

Please could you develop a Test Plan accordingly and update the bug? Then we can look again.

Thanks!

[Robie Basak (racb)]

Also, please analyse the newer upstream commits to determine if they fix any issues inadvertently introduced by this specific fix.

[Kai-Chuan Hsieh (kchsieh)]

@racb

Hello,

I updated the test plan to enhance the test coverage, could you help to check and provide your suggestion?

Thanks,

[Sebastien Bacher (seb128)]

I've added some testcases to the description now and reviewed the recent changes. While we could probably cherrypick more fixes the current set is enough to fix the issue and isn't needed extra fixup commit by itself, so we would prefer to keep the change to minimal and go with that set

[Kai-Chuan Hsieh (kchsieh)]

Test on Dell Latitude 9510, BIOS 1.12.0.

0bda:58ff Realtek Semiconductor Corp. Integrated_Webcam_HD

$ sudo add-apt-repository ppa:kchsieh/verification
$ sudo apt install pipewire
$ sudo reboot
1. gst-launch-1.0 command works good
$ gst-launch-1.0 pipewiresrc path=37 ! image/jpeg, width=1280, height=720, framerate=30/1 ! decodebin ! videoconvert ! glimagesink
2. screen cast works good
3. screen sharing via vnc works good

[Kai-Chuan Hsieh (kchsieh)]

Test on Dell Latitude 5530, BIOS 1.4.0.

0c45:6a14 Microdia Integrated_Webcam_HD

$ sudo add-apt-repository ppa:kchsieh/verification
$ sudo apt install pipewire
$ sudo reboot
1. gst-launch-1.0 command works good
$ gst-launch-1.0 pipewiresrc path=35 ! image/jpeg, width=1280, height=720, framerate=30/1 ! decodebin ! videoconvert ! glimagesink
2. screen cast works good
3. screen sharing via vnc works good

[Kai-Chuan Hsieh (kchsieh)]

Test on Dell new enablement platform, Galio 16, BIOS 89.3.0

0c45:6747 Microdia Integrated_Webcam_HD

$ sudo add-apt-repository ppa:kchsieh/verification
$ sudo apt install pipewire
$ sudo reboot
1. gst-launch-1.0 command works good
$ gst-launch-1.0 pipewiresrc path=35 ! image/jpeg, width=1280, height=720, framerate=30/1 ! decodebin ! videoconvert ! glimagesink
2. screen cast works good
3. screen sharing via vnc works good

[Andy Chi (andch)]

Test on Dell new enablement platform, Dakar AIO 24, BIOS 0.6.51

0bda:5556 Realtek Semiconductor Corp. Integrated_Webcam_FHD

$ sudo add-apt-repository ppa:kchsieh/verification
$ sudo apt install pipewire
$ sudo reboot
1. gst-launch-1.0 command works good
$ gst-launch-1.0 pipewiresrc path=35 ! image/jpeg, width=1280, height=720, framerate=30/1 ! decodebin ! videoconvert ! glimagesink
2. screen cast works good
3. screen sharing via vnc works good

[Kai-Chuan Hsieh (kchsieh)]

Test on HP EliteBook 865 16 inch G9 Notebook PC, BIOS U82 Ver. 01.02.01

0408:545a Quanta Computer, Inc. HP 5MP Camera

$ sudo add-apt-repository ppa:kchsieh/verification
$ sudo apt install pipewire
$ sudo reboot
1. gst-launch-1.0 command works good
$ gst-launch-1.0 pipewiresrc path=35 ! image/jpeg, width=1280, height=720, framerate=30/1 ! decodebin ! videoconvert ! glimagesink
2. screen cast works good
3. screen sharing via vnc works good

[Sebastien Bacher (seb128)]

@Andy, @Kai, what are you testing? the upload hasn't been accepted yet...

[Kai-Chuan Hsieh (kchsieh)]

@seb128

Hello,

I am trying to test on different hardware to relieve the concern of the regression.

I have a test build in my ppa.

[Robie Basak (racb)]

Hello Andy, or anyone else affected,

Accepted pipewire into jammy-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/pipewire/0.3.48-1ubuntu2 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-jammy to verification-done-jammy. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-jammy. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

[Kai-Chuan Hsieh (kchsieh)]

Test on Dell Latitude 9510, BIOS 1.12.0. Tested in wayland session.

0bda:58ff Realtek Semiconductor Corp. Integrated_Webcam_HD

1. Enable proposed
$ sudo apt install pipewire
$ sudo reboot
2. gst-launch-1.0 command works good
$ gst-launch-1.0 pipewiresrc path=37 ! image/jpeg, width=1280, height=720, framerate=30/1 ! decodebin ! videoconvert ! glimagesink
3. screen cast works good
4. screen sharing via vnc works good

[Kai-Chuan Hsieh (kchsieh)]

Test on Dell Latitude 5530, BIOS 1.4.0. Tested in wayland session.

0c45:6a14 Microdia Integrated_Webcam_HD

1. Enable proposed
$ sudo apt install pipewire
$ sudo reboot
2. gst-launch-1.0 command works good
$ gst-launch-1.0 pipewiresrc path=35 ! image/jpeg, width=1280, height=720, framerate=30/1 ! decodebin ! videoconvert ! glimagesink
3. screen cast works good
4. screen sharing via vnc works good

[Andy Chi (andch)]

Test on HP EliteBook 640 BIOS: 01.03.02

0408:5483 Quanta Computer, Inc. HP HD Camera

1. Enable proposed
$ sudo apt install pipewire
$ sudo reboot
2. gst-launch-1.0 command works good
$ gst-launch-1.0 pipewiresrc path=35 ! image/jpeg, width=1280, height=720, framerate=30/1 ! decodebin ! videoconvert ! glimagesink
3. screen cast works good

[Kai-Chuan Hsieh (kchsieh)]

Test on Dell New platform 202209-30584, BIOS 0.2.10. Tested in Xorg.

0c45:6747 Microdia Integrated_Webcam_HD

1. Enable proposed
$ sudo apt install pipewire
$ sudo reboot
2. gst-launch-1.0 command works good
$ gst-launch-1.0 pipewiresrc path=35 ! image/jpeg, width=1280, height=720, framerate=30/1 ! decodebin ! videoconvert ! glimagesink
3. screen cast works good

[Bin Li (binli)]

Tested 5986:116d Acer, Inc Integrated Camera (ThinkCentre Neo 50a)

1. Enable proposed
$ sudo apt install pipewire # 0.3.48-1ubuntu2
$ sudo reboot
2. gst-launch-1.0 command works good
$ gst-launch-1.0 pipewiresrc path=35 ! image/jpeg, width=1280, height=720, framerate=30/1 ! decodebin ! videoconvert ! glimagesink
3. screen cast works good, find a waring from log.

WARNING: from element /GstPipeline:pipeline0/GstGLImageSinkBin:glimagesinkbin0/GstGLImageSink:sink: A lot of buffers are being dropped.
Additional debug info:
../libs/gst/base/gstbasesink.c(3143): gst_base_sink_is_too_late (): /GstPipeline:pipeline0/GstGLImageSinkBin:glimagesinkbin0/GstGLImageSink:sink:
There may be a timestamping problem, or this computer is too slow.

[Bin Li (binli)]

Tested 174f:2459 Syntek Integrated Camera (ThinkBook 14 Gen 4).

1. Enable proposed
$ sudo apt install pipewire # 0.3.48-1ubuntu2
$ sudo reboot
2. gst-launch-1.0 command works good
$ gst-launch-1.0 pipewiresrc path=35 ! image/jpeg, width=1280, height=720, framerate=30/1 ! decodebin ! videoconvert ! glimagesink
3. screen cast works good, find a waring from log.

WARNING: from element /GstPipeline:pipeline0/GstGLImageSinkBin:glimagesinkbin0/GstGLImageSink:sink: A lot of buffers are being dropped.
Additional debug info:
../libs/gst/base/gstbasesink.c(3143): gst_base_sink_is_too_late (): /GstPipeline:pipeline0/GstGLImageSinkBin:glimagesinkbin0/GstGLImageSink:sink:
There may be a timestamping problem, or this computer is too slow.

[Kai-Chuan Hsieh (kchsieh)]

@binli

Do you see the error before updating the pipewire in proposed? is it cased by the new packcage?

[Bin Li (binli)]

@kc,

 I tried to downgrade pipewire to 0.3.48-1ubuntu1 on 5986:116d camera, then reboot.
 After that gst-launch-1.0 command works good
$ gst-launch-1.0 pipewiresrc path=35 ! image/jpeg, width=1280, height=720, framerate=30/1 ! decodebin ! videoconvert ! glimagesink

screen cast works good, I could find the same warning log. So the new fix didn't affect this camera. Thanks!

[Kai-Chuan Hsieh (kchsieh)]

Mark done since we have verified the bug on DELL/HP/Lenovo machine.

[Brian Murray (brian-murray)]

Thank you for the extensive testing on a wide variety of hardware. One thing called out in the test description is doing the steps under wayland. In the verification comments it is not clear to me if wayland or X were used. Could you elaborate about which display environment was used?

[Andy Chi (andch)]

Reply #27,
It's an intel + nvidia sku, so the window server is X

[Bin Li (binli)]

Reply #29 and #30
They are intel skus, so the window server is wayland.

[Kai-Chuan Hsieh (kchsieh)]

reply #35

Hello,

We've updated the test session is based on wayland or xorg, could you proceed the SRU?

Thanks,

[Jay Chen (jay-ch)]

@Brian,
have you got sufficient information and test result to make the pipewire SRU on Jammy ?

this pipewire SRU is expected for a couple of PC OEM projects pre-installed image releases. So it'd be nice to have a plan visibility.

thanks

[Jay Chen (jay-ch)]

with these extensive testings done on Wayland and Xorg, is it sufficient to move the bug (from incomplete) to fix-committed now ? then I'd like to learn about the timeline to release this package to -updates

[Sebastien Bacher (seb128)]

I think it had the required testing now yes so I'm changing to fix commited. I will try to nag the SRU team member on duty to get it moved to updates today

[Launchpad Janitor (janitor)]

This bug was fixed in the package pipewire - 0.3.48-1ubuntu2

---------------
pipewire (0.3.48-1ubuntu2) jammy; urgency=medium

  * d/p/0001-buffers-ensure-buffer-size-does-not-exceed-maxsize.patch
    d/p/0002-gst-dequeue-a-shared-buffer-instead-of-original-pool.patch
    - Camera output freeze when using pipewiresrc (LP: #1985057)

 -- Kai-Chuan Hsieh <email address hidden> Mon, 15 Aug 2022 13:52:20 +0800

[Brian Murray (brian-murray)]

The verification of the Stable Release Update for pipewire has completed successfully and the package is now being released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

[Bin Li (binli)]

Hi guys,

 Found a regression of pipewire on ThinkCentre Neo 50a, the screencast(Ctrl + Alt + Shift + R) could not record video correctly.

 The version 0.3.48-1ubuntu1 of pipewire works fine. After upgraded to 0.3.48-1ubuntu2, it's very easy to reproduce this issue.

https://bugs.launchpad.net/ubuntu/+source/pipewire/+bug/1995358

[Bin Li (binli)]

And on Neo50a with the new version pipewire, using cheese to record video, it only records part of video, then camera freezes.

https://bugs.launchpad.net/ubuntu/+source/pipewire/+bug/1994928

[Robie Basak (racb)]

@seb128 please could you investigate?

[Kai-Chuan Hsieh (kchsieh)]

reply #44 #45,

@binli

Hello,

Can the issue be reproduced on kinetic?
The SRU patch for the bug is in kinetic too.

Thanks,

[Sebastien Bacher (seb128)]

@Robie, yes, I'm subscribed to the bug and it's on my list of things to investigate now

[Bin Li (binli)]

@kchsieh,

 No, I didn't test kinetic, Lenovo reported that the 20.04.1 stock ubuntu screencast recording works fine, but after upgrading latest updates, they found the issue in #44.

 For #45, I also tried the 0.3.48-1ubuntu1 pipewire, found the camera will be freeze when recording, the new version 0.3.48-1ubuntu2 makes it better, but the cheese issue could be reproduced sometimes.

[Kai-Chuan Hsieh (kchsieh)]

Reply #49

Hello,

I'd like to confirm if the latest pipewire contains fix for it, maybe we should apply more patch as mentioned in #13.

Can you try pure gstreamer command to see if you can record video successfully. You can replace glimagesink to avimux ! filesink location=out.avi. if it is ok, maybe it is not pipewire issue, but cheese not using gstreamer correctly.

Thanks,

[Sebastien Bacher (seb128)]

So that's a regression of one of the cherrypicked commits, details are in https://gitlab.gnome.org/GNOME/gnome-shell/-/commit/d32c03488

the issue is fixed in Kinetic through a combination of the shell fix and a new pipewire.

In 22.04 the shell issue is fixed in the recent 42.5 update but we will need to cherrypick https://gitlab.freedesktop.org/pipewire/pipewire/-/commit/1ea1d525 in pipewire to be working.

[Sebastien Bacher (seb128)]

@oem, reading the upstream shell description it suggests that screen recording is simply broken by the change, do you have any idea why that didn't show up in your SRU verification? testing the shell recording feature was part of the test description and Bin wrote that it was still working for him, is that actually the case?

[Sebastien Bacher (seb128)]

cheese has issues but it feels like video recording might have more problems with the SRU installed

[Kai-Chuan Hsieh (kchsieh)]

I uses the gst-launch-1.0 command to record the video, and the result looks good. I did it for decouple issue of cheese, since cheese has many issues in jammy. Also, I tried the latest upstream pipewire, the result is the same as the SRU. Therefore, I think I should patch the pipewire to fix the preview issue first.

[Sebastien Bacher (seb128)]

@Kai-Chuan, was that a reply to my question about the SRU verification?

The testcase specifically list

'6. Check that video recording in gnome-shell works
   - use Ctrl+Shift+Alt+R to start a recording, stop it from the indicator, verify that there is a new entry in ~/Video'

which isn't gst-launch-1.0

[Kai-Chuan Hsieh (kchsieh)]

The screencast test are all passed. The test is recorded in the comment. Do you mean it should be failed on all machine?

The only issue I saw is that build-in Video app can't playback it correctly, I have to use vlc to playback the WebM file.

I used gst-launch-1.0 to test camera recording but not screencast.

[Bin Li (binli)]

For the patch in #51, it depends on below patch.

From a1f33a99df5756c3dedd68f5ba2690819098d14f Mon Sep 17 00:00:00 2001
From: James Hilliard <email address hidden>
Date: Wed, 1 Jun 2022 04:03:37 -0600
Subject: [PATCH] gst: dequeue a shared buffer instead of original pool buffer

This seems to prevent the pool buffer from getting corrupted.

Signed-off-by: James Hilliard <email address hidden>
---
 src/gst/gstpipewirepool.c | 7 ++-----
 src/gst/gstpipewirepool.h | 1 -
 src/gst/gstpipewiresink.c | 2 +-
 src/gst/gstpipewiresrc.c | 24 +++++++++++++-----------
 4 files changed, 16 insertions(+), 18 deletions(-)

[Bin Li (binli)]

The patch in #57 is already in jammy, I could apply the patch from #51 successfully.

pipewire (0.3.48-1ubuntu2) jammy; urgency=medium

  * d/p/0001-buffers-ensure-buffer-size-does-not-exceed-maxsize.patch
    d/p/0002-gst-dequeue-a-shared-buffer-instead-of-original-pool.patch
    - Camera output freeze when using pipewiresrc (LP: #1985057)

Built new packages, the screencast becomes stable, the fail rate is lower than before, although it would skip frames for seconds. I will let our customer do more test.

https://people.canonical.com/~binli/pipewire/

[Bin Li (binli)]

BTW, on 22.10, our customer could not reproduce the screencast issue.

[Sebastien Bacher (seb128)]

22.10 has a newer pipewire including the different patches mentioned here and the gnome-shell workaround so it's expected that the issue isn't present there

[Sebastien Bacher (seb128)]

I've uploaded an update reverting the change for now. We need to figure out how to properly fix the regression and update the testplan to avoid another regression which will take some time (especially as some of the people involved are going to travel back from the Ubuntu summit which will probably create extra delays). Meanwhile we want to resolve the regression

[Robie Basak (racb)]

Thanks. I accepted the upload but changed the bug reference to point to bug 1996148 instead, since landing the revert shouldn't close this bug. I'll reopen this bug since the revert reverts it.

[Bin Li (binli)]

The below two patches in Description could cause the screencast regression, so they were reverted, if we want add them again we need two gstreamer's patches in comment #51.

  * d/p/0001-buffers-ensure-buffer-size-does-not-exceed-maxsize.patch
    d/p/0002-gst-dequeue-a-shared-buffer-instead-of-original-pool.patch
    - Camera output freeze when using pipewiresrc (LP: #1985057)

I also added another pipewire patch, d/p/0003-gst-copy-buffer-memory-in-dequeue_buffer-using-gst_m.patch from comment #51 .

[Sebastien Bacher (seb128)]

Could you provide details on how we ensure the components updates would land in order? What would be the consequence of having the pipewire update landing before gstreamer or the other way around?

Do we have confidence it would not impact other components?

It sounds a risky changeset to fix cheese which is a known to be buggy component anyway, could we consider an alternative option to deprecate or replace cheese perhaps?

[Ubuntu Foundations Team Bug Bot (crichton)]

The attachment "pipewire_0.3.48-1ubuntu2.debdiff" seems to be a debdiff. The ubuntu-sponsors team has been subscribed to the bug report so that they can review and hopefully sponsor the debdiff. If the attachment isn't a patch, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are member of the ~ubuntu-sponsors, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issue please contact him.]

[Jeremy Bícha (jbicha)]

I am setting the bug status to Incomplete.

[Kai-Chuan Hsieh (kchsieh)]

@seb128

Do we have other alternative camera app for ubuntu desktop if we'd like to deprecate cheese?

Thanks,

[jeremyszu (os369510)]

Hi seb128,

> Could you provide details on how we ensure the components updates would land in order? What would be the consequence of having the pipewire update landing before gstreamer or the other way around?

FWIK, they need to be published in the same time. (landed in -updates from -proposed)

> Do we have confidence it would not impact other components?

do you have a list of components (e.g. screencast) you are concerning? I believe we could add them in the test plan to move this forward.

It seems not related to cheese but all apps using pipewiresrc plugin will be impacted.