| Message ID | 20181105162734.87879-1-rodger.combs@gmail.com |
|---|---|
| State | Withdrawn, archived |
| Headers | show |
On Mon, Nov 5, 2018 at 6:34 PM Rodger Combs <rodger.combs@gmail.com> wrote: > > This refers to "Dolby Vision", which can have some additional extensions, > but (usually?) is also valid HEVC. This probably will have to be referenced against https://www.dolby.com/us/en/technologies/dolby-vision/dolby-vision-bitstreams-within-the-iso-base-media-file-format-v2.0.pdf . It seems to define additional boxes which most likely contain the information regarding if the Base Layer (BL) is compatible with standard SDR or HDR AVC/HEVC. The referenced Dolby Vision profile defitions seem to be defined in https://www.dolby.com/us/en/technologies/dolby-vision/dolby-vision-profiles-levels.pdf . Best regards, Jan
2018-11-05 18:26 GMT+01:00, Jan Ekström <jeebjp@gmail.com>: > On Mon, Nov 5, 2018 at 6:34 PM Rodger Combs <rodger.combs@gmail.com> wrote: >> >> This refers to "Dolby Vision", which can have some additional extensions, >> but (usually?) is also valid HEVC. > > This probably will have to be referenced against > https://www.dolby.com/us/en/technologies/dolby-vision/dolby-vision-bitstreams-within-the-iso-base-media-file-format-v2.0.pdf > . > > It seems to define additional boxes which most likely contain the > information regarding if the Base Layer (BL) is compatible with > standard SDR or HDR AVC/HEVC. > > The referenced Dolby Vision profile defitions seem to be defined in > https://www.dolby.com/us/en/technologies/dolby-vision/dolby-vision-profiles-levels.pdf Since the patch doesn't change default muxing behaviour, it could be committed for the time being, please mention ticket #7347. Maybe print a warning if not reading the additional information can be an issue. Carl Eugen
On Tue, Nov 6, 2018 at 11:56 PM Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote: > > Since the patch doesn't change default muxing behaviour, it could > be committed for the time being, please mention ticket #7347. > Maybe print a warning if not reading the additional information > can be an issue. > > Carl Eugen I will post a v2 in a moment which contains all of the AVC and HEVC identifiers specified in that Dolby specification and which are registered at the MPEG-4 registration authority (they have two AVC and two HEVC ones). After looking at the relevant specs: * These custom registered identifiers should only be utilized when the stream cannot be played as-is by a standards-compliant AVC/HEVC player. In other words, no color metadata is (supposed) to be left in the video stream, and a custom DOVIConfigurationBox is required to be parsed in order for the application to be able to interpret the actual contents of the stream (YCbCr vs ICtCp('ish), HDR or SDR, base layer or enhancement layer etc). * These sample entries all contain the standardized configuration box, which means that they should always be decode'able. Thus I am for adding these identifiers to the demuxer, even if the actual content cannot be interpreted without additional parsing. Jan
2018-11-07 23:41 GMT+01:00, Jan Ekström <jeebjp@gmail.com>: > On Tue, Nov 6, 2018 at 11:56 PM Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote: >> >> Since the patch doesn't change default muxing behaviour, it could >> be committed for the time being, please mention ticket #7347. >> Maybe print a warning if not reading the additional information >> can be an issue. >> >> Carl Eugen > > I will post a v2 in a moment which contains all of the AVC and HEVC > identifiers specified in that Dolby specification and which are > registered at the MPEG-4 registration authority Apart from "please see archives": Why can't we do it like the last decade and fix files that don't work instead of creating patches that apparently are impossible to test? Carl Eugen
On Thu, Nov 8, 2018, 03:38 Carl Eugen Hoyos <ceffmpeg@gmail.com wrote: > > Apart from "please see archives": > Why can't we do it like the last decade and fix files that don't work > instead of creating patches that apparently are impossible to test? > > Carl Eugen > We have something that: a) has a specification (albeit by Dolby, which we all can have our opinions on, but still a specification). b) has the identifiers registered to itself by mpeg-4 ra When looking into something that is specified, wouldn't you go through it and enable what it mentions if you notice that there were actually more things than you originally thought?! I'm pretty sure this way of going through it has nothing special regarding it compared to the "last decade". Generally picking up values from samples happens when there are no specifications, or if there's a specific agenda from the side of FFmpeg to prefer one identifier to the other. Or if someone just forgot to look at a specification during initial implementation. Or the specification changed. Jan
2018-11-08 8:25 GMT+01:00, Jan Ekström <jeebjp@gmail.com>: > When looking into something that is specified, wouldn't you go > through it and enable what it mentions if you notice that there > were actually more things than you originally thought?! This may be acceptable for "DTS4" or similar but in general, it is much better to test with a sample. Carl Eugen
diff --git a/libavformat/isom.c b/libavformat/isom.c index ca9d22e4f7..fbfa0dc057 100644 --- a/libavformat/isom.c +++ b/libavformat/isom.c @@ -163,6 +163,7 @@ 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/H.265 with Dolby Vision extensions */ { AV_CODEC_ID_H264, MKTAG('a', 'v', 'c', '1') }, /* AVC-1/H.264 */ { AV_CODEC_ID_H264, MKTAG('a', 'v', 'c', '2') },