dav1d 0.5.1 patch fix?
it does not work on non-x86 at the moment (need more work) but at least on x86 patching should be ok now. anyone want to test? (patch with git am please :-} )
I tried the patch "0001-fix-dav1d-0.5.1-patch-non-x86-incompatible-atm.patch" in Debian 11 32-bit. Applying the patch, on the terminal I have this message: patching: fix dav1d 0.5.1 patch (non-x86 incompatible atm). I used "git am ..." (but even with "patch -p3 < ..." it doesn't work!) Continuing the compilation I have error. I append the cin5-dav1d.log (NOTE: I renamed the patch to "david.patch" before applying it; can this be a problem?)
On Tuesday, November 30, 2021, Andrea paz <[email protected]> wrote:
I tried the patch "0001-fix-dav1d-0.5.1-patch-non-x86-incompatible-atm.patch" in Debian 11 32-bit. Applying the patch, on the terminal I have this message: patching: fix dav1d 0.5.1 patch (non-x86 incompatible atm). I used "git am ..." (but even with "patch -p3 < ..." it doesn't work!) Continuing the compilation I have error. I append the cin5-dav1d.log (NOTE: I renamed the patch to "david.patch" before applying it; can this be a problem?)
ow, you are right, i misedited patch. try to remove dav1d-0.5.1 part from it, or apply edited one I attaching to this mail? sorry!
Build is OK with the new patch. I tried to load 2 AV1 videos: OK. I tried to playback and after a while I got a crash (no dump). I tried again to load the 2 files and do Resoucers --> info: the 2 windows opened (also "detail"); but then they froze and I had to kill CinGG.
On Tuesday, November 30, 2021, Andrea paz <[email protected]> wrote:
Build is OK with the new patch. I tried to load 2 AV1 videos: OK. I tried to playback and after a while I got a crash (no dump). I tried again to load the 2 files and do Resoucers --> info: the 2 windows opened (also "detail"); but then they froze and I had to kill CinGG.
so, i guess even if internal dav1d can be built now it actually unusable...
On Tuesday, November 30, 2021, Andrew Randrianasulu <[email protected]> wrote:
On Tuesday, November 30, 2021, Andrea paz <[email protected]> wrote:
Build is OK with the new patch. I tried to load 2 AV1 videos: OK. I tried to playback and after a while I got a crash (no dump). I tried again to load the 2 files and do Resoucers --> info: the 2 windows opened (also "detail"); but then they froze and I had to kill CinGG.
so, i guess even if internal dav1d can be built now it actually unusable...
can you test same trick I used here: export FFMPEG_EXTRA_CFG="--disable-debug --disable-ffprobe --enable-libdav1d" export EXTRA_LIBS="-ldav1d" ./configure --with-single-user --disable-dav1d with your av1 files? (assuming you have new version of libdav1d and its development files installed)
I found installed libdav1d4 version 0.7.1-3; not installed there: dav1d 0.7.1-3 libdav1d-dev 0.7.1-3 I installed these as well but still get freeze/crash. Then I recompiled according to your latest instructions: Still performance issues and then freeze and crash. I attach the terminal output. Previously I had no warnings on audio.
On Thursday, December 2, 2021, Andrea paz <[email protected]> wrote:
I found installed libdav1d4 version 0.7.1-3; not installed there: dav1d 0.7.1-3 libdav1d-dev 0.7.1-3 I installed these as well but still get freeze/crash.
Then I recompiled according to your latest instructions: Still performance issues and then freeze and crash. I attach the terminal output. Previously I had no warnings on audio.
mmap() failed: Cannot allocate memory mmap() failed: Cannot allocate memory AudioALSA::open_output default: Input/output error mmap() failed: Cannot allocate memory mmap() failed: Cannot allocate memory AudioALSA::open_output default: Input/output error mmap() failed: Cannot allocate memory mmap() failed: Cannot allocate memory AudioALSA::open_output default: Input/output error VFrame::allocate_data 1920x1080: memory exhausted. this is on normal 64-bit os without any additional limits?
No it's on Debian 11 32-bit in VM. Should I patch and test on my Arch 64-bit? I thought the patch was only for 32-bit, sorry.
On Thursday, December 2, 2021, Andrea paz <[email protected]> wrote:
No it's on Debian 11 32-bit in VM. Should I patch and test on my Arch 64-bit? I thought the patch was only for 32-bit, sorry.
well, I saw patching failure on MatN's aarch64 VM then tried to fix it locally (run into fact new makefile really x86-oriented) then you discovered it still has problems.. Can you try smaller (as in with less resolution) av1 file or setting vm's memory to some higher value (like 2.5 gb), and/or try to set up zswap in vm? And yes, double-checking on your normal Arch host install will be helpfull (do not want to break it!)
Using the same AV1 videos but in HD resolution instead of FullHD, I don't have any problems or even slowdowns in playback and reverse playback. I tried both using the 2 exports and "--disable-dav1d" and without these configurations: all is fine in both cases. Anyway, my VM has always been set up with 8GB of RAM (out of 32 physical) and 4c/8t for the CPU (out of 8c/16t physical), but apparently that's not enough to support FullHD. On my system (Arch Linux 64-bit; KDE), I've tried compiling just the patch (without export and --disable-dav1d) and it works without problems. However, with FullHD videos, playback is smooth but reverse playback has some framerate drops. Sorry for wasting your time behind false problems.
On Friday, December 3, 2021, Andrea paz <[email protected]> wrote:
Using the same AV1 videos but in HD resolution instead of FullHD, I don't have any problems or even slowdowns in playback and reverse playback. I tried both using the 2 exports and "--disable-dav1d" and without these configurations: all is fine in both cases. Anyway, my VM has always been set up with 8GB of RAM (out of 32 physical) and 4c/8t for the CPU (out of 8c/16t physical), but apparently that's not enough to support FullHD.
may be problem with 32-bit case is limited _virtual_ address space - no more than 4gb, and some of it eaten by kenel mapping pci devices and such. Ironically so-called PAE linux kernel can address more physical ram than 4gb, yet individual processes limited to some 3gb... or even less (depend on kernel configuration, vm_split I think...)
On my system (Arch Linux 64-bit; KDE), I've tried compiling just the patch (without export and --disable-dav1d) and it works without problems. However, with FullHD videos, playback is smooth but reverse playback has some framerate drops.
Sorry for wasting your time behind false problems.
well, they not false just rare (due to limited 32-bit testing). Not like we can do much about memory exhausting errors.. but this might deserve some footnote.
participants (2)
-
Andrea paz -
Andrew Randrianasulu