Dolby Vision and 1.15.1

[olevelo]

Well I finally got my new Shield, but first test didn't work. Got a black screen for video, and although Plex reported its True HD Atmos, my receiver is only getting DD+. Guess I need to try different versions of tsmuxer. No idea which one I used at this point!

On a different note, with this discussion of Plex and Exoplayer, personally I could care less if Plex implements this support. I want Kodi DV support. That's what I use and I don't want to use Plex at all! (and yes I understand others feel complete opposite. Just saying!)

I had exactly the same issue with tsmuxer and I used the latest nightly build (9 May version - git-7b159f6). Does anyone have a link a version of tsmuxer where they have been able to get the Dolby Vision with Atmos? Many thanks!

I just downloaded and used this one: https://drive.google.com/file/d/1q5v4-J ... gPqCD/view

It's the one that most folks said they were using, and I confirmed that this time it flagged the video as 04.06 instead of 06.06. I'm transferring the file to my Shield now to test. Unfortunately I haven't figured out how to get the Shield to copy files faster than 20 MB/s so it takes forever!

[olevelo]

Success! Using the above tsmuxer both Spider-Man Homecoming and Far From Home (the one that failed before) worked perfectly! Both DV and Atmos working! The info in Plex just says HDR10 for some reason, but playback activates DV. Now to just get MKV playback and Kodi working, and everything will be perfect!

[dawsmith]

For some reason that version didn't work for me but I got one to work with the 30 March nightly build and it triggered Dolby Vision and Atmos on my Shield!

[Grencola]

Now to just get MKV playback and Kodi working, and everything will be perfect!

kodi technically is ready to go, since once there's a stable exoplayer apk from yusesope's work available (or compile it yourself), you can just set kodi to play mkv's using that external player instead.

[steffenmanden]

Just noticed that someone raised concerns regarding the current way to store it.

We will have to see if they want to do it differently now

[siriusbox]

Now to just get MKV playback and Kodi working, and everything will be perfect!

kodi technically is ready to go, since once there's a stable exoplayer apk from yusesope's work available (or compile it yourself), you can just set kodi to play mkv's using that external player instead.

It's true, I didn't realize that, cool! Kodi could give support natively in its own player since they already have code working for DV in the InputStream addon, the problem is always the same, those huge projects needs time to approve new feautres, in fact, I doubt even if they are going to support for Kodi 19, maybe 20 and the we are moving on the range of years.

Regards.

[steffenmanden]

It seems the data will be moved out from CodecPrivate and into some CodecPrivateExtensions.

EDIT: Ignore the above, seems it's now in BlockAdditionalMapping using BlockAddIDType to define the type

This is to avoid future issues and to give a new way of implementating it, so it doesn't cause issues with existing stuff.

As Mortiz suggests:

Code: Select all

OK, new proposal based on the existing elements I hadn't been aware of. It's incomplete, especially wrt. to the ISO references.

AVC/h.264
New way
CodecPrivate only contains the avcC structure, nothing more.
One or more BlockAdditionalMapping elements can be used to store additional data required by the codec for decoding.
For the mvcC structure one BlockAdditionalMapping element must be used with BlockAddIDValue = 1 and BlockAddIDType = 1 [1]. BlockAddIDExtraData contains the mvcC structure as defined in ISO TODO.
Existing, deprecated way
A deprecated way of storing the mvcC structure is what MakeMKV has done for several years now, storing it in CodecPrivate right after the avcC structure with a size field, type field (value: 0x6d 76 63 43) and the content of the mvcC structure.

Demuxers MAY support this way of storing data.

Multiplexers SHOULD NOT create such files anymore. Multiplexers SHOULD convert such structures into the "new way" when re-writing such files.

HEVC/h.265
New way
CodecPrivate only contains the hevcC structure, nothing more.
One or more BlockAdditionalMapping elements can be used to store additional data required by the codec for decoding.
For the hvcE structure one BlockAdditionalMapping element must be used with BlockAddIDValue = 1 and BlockAddIDType = 2 [1]. BlockAddIDExtraData contains the hvcE (?) structure as defined in ISO TODO.
For the dvcC structure one BlockAdditionalMapping element must be used with BlockAddIDValue = 2 and BlockAddIDType = 2 [1]. BlockAddIDExtraData contains the dvcC structure as defined in ISO TODO.
Fotonotes
[1] I don't really understand the difference of BlockAddIDValue and BlockAddIDType, especially given that they're both mandatory. I assume BlockAddIDType can express something like this value (e.g. 1) is supposed to be a header structure vs this value is supposed to be a NALU? I've chosen 1 to mean "this is AVC header data" and 2 "this is HEVC header data". I haven't found an existing list of already-reserved values.

Following with

Code: Select all

Ah, so I would have to say…

BlockAddIDType == 1 is mvcC, only valid for CodecPrivate == AVC
BlockAddIDType == 2 is hvcE, only valid for CodecPrivate == HEVC
BlockAddIDType == 3 is dvcC, only valid for CodecPrivate == HEVC

So we have to wait for this new writeup - and most likely also for mike (or mortiz) to come out with a version which can save the data in the proper way, so we have some test video to work with.

[mbunkus]

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

Please note that we haven't actually decided on the way to store extensions to CodecPrivate yet. Today we're discussing not storing them in CodecPrivate at all but in new Matroska elements. There are very good arguments for that change; please see the corresponding issue for details.

What I'm trying to say: while I understand you're all enthusiastic about having Dolby Vision in Matroska, please hold off on spreading the "store more stuff in CodecPrivate" method everywhere — at least until we've come to a final decision. Thanks.

I don't expect the discussion to take a lot of additional time; probably a couple of days.

[steffenmanden]

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

Please note that we haven't actually decided on the way to store extensions to CodecPrivate yet. Today we're discussing not storing them in CodecPrivate at all but in new Matroska elements. There are very good arguments for that change; please see the corresponding issue for details.

What I'm trying to say: while I understand you're all enthusiastic about having Dolby Vision in Matroska, please hold off on spreading the "store more stuff in CodecPrivate" method everywhere — at least until we've come to a final decision. Thanks.

I don't expect the discussion to take a lot of additional time; probably a couple of days.

No worries, i doubt people are spreading this anywhere in a major scale. Discussions are run here and we are following the specifications so we make sure to follow what you end up deciding! No one is telling anyone to implement the solution (as far as i know) which is also why we are looking into making a pull request ourselves for exoplayer, which is what yusesope has been playing around with!
But i think a lot of people follow this board - especially since mike brought forward Dolby Vision in mkv as many many people desire it

Previously it just seemed like you agreed untill rcombs came with comments, so thats why we had moved on to playing more around with it - with these changes we will just have to wait for the final specifications to be done before we continue, i think we can all wait patiently for that

[yusesope]

[olevelo]

I feel your pain. I'm working on a team with a bunch of other folks where all of our code impacts each other in various ways, and folks keep changing their requirements. I try to make sure compatibility is never broken, but these young guys never think about it!

[yusesope]

I feel your pain...

They are changing the specifications for a better solution...that's okay.
I'm happy with this!

seems it's now in BlockAdditionalMapping using BlockAddIDType to define the type

Taking a look at matroska.org, EBML is described as an XML document.

The elements BlockAdditionalMapping, BlockAddIDValue, BlockAddIDType and BlockAddIDExtraData represent branches of this XML tree. In particular BlockAdditionalMapping is a root element (called "master" in the MKV language) and the others are child elements.

Code: Select all

<ID_BLOCK_ADDITION_MAPPING>
      <ID_BLOCK_ADD_ID_VALUE>(uint) value</ID_BLOCK_ADD_ID_VALUE>
      <ID_BLOCK_ADD_ID_TYPE>(uint) value</ID_BLOCK_ADD_ID_TYPE>
      <ID_BLOCK_ADD_ID_EXTRA_DATA>(0b) value</ID_BLOCK_ADD_ID_EXTRA_DATA>
</ID_BLOCK_ADDITION_MAPPING>

After mapping the new blocks, after creating the new AdditionMapping class (a sort of C struct for the purpose of storing data) and after declaring the listAdditionMapping field (ArrayList) in the Track class, I changed the behavior of the internal parser:

• when ID_BLOCK_ADDITION_MAPPING opens, I instantiate the AdditionMapping class by calling it currentAdditionMapping.
• When I meet the child elements, I save the respective values ​​in currentAdditionMapping.
• When ID_BLOCK_ADDITION_MAPPING closes, I add currentAdditionMapping to the listAdditionMapping field and set currentAdditionMapping as null to start over with a new ID_BLOCK_ADDITION_MAPPING.

When the analysis is finished and the initializeOutput method is called, the data present in listAdditionMapping are processed as in the past days.
The way we analyze this data will change based on the decisions they make (my code for now is a simple showcase) but I think the underlying logic is right (or completely wrong ... who knows? ).

I don't have the possibility to debug everything because I don't have "new files" available but the code compiles without errors and this is a good sign .

I leave the code to the interested parties HERE (simply replace MatroskaExtractor.java)
Once again no Git and no comments in the code

[yusesope]

kodi technically is ready to go, since once there's a stable exoplayer apk from yusesope's work available (or compile it yourself), you can just set kodi to play mkv's using that external player instead.

I had missed this post.
That's a really nice idea.

The ExoPlayer demo app would not work as you would like but I can modify it to fulfill this purpose.

For local files (ex: HardDisk, internal memory, etc ...) there would be no problems.
Streaming using NFS or SAMBA would be impossible because ExoPlayer does not have the appropriate code (and writing it from scratch would take too long) but the problem can be solved easily using the DLNA protocol.

A setup like that

Code: Select all

DLNA server (PLEX, Serviio, etc..) --> Kodi --> ExoPlayer Mod

it would be perfect

Or for those who are minimalist like me

Code: Select all

DLNA server (PLEX, Serviio, etc..) --> Slick UPnP --> ExoPlayer Mod

If the community is interested, let me know!

[olevelo]

kodi technically is ready to go, since once there's a stable exoplayer apk from yusesope's work available (or compile it yourself), you can just set kodi to play mkv's using that external player instead.

I had missed this post.
That's a really nice idea.

The ExoPlayer demo app would not work as you would like but I can modify it to fulfill this purpose.

For local files (ex: HardDisk, internal memory, etc ...) there would be no problems.
Streaming using NFS or SAMBA would be impossible because ExoPlayer does not have the appropriate code (and writing it from scratch would take too long) but the problem can be solved easily using the DLNA protocol.

A setup like that

Code: Select all

DLNA server (PLEX, Serviio, etc..) --> Kodi --> ExoPlayer Mod

it would be perfect

Or for those who are minimalist like me

Code: Select all

DLNA server (PLEX, Serviio, etc..) --> Slick UPnP --> ExoPlayer Mod

If the community is interested, let me know!

This would be amazing! I play all mine off of local storage so shouldn't be a problem. I'd be happy to test it out if you whip something up.

[yusesope]

This would be amazing! I play all mine off of local storage so shouldn't be a problem. I'd be happy to test it out if you whip something up.

For test purposes only, HERE is the apk.
Do not open the app directly but use another application (Kodi, file manager, etc ...) "to open with Exoplayer"

If you use Kodi, edit/create the playercorefactory.xml file as explained HERE.
As "filename" tag, use:

Code: Select all

com.google.android.exoplayer2.demo

Do not use NFS or SAMBA as source but a DLNA server or a local storage(read my previous post)

The app includes the code to play mkv + DV files created by the current version of MakeMKV (v1.15.1).
In the future, as you may have guessed, this part of the code will have to be changed.

I repeat, the apk is only useful for tests and don't share the application outside this forum please!
It does not include FFmpeg therefore on some devices (ex: Fire Stick 4K) the audio and/or the video, in some cases, will not be played.