sometimes takes ~5 seconds to _dma_fmt_to_dma_drm_fmts: assertion 'fmt != GST_VIDEO_FORMAT_UNKNOWN' failed

Bug #2071644 reported by Joe Barnett
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
gst-plugins-good1.0 (Ubuntu)
New
Undecided
Unassigned
linux (Ubuntu)
New
Undecided
Unassigned

Bug Description

since upgrading to noble, sometimes the following bit of code works instantaneously, and sometimes it takes ~5 seconds to report:

** (gst-plugin-scanner:692358): CRITICAL **: 10:55:31.508: _dma_fmt_to_dma_drm_fmts: assertion 'fmt != GST_VIDEO_FORMAT_UNKNOWN' failed

code:
>>> import cv2
>>> vc = cv2.VideoCapture('/dev/video2')

when it takes a long time and reports the assertion error, I see the following in journalctl logs (so maybe an amd/kernel bug instead of an opencv bug? -- also fwiw am on a hybrid amd/intel system where DRI_PRIME=1 generally activates the amd card but this should be running w/out DRI_PRIME set):

Jul 01 10:55:29 taplop kernel: [drm] scheduler comp_1.2.1 is not ready, skipping
Jul 01 10:55:29 taplop kernel: [drm] PCIE GART of 256M enabled (table at 0x000000F400000000).
Jul 01 10:55:30 taplop kernel: amdgpu 0000:01:00.0: [drm:amdgpu_ring_test_helper [amdgpu]] *ERROR* ring comp_1.1.0 test failed (-110)
Jul 01 10:55:30 taplop kernel: amdgpu 0000:01:00.0: [drm:amdgpu_ring_test_helper [amdgpu]] *ERROR* ring comp_1.2.0 test failed (-110)
Jul 01 10:55:30 taplop kernel: amdgpu 0000:01:00.0: [drm:amdgpu_ring_test_helper [amdgpu]] *ERROR* ring comp_1.3.0 test failed (-110)
Jul 01 10:55:30 taplop kernel: amdgpu 0000:01:00.0: [drm:amdgpu_ring_test_helper [amdgpu]] *ERROR* ring comp_1.0.1 test failed (-110)
Jul 01 10:55:30 taplop kernel: amdgpu 0000:01:00.0: [drm:amdgpu_ring_test_helper [amdgpu]] *ERROR* ring comp_1.1.1 test failed (-110)
Jul 01 10:55:31 taplop kernel: amdgpu 0000:01:00.0: [drm:amdgpu_ring_test_helper [amdgpu]] *ERROR* ring comp_1.2.1 test failed (-110)
Jul 01 10:55:31 taplop kernel: [drm] UVD and UVD ENC initialized successfully.
Jul 01 10:55:31 taplop kernel: [drm] VCE initialized successfully.
Jul 01 10:55:31 taplop kernel: [drm] scheduler comp_1.1.0 is not ready, skipping
Jul 01 10:55:31 taplop kernel: [drm] scheduler comp_1.2.0 is not ready, skipping
Jul 01 10:55:31 taplop kernel: [drm] scheduler comp_1.3.0 is not ready, skipping
Jul 01 10:55:31 taplop kernel: [drm] scheduler comp_1.0.1 is not ready, skipping
<<< not ready skipping lines repeat a whole bunch of times >>>

ProblemType: Bug
DistroRelease: Ubuntu 24.04
Package: python3-opencv 4.6.0+dfsg-13.1ubuntu1
ProcVersionSignature: Ubuntu 6.8.0-35.35-generic 6.8.4
Uname: Linux 6.8.0-35-generic x86_64
ApportVersion: 2.28.1-0ubuntu3
Architecture: amd64
CasperMD5CheckResult: unknown
CurrentDesktop: GNOME
Date: Mon Jul 1 10:59:12 2024
InstallationDate: Installed on 2019-08-17 (1781 days ago)
InstallationMedia: Ubuntu 19.04 "Disco Dingo" - Alpha amd64 (20190305.1)
RebootRequiredPkgs: Error: path contained symlinks.
SourcePackage: opencv
UpgradeStatus: Upgraded to noble on 2024-03-23 (100 days ago)

Revision history for this message
Joe Barnett (thejoe) wrote :
Revision history for this message
Joe Barnett (thejoe) wrote :

can reproduce this without opencv using:

gst-launch-1.0 v4l2src device="/dev/video2" ! videoconvert ! ximagesink

no longer affects: opencv (Ubuntu)
Revision history for this message
Joe Barnett (thejoe) wrote :

it does appear that `mplayer tv:// -tv driver=v4l2:device=/dev/video2` doesn't have this problem, while the gst-launch command above does, so adding gst plugins package that includes the v4l2 src

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.