Dolby Vision and 1.15.1

[tr000]

Is that normal that the .ts doesn't trigger Dobly Vision on both my LG C8 's embedded player and Plex app?
Or do we need a Shield to make it works.

Btw thanks guys for such a work.

tsMuxer dual-layer remux is by far the easiest and fastest solution but unfortunately, it only works(in DV) on the Sony x700 and the Oppo bluray player.

You missed one, a .ts generated with yuseope's tool in mode 1 plays in DV fine on my TCL Home Theatre DV TV. The only limitation being you can't fast forward or rewind.

[bcline1]

Upgraded to 1.15.1 to test the Dolby Vision capabilities and it is failing to open UHD BDs from a UHD capable drive. Tried Joker & Top Gun. Both get recognized and opened by DVDFab. MakeMKV said something about failing to get the keys or something...

[RESET_9999]

You missed one, a .ts generated with yuseope's tool in mode 1 plays in DV fine on my TCL Home Theatre DV TV. The only limitation being you can't fast forward or rewind.

I was talking about the tsmuxer method only. no other tool except tsmuxer is needed for the x700 and the oppo.
FYI, I remux the main m2ts straight to a DV ATMOS TS (with subs) in like 5 min. on my NVME drive. No messing around with yuseope's tool nor eac3to nor makemkv.

[Trujax]

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.

I have successfully tried your demo apk in a tube shield with x-plore and Kodi over SMB, although SAMBA it is supposed not to be supported.

Great, great work!!!

[olevelo]

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.

Wow, that was fast! The good news: I tested 4 or 5 MKV's and every single one triggered DV and Atmos, from Kodi! And subtitles work, including forced! Amazing!!!!

The bad news, and maybe this is just some external payer gotchas that I'm not familiar with because I've never used them:

1. Biggest issue is that doesn't appear to be frame rate switching. I'm seeing a lot of judder I wasn't seeing in stock Kodi or Plex. I tried the beta match frame rate feature in Shield, but it says playback failed. This pretty much makes the movies unwatchable unfortunately. (EDIT: I realized I could just set the Shield to 23.9hz, and since that's the frame rate for 99% of the DV movies that solves the problem. But it makes the interface kind of ugly at that framerate, and I'm not sure what happens yet in other apps that don't support switching where 60hz would look a lot better.)
2. The exoplayer interface sucks, and you lose all of the stuff Kodi has, including chapter skip and the nicer audio/subtitle switching.
3. Sometimes when fast forwarding the audio gets out of sync, and there doesn't seem to be any way to fix it.
4. No resume playback.
5. Subtitles are outlined with transparent middle so really hard to read.

Sorry for the complaints, and many of them are minor and livable to deal with if I set just DV movies to play with exoplayer. Auto frame rate switching is the biggest issue. Thanks for the awesome work!

[Grencola]

1. Biggest issue is that doesn't appear to be frame rate switching. I'm seeing a lot of judder I wasn't seeing in stock Kodi or Plex. I tried the beta match frame rate feature in Shield, but it says playback failed. This pretty much makes the movies unwatchable unfortunately. (EDIT: I realized I could just set the Shield to 23.9hz, and since that's the frame rate for 99% of the DV movies that solves the problem. But it makes the interface kind of ugly at that framerate, and I'm not sure what happens yet in other apps that don't support switching where 60hz would look a lot better.)

is your kodi frame switching set to always on or on start/stop?

2. The exoplayer interface sucks, and you lose all of the stuff Kodi has, including chapter skip and the nicer audio/subtitle switching.

try <hidexbmc>false</hidexbmc> in playerfactorycore.xml as this overlays the kodi player gui which can help

[olevelo]

is your kodi frame switching set to always on or on start/stop?

It was on "always". I tried changing to start/stop, but same behavior. Exoplayer still plays in whatever the Shield is set to, and click match frame rate says playback failed. Switching works fine with the default player.

is your xbmc hide set to false in playerfactorycore.xml? this still overlays the kodi player gui which can help

It was set to true. I changed to false but it didn't change anything. I force closed Kodi to make sure it was reloading the config, but same behavior.

The inconveniences of switching the frame rates one way or another is still better than having to convert the MKV to a TS, and losing force subtitles. Hopefully by the time the new MKV standard is finalized and we have a new version of makemkv to either re-save or re-rip everything, these little issues can get ironed out. Even better hopefully the main Kodi player will just get DV support. But we're on the right track!

The bottom line is we can play DV MKV's!!!

[Grencola]

It was set to true. I changed to false but it didn't change anything. I force closed Kodi to make sure it was reloading the config, but same behavior.

That's strange that nothing changed. it should overlay the Kodi controls on top of whatever video player you're using. I wonder if your XML is set properly?

[olevelo]

It was set to true. I changed to false but it didn't change anything. I force closed Kodi to make sure it was reloading the config, but same behavior.

That's strange that nothing changed. it should overlay the Kodi controls on top of whatever video player you're using. I wonder if your XML is set properly?

It's kind of hard to get it wrong...and if it was wrong it would break the whole file. Are you sure that option does what you think it does? Everything I've read says there's no way to get Kodi controls up when you're using an external player, which makes sense...because it can't send it the commands (although Plex uses Exoplayer and it uses it's own GUI?).

[yusesope]

I have successfully tried your demo apk in a tube shield with x-plore and Kodi over SMB, although SAMBA it is supposed not to be supported.

Great, great work!!!

It works because you are using x-plore.

Sorry for the complaints...

Those are legitimate observations.
Keep in mind that I don't own a device like the Shield: imagine what it would mean to test and retest broken code through the people here on the MakeMkv forum. Asking "does it work?" after changing a single line of code. It would become frustrating and I write code out of passion on the weekend when I'm at home.
Then consider that I don't have much time and even if I try to solve all the problems, in a few months Plex will implement all the necessary code to play our videos and nobody will remember yusesope and its ramshackle player .
This app should be considered as a transition app.
I would like to be able to solve the "match frame rate" problem (the mechanism fascinates me) but I don't promise anything for the reasons mentioned above.
Maybe the Refresh Rate app (HERE) could solve the problem.

[steffenmanden]

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

Haha nice, i decided to wait with looking into it untill they finished! Also know that it can still change - still would've preffered the private chat we had for this, as some people simply cant stop sharing.

Ill look through it later, but all comments will be in the private

[olevelo]

Keep in mind that I don't own a device like the Shield: imagine what it would mean to test and retest broken code through the people here on the MakeMkv forum. Asking "does it work?" after changing a single line of code. It would become frustrating and I write code out of passion on the weekend when I'm at home.
Then consider that I don't have much time and even if I try to solve all the problems, in a few months Plex will implement all the necessary code to play our videos and nobody will remember yusesope and its ramshackle player .

All of that makes it even more amazing that it worked the first time! I have to debug the hell out of everything I write. It works the first time maybe 10% of the time!

I'll give that refresh rate tool a try.

[olevelo]

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

Haha nice, i decided to wait with looking into it untill they finished! Also know that it can still change - still would've preffered the private chat we had for this, as some people simply cant stop sharing.

Ill look through it later, but all comments will be in the private

Well I'm glad this wasn't posted in some private chat, or I would never have been able to see it. If you have something of value to share it needs to be where we can see it!

EDIT: Just realized you weren't talking about the modded Exoplayer for Kodi...although the general idea of my comment still remains.

[steffenmanden]

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





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

Haha nice, i decided to wait with looking into it untill they finished! Also know that it can still change - still would've preffered the private chat we had for this, as some people simply cant stop sharing.

Ill look through it later, but all comments will be in the private

Well I'm glad this wasn't posted in some private chat, or I would never have been able to see it. If you have something of value to share it needs to be where we can see it!

EDIT: Just realized you weren't talking about the modded Exoplayer for Kodi...although the general idea of my comment still remains.

Not really, right now its pure testing and development.
The big risk is that people start to spread these days of implementing as long as the standard is not in place - that is also why Morris from mkvtoolnix wrote us to hold, as changes happened to the planned standard we had been talking about earlier.
If we dont it can result in bad ways becoming the standard and then the mkv standard wouldnt be in control.

Results wouldnt be any different for you if you got it later, but future options for mkv could be damaged

[yusesope]

Also know that it can still change

Of course

...as some people simply cant stop sharing.

but isn't this the ultimate goal? To share...


The code does not work if a standard is not approved first...it is harmless.

And anyway, bad bad people who share without permission, know that inside my code there is always a deadly virus that will send your shields in quarantine!

Goodnight forum.