diff mbox series

[FFmpeg-devel,2/2] avformat/mov: Support parsing of still AVIF Alpha Channel

Message ID 20220630210434.1551769-2-vigneshv@google.com
State New
Headers show
Series [FFmpeg-devel,1/2] avformat/mov: Rework the AVIF parser to handle multiple items | expand

Checks

Context Check Description
yinshiyou/make_loongarch64 success Make finished
yinshiyou/make_fate_loongarch64 success Make fate finished
andriy/make_x86 success Make finished
andriy/make_fate_x86 success Make fate finished
andriy/make_armv7_RPi4 success Make finished
andriy/make_fate_armv7_RPi4 success Make fate finished

Commit Message

Vignesh Venkatasubramanian June 30, 2022, 9:04 p.m. UTC
Parse the alpha channel for still AVIF images and expose it as a
separate track. This is the simplest way of supporting AVIF alpha
channel in a codec independent manner (similar to how ffmpeg
supports animated AVIF with alpha channel).

One can use the alphamerge filter to get a transparent image with
a single command. For example:

ffmpeg -i image_with_alpha.avif -filter_complex alphamerge image_with_alpha.png

Signed-off-by: Vignesh Venkatasubramanian <vigneshv@google.com>
---
 libavformat/isom.h |  1 +
 libavformat/mov.c  | 66 ++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 67 insertions(+)

Comments

Anton Khirnov July 2, 2022, 9:34 a.m. UTC | #1
Quoting Vignesh Venkatasubramanian (2022-06-30 23:04:34)
> Parse the alpha channel for still AVIF images and expose it as a
> separate track. This is the simplest way of supporting AVIF alpha
> channel in a codec independent manner (similar to how ffmpeg
> supports animated AVIF with alpha channel).
> 
> One can use the alphamerge filter to get a transparent image with
> a single command. For example:
> 
> ffmpeg -i image_with_alpha.avif -filter_complex alphamerge image_with_alpha.png
> 
> Signed-off-by: Vignesh Venkatasubramanian <vigneshv@google.com>
> ---
>  libavformat/isom.h |  1 +
>  libavformat/mov.c  | 66 ++++++++++++++++++++++++++++++++++++++++++++++
>  2 files changed, 67 insertions(+)

I am against this patch, this is a digusting hack.

These are not two streams, it is a single stream and should be exposed
as such.
Vignesh Venkatasubramanian July 2, 2022, 4:32 p.m. UTC | #2
On Sat, Jul 2, 2022 at 2:35 AM Anton Khirnov <anton@khirnov.net> wrote:
>
> Quoting Vignesh Venkatasubramanian (2022-06-30 23:04:34)
> > Parse the alpha channel for still AVIF images and expose it as a
> > separate track. This is the simplest way of supporting AVIF alpha
> > channel in a codec independent manner (similar to how ffmpeg
> > supports animated AVIF with alpha channel).
> >
> > One can use the alphamerge filter to get a transparent image with
> > a single command. For example:
> >
> > ffmpeg -i image_with_alpha.avif -filter_complex alphamerge image_with_alpha.png
> >
> > Signed-off-by: Vignesh Venkatasubramanian <vigneshv@google.com>
> > ---
> >  libavformat/isom.h |  1 +
> >  libavformat/mov.c  | 66 ++++++++++++++++++++++++++++++++++++++++++++++
> >  2 files changed, 67 insertions(+)
>
> I am against this patch, this is a digusting hack.
>
> These are not two streams, it is a single stream and should be exposed
> as such.
>

Yes, while it is a hack, it is also the simplest way of supporting
AVIF images with alpha. Since AVIF alpha images require two separate
decoders, i could not think of any other solution that does not
involve modifying the underlying av1 codec itself.

If there are any alternative solutions where we can expose a single
stream that needs two codecs, then i am open to implementing that.

Otherwise, this solution improves the current situation where there is
no way for the user to extract the alpha channel (albeit in a hacky
way).

> --
> Anton Khirnov
Jan Ekström July 2, 2022, 7:34 p.m. UTC | #3
On Sat, Jul 2, 2022 at 7:32 PM Vignesh Venkatasubramanian
<vigneshv-at-google.com@ffmpeg.org> wrote:
>
> On Sat, Jul 2, 2022 at 2:35 AM Anton Khirnov <anton@khirnov.net> wrote:
> >
> > Quoting Vignesh Venkatasubramanian (2022-06-30 23:04:34)
> > > Parse the alpha channel for still AVIF images and expose it as a
> > > separate track. This is the simplest way of supporting AVIF alpha
> > > channel in a codec independent manner (similar to how ffmpeg
> > > supports animated AVIF with alpha channel).
> > >
> > > One can use the alphamerge filter to get a transparent image with
> > > a single command. For example:
> > >
> > > ffmpeg -i image_with_alpha.avif -filter_complex alphamerge image_with_alpha.png
> > >
> > > Signed-off-by: Vignesh Venkatasubramanian <vigneshv@google.com>
> > > ---
> > >  libavformat/isom.h |  1 +
> > >  libavformat/mov.c  | 66 ++++++++++++++++++++++++++++++++++++++++++++++
> > >  2 files changed, 67 insertions(+)
> >
> > I am against this patch, this is a digusting hack.
> >
> > These are not two streams, it is a single stream and should be exposed
> > as such.
> >
>
> Yes, while it is a hack, it is also the simplest way of supporting
> AVIF images with alpha. Since AVIF alpha images require two separate
> decoders, i could not think of any other solution that does not
> involve modifying the underlying av1 codec itself.
>
> If there are any alternative solutions where we can expose a single
> stream that needs two codecs, then i am open to implementing that.
>
> Otherwise, this solution improves the current situation where there is
> no way for the user to extract the alpha channel (albeit in a hacky
> way).

I have discussed this on IRC, and as far as I can see we have multiple
cases where an additional image has to be decoded by a separate
decoder context to get alpha, namely:

- vp8/9 (currently handled by AV_PKT_DATA_MATROSKA_BLOCKADDITIONAL)
- HEIF-like formats (such as AVIF), which are codec agnostic (you can
put JPEG, HEVC, AV1 etc into HEIF)

This means the logic (preferably) should not be codec-specific, and
would allow to implement at least two separate

My proposal - which Anton didn't really like - was to add a side data
entry AV_PKT_DATA_AUXILIARY_IMAGE , which could have type (ALPHA,
DEPTH etc) as well as the relevant packet(s) - as well as if any of
specifications define codec initialization data, that. Then
libavcodec/decode or so could initialize a secondary decoder context
for alpha images and add the third plane if parameters match what's
required.

This would also make remux possible, since containers that do not
support such auxiliary images would ignore the alpha plane, and those
that do would properly pass it through.

As for encoding, not fully sure how it should be integrated, if any
encoders actually at this moment do proper alpha coding, or do all API
clients have to separately encode with one context the primary image,
and the alpha with another? That said, the multi-stream implementation
is already merged on the muxer side, so that can be utilized in the
mean time, even though the auxiliary images are not technically a
separate stream within HEIF-likes.

Jan
Vignesh Venkatasubramanian July 2, 2022, 9:15 p.m. UTC | #4
On Sat, Jul 2, 2022 at 12:35 PM Jan Ekström <jeebjp@gmail.com> wrote:
>
> On Sat, Jul 2, 2022 at 7:32 PM Vignesh Venkatasubramanian
> <vigneshv-at-google.com@ffmpeg.org> wrote:
> >
> > On Sat, Jul 2, 2022 at 2:35 AM Anton Khirnov <anton@khirnov.net> wrote:
> > >
> > > Quoting Vignesh Venkatasubramanian (2022-06-30 23:04:34)
> > > > Parse the alpha channel for still AVIF images and expose it as a
> > > > separate track. This is the simplest way of supporting AVIF alpha
> > > > channel in a codec independent manner (similar to how ffmpeg
> > > > supports animated AVIF with alpha channel).
> > > >
> > > > One can use the alphamerge filter to get a transparent image with
> > > > a single command. For example:
> > > >
> > > > ffmpeg -i image_with_alpha.avif -filter_complex alphamerge image_with_alpha.png
> > > >
> > > > Signed-off-by: Vignesh Venkatasubramanian <vigneshv@google.com>
> > > > ---
> > > >  libavformat/isom.h |  1 +
> > > >  libavformat/mov.c  | 66 ++++++++++++++++++++++++++++++++++++++++++++++
> > > >  2 files changed, 67 insertions(+)
> > >
> > > I am against this patch, this is a digusting hack.
> > >
> > > These are not two streams, it is a single stream and should be exposed
> > > as such.
> > >
> >
> > Yes, while it is a hack, it is also the simplest way of supporting
> > AVIF images with alpha. Since AVIF alpha images require two separate
> > decoders, i could not think of any other solution that does not
> > involve modifying the underlying av1 codec itself.
> >
> > If there are any alternative solutions where we can expose a single
> > stream that needs two codecs, then i am open to implementing that.
> >
> > Otherwise, this solution improves the current situation where there is
> > no way for the user to extract the alpha channel (albeit in a hacky
> > way).
>
> I have discussed this on IRC,

Thank you for discussing this!

> and as far as I can see we have multiple
> cases where an additional image has to be decoded by a separate
> decoder context to get alpha, namely:
>
> - vp8/9 (currently handled by AV_PKT_DATA_MATROSKA_BLOCKADDITIONAL)
> - HEIF-like formats (such as AVIF), which are codec agnostic (you can
> put JPEG, HEVC, AV1 etc into HEIF)
>
> This means the logic (preferably) should not be codec-specific, and
> would allow to implement at least two separate
>
> My proposal - which Anton didn't really like - was to add a side data
> entry AV_PKT_DATA_AUXILIARY_IMAGE , which could have type (ALPHA,
> DEPTH etc) as well as the relevant packet(s) - as well as if any of
> specifications define codec initialization data, that. Then
> libavcodec/decode or so could initialize a secondary decoder context
> for alpha images and add the third plane if parameters match what's
> required.
>

My only concern about this solution is that, while the demuxer can
easily put the alpha data in the side data, we will then have to
modify the decoder (in case of HEIF, we will have to change each
underlying codec like av1, hevc, jpeg, etc) to support handling of
this side data. I was just hoping it would be nicer if we can have
something simpler without having to change every individual libavcodec
implementation. ffmpeg already has a way to cleanly initialize codecs
and pass data to them, so it would be nicer if we can leverage that
somehow instead of making each libavcodec implementation handle this
side data type.

For example, the proposed solution is what we do for the VP8 alpha
demuxing and there is already some fragmentation. The libvpx based vp8
decoder supports alpha channel decoding while the native ffmpeg vp8
decoder does not support it. So, a user has to explicitly pass -c:v
libvpx-vp8 to be able to decode files with alpha channel properly.

> This would also make remux possible, since containers that do not
> support such auxiliary images would ignore the alpha plane, and those
> that do would properly pass it through.
>

The remux is possible in the multi-stream approach/hack as well. But I
do see your point.

> As for encoding, not fully sure how it should be integrated, if any
> encoders actually at this moment do proper alpha coding, or do all API
> clients have to separately encode with one context the primary image,
> and the alpha with another?

I am not sure about other codecs, but in the case of AVIF/AV1, the
encoder does not understand/support alpha channels. The only way to do
it is to use two separate encoders.

> That said, the multi-stream implementation
> is already merged on the muxer side, so that can be utilized in the
> mean time, even though the auxiliary images are not technically a
> separate stream within HEIF-likes.
>
> Jan
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
Jan Ekström July 3, 2022, 12:17 p.m. UTC | #5
On Sun, Jul 3, 2022 at 12:15 AM Vignesh Venkatasubramanian
<vigneshv-at-google.com@ffmpeg.org> wrote:
>
> On Sat, Jul 2, 2022 at 12:35 PM Jan Ekström <jeebjp@gmail.com> wrote:
> >
> > On Sat, Jul 2, 2022 at 7:32 PM Vignesh Venkatasubramanian
> > <vigneshv-at-google.com@ffmpeg.org> wrote:
> > >
> > > On Sat, Jul 2, 2022 at 2:35 AM Anton Khirnov <anton@khirnov.net> wrote:
> > > >
> > > > Quoting Vignesh Venkatasubramanian (2022-06-30 23:04:34)
> > > > > Parse the alpha channel for still AVIF images and expose it as a
> > > > > separate track. This is the simplest way of supporting AVIF alpha
> > > > > channel in a codec independent manner (similar to how ffmpeg
> > > > > supports animated AVIF with alpha channel).
> > > > >
> > > > > One can use the alphamerge filter to get a transparent image with
> > > > > a single command. For example:
> > > > >
> > > > > ffmpeg -i image_with_alpha.avif -filter_complex alphamerge image_with_alpha.png
> > > > >
> > > > > Signed-off-by: Vignesh Venkatasubramanian <vigneshv@google.com>
> > > > > ---
> > > > >  libavformat/isom.h |  1 +
> > > > >  libavformat/mov.c  | 66 ++++++++++++++++++++++++++++++++++++++++++++++
> > > > >  2 files changed, 67 insertions(+)
> > > >
> > > > I am against this patch, this is a digusting hack.
> > > >
> > > > These are not two streams, it is a single stream and should be exposed
> > > > as such.
> > > >
> > >
> > > Yes, while it is a hack, it is also the simplest way of supporting
> > > AVIF images with alpha. Since AVIF alpha images require two separate
> > > decoders, i could not think of any other solution that does not
> > > involve modifying the underlying av1 codec itself.
> > >
> > > If there are any alternative solutions where we can expose a single
> > > stream that needs two codecs, then i am open to implementing that.
> > >
> > > Otherwise, this solution improves the current situation where there is
> > > no way for the user to extract the alpha channel (albeit in a hacky
> > > way).
> >
> > I have discussed this on IRC,
>
> Thank you for discussing this!
>
> > and as far as I can see we have multiple
> > cases where an additional image has to be decoded by a separate
> > decoder context to get alpha, namely:
> >
> > - vp8/9 (currently handled by AV_PKT_DATA_MATROSKA_BLOCKADDITIONAL)
> > - HEIF-like formats (such as AVIF), which are codec agnostic (you can
> > put JPEG, HEVC, AV1 etc into HEIF)
> >
> > This means the logic (preferably) should not be codec-specific, and
> > would allow to implement at least two separate
> >
> > My proposal - which Anton didn't really like - was to add a side data
> > entry AV_PKT_DATA_AUXILIARY_IMAGE , which could have type (ALPHA,
> > DEPTH etc) as well as the relevant packet(s) - as well as if any of
> > specifications define codec initialization data, that. Then
> > libavcodec/decode or so could initialize a secondary decoder context
> > for alpha images and add the third plane if parameters match what's
> > required.
> >
>
> My only concern about this solution is that, while the demuxer can
> easily put the alpha data in the side data, we will then have to
> modify the decoder (in case of HEIF, we will have to change each
> underlying codec like av1, hevc, jpeg, etc) to support handling of
> this side data. I was just hoping it would be nicer if we can have
> something simpler without having to change every individual libavcodec
> implementation. ffmpeg already has a way to cleanly initialize codecs
> and pass data to them, so it would be nicer if we can leverage that
> somehow instead of making each libavcodec implementation handle this
> side data type.

Yes This is why I specifically noted that general decode logic should
be modified, not separate decoders. Just like the recent ICC profile
<-> color space information patch set by Niklas.

It is clearly a thing that is going to get utilized by multiple
things, so having it specific to specific codecs makes no sense :) .

Jan
Vignesh Venkatasubramanian July 3, 2022, 4:52 p.m. UTC | #6
On Sun, Jul 3, 2022 at 5:18 AM Jan Ekström <jeebjp@gmail.com> wrote:
>
> On Sun, Jul 3, 2022 at 12:15 AM Vignesh Venkatasubramanian
> <vigneshv-at-google.com@ffmpeg.org> wrote:
> >
> > On Sat, Jul 2, 2022 at 12:35 PM Jan Ekström <jeebjp@gmail.com> wrote:
> > >
> > > On Sat, Jul 2, 2022 at 7:32 PM Vignesh Venkatasubramanian
> > > <vigneshv-at-google.com@ffmpeg.org> wrote:
> > > >
> > > > On Sat, Jul 2, 2022 at 2:35 AM Anton Khirnov <anton@khirnov.net> wrote:
> > > > >
> > > > > Quoting Vignesh Venkatasubramanian (2022-06-30 23:04:34)
> > > > > > Parse the alpha channel for still AVIF images and expose it as a
> > > > > > separate track. This is the simplest way of supporting AVIF alpha
> > > > > > channel in a codec independent manner (similar to how ffmpeg
> > > > > > supports animated AVIF with alpha channel).
> > > > > >
> > > > > > One can use the alphamerge filter to get a transparent image with
> > > > > > a single command. For example:
> > > > > >
> > > > > > ffmpeg -i image_with_alpha.avif -filter_complex alphamerge image_with_alpha.png
> > > > > >
> > > > > > Signed-off-by: Vignesh Venkatasubramanian <vigneshv@google.com>
> > > > > > ---
> > > > > >  libavformat/isom.h |  1 +
> > > > > >  libavformat/mov.c  | 66 ++++++++++++++++++++++++++++++++++++++++++++++
> > > > > >  2 files changed, 67 insertions(+)
> > > > >
> > > > > I am against this patch, this is a digusting hack.
> > > > >
> > > > > These are not two streams, it is a single stream and should be exposed
> > > > > as such.
> > > > >
> > > >
> > > > Yes, while it is a hack, it is also the simplest way of supporting
> > > > AVIF images with alpha. Since AVIF alpha images require two separate
> > > > decoders, i could not think of any other solution that does not
> > > > involve modifying the underlying av1 codec itself.
> > > >
> > > > If there are any alternative solutions where we can expose a single
> > > > stream that needs two codecs, then i am open to implementing that.
> > > >
> > > > Otherwise, this solution improves the current situation where there is
> > > > no way for the user to extract the alpha channel (albeit in a hacky
> > > > way).
> > >
> > > I have discussed this on IRC,
> >
> > Thank you for discussing this!
> >
> > > and as far as I can see we have multiple
> > > cases where an additional image has to be decoded by a separate
> > > decoder context to get alpha, namely:
> > >
> > > - vp8/9 (currently handled by AV_PKT_DATA_MATROSKA_BLOCKADDITIONAL)
> > > - HEIF-like formats (such as AVIF), which are codec agnostic (you can
> > > put JPEG, HEVC, AV1 etc into HEIF)
> > >
> > > This means the logic (preferably) should not be codec-specific, and
> > > would allow to implement at least two separate
> > >
> > > My proposal - which Anton didn't really like - was to add a side data
> > > entry AV_PKT_DATA_AUXILIARY_IMAGE , which could have type (ALPHA,
> > > DEPTH etc) as well as the relevant packet(s) - as well as if any of
> > > specifications define codec initialization data, that. Then
> > > libavcodec/decode or so could initialize a secondary decoder context
> > > for alpha images and add the third plane if parameters match what's
> > > required.
> > >
> >
> > My only concern about this solution is that, while the demuxer can
> > easily put the alpha data in the side data, we will then have to
> > modify the decoder (in case of HEIF, we will have to change each
> > underlying codec like av1, hevc, jpeg, etc) to support handling of
> > this side data. I was just hoping it would be nicer if we can have
> > something simpler without having to change every individual libavcodec
> > implementation. ffmpeg already has a way to cleanly initialize codecs
> > and pass data to them, so it would be nicer if we can leverage that
> > somehow instead of making each libavcodec implementation handle this
> > side data type.
>
> Yes This is why I specifically noted that general decode logic should
> be modified, not separate decoders. Just like the recent ICC profile
> <-> color space information patch set by Niklas.
>

Ah okay, i see what you are saying now. This makes sense. I am also in
favor of this solution then.

We can abandon this second patch for now and i will see if i can
implement the side data based solution.

The first patch in this series is still a refactor that will be useful
for the future. So i will leave that open for review.

> It is clearly a thing that is going to get utilized by multiple
> things, so having it specific to specific codecs makes no sense :) .

Yes, sounds good!

>
> Jan
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
Anton Khirnov July 5, 2022, 4:53 p.m. UTC | #7
Quoting Vignesh Venkatasubramanian (2022-07-02 23:15:35)
> > As for encoding, not fully sure how it should be integrated, if any
> > encoders actually at this moment do proper alpha coding, or do all API
> > clients have to separately encode with one context the primary image,
> > and the alpha with another?
> 
> I am not sure about other codecs, but in the case of AVIF/AV1, the
> encoder does not understand/support alpha channels. The only way to do
> it is to use two separate encoders.

Can this not be handled in our encoder wrapper?

We should strive as much as possible to shield our callers from
codec-specific implementation details.
Vignesh Venkatasubramanian July 12, 2022, 3:17 p.m. UTC | #8
On Tue, Jul 5, 2022 at 9:54 AM Anton Khirnov <anton@khirnov.net> wrote:
>
> Quoting Vignesh Venkatasubramanian (2022-07-02 23:15:35)
> > > As for encoding, not fully sure how it should be integrated, if any
> > > encoders actually at this moment do proper alpha coding, or do all API
> > > clients have to separately encode with one context the primary image,
> > > and the alpha with another?
> >
> > I am not sure about other codecs, but in the case of AVIF/AV1, the
> > encoder does not understand/support alpha channels. The only way to do
> > it is to use two separate encoders.
>
> Can this not be handled in our encoder wrapper?
>

By encoder wrapper, you mean codec wrappers in libavcodec like
libaomenc.c right ? Yes, it is possible to do this in the encoder
wrapper by keeping multiple instances of the encoder. But each encoder
wrapper has to be updated to support it. AV1, for example, has three
different encoders that can be used as of today (aom, rav1e and
svt-av1).

> We should strive as much as possible to shield our callers from
> codec-specific implementation details.
>
> --
> Anton Khirnov
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
diff mbox series

Patch

diff --git a/libavformat/isom.h b/libavformat/isom.h
index d8b262e915..62b95b40ff 100644
--- a/libavformat/isom.h
+++ b/libavformat/isom.h
@@ -318,6 +318,7 @@  typedef struct MOVContext {
     uint32_t max_stts_delta;
     int is_still_picture_avif;
     int primary_item_id;
+    int alpha_item_id;
     int *avif_item_ids;
     int avif_item_ids_size;
     int *avif_extent_lengths;
diff --git a/libavformat/mov.c b/libavformat/mov.c
index 9df5055d4e..72b17b618d 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -4758,6 +4758,7 @@  static int mov_read_meta(MOVContext *c, AVIOContext *pb, MOVAtom atom)
             int ret;
             avio_seek(pb, -8, SEEK_CUR);
             atom.size += 8;
+            c->alpha_item_id = -1;
             ret = mov_read_default(c, pb, atom);
             if (ret < 0)
                 return ret;
@@ -4767,6 +4768,12 @@  static int mov_read_meta(MOVContext *c, AVIOContext *pb, MOVAtom atom)
                 ret = avif_add_stream(c, c->primary_item_id);
                 if (ret)
                     return ret;
+                if (c->alpha_item_id != -1) {
+                    // Add a stream for the Alpha plane.
+                    ret = avif_add_stream(c, c->alpha_item_id);
+                    if (ret)
+                        return ret;
+                }
                 // For still AVIF images, the meta box contains all the
                 // necessary information that would generally be provided by the
                 // moov box. So simply mark that we have found the moov box so
@@ -7556,6 +7563,64 @@  static int mov_read_pitm(MOVContext *c, AVIOContext *pb, MOVAtom atom)
     return atom.size;
 }
 
+static int mov_read_iprp(MOVContext *c, AVIOContext *pb, MOVAtom atom)
+{
+    int entry_count, size, version, flags;
+    int index = 0, auxC_alpha_index = -1;
+    size = avio_rb32(pb);
+    if (avio_rl32(pb) != MKTAG('i','p','c','o'))
+        return AVERROR_INVALIDDATA;
+    size -= 8;
+    while (size > 0) {
+        int sub_size, sub_type;
+        sub_size = avio_rb32(pb);
+        sub_type = avio_rl32(pb);
+        sub_size -= 8;
+        size -= sub_size + 8;
+        index++;
+        if (sub_type == MKTAG('a','u','x','C')) {
+            const char *expected_alpha_urn = "urn:mpeg:mpegB:cicp:systems:auxiliary:alpha";
+            avio_rb32(pb);  // version & flags.
+            sub_size -= 4;
+            if (sub_size >= strlen(expected_alpha_urn) + 1) {
+                char alpha_urn[44];
+                avio_read(pb, alpha_urn, 44);
+                sub_size -= 44;
+                if (!strncmp(alpha_urn, expected_alpha_urn, 44)) {
+                    auxC_alpha_index = index;
+                }
+            }
+        }
+        avio_skip(pb, sub_size);
+    }
+    if (auxC_alpha_index == -1)
+        return atom.size;
+
+    // ipma.
+    size = avio_rb32(pb);
+    if (avio_rl32(pb) != MKTAG('i','p','m','a'))
+        return AVERROR_INVALIDDATA;
+    version = avio_r8(pb);
+    flags = avio_rb24(pb);
+    entry_count = avio_rb32(pb);
+    for (int i = 0; i < entry_count; i++) {
+        int item_id, association_count;
+        item_id = (version < 1) ? avio_rb16(pb) : avio_rb32(pb);
+        association_count = avio_r8(pb);
+        for (int j = 0; j < association_count; j++) {
+            int property_index;
+            if (flags & 1)
+                property_index = avio_rb16(pb) & 0x7fff;
+            else
+                property_index = avio_r8(pb) & 0x7f;
+            if (property_index == auxC_alpha_index) {
+                c->alpha_item_id = item_id;
+            }
+        }
+    }
+    return atom.size;
+}
+
 static int mov_read_iloc(MOVContext *c, AVIOContext *pb, MOVAtom atom)
 {
     int version, offset_size, length_size, base_offset_size, index_size;
@@ -7732,6 +7797,7 @@  static const MOVParseTableEntry mov_default_parse_table[] = {
 { MKTAG('i','l','o','c'), mov_read_iloc },
 { MKTAG('p','c','m','C'), mov_read_pcmc }, /* PCM configuration box */
 { MKTAG('p','i','t','m'), mov_read_pitm },
+{ MKTAG('i','p','r','p'), mov_read_iprp },
 { 0, NULL }
 };