[MIR] libheif

Bug #1827442 reported by Steve Langasek
26
This bug affects 3 people
Affects Status Importance Assigned to Milestone
aom (Ubuntu)
Invalid
Undecided
Unassigned
dav1d (Ubuntu)
Invalid
Undecided
Unassigned
libde265 (Ubuntu)
Invalid
Undecided
Unassigned
libheif (Ubuntu)
In Progress
Undecided
Unassigned
x265 (Ubuntu)
Invalid
Undecided
Unassigned

Bug Description

[Availablity]

The package libheif is already in ubuntu/universe.
The package libheif build for the architectures it is designed to work on.
It currently builds and works for architectures:
amd64 arm64 armhf i386 ppc64el riscv64 s390x
Link to package: https://launchpad.net/ubuntu/+source/libheif

[Rationale]

- The package libheif is required in Ubuntu main for decoding
  ISO/IEC 23008-12:2017 HEIF files by libgd2 which is present in main.
- The package libheif will not generally be useful for a large part of our user
  base, but is important/helpful still because no other package in main supports
  decoding of ISO/IEC 23008-12:2017 HEIF files.
- The package libheif is a runtime dependency of package libgd2 that we already
  support.
- It would be great and useful to community/processes to have the package
  libheif in Ubuntu main, but there is no definitive deadline.

[Security]

- libheif had 4 security issues in the past:
  - https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-23109
    The github issue: https://github.com/strukturag/libheif/issues/207 is open,
    though developer comments that it was fixed in 1.7.0
  - https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-19499
    Fixed in 1.5.0
  - https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-19498
    Fixed in 1.5.0.
  - https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-11471
    Fixed in 1.5.0.
  The vulnerable versions are libheif < 1.7.0, current version 1.14.2
  Currently vulnerable packages (CVE-2020-23109) are deployed in focal and
  bionic. Jammy and up has no known vulnerabilitites.
- no `suid` or `sgid` binaries
- no executables in `/sbin` and `/usr/sbin`
- Package does not install services, timers or recurring jobs
- Packages does not open privileged ports (ports < 1024)
- Packages does contain extensions to security-sensitive software:
  the package provides HEIF image plugin which processes untrusted input

[Quality assurance – function/usage]

- The package does not work well right after install. There is a bug filed in
  debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1029668
  1.14.2 contains significant regression, HEIC can not be read using viewnoir.
- Basic test cases pass:
    apt install imagemagick
    wget https://filesamples.com/samples/image/heif/sample1.heif
    convert -verbose sample1.heif test.gif
    wget https://filesamples.com/samples/image/heic/sample1.heic
    convert -verbose sample1.heic test1.gif
  Notice, that libgd2 HEIF support is disabled.
- Compiling a sample that tries to save HEIF file produces following output
  "GD Warning: HEIF image support has been disabled"

[Quality assurance - maintenance]

- The package is maintained well in Debian/Ubuntu and has no bugs open
   - Ubuntu https://bugs.launchpad.net/ubuntu/+source/libheif/+bug
   - Debian https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=libheif
- The package has important open bugs, listing them:
  - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1014125
    Confirm CVE-2020-23109 fix
  - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1029668
    1.14.2 contains significant regression, HEIC can not be read using
    viewnoir package [confirmed in lunar].
    Downgrading to 1.13.0-1 solves the issue.
- The package does not deal with exotic hardware we cannot support

[Quality assurance – testing]

- The package does not run a test at build time because no unit tests are
  present in the repository upstream:
  https://launchpadlibrarian.net/646769183/buildlog_ubuntu-lunar-amd64.libheif_1.14.2-1_BUILDING.txt.gz
  https://github.com/strukturag/libheif
- The package does not run an autopkgtest because no autopackage tests are
  present.
  Note: upstream contains a CI script that can be adapted for autopkgtests:
  https://github.com/strukturag/libheif/blob/master/scripts/run-ci.sh

This section is not complete, as the test plan/approach for developing
autopkgtests needs to be discussed.
TODO: - The package can not be tested at build or autopktest time because TBD
TODO: to make up for that here TBD is a test plan/automation and example
TODO: test TBD (logs/scripts)

[Quality assurance - packaging]

- debian/watch is present and works BUT also get-orig-head target is present
  in debian/rules that produces a different result.
  There is no specific documentation on which method to use.
- debian/control defines a correct Maintainer field
- This package does not yield massive lintian Warnings, Errors
  https://udd.debian.org/lintian/?packages=libheif
- Please link to a recent build log of the package
  https://launchpadlibrarian.net/646769183/buildlog_ubuntu-lunar-amd64.libheif_1.14.2-1_BUILDING.txt.gz
- Please attach the full output you have got from `lintian --pedantic` as an
  extra post to this bug.
- Lintian overrides are not present
- This package relies on obsolete or about to be demoted packages
  see https://udd.debian.org/lintian/?packages=libheif, consider using
  libgdk-pixbuf-2.0-dev instead of transitional libgdk-pixbuf2.0-dev
- This package has no python2 or GTK2 dependencies
- The package will not be installed by default
- Packaging and build is easy, link to d/rules:
  https://salsa.debian.org/multimedia-team/libheif/-/blob/master/debian/rules

[UI standards]

- Application is not end-user facing (does not need translation)
- End-user applications without desktop file, not needed because application
  does not provide GUI

[Dependencies]

- There are further dependencies that are not yet in main, MIR for them
  is at:
  - aom: LP: #2004442
  - dav1d: LP: #2004446
  - libde265: LP: #2004449
  - x265: LP: #2004453

[Standards compliance]

 - This package correctly follows FHS and Debian Policy

[Maintenance/Owner]

- Owning Team will be Foundations team
- Team is already subscribed to the package
- This does not use static builds
- This does not use vendored code
- This package is not rust based

[Background information]

The Package description explains the package well
Upstream Name is libheif
Link to upstream project https://github.com/strukturag/libheif/

Tags: eoan fr-3316

CVE References

Steve Langasek (vorlon)
description: updated
Changed in libheif (Ubuntu):
status: Incomplete → New
Revision history for this message
Mathieu Trudel-Lapierre (cyphermox) wrote :

I've had a look, certainly seems fine packaging-wise; but should be looked at by the Security Team.

Changed in libheif (Ubuntu):
assignee: nobody → Ubuntu Security Team (ubuntu-security)
Revision history for this message
Steve Langasek (vorlon) wrote :

I just noticed via https://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg that libde265 wants to pull in:
 - qtbase-opensource-src (qt4)
  - qtchooser
  - double-conversion
  - qtsvg-opensource-src
  - qttranslations-opensource-src
 - libsd1.2
 - *ffmpeg*
  - zeromq3
   - norm
   - libpgm
  - libdc1394-22
  - libbs2b
  - x264
  - lilv
   - sratom
   - serd
   - sord
  - zvbi
  - libva
   - intel-vaapi-driver
   - intel-media-driver
    - intel-gmmlib
   - libset-scalar-perl
  - codec2
  - chromaprint
  - twitter-bootstrap3
  - libgsm
  - crystalhd
  - libopenmpt
  - game-music-emu
  - libvidstab
  - rubberband
  - aom
  - xvidcore
  - openjpeg2
  - libbluray
   - libaacs
    - libbdplus
  - openal-soft
   - sndio
  - shine
  - flite
  - libmysofa
  - libass

Sooo that's a huge pile of work and it's not justifiable in terms of reducing delta on the imagemagick package. I'm going to reupload imagemagick to drop the libheif build-dependency. Security feedback on the suitability of libheif is still welcome but is a low priority.

Revision history for this message
Seth Arnold (seth-arnold) wrote :

Wow, that's a pretty significant chain of deps. Thanks for pruning this one.

I had started in on libheif but not much beyond inspecting a few Coverity results. (More in the spirit of learning Coverity than inspecting libheif, I must be honest.)

I passed along the Coverity results to upstream on https://github.com/strukturag/libheif/issues/128 -- hopefully it'll be useful to them.

Thanks

Revision history for this message
Joachim Bauch (fancycode) wrote :

libde265-0 actually pulls in a lot less dependencies:
https://packages.ubuntu.com/bionic/libde265-0

The dependencies on Qt, SDL, swscale are being pulled in by the examples:
https://packages.ubuntu.com/bionic/libde265-examples

libheif only depends on libde265-0 and thus doesn't pull in the whole list of dependencies mentioned in #2

Revision history for this message
Steve Langasek (vorlon) wrote :

Joachim, thanks for bringing this to my attention. I've gone ahead and added libde265-examples to the exclusion list for main, and readded the libheif build-dep to imagemagick in order to revisit this MIR.

Seth, can this go back in the queue for security team review?

Revision history for this message
Seth Arnold (seth-arnold) wrote :

Thanks Joachim, Steve, I've removed the comment in trello saying this is on hold.

Thanks

Revision history for this message
Amr Ibrahim (amribrahim1987) wrote :

Just a question, I thought build-dependencies need not be in main any more to build packages in main. It was announced some time ago on ubuntu-devel. Am I wrong?

Revision history for this message
Steve Langasek (vorlon) wrote :

It's correct that packages do not have to be in main merely for being build dependencies. But most libraries that are build dependencies are linked against during build and become runtime dependencies.

Revision history for this message
Balint Reczey (rbalint) wrote :

This MIR keeps imagemagick out of the release pocket in the devel release.

Changed in imagemagick (Ubuntu):
status: New → Invalid
tags: added: update-excuse
Revision history for this message
Seth Arnold (seth-arnold) wrote :

Apparently this is useful for photos from iPhones.

Revision history for this message
Joachim Bauch (fancycode) wrote :
Balint Reczey (rbalint)
Changed in imagemagick (Ubuntu):
status: Invalid → Fix Released
Balint Reczey (rbalint)
Changed in imagemagick (Ubuntu):
status: Fix Released → Won't Fix
Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in libde265 (Ubuntu):
status: New → Confirmed
Changed in libheif (Ubuntu):
status: New → Confirmed
Changed in x265 (Ubuntu):
status: New → Confirmed
Balint Reczey (rbalint)
no longer affects: imagemagick (Ubuntu)
Balint Reczey (rbalint)
tags: removed: update-excuse
Revision history for this message
Seth Arnold (seth-arnold) wrote :

Here's the Coverity results on libheif. The first third of the file is all about example code. It might be nice to get those issues fixed, both to help bring the overall number of findings closer to zero, but more importantly to improve the quality of potential copy-and-paste coding.

I haven't looked at the results in any real depth.

Thanks

Revision history for this message
Seth Arnold (seth-arnold) wrote :

I forgot I already passed along the coverity results to the libheif team:
https://github.com/strukturag/libheif/issues/128

Their response is very encouraging.

Thanks

Revision history for this message
Seth Arnold (seth-arnold) wrote :

Is the libheif package still lintian clean? Using disco's lintian I get the following:

Output of lintian:
 W: libheif source: debhelper-compat-file-is-missing
 W: libheif source: package-uses-deprecated-debhelper-compat-version 1
 E: libheif source: package-uses-debhelper-but-lacks-build-depends
 W: libheif source: newer-standards-version 4.4.1 (current is 4.1.4)

This is libheif 1.6.1-1.

Thanks

Revision history for this message
Seth Arnold (seth-arnold) wrote :

Has anyone looked to see if x265 and libde265 are also required to be MIR'd for this package to be useful in its target use? There's no install time dependencies declared in the Debian packaging but it's hard for me to imagine why these libraries would be required at build in order to enable some of the functionality, unless they also influence the runtime behaviour of the library.

Thanks

Revision history for this message
Steve Langasek (vorlon) wrote :

Seth, I'm not sure how you reached the conclusion that there are "no install time dependencies declared in the Debian packaging". libheif1-1 in focal depends on both libx265-179 and libde265-0.

Revision history for this message
Seth Arnold (seth-arnold) wrote :

Thanks Steve, I'm not sure why I thought the dependencies on libx265-179 and libde265-0 were overlooked. Now that I take another look it all looks pretty normal.

Thanks

Revision history for this message
Sebastian Ramacher (s-ramacher) wrote :

> Is the libheif package still lintian clean?

Looks like that lintian is too old.

Revision history for this message
Seth Arnold (seth-arnold) wrote :

I've returned to this package, and I'm seeing enough // TODO markers that I'm starting to be concerned that this library implements sufficient functionality to be useful for us. The code that's there mostly looks good, but there's enough markers for "handle errors" and "find out .." that I'm wondering if enough of this is useful for the things we want it for.

Has it been used and found useful?

Thanks

Revision history for this message
Steve Langasek (vorlon) wrote : Re: [Bug 1827442] Re: [MIR] libheif

On Wed, Feb 26, 2020 at 04:02:33AM -0000, Seth Arnold wrote:
> Has it been used and found useful?

Not by me. This was pulled into Ubuntu automatically via Debian.

Revision history for this message
Seth Arnold (seth-arnold) wrote :

I reviewed libheif 1.6.1-1 as checked into focal. This shouldn't be
considered a full audit but rather a quick gauge of maintainability.

libheif is an image codec library necessary for decoding photos from some
newer phones.

- CVE History:
  - CVE-2019-11471, our database says still unfixed in 18.04 LTS.
- Build-Depends: debhelper-compat, libde265-dev, libgdk-pixbuf2.0-dev,
  libjpeg-dev, libpng-dev, libx265-dev, pkg-config
- no pre/post inst/rm scripts
- no init scripts
- no systemd units
- no dbus services
- no setuid binaries
- binaries in PATH
  - heif-thumbnailer in heif-thumbnailer
  - heif-convert, heif-enc, heif-info in libheif-examples
- no sudo fragments
- no udev rules
- There are some very thin unit tests. No autopkgtests. THere's some
  support for fuzzers but I don't see it used.
- no cron jobs
- relatively clean build logs

- no processes spawned
- significant memory management and C-style manipulation of data. Most
  calls looked like there were checks in place, but this level of C-style
  memory manipulation probably has errors.
- No file IO in library, only in examples
- Very little human logging; looked fine
- No environment variable usage
- No use of privileged functions
- No cryptography
- No temp files
- No networking
- No webkit
- No polkit

- cppcheck false positive
- an earlier look found some coverity issues, which the team addressed

Here's a list of the small handful of things I noticed:

In convert_libde265_image_to_heif_image() what constrains stride to
reasonable values? I get lost reading libde265 code to find the stride.

setjmp() used for error handling in example code; this kind of error
handling is very difficult to use correctly over time.

Y4MEncoder::Encode() doesn't appear to guard against integer overflow in
fwrite() calls

Box_iloc::write_mdat_after_iloc() 4gig outputs unhandled

I'm not sure the consequences of any of these issues.

Code quality looked goodh, especially for a codec library; the examples didn't
look as good, but this is common.

Security team ACK for promoting the libheif library packages libheif1 and
heif-gdk-pixbuf to main. I'd like to keep the examples in heif-thumbnailer
and libheif-examples in universe.

Thanks

Changed in libheif (Ubuntu):
assignee: Ubuntu Security Team (ubuntu-security) → nobody
Revision history for this message
Joachim Bauch (fancycode) wrote :

Anything we could do to help move this forward?

Revision history for this message
Dan Streetman (ddstreet) wrote :

It's unclear to me if this ever was approved by the MIR team, possibly comment 1 was intended to be a MIR team review, but it's not clear if that was the intention and certainly doesn't have the normal MIR review details.

Technically after security team review, this should have been changed to status 'In Progress' to wait for seeding updates, but I think this got 'lost' in the process since it was in state 'CONFIRMED' but the MIR team has only been looking at 'NEW' state unclaimed bugs.

@paelzer I updated the 'All open unclaimed MIR bugs' link on the MIR wiki page to show both NEW and CONFIRMED bugs, and I think we should be sure to include 'CONFIRMED' state bugs in our weekly review, not just 'NEW' state bugs.

Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

> @paelzer I updated the 'All open unclaimed MIR bugs' link on the MIR
> wiki page to show both NEW and CONFIRMED bugs, and I think we should be
> sure to include 'CONFIRMED' state bugs in our weekly review, not just
> 'NEW' state bugs.

Yeah I've got a notification about it.
I agree and thank you Dan!
I have shortened the link (same function, but omitting the defaults)
and updated also the link that we use in the weekly meeting (also on
that page, but in a different place).
Finally I have updated the state-machine info on the page to reflect
that we now also consider "Confirmed" tasks in our incoming queue.

We'll have to re-review all these cases that pop up by that, they are
all a bit fallen through the cracks by this.
Once discussed we will update each of one either assigning a
(re-)reviewer or whatever else seems to be the appropriate next step.

Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

Per comment #1 + #24 libheif is ready - updating the state.
But the dependencies are not yet looked at in depth at all.

We will need to look for it, but first we need to make sure (likely but not state explicitly yet) that someone wants to look after it.
I assume that foundations will own them, but would like to ask for a MIR-request template for x265 and libde265 in the description please.
That will also inlcude the QA-checks that the requester is supposed to do as part of [1].
Setting them to incomplete to reflect that.
Please set them back to NEW once this is ready.

Then (probably next week meeting if it is ready by the time) we assigned them for review (and if generally ok they most likely will have to go to security review as well).

[1]: https://wiki.ubuntu.com/MainInclusionProcess?action=show&redirect=MIRTeam#Filing_a_MIR_bug

Changed in libheif (Ubuntu):
status: Confirmed → In Progress
Changed in x265 (Ubuntu):
status: Confirmed → Incomplete
Changed in libde265 (Ubuntu):
status: Confirmed → Incomplete
Revision history for this message
Steve Langasek (vorlon) wrote :

imagemagick is no longer in main, so this is wontfix.

Changed in libde265 (Ubuntu):
status: Incomplete → Won't Fix
Changed in libheif (Ubuntu):
status: In Progress → Won't Fix
Changed in x265 (Ubuntu):
status: Incomplete → Won't Fix
Revision history for this message
Steve Langasek (vorlon) wrote :

libheif is now a dependency of libgd2 in lunar-proposed, so asking for reconsideration of this MIR. (For the moment I am dropping the added dependency from libgd2 to unblock it.)

Changed in libheif (Ubuntu):
status: Won't Fix → In Progress
Changed in libde265 (Ubuntu):
status: Won't Fix → Incomplete
Changed in x265 (Ubuntu):
status: Won't Fix → New
status: New → Incomplete
Revision history for this message
Lukas Märdian (slyon) wrote :

Setting the libheif status to "New", so it pops up in the correct MIR queue.

Overall, this MIR is pretty old and we'll probably want to have it updated using the new template in order to do a new review.

https://github.com/canonical/ubuntu-mir#main-inclusion-requirements

Changed in libheif (Ubuntu):
status: In Progress → New
Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

Will the mentioned "updated using the new template" come?
Marking it incomplete until done

Changed in libheif (Ubuntu):
status: New → Incomplete
Lukas Märdian (slyon)
Changed in aom (Ubuntu):
status: New → Incomplete
Changed in dav1d (Ubuntu):
status: New → Incomplete
Revision history for this message
Steve Langasek (vorlon) wrote :

> Will the mentioned "updated using the new template" come?

I guess this comment is addressed to me as the submitter. It wasn't clear to me that the previous comment was.

The MIR was already approved for libheif (though not its dependencies) before being abandoned with the determination that it was no longer needed. I don't think it's reasonable to require resubmission with fresh paperwork given that it was already approved. We aren't requiring re-review of all the other packages already in main.

Changed in libheif (Ubuntu):
status: Incomplete → In Progress
Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

Hi,
sorry for being misunderstandable.
I agree, that we do not need anything more for libheif itself (which should be in "in progress" to reflect it is ready, but no change has landed that would pull it in).

But as we all have seen its dependencies aom, dav1d, libde265, x265 are not yet processed.
They will need:
a) initial paperwork (other than rationale they usually share nothing, so they are per PKG)
b) a team that commits to own them
c) set those tasks back to "new" to enter the MIR process queue

So they are "incomplete" waiting for one to step up committing to (b) and providing (a) and doing (c) for them to enter the queue.

Revision history for this message
Dirk Farin (dirk-farin) wrote :

FYI: I have just released v1.4.0 of libheif.
A main change in that version is that it removes all dependencies (except to the new zlib dependency) and uses a dynamic plugin system.
I.e. all the codecs (aom, dav1d, ...) will be moved to separate packages.

That means that in order to have a working installation with only AVIF support, it is sufficient to install the codec package with the aom dependency.
For HEIC support, we will need the codecs with libde265 and x265.

There will also be codec plugins for dav1d, rav1e, and svt-av1, but these will be only "Suggested".

Revision history for this message
Dirk Farin (dirk-farin) wrote :

Sorry, typo: v1.14.0 is the new version

Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

That is great to know Dirk, as it would cut the recommended (and therefore required to promote) dependencies down quite a bit.
Thanks!

Fur the curious, have a look at https://github.com/strukturag/libheif/releases/tag/v1.14.0

And for the chance that one of the libs will pass and another will fail we might now make more things a suggest in Ubuntu to keep those that do not pass the checks in universe until being ok.

Revision history for this message
Oibaf (oibaf) wrote :

1.14.2-1 is now in lunar.

Revision history for this message
Steve Langasek (vorlon) wrote :

However, libheif 1.14.2-1 still has all the same dependencies.

Package: libheif1
Version: 1.14.2-1
Depends: libaom3 (>= 3.2.0), libc6 (>= 2.34), libdav1d6 (>= 0.1.0), libde265-0 (>= 1.0.7), libgcc-s1 (>= 3.3.1), libstdc++6 (>= 11), libx265-199 (>= 3.5), zlib1g (>= 1:1.1.4)

And libheif1 contains only the single libheif.so.1.14.2 object.

Did the dynamic plugin system not happen?

Revision history for this message
Steve Langasek (vorlon) wrote :

Looks like the Debian maintainer deliberately shipped these bundled instead of as plugins.

+ -DPLUGIN_DIRECTORY=/usr/lib/$(DEB_HOST_MULTIARCH)/libheif/plugins \
+ -DWITH_AOM_DECODER_PLUGIN=OFF \
+ -DWITH_AOM_ENCODER_PLUGIN=OFF \
+ -DWITH_DAV1D_PLUGIN=OFF \
+ -DWITH_DEFLATE_HEADER_COMPRESSION=ON \
+ -DWITH_LIBDE265_PLUGIN=OFF \
+ -DWITH_X265_PLUGIN=OFF

I'll reach out to Debian to see what they think about splitting these into a separate package.

Revision history for this message
Steve Langasek (vorlon) wrote :

Since it looks like the only dependency here which is genuinely optional for proper functionality of the library is dav1d, and the other dependencies are essential for decoding as mentioned in comment #35, I think we should just investigate MIR of all the dependencies as-is as a first course of action.

Revision history for this message
Joachim Bauch (fancycode) wrote :

Some plugins were still using internal APIs, causing errors while loading (see https://github.com/strukturag/libheif/issues/745). Thats why I decided to keep the Debian packaging as-is for now.

The issue will be fixed in the next version of libheif and Debian will split the packaging into individual plugin packages.

Lukas Märdian (slyon)
Changed in libgd2 (Ubuntu):
assignee: nobody → Canonical Foundations Team (canonical-foundations)
tags: added: rls-ll-incoming
Vladimir Petko (vpa1977)
tags: added: fr-3316
Revision history for this message
Vladimir Petko (vpa1977) wrote :

Differences between getting orig tar through rules vs uscan

description: updated
description: updated
Revision history for this message
Vladimir Petko (vpa1977) wrote :

No lintian output generated when running `lintian --pedantic` except distribution mismatch warning
```
 libheif1: changelog-distribution-does-not-match-changes-file unstable != kinetic [usr/share/doc/libheif1/changelog.Debian.gz:1]
W: libheif changes: distribution-and-changes-mismatch kinetic unstable

```

Vladimir Petko (vpa1977)
description: updated
Vladimir Petko (vpa1977)
description: updated
Vladimir Petko (vpa1977)
description: updated
Revision history for this message
Lukas Märdian (slyon) wrote :

See separate MIR bug reports for libheif dependencies:

- aom: bug #2004442
- dav1d: bug #2004446
- libde265: bug #2004449
- x265: bug #2004453

Changed in aom (Ubuntu):
status: Incomplete → Invalid
Changed in dav1d (Ubuntu):
status: Incomplete → Invalid
Changed in libde265 (Ubuntu):
status: Incomplete → Invalid
Changed in x265 (Ubuntu):
status: Incomplete → Invalid
no longer affects: libgd2 (Ubuntu)
Vladimir Petko (vpa1977)
description: updated
Lukas Märdian (slyon)
tags: removed: rls-ll-incoming
Revision history for this message
Mark Esler (eslerm) wrote :

Since x265 was NAKd, is this and related MIRs still valid?

libheif depends aom [0] which is incomplete. MIR and Security have conditionally ACK'd, and owning team needs to satisfy conditions.

aom depends on libyuv [1] which is incomplete. MIR team conditionally ACK'd. When conditions are satisfied by owning team, the MIR will be assigned to Security.

aom depends on libwebm [2] which Ubuntu Security will ACK soon.

libheif depends on dav1d [3] which is incomplete and not yet ready for MIR team review.

libheif depends on libde265 [4] which needs an Ubuntu Security review.

libheif depends on x265 [5] which was NACKd by Ubuntu Security.

[0] https://bugs.launchpad.net/ubuntu/+source/aom/+bug/2004442
[1] https://bugs.launchpad.net/ubuntu/+source/libyuv/+bug/2004516
[2] https://bugs.launchpad.net/ubuntu/+source/libwebm/+bug/2004523
[3] https://bugs.launchpad.net/ubuntu/+source/dav1d/+bug/2004446
[4] https://bugs.launchpad.net/ubuntu/+source/libde265/+bug/2004449
[5] https://bugs.launchpad.net/ubuntu/+source/x265/+bug/2004453

Revision history for this message
Dirk Farin (dirk-farin) wrote :

Note that libheif packaging has changed in version 1.16.2-2.
Codecs are now split out into separate plugin packages.

We now have:
- libheif1 - main library
- libheif-examples - command line tools
- libheif-dev
- heif-gdk-pixbuf
- heif-thumbnailer

and the codecs:
- libheif-plugin-aomdec - AVIF decoder (based on libaom)
- libheif-plugin-aomenc - AVIF encoder (based on libaom)
- libheif-plugin-dav1d - alternative AVIF decoder (based on dav1d)
- libheif-plugin-rav1e - alternative AVIF encoder (based on rav1e)
- libheif-plugin-svtenc - alternative AVIF encoder (based on svt-av1)

- libheif-plugin-libde265 - HEIC decoder (based on libde265)
- libheif-plugin-x265 - HEIC encoder (based on x265)

In the next release, there will also be support for "kvazaar" as an alternative HEIC encoder (instead of x265).

In order to be useful to the user:
- for AVIF support, the two codec packages based on libaom work best for me and are well maintained.
- for HEIC decoding support, the libde265 plugin package is required.

As x265 is NACKd, one could leave this out (no encoding support for HEIC) and replace this with 'kvazaar' in the future.

Revision history for this message
Mark Esler (eslerm) wrote :

Thank you @dirk-farin!

Glad to hear that kvazaar is a possible alternative. I'll run a quick audit in case we can report something to upstream early.

It looks like rust-rav1e and svt-av1 will need MIRs. For preparing Rust MIRs, please see https://wiki.ubuntu.com/RustCodeInMain

Revision history for this message
Seth Arnold (seth-arnold) wrote :

Thank you both Dirk and Mark for coming up with a single coherent view of where this is at today.

Revision history for this message
Lukas Märdian (slyon) wrote (last edit ):

Indeed, thanks for the summary. Effectively, for an MVP (libheif with HEIC decoding support), we'd need to satisfy the following depends:

* libheif-plugin-dav1d OR libheif-plugin-aomdec
=> bug #2004442 (src:aom) + bug #2004516 (src:libyuv) + bug #2004523 (src:libwebm)

* libheif-plugin-libde265
=> bug #2004449 (src:libde265)

It sounds like getting aom (and its transitive depends) MIRed should be doable, same for libde265. Everything else can be ignored for now, thanks to the new plugin architecture, and we can revisit in the future to enable more functionality/plugins.

Revision history for this message
Steve Langasek (vorlon) wrote :

On Thu, Aug 17, 2023 at 07:26:01AM -0000, Lukas Märdian wrote:
> Indeed, thanks for the summary. Effectively, for an MVP (libheif with
> HEIC encoding support), we'd need to satisfy the following depends:

I think you mean decoding support here

Revision history for this message
Lukas Märdian (slyon) wrote :

> I think you mean decoding support here

ACK, fixed.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.