Skip to content

Conversation

@y-guyon
Copy link
Contributor

@y-guyon y-guyon commented Oct 28, 2021

The AVIF parser is a standalone library that can be used to extract
the width, height, bit depth and number of channels from an AVIF
payload. The code is kept short enough to be used by applications that
cannot link to the whole libavif library.

The AVIF parser is a standalone library that can be used to extract
the width, height, bit depth and number of channels from an AVIF
payload. The code is kept short enough to be used by applications that
cannot link to the whole libavif library.
@joedrago
Copy link
Contributor

Hello --

Putting aside an audit of the actual code's design/flow/accuracy for a secondary discussion, I'm not convinced yet that it makes sense for this code to live in the contrib/ directory of libavif at all, honestly. Its entire existence is to be a lightweight alternative to libavif, if your only goal is to get a few pieces of data (dimensions/depth/hasAlpha) out of a valid AVIF. I don't know why implementers that would prefer to use this over libavif (as they only need the subset of info this provides) would want to have to clone all of libavif and be subject to libavif's build environment to get it. I don't know why this code would similarly want to be subject to libavif's PR process and release schedule, either.

This would make way more sense in its own git repository. It interacts in no way with libavif, benefits in no way from its build environment, and users of it clearly don't want the other parts of libavif in their build or on their disk. Why put it in here?

@y-guyon
Copy link
Contributor Author

y-guyon commented Oct 29, 2021

This code is in contrib because:

  • It is heavily related to libavif,
  • It seemed faster and simpler than creating a new repo,
  • The intent was to just create some code snippet that can be easily copy-pasted, even from GitHub Web UI. No need to clone the repo.

I added a test and CMakeLists.txt for several reasons: to show usage examples, to show how to build it/include it, and maybe in the future to enable it in a libavif presubmit workflow.

With that being said, I do not mind at all moving it to a new repository. It even has some advantages that you mentioned. Do you know how to create one? I guess AOMediaCodec would be the best parent.

@tongyuantongyu
Copy link
Contributor

Maybe a bit off-topic, but I'd like to have a muxer&demuxer API for AVIF file, to allow customized AVIF creating/parsing logic (including simple ones like read some basic info and stop, and also complicated ones like write progressive grid with custom interleaving), like the APIs libwebp provided through its libwebpmux and libwebpdemux libraries (they are also quite smaller than the encoder/decoder libraries).

@joedrago
Copy link
Contributor

It is heavily related to libavif,

It is related to AVIF, but certainly not libavif. To be clear, I was not suggesting it belongs a new AOMediaCodec repo either, simply in its own repo elsewhere (perhaps y-guyon/avifparser). I think having a second AOMediaCodec C AVIF library repository that is completely disconnected from libavif would make for quite a bit of confusion. Which should someone use? Do they need both? Does one depend on the other?

To stay within the context of this PR, we're in agreement that this doesn't belong in this repo, so I will be closing this PR.

(I think it might be worth pursuing whether or not it makes sense for libavif's Parse() functions to work in the absence of any linked in AV1 codecs and/or offer the kind of muxing support @tongyuantongyu , but that should be discussed elsewhere.)

@joedrago joedrago closed this Oct 29, 2021
@y-guyon
Copy link
Contributor Author

y-guyon commented Nov 3, 2021

Thanks. To avoid the confusion you mentioned, a new repository was opened elsewhere:
https://aomedia.googlesource.com/libavifinfo/

The commit is sent for review, if you would like to take a look:
https://aomedia-review.googlesource.com/c/libavifinfo/+/148321
There is a sentence in the README.md describing when to use libavifinfo over libavif.
It is also specified that libavifinfo is a standalone.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants