Dolby Vision now possible through MP4 Mux.

[SamuriHL]

That's what I thought. I don't particularly like the X700 for that very reason which is why it got replaced by a UB820 in my main entertainment center. All this effort for DB doesn't seem worth it to me, although one could argue the strides being made with Plex/Kodi on the SHIELD for DV support are pretty good barring audio support....I really wish THOSE would support DV in an m2ts container so we could keep the ATMOS. Then it'd be worth chasing after.

some guys at doom9 in the open source tsmuxer thread are trying to remux single layer DV mp4 to TS/m2ts. That would allow Atmos /DV playback on the shield
https://forum.doom9.org/showthread.php?t=176668&page=19

That would be fantastic. Thanks for the info.

[davin8r]

this has all been answered multiple times earlier in this thread, but it's now massive though so I get it. the x700 only plays m2ts in hdr10, NOT dolby vision. the only thing (other than discs) that works in dolby vision is a dual-layer mp4 from both dlna and usb. this has been tested extensively. forcing dolby vision to ON, as stated above, applies a pseudo dv to all content and isn't real dolby vision. turning it off will still properly flag dv so long as the actual Metadata exists and your source content is correct.

Bummer. I should have known it couldn't be that easy!

[Grencola]

some guys at doom9 in the open source tsmuxer thread are trying to remux single layer DV mp4 to TS/m2ts. That would allow Atmos /DV playback on the shield
https://forum.doom9.org/showthread.php?t=176668&page=19

unfortunately I highly doubt this will work. the secondary dolby vision track on uhd discs is an hevc layer, just like the main layer. when mp4muxer (or dvdfab) makes an mp4 it uses the dvhe (dolby vision high efficiency) codec. the dolby vision metadata is now hardcoded with the mp4 container, and not the actual file inside. the same goes with if dolby makes a ts file - the dvhe exists only within that container. as soon as you demux the contents, or remux into a different container, you completely lose all dolby vision information and are left with an hdr10 base file only. in order to remux a dv mp4 to ts (for atmos I assume) and retain dv, you would need to extract the el+rpu data using one of Dolby's officially licensed PSU workstations. you would then have to re-author a ts file using proprietary licensed dolby tools, like it does for their sample videos. none of this is currently possible with 3rd-party hardware and software.

[built_to_chill]

forcing dolby vision to ON, as stated above, applies a pseudo dv to all content and isn't real dolby vision. turning it off will still properly flag dv so long as the actual Metadata exists and your source content is correct.

Thank you and apologies that this has been covered before. If I follow what you’re saying above - even if DV is turned off on the X700, playing a dual layer DV MP4 will result in DV being passed to the TV?

Thanks anyway for confirming the X700 does proper playback of dual layer DV MP4s. I’m
ok with lossless PCM even if Atmos spatial data is lost. Think I’ll buy one later.

[built_to_chill]

I use my player only for DV so i leave it in DV all the time. it's true DV, see my response bgalakazam and davin8r

and see: https://slow.pics/c/feEmrLAZ

Thank you. Ok - think I'm going to go in and buy one this morning.

Will report back if I get it working.

I have a 5.1.2 Atmos setup and a Sony OLED. I also have a bunch of UHDs I backed up to my NAS using MakeMKV and one of the unicorn blu-ray drives.

Getting my TV calibrated recently has been a game changer for Dolby Vision, so I put much greater value in it now after being Luke warm on it for 2 years. Maintaining lossless fidelity with LPCM means the Atmos hit is worth getting Dolby Vision on all my UHD backups.

Cheers again.

[RESET_9999]

- even if DV is turned off on the X700, playing a dual layer DV MP4 will result in DV being passed to the TV?

No you still need to turn on DV for DV playback and turn it off for HDR10 playback.

[built_to_chill]

No you still need to turn on DV for DV playback and turn it off for HDR10 playback.

Thanks. I bought an X700 this morning and have it setup and plugged in to my AVR.

I’ll be creating the MP4 remuxes on an Ubuntu machine.

Was easy to install ffmpeg and use your command to extract the two separate video files and audio as LPCM. Also managed to compile ‪mp4muxer‬ from GitHub reasonably painlessly (I had to first install “cc” which my lite server didn’t have).

Had to go out now but will experiment more later and report back if I got it working.

[built_to_chill]

Hi all - I'm finding the MP4Box command runs extremely slowly (I dare say running in movie realtime). This is for adding the LPCM to the dual layer MP4.

It seems to hit a bottle neck when it comes to add the LPCM (after apparently reading in the two video layers normally).

Is this normal? Looks like it might take hours...

[RESET_9999]

Hi all - I'm finding the MP4Box command runs extremely slowly (I dare say running in movie realtime). This is for adding the LPCM to the dual layer MP4.

It seems to hit a bottle neck when it comes to add the LPCM (after apparently reading in the two video layers normally).

Is this normal? Looks like it might take hours...

it all depends on the speed of your HDD / SSD.
With my PCI-E M2 SSD, it takes less than 10min building the final MP4 with LPCM

[built_to_chill]

Hi all - I'm finding the MP4Box command runs extremely slowly (I dare say running in movie realtime). This is for adding the LPCM to the dual layer MP4.

It seems to hit a bottle neck when it comes to add the LPCM (after apparently reading in the two video layers normally).

Is this normal? Looks like it might take hours...

it all depends on the speed of your HDD / SSD.
With my PCI-E M2 SSD, it takes less than 10min building the final MP4 with LPCM

I'm doing this on a SATA connected SSD. I'd be surprised if that's the bottle neck, but perhaps so.

I'm more inclined to think something is actually wrong. The rate it's going it would take 18 hours, and the one of the CPU cores would be at 100% for the duration (a core i3). Which is obviously dramatically different to 10 mins.

Incidentally I do also have an M2 SSD on the system, so I'll see if it's quicker there, and try a different file.

Edit: Also, I've found I can't use the option ":rate=0" after the video mp4, when using mp4box. It throws an error - perhaps because it's the linux version. I don't suppose you know what that does and if it could be the issue?

[built_to_chill]

Hi all - I'm finding the MP4Box command runs extremely slowly (I dare say running in movie realtime). This is for adding the LPCM to the dual layer MP4.

It seems to hit a bottle neck when it comes to add the LPCM (after apparently reading in the two video layers normally).

Is this normal? Looks like it might take hours...

it all depends on the speed of your HDD / SSD.
With my PCI-E M2 SSD, it takes less than 10min building the final MP4 with LPCM

I figured it out. The problem was the Ubuntu version of gpac/MP4box.

When I copied the "no audio" MP4 and lpcm.mov files over to my MacBook Pro, and did the final MP4Box command using the Mac version of gpac, it ran very quickly. When it was adding the video tracks to the temporary ISO - this was very similar speed to on Ubuntu - but it didn't grind to a halt when adding the LPCM. And the ":rate=0" option works on the Mac version. No idea what is going wrong on Ubuntu but at least I have a workable solution now.

Just tried my first MP4 with dual layer Dolby Vision and True HD/Atmos as LPCM on the X700 - Game of thrones Season 8 episode 1. As far as I can tell it worked a charm. Pressing info on the X700 remote showed "Dolby Vision HDR" (as of course did info on my TV - a Sony AF9). And the audio was intact too.

Thanks again for sharing the information above.

[kazuma]

grencola, when can we expect you're new tool?

[bgalakazam]

Would sure love a 1-click wonder converting a UHD rip to MP4 with DV and 7.1 LPCM.

[built_to_chill]

Just to say it’s easy enough to string the three commands together into a basic shell script. Which takes the file as an argument. That’s what I’m doing now,

But it’s far from elegant with all the unnecessary hard disk writing that happens.

If there’s something better coming that’s great news.

In the mean time I think I’ll looking at running the operations on an attached USB 3.0 HDD. Not worried about it taking longer, think would rather that to save my SSD from hundreds of GBs being written.

[Grencola]

grencola, when can we expect you're new tool?

you shouldn't expect anything :p but if I finish it soon then bonus, right?