Activity for guvcview
-
Johan Eriksson created merge request #14 on Git-Master
Increase allowed device path length
-
Igor Volovichev created ticket #80
Segmentation fault in packet.c
-
guvcview released /source/guvcview-src-2.2.2.tar.bz2
-
Paulo Assis committed [289fd2] on Git-Master
update changelog for v2.2.2
-
Fix compile with musl and ffmpeg 8.0
-
Patches added to git master
-
Apply ffmpeg8 and musl patches by Paul Zander <negril.nx+gentoo@gmail.com>; add sfml3 fixes
-
Nico P modified ticket #79
Fix compile with musl and ffmpeg 8.0
-
Fix compile with musl and ffmpeg 8.0
-
update to SFML 3.0
-
Patrick Roncagliolo created ticket #78
Uninitialized string field in code
-
Mejdi modified a comment on discussion General Discussion
Hello, It is great that with Guvcview one can chose the camera output format (depending on camera: MJPG, RGB3, Grey 16bit...) and Cap. Video codec (Raw, H264...) directly via the GUI. It would be great if we could also chose the Cap. Image encoding like Raw or PNG. Today it seems to be only JPG (which has lossy compression). Use case: when using scientific cameras (more and more propose UVC output), it is critical to extract photo/snapshot that are exactly the raw format without (lossy) compression....
-
Hello, It is great that with Guvcview one can chose the camera output format (depending on camera: MJPG, RGB3, Grey 16bit...) and Cap. Video codec (Raw, H264...) directly via the GUI. It would be great if we could also chose the Cap. Image encoding like Raw or PNG. Today it seems to be only JPG (which has lossy compression). Use case: when using scientific cameras (more and more propose UVC output), it is critical to extract photo/snapshot that are exactly the raw format without (lossy) compression....
-
Ju In posted a comment on discussion General Discussion
I am trying to capture the video feed off of my Nikon D500 DSLR camera that is connected to an USB capture card. The captured video lags so much against the audio (from an audio recording device separate from the camera). Adjusting the audio latency does not help much. Could this problem be caused by the performance of the capture card, or is it a performance issue of v4l2? Thanks.
-
fix some spelling errors
-
Add gtk3 support for OBSBOT Meet4K AI camera
-
Sam Liddicott posted a comment on merge request #11
I've added QT and fixed other warnings. It compiles clean for QT and GTM and works for both. Please would you merge
-
I've refreshed the GTK for current master, and am making progress on QT.
-
I've refreshed the GTK for current master, but I can't get the QT interface to show at all right now so I'm a bit stuck on making that work
-
Fix desktop file for cmake
-
fix deprecation warning with ffpmeg 7.1; add -Wall to compile flags
-
I think in arch libdecor doesn't force the gtk3 plugin, so SDL in gnome ends up using the default cairo backend.
-
I think in arch libdecor doesn't force the gtk3 plugin, so SDL in gnome ends up using the default cairo,
-
this is because mutter doesn't implement xdg-decorations and forces csd (client side decorations), this seems like a lost battle. All wayland compositors, implement ssd (server side decorations) with the exception of gnome and enlighthment.
-
Adam Williamson posted a comment on ticket #77
Huh, Fedora's SDL2 and libdecor both buildrequire pkgconfig(wayland-protocols), so I'm not sure why we wind up in GTK3 nevertheless. Will poke into it a bit.
-
guvcview with SDL backend uses GTK in two separate threads which is not valid, causes crashes on Wayland
-
Thanks Jonas! Sorry, I misunderstood the PR as meaning "the app will crash intentionally" or something equally bad, not "it'll fall back smoothly to some other decorations". I guess I'll check if Fedora's SDL can be built with wayland-protocols, too...
-
Jonas Ådahl posted a comment on ticket #77
I don't think guvcview needs to or should change, I created a MR to libdecor to not attempt to use the gtk decoration plugin and fall back to the cairo one, if it's not run from the main thread. Cairo doesn't care what thread it is run from. Ideally libdecor can address this in the future to get GTK based decorations for this use case.
-
This can't be the issue. Building guvcview with Qt and disabling Gtk also causes the same crash (according to your tests). Disabling Gtk makes sure guvcview isn't even linked against Gtk. Guvcview only uses Gtk in the main thread. The render thread uses SDL or SFML. I don't know any distribution in that SDL has a direct dependency on Gtk. This just doesn't make any sense. SDL is supposed to be system independent. libdecor is NOT a gtk lib, although it has a optional Gtk pluggin (https://gitlab.freedesktop.org/libdecor/libdecor)...
-
Checking SDL API I found that libdecor is used over xdg-shell when xdg-decoration protocol is unavailable. So if xdg-decoration is available native decorations are used instead. In Arch both SDL and libdecor are build with a dependency on wayland-protocols package that includes xdg-decoration, so in arch at least, both SDL and libdecor use native wayland window decorations instead of the Gtk3 pluggin.
-
libdecor can be disabled programmatically : https://wiki.libsdl.org/SDL2/SDL_HINT_VIDEO_WAYLAND_ALLOW_LIBDECOR just need to add SDL_SetHint("SDL_HINT_VIDEO_WAYLAND_ALLOW_LIBDECOR", "0"); to render_sdl2.c just after SDL_SetHint("SDL_HINT_RENDER_SCALE_QUALITY", "1"); around line 84
-
This can't be the issue. Building guvcview with Qt and disabling Gtk also causes the same crash (according to your tests). Disabling Gtk makes sure guvcview isn't even linked against Gtk. Guvcview only uses Gtk in the main thread. The render thread uses SDL or SFML. I don't know any distribution in that SDL is has a direct dependency on Gtk. This just doesn't make any sense. SDL is supposed to be system independent. libdecor is NOT a gtk lib, although it has a optional Gtk pluggin (https://gitlab.freedesktop.org/libdecor/libdecor)...
-
The problem started appearing on Fedora when the whole stack was native Wayland, I think. But according to the GTK devs, running GTK in two threads within the app is just fundamentally wrong and not supportable even if it happened to work in some configurations, they're not going to do anything to fix the crash. edit: and yeah, I guess SDL build could affect it. For instance, is arch's SDL actually built against libdecor? This bug will only happen with libdecor, as that's what causes SDL to use ...
-
The problem started appearing on Fedora when the whole stack was native Wayland, I think. But according to the GTK devs, running GTK in two threads within the app is just fundamentally wrong and not supportable even if it happened to work in some configurations, they're not going to do anything to fix the crash.
-
Hi, I've been running guvcview in wayland with the sdl backend for 2+ years (in Arch) without any issues. The gui and the render run in different threads, this is how guvcview is designed. I've tested in gnome, plasma and sway and never had any issues. Could this be related to the way sdl is build?
-
Hi, I've been running guvcview in wayland with the sdl backend for 2+ years (in Arch) without any issues. The gui and the render run in different threads, this is how guvcview is designed. I've tested in gnome, plasma and sway and never ad any issues. Could this be related ti the way sdl is build?
-
ah, forgot about this ticket. this eventually came back around on 'guvcview is doing something wrong', specifically using GTK in two threads - https://sourceforge.net/p/guvcview/tickets/77/ .
-
guvcview with SDL backend uses GTK in two separate threads which is not valid, causes crashes on Wayland
-
-
fix libs version
-
Also needs QT support for merging, otherwise it will loose consistency between GTK and QT interfaces. Since I don't have this camera to test, I can't add support for the QT interface myself.
-
fix the guvcview with mjpeg when I use high resolution camera to preview
-
add corrected fix to master with commit [9b143fe]
-
add support for MJPG decoder for yuv420p output pixel format
-
set render window to fixed size keeping video aspect ratio
-
fix pts ordering for video muxing
-
use pkt pts as muxer timestamp
-
fix video timestamps
-
glads it helps.
-
林博仁(Buo-ren Lin) posted a comment on merge request #11
I also have this hardware as well, thanks for the work!
-
Fix build failure
-
No longer reproduced in 2.1.0, closing.
-
I have the same issue as well and can verify that this patch works for me. Good job!
-
fix spelling errors in gview_audio
-
clang-format gview_v4l2core code
-
fix qt6 package name in README.md
-
small update to README.md
-
update README.md with cmake build system info
-
clang-format gview_audio code
-
update Changelog
-
update GL linking
-
add -lGL to gview_render and guvcview if SFML is used
-
make -lGL option PUBLIC
-
in some distros GL is not linked for gview_render, force it with -lGL
-
change build system: move from autoconf to cmake
-
Daniel Schaefer created merge request #13 on Git-Master
Detect readonly controls and disable in UI
-
fix x265 encoder defaults
-
Frequent crashes in GTK CSS code when run as regular user
-
Filed https://gitlab.gnome.org/GNOME/gtk/-/issues/6611 .
-
it's kinda starting to look a lot like this isn't a guvcview issue, anyway. will probably move it to gtk or mutter or something soon.
-
qt5 with SDL does not solve the crash, and we get a pretty weird backtrace that goes qt5->glib->gdk->gtk3: Stack trace of thread 266293: #0 0x0000000200400310 n/a (n/a + 0x0) #1 0x00007fa81573c979 gtk_css_node_real_update_style (libgtk-3.so.0 + 0x13c979) #2 0x00007fa8157398eb gtk_css_node_ensure_style.part.0 (libgtk-3.so.0 + 0x1398eb) #3 0x00007fa815739b88 gtk_css_node_validate_internal.part.0 (libgtk-3.so.0 + 0x139b88) #4 0x00007fa815739bdb gtk_css_node_validate_internal.part.0 (libgtk-3.so.0 +...
-
OK, so, found out a couple of things: Building with SFML does indeed seem to avoid the problem. Tried running an SFML build twice and letting it run for a while, it didn't crash. The crash seems to be Wayland-specific. When running on X.org, the crash doesn't happen. This might explain why folks have had trouble reproducing it outside of Fedora, I guess. Edit: looks like it may even be GNOME-on-Wayland specific; Neal Gompa says it doesn't crash on KDE-on-Wayland. Didn't try qt UI-on-SDL yet, will...
-
OK, so, found out a couple of things: Building with SFML does indeed seem to avoid the problem. Tried running an SFML build twice and letting it run for a while, it didn't crash. The crash seems to be Wayland-specific. When running on X.org, the crash doesn't happen. This might explain why folks have had trouble reproducing it outside of Fedora, I guess. Didn't try qt UI-on-SDL yet, will try that next.
-
OK, if it will help with triaging I'll try both and report back. thanks!
-
If the problem is in sdl2, then using the qt interface shouldn't make any difference. The crash should happen any way. If the problem is in the gtk interface, then yes, using the qt interface should produce a different output
-
"I don't think fedora default theme is the same as gtk default (Adwaita)." It is. We use pretty much all upstream GNOME defaults, these days. "Have you tried with sfml render instead of sdl2?" Not yet, I can try that if you think it may help. Switching to the qt5 backend will obviously produce different results, but...it feels like a weird way to resolve the gtk backend crashing when it shouldn't. :D
-
I don't think fedora default theme is the same as gtk default (Adwaita). In any case guvcview doesn't use any of the gtk css stuff directly. For what I can see from your backtrace, there seems to be some calls to sdl decorate border, I'm not sure about sdl2 internals, but if you running gnome, maybe window decorations use gtk css. Have you tried with sfml render instead of sdl2?
-
This is with default theme. I reproduced this on a completely clean fresh boot of Fedora (40). I agree the different result with root points to some kind of permission situation, but the app still should not just crash, and I was hoping as the author you might have some kind of idea what different permissions might cause the app to go down different paths early in startup, so we could try and isolate exactly where the divergence is. I would like to try giving the regular user one additional permission...
-
Hi, have you tried with the qt interface : --disable-gtk3 --enable-qt5 You can also enable the sfml render: --enable-sfml and then: guvcview --render=sfml As for the GTK interface, I really can't reproduce the problem in Arch. Did you tried changing your gtk theme? If it works under root then it's most likely a permission issue. Just try with a default theme like Adwaita or installing a local theme. Regards,
-
My full backtrace.
-
Frequent crashes in GTK CSS code when run as regular user
-
jpeg_decoder.c and uvc_h264.c are missing include of libavutil/imgutils.h for av_image_get_buffer_size
-
Morpher posted a comment on ticket #48
Also, Guvcview creates large video files which could be reduced by allowing the specification of H264 attributes "crf" and "gop_size". In my case adding some command line parameters which set internal global variables would be sufficient. I am a coder and could do the work if that helps.
-
-
always link guvcview with -lGl if sfml build is enabled; bump guvcview and libraries verion
-
Fix duplicate key
-
fix crosshair size config file read
-
Merge remote-tracking branch 'refs/remotes/origin/master'
-
enable osd crosshair size to be changed in the config file
-
b'Paulo Assis committed [419a91] on Git-Master
Merge /u/ramast/guvcview/ branch master into master
-
Support physical button click for certain digital microscope models
-
Make guvicview skips device files for metadata.
-
apply Kentaro Fukushi patch: Make guvicview skips device files for metadata.
-
fix printf warning
-
Add binary fx filter
-
Hi, This will only work for gtk3, you also need to change MainWindow::render_fx_filter_changed(int state) in gui_qt5_callbacks.cpp so that the filter is available in the qt5 interface. Otherwise it wont even build with configure --enable-qt5
-
okokok created merge request #12 on Git-Master
Added fisheye video filter effect.
-
Michael Gilligan modified a comment on discussion General Discussion
There is a very useful little program called sViacam which runs on Windows and appears not to have been updated since 2012 Could you please consider adding similar functionality to guvcview ? … it would obviously be even better on the RasPi with its GPIO
-
Feature Request
-
Feature Request
1 >