Cheese can't playback the preview on Intel IPU6 camera platform

apport information

apport information

apport information

apport information

apport information

apport information

apport information

I try to disable gstreamer1.0-pipewire device provider cap, then the Cheese can work correctly.

The package with device provider cap disabled can be installed by:

1. $ sudo add-apt-repository ppa:kchsieh/verification
2. $ sudo apt install gstreamer1.0-pipewire libpipewire-0.3-0 libpipewire-0.3-common libpipewire-0.3-modules libspa-0.2-modules pipewire-bin pipewire
3. $ sudo reboot

shouldn't pipewire use libcamera that should be able to handle the camera?

libcamera is a long term solution that Intel is still working on.
Currently it still needs to use a mid term solution that is to use libcamhal in https://launchpad.net/~oem-solutions-group/+archive/ubuntu/intel-ipu6 with v4l2-relayd in jammy/universe to bind the MIPI camera to a v4l2video device made by v4l2loopback kernel module.
We are still working on making the MIPI camera userspace stack to jammy/restricted.

@seb128

Hello,

Do you think to make gstreamer1.0-pipewire not register device provider by not set HAS_GSTREAMER_DEVICE_PROVIDER can be a temporary fix to maximize the compatibility?

Thanks,

I'm unsure to understand the details of that proposal enough to have an opinion. How is HAS_GSTREAMER_DEVICE_PROVIDER set? Wouldn't it be easier for you to just not install gstreamer1.0-pipewire on those oem images?

I create a build with the patch to make HAS_GSTREAMER_DEVICE_PROVIDER not set. I've tried to $ sudo apt purge gstremaer1.0-pipewire, then my platform can't boot into Desktop.

Therefore, I think wayland session has some package rely on gstreamer1.0-pipewire.

The attachment "Don-t-register-device-provider.patch" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.

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

It seems to me there is a problem in the pipewiresrc that it closes/reopens the device every 3 seconds, while the gstreamer v4l2src works just fine.

1. add `debug=3` to /etc/modprobe.d/v4l2-relayd.conf, reboot to take effect

2. list supported media device:

  $ gst-device-monitor-1.0 Video/Source
  Probing devices...
  Device found:

  name : Intel MIPI Camera
  ...
  properties:
          object.path = v4l2:/dev/video0
          ...
  gst-launch-1.0 pipewiresrc path=34 ! ...

2. for pipewiresrc, run:

  $ GST_DEBUG=2,pipewiresrc:5 gst-launch-1.0 pipewiresrc path=34 ! videoconvert ! xvimagesink

   for v4l2src, run:

  $ GST_DEBUG=2,v4l2src:5 gst-launch-1.0 v4l2src device=/dev/video0 ! videoconvert ! xvimagesink

3. The v4l2src behaves well while pipewiresrc gives a blank screen.

> It seems to me there is a problem in the pipewiresrc that it closes/reopens the device every 3 seconds,

could you report that upstream?

I try to compare the working and non-working system. The log's different when allocate buffer.

Good:
pipewire[1889]: pw.link: 0x5595fb3a6de0: allocating 16 buffers 0x5595fb3b4590
pipewire[1889]: pw.port: 0x5595fb361960: 1:0.0: 16 buffers flags:1 state:2 n_mix:1
pipewire[1889]: pw.port: 0x5595fb361960: 1.0 use 16 buffers on node: 0x5595fb35f2d0
pipewire[1889]: spa.v4l2: got 16 buffers

Bad:
pipewire[1118]: pw.link: 0x5620ee222d50: allocating 16 buffers 0x5620ee222600
pipewire[1118]: pw.port: 0x5620ee23d570: 1:0.0: 16 buffers flags:1 state:2 n_mix:1
pipewire[1118]: pw.port: 0x5620ee23d570: 1.0 use 16 buffers on node: 0x5620ee243c50
pipewire[1118]: spa.v4l2: got 2 buffers
pipewire[1118]: spa.v4l2: buffer 0 was already queued
pipewire[1118]: spa.v4l2: have 0 buffers using MMAP

From the source it utilize the ioctl to query the driver:
https://gitlab.freedesktop.org/pipewire/pipewire/-/blob/master/spa/plugins/v4l2/v4l2-utils.c#L1439

More, the driver report the buffer flag V4L2_BUF_FLAG_QUEUED on IPU6 platform.
Might need to check driver what makes it different. It keeps reporting no buffers for doing streaming on IPU6 platform.

The log of #17.

It appears to me now there is a bug in the v4l2loopback that its timer calculation may corrupt under a certain scenario that `v4l2-compliance` gives:

  $ v4l2-compliance -d /dev/video1
  ...
  Buffer ioctls (Output 0):
                  fail: v4l2-test-buffers.cpp(369): timestamp != V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC && timestamp != V4L2_BUF_FLAG_TIMESTAMP_COPY
                  fail: v4l2-test-buffers.cpp(486): buf.check(Unqueued, i)
                  fail: v4l2-test-buffers.cpp(615): testQueryBuf(node, i, q.g_buffers())
          test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: FAIL
          test VIDIOC_EXPBUF: OK (Not Supported)
                  fail: v4l2-test-buffers.cpp(1803): media_fd < 0
          test Requests: FAIL

Then a simple v4l2sink test will fail with log:

  $ GST_DEBUG=v4l2sink:7 gst-launch-1.0 -v videotestsrc ! v4l2sink device=/dev/video1
  ...
  0:00:00.025135153 2684382 0x55949d5f01e0 DEBUG v4l2sink
  gstv4l2sink.c:592:gst_v4l2sink_show_frame:<v4l2sink0> render buffer: 0x55949d6067e0
  Pipeline is PREROLLED ...
  Setting pipeline to PLAYING ...
  0:00:00.025482054 2684382 0x55949d5f8240 DEBUG v4l2sink
  gstv4l2sink.c:444:gst_v4l2sink_change_state:<v4l2sink0> 3 -> 4
  Redistribute latency...
  New clock: GstSystemClock
  0:00:00.025629911 2684382 0x55949d5f01e0 DEBUG v4l2sink
  gstv4l2sink.c:592:gst_v4l2sink_show_frame:<v4l2sink0> render buffer: 0x55949d6067e0
  Caught SIGSEGV
  Spinning. Please run 'gdb gst-launch-1.0 2684382' to continue debugging, Ctrl-C to quit, or
  Ctrl-\ to dump core.
  ^C

This can be easily reproduced with multiple `v4l2-compliance -d /dev/video1` executions until that timestamp test failure appears, then the following gst-launch-1.0 attempts will all fail.

Status changed to 'Confirmed' because the bug affects multiple users.

Hello @fourdollars @andch,

Any news on this topic? We just replaced our laptops at work and we now have a batch of some Dell XPS 13 experiencing this bug under 22.04LTS.

Webcams are working properly in Chromium, not in Firefox and Cheese. Is there any workaround or fix available that could be deployed without messing another thing on the machines?

Here is the issue that address the Firefox issue [1].
Here is the workaround for cheese [2] that makes mipi camera work.

[1] https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2532#note_1892434
[2] https://wiki.ubuntu.com/Dell, known issue > LP:#1978757 Cheese can't playback preview not working on 22.04

For firefox, I got it running with linux/jammy version 5.15.0-77, as well as all other available jammy kernels in ubuntu archive: oem-5.17, hwe-5.19, oem-6.0, oem-6.1, hwe-6.2. All probed virtual camera and streaming well on https://webcamtests.com/.

The fix for firefox pointed out in comment #24 was planned as bug 2025204, but as my comment #25, I can no longer reproduce it with current released kernels.

Cheese is still broken.

I tested 6.0-oem 6.0.0-1017-oem with the latest firefox snap 115.0-2 on jammy. The camera works in webcamtests.com.