| Message ID | 20181107231105.4367-1-jeebjp@gmail.com |
|---|---|
| State | Accepted |
| Headers | show |
2018-11-08 0:11 GMT+01:00, Jan Ekström <jeebjp@gmail.com>: > + { AV_CODEC_ID_HEVC, MKTAG('d', 'v', 'h', '1') }, /* HEVC-based Dolby > Vision derived from hvc1 */ As said before, this breaks real-world files, the patch is therefore not ok. (And as said before, the authority hasn't done their homework.) Carl Eugen
On Thu, Nov 8, 2018, 03:39 Carl Eugen Hoyos <ceffmpeg@gmail.com wrote: > 2018-11-08 0:11 GMT+01:00, Jan Ekström <jeebjp@gmail.com>: > > > + { AV_CODEC_ID_HEVC, MKTAG('d', 'v', 'h', '1') }, /* HEVC-based Dolby > > Vision derived from hvc1 */ > > As said before, this breaks real-world files, the patch is therefore not > ok. > (And as said before, the authority hasn't done their homework.) > > Carl Eugen > I think the authority really doesn't look further than "was this identifier registered already?", which to be fair is not incorrect since you csn consider everything outside mpeg-4 ra's lists unofficial/nonstandard. Now, that said, sure. If the stuff got any real usage and you - I think - have already handled dvh1 in some other point of code if I recall correctly, then let's leave that thing at that. Then regarding the rest. Do I understand correctly that you do not trust dolby's specification and/or mpeg-4 ra and would only like identifiers be added that have been seen in the wild? Best regards, Jan >
2018-11-08 17:34 GMT+01:00, Jan Ekström <jeebjp@gmail.com>: > Then regarding the rest. Do I understand correctly that you do > not trust dolby's specification and/or mpeg-4 ra and would only > like identifiers be added that have been seen in the wild? This is not trust-related, I simply believe this patch is good example for why patches should be tested with samples. Carl Eugen
On Sat, Nov 10, 2018 at 3:36 PM Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote: > > 2018-11-08 17:34 GMT+01:00, Jan Ekström <jeebjp@gmail.com>: > > > Then regarding the rest. Do I understand correctly that you do > > not trust dolby's specification and/or mpeg-4 ra and would only > > like identifiers be added that have been seen in the wild? > > This is not trust-related, I simply believe this patch is good > example for why patches should be tested with samples. > > Carl Eugen So far: - 2/4 identifiers have been proven to match the darn specification regarding the sample identifier and the fact that the standard decoder initialization box is in there. I dislike Dolby as much as the other person, but this is so far a good track record and given the wording of the specification I would tend to trust it. - VLC has added these identifiers (http://git.videolan.org/?p=vlc.git;a=commit;h=dbb0f6c7353aad4cbbb14d88f9409c8419c26bcd) - Chromium has added these identifiers (https://codereview.chromium.org/2640113004/ - it goes to a separate codec on their side since they just want to pass it to the specific decoder interfaces that can handle the profiles fully instead of actually decoding them themselves). So what if I just make a patch without dvh1 that you have already implemented, and then we call that a day? Jan
2018-11-14 20:59 GMT+01:00, Jan Ekström <jeebjp@gmail.com>: > So what if I just make a patch without dvh1 that you have > already implemented, and then we call that a day? I thought I suggested that but I may misremember. Sorry, Carl Eugen
diff --git a/libavformat/isom.c b/libavformat/isom.c index ca9d22e4f7..a7bd657b63 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 */ + { AV_CODEC_ID_HEVC, MKTAG('d', 'v', 'h', '1') }, /* HEVC-based Dolby Vision derived from hvc1 */ { 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 ICtCP, SDR or HDR, base or enhancement layer). --- libavformat/isom.c | 4 ++++ 1 file changed, 4 insertions(+)