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

Jan Ekström jeebjp at gmail.com
Mon Dec 17 09:39:02 EET 2018


On Mon, Dec 17, 2018, 08:58 Jan Ekström <jeebjp at gmail.com wrote:

>
>
> On Mon, Dec 17, 2018, 03:02 Carl Eugen Hoyos <ceffmpeg at gmail.com wrote:
>
>> 2018-12-17 1:58 GMT+01:00, Jan Ekström <jeebjp at gmail.com>:
>> > On Mon, Dec 10, 2018 at 12:13 AM Michael Niedermayer
>> > <michael at 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 at gmail.com> wrote:
>> >> > >
>> >> > > On Mon, Dec 3, 2018 at 3:19 AM Jan Ekström <jeebjp at gmail.com>
>> wrote:
>> >> > > >
>> >> > > > From: Rodger Combs <rodger.combs at 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

>


More information about the ffmpeg-devel mailing list