I have an RHEL8 system and wanted support for vdpau playback. The appimage does not seem to work, dropping back to software playback. I downloaded the Dec 31 2021 tarball and compiled it. It worked for a while but now it crashes with the following when I hit the play button. There were some system updates installed in the interim. VFrame::allocate_data 518 could not attach shared memory, 930x523 (model 6) shmid=0x00000000 shmall = 18446744073692774399 shmmax = 18446744073692774399 shmmni = 4096 shmused = 50173032 (6 items) shmother = 4870728 (8 items) Mutex::lock: Success Mutex::unlock: Invalid argument Regards, Mark
On Saturday, January 15, 2022, Mark Goldberg via Cin < [email protected]> wrote:
I have an RHEL8 system and wanted support for vdpau playback. The appimage does not seem to work, dropping back to software playback. I downloaded the Dec 31 2021 tarball and compiled it. It worked for a while but now it crashes with the following when I hit the play button. There were some system updates installed in the interim.
trivial idea but try to re-compile again?
VFrame::allocate_data 518 could not attach shared memory, 930x523 (model 6) shmid=0x00000000 shmall = 18446744073692774399 shmmax = 18446744073692774399 shmmni = 4096 shmused = 50173032 (6 items) shmother = 4870728 (8 items) Mutex::lock: Success Mutex::unlock: Invalid argument
Regards,
Mark
The crash is bad, but I can confirm that vdpau playback in the AppImage does not work.Test procedure (on Mint 20.2):- Make sure that "vdpauinfo" confirms it is OK. Maybe vdpau is not supported on Redhat, Fedora_35 does not support either vaapi or vdpau.- From a terminal, load the CinGG-20211231-multibit.AppImage . In Settings->Prefrences-
Performance, make sure "HW device" is set to "none".- Load a video of a format supported by vdpau on your hardware (see output of vdpauinfo). H.264-main or -high is usually safe.- Play a little of the video. The terminal CinGG was started from should not show any errors.- Change the "HW Device" to vdpau. Exit and reload CinGG. Load the same video, play it a little.I get errors in the terminal:============Failed to open VDPAU backend libvdpau_radeonsi.so: cannot open shared object file: No such file or directoryFailed HW device create.dev:vdpau err: Unknown error occurredHW device init failed, using SW decode.=============The shared object file name depends on you hardware. @Mark, can you confirm vdpau works on your system, outside of CinGG? Does vdpauinfo say it is OK?Does "HW device" vdpau work in the compiled version without errors, apart from the crash? MatN On Sat, 2022-01-15 at 10:20 -0700, Mark Goldberg via Cin wrote: I have an RHEL8 system and wanted support for vdpau playback. The appimage does not seem to work, dropping back to software playback. I downloaded the Dec 31 2021 tarball and compiled it. It worked for a while but now it crashes with the following when I hit the play button. There were some system updates installed in the interim.
VFrame::allocate_data 518 could not attach shared memory, 930x523 (model 6) shmid=0x00000000 shmall = 18446744073692774399 shmmax = 18446744073692774399 shmmni = 4096 shmused = 50173032 (6 items) shmother = 4870728 (8 items) Mutex::lock: Success Mutex::unlock: Invalid argument
Regards,
Mark
For those who don't follow the forum, there is a similar discussion regarding (among other things) vaapi: https://www.cinelerra-gg.org/forum/help-video/how-to-optimize-playback/#post...
On Mon, Jan 17, 2022, 3:32 AM mat <[email protected]> wrote:
@Mark, can you confirm vdpau works on your system, outside of CinGG? Does vdpauinfo say it is OK? Does "HW device" vdpau work in the compiled version without errors, apart from the crash?
On RHEL8 the appimage for older distros is required as glibc is older. It does not work with vdpau, falling back to software. In the locally compiled version it does use vdpau, but I have 4k60 f-log videos, and adding the lut3d plugin slows things down such that it cannot play in real time. @Andrew, I have compiled multiple times and changed versions of the Nvidia driver, same crash. @Andrea, I have seen the forum posting. There are issues with plugins slowing things down, but I will start a second thread for that. Latest compile is the multibit version. It's more complicated. If there is another video track on the timeline below what is playing, it does not crash and plays successfully. Regards, Mark
On Monday, January 17, 2022, Mark Goldberg via Cin < [email protected]> wrote:
On Mon, Jan 17, 2022, 3:32 AM mat <[email protected]> wrote:
@Mark, can you confirm vdpau works on your system, outside of CinGG? Does vdpauinfo say it is OK? Does "HW device" vdpau work in the compiled version without errors, apart from the crash?
On RHEL8 the appimage for older distros is required as glibc is older. It does not work with vdpau, falling back to software. In the locally compiled version it does use vdpau, but I have 4k60 f-log videos, and adding the lut3d plugin slows things down such that it cannot play in real time.
you can try to hack makefiles of individual plugins (while lut3d is ffmpeg's one, so not sure how to influence irs compile flags individually) with -march=native, -mavx (if you have avx instructions in your cpu), and other suitable flags... CinGG for now mostly cpu/memory intensive, not using OpenCL/cuda (unlike big commercial editors?) so setting correct cpu flags may give relatively big boost.
@Andrew, I have compiled multiple times and changed versions of the Nvidia driver, same crash.
from forum post I see case when gpu decoder utilization (as seen via nvidia's utility) still not 0%, so it works, but probably pulling and pushing frames between vram and ram via pci-e bus takes cpu, too (even if dma should do it for free?). I remember long time ago open-source radeon driver developers run into some underutilization of bus so they applied big expensive logic analyzer (at pcie speeds!) for finding some bottlenecks.... so I am afraid without much better developers poking graphics stack while Cingg is running not much can be done.. :( @Andrea, for some reason I can't download attaches from forum (because I have no login there?), can you add CMS.txt as attachment to email (again)? I recall older version of Final Cut (before X) has ColorSync plugin (probably utilizing cpu at early 2000s), so may be making lcms2 plugin will provide some workaround for lack of core color management? (like, you switch slow colorcorrection plugin/effect for color work, turn it off for edits... those transforms using monitor's profile tend to be math heavy if executed on cpu only, even with simd... )
@Andrea, I have seen the forum posting. There are issues with plugins slowing things down, but I will start a second thread for that.
Latest compile is the multibit version. It's more complicated. If there is another video track on the timeline below what is playing, it does not crash and plays successfully.
sorry, I can't test this due to lack of access to my main desktop... and laptops here only have vaapi (may be I can recompile x86_32 version of cingg... those are not *my* laptops, but I have live usb stick with slackware /copy of my home system from ~2020)
Regards,
Mark
Mark, of concern to me first is the below because a* change was made to vframe.C in December.* Ignoring vdpau for me for now, did the November tarball work? *VFrame*::allocate_data 518 could not attach shared memory, 930x523 (model
6) shmid=0x00000000 shmall = 18446744073692774399 shmmax = 18446744073692774399 shmmni = 4096 shmused = 50173032 (6 items) shmother = 4870728 (8 items) Mutex::lock: Success Mutex::unlock: Invalid argument
On Mon, Jan 17, 2022 at 8:07 AM Phyllis Smith via Cin < [email protected]> wrote:
Mark, of concern to me first is the below because a* change was made to vframe.C in December.* Ignoring vdpau for me for now, did the November tarball work?
I will try it. It may be a day or two until I get to recompiling the November tarball.
Regards, Mark
On Mon, Jan 17, 2022 at 8:18 AM Mark Goldberg <[email protected]> wrote:
On Mon, Jan 17, 2022 at 8:07 AM Phyllis Smith via Cin < [email protected]> wrote:
Mark, of concern to me first is the below because a* change was made to vframe.C in December.* Ignoring vdpau for me for now, did the November tarball work?
I will try it. It may be a day or two until I get to recompiling the November tarball.
November tarball crashes the same way. Note the input file is a 200 Mbps H.265 10 bit f-log 4k60 .MOV file from a Fuji X-T4. Regards, Mark
What additional information can I provide to help determine what the issue is? The appimage does not succeed in using vdpau and does not crash. If I set the compiled version to not use any hardware accel, it still crashes. I don't think the vdpau issue and the crash are related. The crash is my big concern obviously, as any work not saved is lost. What is the difference in the "older distro" appimages? Regards, Mark On Mon, Jan 17, 2022 at 10:46 AM Mark Goldberg <[email protected]> wrote:
On Mon, Jan 17, 2022 at 8:18 AM Mark Goldberg <[email protected]> wrote:
On Mon, Jan 17, 2022 at 8:07 AM Phyllis Smith via Cin < [email protected]> wrote:
Mark, of concern to me first is the below because a* change was made to vframe.C in December.* Ignoring vdpau for me for now, did the November tarball work?
I will try it. It may be a day or two until I get to recompiling the November tarball.
November tarball crashes the same way. Note the input file is a 200 Mbps H.265 10 bit f-log 4k60 .MOV file from a Fuji X-T4.
Regards,
Mark
On Tuesday, January 18, 2022, Mark Goldberg via Cin < [email protected]> wrote:
What additional information can I provide to help determine what the issue is?
try to install gdb and get some backtrace?
The appimage does not succeed in using vdpau and does not crash. If I set the compiled version to not use any hardware accel, it still crashes. I don't think the vdpau issue and the crash are related. The crash is my big concern obviously, as any work not saved is lost. What is the difference in the "older distro" appimages?
compiled on older distribution? (so older glibc, etc...)
Regards,
Mark
On Mon, Jan 17, 2022 at 10:46 AM Mark Goldberg <[email protected]> wrote:
On Mon, Jan 17, 2022 at 8:18 AM Mark Goldberg <[email protected]> wrote:
On Mon, Jan 17, 2022 at 8:07 AM Phyllis Smith via Cin < [email protected]> wrote:
Mark, of concern to me first is the below because a* change was made to vframe.C in December.* Ignoring vdpau for me for now, did the November tarball work?
I will try it. It may be a day or two until I get to recompiling the November tarball.
November tarball crashes the same way. Note the input file is a 200 Mbps H.265 10 bit f-log 4k60 .MOV file from a Fuji X-T4.
Regards,
Mark
participants (5)
-
Andrea paz -
Andrew Randrianasulu -
Mark Goldberg -
mat -
Phyllis Smith