[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 Accepted
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
Jan Ekström Dec. 17, 2018, 8:17 p.m.
On Mon, Dec 17, 2018 at 3:47 PM Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
>
> 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

Unfortunately I have no idea what samples Vittorio does or does not
possess, he has only mentioned off-hand that he might able to get hold
of some if required. And since you were the one requiring them, I
pointed you towards him.

For myself, I am happy with the following points regarding this:
1. The identifiers are registered at the MPEG-4 RA.
2. There is a proper specification for these mappings that is
seemingly kept up-to-date.
3. The mappings specification specifically notes that the only
difference between the AVC and HEVC identifiers are the semantics
mentioned in ISO/IEC 14496-15. We already have all of the identifiers
specified which these mappings are based upon, so those semantics
should not matter to us (and if they do, we have already broken those
constraints at this point).
4. The mapping specification specifically notes that the given AVC and
HEVC identifiers must also include the standard avcC and hvcC boxes so
that they can be decoded normally without any additional custom code.
5. We have samples for at least one of the four identifiers that
matches points 1 to 4.
6. Android, Chromium, VLC among others have already implemented these
identifiers in the same way.

Now, if you are not happy with these points, then please clearly state
that you are blocking any and all additional identifier additions - no
matter how specified - as long as there are no samples on hand for
them.

Best regards,
Jan
Carl Eugen Hoyos Dec. 17, 2018, 8:23 p.m.
2018-12-17 21:17 GMT+01:00, Jan Ekström <jeebjp@gmail.com>:
> On Mon, Dec 17, 2018 at 3:47 PM Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
>>
>> 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
>
> Unfortunately I have no idea what samples Vittorio does or does not
> possess, he has only mentioned off-hand that he might able to get hold
> of some if required. And since you were the one requiring them, I
> pointed you towards him.
>
> For myself, I am happy with the following points regarding this:
> 1. The identifiers are registered at the MPEG-4 RA.
> 2. There is a proper specification for these mappings that is
> seemingly kept up-to-date.
> 3. The mappings specification specifically notes that the only
> difference between the AVC and HEVC identifiers are the semantics
> mentioned in ISO/IEC 14496-15. We already have all of the identifiers
> specified which these mappings are based upon, so those semantics
> should not matter to us (and if they do, we have already broken those
> constraints at this point).
> 4. The mapping specification specifically notes that the given AVC and
> HEVC identifiers must also include the standard avcC and hvcC boxes so
> that they can be decoded normally without any additional custom code.
> 5. We have samples for at least one of the four identifiers that
> matches points 1 to 4.
> 6. Android, Chromium, VLC among others have already implemented these
> identifiers in the same way.
>
> Now, if you are not happy with these points, then please clearly state
> that you are blocking any and all additional identifier additions - no

> matter how specified - as long as there are no samples on hand for
> them.

I thought we had samples?

Anyway, please mention ticket #7347.

Carl Eugen
Jan Ekström Dec. 17, 2018, 8:30 p.m.
On Mon, Dec 17, 2018 at 10:23 PM Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
>
> 2018-12-17 21:17 GMT+01:00, Jan Ekström <jeebjp@gmail.com>:
> > On Mon, Dec 17, 2018 at 3:47 PM Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
> >>
> >> 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
> >
> > Unfortunately I have no idea what samples Vittorio does or does not
> > possess, he has only mentioned off-hand that he might able to get hold
> > of some if required. And since you were the one requiring them, I
> > pointed you towards him.
> >
> > For myself, I am happy with the following points regarding this:
> > 1. The identifiers are registered at the MPEG-4 RA.
> > 2. There is a proper specification for these mappings that is
> > seemingly kept up-to-date.
> > 3. The mappings specification specifically notes that the only
> > difference between the AVC and HEVC identifiers are the semantics
> > mentioned in ISO/IEC 14496-15. We already have all of the identifiers
> > specified which these mappings are based upon, so those semantics
> > should not matter to us (and if they do, we have already broken those
> > constraints at this point).
> > 4. The mapping specification specifically notes that the given AVC and
> > HEVC identifiers must also include the standard avcC and hvcC boxes so
> > that they can be decoded normally without any additional custom code.
> > 5. We have samples for at least one of the four identifiers that
> > matches points 1 to 4.
> > 6. Android, Chromium, VLC among others have already implemented these
> > identifiers in the same way.
> >
> > Now, if you are not happy with these points, then please clearly state
> > that you are blocking any and all additional identifier additions - no
>
> > matter how specified - as long as there are no samples on hand for
> > them.
>
> I thought we had samples?
>
> Anyway, please mention ticket #7347.
>
> Carl Eugen

The sample last linked in that ticket was supposedly MPEG-TS for the
other HEVC identifier, not ISOBMFF. We can not present these pictures
correctly, thus this by itself I would be against mentioning something
getting fixed. We gain the capability of decoding, not presenting due
to Dolby not even using their own ICtCp colorspace as-is for Dolby
Vision profile 5 (which is pretty much everything that these custom
identifiers get used for since they are supposed to only be utilized
for video streams that are not decode'able with "standard decoders" -
which means things that cannot present the colorspace that Dolby
Vision's non-backwards compatible profiles utilize).

Jan
Carl Eugen Hoyos Dec. 17, 2018, 8:48 p.m.
2018-12-17 21:30 GMT+01:00, Jan Ekström <jeebjp@gmail.com>:
> On Mon, Dec 17, 2018 at 10:23 PM Carl Eugen Hoyos <ceffmpeg@gmail.com>
> wrote:
>>
>> 2018-12-17 21:17 GMT+01:00, Jan Ekström <jeebjp@gmail.com>:
>> > On Mon, Dec 17, 2018 at 3:47 PM Carl Eugen Hoyos <ceffmpeg@gmail.com>
>> > wrote:
>> >>
>> >> 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
>> >
>> > Unfortunately I have no idea what samples Vittorio does or does not
>> > possess, he has only mentioned off-hand that he might able to get hold
>> > of some if required. And since you were the one requiring them, I
>> > pointed you towards him.
>> >
>> > For myself, I am happy with the following points regarding this:
>> > 1. The identifiers are registered at the MPEG-4 RA.
>> > 2. There is a proper specification for these mappings that is
>> > seemingly kept up-to-date.
>> > 3. The mappings specification specifically notes that the only
>> > difference between the AVC and HEVC identifiers are the semantics
>> > mentioned in ISO/IEC 14496-15. We already have all of the identifiers
>> > specified which these mappings are based upon, so those semantics
>> > should not matter to us (and if they do, we have already broken those
>> > constraints at this point).
>> > 4. The mapping specification specifically notes that the given AVC and
>> > HEVC identifiers must also include the standard avcC and hvcC boxes so
>> > that they can be decoded normally without any additional custom code.
>> > 5. We have samples for at least one of the four identifiers that
>> > matches points 1 to 4.
>> > 6. Android, Chromium, VLC among others have already implemented these
>> > identifiers in the same way.
>> >
>> > Now, if you are not happy with these points, then please clearly state
>> > that you are blocking any and all additional identifier additions - no
>>
>> > matter how specified - as long as there are no samples on hand for
>> > them.
>>
>> I thought we had samples?
>>
>> Anyway, please mention ticket #7347.
>
> The sample last linked in that ticket was supposedly MPEG-TS for the
> other HEVC identifier, not ISOBMFF.

Why do you think so? Which sample did you test?

Carl Eugen
Jan Ekström Dec. 17, 2018, 8:52 p.m.
On Mon, Dec 17, 2018 at 10:49 PM Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
>
> 2018-12-17 21:30 GMT+01:00, Jan Ekström <jeebjp@gmail.com>:
> > On Mon, Dec 17, 2018 at 10:23 PM Carl Eugen Hoyos <ceffmpeg@gmail.com>
> > wrote:
> >>
> >> 2018-12-17 21:17 GMT+01:00, Jan Ekström <jeebjp@gmail.com>:
> >> > On Mon, Dec 17, 2018 at 3:47 PM Carl Eugen Hoyos <ceffmpeg@gmail.com>
> >> > wrote:
> >> >>
> >> >> 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
> >> >
> >> > Unfortunately I have no idea what samples Vittorio does or does not
> >> > possess, he has only mentioned off-hand that he might able to get hold
> >> > of some if required. And since you were the one requiring them, I
> >> > pointed you towards him.
> >> >
> >> > For myself, I am happy with the following points regarding this:
> >> > 1. The identifiers are registered at the MPEG-4 RA.
> >> > 2. There is a proper specification for these mappings that is
> >> > seemingly kept up-to-date.
> >> > 3. The mappings specification specifically notes that the only
> >> > difference between the AVC and HEVC identifiers are the semantics
> >> > mentioned in ISO/IEC 14496-15. We already have all of the identifiers
> >> > specified which these mappings are based upon, so those semantics
> >> > should not matter to us (and if they do, we have already broken those
> >> > constraints at this point).
> >> > 4. The mapping specification specifically notes that the given AVC and
> >> > HEVC identifiers must also include the standard avcC and hvcC boxes so
> >> > that they can be decoded normally without any additional custom code.
> >> > 5. We have samples for at least one of the four identifiers that
> >> > matches points 1 to 4.
> >> > 6. Android, Chromium, VLC among others have already implemented these
> >> > identifiers in the same way.
> >> >
> >> > Now, if you are not happy with these points, then please clearly state
> >> > that you are blocking any and all additional identifier additions - no
> >>
> >> > matter how specified - as long as there are no samples on hand for
> >> > them.
> >>
> >> I thought we had samples?
> >>
> >> Anyway, please mention ticket #7347.
> >
> > The sample last linked in that ticket was supposedly MPEG-TS for the
> > other HEVC identifier, not ISOBMFF.
>
> Why do you think so? Which sample did you test?
>

From #7347
> Dobly Vision transport stream with codec tag "dvhe" can be found under:
> http://4kmedia.org/tag/dolby-vision/

The site also notes that it's supposed to be a transport stream. I did
not look further.

Jan
Carl Eugen Hoyos Dec. 17, 2018, 8:57 p.m.
2018-12-17 21:52 GMT+01:00, Jan Ekström <jeebjp@gmail.com>:
> On Mon, Dec 17, 2018 at 10:49 PM Carl Eugen Hoyos <ceffmpeg@gmail.com>
> wrote:
>>
>> 2018-12-17 21:30 GMT+01:00, Jan Ekström <jeebjp@gmail.com>:
>> > On Mon, Dec 17, 2018 at 10:23 PM Carl Eugen Hoyos <ceffmpeg@gmail.com>
>> > wrote:
>> >>
>> >> 2018-12-17 21:17 GMT+01:00, Jan Ekström <jeebjp@gmail.com>:
>> >> > On Mon, Dec 17, 2018 at 3:47 PM Carl Eugen Hoyos <ceffmpeg@gmail.com>
>> >> > wrote:
>> >> >>
>> >> >> 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
>> >> >
>> >> > Unfortunately I have no idea what samples Vittorio does or does not
>> >> > possess, he has only mentioned off-hand that he might able to get
>> >> > hold
>> >> > of some if required. And since you were the one requiring them, I
>> >> > pointed you towards him.
>> >> >
>> >> > For myself, I am happy with the following points regarding this:
>> >> > 1. The identifiers are registered at the MPEG-4 RA.
>> >> > 2. There is a proper specification for these mappings that is
>> >> > seemingly kept up-to-date.
>> >> > 3. The mappings specification specifically notes that the only
>> >> > difference between the AVC and HEVC identifiers are the semantics
>> >> > mentioned in ISO/IEC 14496-15. We already have all of the identifiers
>> >> > specified which these mappings are based upon, so those semantics
>> >> > should not matter to us (and if they do, we have already broken those
>> >> > constraints at this point).
>> >> > 4. The mapping specification specifically notes that the given AVC
>> >> > and
>> >> > HEVC identifiers must also include the standard avcC and hvcC boxes
>> >> > so
>> >> > that they can be decoded normally without any additional custom code.
>> >> > 5. We have samples for at least one of the four identifiers that
>> >> > matches points 1 to 4.
>> >> > 6. Android, Chromium, VLC among others have already implemented these
>> >> > identifiers in the same way.
>> >> >
>> >> > Now, if you are not happy with these points, then please clearly
>> >> > state
>> >> > that you are blocking any and all additional identifier additions -
>> >> > no
>> >>
>> >> > matter how specified - as long as there are no samples on hand for
>> >> > them.
>> >>
>> >> I thought we had samples?
>> >>
>> >> Anyway, please mention ticket #7347.
>> >
>> > The sample last linked in that ticket was supposedly MPEG-TS for the
>> > other HEVC identifier, not ISOBMFF.
>>
>> Why do you think so? Which sample did you test?
>>
>
> From #7347
>> Dobly Vision transport stream with codec tag "dvhe" can be found under:
>> http://4kmedia.org/tag/dolby-vision/
>
> The site also notes that it's supposed to be a transport stream. I did
> not look further.

Then please allow me to once again suggest testing (at least if
you trust neither me nor Igor).

Carl Eugen
Jan Ekström Dec. 17, 2018, 9:02 p.m.
On Mon, Dec 17, 2018 at 10:57 PM Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
>
> 2018-12-17 21:52 GMT+01:00, Jan Ekström <jeebjp@gmail.com>:
> > On Mon, Dec 17, 2018 at 10:49 PM Carl Eugen Hoyos <ceffmpeg@gmail.com>
> > wrote:
> >>
> >> 2018-12-17 21:30 GMT+01:00, Jan Ekström <jeebjp@gmail.com>:
> >> > On Mon, Dec 17, 2018 at 10:23 PM Carl Eugen Hoyos <ceffmpeg@gmail.com>
> >> > wrote:
> >> >>
> >> >> 2018-12-17 21:17 GMT+01:00, Jan Ekström <jeebjp@gmail.com>:
> >> >> > On Mon, Dec 17, 2018 at 3:47 PM Carl Eugen Hoyos <ceffmpeg@gmail.com>
> >> >> > wrote:
> >> >> >>
> >> >> >> 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
> >> >> >
> >> >> > Unfortunately I have no idea what samples Vittorio does or does not
> >> >> > possess, he has only mentioned off-hand that he might able to get
> >> >> > hold
> >> >> > of some if required. And since you were the one requiring them, I
> >> >> > pointed you towards him.
> >> >> >
> >> >> > For myself, I am happy with the following points regarding this:
> >> >> > 1. The identifiers are registered at the MPEG-4 RA.
> >> >> > 2. There is a proper specification for these mappings that is
> >> >> > seemingly kept up-to-date.
> >> >> > 3. The mappings specification specifically notes that the only
> >> >> > difference between the AVC and HEVC identifiers are the semantics
> >> >> > mentioned in ISO/IEC 14496-15. We already have all of the identifiers
> >> >> > specified which these mappings are based upon, so those semantics
> >> >> > should not matter to us (and if they do, we have already broken those
> >> >> > constraints at this point).
> >> >> > 4. The mapping specification specifically notes that the given AVC
> >> >> > and
> >> >> > HEVC identifiers must also include the standard avcC and hvcC boxes
> >> >> > so
> >> >> > that they can be decoded normally without any additional custom code.
> >> >> > 5. We have samples for at least one of the four identifiers that
> >> >> > matches points 1 to 4.
> >> >> > 6. Android, Chromium, VLC among others have already implemented these
> >> >> > identifiers in the same way.
> >> >> >
> >> >> > Now, if you are not happy with these points, then please clearly
> >> >> > state
> >> >> > that you are blocking any and all additional identifier additions -
> >> >> > no
> >> >>
> >> >> > matter how specified - as long as there are no samples on hand for
> >> >> > them.
> >> >>
> >> >> I thought we had samples?
> >> >>
> >> >> Anyway, please mention ticket #7347.
> >> >
> >> > The sample last linked in that ticket was supposedly MPEG-TS for the
> >> > other HEVC identifier, not ISOBMFF.
> >>
> >> Why do you think so? Which sample did you test?
> >>
> >
> > From #7347
> >> Dobly Vision transport stream with codec tag "dvhe" can be found under:
> >> http://4kmedia.org/tag/dolby-vision/
> >
> > The site also notes that it's supposed to be a transport stream. I did
> > not look further.
>
> Then please allow me to once again suggest testing (at least if
> you trust neither me nor Igor).
>
> Carl Eugen

That was a quote FROM Igor's post
(https://trac.ffmpeg.org/ticket/7347#comment:12). If he and the site
mentioned it wrong then please just note that.

Jan
Jan Ekström Dec. 17, 2018, 9:07 p.m.
On Mon, Dec 17, 2018 at 11:02 PM Jan Ekström <jeebjp@gmail.com> wrote:
>
> On Mon, Dec 17, 2018 at 10:57 PM Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
> >
> > 2018-12-17 21:52 GMT+01:00, Jan Ekström <jeebjp@gmail.com>:
> > > On Mon, Dec 17, 2018 at 10:49 PM Carl Eugen Hoyos <ceffmpeg@gmail.com>
> > > wrote:
> > >>
> > >> 2018-12-17 21:30 GMT+01:00, Jan Ekström <jeebjp@gmail.com>:
> > >> > On Mon, Dec 17, 2018 at 10:23 PM Carl Eugen Hoyos <ceffmpeg@gmail.com>
> > >> > wrote:
> > >> >>
> > >> >> 2018-12-17 21:17 GMT+01:00, Jan Ekström <jeebjp@gmail.com>:
> > >> >> > On Mon, Dec 17, 2018 at 3:47 PM Carl Eugen Hoyos <ceffmpeg@gmail.com>
> > >> >> > wrote:
> > >> >> >>
> > >> >> >> 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
> > >> >> >
> > >> >> > Unfortunately I have no idea what samples Vittorio does or does not
> > >> >> > possess, he has only mentioned off-hand that he might able to get
> > >> >> > hold
> > >> >> > of some if required. And since you were the one requiring them, I
> > >> >> > pointed you towards him.
> > >> >> >
> > >> >> > For myself, I am happy with the following points regarding this:
> > >> >> > 1. The identifiers are registered at the MPEG-4 RA.
> > >> >> > 2. There is a proper specification for these mappings that is
> > >> >> > seemingly kept up-to-date.
> > >> >> > 3. The mappings specification specifically notes that the only
> > >> >> > difference between the AVC and HEVC identifiers are the semantics
> > >> >> > mentioned in ISO/IEC 14496-15. We already have all of the identifiers
> > >> >> > specified which these mappings are based upon, so those semantics
> > >> >> > should not matter to us (and if they do, we have already broken those
> > >> >> > constraints at this point).
> > >> >> > 4. The mapping specification specifically notes that the given AVC
> > >> >> > and
> > >> >> > HEVC identifiers must also include the standard avcC and hvcC boxes
> > >> >> > so
> > >> >> > that they can be decoded normally without any additional custom code.
> > >> >> > 5. We have samples for at least one of the four identifiers that
> > >> >> > matches points 1 to 4.
> > >> >> > 6. Android, Chromium, VLC among others have already implemented these
> > >> >> > identifiers in the same way.
> > >> >> >
> > >> >> > Now, if you are not happy with these points, then please clearly
> > >> >> > state
> > >> >> > that you are blocking any and all additional identifier additions -
> > >> >> > no
> > >> >>
> > >> >> > matter how specified - as long as there are no samples on hand for
> > >> >> > them.
> > >> >>
> > >> >> I thought we had samples?
> > >> >>
> > >> >> Anyway, please mention ticket #7347.
> > >> >
> > >> > The sample last linked in that ticket was supposedly MPEG-TS for the
> > >> > other HEVC identifier, not ISOBMFF.
> > >>
> > >> Why do you think so? Which sample did you test?
> > >>
> > >
> > > From #7347
> > >> Dobly Vision transport stream with codec tag "dvhe" can be found under:
> > >> http://4kmedia.org/tag/dolby-vision/
> > >
> > > The site also notes that it's supposed to be a transport stream. I did
> > > not look further.
> >
> > Then please allow me to once again suggest testing (at least if
> > you trust neither me nor Igor).
> >
> > Carl Eugen
>
> That was a quote FROM Igor's post
> (https://trac.ffmpeg.org/ticket/7347#comment:12). If he and the site
> mentioned it wrong then please just note that.
>
> Jan

OK, so it is ISOBMFF and not MPEG-TS unlike Igor and the site noted.
Thank you, now there is a sample.

I think this is the sample that Rodger coded this patch set originally
against when we were hacking on this stuff around mpv.

Jan
Carl Eugen Hoyos Dec. 17, 2018, 9:10 p.m.
2018-12-17 22:02 GMT+01:00, Jan Ekström <jeebjp@gmail.com>:
> On Mon, Dec 17, 2018 at 10:57 PM Carl Eugen Hoyos <ceffmpeg@gmail.com>
> wrote:
>>
>> 2018-12-17 21:52 GMT+01:00, Jan Ekström <jeebjp@gmail.com>:
>> > On Mon, Dec 17, 2018 at 10:49 PM Carl Eugen Hoyos <ceffmpeg@gmail.com>
>> > wrote:
>> >>
>> >> 2018-12-17 21:30 GMT+01:00, Jan Ekström <jeebjp@gmail.com>:
>> >> > On Mon, Dec 17, 2018 at 10:23 PM Carl Eugen Hoyos
>> >> > <ceffmpeg@gmail.com>
>> >> > wrote:
>> >> >>
>> >> >> 2018-12-17 21:17 GMT+01:00, Jan Ekström <jeebjp@gmail.com>:
>> >> >> > On Mon, Dec 17, 2018 at 3:47 PM Carl Eugen Hoyos
>> >> >> > <ceffmpeg@gmail.com>
>> >> >> > wrote:
>> >> >> >>
>> >> >> >> 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
>> >> >> >
>> >> >> > Unfortunately I have no idea what samples Vittorio does or does
>> >> >> > not
>> >> >> > possess, he has only mentioned off-hand that he might able to get
>> >> >> > hold
>> >> >> > of some if required. And since you were the one requiring them, I
>> >> >> > pointed you towards him.
>> >> >> >
>> >> >> > For myself, I am happy with the following points regarding this:
>> >> >> > 1. The identifiers are registered at the MPEG-4 RA.
>> >> >> > 2. There is a proper specification for these mappings that is
>> >> >> > seemingly kept up-to-date.
>> >> >> > 3. The mappings specification specifically notes that the only
>> >> >> > difference between the AVC and HEVC identifiers are the semantics
>> >> >> > mentioned in ISO/IEC 14496-15. We already have all of the
>> >> >> > identifiers
>> >> >> > specified which these mappings are based upon, so those semantics
>> >> >> > should not matter to us (and if they do, we have already broken
>> >> >> > those
>> >> >> > constraints at this point).
>> >> >> > 4. The mapping specification specifically notes that the given AVC
>> >> >> > and
>> >> >> > HEVC identifiers must also include the standard avcC and hvcC
>> >> >> > boxes
>> >> >> > so
>> >> >> > that they can be decoded normally without any additional custom
>> >> >> > code.
>> >> >> > 5. We have samples for at least one of the four identifiers that
>> >> >> > matches points 1 to 4.
>> >> >> > 6. Android, Chromium, VLC among others have already implemented
>> >> >> > these
>> >> >> > identifiers in the same way.
>> >> >> >
>> >> >> > Now, if you are not happy with these points, then please clearly
>> >> >> > state
>> >> >> > that you are blocking any and all additional identifier additions
>> >> >> > -
>> >> >> > no
>> >> >>
>> >> >> > matter how specified - as long as there are no samples on hand for
>> >> >> > them.
>> >> >>
>> >> >> I thought we had samples?
>> >> >>
>> >> >> Anyway, please mention ticket #7347.
>> >> >
>> >> > The sample last linked in that ticket was supposedly MPEG-TS for the
>> >> > other HEVC identifier, not ISOBMFF.
>> >>
>> >> Why do you think so? Which sample did you test?
>> >>
>> >
>> > From #7347
>> >> Dobly Vision transport stream with codec tag "dvhe" can be found under:
>> >> http://4kmedia.org/tag/dolby-vision/
>> >
>> > The site also notes that it's supposed to be a transport stream. I did
>> > not look further.
>>
>> Then please allow me to once again suggest testing (at least if
>> you trust neither me nor Igor).

> That was a quote FROM Igor's post
> (https://trac.ffmpeg.org/ticket/7347#comment:12). If he and the site
> mentioned it wrong then please just note that.

Which reminds me that you could mention him too in
the commit message:
https://patchwork.ffmpeg.org/patch/10023/

Carl Eugen
Jan Ekström Dec. 17, 2018, 9:18 p.m.
On Mon, Dec 17, 2018 at 11:11 PM Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
>
> 2018-12-17 22:02 GMT+01:00, Jan Ekström <jeebjp@gmail.com>:
> > On Mon, Dec 17, 2018 at 10:57 PM Carl Eugen Hoyos <ceffmpeg@gmail.com>
> > wrote:
> >>
> >> 2018-12-17 21:52 GMT+01:00, Jan Ekström <jeebjp@gmail.com>:
> >> > On Mon, Dec 17, 2018 at 10:49 PM Carl Eugen Hoyos <ceffmpeg@gmail.com>
> >> > wrote:
> >> >>
> >> >> 2018-12-17 21:30 GMT+01:00, Jan Ekström <jeebjp@gmail.com>:
> >> >> > On Mon, Dec 17, 2018 at 10:23 PM Carl Eugen Hoyos
> >> >> > <ceffmpeg@gmail.com>
> >> >> > wrote:
> >> >> >>
> >> >> >> 2018-12-17 21:17 GMT+01:00, Jan Ekström <jeebjp@gmail.com>:
> >> >> >> > On Mon, Dec 17, 2018 at 3:47 PM Carl Eugen Hoyos
> >> >> >> > <ceffmpeg@gmail.com>
> >> >> >> > wrote:
> >> >> >> >>
> >> >> >> >> 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
> >> >> >> >
> >> >> >> > Unfortunately I have no idea what samples Vittorio does or does
> >> >> >> > not
> >> >> >> > possess, he has only mentioned off-hand that he might able to get
> >> >> >> > hold
> >> >> >> > of some if required. And since you were the one requiring them, I
> >> >> >> > pointed you towards him.
> >> >> >> >
> >> >> >> > For myself, I am happy with the following points regarding this:
> >> >> >> > 1. The identifiers are registered at the MPEG-4 RA.
> >> >> >> > 2. There is a proper specification for these mappings that is
> >> >> >> > seemingly kept up-to-date.
> >> >> >> > 3. The mappings specification specifically notes that the only
> >> >> >> > difference between the AVC and HEVC identifiers are the semantics
> >> >> >> > mentioned in ISO/IEC 14496-15. We already have all of the
> >> >> >> > identifiers
> >> >> >> > specified which these mappings are based upon, so those semantics
> >> >> >> > should not matter to us (and if they do, we have already broken
> >> >> >> > those
> >> >> >> > constraints at this point).
> >> >> >> > 4. The mapping specification specifically notes that the given AVC
> >> >> >> > and
> >> >> >> > HEVC identifiers must also include the standard avcC and hvcC
> >> >> >> > boxes
> >> >> >> > so
> >> >> >> > that they can be decoded normally without any additional custom
> >> >> >> > code.
> >> >> >> > 5. We have samples for at least one of the four identifiers that
> >> >> >> > matches points 1 to 4.
> >> >> >> > 6. Android, Chromium, VLC among others have already implemented
> >> >> >> > these
> >> >> >> > identifiers in the same way.
> >> >> >> >
> >> >> >> > Now, if you are not happy with these points, then please clearly
> >> >> >> > state
> >> >> >> > that you are blocking any and all additional identifier additions
> >> >> >> > -
> >> >> >> > no
> >> >> >>
> >> >> >> > matter how specified - as long as there are no samples on hand for
> >> >> >> > them.
> >> >> >>
> >> >> >> I thought we had samples?
> >> >> >>
> >> >> >> Anyway, please mention ticket #7347.
> >> >> >
> >> >> > The sample last linked in that ticket was supposedly MPEG-TS for the
> >> >> > other HEVC identifier, not ISOBMFF.
> >> >>
> >> >> Why do you think so? Which sample did you test?
> >> >>
> >> >
> >> > From #7347
> >> >> Dobly Vision transport stream with codec tag "dvhe" can be found under:
> >> >> http://4kmedia.org/tag/dolby-vision/
> >> >
> >> > The site also notes that it's supposed to be a transport stream. I did
> >> > not look further.
> >>
> >> Then please allow me to once again suggest testing (at least if
> >> you trust neither me nor Igor).
>
> > That was a quote FROM Igor's post
> > (https://trac.ffmpeg.org/ticket/7347#comment:12). If he and the site
> > mentioned it wrong then please just note that.
>
> Which reminds me that you could mention him too in
> the commit message:
> https://patchwork.ffmpeg.org/patch/10023/
>
> Carl Eugen

I did not see that patch when taking the initial single-identifier
patch from Rodger, and even compared to Rodger's original patch me
adding the other identifiers and adding the MPEG-4 RA identifier
description comments and proper commit message at that point keep very
little of what was there to begin with.

Unless there is something substantial, I would rather just get done
with this pain that is trying to get a seemingly darn simple patch
through review. At this point I hate humans, I hate communication.
This is not fun. If you got any enjoyment of this, I am very happy for
you.

Jan
Carl Eugen Hoyos Dec. 17, 2018, 9:22 p.m.
2018-12-17 22:18 GMT+01:00, Jan Ekström <jeebjp@gmail.com>:
> On Mon, Dec 17, 2018 at 11:11 PM Carl Eugen Hoyos <ceffmpeg@gmail.com>
> wrote:
>>
>> 2018-12-17 22:02 GMT+01:00, Jan Ekström <jeebjp@gmail.com>:
>> > On Mon, Dec 17, 2018 at 10:57 PM Carl Eugen Hoyos <ceffmpeg@gmail.com>
>> > wrote:
>> >>
>> >> 2018-12-17 21:52 GMT+01:00, Jan Ekström <jeebjp@gmail.com>:
>> >> > On Mon, Dec 17, 2018 at 10:49 PM Carl Eugen Hoyos
>> >> > <ceffmpeg@gmail.com>
>> >> > wrote:
>> >> >>
>> >> >> 2018-12-17 21:30 GMT+01:00, Jan Ekström <jeebjp@gmail.com>:
>> >> >> > On Mon, Dec 17, 2018 at 10:23 PM Carl Eugen Hoyos
>> >> >> > <ceffmpeg@gmail.com>
>> >> >> > wrote:
>> >> >> >>
>> >> >> >> 2018-12-17 21:17 GMT+01:00, Jan Ekström <jeebjp@gmail.com>:
>> >> >> >> > On Mon, Dec 17, 2018 at 3:47 PM Carl Eugen Hoyos
>> >> >> >> > <ceffmpeg@gmail.com>
>> >> >> >> > wrote:
>> >> >> >> >>
>> >> >> >> >> 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
>> >> >> >> >
>> >> >> >> > Unfortunately I have no idea what samples Vittorio does or does
>> >> >> >> > not
>> >> >> >> > possess, he has only mentioned off-hand that he might able to
>> >> >> >> > get
>> >> >> >> > hold
>> >> >> >> > of some if required. And since you were the one requiring them,
>> >> >> >> > I
>> >> >> >> > pointed you towards him.
>> >> >> >> >
>> >> >> >> > For myself, I am happy with the following points regarding
>> >> >> >> > this:
>> >> >> >> > 1. The identifiers are registered at the MPEG-4 RA.
>> >> >> >> > 2. There is a proper specification for these mappings that is
>> >> >> >> > seemingly kept up-to-date.
>> >> >> >> > 3. The mappings specification specifically notes that the only
>> >> >> >> > difference between the AVC and HEVC identifiers are the
>> >> >> >> > semantics
>> >> >> >> > mentioned in ISO/IEC 14496-15. We already have all of the
>> >> >> >> > identifiers
>> >> >> >> > specified which these mappings are based upon, so those
>> >> >> >> > semantics
>> >> >> >> > should not matter to us (and if they do, we have already broken
>> >> >> >> > those
>> >> >> >> > constraints at this point).
>> >> >> >> > 4. The mapping specification specifically notes that the given
>> >> >> >> > AVC
>> >> >> >> > and
>> >> >> >> > HEVC identifiers must also include the standard avcC and hvcC
>> >> >> >> > boxes
>> >> >> >> > so
>> >> >> >> > that they can be decoded normally without any additional custom
>> >> >> >> > code.
>> >> >> >> > 5. We have samples for at least one of the four identifiers
>> >> >> >> > that
>> >> >> >> > matches points 1 to 4.
>> >> >> >> > 6. Android, Chromium, VLC among others have already implemented
>> >> >> >> > these
>> >> >> >> > identifiers in the same way.
>> >> >> >> >
>> >> >> >> > Now, if you are not happy with these points, then please
>> >> >> >> > clearly
>> >> >> >> > state
>> >> >> >> > that you are blocking any and all additional identifier
>> >> >> >> > additions
>> >> >> >> > -
>> >> >> >> > no
>> >> >> >>
>> >> >> >> > matter how specified - as long as there are no samples on hand
>> >> >> >> > for
>> >> >> >> > them.
>> >> >> >>
>> >> >> >> I thought we had samples?
>> >> >> >>
>> >> >> >> Anyway, please mention ticket #7347.
>> >> >> >
>> >> >> > The sample last linked in that ticket was supposedly MPEG-TS for
>> >> >> > the
>> >> >> > other HEVC identifier, not ISOBMFF.
>> >> >>
>> >> >> Why do you think so? Which sample did you test?
>> >> >>
>> >> >
>> >> > From #7347
>> >> >> Dobly Vision transport stream with codec tag "dvhe" can be found
>> >> >> under:
>> >> >> http://4kmedia.org/tag/dolby-vision/
>> >> >
>> >> > The site also notes that it's supposed to be a transport stream. I
>> >> > did
>> >> > not look further.
>> >>
>> >> Then please allow me to once again suggest testing (at least if
>> >> you trust neither me nor Igor).
>>
>> > That was a quote FROM Igor's post
>> > (https://trac.ffmpeg.org/ticket/7347#comment:12). If he and the site
>> > mentioned it wrong then please just note that.
>>
>> Which reminds me that you could mention him too in
>> the commit message:
>> https://patchwork.ffmpeg.org/patch/10023/
>>
>> Carl Eugen
>
> I did not see that patch when taking the initial single-identifier

I know (actually: I assumed so) and wrote that in my first comment.

> patch from Rodger, and even compared to Rodger's original patch me
> adding the other identifiers and adding the MPEG-4 RA identifier
> description comments and proper commit message at that point keep very
> little of what was there to begin with.
>
> Unless there is something substantial, I would rather just get done
> with this pain that is trying to get a seemingly darn simple patch
> through review. At this point I hate humans, I hate communication.

> This is not fun. If you got any enjoyment of this, I am very happy for
> you.

Sadly not, on the contrary.

Carl Eugen
Paul B Mahol Dec. 17, 2018, 9:23 p.m.
On 12/3/18, 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).
> ---
>  libavformat/isom.c | 4 ++++
>  1 file changed, 4 insertions(+)
>
> 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 */
> --
> 2.19.2

OK
Jan Ekström Dec. 17, 2018, 9:29 p.m.
On Mon, Dec 17, 2018 at 11:23 PM Paul B Mahol <onemda@gmail.com> wrote:
>
> On 12/3/18, 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).
> > ---
> >  libavformat/isom.c | 4 ++++
> >  1 file changed, 4 insertions(+)
> >
> > 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 */
> > --
> > 2.19.2
>
> OK

As it was verified to pass FATE on IRC, the patch with the comments
matching the AVC identifiers (they were the other way around) was
pushed.

Jan
Jan Ekström Dec. 18, 2018, 5:17 p.m.
On Mon, Dec 17, 2018 at 10:17 PM Jan Ekström <jeebjp@gmail.com> wrote:
>
> On Mon, Dec 17, 2018 at 3:47 PM Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
> >
> > 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
>
> Unfortunately I have no idea what samples Vittorio does or does not
> possess, he has only mentioned off-hand that he might able to get hold
> of some if required. And since you were the one requiring them, I
> pointed you towards him.
>
> For myself, I am happy with the following points regarding this:
> 1. The identifiers are registered at the MPEG-4 RA.
> 2. There is a proper specification for these mappings that is
> seemingly kept up-to-date.
> 3. The mappings specification specifically notes that the only
> difference between the AVC and HEVC identifiers are the semantics
> mentioned in ISO/IEC 14496-15. We already have all of the identifiers
> specified which these mappings are based upon, so those semantics
> should not matter to us (and if they do, we have already broken those
> constraints at this point).
> 4. The mapping specification specifically notes that the given AVC and
> HEVC identifiers must also include the standard avcC and hvcC boxes so
> that they can be decoded normally without any additional custom code.
> 5. We have samples for at least one of the four identifiers that
> matches points 1 to 4.
> 6. Android, Chromium, VLC among others have already implemented these
> identifiers in the same way.
>
> Now, if you are not happy with these points, then please clearly state
> that you are blocking any and all additional identifier additions - no
> matter how specified - as long as there are no samples on hand for
> them.

After taking a second look at this sentence, I find this wording being
loaded and antagonizing. It was unprofessional, and I apologize for
it.

But the wish underneath was to get a clear view into what it was it
that you wanted. That was what was mostly clouded for me in your
replies, and that annoyed me to no end.

While I must say that I would have been happy if you had told me you
were not blocking the patch (set), I did not want a specific outcome
out of this sentence. I just wanted you to voice your level of
discomfort with the patch (set) and to voice your current wishes
regarding it. I had set my wishes on the table with the six points,
and why I believed the patch (set) was fine as it was.

That is why after I wrote this post I asked Michael what it was that
was the procedure for cases where developers have seemingly
irreconcilable differences in opinions regarding a patch set. I did
not know if that was the case, but the main point was that in the
unfortunate case that the patch was blocked, and we did not agree on
some points heavily enough that we could not co-operate, that the next
step could be taken right away so as to not have the patch (set) sit
there untouched for another week or two.

Unfortunately, you did not respond to or touch this sentence at all,
which I then interpreted as your comments not being blockers.

I hope this makes my intentions and annoyances clear. I hope that in
the future we can continue to co-operate, and that this makes it clear
that I do not have any personal grievances nor a vendetta against you.

Best regards,
Jan
Carl Eugen Hoyos Dec. 18, 2018, 5:20 p.m.
2018-12-18 18:17 GMT+01:00, Jan Ekström <jeebjp@gmail.com>:
> On Mon, Dec 17, 2018 at 10:17 PM Jan Ekström <jeebjp@gmail.com> wrote:
>>
>> On Mon, Dec 17, 2018 at 3:47 PM Carl Eugen Hoyos <ceffmpeg@gmail.com>
>> wrote:
>> >
>> > 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
>>
>> Unfortunately I have no idea what samples Vittorio does or does not
>> possess, he has only mentioned off-hand that he might able to get hold
>> of some if required. And since you were the one requiring them, I
>> pointed you towards him.
>>
>> For myself, I am happy with the following points regarding this:
>> 1. The identifiers are registered at the MPEG-4 RA.
>> 2. There is a proper specification for these mappings that is
>> seemingly kept up-to-date.
>> 3. The mappings specification specifically notes that the only
>> difference between the AVC and HEVC identifiers are the semantics
>> mentioned in ISO/IEC 14496-15. We already have all of the identifiers
>> specified which these mappings are based upon, so those semantics
>> should not matter to us (and if they do, we have already broken those
>> constraints at this point).
>> 4. The mapping specification specifically notes that the given AVC and
>> HEVC identifiers must also include the standard avcC and hvcC boxes so
>> that they can be decoded normally without any additional custom code.
>> 5. We have samples for at least one of the four identifiers that
>> matches points 1 to 4.
>> 6. Android, Chromium, VLC among others have already implemented these
>> identifiers in the same way.
>>
>> Now, if you are not happy with these points, then please clearly state
>> that you are blocking any and all additional identifier additions - no
>> matter how specified - as long as there are no samples on hand for
>> them.
>
> After taking a second look at this sentence, I find this wording being
> loaded and antagonizing. It was unprofessional, and I apologize for
> it.
>
> But the wish underneath was to get a clear view into what it was it
> that you wanted. That was what was mostly clouded for me in your
> replies, and that annoyed me to no end.
>
> While I must say that I would have been happy if you had told me you
> were not blocking the patch (set), I did not want a specific outcome
> out of this sentence. I just wanted you to voice your level of
> discomfort with the patch (set) and to voice your current wishes
> regarding it. I had set my wishes on the table with the six points,
> and why I believed the patch (set) was fine as it was.
>
> That is why after I wrote this post I asked Michael what it was that
> was the procedure for cases where developers have seemingly
> irreconcilable differences in opinions regarding a patch set. I did
> not know if that was the case, but the main point was that in the
> unfortunate case that the patch was blocked, and we did not agree on
> some points heavily enough that we could not co-operate, that the next
> step could be taken right away so as to not have the patch (set) sit
> there untouched for another week or two.
>
> Unfortunately, you did not respond to or touch this sentence at all,
> which I then interpreted as your comments not being blockers.

> I hope this makes my intentions and annoyances clear.

Afaict, it contradicts what you wrote on irc yesterday.

> I hope that in
> the future we can continue to co-operate, and that this makes it clear
> that I do not have any personal grievances nor a vendetta against you.

Carl Eugen
Jan Ekström Dec. 18, 2018, 5:24 p.m.
On Tue, Dec 18, 2018 at 7:21 PM Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
>
> 2018-12-18 18:17 GMT+01:00, Jan Ekström <jeebjp@gmail.com>:
> > On Mon, Dec 17, 2018 at 10:17 PM Jan Ekström <jeebjp@gmail.com> wrote:
> >>
> >> On Mon, Dec 17, 2018 at 3:47 PM Carl Eugen Hoyos <ceffmpeg@gmail.com>
> >> wrote:
> >> >
> >> > 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
> >>
> >> Unfortunately I have no idea what samples Vittorio does or does not
> >> possess, he has only mentioned off-hand that he might able to get hold
> >> of some if required. And since you were the one requiring them, I
> >> pointed you towards him.
> >>
> >> For myself, I am happy with the following points regarding this:
> >> 1. The identifiers are registered at the MPEG-4 RA.
> >> 2. There is a proper specification for these mappings that is
> >> seemingly kept up-to-date.
> >> 3. The mappings specification specifically notes that the only
> >> difference between the AVC and HEVC identifiers are the semantics
> >> mentioned in ISO/IEC 14496-15. We already have all of the identifiers
> >> specified which these mappings are based upon, so those semantics
> >> should not matter to us (and if they do, we have already broken those
> >> constraints at this point).
> >> 4. The mapping specification specifically notes that the given AVC and
> >> HEVC identifiers must also include the standard avcC and hvcC boxes so
> >> that they can be decoded normally without any additional custom code.
> >> 5. We have samples for at least one of the four identifiers that
> >> matches points 1 to 4.
> >> 6. Android, Chromium, VLC among others have already implemented these
> >> identifiers in the same way.
> >>
> >> Now, if you are not happy with these points, then please clearly state
> >> that you are blocking any and all additional identifier additions - no
> >> matter how specified - as long as there are no samples on hand for
> >> them.
> >
> > After taking a second look at this sentence, I find this wording being
> > loaded and antagonizing. It was unprofessional, and I apologize for
> > it.
> >
> > But the wish underneath was to get a clear view into what it was it
> > that you wanted. That was what was mostly clouded for me in your
> > replies, and that annoyed me to no end.
> >
> > While I must say that I would have been happy if you had told me you
> > were not blocking the patch (set), I did not want a specific outcome
> > out of this sentence. I just wanted you to voice your level of
> > discomfort with the patch (set) and to voice your current wishes
> > regarding it. I had set my wishes on the table with the six points,
> > and why I believed the patch (set) was fine as it was.
> >
> > That is why after I wrote this post I asked Michael what it was that
> > was the procedure for cases where developers have seemingly
> > irreconcilable differences in opinions regarding a patch set. I did
> > not know if that was the case, but the main point was that in the
> > unfortunate case that the patch was blocked, and we did not agree on
> > some points heavily enough that we could not co-operate, that the next
> > step could be taken right away so as to not have the patch (set) sit
> > there untouched for another week or two.
> >
> > Unfortunately, you did not respond to or touch this sentence at all,
> > which I then interpreted as your comments not being blockers.
>
> > I hope this makes my intentions and annoyances clear.
>
> Afaict, it contradicts what you wrote on irc yesterday.
>
> > I hope that in
> > the future we can continue to co-operate, and that this makes it clear
> > that I do not have any personal grievances nor a vendetta against you.
>
> Carl Eugen

Feel free to quote the parts that you think contradict.

Jan
Carl Eugen Hoyos Dec. 18, 2018, 5:30 p.m.
2018-12-18 18:24 GMT+01:00, Jan Ekström <jeebjp@gmail.com>:
> On Tue, Dec 18, 2018 at 7:21 PM Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
>>
>> 2018-12-18 18:17 GMT+01:00, Jan Ekström <jeebjp@gmail.com>:
>> > On Mon, Dec 17, 2018 at 10:17 PM Jan Ekström <jeebjp@gmail.com> wrote:
>> >>
>> >> On Mon, Dec 17, 2018 at 3:47 PM Carl Eugen Hoyos <ceffmpeg@gmail.com>
>> >> wrote:
>> >> >
>> >> > 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
>> >>
>> >> Unfortunately I have no idea what samples Vittorio does or does not
>> >> possess, he has only mentioned off-hand that he might able to get hold
>> >> of some if required. And since you were the one requiring them, I
>> >> pointed you towards him.
>> >>
>> >> For myself, I am happy with the following points regarding this:
>> >> 1. The identifiers are registered at the MPEG-4 RA.
>> >> 2. There is a proper specification for these mappings that is
>> >> seemingly kept up-to-date.
>> >> 3. The mappings specification specifically notes that the only
>> >> difference between the AVC and HEVC identifiers are the semantics
>> >> mentioned in ISO/IEC 14496-15. We already have all of the identifiers
>> >> specified which these mappings are based upon, so those semantics
>> >> should not matter to us (and if they do, we have already broken those
>> >> constraints at this point).
>> >> 4. The mapping specification specifically notes that the given AVC and
>> >> HEVC identifiers must also include the standard avcC and hvcC boxes so
>> >> that they can be decoded normally without any additional custom code.
>> >> 5. We have samples for at least one of the four identifiers that
>> >> matches points 1 to 4.
>> >> 6. Android, Chromium, VLC among others have already implemented these
>> >> identifiers in the same way.
>> >>
>> >> Now, if you are not happy with these points, then please clearly state
>> >> that you are blocking any and all additional identifier additions - no
>> >> matter how specified - as long as there are no samples on hand for
>> >> them.
>> >
>> > After taking a second look at this sentence, I find this wording being
>> > loaded and antagonizing. It was unprofessional, and I apologize for
>> > it.
>> >
>> > But the wish underneath was to get a clear view into what it was it
>> > that you wanted. That was what was mostly clouded for me in your
>> > replies, and that annoyed me to no end.
>> >
>> > While I must say that I would have been happy if you had told me you
>> > were not blocking the patch (set), I did not want a specific outcome
>> > out of this sentence. I just wanted you to voice your level of
>> > discomfort with the patch (set) and to voice your current wishes
>> > regarding it. I had set my wishes on the table with the six points,
>> > and why I believed the patch (set) was fine as it was.
>> >
>> > That is why after I wrote this post I asked Michael what it was that
>> > was the procedure for cases where developers have seemingly
>> > irreconcilable differences in opinions regarding a patch set. I did
>> > not know if that was the case, but the main point was that in the
>> > unfortunate case that the patch was blocked, and we did not agree on
>> > some points heavily enough that we could not co-operate, that the next
>> > step could be taken right away so as to not have the patch (set) sit
>> > there untouched for another week or two.
>> >
>> > Unfortunately, you did not respond to or touch this sentence at all,
>> > which I then interpreted as your comments not being blockers.
>>
>> > I hope this makes my intentions and annoyances clear.
>>
>> Afaict, it contradicts what you wrote on irc yesterday.
>>
>> > I hope that in
>> > the future we can continue to co-operate, and that this makes it clear
>> > that I do not have any personal grievances nor a vendetta against you.
>>
>> Carl Eugen
>
> Feel free to quote the parts that you think contradict.

I was under the assumption you had read this:
[21:26:03 CET] <durandal_1707> carl just officially approved your
patch with single condition to mention ticket #7347

But re-reading it, there was no indication you actually understood
what Paul wrote (or even read it), so sorry if I was wrong.

Carl Eugen
Jan Ekström Dec. 18, 2018, 5:38 p.m.
On Tue, Dec 18, 2018 at 7:30 PM Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
>
> 2018-12-18 18:24 GMT+01:00, Jan Ekström <jeebjp@gmail.com>:
> > On Tue, Dec 18, 2018 at 7:21 PM Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
> >>
> >> 2018-12-18 18:17 GMT+01:00, Jan Ekström <jeebjp@gmail.com>:
> >> > On Mon, Dec 17, 2018 at 10:17 PM Jan Ekström <jeebjp@gmail.com> wrote:
> >> >>
> >> >> On Mon, Dec 17, 2018 at 3:47 PM Carl Eugen Hoyos <ceffmpeg@gmail.com>
> >> >> wrote:
> >> >> >
> >> >> > 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
> >> >>
> >> >> Unfortunately I have no idea what samples Vittorio does or does not
> >> >> possess, he has only mentioned off-hand that he might able to get hold
> >> >> of some if required. And since you were the one requiring them, I
> >> >> pointed you towards him.
> >> >>
> >> >> For myself, I am happy with the following points regarding this:
> >> >> 1. The identifiers are registered at the MPEG-4 RA.
> >> >> 2. There is a proper specification for these mappings that is
> >> >> seemingly kept up-to-date.
> >> >> 3. The mappings specification specifically notes that the only
> >> >> difference between the AVC and HEVC identifiers are the semantics
> >> >> mentioned in ISO/IEC 14496-15. We already have all of the identifiers
> >> >> specified which these mappings are based upon, so those semantics
> >> >> should not matter to us (and if they do, we have already broken those
> >> >> constraints at this point).
> >> >> 4. The mapping specification specifically notes that the given AVC and
> >> >> HEVC identifiers must also include the standard avcC and hvcC boxes so
> >> >> that they can be decoded normally without any additional custom code.
> >> >> 5. We have samples for at least one of the four identifiers that
> >> >> matches points 1 to 4.
> >> >> 6. Android, Chromium, VLC among others have already implemented these
> >> >> identifiers in the same way.
> >> >>
> >> >> Now, if you are not happy with these points, then please clearly state
> >> >> that you are blocking any and all additional identifier additions - no
> >> >> matter how specified - as long as there are no samples on hand for
> >> >> them.
> >> >
> >> > After taking a second look at this sentence, I find this wording being
> >> > loaded and antagonizing. It was unprofessional, and I apologize for
> >> > it.
> >> >
> >> > But the wish underneath was to get a clear view into what it was it
> >> > that you wanted. That was what was mostly clouded for me in your
> >> > replies, and that annoyed me to no end.
> >> >
> >> > While I must say that I would have been happy if you had told me you
> >> > were not blocking the patch (set), I did not want a specific outcome
> >> > out of this sentence. I just wanted you to voice your level of
> >> > discomfort with the patch (set) and to voice your current wishes
> >> > regarding it. I had set my wishes on the table with the six points,
> >> > and why I believed the patch (set) was fine as it was.
> >> >
> >> > That is why after I wrote this post I asked Michael what it was that
> >> > was the procedure for cases where developers have seemingly
> >> > irreconcilable differences in opinions regarding a patch set. I did
> >> > not know if that was the case, but the main point was that in the
> >> > unfortunate case that the patch was blocked, and we did not agree on
> >> > some points heavily enough that we could not co-operate, that the next
> >> > step could be taken right away so as to not have the patch (set) sit
> >> > there untouched for another week or two.
> >> >
> >> > Unfortunately, you did not respond to or touch this sentence at all,
> >> > which I then interpreted as your comments not being blockers.
> >>
> >> > I hope this makes my intentions and annoyances clear.
> >>
> >> Afaict, it contradicts what you wrote on irc yesterday.
> >>
> >> > I hope that in
> >> > the future we can continue to co-operate, and that this makes it clear
> >> > that I do not have any personal grievances nor a vendetta against you.
> >>
> >> Carl Eugen
> >
> > Feel free to quote the parts that you think contradict.
>
> I was under the assumption you had read this:
> [21:26:03 CET] <durandal_1707> carl just officially approved your
> patch with single condition to mention ticket #7347
>
> But re-reading it, there was no indication you actually understood
> what Paul wrote (or even read it), so sorry if I was wrong.
>

Yes, that specific line I had no interest in. I was tired, and the
ticket was not in my opinion getting fixed with this, as only after we
got the Dolby Vision profile 5 color space reverse engineered would we
actually have these clips properly playing (outside of hardware
decoding paths specifically meant for Dolby Vision). I had commented
in a way on the mailing list thread towards that e-mail that I thought
made it clear that I would not be adding the ticket identifier (esp.
not at the eleventh hour, which it really did feel like to me at that
point).

For the record, me and Rodger had already worked on grasping what
standard ICtCp was on the mpv development channel (and Rodger with
Niklas already had a patch around which I still have had not the time
to review on that side of open source), and that seemed to not be the
thing (so the marketing text in Dolby's specification about it being
proprietary in some way was not a lie).

Jan
Carl Eugen Hoyos Dec. 18, 2018, 6:05 p.m.
2018-12-18 18:38 GMT+01:00, Jan Ekström <jeebjp@gmail.com>:
> On Tue, Dec 18, 2018 at 7:30 PM Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
>>
>> 2018-12-18 18:24 GMT+01:00, Jan Ekström <jeebjp@gmail.com>:
>> > On Tue, Dec 18, 2018 at 7:21 PM Carl Eugen Hoyos <ceffmpeg@gmail.com>
>> > wrote:
>> >>
>> >> 2018-12-18 18:17 GMT+01:00, Jan Ekström <jeebjp@gmail.com>:
>> >> > On Mon, Dec 17, 2018 at 10:17 PM Jan Ekström <jeebjp@gmail.com>
>> >> > wrote:
>> >> >>
>> >> >> On Mon, Dec 17, 2018 at 3:47 PM Carl Eugen Hoyos
>> >> >> <ceffmpeg@gmail.com>
>> >> >> wrote:
>> >> >> >
>> >> >> > 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
>> >> >>
>> >> >> Unfortunately I have no idea what samples Vittorio does or does not
>> >> >> possess, he has only mentioned off-hand that he might able to get
>> >> >> hold
>> >> >> of some if required. And since you were the one requiring them, I
>> >> >> pointed you towards him.
>> >> >>
>> >> >> For myself, I am happy with the following points regarding this:
>> >> >> 1. The identifiers are registered at the MPEG-4 RA.
>> >> >> 2. There is a proper specification for these mappings that is
>> >> >> seemingly kept up-to-date.
>> >> >> 3. The mappings specification specifically notes that the only
>> >> >> difference between the AVC and HEVC identifiers are the semantics
>> >> >> mentioned in ISO/IEC 14496-15. We already have all of the
>> >> >> identifiers
>> >> >> specified which these mappings are based upon, so those semantics
>> >> >> should not matter to us (and if they do, we have already broken
>> >> >> those
>> >> >> constraints at this point).
>> >> >> 4. The mapping specification specifically notes that the given AVC
>> >> >> and
>> >> >> HEVC identifiers must also include the standard avcC and hvcC boxes
>> >> >> so
>> >> >> that they can be decoded normally without any additional custom
>> >> >> code.
>> >> >> 5. We have samples for at least one of the four identifiers that
>> >> >> matches points 1 to 4.
>> >> >> 6. Android, Chromium, VLC among others have already implemented
>> >> >> these
>> >> >> identifiers in the same way.
>> >> >>
>> >> >> Now, if you are not happy with these points, then please clearly
>> >> >> state
>> >> >> that you are blocking any and all additional identifier additions -
>> >> >> no
>> >> >> matter how specified - as long as there are no samples on hand for
>> >> >> them.
>> >> >
>> >> > After taking a second look at this sentence, I find this wording
>> >> > being
>> >> > loaded and antagonizing. It was unprofessional, and I apologize for
>> >> > it.
>> >> >
>> >> > But the wish underneath was to get a clear view into what it was it
>> >> > that you wanted. That was what was mostly clouded for me in your
>> >> > replies, and that annoyed me to no end.
>> >> >
>> >> > While I must say that I would have been happy if you had told me you
>> >> > were not blocking the patch (set), I did not want a specific outcome
>> >> > out of this sentence. I just wanted you to voice your level of
>> >> > discomfort with the patch (set) and to voice your current wishes
>> >> > regarding it. I had set my wishes on the table with the six points,
>> >> > and why I believed the patch (set) was fine as it was.
>> >> >
>> >> > That is why after I wrote this post I asked Michael what it was that
>> >> > was the procedure for cases where developers have seemingly
>> >> > irreconcilable differences in opinions regarding a patch set. I did
>> >> > not know if that was the case, but the main point was that in the
>> >> > unfortunate case that the patch was blocked, and we did not agree on
>> >> > some points heavily enough that we could not co-operate, that the
>> >> > next
>> >> > step could be taken right away so as to not have the patch (set) sit
>> >> > there untouched for another week or two.
>> >> >
>> >> > Unfortunately, you did not respond to or touch this sentence at all,
>> >> > which I then interpreted as your comments not being blockers.
>> >>
>> >> > I hope this makes my intentions and annoyances clear.
>> >>
>> >> Afaict, it contradicts what you wrote on irc yesterday.
>> >>
>> >> > I hope that in
>> >> > the future we can continue to co-operate, and that this makes it
>> >> > clear
>> >> > that I do not have any personal grievances nor a vendetta against
>> >> > you.
>> >>
>> >> Carl Eugen
>> >
>> > Feel free to quote the parts that you think contradict.
>>
>> I was under the assumption you had read this:
>> [21:26:03 CET] <durandal_1707> carl just officially approved your
>> patch with single condition to mention ticket #7347
>>
>> But re-reading it, there was no indication you actually understood
>> what Paul wrote (or even read it), so sorry if I was wrong.
>>
>
> Yes, that specific line I had no interest in. I was tired, and the
> ticket was not in my opinion getting fixed with this, as only after we
> got the Dolby Vision profile 5 color space reverse engineered would we
> actually have these clips properly playing (outside of hardware
> decoding paths specifically meant for Dolby Vision). I had commented
> in a way on the mailing list thread towards that e-mail that I thought
> made it clear that I would not be adding the ticket identifier

> (esp. not at the eleventh hour, which it really did feel like to me at that
> point).

No, November 6th is not the eleventh hour.

> For the record, me and Rodger had already worked on grasping what
> standard ICtCp was on the mpv development channel (and Rodger with
> Niklas already had a patch around which I still have had not the time
> to review on that side of open source), and that seemed to not be the
> thing (so the marketing text in Dolby's specification about it being
> proprietary in some way was not a lie).

Carl Eugen
Jan Ekström Dec. 18, 2018, 6:16 p.m.
On Tue, Dec 18, 2018 at 8:05 PM Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
>
> 2018-12-18 18:38 GMT+01:00, Jan Ekström <jeebjp@gmail.com>:
> > On Tue, Dec 18, 2018 at 7:30 PM Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
> >>
> >> 2018-12-18 18:24 GMT+01:00, Jan Ekström <jeebjp@gmail.com>:
> >> > On Tue, Dec 18, 2018 at 7:21 PM Carl Eugen Hoyos <ceffmpeg@gmail.com>
> >> > wrote:
> >> >>
> >> >> 2018-12-18 18:17 GMT+01:00, Jan Ekström <jeebjp@gmail.com>:
> >> >> > On Mon, Dec 17, 2018 at 10:17 PM Jan Ekström <jeebjp@gmail.com>
> >> >> > wrote:
> >> >> >>
> >> >> >> On Mon, Dec 17, 2018 at 3:47 PM Carl Eugen Hoyos
> >> >> >> <ceffmpeg@gmail.com>
> >> >> >> wrote:
> >> >> >> >
> >> >> >> > 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
> >> >> >>
> >> >> >> Unfortunately I have no idea what samples Vittorio does or does not
> >> >> >> possess, he has only mentioned off-hand that he might able to get
> >> >> >> hold
> >> >> >> of some if required. And since you were the one requiring them, I
> >> >> >> pointed you towards him.
> >> >> >>
> >> >> >> For myself, I am happy with the following points regarding this:
> >> >> >> 1. The identifiers are registered at the MPEG-4 RA.
> >> >> >> 2. There is a proper specification for these mappings that is
> >> >> >> seemingly kept up-to-date.
> >> >> >> 3. The mappings specification specifically notes that the only
> >> >> >> difference between the AVC and HEVC identifiers are the semantics
> >> >> >> mentioned in ISO/IEC 14496-15. We already have all of the
> >> >> >> identifiers
> >> >> >> specified which these mappings are based upon, so those semantics
> >> >> >> should not matter to us (and if they do, we have already broken
> >> >> >> those
> >> >> >> constraints at this point).
> >> >> >> 4. The mapping specification specifically notes that the given AVC
> >> >> >> and
> >> >> >> HEVC identifiers must also include the standard avcC and hvcC boxes
> >> >> >> so
> >> >> >> that they can be decoded normally without any additional custom
> >> >> >> code.
> >> >> >> 5. We have samples for at least one of the four identifiers that
> >> >> >> matches points 1 to 4.
> >> >> >> 6. Android, Chromium, VLC among others have already implemented
> >> >> >> these
> >> >> >> identifiers in the same way.
> >> >> >>
> >> >> >> Now, if you are not happy with these points, then please clearly
> >> >> >> state
> >> >> >> that you are blocking any and all additional identifier additions -
> >> >> >> no
> >> >> >> matter how specified - as long as there are no samples on hand for
> >> >> >> them.
> >> >> >
> >> >> > After taking a second look at this sentence, I find this wording
> >> >> > being
> >> >> > loaded and antagonizing. It was unprofessional, and I apologize for
> >> >> > it.
> >> >> >
> >> >> > But the wish underneath was to get a clear view into what it was it
> >> >> > that you wanted. That was what was mostly clouded for me in your
> >> >> > replies, and that annoyed me to no end.
> >> >> >
> >> >> > While I must say that I would have been happy if you had told me you
> >> >> > were not blocking the patch (set), I did not want a specific outcome
> >> >> > out of this sentence. I just wanted you to voice your level of
> >> >> > discomfort with the patch (set) and to voice your current wishes
> >> >> > regarding it. I had set my wishes on the table with the six points,
> >> >> > and why I believed the patch (set) was fine as it was.
> >> >> >
> >> >> > That is why after I wrote this post I asked Michael what it was that
> >> >> > was the procedure for cases where developers have seemingly
> >> >> > irreconcilable differences in opinions regarding a patch set. I did
> >> >> > not know if that was the case, but the main point was that in the
> >> >> > unfortunate case that the patch was blocked, and we did not agree on
> >> >> > some points heavily enough that we could not co-operate, that the
> >> >> > next
> >> >> > step could be taken right away so as to not have the patch (set) sit
> >> >> > there untouched for another week or two.
> >> >> >
> >> >> > Unfortunately, you did not respond to or touch this sentence at all,
> >> >> > which I then interpreted as your comments not being blockers.
> >> >>
> >> >> > I hope this makes my intentions and annoyances clear.
> >> >>
> >> >> Afaict, it contradicts what you wrote on irc yesterday.
> >> >>
> >> >> > I hope that in
> >> >> > the future we can continue to co-operate, and that this makes it
> >> >> > clear
> >> >> > that I do not have any personal grievances nor a vendetta against
> >> >> > you.
> >> >>
> >> >> Carl Eugen
> >> >
> >> > Feel free to quote the parts that you think contradict.
> >>
> >> I was under the assumption you had read this:
> >> [21:26:03 CET] <durandal_1707> carl just officially approved your
> >> patch with single condition to mention ticket #7347
> >>
> >> But re-reading it, there was no indication you actually understood
> >> what Paul wrote (or even read it), so sorry if I was wrong.
> >>
> >
> > Yes, that specific line I had no interest in. I was tired, and the
> > ticket was not in my opinion getting fixed with this, as only after we
> > got the Dolby Vision profile 5 color space reverse engineered would we
> > actually have these clips properly playing (outside of hardware
> > decoding paths specifically meant for Dolby Vision). I had commented
> > in a way on the mailing list thread towards that e-mail that I thought
> > made it clear that I would not be adding the ticket identifier
>
> > (esp. not at the eleventh hour, which it really did feel like to me at that
> > point).
>
> No, November 6th is not the eleventh hour.
>

Emphasis on the the "did feel like <IT> to me at that point" part of
the sentence. Also I would have really preferred it if you could have
put all these points into the discussion when I requested confirmation
on whether you were blocking the patch (set) or not, as I already
noted in my previous e-mail.

Jan
Carl Eugen Hoyos Dec. 18, 2018, 6:19 p.m.
2018-12-18 19:16 GMT+01:00, Jan Ekström <jeebjp@gmail.com>:
> On Tue, Dec 18, 2018 at 8:05 PM Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
>>
>> 2018-12-18 18:38 GMT+01:00, Jan Ekström <jeebjp@gmail.com>:
>> > On Tue, Dec 18, 2018 at 7:30 PM Carl Eugen Hoyos <ceffmpeg@gmail.com>
>> > wrote:
>> >>
>> >> 2018-12-18 18:24 GMT+01:00, Jan Ekström <jeebjp@gmail.com>:
>> >> > On Tue, Dec 18, 2018 at 7:21 PM Carl Eugen Hoyos <ceffmpeg@gmail.com>
>> >> > wrote:
>> >> >>
>> >> >> 2018-12-18 18:17 GMT+01:00, Jan Ekström <jeebjp@gmail.com>:
>> >> >> > On Mon, Dec 17, 2018 at 10:17 PM Jan Ekström <jeebjp@gmail.com>
>> >> >> > wrote:
>> >> >> >>
>> >> >> >> On Mon, Dec 17, 2018 at 3:47 PM Carl Eugen Hoyos
>> >> >> >> <ceffmpeg@gmail.com>
>> >> >> >> wrote:
>> >> >> >> >
>> >> >> >> > 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
>> >> >> >>
>> >> >> >> Unfortunately I have no idea what samples Vittorio does or does
>> >> >> >> not
>> >> >> >> possess, he has only mentioned off-hand that he might able to get
>> >> >> >> hold
>> >> >> >> of some if required. And since you were the one requiring them, I
>> >> >> >> pointed you towards him.
>> >> >> >>
>> >> >> >> For myself, I am happy with the following points regarding this:
>> >> >> >> 1. The identifiers are registered at the MPEG-4 RA.
>> >> >> >> 2. There is a proper specification for these mappings that is
>> >> >> >> seemingly kept up-to-date.
>> >> >> >> 3. The mappings specification specifically notes that the only
>> >> >> >> difference between the AVC and HEVC identifiers are the semantics
>> >> >> >> mentioned in ISO/IEC 14496-15. We already have all of the
>> >> >> >> identifiers
>> >> >> >> specified which these mappings are based upon, so those semantics
>> >> >> >> should not matter to us (and if they do, we have already broken
>> >> >> >> those
>> >> >> >> constraints at this point).
>> >> >> >> 4. The mapping specification specifically notes that the given
>> >> >> >> AVC
>> >> >> >> and
>> >> >> >> HEVC identifiers must also include the standard avcC and hvcC
>> >> >> >> boxes
>> >> >> >> so
>> >> >> >> that they can be decoded normally without any additional custom
>> >> >> >> code.
>> >> >> >> 5. We have samples for at least one of the four identifiers that
>> >> >> >> matches points 1 to 4.
>> >> >> >> 6. Android, Chromium, VLC among others have already implemented
>> >> >> >> these
>> >> >> >> identifiers in the same way.
>> >> >> >>
>> >> >> >> Now, if you are not happy with these points, then please clearly
>> >> >> >> state
>> >> >> >> that you are blocking any and all additional identifier additions
>> >> >> >> -
>> >> >> >> no
>> >> >> >> matter how specified - as long as there are no samples on hand
>> >> >> >> for
>> >> >> >> them.
>> >> >> >
>> >> >> > After taking a second look at this sentence, I find this wording
>> >> >> > being
>> >> >> > loaded and antagonizing. It was unprofessional, and I apologize
>> >> >> > for
>> >> >> > it.
>> >> >> >
>> >> >> > But the wish underneath was to get a clear view into what it was
>> >> >> > it
>> >> >> > that you wanted. That was what was mostly clouded for me in your
>> >> >> > replies, and that annoyed me to no end.
>> >> >> >
>> >> >> > While I must say that I would have been happy if you had told me
>> >> >> > you
>> >> >> > were not blocking the patch (set), I did not want a specific
>> >> >> > outcome
>> >> >> > out of this sentence. I just wanted you to voice your level of
>> >> >> > discomfort with the patch (set) and to voice your current wishes
>> >> >> > regarding it. I had set my wishes on the table with the six
>> >> >> > points,
>> >> >> > and why I believed the patch (set) was fine as it was.
>> >> >> >
>> >> >> > That is why after I wrote this post I asked Michael what it was
>> >> >> > that
>> >> >> > was the procedure for cases where developers have seemingly
>> >> >> > irreconcilable differences in opinions regarding a patch set. I
>> >> >> > did
>> >> >> > not know if that was the case, but the main point was that in the
>> >> >> > unfortunate case that the patch was blocked, and we did not agree
>> >> >> > on
>> >> >> > some points heavily enough that we could not co-operate, that the
>> >> >> > next
>> >> >> > step could be taken right away so as to not have the patch (set)
>> >> >> > sit
>> >> >> > there untouched for another week or two.
>> >> >> >
>> >> >> > Unfortunately, you did not respond to or touch this sentence at
>> >> >> > all,
>> >> >> > which I then interpreted as your comments not being blockers.
>> >> >>
>> >> >> > I hope this makes my intentions and annoyances clear.
>> >> >>
>> >> >> Afaict, it contradicts what you wrote on irc yesterday.
>> >> >>
>> >> >> > I hope that in
>> >> >> > the future we can continue to co-operate, and that this makes it
>> >> >> > clear
>> >> >> > that I do not have any personal grievances nor a vendetta against
>> >> >> > you.
>> >> >>
>> >> >> Carl Eugen
>> >> >
>> >> > Feel free to quote the parts that you think contradict.
>> >>
>> >> I was under the assumption you had read this:
>> >> [21:26:03 CET] <durandal_1707> carl just officially approved your
>> >> patch with single condition to mention ticket #7347
>> >>
>> >> But re-reading it, there was no indication you actually understood
>> >> what Paul wrote (or even read it), so sorry if I was wrong.
>> >>
>> >
>> > Yes, that specific line I had no interest in. I was tired, and the
>> > ticket was not in my opinion getting fixed with this, as only after we
>> > got the Dolby Vision profile 5 color space reverse engineered would we
>> > actually have these clips properly playing (outside of hardware
>> > decoding paths specifically meant for Dolby Vision). I had commented
>> > in a way on the mailing list thread towards that e-mail that I thought
>> > made it clear that I would not be adding the ticket identifier
>>
>> > (esp. not at the eleventh hour, which it really did feel like to me at
>> > that
>> > point).
>>
>> No, November 6th is not the eleventh hour.
>>
>
> Emphasis on the the "did feel like <IT> to me at that point" part of
> the sentence. Also I would have really preferred it if you could have
> put all these points into the discussion when I requested confirmation
> on whether you were blocking the patch (set) or not, as I already
> noted in my previous e-mail.

The e-mail in which you requested confirmation (which one was
it?) may have been so long and contained so many points that
I got distracted and didn't realize I had to comment, possibly
because I considered my request so simple.

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 */