Package Details: rav1e-git 0.6.6.r211.gba7ed562-1

Git Clone URL: https://aur.archlinux.org/rav1e-git.git (read-only, click to copy)
Package Base: rav1e-git
Description: The fastest and safest AV1 encoder
Upstream URL: https://github.com/xiph/rav1e
Licenses: custom, BSD
Conflicts: rav1e
Provides: librav1e.so, rav1e
Submitter: Chocobo1
Maintainer: Chocobo1
Last Packager: Chocobo1
Votes: 7
Popularity: 0.000000
First Submitted: 2018-02-25 07:31 (UTC)
Last Updated: 2023-06-21 10:39 (UTC)

Dependencies (5)

Required by (25)

Sources (1)

Latest Comments

« First ‹ Previous 1 2 3 4 Next › Last »

Chocobo1 commented on 2020-01-23 03:54 (UTC) (edited on 2020-01-23 04:03 (UTC) by Chocobo1)

/usr/.crates2.json should be removed from the package.

I see no such file on my builds, where does it come from?

gmes78 commented on 2020-01-23 00:29 (UTC)

/usr/.crates2.json should be removed from the package. I also suggest passing the -f flag to rm, so that if /usr/.crates2.json (or /usr/.crates.toml) isn't there, the build doesn't fail.

gmes78 commented on 2019-11-22 18:21 (UTC)

OK, updated although I haven't really compared the run time differences. A quick glance reveals that cargo-c is spending most of its time waiting for rustc to complete so I guess time difference won't be significant.

I made a comparison just now:

$ rm -rf src/ pkg/ && makepkg -o --noprepare && time makepkg --noarchive
makepkg --noarchive  906,78s user 14,30s system 215% cpu 7:07,42 total
$ git reset --hard PKGBUILD && git pull
$ rm -rf src/ pkg/ && makepkg -o --noprepare && time makepkg --noarchive
makepkg --noarchive  630,62s user 14,11s system 177% cpu 6:03,62 total

The difference between the former (cargo-c with optimizations) and the latter (cargo-c without optimizations) is that the latter is 64 seconds faster. Which is the exact same difference as my other comparison.

In other words, disabling optimizations for cargo-c doesn't impact its runtime speed in any noticeable way.

Chocobo1 commented on 2019-11-22 03:24 (UTC)

May I suggest building cargo-c in debug mode?

OK, updated although I haven't really compared the run time differences. A quick glance reveals that cargo-c is spending most of its time waiting for rustc to complete so I guess time difference won't be significant.

gmes78 commented on 2019-11-21 19:00 (UTC)

May I suggest building cargo-c in debug mode? It cuts off a lot of compile time (and we don't need a high level of optimization for a build tool):

$ time cargo install --root /tmp/cinstall-release cargo-c
cargo install --root /tmp/cinstall-release cargo-c  384,17s user 6,11s system 354% cpu 1:50,10 total

$ time cargo install --debug --root /tmp/cinstall-debug cargo-c
cargo install --debug --root /tmp/cinstall-debug cargo-c  127,79s user 5,57s system 288% cpu 46,145 total

Chocobo1 commented on 2019-11-10 18:45 (UTC)

Can librav1e be added to this package (for use with ffmpeg) or would it be better to package it separately?

Updated the package, now it should produce the library.

gmes78 commented on 2019-11-10 16:39 (UTC)

Can librav1e be added to this package (for use with ffmpeg) or would it be better to package it separately?

Chocobo1 commented on 2018-08-02 16:19 (UTC)

Needs checkdepends=('python'), otherwise tests will fail in clean chroot.

Thanks, fixed.

xiretza commented on 2018-08-02 14:46 (UTC)

Needs checkdepends=('python'), otherwise tests will fail in clean chroot.

« First ‹ Previous 1 2 3 4 Next › Last »