Camera output freeze when using pipewiresrc

Bug #1985057 reported by Andy Chi
22
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OEM Priority Project
New
High
Kai-Chuan Hsieh
gst-plugins-base1.0 (Ubuntu)
New
Undecided
Unassigned
Jammy
Incomplete
Undecided
Unassigned
gstreamer1.0 (Ubuntu)
New
Undecided
Unassigned
Jammy
Incomplete
Undecided
Unassigned
pipewire (Ubuntu)
Fix Released
High
Unassigned
Jammy
Incomplete
High
Unassigned

Bug Description

[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

Revision history for this message
Andy Chi (andch) wrote : Dependencies.txt

apport information

tags: added: apport-collected jammy
description: updated
Revision history for this message
Andy Chi (andch) wrote : ProcCpuinfoMinimal.txt

apport information

Revision history for this message
Andy Chi (andch) wrote : ProcEnviron.txt

apport information

description: updated
Revision history for this message
Andy Chi (andch) wrote : Dependencies.txt

apport information

Revision history for this message
Andy Chi (andch) wrote : ProcCpuinfoMinimal.txt

apport information

Revision history for this message
Andy Chi (andch) wrote : ProcEnviron.txt

apport information

summary: - Camera outpur freeze when using pipewiresrc
+ Camera output freeze when using pipewiresrc
Revision history for this message
Kai-Chuan Hsieh (kchsieh) wrote :

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

Andy Chi (andch)
tags: added: oem-priority originate-from-1983443 somerville
Revision history for this message
Kai-Chuan Hsieh (kchsieh) wrote :
Changed in oem-priority:
assignee: nobody → Kai-Chuan Hsieh (kchsieh)
Changed in oem-priority:
status: New → Confirmed
description: updated
Revision history for this message
Andy Chi (andch) wrote :

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.

Revision history for this message
Kai-Chuan Hsieh (kchsieh) wrote :

Upload debdiff.

description: updated
description: updated
description: updated
Revision history for this message
Sebastien Bacher (seb128) wrote :

Kinetic has 0.3.56 and it's fixed in that serie

Changed in pipewire (Ubuntu):
importance: Undecided → High
status: New → Fix Released
Revision history for this message
Sebastien Bacher (seb128) wrote :

and I've sponsored the SRU now

description: updated
Changed in pipewire (Ubuntu Jammy):
status: New → In Progress
Revision history for this message
Robie Basak (racb) wrote :

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!

Changed in pipewire (Ubuntu Jammy):
status: In Progress → Incomplete
Revision history for this message
Robie Basak (racb) wrote :

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

description: updated
description: updated
description: updated
Andy Chi (andch)
description: updated
Andy Chi (andch)
description: updated
Bin Li (binli)
description: updated
description: updated
Revision history for this message
Kai-Chuan Hsieh (kchsieh) wrote (last edit ):

@racb

Hello,

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

Thanks,

description: updated
Revision history for this message
Sebastien Bacher (seb128) wrote :

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

description: updated
description: updated
description: updated
description: updated
Revision history for this message
Kai-Chuan Hsieh (kchsieh) wrote :

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

Revision history for this message
Kai-Chuan Hsieh (kchsieh) wrote :

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

description: updated
description: updated
description: updated
Revision history for this message
Kai-Chuan Hsieh (kchsieh) wrote :

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

Revision history for this message
Andy Chi (andch) wrote :

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

description: updated
Revision history for this message
Kai-Chuan Hsieh (kchsieh) wrote :

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

Revision history for this message
Sebastien Bacher (seb128) wrote :

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

Revision history for this message
Kai-Chuan Hsieh (kchsieh) wrote (last edit ):

@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.

description: updated
Revision history for this message
Robie Basak (racb) wrote : Please test proposed package

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.

Changed in pipewire (Ubuntu Jammy):
status: Incomplete → Fix Committed
tags: added: verification-needed verification-needed-jammy
description: updated
Revision history for this message
Kai-Chuan Hsieh (kchsieh) wrote (last edit ):

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

Revision history for this message
Kai-Chuan Hsieh (kchsieh) wrote (last edit ):

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

Revision history for this message
Andy Chi (andch) wrote :

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

Revision history for this message
Kai-Chuan Hsieh (kchsieh) wrote (last edit ):

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

Revision history for this message
Bin Li (binli) wrote :

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.

Revision history for this message
Bin Li (binli) wrote :

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.

Revision history for this message
Kai-Chuan Hsieh (kchsieh) wrote :

@binli

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

Revision history for this message
Bin Li (binli) wrote :

@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!

Revision history for this message
Kai-Chuan Hsieh (kchsieh) wrote :

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

tags: added: verification-done verification-done-jammy
removed: verification-needed verification-needed-jammy
Revision history for this message
Brian Murray (brian-murray) wrote :

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?

Changed in pipewire (Ubuntu Jammy):
status: Fix Committed → Incomplete
Revision history for this message
Andy Chi (andch) wrote :

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

Revision history for this message
Bin Li (binli) wrote (last edit ):

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

Revision history for this message
Kai-Chuan Hsieh (kchsieh) wrote :

reply #35

Hello,

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

Thanks,

Revision history for this message
Jay Chen (jay-ch) wrote :

@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

Revision history for this message
Jay Chen (jay-ch) wrote :

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

Revision history for this message
Sebastien Bacher (seb128) wrote :

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

Changed in pipewire (Ubuntu Jammy):
status: Incomplete → Fix Committed
importance: Undecided → High
Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in pipewire (Ubuntu Jammy):
status: Fix Committed → Fix Released
Revision history for this message
Brian Murray (brian-murray) wrote : Update Released

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.

Changed in oem-priority:
status: Confirmed → Fix Released
importance: Undecided → High
Revision history for this message
Bin Li (binli) wrote (last edit ):

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

Revision history for this message
Bin Li (binli) wrote :

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

Revision history for this message
Robie Basak (racb) wrote :

@seb128 please could you investigate?

Revision history for this message
Kai-Chuan Hsieh (kchsieh) wrote :

reply #44 #45,

@binli

Hello,

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

Thanks,

Revision history for this message
Sebastien Bacher (seb128) wrote :

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

Revision history for this message
Bin Li (binli) wrote :

@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.

Revision history for this message
Kai-Chuan Hsieh (kchsieh) wrote :

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,

Revision history for this message
Sebastien Bacher (seb128) wrote :

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.

Revision history for this message
Sebastien Bacher (seb128) wrote :

@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?

Revision history for this message
Sebastien Bacher (seb128) wrote :

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

Revision history for this message
Kai-Chuan Hsieh (kchsieh) wrote (last edit ):

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.

Revision history for this message
Sebastien Bacher (seb128) wrote :

@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

Revision history for this message
Kai-Chuan Hsieh (kchsieh) wrote (last edit ):

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.

Revision history for this message
Bin Li (binli) wrote :

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(-)

Revision history for this message
Bin Li (binli) wrote :

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/

Revision history for this message
Bin Li (binli) wrote (last edit ):

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

Revision history for this message
Sebastien Bacher (seb128) wrote :

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

Revision history for this message
Sebastien Bacher (seb128) wrote :

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

Revision history for this message
Robie Basak (racb) wrote :

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.

Changed in pipewire (Ubuntu Jammy):
status: Fix Released → Triaged
Rex Tsai (chihchun)
Changed in oem-priority:
status: Fix Released → New
Revision history for this message
Bin Li (binli) wrote :
Revision history for this message
Bin Li (binli) wrote :
Revision history for this message
Bin Li (binli) wrote :
Revision history for this message
Bin Li (binli) wrote (last edit ):

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 .

Revision history for this message
Sebastien Bacher (seb128) wrote :

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?

Revision history for this message
Ubuntu Foundations Team Bug Bot (crichton) wrote :

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.]

tags: added: patch
Revision history for this message
Jeremy Bícha (jbicha) wrote :

I am setting the bug status to Incomplete.

Changed in pipewire (Ubuntu Jammy):
status: Triaged → Incomplete
Changed in gstreamer1.0 (Ubuntu Jammy):
status: New → Incomplete
Changed in gst-plugins-base1.0 (Ubuntu Jammy):
status: New → Incomplete
Revision history for this message
Kai-Chuan Hsieh (kchsieh) wrote :

@seb128

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

Thanks,

Revision history for this message
jeremyszu (os369510) wrote :

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.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.