Dolby Vision and 1.15.1

[shawnc22]

Hello guys!
Today I had two hours free so I took a look at the ExoPlayer code.

I state that I do not program in Java, I do not know how the MKV container is structured (until now I did not know what "CodecPrivate" was) and I do not have an Android device capable of playing movies in 4K and especially with Dolby Vision.

The written code is clearly ugly AF but it does its dirty job (you can't expect more from one who writes lines of code as a hobby).
In the LogCat, I read:

Code: Select all

com.google.android.exoplayer2.demo D / EventLogger: [] Track: 0, id = 1, mimeType = video/dolby-vision, codecs = dvhe.07.06, res = 3840x2160, supported = NO_UNSUPPORTED_TYPE

I think I did it but I can't continue with the code debugging because my device doesn't have the correct hardware decoder.

So Programmers take one step forward (if you clearly own a new Shield 2019).

1. Clone the ExoPlayer source code (HERE) and install Android Studio (HERE)
2. Before you start, edit the media.exolist.json file (ExoPlayer-release-v2\demos\main\src\main\assets\) as follows:

   Code: Select all

   [
     {
       "name": "Dolby Vision inside the MKV container",
       "samples": [
         {
           "name": "Test File",
           "uri": "http://IP_ADDR:PORT/TEST_FILE.mkv",
           "extension": "mkv"
         }
       ]
     }
   ]

   Clearly replace the IP_ADDR, PORT and TEST_FILE.mkv entries and set up an HTTP server on your PC. You can use whatever you want (Apache, Nginx, etc ...). The simplest solution is to open a command window inside the folder that contains the file to be tested and run:

   Code: Select all

   python -m http.server 

   If you downloaded my tool you can use the interpreter present in the "python-3.7.6.amd64" folder.
   Be careful though: if you use the Python server, do your tests with small files (60 sec). The server does not support partial requests (Byte-range request) so you would have to download dozens of GB of data before starting playback.
3. HERE you will find the archive with the three files that I modified.
   Replace

   Code: Select all

   ExoPlayer-release-v2\library\core\src\main\java\com\google\android\exoplayer2\video\HevcConfig.java
   ExoPlayer-release-v2\library\core\src\main\java\com\google\android\exoplayer2\extractor\mkv\MatroskaExtractor.java
   ExoPlayer-release-v2\demos\main\src\main\AndroidManifest.xml

   with those in the archive.
4. Now open Android Studio, Import Project (Gradle, etc ...), select the folder "ExoPlayer-release-v2", wait for the IDE to finish its configuration and then start a debug session or directly build an apk (demo app) to be installed on the Shield.

The basic idea is to emulate the behavior of the "parseVideoSampleEntry" method in the "AtomParsers" class (ExoPlayer-release-v2\library\core\src\main\java\com\google\android\exoplayer2\extractor\mp4\AtomParsers.java).
In particular:

Code: Select all

else if (childAtomType == Atom.TYPE_dvcC || childAtomType == Atom.TYPE_dvvC) {
  DolbyVisionConfig dolbyVisionConfig = DolbyVisionConfig.parse(parent);
  if (dolbyVisionConfig != null) {
    codecs = dolbyVisionConfig.codecs;
    mimeType = MimeTypes.VIDEO_DOLBY_VISION;
  }
}

From what I understand mike has positioned the Atom boxes that interest us within the CodecPrivate area.
So, inside the MatroskaExtractor class I added the "findDolbyVisionBox" method.

Code: Select all

private byte[] findDolbyVisionBox(byte[] codecPrivate) {
  byte[] dvccBox = {100, 118, 99, 67};
  byte[] dvvcBox = {100, 118, 118, 99};
  byte[] emptyBox = {};
  byte[] boxSize = new byte[4];
  ArrayList<byte[]> DolbyVisionBoxesType = new ArrayList<byte[]>(
      Arrays.asList(dvccBox, dvvcBox)
  );
  for (int indexBoxType = 0; indexBoxType < DolbyVisionBoxesType.size(); indexBoxType++) {
    byte[] boxType = DolbyVisionBoxesType.get(indexBoxType);
    for (int pos = 0; pos <= codecPrivate.length - boxType.length; pos++) {
      int j = 0;
      while (j < boxType.length && codecPrivate[pos + j] == boxType[j]) {
        j++;
      }
      if (j == boxType.length) {
        System.arraycopy(codecPrivate,pos - boxSize.length, boxSize, 0, boxSize.length);
        byte[] boxContent = new byte[ByteBuffer.wrap(boxSize).getInt()];
        System.arraycopy(codecPrivate,pos + boxType.length, boxContent, 0, boxContent.length);
        return boxContent;
      }
    }
  }
  return emptyBox;
}

The latter searches for one of the boxes of interest and if one is found it calculates the size and returns the content (otherwise an empty box is returned)
I used the new method inside "initializeOutput".
At the point where the configuration for the HEVC stream is initialized ("case CODEC_ID_H265:") I added:

Code: Select all

byte[] dolbyVisionBoxContent = findDolbyVisionBox(codecPrivate);
if (dolbyVisionBoxContent.length > 0) {
  DolbyVisionConfig dolbyVisionConfig = DolbyVisionConfig.parse(new ParsableByteArray(dolbyVisionBoxContent));
  if (dolbyVisionConfig != null) {
    codecs = dolbyVisionConfig.codecs;
    mimeType = MimeTypes.VIDEO_DOLBY_VISION;
  }
}

I have doubts:

• Is there a better way to parse "CodecPrivate"?
  On-line I have not found anything about it.
• I realized that the "HevcConfig" class finishes analyzing codecPrivate right in correspondence of the dvcC box. So I modified the "HevcConfig" class to set the "dataPos" field i've added with the last buffer position at the end of the codecPrivate parsing.
  With the last known position it is much easier to analyze the remaining part of codecPrivate: I created the "logMyDoubts" method which is equivalent to "findDolbyVisionBox" but much more efficient (returns an error log visible in LogCat).

  Code: Select all

      private void logMyDoubts(byte[] codecPrivate, int buffPos){
        int lengthUnprocessedData = codecPrivate.length - buffPos;
        byte[] unprocessedData = new byte[lengthUnprocessedData];
        System.arraycopy(codecPrivate, buffPos, unprocessedData, 0, unprocessedData.length);
        ParsableByteArray unprocessedDataParsableByteArray = new ParsableByteArray(unprocessedData);
        int boxSize = unprocessedDataParsableByteArray.readInt();
        String boxType = unprocessedDataParsableByteArray.readString(4);
        byte[] boxContent = new byte[boxSize - 8];
        unprocessedDataParsableByteArray.readBytes(boxContent,0,boxContent.length);
        Log.e("yusesope msg",String.format("I've found %s",boxType));
      }

  I don't know if the behavior I have observed is always reproducible:
  mike, do the atom boxes just follow one after another until the end of codecPrivate?
• The hvcE box was not taken into consideration by the developers of ExoPlayer. We have to understand how to use it!

Appreciate the work! I will give this a try over the upcoming long weekend, or earlier if I find time. I don't have the right debug environment for this either, so building a demo apk each time to load on the shield to debug the old fashion way (hopefully there's good logging at least?) is already giving me ptsd flashbacks .

[Kolci]

Hey guys, is there a version of tsMuxer, that does dvhe.05.06 in .ts container?

[steffenmanden]

Hello guys!
Today I had two hours free so I took a look at the ExoPlayer code.

I state that I do not program in Java, I do not know how the MKV container is structured (until now I did not know what "CodecPrivate" was) and I do not have an Android device capable of playing movies in 4K and especially with Dolby Vision.

The written code is clearly ugly AF but it does its dirty job (you can't expect more from one who writes lines of code as a hobby).
In the LogCat, I read:

Code: Select all

com.google.android.exoplayer2.demo D / EventLogger: [] Track: 0, id = 1, mimeType = video/dolby-vision, codecs = dvhe.07.06, res = 3840x2160, supported = NO_UNSUPPORTED_TYPE

I think I did it but I can't continue with the code debugging because my device doesn't have the correct hardware decoder.

So Programmers take one step forward (if you clearly own a new Shield 2019).

1. Clone the ExoPlayer source code (HERE) and install Android Studio (HERE)
2. Before you start, edit the media.exolist.json file (ExoPlayer-release-v2\demos\main\src\main\assets\) as follows:

   Code: Select all

   [
     {
       "name": "Dolby Vision inside the MKV container",
       "samples": [
         {
           "name": "Test File",
           "uri": "http://IP_ADDR:PORT/TEST_FILE.mkv",
           "extension": "mkv"
         }
       ]
     }
   ]

   Clearly replace the IP_ADDR, PORT and TEST_FILE.mkv entries and set up an HTTP server on your PC. You can use whatever you want (Apache, Nginx, etc ...). The simplest solution is to open a command window inside the folder that contains the file to be tested and run:

   Code: Select all

   python -m http.server 

   If you downloaded my tool you can use the interpreter present in the "python-3.7.6.amd64" folder.
   Be careful though: if you use the Python server, do your tests with small files (60 sec). The server does not support partial requests (Byte-range request) so you would have to download dozens of GB of data before starting playback.
3. HERE you will find the archive with the three files that I modified.
   Replace

   Code: Select all

   ExoPlayer-release-v2\library\core\src\main\java\com\google\android\exoplayer2\video\HevcConfig.java
   ExoPlayer-release-v2\library\core\src\main\java\com\google\android\exoplayer2\extractor\mkv\MatroskaExtractor.java
   ExoPlayer-release-v2\demos\main\src\main\AndroidManifest.xml

   with those in the archive.
4. Now open Android Studio, Import Project (Gradle, etc ...), select the folder "ExoPlayer-release-v2", wait for the IDE to finish its configuration and then start a debug session or directly build an apk (demo app) to be installed on the Shield.

The basic idea is to emulate the behavior of the "parseVideoSampleEntry" method in the "AtomParsers" class (ExoPlayer-release-v2\library\core\src\main\java\com\google\android\exoplayer2\extractor\mp4\AtomParsers.java).
In particular:

Code: Select all

else if (childAtomType == Atom.TYPE_dvcC || childAtomType == Atom.TYPE_dvvC) {
  DolbyVisionConfig dolbyVisionConfig = DolbyVisionConfig.parse(parent);
  if (dolbyVisionConfig != null) {
    codecs = dolbyVisionConfig.codecs;
    mimeType = MimeTypes.VIDEO_DOLBY_VISION;
  }
}

From what I understand mike has positioned the Atom boxes that interest us within the CodecPrivate area.
So, inside the MatroskaExtractor class I added the "findDolbyVisionBox" method.

Code: Select all

private byte[] findDolbyVisionBox(byte[] codecPrivate) {
  byte[] dvccBox = {100, 118, 99, 67};
  byte[] dvvcBox = {100, 118, 118, 99};
  byte[] emptyBox = {};
  byte[] boxSize = new byte[4];
  ArrayList<byte[]> DolbyVisionBoxesType = new ArrayList<byte[]>(
      Arrays.asList(dvccBox, dvvcBox)
  );
  for (int indexBoxType = 0; indexBoxType < DolbyVisionBoxesType.size(); indexBoxType++) {
    byte[] boxType = DolbyVisionBoxesType.get(indexBoxType);
    for (int pos = 0; pos <= codecPrivate.length - boxType.length; pos++) {
      int j = 0;
      while (j < boxType.length && codecPrivate[pos + j] == boxType[j]) {
        j++;
      }
      if (j == boxType.length) {
        System.arraycopy(codecPrivate,pos - boxSize.length, boxSize, 0, boxSize.length);
        byte[] boxContent = new byte[ByteBuffer.wrap(boxSize).getInt()];
        System.arraycopy(codecPrivate,pos + boxType.length, boxContent, 0, boxContent.length);
        return boxContent;
      }
    }
  }
  return emptyBox;
}

The latter searches for one of the boxes of interest and if one is found it calculates the size and returns the content (otherwise an empty box is returned)
I used the new method inside "initializeOutput".
At the point where the configuration for the HEVC stream is initialized ("case CODEC_ID_H265:") I added:

Code: Select all

byte[] dolbyVisionBoxContent = findDolbyVisionBox(codecPrivate);
if (dolbyVisionBoxContent.length > 0) {
  DolbyVisionConfig dolbyVisionConfig = DolbyVisionConfig.parse(new ParsableByteArray(dolbyVisionBoxContent));
  if (dolbyVisionConfig != null) {
    codecs = dolbyVisionConfig.codecs;
    mimeType = MimeTypes.VIDEO_DOLBY_VISION;
  }
}

I have doubts:

• Is there a better way to parse "CodecPrivate"?
  On-line I have not found anything about it.
• I realized that the "HevcConfig" class finishes analyzing codecPrivate right in correspondence of the dvcC box. So I modified the "HevcConfig" class to set the "dataPos" field i've added with the last buffer position at the end of the codecPrivate parsing.
  With the last known position it is much easier to analyze the remaining part of codecPrivate: I created the "logMyDoubts" method which is equivalent to "findDolbyVisionBox" but much more efficient (returns an error log visible in LogCat).

  Code: Select all

      private void logMyDoubts(byte[] codecPrivate, int buffPos){
        int lengthUnprocessedData = codecPrivate.length - buffPos;
        byte[] unprocessedData = new byte[lengthUnprocessedData];
        System.arraycopy(codecPrivate, buffPos, unprocessedData, 0, unprocessedData.length);
        ParsableByteArray unprocessedDataParsableByteArray = new ParsableByteArray(unprocessedData);
        int boxSize = unprocessedDataParsableByteArray.readInt();
        String boxType = unprocessedDataParsableByteArray.readString(4);
        byte[] boxContent = new byte[boxSize - 8];
        unprocessedDataParsableByteArray.readBytes(boxContent,0,boxContent.length);
        Log.e("yusesope msg",String.format("I've found %s",boxType));
      }

  I don't know if the behavior I have observed is always reproducible:
  mike, do the atom boxes just follow one after another until the end of codecPrivate?
• The hvcE box was not taken into consideration by the developers of ExoPlayer. We have to understand how to use it!

Super awesome! i had planned to take a spin on it during the weekend as i simply cant find time in the weekdays.

ill try to give it a look this weekend - let us know if you do more!
ill test on my shield, the process just takes ages!

i hope mike sees this, maybe he has some comments on how stuff works

[shawnc22]

had some free time after work today:

https://drive.google.com/open?id=1Fm1r6 ... NmxBJsH6AS

it's a promising start

couple notes:
-no edits made to any of yusecope's changes
-sample mkv made from a 1:00 demo iso file that @RESET999 had previously uploaded here: https://drive.google.com/file/d/1HeooI- ... sp=sharing
-the mkv is single track profile 7 (BL+EL+RPU)
-demo apk running on 2019 shield pro

[Grencola]

had some free time after work today:

https://drive.google.com/open?id=1Fm1r6 ... NmxBJsH6AS

it's a promising start

couple notes:
-no edits made to any of yusecope's changes
-sample mkv made from a 1:00 demo iso file that @RESET999 had previously uploaded here: https://drive.google.com/file/d/1HeooI- ... sp=sharing
-the mkv is single track profile 7 (BL+EL+RPU)
-demo apk running on 2019 shield pro

wicked! awesome that it's profile 7 with all the metadata retained, that is promising! did you use a movie with an FEL by chance? pretty dope that you can just rip an mkv and play it on your fancy exo apk in dolby vision so what's our biggest drawback? do the colors look any better vs other profiles?

[shawnc22]

had some free time after work today:

https://drive.google.com/open?id=1Fm1r6 ... NmxBJsH6AS

it's a promising start

couple notes:
-no edits made to any of yusecope's changes
-sample mkv made from a 1:00 demo iso file that @RESET999 had previously uploaded here: https://drive.google.com/file/d/1HeooI- ... sp=sharing
-the mkv is single track profile 7 (BL+EL+RPU)
-demo apk running on 2019 shield pro

wicked! awesome that it's profile 7 with all the metadata retained, that is promising! did you use a movie with an FEL by chance? pretty dope that you can just rip an mkv and play it on your fancy exo apk in dolby vision so what's our biggest drawback? do the colors look any better vs other profiles?

Yep, according to makemkv, that sample iso file just happened to be FEL. Picture wise, I'm guessing it'll be the same as its TS counterpart. Whether it's 4, 6 or 7, I think they'll all look the same on the Shield as long as the stream is BL+EL+RPU. I honestly have no idea what the Shield is doing when it encounters a FEL file since it's not supposedly supported. Dolby specs states that it should exit the DV pipeline if it encounters an FEL video and cannot instantiate a second HEVC decoder, but the Shield is clearly not doing that. I don't have a DV-enabled uhd player to do any picture comparisons with FEL titles, but maybe somebody else can give that a try.

[steffenmanden]

Awesome first test - asked Mortiz if he would come and explain how stuff works.

Knowing the basics would make it way easier for us to continue!

From a look at the code i also think we can get it cleaned up a little - but seems like its the first big step in the right direction!

However we have to make sure we do the code in a way where its not "only" Dolby Vision as they also want to use CodecPrivate for MVC data as well.

So we have to build it in a nice way to allow for easy expanding over time, else we wont get it through a review anyway

[siriusbox]

Hello guys!
Today I had two hours free so I took a look at the ExoPlayer code.
...

That's awesome dude! Wow! Thank you very much for your effort, you are clearly the one behind make DV in MKV a reality, kudos for that.

Regarding how you should read the CodecPrivate from the MKV I guess you need to follow the way it was decided on the matroska's github discussion (https://github.com/cellar-wg/matroska-s ... issues/373) becuase it's going to be the way Mike (and other like Moritz) are going to use for generate the MKVs, I hope they can appear here and help you with that a bit.

Again, thank you very much for your work!

Regards.

[siriusbox]

Awesome first test - asked Mortiz if he would come and explain how stuff works.

Knowing the basics would make it way easier for us to continue!

From a look at the code i also think we can get it cleaned up a little - but seems like its the first big step in the right direction!

However we have to make sure we do the code in a way where its not "only" Dolby Vision as they also want to use CodecPrivate for MVC data as well.

So we have to build it in a nice way to allow for easy expanding over time, else we wont get it through a review anyway

There is also other things to test, not sure if related 100%, but PGS subtibles never worked even in .TS but it does with normal HDR so should be something related to who DV is rendered in the layers, since I guess PGS uses another bitmap layer to be painted. Also test audio formats, just to be sure all works as a whole.

[baker99]

Amazing work guys, seems like another breakthrough. Hopefully Nvidia fix their DV colour issues and we can then have perfect reproduction without having to use an x700 (if the X700 had a decent network speed it would have been perfect, plugging in a harddrive all the time is a pain).

[kcxserver]

...

At this point a big compliment and thanks for the effort! Of course, this also applies to everyone else who brings the topic forward here. Nice to see that it can work. I'm delighted As siriusbox wrote, only the PGS subtitle support is missing. But one by one... Great work!

regards!
KCX

[steffenmanden]

Awesome first test - asked Mortiz if he would come and explain how stuff works.

Knowing the basics would make it way easier for us to continue!

From a look at the code i also think we can get it cleaned up a little - but seems like its the first big step in the right direction!

However we have to make sure we do the code in a way where its not "only" Dolby Vision as they also want to use CodecPrivate for MVC data as well.

So we have to build it in a nice way to allow for easy expanding over time, else we wont get it through a review anyway

There is also other things to test, not sure if related 100%, but PGS subtibles never worked even in .TS but it does with normal HDR so should be something related to who DV is rendered in the layers, since I guess PGS uses another bitmap layer to be painted. Also test audio formats, just to be sure all works as a whole.

We have to wait and see if this is actually an issue with the MKV container. These issues might be tied to the TS container in general.

Untill then i wouldn't worry about them

[ragico]

Congrats to Yusesope and everybody who is actively contribuing to this big project. "Still going strong, now what the next?"

[yusesope]

it's a promising start

Great

From a look at the code i also think we can get it cleaned up a little...

That's awesome dude! Wow! Thank you very much for your effort, you are clearly the one behind make DV in MKV a reality, kudos for that.

Regarding how you should read the CodecPrivate from the MKV I guess you need to follow the way it was decided on the matroska's github discussion (https://github.com/cellar-wg/matroska-s ... issues/373) becuase it's going to be the way Mike (and other like Moritz) are going to use for generate the MKVs, I hope they can appear here and help you with that a bit.

Again, thank you very much for your work!

Regards.

Nahhhh man, it's the result of the work of an entire community.
I am simply an Italian: we are born with the "arte dell'arrangiarsi" gene (more details HERE)


Thank you for the link.
That make things a little more clear.



Exoplayer identifies the CodecPrivate area starting from its start code (0x63A2) and with the HevcConfig class it analyzes the "Codec Specific Data" block.

So the idea of ​​adding the "dataPos" field to the HevcConfig class seems valid to me.
Maybe it is appropriate to change its name to something more evocative (perhaps "csdEndPosition").

The "logMyDoubts" method is more appropriate at this point: starting from hevcConfig.dataPos, it is possible, using a "while loop", to analyze all the boxes that follow until an error/garbage/
end of CodecPrivate is encountered.
The use of the ParsableByteArray class would then make the code more homogenous with that already present in Exoplayer.

From what I understood, the use of atoms as for mp4 files comes in contrast with the "old way" of storing data inside the CodecPrivate area.

The "new way" seemed optimal to me. It's a shame, though.
So how do you deal with the "old way"?
An example file with the boxes for Dolby Vision is needed.

There is also other things to test, not sure if related 100%, but PGS subtibles never worked even in .TS but it does with normal HDR so should be something related to who DV is rendered in the layers, since I guess PGS uses another bitmap layer to be painted. Also test audio formats, just to be sure all works as a whole.

As siriusbox wrote, only the PGS subtitle support is missing. But one by one... Great work!

As for the issue of PGS subtitles, I don't think I can do anything
I can't debug the code up to that point because my device is unable to play a 4K DV movie.

[steffenmanden]

it's a promising start

Great

From a look at the code i also think we can get it cleaned up a little...

That's awesome dude! Wow! Thank you very much for your effort, you are clearly the one behind make DV in MKV a reality, kudos for that.

Regarding how you should read the CodecPrivate from the MKV I guess you need to follow the way it was decided on the matroska's github discussion (https://github.com/cellar-wg/matroska-s ... issues/373) becuase it's going to be the way Mike (and other like Moritz) are going to use for generate the MKVs, I hope they can appear here and help you with that a bit.

Again, thank you very much for your work!

Regards.

Nahhhh man, it's the result of the work of an entire community.
I am simply an Italian: we are born with the "arte dell'arrangiarsi" gene (more details HERE)


Thank you for the link.
That make things a little more clear.



Exoplayer identifies the CodecPrivate area starting from its start code (0x63A2) and with the HevcConfig class it analyzes the "Codec Specific Data" block.

So the idea of ​​adding the "dataPos" field to the HevcConfig class seems valid to me.
Maybe it is appropriate to change its name to something more evocative (perhaps "csdEndPosition").

The "logMyDoubts" method is more appropriate at this point: starting from hevcConfig.dataPos, it is possible, using a "while loop", to analyze all the boxes that follow until an error/garbage/
end of CodecPrivate is encountered.
The use of the ParsableByteArray class would then make the code more homogenous with that already present in Exoplayer.

From what I understood, the use of atoms as for mp4 files comes in contrast with the "old way" of storing data inside the CodecPrivate area.

The "new way" seemed optimal to me. It's a shame, though.
So how do you deal with the "old way"?
An example file with the boxes for Dolby Vision is needed.

There is also other things to test, not sure if related 100%, but PGS subtibles never worked even in .TS but it does with normal HDR so should be something related to who DV is rendered in the layers, since I guess PGS uses another bitmap layer to be painted. Also test audio formats, just to be sure all works as a whole.

As siriusbox wrote, only the PGS subtitle support is missing. But one by one... Great work!

As for the issue of PGS subtitles, I don't think I can do anything
I can't debug the code up to that point because my device is unable to play a 4K DV movie.

naming of the dataPos should be renamed to give more sense. Using your suggestion sounds good!

Pretty sure mike got this coming! He confirmed going to the "old" way.

Wish mike would give his few thoughts into this thread and then the rest of us can mess around with a solution to it

Hopefully he can bring us goodies before the weekend so i can get to play around as well

The old way should be like this according to their suggestion for the writeup:

Each extension block begins with a 4-byte extension block size field which is the size of the extension block minus 4 (excluding the size of the extension block size field), followed by an extension block identifier field; extension block identifier field MAY be identical to the ones found in ISO/IEC 14496-12 and its extensions.

Registered `Private Data` extension block identifier fields are:

### dvcC

Block identifier: 0x64766343

Extension name: Dolby Vision configuration

Description: `DOVIDecoderConfigurationRecord` structure as defined in [Dolby Vision Streams File Format](https://www.dolby.com/us/en/technologie ... v2.1.2.pdf).

### hvcE

Block identifier: 0x68766345

Extension name: Dolby Vision enhancement-layer HEVC configuration

Description: `HEVCDecoderConfigurationRecord` structure as defined in ISO/IEC 14496-15, as described in [Dolby Vision Streams File Format](https://www.dolby.com/us/en/technologie ... v2.1.2.pdf).

### mvcC

Block identifier: 0x6D766343

Extension name: MVC configuration

Description: `MVCDecoderConfigurationRecord` structure as defined in ISO/IEC 14496-15.