| Message ID | 20181203011919.8354-1-jeebjp@gmail.com |
|---|---|
| State | Accepted |
| Headers | show |
On Mon, Dec 3, 2018 at 3:19 AM Jan Ekström <jeebjp@gmail.com> wrote: > > From: Rodger Combs <rodger.combs@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
On Wed, Dec 5, 2018 at 7:13 PM Jan Ekström <jeebjp@gmail.com> wrote: > > On Mon, Dec 3, 2018 at 3:19 AM Jan Ekström <jeebjp@gmail.com> wrote: > > > > From: Rodger Combs <rodger.combs@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. Best regards, Jan
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@gmail.com> wrote: > > > > On Mon, Dec 3, 2018 at 3:19 AM Jan Ekström <jeebjp@gmail.com> wrote: > > > > > > From: Rodger Combs <rodger.combs@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 [...]
On Mon, Dec 10, 2018 at 12:13 AM Michael Niedermayer <michael@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@gmail.com> wrote: > > > > > > On Mon, Dec 3, 2018 at 3:19 AM Jan Ekström <jeebjp@gmail.com> wrote: > > > > > > > > From: Rodger Combs <rodger.combs@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 and we're just implementing things according to the specification - which is how other projects seem to have done it as well. Jan
2018-12-17 1:58 GMT+01:00, Jan Ekström <jeebjp@gmail.com>: > On Mon, Dec 10, 2018 at 12:13 AM Michael Niedermayer > <michael@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@gmail.com> wrote: >> > > >> > > On Mon, Dec 3, 2018 at 3:19 AM Jan Ekström <jeebjp@gmail.com> wrote: >> > > > >> > > > From: Rodger Combs <rodger.combs@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? > 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? Thank you, Carl Eugen
On Mon, Dec 17, 2018, 03:02 Carl Eugen Hoyos <ceffmpeg@gmail.com wrote: > 2018-12-17 1:58 GMT+01:00, Jan Ekström <jeebjp@gmail.com>: > > On Mon, Dec 10, 2018 at 12:13 AM Michael Niedermayer > > <michael@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@gmail.com> wrote: > >> > > > >> > > On Mon, Dec 3, 2018 at 3:19 AM Jan Ekström <jeebjp@gmail.com> > wrote: > >> > > > > >> > > > From: Rodger Combs <rodger.combs@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"? Jan
On Mon, Dec 17, 2018, 08:58 Jan Ekström <jeebjp@gmail.com wrote: > > > On Mon, Dec 17, 2018, 03:02 Carl Eugen Hoyos <ceffmpeg@gmail.com wrote: > >> 2018-12-17 1:58 GMT+01:00, Jan Ekström <jeebjp@gmail.com>: >> > On Mon, Dec 10, 2018 at 12:13 AM Michael Niedermayer >> > <michael@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@gmail.com> wrote: >> >> > > >> >> > > On Mon, Dec 3, 2018 at 3:19 AM Jan Ekström <jeebjp@gmail.com> >> wrote: >> >> > > > >> >> > > > From: Rodger Combs <rodger.combs@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 >
2018-12-17 7:58 GMT+01:00, Jan Ekström <jeebjp@gmail.com>: > On Mon, Dec 17, 2018, 03:02 Carl Eugen Hoyos <ceffmpeg@gmail.com wrote: > >> 2018-12-17 1:58 GMT+01:00, Jan Ekström <jeebjp@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
On Mon, Dec 17, 2018 at 3:47 PM Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote: > > 2018-12-17 7:58 GMT+01:00, Jan Ekström <jeebjp@gmail.com>: > > On Mon, Dec 17, 2018, 03:02 Carl Eugen Hoyos <ceffmpeg@gmail.com wrote: > > > >> 2018-12-17 1:58 GMT+01:00, Jan Ekström <jeebjp@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. Best regards, Jan
2018-12-17 21:17 GMT+01:00, Jan Ekström <jeebjp@gmail.com>: > On Mon, Dec 17, 2018 at 3:47 PM Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote: >> >> 2018-12-17 7:58 GMT+01:00, Jan Ekström <jeebjp@gmail.com>: >> > On Mon, Dec 17, 2018, 03:02 Carl Eugen Hoyos <ceffmpeg@gmail.com wrote: >> > >> >> 2018-12-17 1:58 GMT+01:00, Jan Ekström <jeebjp@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
On Mon, Dec 17, 2018 at 10:23 PM Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote: > > 2018-12-17 21:17 GMT+01:00, Jan Ekström <jeebjp@gmail.com>: > > On Mon, Dec 17, 2018 at 3:47 PM Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote: > >> > >> 2018-12-17 7:58 GMT+01:00, Jan Ekström <jeebjp@gmail.com>: > >> > On Mon, Dec 17, 2018, 03:02 Carl Eugen Hoyos <ceffmpeg@gmail.com wrote: > >> > > >> >> 2018-12-17 1:58 GMT+01:00, Jan Ekström <jeebjp@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). Jan
2018-12-17 21:30 GMT+01:00, Jan Ekström <jeebjp@gmail.com>: > On Mon, Dec 17, 2018 at 10:23 PM Carl Eugen Hoyos <ceffmpeg@gmail.com> > wrote: >> >> 2018-12-17 21:17 GMT+01:00, Jan Ekström <jeebjp@gmail.com>: >> > On Mon, Dec 17, 2018 at 3:47 PM Carl Eugen Hoyos <ceffmpeg@gmail.com> >> > wrote: >> >> >> >> 2018-12-17 7:58 GMT+01:00, Jan Ekström <jeebjp@gmail.com>: >> >> > On Mon, Dec 17, 2018, 03:02 Carl Eugen Hoyos <ceffmpeg@gmail.com >> >> > wrote: >> >> > >> >> >> 2018-12-17 1:58 GMT+01:00, Jan Ekström <jeebjp@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. > > The sample last linked in that ticket was supposedly MPEG-TS for the > other HEVC identifier, not ISOBMFF. Why do you think so? Which sample did you test? Carl Eugen
On Mon, Dec 17, 2018 at 10:49 PM Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote: > > 2018-12-17 21:30 GMT+01:00, Jan Ekström <jeebjp@gmail.com>: > > On Mon, Dec 17, 2018 at 10:23 PM Carl Eugen Hoyos <ceffmpeg@gmail.com> > > wrote: > >> > >> 2018-12-17 21:17 GMT+01:00, Jan Ekström <jeebjp@gmail.com>: > >> > On Mon, Dec 17, 2018 at 3:47 PM Carl Eugen Hoyos <ceffmpeg@gmail.com> > >> > wrote: > >> >> > >> >> 2018-12-17 7:58 GMT+01:00, Jan Ekström <jeebjp@gmail.com>: > >> >> > On Mon, Dec 17, 2018, 03:02 Carl Eugen Hoyos <ceffmpeg@gmail.com > >> >> > wrote: > >> >> > > >> >> >> 2018-12-17 1:58 GMT+01:00, Jan Ekström <jeebjp@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. > > > > The sample last linked in that ticket was supposedly MPEG-TS for the > > other HEVC identifier, not ISOBMFF. > > Why do you think so? Which sample did you test? > From #7347 > Dobly Vision transport stream with codec tag "dvhe" can be found under: > http://4kmedia.org/tag/dolby-vision/ The site also notes that it's supposed to be a transport stream. I did not look further. Jan
2018-12-17 21:52 GMT+01:00, Jan Ekström <jeebjp@gmail.com>: > On Mon, Dec 17, 2018 at 10:49 PM Carl Eugen Hoyos <ceffmpeg@gmail.com> > wrote: >> >> 2018-12-17 21:30 GMT+01:00, Jan Ekström <jeebjp@gmail.com>: >> > On Mon, Dec 17, 2018 at 10:23 PM Carl Eugen Hoyos <ceffmpeg@gmail.com> >> > wrote: >> >> >> >> 2018-12-17 21:17 GMT+01:00, Jan Ekström <jeebjp@gmail.com>: >> >> > On Mon, Dec 17, 2018 at 3:47 PM Carl Eugen Hoyos <ceffmpeg@gmail.com> >> >> > wrote: >> >> >> >> >> >> 2018-12-17 7:58 GMT+01:00, Jan Ekström <jeebjp@gmail.com>: >> >> >> > On Mon, Dec 17, 2018, 03:02 Carl Eugen Hoyos <ceffmpeg@gmail.com >> >> >> > wrote: >> >> >> > >> >> >> >> 2018-12-17 1:58 GMT+01:00, Jan Ekström <jeebjp@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. >> > >> > The sample last linked in that ticket was supposedly MPEG-TS for the >> > other HEVC identifier, not ISOBMFF. >> >> Why do you think so? Which sample did you test? >> > > From #7347 >> Dobly Vision transport stream with codec tag "dvhe" can be found under: >> http://4kmedia.org/tag/dolby-vision/ > > The site also notes that it's supposed to be a transport stream. I did > not look further. Then please allow me to once again suggest testing (at least if you trust neither me nor Igor). Carl Eugen
On Mon, Dec 17, 2018 at 10:57 PM Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote: > > 2018-12-17 21:52 GMT+01:00, Jan Ekström <jeebjp@gmail.com>: > > On Mon, Dec 17, 2018 at 10:49 PM Carl Eugen Hoyos <ceffmpeg@gmail.com> > > wrote: > >> > >> 2018-12-17 21:30 GMT+01:00, Jan Ekström <jeebjp@gmail.com>: > >> > On Mon, Dec 17, 2018 at 10:23 PM Carl Eugen Hoyos <ceffmpeg@gmail.com> > >> > wrote: > >> >> > >> >> 2018-12-17 21:17 GMT+01:00, Jan Ekström <jeebjp@gmail.com>: > >> >> > On Mon, Dec 17, 2018 at 3:47 PM Carl Eugen Hoyos <ceffmpeg@gmail.com> > >> >> > wrote: > >> >> >> > >> >> >> 2018-12-17 7:58 GMT+01:00, Jan Ekström <jeebjp@gmail.com>: > >> >> >> > On Mon, Dec 17, 2018, 03:02 Carl Eugen Hoyos <ceffmpeg@gmail.com > >> >> >> > wrote: > >> >> >> > > >> >> >> >> 2018-12-17 1:58 GMT+01:00, Jan Ekström <jeebjp@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. > >> > > >> > The sample last linked in that ticket was supposedly MPEG-TS for the > >> > other HEVC identifier, not ISOBMFF. > >> > >> Why do you think so? Which sample did you test? > >> > > > > From #7347 > >> Dobly Vision transport stream with codec tag "dvhe" can be found under: > >> http://4kmedia.org/tag/dolby-vision/ > > > > The site also notes that it's supposed to be a transport stream. I did > > not look further. > > Then please allow me to once again suggest testing (at least if > you trust neither me nor Igor). > > Carl Eugen That was a quote FROM Igor's post (https://trac.ffmpeg.org/ticket/7347#comment:12). If he and the site mentioned it wrong then please just note that. Jan
On Mon, Dec 17, 2018 at 11:02 PM Jan Ekström <jeebjp@gmail.com> wrote: > > On Mon, Dec 17, 2018 at 10:57 PM Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote: > > > > 2018-12-17 21:52 GMT+01:00, Jan Ekström <jeebjp@gmail.com>: > > > On Mon, Dec 17, 2018 at 10:49 PM Carl Eugen Hoyos <ceffmpeg@gmail.com> > > > wrote: > > >> > > >> 2018-12-17 21:30 GMT+01:00, Jan Ekström <jeebjp@gmail.com>: > > >> > On Mon, Dec 17, 2018 at 10:23 PM Carl Eugen Hoyos <ceffmpeg@gmail.com> > > >> > wrote: > > >> >> > > >> >> 2018-12-17 21:17 GMT+01:00, Jan Ekström <jeebjp@gmail.com>: > > >> >> > On Mon, Dec 17, 2018 at 3:47 PM Carl Eugen Hoyos <ceffmpeg@gmail.com> > > >> >> > wrote: > > >> >> >> > > >> >> >> 2018-12-17 7:58 GMT+01:00, Jan Ekström <jeebjp@gmail.com>: > > >> >> >> > On Mon, Dec 17, 2018, 03:02 Carl Eugen Hoyos <ceffmpeg@gmail.com > > >> >> >> > wrote: > > >> >> >> > > > >> >> >> >> 2018-12-17 1:58 GMT+01:00, Jan Ekström <jeebjp@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. > > >> > > > >> > The sample last linked in that ticket was supposedly MPEG-TS for the > > >> > other HEVC identifier, not ISOBMFF. > > >> > > >> Why do you think so? Which sample did you test? > > >> > > > > > > From #7347 > > >> Dobly Vision transport stream with codec tag "dvhe" can be found under: > > >> http://4kmedia.org/tag/dolby-vision/ > > > > > > The site also notes that it's supposed to be a transport stream. I did > > > not look further. > > > > Then please allow me to once again suggest testing (at least if > > you trust neither me nor Igor). > > > > Carl Eugen > > That was a quote FROM Igor's post > (https://trac.ffmpeg.org/ticket/7347#comment:12). If he and the site > mentioned it wrong then please just note that. > > Jan OK, so it is ISOBMFF and not MPEG-TS unlike Igor and the site noted. Thank you, now there is a sample. I think this is the sample that Rodger coded this patch set originally against when we were hacking on this stuff around mpv. Jan
2018-12-17 22:02 GMT+01:00, Jan Ekström <jeebjp@gmail.com>: > On Mon, Dec 17, 2018 at 10:57 PM Carl Eugen Hoyos <ceffmpeg@gmail.com> > wrote: >> >> 2018-12-17 21:52 GMT+01:00, Jan Ekström <jeebjp@gmail.com>: >> > On Mon, Dec 17, 2018 at 10:49 PM Carl Eugen Hoyos <ceffmpeg@gmail.com> >> > wrote: >> >> >> >> 2018-12-17 21:30 GMT+01:00, Jan Ekström <jeebjp@gmail.com>: >> >> > On Mon, Dec 17, 2018 at 10:23 PM Carl Eugen Hoyos >> >> > <ceffmpeg@gmail.com> >> >> > wrote: >> >> >> >> >> >> 2018-12-17 21:17 GMT+01:00, Jan Ekström <jeebjp@gmail.com>: >> >> >> > On Mon, Dec 17, 2018 at 3:47 PM Carl Eugen Hoyos >> >> >> > <ceffmpeg@gmail.com> >> >> >> > wrote: >> >> >> >> >> >> >> >> 2018-12-17 7:58 GMT+01:00, Jan Ekström <jeebjp@gmail.com>: >> >> >> >> > On Mon, Dec 17, 2018, 03:02 Carl Eugen Hoyos >> >> >> >> > <ceffmpeg@gmail.com >> >> >> >> > wrote: >> >> >> >> > >> >> >> >> >> 2018-12-17 1:58 GMT+01:00, Jan Ekström <jeebjp@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. >> >> > >> >> > The sample last linked in that ticket was supposedly MPEG-TS for the >> >> > other HEVC identifier, not ISOBMFF. >> >> >> >> Why do you think so? Which sample did you test? >> >> >> > >> > From #7347 >> >> Dobly Vision transport stream with codec tag "dvhe" can be found under: >> >> http://4kmedia.org/tag/dolby-vision/ >> > >> > The site also notes that it's supposed to be a transport stream. I did >> > not look further. >> >> Then please allow me to once again suggest testing (at least if >> you trust neither me nor Igor). > That was a quote FROM Igor's post > (https://trac.ffmpeg.org/ticket/7347#comment:12). If he and the site > mentioned it wrong then please just note that. Which reminds me that you could mention him too in the commit message: https://patchwork.ffmpeg.org/patch/10023/ Carl Eugen
On Mon, Dec 17, 2018 at 11:11 PM Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote: > > 2018-12-17 22:02 GMT+01:00, Jan Ekström <jeebjp@gmail.com>: > > On Mon, Dec 17, 2018 at 10:57 PM Carl Eugen Hoyos <ceffmpeg@gmail.com> > > wrote: > >> > >> 2018-12-17 21:52 GMT+01:00, Jan Ekström <jeebjp@gmail.com>: > >> > On Mon, Dec 17, 2018 at 10:49 PM Carl Eugen Hoyos <ceffmpeg@gmail.com> > >> > wrote: > >> >> > >> >> 2018-12-17 21:30 GMT+01:00, Jan Ekström <jeebjp@gmail.com>: > >> >> > On Mon, Dec 17, 2018 at 10:23 PM Carl Eugen Hoyos > >> >> > <ceffmpeg@gmail.com> > >> >> > wrote: > >> >> >> > >> >> >> 2018-12-17 21:17 GMT+01:00, Jan Ekström <jeebjp@gmail.com>: > >> >> >> > On Mon, Dec 17, 2018 at 3:47 PM Carl Eugen Hoyos > >> >> >> > <ceffmpeg@gmail.com> > >> >> >> > wrote: > >> >> >> >> > >> >> >> >> 2018-12-17 7:58 GMT+01:00, Jan Ekström <jeebjp@gmail.com>: > >> >> >> >> > On Mon, Dec 17, 2018, 03:02 Carl Eugen Hoyos > >> >> >> >> > <ceffmpeg@gmail.com > >> >> >> >> > wrote: > >> >> >> >> > > >> >> >> >> >> 2018-12-17 1:58 GMT+01:00, Jan Ekström <jeebjp@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. > >> >> > > >> >> > The sample last linked in that ticket was supposedly MPEG-TS for the > >> >> > other HEVC identifier, not ISOBMFF. > >> >> > >> >> Why do you think so? Which sample did you test? > >> >> > >> > > >> > From #7347 > >> >> Dobly Vision transport stream with codec tag "dvhe" can be found under: > >> >> http://4kmedia.org/tag/dolby-vision/ > >> > > >> > The site also notes that it's supposed to be a transport stream. I did > >> > not look further. > >> > >> Then please allow me to once again suggest testing (at least if > >> you trust neither me nor Igor). > > > That was a quote FROM Igor's post > > (https://trac.ffmpeg.org/ticket/7347#comment:12). If he and the site > > mentioned it wrong then please just note that. > > Which reminds me that you could mention him too in > the commit message: > https://patchwork.ffmpeg.org/patch/10023/ > > Carl Eugen I did not see that patch when taking the initial single-identifier patch from Rodger, and even compared to Rodger's original patch me adding the other identifiers and adding the MPEG-4 RA identifier description comments and proper commit message at that point keep very little of what was there to begin with. Unless there is something substantial, I would rather just get done with this pain that is trying to get a seemingly darn simple patch through review. At this point I hate humans, I hate communication. This is not fun. If you got any enjoyment of this, I am very happy for you. Jan
2018-12-17 22:18 GMT+01:00, Jan Ekström <jeebjp@gmail.com>: > On Mon, Dec 17, 2018 at 11:11 PM Carl Eugen Hoyos <ceffmpeg@gmail.com> > wrote: >> >> 2018-12-17 22:02 GMT+01:00, Jan Ekström <jeebjp@gmail.com>: >> > On Mon, Dec 17, 2018 at 10:57 PM Carl Eugen Hoyos <ceffmpeg@gmail.com> >> > wrote: >> >> >> >> 2018-12-17 21:52 GMT+01:00, Jan Ekström <jeebjp@gmail.com>: >> >> > On Mon, Dec 17, 2018 at 10:49 PM Carl Eugen Hoyos >> >> > <ceffmpeg@gmail.com> >> >> > wrote: >> >> >> >> >> >> 2018-12-17 21:30 GMT+01:00, Jan Ekström <jeebjp@gmail.com>: >> >> >> > On Mon, Dec 17, 2018 at 10:23 PM Carl Eugen Hoyos >> >> >> > <ceffmpeg@gmail.com> >> >> >> > wrote: >> >> >> >> >> >> >> >> 2018-12-17 21:17 GMT+01:00, Jan Ekström <jeebjp@gmail.com>: >> >> >> >> > On Mon, Dec 17, 2018 at 3:47 PM Carl Eugen Hoyos >> >> >> >> > <ceffmpeg@gmail.com> >> >> >> >> > wrote: >> >> >> >> >> >> >> >> >> >> 2018-12-17 7:58 GMT+01:00, Jan Ekström <jeebjp@gmail.com>: >> >> >> >> >> > On Mon, Dec 17, 2018, 03:02 Carl Eugen Hoyos >> >> >> >> >> > <ceffmpeg@gmail.com >> >> >> >> >> > wrote: >> >> >> >> >> > >> >> >> >> >> >> 2018-12-17 1:58 GMT+01:00, Jan Ekström <jeebjp@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. >> >> >> > >> >> >> > The sample last linked in that ticket was supposedly MPEG-TS for >> >> >> > the >> >> >> > other HEVC identifier, not ISOBMFF. >> >> >> >> >> >> Why do you think so? Which sample did you test? >> >> >> >> >> > >> >> > From #7347 >> >> >> Dobly Vision transport stream with codec tag "dvhe" can be found >> >> >> under: >> >> >> http://4kmedia.org/tag/dolby-vision/ >> >> > >> >> > The site also notes that it's supposed to be a transport stream. I >> >> > did >> >> > not look further. >> >> >> >> Then please allow me to once again suggest testing (at least if >> >> you trust neither me nor Igor). >> >> > That was a quote FROM Igor's post >> > (https://trac.ffmpeg.org/ticket/7347#comment:12). If he and the site >> > mentioned it wrong then please just note that. >> >> Which reminds me that you could mention him too in >> the commit message: >> https://patchwork.ffmpeg.org/patch/10023/ >> >> Carl Eugen > > I did not see that patch when taking the initial single-identifier I know (actually: I assumed so) and wrote that in my first comment. > patch from Rodger, and even compared to Rodger's original patch me > adding the other identifiers and adding the MPEG-4 RA identifier > description comments and proper commit message at that point keep very > little of what was there to begin with. > > Unless there is something substantial, I would rather just get done > with this pain that is trying to get a seemingly darn simple patch > through review. At this point I hate humans, I hate communication. > This is not fun. If you got any enjoyment of this, I am very happy for > you. Sadly not, on the contrary. Carl Eugen
On 12/3/18, Jan Ekström <jeebjp@gmail.com> wrote: > From: Rodger Combs <rodger.combs@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). > --- > libavformat/isom.c | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/libavformat/isom.c b/libavformat/isom.c > index ca9d22e4f7..f7e1654484 100644 > --- a/libavformat/isom.c > +++ b/libavformat/isom.c > @@ -163,6 +163,8 @@ const AVCodecTag ff_codec_movvideo_tags[] = { > > { AV_CODEC_ID_HEVC, MKTAG('h', 'e', 'v', '1') }, /* HEVC/H.265 which > indicates parameter sets may be in ES */ > { AV_CODEC_ID_HEVC, MKTAG('h', 'v', 'c', '1') }, /* HEVC/H.265 which > indicates parameter sets shall not be in ES */ > + { AV_CODEC_ID_HEVC, MKTAG('d', 'v', 'h', 'e') }, /* HEVC-based Dolby > Vision derived from hev1 */ > + /* dvh1 is handled > within mov.c */ > > { AV_CODEC_ID_H264, MKTAG('a', 'v', 'c', '1') }, /* AVC-1/H.264 */ > { AV_CODEC_ID_H264, MKTAG('a', 'v', 'c', '2') }, > @@ -185,6 +187,8 @@ const AVCodecTag ff_codec_movvideo_tags[] = { > { AV_CODEC_ID_H264, MKTAG('r', 'v', '6', '4') }, /* X-Com Radvision */ > { AV_CODEC_ID_H264, MKTAG('x', 'a', 'l', 'g') }, /* XAVC-L HD422 > produced by FCP */ > { AV_CODEC_ID_H264, MKTAG('a', 'v', 'l', 'g') }, /* Panasonic P2 > AVC-LongG */ > + { AV_CODEC_ID_H264, MKTAG('d', 'v', 'a', 'v') }, /* AVC-based Dolby > Vision derived from avc1 */ > + { AV_CODEC_ID_H264, MKTAG('d', 'v', 'a', '1') }, /* AVC-based Dolby > Vision derived from avc3 */ > > { AV_CODEC_ID_VP8, MKTAG('v', 'p', '0', '8') }, /* VP8 */ > { AV_CODEC_ID_VP9, MKTAG('v', 'p', '0', '9') }, /* VP9 */ > -- > 2.19.2 OK
On Mon, Dec 17, 2018 at 11:23 PM Paul B Mahol <onemda@gmail.com> wrote: > > On 12/3/18, Jan Ekström <jeebjp@gmail.com> wrote: > > From: Rodger Combs <rodger.combs@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). > > --- > > libavformat/isom.c | 4 ++++ > > 1 file changed, 4 insertions(+) > > > > diff --git a/libavformat/isom.c b/libavformat/isom.c > > index ca9d22e4f7..f7e1654484 100644 > > --- a/libavformat/isom.c > > +++ b/libavformat/isom.c > > @@ -163,6 +163,8 @@ const AVCodecTag ff_codec_movvideo_tags[] = { > > > > { AV_CODEC_ID_HEVC, MKTAG('h', 'e', 'v', '1') }, /* HEVC/H.265 which > > indicates parameter sets may be in ES */ > > { AV_CODEC_ID_HEVC, MKTAG('h', 'v', 'c', '1') }, /* HEVC/H.265 which > > indicates parameter sets shall not be in ES */ > > + { AV_CODEC_ID_HEVC, MKTAG('d', 'v', 'h', 'e') }, /* HEVC-based Dolby > > Vision derived from hev1 */ > > + /* dvh1 is handled > > within mov.c */ > > > > { AV_CODEC_ID_H264, MKTAG('a', 'v', 'c', '1') }, /* AVC-1/H.264 */ > > { AV_CODEC_ID_H264, MKTAG('a', 'v', 'c', '2') }, > > @@ -185,6 +187,8 @@ const AVCodecTag ff_codec_movvideo_tags[] = { > > { AV_CODEC_ID_H264, MKTAG('r', 'v', '6', '4') }, /* X-Com Radvision */ > > { AV_CODEC_ID_H264, MKTAG('x', 'a', 'l', 'g') }, /* XAVC-L HD422 > > produced by FCP */ > > { AV_CODEC_ID_H264, MKTAG('a', 'v', 'l', 'g') }, /* Panasonic P2 > > AVC-LongG */ > > + { AV_CODEC_ID_H264, MKTAG('d', 'v', 'a', 'v') }, /* AVC-based Dolby > > Vision derived from avc1 */ > > + { AV_CODEC_ID_H264, MKTAG('d', 'v', 'a', '1') }, /* AVC-based Dolby > > Vision derived from avc3 */ > > > > { AV_CODEC_ID_VP8, MKTAG('v', 'p', '0', '8') }, /* VP8 */ > > { AV_CODEC_ID_VP9, MKTAG('v', 'p', '0', '9') }, /* VP9 */ > > -- > > 2.19.2 > > OK As it was verified to pass FATE on IRC, the patch with the comments matching the AVC identifiers (they were the other way around) was pushed. Jan
On Mon, Dec 17, 2018 at 10:17 PM Jan Ekström <jeebjp@gmail.com> wrote: > > On Mon, Dec 17, 2018 at 3:47 PM Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote: > > > > 2018-12-17 7:58 GMT+01:00, Jan Ekström <jeebjp@gmail.com>: > > > On Mon, Dec 17, 2018, 03:02 Carl Eugen Hoyos <ceffmpeg@gmail.com wrote: > > > > > >> 2018-12-17 1:58 GMT+01:00, Jan Ekström <jeebjp@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. 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. Best regards, Jan
2018-12-18 18:17 GMT+01:00, Jan Ekström <jeebjp@gmail.com>: > On Mon, Dec 17, 2018 at 10:17 PM Jan Ekström <jeebjp@gmail.com> wrote: >> >> On Mon, Dec 17, 2018 at 3:47 PM Carl Eugen Hoyos <ceffmpeg@gmail.com> >> wrote: >> > >> > 2018-12-17 7:58 GMT+01:00, Jan Ekström <jeebjp@gmail.com>: >> > > On Mon, Dec 17, 2018, 03:02 Carl Eugen Hoyos <ceffmpeg@gmail.com >> > > wrote: >> > > >> > >> 2018-12-17 1:58 GMT+01:00, Jan Ekström <jeebjp@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
On Tue, Dec 18, 2018 at 7:21 PM Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote: > > 2018-12-18 18:17 GMT+01:00, Jan Ekström <jeebjp@gmail.com>: > > On Mon, Dec 17, 2018 at 10:17 PM Jan Ekström <jeebjp@gmail.com> wrote: > >> > >> On Mon, Dec 17, 2018 at 3:47 PM Carl Eugen Hoyos <ceffmpeg@gmail.com> > >> wrote: > >> > > >> > 2018-12-17 7:58 GMT+01:00, Jan Ekström <jeebjp@gmail.com>: > >> > > On Mon, Dec 17, 2018, 03:02 Carl Eugen Hoyos <ceffmpeg@gmail.com > >> > > wrote: > >> > > > >> > >> 2018-12-17 1:58 GMT+01:00, Jan Ekström <jeebjp@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. Jan
2018-12-18 18:24 GMT+01:00, Jan Ekström <jeebjp@gmail.com>: > On Tue, Dec 18, 2018 at 7:21 PM Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote: >> >> 2018-12-18 18:17 GMT+01:00, Jan Ekström <jeebjp@gmail.com>: >> > On Mon, Dec 17, 2018 at 10:17 PM Jan Ekström <jeebjp@gmail.com> wrote: >> >> >> >> On Mon, Dec 17, 2018 at 3:47 PM Carl Eugen Hoyos <ceffmpeg@gmail.com> >> >> wrote: >> >> > >> >> > 2018-12-17 7:58 GMT+01:00, Jan Ekström <jeebjp@gmail.com>: >> >> > > On Mon, Dec 17, 2018, 03:02 Carl Eugen Hoyos <ceffmpeg@gmail.com >> >> > > wrote: >> >> > > >> >> > >> 2018-12-17 1:58 GMT+01:00, Jan Ekström <jeebjp@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. Carl Eugen
On Tue, Dec 18, 2018 at 7:30 PM Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote: > > 2018-12-18 18:24 GMT+01:00, Jan Ekström <jeebjp@gmail.com>: > > On Tue, Dec 18, 2018 at 7:21 PM Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote: > >> > >> 2018-12-18 18:17 GMT+01:00, Jan Ekström <jeebjp@gmail.com>: > >> > On Mon, Dec 17, 2018 at 10:17 PM Jan Ekström <jeebjp@gmail.com> wrote: > >> >> > >> >> On Mon, Dec 17, 2018 at 3:47 PM Carl Eugen Hoyos <ceffmpeg@gmail.com> > >> >> wrote: > >> >> > > >> >> > 2018-12-17 7:58 GMT+01:00, Jan Ekström <jeebjp@gmail.com>: > >> >> > > On Mon, Dec 17, 2018, 03:02 Carl Eugen Hoyos <ceffmpeg@gmail.com > >> >> > > wrote: > >> >> > > > >> >> > >> 2018-12-17 1:58 GMT+01:00, Jan Ekström <jeebjp@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
2018-12-18 18:38 GMT+01:00, Jan Ekström <jeebjp@gmail.com>: > On Tue, Dec 18, 2018 at 7:30 PM Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote: >> >> 2018-12-18 18:24 GMT+01:00, Jan Ekström <jeebjp@gmail.com>: >> > On Tue, Dec 18, 2018 at 7:21 PM Carl Eugen Hoyos <ceffmpeg@gmail.com> >> > wrote: >> >> >> >> 2018-12-18 18:17 GMT+01:00, Jan Ekström <jeebjp@gmail.com>: >> >> > On Mon, Dec 17, 2018 at 10:17 PM Jan Ekström <jeebjp@gmail.com> >> >> > wrote: >> >> >> >> >> >> On Mon, Dec 17, 2018 at 3:47 PM Carl Eugen Hoyos >> >> >> <ceffmpeg@gmail.com> >> >> >> wrote: >> >> >> > >> >> >> > 2018-12-17 7:58 GMT+01:00, Jan Ekström <jeebjp@gmail.com>: >> >> >> > > On Mon, Dec 17, 2018, 03:02 Carl Eugen Hoyos <ceffmpeg@gmail.com >> >> >> > > wrote: >> >> >> > > >> >> >> > >> 2018-12-17 1:58 GMT+01:00, Jan Ekström <jeebjp@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). No, November 6th is not the eleventh hour. > 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). Carl Eugen
On Tue, Dec 18, 2018 at 8:05 PM Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote: > > 2018-12-18 18:38 GMT+01:00, Jan Ekström <jeebjp@gmail.com>: > > On Tue, Dec 18, 2018 at 7:30 PM Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote: > >> > >> 2018-12-18 18:24 GMT+01:00, Jan Ekström <jeebjp@gmail.com>: > >> > On Tue, Dec 18, 2018 at 7:21 PM Carl Eugen Hoyos <ceffmpeg@gmail.com> > >> > wrote: > >> >> > >> >> 2018-12-18 18:17 GMT+01:00, Jan Ekström <jeebjp@gmail.com>: > >> >> > On Mon, Dec 17, 2018 at 10:17 PM Jan Ekström <jeebjp@gmail.com> > >> >> > wrote: > >> >> >> > >> >> >> On Mon, Dec 17, 2018 at 3:47 PM Carl Eugen Hoyos > >> >> >> <ceffmpeg@gmail.com> > >> >> >> wrote: > >> >> >> > > >> >> >> > 2018-12-17 7:58 GMT+01:00, Jan Ekström <jeebjp@gmail.com>: > >> >> >> > > On Mon, Dec 17, 2018, 03:02 Carl Eugen Hoyos <ceffmpeg@gmail.com > >> >> >> > > wrote: > >> >> >> > > > >> >> >> > >> 2018-12-17 1:58 GMT+01:00, Jan Ekström <jeebjp@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). > > No, November 6th is not the eleventh hour. > Emphasis on the the "did feel like <IT> to me at that point" part of the sentence. Also I would have really preferred it if you could have put all these points into the discussion when I requested confirmation on whether you were blocking the patch (set) or not, as I already noted in my previous e-mail. Jan
2018-12-18 19:16 GMT+01:00, Jan Ekström <jeebjp@gmail.com>: > On Tue, Dec 18, 2018 at 8:05 PM Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote: >> >> 2018-12-18 18:38 GMT+01:00, Jan Ekström <jeebjp@gmail.com>: >> > On Tue, Dec 18, 2018 at 7:30 PM Carl Eugen Hoyos <ceffmpeg@gmail.com> >> > wrote: >> >> >> >> 2018-12-18 18:24 GMT+01:00, Jan Ekström <jeebjp@gmail.com>: >> >> > On Tue, Dec 18, 2018 at 7:21 PM Carl Eugen Hoyos <ceffmpeg@gmail.com> >> >> > wrote: >> >> >> >> >> >> 2018-12-18 18:17 GMT+01:00, Jan Ekström <jeebjp@gmail.com>: >> >> >> > On Mon, Dec 17, 2018 at 10:17 PM Jan Ekström <jeebjp@gmail.com> >> >> >> > wrote: >> >> >> >> >> >> >> >> On Mon, Dec 17, 2018 at 3:47 PM Carl Eugen Hoyos >> >> >> >> <ceffmpeg@gmail.com> >> >> >> >> wrote: >> >> >> >> > >> >> >> >> > 2018-12-17 7:58 GMT+01:00, Jan Ekström <jeebjp@gmail.com>: >> >> >> >> > > On Mon, Dec 17, 2018, 03:02 Carl Eugen Hoyos >> >> >> >> > > <ceffmpeg@gmail.com >> >> >> >> > > wrote: >> >> >> >> > > >> >> >> >> > >> 2018-12-17 1:58 GMT+01:00, Jan Ekström <jeebjp@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). >> >> No, November 6th is not the eleventh hour. >> > > Emphasis on the the "did feel like <IT> to me at that point" part of > the sentence. Also I would have really preferred it if you could have > put all these points into the discussion when I requested confirmation > on whether you were blocking the patch (set) or not, as I already > noted in my previous e-mail. The e-mail in which you requested confirmation (which one was it?) may have been so long and contained so many points that I got distracted and didn't realize I had to comment, possibly because I considered my request so simple. Carl Eugen
diff --git a/libavformat/isom.c b/libavformat/isom.c index ca9d22e4f7..f7e1654484 100644 --- a/libavformat/isom.c +++ b/libavformat/isom.c @@ -163,6 +163,8 @@ const AVCodecTag ff_codec_movvideo_tags[] = { { AV_CODEC_ID_HEVC, MKTAG('h', 'e', 'v', '1') }, /* HEVC/H.265 which indicates parameter sets may be in ES */ { AV_CODEC_ID_HEVC, MKTAG('h', 'v', 'c', '1') }, /* HEVC/H.265 which indicates parameter sets shall not be in ES */ + { AV_CODEC_ID_HEVC, MKTAG('d', 'v', 'h', 'e') }, /* HEVC-based Dolby Vision derived from hev1 */ + /* dvh1 is handled within mov.c */ { AV_CODEC_ID_H264, MKTAG('a', 'v', 'c', '1') }, /* AVC-1/H.264 */ { AV_CODEC_ID_H264, MKTAG('a', 'v', 'c', '2') }, @@ -185,6 +187,8 @@ const AVCodecTag ff_codec_movvideo_tags[] = { { AV_CODEC_ID_H264, MKTAG('r', 'v', '6', '4') }, /* X-Com Radvision */ { AV_CODEC_ID_H264, MKTAG('x', 'a', 'l', 'g') }, /* XAVC-L HD422 produced by FCP */ { AV_CODEC_ID_H264, MKTAG('a', 'v', 'l', 'g') }, /* Panasonic P2 AVC-LongG */ + { AV_CODEC_ID_H264, MKTAG('d', 'v', 'a', 'v') }, /* AVC-based Dolby Vision derived from avc1 */ + { AV_CODEC_ID_H264, MKTAG('d', 'v', 'a', '1') }, /* AVC-based Dolby Vision derived from avc3 */ { AV_CODEC_ID_VP8, MKTAG('v', 'p', '0', '8') }, /* VP8 */ { AV_CODEC_ID_VP9, MKTAG('v', 'p', '0', '9') }, /* VP9 */
From: Rodger Combs <rodger.combs@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). --- libavformat/isom.c | 4 ++++ 1 file changed, 4 insertions(+)