-
Notifications
You must be signed in to change notification settings - Fork 544
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
Linux AppImage: Possible issues importing video with certain GPUs #4538
Comments
Devs: The issue occurs because an existing Due to the problems users previously reported with hardware decoding in AppImage builds, I added a library-mangler to the project build servers which disables the built-in The problem we now have is that, if libopenshot is told to attempt to use hardware decoding, it will. And if (using my own setup as an example) the hardware-decoding mode is set to There are two solutions here, as I see it:
|
YES! Disable it in the AppImage. Short: Longer: Extended but worth reading: |
Hardware-accelerated de-coding is of precious little value to us anyway, because we have to decode every frame to an RGB image in system memory, (potentially) modify that image, and then display the results "by hand" — the GPU isn't involved in the process hardly at all. The decoding step is the least of the work there. Hardware decoding's benefits depend on the video never coming back out of the GPU, and being displayed directly from video memory as it exits the decoding pipeline. But OpenShot can't possibly work that way. ...Hardware-accelerated EN-coding is nice to have, and can actually represent a genuine speedup for the encoding process. But I don't think it's unfair to say: If you want that, install a native package for your distro. (Or switch to the Flatpak, which may or may not currently have support for hardware encoding, but definitely could have support for hardware encoding much more feasibly than the AppImage can, since Flathub publishes runtimes with GPU driver support already enabled.) |
@ferdnyc That is where I can see Vulkan helping us in the future. With Vulkan Video we would be able to load accelerated, then modify (fading, blurr ...) with Vulkan Compute, and then export accelerated with Vulkan Video. Vulkan uses the same memory space a copying would not be necessary. In the future that might be an option! |
That does sound interesting, wow! It'd be awesome if we could develop a fully in-GPU pipeline. It'd mean some major changes to the entire data model for how content moves through OpenShot, but it sounds like the benefits are probably more than worth it. Would that mean having to implement effects in the YUV color space? Or would the Vulkan pipeline be able to handle round-trip conversion to RGB as well? For some effects like crop and blur it doesn't really matter, obviously, but trying to wrap my brain around YUV ChromaKey is already giving me a headache. Maybe there's some way to convert the effect into YUV so that it still produces the same results you'd get with RGB? That's a question for color wizards far more powerful than I. (Though, even then, I'm curious whether it could still be parameterized the same way.) |
Historically my idea was to have the effects on the GPU but ack then it would have been CUDA and OpenCL, then Vulkan was released with Vulkan Compute and that sounded very interesting as Vulkan is basically on every machine because of the gaming part (no need to install something people don't know), and not too far ago Vulkan Video was released. Now I am right now in a situation where I have not enough time to do anything I want to do (including playing around with RISC-V and it's vector extension) but I try to stay informed and develop ideas. The Vulkan pipeline for decoding, modifying, and encoding (plus display) would be great. |
@ferdnyc Just in today: |
Thank you so much for submitting an issue to help improve OpenShot Video Editor. We are sorry about this, but this particular issue has gone unnoticed for quite some time. To help keep the OpenShot GitHub Issue Tracker organized and focused, we must ensure that every issue is correctly labelled and triaged, to get the proper attention. This issue will be closed, as it meets the following criteria:
We'd like to ask you to help us out and determine whether this issue should be reopened.
Thanks again for your help! |
It appears the OpenShot 2.6.1 release AppImage (and all recent daily builds before/after that release) may fail to import certain video formats on systems containing a GPU which has hardware decoding support for the video format.
The issue occurs when the user's existing preferences have a hardware-decoding mode selected. (For instance, from previously running an installed native build of OpenShot.) This setting is not properly ignored by the AppImage builds of OpenShot, which do not currently support hardware video decoding. This results in a valid video file being rejected by OpenShot when importing:
As a workaround, quit all instances of OpenShot, then delete or rename the file
$HOME/.openshot_qt/openshot.settings
to reset your OpenShot user preferences. The next time OpenShot is launched, that file will be created with default settings, and the AppImage build will successfully import the affected files.The text was updated successfully, but these errors were encountered: