[FFmpeg-devel] [PATCH 1/2 v3] lavf/isom: add Dolby Vision sample entry codes for HEVC and H.264
jeebjp at gmail.com
Tue Dec 18 19:17:38 EET 2018
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
After taking a second look at this sentence, I find this wording being
loaded and antagonizing. It was unprofessional, and I apologize for
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.
More information about the ffmpeg-devel