Requested output format 'v4l2' is not a suitable output format #92
Comments
|
You might check the output of |
Thanks for the response |
|
Here I see |
|
Something like that working (Off course blank screen due to x11grab) This means Muxer exists right ? |
|
You probably need ffmpeg built with |
|
Hi, Recompiled it with Still same :'( |
|
Did you install the libv4l development package before configuring ffmpeg and check the configure output for enabled v4l2 components? |
|
You might try adding |
|
but there must be some dependency problem because this is the ffmpeg configuration I use, and v4l2 loopback works: https://pastebin.com/raw/MfGday27 |
Yes,
I tried but this config doesn't exists. There is my configuration output. It also shows indev May be the |
|
I'm using the git master version from https://github.com/FFmpeg/FFmpeg |
|
I compiled many different possibilities (diff branches, config) . None worked. :'( I will try in a fresh installation Debian sid on kvm. I don't know any other way to figure out this issue. |
|
Well sorry I couldn't help, I don't know what the exact problem is but apparently it's with ffmpeg configuration most likely. There is an off chance that there's something wrong with the kernel module you have, if you want to try building that it's here. To test it without installing, run |
|
Btw, I tried |
|
What happens if you try /dev/video2 (which should be created by loading the kernel module)? |
|
I see you're using /dev/video4 here but in the original command you used /dev/video2 |
|
|
@EvanCarroll This could indicate the module is not compatible with your kernel. Check |
|
I'm having the same problem as @pshanoop with Debian testing. Did you get this working? |
|
Not on debian,
I tried in a VM on arch things worked perfectly, I recompiled ffmpeg with
many different build flags and Video4Linux2 but this also didn't help.
I don't know how to solve this problem.
…On Thu, Jun 11, 2020 at 2:47 AM Evan Carroll ***@***.***> wrote:
I'm having the same problem as @pshanoop <https://github.com/pshanoop>
with Debian testing. Did you get this working?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#92 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAI6V4ISKWXGY6K6666I3DDRWASSBANCNFSM4MWW5GIA>
.
--
Looking forward to hear from you
Sanoob Pattanath
|
|
i'll spend some time and try to gather more information here. |
wfleming
added a commit
to wfleming/dotfiles
that referenced
this issue
Jun 15, 2020
I've spent some time this week setting up a new laptop, and as usual for some reason I consider a new machine a great time to re-evaluate my entire setup. One of the things I wanted to re-evaluate was my window manager, and I wondered: "is Wayland good enough to use now?" The answer turned out to be that it is so, so, close, and if it weren't for one deal-breaker annoyance I would be all-in. I started by looking at the current available tiling compositors for Wayland. [Waymonad] is (unsurprisingly) the philisophical descendant of Xmonad for Wayland, but from some light inspection it looks much less mature to me than some of the alternatives, it hasn't attracted the same kind of community that Xmonad has AFAICT, and although I'm happy to spend some time learning a new tool, right now I have minimal interest in figuring out a new window manager without docs or a community from reading source code. So the obvious choice seems to be [sway], which is mostly an [i3] clone for Wayland, and as i3 is a reasonably close cousin to Xmonad in X11 (I think it's the usual choice for people who want a tiling window manager but don't want to write Haskell), so I decided to give it a shot. So I took a stab at setting up sway, and it's really great! My only real complaint is that I somewhat prefer Xmonad's approach to managing windows with designated layouts to i3/sway's approach to managing windows by splitting and moving containers. Xmonad's approach is simpler, while i3's is both more complex but also more flexible. (To be fair, Xmonad is more of a window manager framework than just a window manager, so I'm sure there are people with much more flexible Xmonad setups: mine is not much different from the out-of-the-box experience, so that's what I'm talking about.) But I'm getting used to the new approach, and it's growing on me. On the plus side, the overall experience of "managing" a sway environment is *much* nicer than needing to massage an X11 environment into working order. Display management is built-in and just works, there's no need for extra tools like my [`msu` script][msu], or the several ways I trigger it. There's less mucking about with `xorg.conf.d` configs to get inputs like trackpads behving sanely (so far). Getting a decent status bar to play nicely with the window manager was also much less futzing around. Applications pretty much all just work. It feels responsive and just generally less flakey than X11. Ah, but the deal-breaker. One area where Wayland is well behind X11 is the development of protocols that applications can use for screen-sharing. They exist, but AFAICT they're unevenly supported by compositors and even more unevenly supported by applications. I spent an afternoon trying various approaches, but for the life of me I could not get Zoom to do anything like screen sharing of my sway desktop. And unfortunately with everybody being entirely remote in the midst of a pandemic, "sharing my screen on a Zoom call" is a non-negotiable requirement for me several times a week right now. But I like the advantages of sway enough that after a few days of playing with it I am loathe to go back to my old setup, so this is the awful compromise I've landed on for now: I've put together an i3/polybar setup for X11 that is almost the same as my sway/waybar setup for Wayland. And I'm going to try and use both: I'll start my day in an X session on days when I expect to be on calls, but try to spend time in Wayland if I don't expect to be be screen-sharing. Hopefully the screen-sharing situation will improve and I can drop this crufty dual setup and delete a bunch of X11 cruft from my dotfiles. Wayland definitely seems like the future, I guess that future just isn't quite here for those of us who prefer tiling window managers (and thus don't want to use GNOME). In some ways it reminds me of Systemd: it feels less "unixy" because it's not organized around very focused programs that interact with each other, but instead tends towards a more monolithic implementation of a bunch of related functionality. And it has some definitely questionable technical details. But the lived experience of *using it* is so much better than what came before that it seems obvious that it's what should be focused on. For my own future reference, here is what I played with to try and get screensharing working on Sway: - swaywm/sway#4358 & swaywm/sway#3282 - `xdg-desktop-portal-wlr` is apparently supposed to add appropriate support for screensharing, but it didn't work for me. I didn't bother trying to use a patched FF, so I'm not surprised that didn't work. Some post I saw somewhere suggested that Zoom actually detects its on GNOME, so maybe it would work here if I forced it to think it's on GNOME? Didn't try that, should do that. - The slightly crazier suggestion there was to use a v4l2loopback device to record your desktop as a "webcam" and then just pick that as your video camera in zoom. Clever, but awkard and hacky. I also ran into errors with having `wf-recorder` record using v4l2. (I don't think ammen99/wf-recorder#92 was the issue, `ffmpeg` said the code was available, the error was a bit more like ammen99/wf-recorder#70 but the kernel module was also there and the device was available.) - https://gitlab.com/jamedjo/gnome-dbus-emulation-wlr - saw this mentioned in one of the Sway issues linked above. It's a Ruby project that apparently presents dbus services that look like GNOME services to trick apps like Zoom into thinking their on GNOME? Again, didnt' work for me. - swaywm/sway#5083 has the truly crazy idea of running zoom, etc. via x11docker, running a VNC server on your host, and then connecting the x11docker to your desktop via VNC and sharing that. I did not do that, I think I prefer to just switch back to X11. [Waymonad]: https://github.com/waymonad/waymonad [Sway]: https://github.com/swaywm/sway [i3]: https://github.com/i3/i3 [msu]: https://github.com/wfleming/dotfiles/blob/arch-linux/home_nodot/bin/msu
|
Had same issue on Ubuntu 20.10. It turned out that wf-recorder was initially built without libavdevice and couldn't understand "v4l2" muxer option. My setup:
Other things I tried during debugging and which worked:
|
|
I'm on debian bullseye and followed @gmykhailiuta suggestion: |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
When run
wf-recorder --muxer=v4l2 --codec=rawvideo --file=/dev/video2 -o eDP-1I get output
User has
videogroup andv4l2loopbackmodule is loaded.Version:
0.2.1OS: Debian sid
Btw, Thanks for developing this tool. Except this issue it's working pretty nice :)
The text was updated successfully, but these errors were encountered: