-
Notifications
You must be signed in to change notification settings - Fork 539
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Failed to stream H264 to virtual camera: "does not support 2:4:7:1 colorimetry" #557
Comments
could you try with current i cannot fully reproduce the problem (having no hardware that natively speaks h264), however: the following pipeline appears to work for me with v0.12.7 and current main: gst-launch-1.0 -v videotestsrc \
! x264enc \
! h264parse \
! "video/x-h264,width=640,height=480,pixel-aspect-ratio=1/1,framerate=30/1,interlace-mode=progressive,colorimetry=2:4:7:1" \
! v4l2sink device=/dev/video2 however, the following pipeline fails from me with v0.12.7 (note the "colorimetry=bt601") gst-launch-1.0 -v videotestsrc \
! x264enc \
! h264parse \
! "video/x-h264,width=640,height=480,pixel-aspect-ratio=1/1,framerate=30/1,interlace-mode=progressive,colorimetry=bt601" \
! v4l2sink device=/dev/video2 however, the above pipeline appears to work with |
Hi @umlaeute, Thank you for your response. I tried with v4l2loopback v0.12.7 (9ba7e29) with following pipeline (
I get the following error.
For the following pipeline:
I get the following error:
For the following pipeline:
I get the following error:
Is it possible that the outcome can be changed based on the Linux distribution or the kernel version? Because i want to run this on Jetson Orin with Ubuntu 20.04 installed. It also get the same errors as my laptop.
|
rather than the Linux kernel version i would imagine that the GStreamer version matters. I'm using gstreamer_1.22.6-1 (on my Debian/sid machine). Newer Linux distributions will have newer versions of the packaged software, which in turn will have bugs fixed (and new bugs) |
Apologies for reviving a year-old thread, but I'm having this exact same issue. I'm receiving video from a remote IP source, decoding it and then trying to present it as a webcam device within a web app. However, whenever I try to link the video decoder and the I've done some digging and discovered that the 2:4:7:1 string comes from the Reading the v4l2 docs, it seems to imply that sRGB should be limited range by default - so am I misunderstanding something or is GStreamer wrong to assert that sRGB can only ever be full range? I'm using Ubuntu 24.04, kernel 6.8.12, v4l2loopback version 0.12.7 (from Ubuntu repositories) and GStreamer 1.25.0 from git (as of a couple of days ago). |
This works on main for me:
Although I don't know enough about this to confirm that the output is correct (messaed around with ffplay for a bit, but ran out of time). |
Seems commit 6e3d0a7 introduced this issue. |
@stephematician Are you sure you are loading the custom-built kernel module? |
@sanbrother - yes, I am using the main branch of v4l2loopback. Can you provide an example of a command that produces the error? |
|
the example above runs on v0.13.0 with this patch diff --git a/v4l2loopback.c b/v4l2loopback.c
index 61663d5..fe1f243 100644
--- a/v4l2loopback.c
+++ b/v4l2loopback.c
@@ -1562,9 +1562,11 @@ static int vidioc_reqbufs(struct file *file, void *fh,
return 0;
}
+#if 0
if (V4L2_TYPE_IS_OUTPUT(b->type) && (!dev->ready_for_output)) {
return -EBUSY;
}
+#endif
init_buffers(dev);
switch (b->memory) { |
That's related to ioctl REQBUFS - so this probably isn't an issue with colour space support; it's probably related to how v4l2loopback handles devices that are opened multiple times. I've been looking at this recently but I don't have a PR ready just yet (am on holidays) - as I encountered a slightly different problem at the same line of code. |
Recently, I've been trying the combination of gstreamer and v4l2loopback, and I want to make an attempt at sharing the camera data stream. It's not very urgent. Have a nice holiday! |
@sanbrother - I tried your example in comment #557 (comment). It SIGSEGV'd, usually shortly or directly after the output "Got stream-start message". I used The main thread was at line 141: g_usleep(G_USEC_PER_SEC); Thread It did run once with output: user@home:~/doc/temp$ ./gst-test
** Message: 10:29:04.785: switching
COCOA : active_name = sink_0
** Message: 10:29:04.785: current number of sources : 2, active source sink_0
** Message: 10:29:08.789: switching
COCOA : active_name = sink_1
... And then I tried another terminal: user@home:~$ vlc v4l2:///dev/video52
VLC media player 3.0.20 Vetinari (revision 3.0.20-0-g6f0d0ab126b)
[00007cd1bc001170] v4l2 demux error: cannot map buffer 0: Invalid argument
[00007cd1bc001170] v4l2 demux error: not a radio tuner device
[00007cd1bc003af0] v4l2 stream error: cannot map buffer 0: Invalid argument Can you find a simpler, more stable example? |
Yeah, got it. I will keep trying to see if I can find out a more stable example. |
I'm still reworking some of the S_FMT and REQBUFS mechanics - but I believe this should be resolved in my experimental efforts here d935c8e and more generally PR #611. This code is still experimental, I recommend you try first with a virtual machine (e.g. KVM). |
@sanbrother - after thinking about this longer; I'm going back on the changes related to 'unlocking' colorspace that I made in PR #611. I believe that it makes more sense for v4l2loopback to fail in your example. The gstreamer pipeline in your example switches between sources with different colorspaces (one for The solution would be to get gstreamer to convert the two sources into a common colorspace before sinking to the loopback device(s). Of course, some changes are still needed to v4l2loopback - I am close to having a (non-draft) PR. Should push in the next day or two. |
@samhurst Can you provide an example of the pipeline you're using and the output you get? |
My environment
v4l2loopback
version: 0.12.5GStreamer version: 1.16.3
kernel version (
uname -a
):5.15.0-84-generic # 93~20.04.1-Ubuntu SMP Wed Sep 6 16:15:40 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
Distribution (+version) (
lsb_release -a
):Distributor ID: Ubuntu
Description: Ubuntu 20.04.6 LTS
Release: 20.04
Codename: focal
Problem Description:
I am trying to stream my USB cam video in H264 format to virtual camera using GStreamer. But i am getting error:
does not support 2:4:7:1 colorimetry
.My USB cam (Arducam USB Camera: Arducam USB) support H264 video format.
Trying to stream H264 video from USB camera (
/dev/video2
) to virtual camera (/dev/video10
):gst-launch-1.0 -v v4l2src device=/dev/video2 ! video/x-h264,width=640,height=480,framerate=30/1 ! v4l2sink device=/dev/video10
Gets Following error:
Trying to get raw video from USB camera (
/dev/video0
) and convert to H264 and stream to virtual camera (/dev/video10
):gst-launch-1.0 -v v4l2src device=/dev/video0 ! videoscale ! videoconvert ! x264enc ! h264parse ! video/x-h264,stream-format=avc,alignment=au,width=640,height=480,framerate=30/1 ! v4l2sink device=/dev/video10
Gets Following error:
Successful when trying to stream raw video from
/dev/video0
to virtual camera/dev/video10
gst-launch-1.0 -v v4l2src device=/dev/video0 ! video/x-raw,format=YUY2,width=640,height=480,framerate=30/1 ! videoconvert ! v4l2sink device=/dev/video10
Result of
gst-device-monitor-1.0
:I also tried with
v4l2loopback
versions0.12.6, 0.12.7
and gstreamer version1.18.6
. But same errors.I would appreciate a prompt response.
Thank you.
The text was updated successfully, but these errors were encountered: