[FFmpeg-devel,1/2,v3] lavf/isom: add Dolby Vision sample entry codes for HEVC and H.264

Submitted by Jan Ekström on Dec. 3, 2018, 1:19 a.m.

Details

Message ID 20181203011919.8354-1-jeebjp@gmail.com
State New
Headers show

Commit Message

Jan Ekström Dec. 3, 2018, 1:19 a.m.
From: Rodger Combs <rodger.combs@gmail.com>

These are registered identifiers at the MPEG-4 RA, which are
defined as to be utilized for Dolby Vision AVC/HEVC streams that
are not correctly presentable by standards-compliant AVC/HEVC players.

According to the Dolby Vision specification for ISOBMFF, these sample
entry codes are specified to have the standard AVC or HEVC decoder
configuration box in addition to the Dolby custom DOVIConfigurationBox.
This is what enables us to decode the streams without custom parsing.

For correct presentation information from the DOVIConfigurationBox
is required (YCbCr or modified ICtCP, SDR or HDR, base or enhancement
layer).
---
 libavformat/isom.c | 4 ++++
 1 file changed, 4 insertions(+)

Comments

Jan Ekström Dec. 5, 2018, 5:13 p.m.
On Mon, Dec 3, 2018 at 3:19 AM Jan Ekström <jeebjp@gmail.com> wrote:
>
> From: Rodger Combs <rodger.combs@gmail.com>
>
> These are registered identifiers at the MPEG-4 RA, which are
> defined as to be utilized for Dolby Vision AVC/HEVC streams that
> are not correctly presentable by standards-compliant AVC/HEVC players.
>
> According to the Dolby Vision specification for ISOBMFF, these sample
> entry codes are specified to have the standard AVC or HEVC decoder
> configuration box in addition to the Dolby custom DOVIConfigurationBox.
> This is what enables us to decode the streams without custom parsing.
>
> For correct presentation information from the DOVIConfigurationBox
> is required (YCbCr or modified ICtCP, SDR or HDR, base or enhancement
> layer).
> ---

Gentle Ping?

Jan
Jan Ekström Dec. 7, 2018, 5:34 p.m.
On Wed, Dec 5, 2018 at 7:13 PM Jan Ekström <jeebjp@gmail.com> wrote:
>
> On Mon, Dec 3, 2018 at 3:19 AM Jan Ekström <jeebjp@gmail.com> wrote:
> >
> > From: Rodger Combs <rodger.combs@gmail.com>
> >
> > These are registered identifiers at the MPEG-4 RA, which are
> > defined as to be utilized for Dolby Vision AVC/HEVC streams that
> > are not correctly presentable by standards-compliant AVC/HEVC players.
> >
> > According to the Dolby Vision specification for ISOBMFF, these sample
> > entry codes are specified to have the standard AVC or HEVC decoder
> > configuration box in addition to the Dolby custom DOVIConfigurationBox.
> > This is what enables us to decode the streams without custom parsing.
> >
> > For correct presentation information from the DOVIConfigurationBox
> > is required (YCbCr or modified ICtCP, SDR or HDR, base or enhancement
> > layer).
> > ---
>
> Gentle Ping?
>
> Jan

Ping^2?

And if nobody really cares, I will reverse the comments on the AVC
entries (since I seem to have gotten them the wrong way around when
adding the comments and commit message late at night) and apply the
set tomorrow morning. These additional identifiers and the comment
should not be affecting existing FATE samples.

Best regards,
Jan
Michael Niedermayer Dec. 9, 2018, 10:13 p.m.
On Fri, Dec 07, 2018 at 07:34:43PM +0200, Jan Ekström wrote:
> On Wed, Dec 5, 2018 at 7:13 PM Jan Ekström <jeebjp@gmail.com> wrote:
> >
> > On Mon, Dec 3, 2018 at 3:19 AM Jan Ekström <jeebjp@gmail.com> wrote:
> > >
> > > From: Rodger Combs <rodger.combs@gmail.com>
> > >
> > > These are registered identifiers at the MPEG-4 RA, which are
> > > defined as to be utilized for Dolby Vision AVC/HEVC streams that
> > > are not correctly presentable by standards-compliant AVC/HEVC players.
> > >
> > > According to the Dolby Vision specification for ISOBMFF, these sample
> > > entry codes are specified to have the standard AVC or HEVC decoder
> > > configuration box in addition to the Dolby custom DOVIConfigurationBox.
> > > This is what enables us to decode the streams without custom parsing.
> > >
> > > For correct presentation information from the DOVIConfigurationBox
> > > is required (YCbCr or modified ICtCP, SDR or HDR, base or enhancement
> > > layer).
> > > ---
> >
> > Gentle Ping?
> >
> > Jan
> 
> Ping^2?
> 
> And if nobody really cares, I will reverse the comments on the AVC
> entries (since I seem to have gotten them the wrong way around when
> adding the comments and commit message late at night) and apply the
> set tomorrow morning. These additional identifiers and the comment
> should not be affecting existing FATE samples.

probably ok, if tested and it works

thx

[...]
Jan Ekström Dec. 17, 2018, 12:58 a.m.
On Mon, Dec 10, 2018 at 12:13 AM Michael Niedermayer
<michael@niedermayer.cc> wrote:
>
> On Fri, Dec 07, 2018 at 07:34:43PM +0200, Jan Ekström wrote:
> > On Wed, Dec 5, 2018 at 7:13 PM Jan Ekström <jeebjp@gmail.com> wrote:
> > >
> > > On Mon, Dec 3, 2018 at 3:19 AM Jan Ekström <jeebjp@gmail.com> wrote:
> > > >
> > > > From: Rodger Combs <rodger.combs@gmail.com>
> > > >
> > > > These are registered identifiers at the MPEG-4 RA, which are
> > > > defined as to be utilized for Dolby Vision AVC/HEVC streams that
> > > > are not correctly presentable by standards-compliant AVC/HEVC players.
> > > >
> > > > According to the Dolby Vision specification for ISOBMFF, these sample
> > > > entry codes are specified to have the standard AVC or HEVC decoder
> > > > configuration box in addition to the Dolby custom DOVIConfigurationBox.
> > > > This is what enables us to decode the streams without custom parsing.
> > > >
> > > > For correct presentation information from the DOVIConfigurationBox
> > > > is required (YCbCr or modified ICtCP, SDR or HDR, base or enhancement
> > > > layer).
> > > > ---
> > >
> > > Gentle Ping?
> > >
> > > Jan
> >
> > Ping^2?
> >
> > And if nobody really cares, I will reverse the comments on the AVC
> > entries (since I seem to have gotten them the wrong way around when
> > adding the comments and commit message late at night) and apply the
> > set tomorrow morning. These additional identifiers and the comment
> > should not be affecting existing FATE samples.
>
> probably ok, if tested and it works
>
> thx

The specification so far has matched reality:
1. Custom MPEG-4 RA registered ID is used
2. Standard AVC or HEVC initialization data box is used (so in that
sense an implementation does not need to implement additional parsing
just to get the streams decoded)
3. Video stream itself contains no metadata, but additional
Dolby-specific box (DOVIConfigurationBox) specified in the
specification contains the actual colorimetry utilized. These custom
identifiers are mostly utilized for profile 5 of Dolby Vision, so we
cannot properly *present* the video without figuring out how ICtCt+PQ
has been mangled for Dolby Vision (which is why at this point I
wouldn't mention tickets being "fixed" by these identifiers).
4. Both VLC and Chromium added and utilize these same identifiers, as
I've posted links to them before in previous versions of this patch
set.

So as far as it's been possible to test this, that's been done and
we're just implementing things according to the specification - which
is how other projects seem to have done it as well.

Jan
Carl Eugen Hoyos Dec. 17, 2018, 1:01 a.m.
2018-12-17 1:58 GMT+01:00, Jan Ekström <jeebjp@gmail.com>:
> On Mon, Dec 10, 2018 at 12:13 AM Michael Niedermayer
> <michael@niedermayer.cc> wrote:
>>
>> On Fri, Dec 07, 2018 at 07:34:43PM +0200, Jan Ekström wrote:
>> > On Wed, Dec 5, 2018 at 7:13 PM Jan Ekström <jeebjp@gmail.com> wrote:
>> > >
>> > > On Mon, Dec 3, 2018 at 3:19 AM Jan Ekström <jeebjp@gmail.com> wrote:
>> > > >
>> > > > From: Rodger Combs <rodger.combs@gmail.com>
>> > > >
>> > > > These are registered identifiers at the MPEG-4 RA, which are
>> > > > defined as to be utilized for Dolby Vision AVC/HEVC streams that
>> > > > are not correctly presentable by standards-compliant AVC/HEVC
>> > > > players.
>> > > >
>> > > > According to the Dolby Vision specification for ISOBMFF, these
>> > > > sample
>> > > > entry codes are specified to have the standard AVC or HEVC decoder
>> > > > configuration box in addition to the Dolby custom
>> > > > DOVIConfigurationBox.
>> > > > This is what enables us to decode the streams without custom
>> > > > parsing.
>> > > >
>> > > > For correct presentation information from the DOVIConfigurationBox
>> > > > is required (YCbCr or modified ICtCP, SDR or HDR, base or
>> > > > enhancement
>> > > > layer).
>> > > > ---
>> > >
>> > > Gentle Ping?
>> > >
>> > > Jan
>> >
>> > Ping^2?
>> >
>> > And if nobody really cares, I will reverse the comments on the AVC
>> > entries (since I seem to have gotten them the wrong way around when
>> > adding the comments and commit message late at night) and apply the
>> > set tomorrow morning. These additional identifiers and the comment
>> > should not be affecting existing FATE samples.
>>
>> probably ok, if tested and it works
>>
>> thx
>
> The specification so far has matched reality:
> 1. Custom MPEG-4 RA registered ID is used
> 2. Standard AVC or HEVC initialization data box is used (so in that
> sense an implementation does not need to implement additional parsing
> just to get the streams decoded)
> 3. Video stream itself contains no metadata, but additional
> Dolby-specific box (DOVIConfigurationBox) specified in the
> specification contains the actual colorimetry utilized. These custom
> identifiers are mostly utilized for profile 5 of Dolby Vision, so we
> cannot properly *present* the video without figuring out how ICtCt+PQ
> has been mangled for Dolby Vision (which is why at this point I
> wouldn't mention tickets being "fixed" by these identifiers).
> 4. Both VLC and Chromium added and utilize these same identifiers, as
> I've posted links to them before in previous versions of this patch
> set.
>
> So as far as it's been possible to test this, that's been done

Could you point me to a dva1 sample?

> and we're just implementing things according to the specification

> - which is how other projects seem to have done it as well.

But isn't this exactly the issue?

Thank you, Carl Eugen
Jan Ekström Dec. 17, 2018, 6:58 a.m.
On Mon, Dec 17, 2018, 03:02 Carl Eugen Hoyos <ceffmpeg@gmail.com wrote:

> 2018-12-17 1:58 GMT+01:00, Jan Ekström <jeebjp@gmail.com>:
> > On Mon, Dec 10, 2018 at 12:13 AM Michael Niedermayer
> > <michael@niedermayer.cc> wrote:
> >>
> >> On Fri, Dec 07, 2018 at 07:34:43PM +0200, Jan Ekström wrote:
> >> > On Wed, Dec 5, 2018 at 7:13 PM Jan Ekström <jeebjp@gmail.com> wrote:
> >> > >
> >> > > On Mon, Dec 3, 2018 at 3:19 AM Jan Ekström <jeebjp@gmail.com>
> wrote:
> >> > > >
> >> > > > From: Rodger Combs <rodger.combs@gmail.com>
> >> > > >
> >> > > > These are registered identifiers at the MPEG-4 RA, which are
> >> > > > defined as to be utilized for Dolby Vision AVC/HEVC streams that
> >> > > > are not correctly presentable by standards-compliant AVC/HEVC
> >> > > > players.
> >> > > >
> >> > > > According to the Dolby Vision specification for ISOBMFF, these
> >> > > > sample
> >> > > > entry codes are specified to have the standard AVC or HEVC decoder
> >> > > > configuration box in addition to the Dolby custom
> >> > > > DOVIConfigurationBox.
> >> > > > This is what enables us to decode the streams without custom
> >> > > > parsing.
> >> > > >
> >> > > > For correct presentation information from the DOVIConfigurationBox
> >> > > > is required (YCbCr or modified ICtCP, SDR or HDR, base or
> >> > > > enhancement
> >> > > > layer).
> >> > > > ---
> >> > >
> >> > > Gentle Ping?
> >> > >
> >> > > Jan
> >> >
> >> > Ping^2?
> >> >
> >> > And if nobody really cares, I will reverse the comments on the AVC
> >> > entries (since I seem to have gotten them the wrong way around when
> >> > adding the comments and commit message late at night) and apply the
> >> > set tomorrow morning. These additional identifiers and the comment
> >> > should not be affecting existing FATE samples.
> >>
> >> probably ok, if tested and it works
> >>
> >> thx
> >
> > The specification so far has matched reality:
> > 1. Custom MPEG-4 RA registered ID is used
> > 2. Standard AVC or HEVC initialization data box is used (so in that
> > sense an implementation does not need to implement additional parsing
> > just to get the streams decoded)
> > 3. Video stream itself contains no metadata, but additional
> > Dolby-specific box (DOVIConfigurationBox) specified in the
> > specification contains the actual colorimetry utilized. These custom
> > identifiers are mostly utilized for profile 5 of Dolby Vision, so we
> > cannot properly *present* the video without figuring out how ICtCt+PQ
> > has been mangled for Dolby Vision (which is why at this point I
> > wouldn't mention tickets being "fixed" by these identifiers).
> > 4. Both VLC and Chromium added and utilize these same identifiers, as
> > I've posted links to them before in previous versions of this patch
> > set.
> >
> > So as far as it's been possible to test this, that's been done
>
> Could you point me to a dva1 sample?
>

I have not seen any dolby vision samples with avc in the wild. You can ask
Vittorio if he has some as he noted about possibly being able to ask for
some before.


> > and we're just implementing things according to the specification
>
> > - which is how other projects seem to have done it as well.
>
> But isn't this exactly the issue?
>

How is implementing things according to a specification "the issue"?

Jan
Jan Ekström Dec. 17, 2018, 7:39 a.m.
On Mon, Dec 17, 2018, 08:58 Jan Ekström <jeebjp@gmail.com wrote:

>
>
> On Mon, Dec 17, 2018, 03:02 Carl Eugen Hoyos <ceffmpeg@gmail.com wrote:
>
>> 2018-12-17 1:58 GMT+01:00, Jan Ekström <jeebjp@gmail.com>:
>> > On Mon, Dec 10, 2018 at 12:13 AM Michael Niedermayer
>> > <michael@niedermayer.cc> wrote:
>> >>
>> >> On Fri, Dec 07, 2018 at 07:34:43PM +0200, Jan Ekström wrote:
>> >> > On Wed, Dec 5, 2018 at 7:13 PM Jan Ekström <jeebjp@gmail.com> wrote:
>> >> > >
>> >> > > On Mon, Dec 3, 2018 at 3:19 AM Jan Ekström <jeebjp@gmail.com>
>> wrote:
>> >> > > >
>> >> > > > From: Rodger Combs <rodger.combs@gmail.com>
>> >> > > >
>> >> > > > These are registered identifiers at the MPEG-4 RA, which are
>> >> > > > defined as to be utilized for Dolby Vision AVC/HEVC streams that
>> >> > > > are not correctly presentable by standards-compliant AVC/HEVC
>> >> > > > players.
>> >> > > >
>> >> > > > According to the Dolby Vision specification for ISOBMFF, these
>> >> > > > sample
>> >> > > > entry codes are specified to have the standard AVC or HEVC
>> decoder
>> >> > > > configuration box in addition to the Dolby custom
>> >> > > > DOVIConfigurationBox.
>> >> > > > This is what enables us to decode the streams without custom
>> >> > > > parsing.
>> >> > > >
>> >> > > > For correct presentation information from the
>> DOVIConfigurationBox
>> >> > > > is required (YCbCr or modified ICtCP, SDR or HDR, base or
>> >> > > > enhancement
>> >> > > > layer).
>> >> > > > ---
>> >> > >
>> >> > > Gentle Ping?
>> >> > >
>> >> > > Jan
>> >> >
>> >> > Ping^2?
>> >> >
>> >> > And if nobody really cares, I will reverse the comments on the AVC
>> >> > entries (since I seem to have gotten them the wrong way around when
>> >> > adding the comments and commit message late at night) and apply the
>> >> > set tomorrow morning. These additional identifiers and the comment
>> >> > should not be affecting existing FATE samples.
>> >>
>> >> probably ok, if tested and it works
>> >>
>> >> thx
>> >
>> > The specification so far has matched reality:
>> > 1. Custom MPEG-4 RA registered ID is used
>> > 2. Standard AVC or HEVC initialization data box is used (so in that
>> > sense an implementation does not need to implement additional parsing
>> > just to get the streams decoded)
>> > 3. Video stream itself contains no metadata, but additional
>> > Dolby-specific box (DOVIConfigurationBox) specified in the
>> > specification contains the actual colorimetry utilized. These custom
>> > identifiers are mostly utilized for profile 5 of Dolby Vision, so we
>> > cannot properly *present* the video without figuring out how ICtCt+PQ
>> > has been mangled for Dolby Vision (which is why at this point I
>> > wouldn't mention tickets being "fixed" by these identifiers).
>> > 4. Both VLC and Chromium added and utilize these same identifiers, as
>> > I've posted links to them before in previous versions of this patch
>> > set.
>> >
>> > So as far as it's been possible to test this, that's been done
>>
>> Could you point me to a dva1 sample?
>>
>
> I have not seen any dolby vision samples with avc in the wild. You can ask
> Vittorio if he has some as he noted about possibly being able to ask for
> some before.
>
>
>> > and we're just implementing things according to the specification
>>
>> > - which is how other projects seem to have done it as well.
>>
>> But isn't this exactly the issue?
>>
>
> How is implementing things according to a specification "the issue"?
>

Also I would feel some worry if there were zero samples of it at all in the
wild. But there are samples and those follow the specification.

The fact that major projects in consumer space such as Chromium/Android
implemented this, and that the identifier was registered properly at mpeg-4
ra means that if this thing changes then it will be an inconveniece for a
lot of people. And if that happens it will be similar to the change in
lossless predictive mode of H.264, since specs can change. Any spec.

Although so far there have been zero signs of this possibly happening.

Jan

>
Carl Eugen Hoyos Dec. 17, 2018, 1:47 p.m.
2018-12-17 7:58 GMT+01:00, Jan Ekström <jeebjp@gmail.com>:
> On Mon, Dec 17, 2018, 03:02 Carl Eugen Hoyos <ceffmpeg@gmail.com wrote:
>
>> 2018-12-17 1:58 GMT+01:00, Jan Ekström <jeebjp@gmail.com>:

>> > So as far as it's been possible to test this, that's been done
>>
>> Could you point me to a dva1 sample?
>
> I have not seen any dolby vision samples with avc in the wild.
> You can ask Vittorio if he has some as he noted about
> possibly being able to ask for some before.

The patch is of course ok if Vittorio tested it with his samples.

Thank you, Carl Eugen

Patch hide | download patch | download mbox

diff --git a/libavformat/isom.c b/libavformat/isom.c
index ca9d22e4f7..f7e1654484 100644
--- a/libavformat/isom.c
+++ b/libavformat/isom.c
@@ -163,6 +163,8 @@  const AVCodecTag ff_codec_movvideo_tags[] = {
 
     { AV_CODEC_ID_HEVC, MKTAG('h', 'e', 'v', '1') }, /* HEVC/H.265 which indicates parameter sets may be in ES */
     { AV_CODEC_ID_HEVC, MKTAG('h', 'v', 'c', '1') }, /* HEVC/H.265 which indicates parameter sets shall not be in ES */
+    { AV_CODEC_ID_HEVC, MKTAG('d', 'v', 'h', 'e') }, /* HEVC-based Dolby Vision derived from hev1 */
+                                                     /* dvh1 is handled within mov.c */
 
     { AV_CODEC_ID_H264, MKTAG('a', 'v', 'c', '1') }, /* AVC-1/H.264 */
     { AV_CODEC_ID_H264, MKTAG('a', 'v', 'c', '2') },
@@ -185,6 +187,8 @@  const AVCodecTag ff_codec_movvideo_tags[] = {
     { AV_CODEC_ID_H264, MKTAG('r', 'v', '6', '4') }, /* X-Com Radvision */
     { AV_CODEC_ID_H264, MKTAG('x', 'a', 'l', 'g') }, /* XAVC-L HD422 produced by FCP */
     { AV_CODEC_ID_H264, MKTAG('a', 'v', 'l', 'g') }, /* Panasonic P2 AVC-LongG */
+    { AV_CODEC_ID_H264, MKTAG('d', 'v', 'a', 'v') }, /* AVC-based Dolby Vision derived from avc1 */
+    { AV_CODEC_ID_H264, MKTAG('d', 'v', 'a', '1') }, /* AVC-based Dolby Vision derived from avc3 */
 
     { AV_CODEC_ID_VP8,  MKTAG('v', 'p', '0', '8') }, /* VP8 */
     { AV_CODEC_ID_VP9,  MKTAG('v', 'p', '0', '9') }, /* VP9 */