[FFmpeg-devel] [PATCH 1/2 v3] lavf/isom: add Dolby Vision sample entry codes for HEVC and H.264
Carl Eugen Hoyos
ceffmpeg at gmail.com
Tue Dec 18 19:20:51 EET 2018
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
More information about the ffmpeg-devel
mailing list