Review for Source Package: dav1d
[Summary]
MIR team ACK under the constraint to help with the below listed
recommended TODOs (no required ones in this case).
This does need a security review, so I'll assign ubuntu-security
List of specific binary packages to be promoted to main: libdav1d7,
libdav1d-dev
Specific binary packages built, but NOT to be promoted to main: dav1d
(not forbidden, but no need to)
Notes:
Recommended TODOs:
- #1 - for promoting dav1d we should demote aom, please have a look
if we could change (not strictly needed as they are alternatives)
the ordering from libheif. But in any case help along this
to demote aom afterwards. That will not only be a clear
signal towards dav1d, but also avoid maintaining two libs in main
with so similar function. The old MIR was postponed, but I think the
time is right to switch over for resolute.
- #2 - The package should get a team bug subscriber before being
promoted (you are already aware that won't be a problem)
- #3 - Isn't this an ideal case to ship some known-working files as dep8 tests
and let them en/de-code for an autopkgtest? In general adding one would
be awesome. More considerations about that below.
[Rationale, Duplication and Ownership]
There is no other package in main providing the same functionality (since we'd
demote aom along that change).
A team is committed to own long term maintenance of this package.
The rationale given in the report seems valid and useful for Ubuntu (I think I
had to convince myself by some research as there was not that much in the
report, but that is fine).
The duplication question is probably the most crucial aspect to discuss in this
case. Let me elaborate on that a bit.
As I understand there is the following related trio: libavif + libdav1d + libaom
Of these libavif16 is an abstraction for handling image files and can use
either libdav1d7 or libaom3 to do so. Therefore libavif16 is only a bystander
representing the non-video but image use-cases, but not hard-forcing either.
More intersting is the difference between libdav1d and libaom.
Let me outline what I found by the seraches I've done comparing the two.
Pro-dav1d
- dav1d is faster, consumes less memory and less cpu as well as utilizing
more acceleration methods.
- This is actually funded by the AOM alliance to be the good implementation
and therefore will further outperform aom itself.
- The AOM Codebase is large and complex as it was originally designed for
research rather than pure performance. It remains the standard for
compatibility and correctness, but its development is slower due to its
size and legacy codebase.
Pro-AOM
- If we aim for maximum compatibility or are working with 10/12-bit content,
libaom remains a solid choice for now.
TL;DR: we'd want to pick dav1d for any case except perfect spec
compatibility.
I think it makes sense to switch to dav1d wherever we can for being the better
general choice. Ideally that can be done far enough to keep aom around, but
let it drop out of main.
Looking at the current users:
reverse-depends --release resolute src:aom
Reverse-Depends
===============
* gstreamer1.0-plugins-bad (for libaom3)
* libavcodec-extra61 (for libaom3)
* libavcodec61 (for libaom3)
* libavif-dev (for libaom-dev)
* libavif16 (for libaom3)
* libheif-plugin-aomdec (for libaom3)
* libheif-plugin-aomenc (for libaom3)
* librust-aom-sys-dev [amd64 amd64v3 arm64 armhf ppc64el riscv64 s390x]
Of these only libheif is in main right now, so switching that would be enough.
https://github.com/strukturag/libheif states "... For AVIF, libaom, dav1d,
svt-av1, or rav1e are used as codecs".
There already is `libheif-plugin-dav1d`
And libheif already has:
Depends: libc6 (>= 2.38), libgcc-s1 (>= 3.3.1), libsharpyuv0 (>= 1.5.0),
libstdc++6 (>= 13.1), zlib1g (>= 1:1.1.4), libheif-plugin-aomdec (=
1.20.2-2build1) | libheif-plugin-dav1d (= 1.20.2-2build1),
libheif-plugin-libde265 (= 1.20.2-2build1)
Recommends: libheif-plugin-aomenc (= 1.20.2-2build1)
Suggests: libheif-plugin-x265 (= 1.20.2-2build1), libheif-plugin-ffmpegdec (=
1.20.2-2build1), libheif-plugin-jpegdec (= 1.20.2-2build1),
libheif-plugin-jpegenc (= 1.20.2-2build1), libheif-plugin-j2kdec (=
1.20.2-2build1), libheif-plugin-j2kenc (= 1.20.2-2build1),
libheif-plugin-kvazaar (= 1.20.2-2build1), libheif-plugin-rav1e (=
1.20.2-2build1), libheif-plugin-svtenc (= 1.20.2-2build1)
So they are equal resolutions to the dependency.
Ideally you might turn this around to make the order preference represent
the ecosystem "we should prefer dav1d", but that is optional.
[Dependencies]
OK:
- no other runtime Dependencies to MIR due to this
- no other build-time Dependencies with active code in the final binaries
to MIR due to this
- no -dev/-debug/-doc packages that need exclusion (the one it has is save)
- No dependencies in main that are only superficially tested requiring
more tests now.
Problems: None
[Embedded sources and static linking]
OK:
- no embedded source present
- no static linking
- does not have unexpected Built-Using entries
- not a go package, no extra constraints to consider in that regard
- not a rust package, no extra constraints to consider in that regard
- Does not include vendored code
Problems: None
[Security]
OK:
- history of CVEs does not look concerning
- does not run a daemon as root
- does not use webkit1,2
- does not use lib*v8 directly
- does not expose any external endpoint (port/socket/... or similar)
- does not use centralized online accounts
- does not integrate arbitrary javascript into the desktop
- does not deal with system authentication (eg, pam), etc)
- does not deal with security attestation (secure boot, tpm, signatures)
- does not deal with cryptography (en-/decryption, certificates,
signing, ...)
- this makes appropriate (for its exposure) use of established risk
mitigation features (as a lib this is delegated to the actual use cases)
Problems:
- does parse data formats (video and images)
- might process arbitrary web content
=> We need a security review, but that was to be expected.
[Common blockers]
OK:
- does not FTBFS currently
- test suite fails will fail the build upon error.
- no new python2 dependency
Problems:
- Does not have a non-trivial test suite that runs as autopkgtest.
The lib supports so many accelaration options (good) that real tests
will always only cover some, but I'd consider that sufficient and better
than using that argument to not add automated tests at all.
As with many libs you may consider doing that where they are used,
libavif has nothing yet libheif tests heic & avif image decoding.
A few more of these and some short videos might help further.
But TBH it seems the dav1d tool itself calls to be used for exactly that
in tests - known in/out content. Complexity - comparing videos as I'm
not sure it can be perfectly deterministic.
[Packaging red flags]
OK:
- Ubuntu does not carry a delta
- symbols tracking is in place.
- debian/watch is present and looks ok
- Upstream update history is good
- Debian/Ubuntu update history is good
- the current release is packaged
- promoting this does not seem to cause issues for MOTUs that so far
maintained the package
- no massive Lintian warnings
- debian/rules is rather clean
- It is not on the lto-disabled list
Problems: None
[Upstream red flags]
OK:
- no Errors/warnings during the build
- no incautious use of malloc/sprintf (as far as we can check it)
- no use of sudo, gksu, pkexec, or LD_LIBRARY_PATH (usage is OK inside
tests)
- no use of user 'nobody' outside of tests
- no use of setuid / setgid
- no important open bugs (crashers, etc) in Debian or Ubuntu
- no dependency on webkit, qtwebkit or libseed
- not part of the UI for extra checks
- no translation present, but none needed for this case (not user visible)
Problems: None
** Changed in: dav1d (Ubuntu)
Assignee: Christian Ehrhardt (paelzer) => Ubuntu Security Team
(ubuntu-security)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2133757
Title:
[MIR] dav1d (transitive depends of libavif -> pillow)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/dav1d/+bug/2133757/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
