[FFmpeg-devel] [PATCH 1/2 v3] lavf/isom: add Dolby Vision sample entry codes for HEVC and H.264
jeebjp at gmail.com
Mon Dec 17 22:30:31 EET 2018
On Mon, Dec 17, 2018 at 10:23 PM Carl Eugen Hoyos <ceffmpeg at gmail.com> wrote:
> 2018-12-17 21:17 GMT+01:00, Jan Ekström <jeebjp at gmail.com>:
> > On Mon, Dec 17, 2018 at 3:47 PM Carl Eugen Hoyos <ceffmpeg at gmail.com> wrote:
> >> 2018-12-17 7:58 GMT+01:00, Jan Ekström <jeebjp at gmail.com>:
> >> > 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>:
> >> >> > 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).
More information about the ffmpeg-devel