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

[Jan Ekström]

On Tue, Dec 18, 2018 at 7:30 PM Carl Eugen Hoyos <ceffmpeg at gmail.com> wrote:
>
> 2018-12-18 18:24 GMT+01:00, Jan Ekström <jeebjp at gmail.com>:
> > On Tue, Dec 18, 2018 at 7:21 PM Carl Eugen Hoyos <ceffmpeg at gmail.com> wrote:
> >>
> >> 2018-12-18 18:17 GMT+01:00, Jan Ekström <jeebjp at gmail.com>:
> >> > On Mon, Dec 17, 2018 at 10:17 PM Jan Ekström <jeebjp at gmail.com> wrote:
> >> >>
> >> >> 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.
> >> >
> >> > 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