tsMuxer Open Source

[a5180007]

If one chooses Blu-ray ISO or Blu-ray folder, yes, (wasn't it already ?),
(can not speak for other users that want to have .ts and .m2ts untouched, but yes, to me it would be welcome)
and while we are at it:
If Blu-ray ISO or Blu-ray folder, please add preload --start-time=524250, this is vital.

AddSEI and AddSPS have been moved to ini settings, so it is now user's choice.
I'll look at this --start-time thing.

[Emulgator]

I guess this post will give the best hint: underflow of a register/counter

https://forum.doom9.org/showthread.php?p=1916192#post1916192

Looks like backwards overflow of a 32-bit counter !
(2^32 = 4294967296)

4294967296 - 4294443016 = 524280 !
There is the magic number.
What power of 2 is next ? 2^19 = 524288.

This offset indicates that somewhere 19 bits might be shifted

[SquallMX]

"Split by size" is broken in newest builds, only works for less than 4 GiB values, any higher value gets ignored.

[Hellboy.]

von Suppé:

https://forum.doom9.org/showthread.php?p=1916110#post1916110
and following...

I remux a 4k and 1080p mkv movies with "Start mux time - 45 khz clock" = 0 and when put the resulting playlist in tsMuxer, it say "0:10:00.000 y 27000000". And you recommend EDIT-524280 or more, so looks this is fixed.

The strange think was that the 1080p mkv Check by default "Force BD-ROM V3 format". I always thinks that was for 4k movies only.
EDIT: Forgot to say i checked this again and the the movie is HEVC.

[varekai]

Hello justdan96!

Just wanted to say thank you very much for this one-of-a-kind must-have software!
Couldn't do without it!

[varekai]

Thanks for updating and working on tsMuxer, much appreciated!
Question about latest pre-release "Nightly build from 2023-06-04-02-47-33".
There is no w64.zip release, yet? Maybe later?
Best regards,
varekai

[hubblec4]

Hi
I have some questions for demuxing.
Is there a mechanic to remove the duplicated frames for audio when the move is splitted in many small m2ts files, like eac3to or DGDemux do?
Is it possible to demux the forced sups at the same time when I demux a sup stream which contains forced sups, like DGDemux it do?

[guest]

Can someone help me with this command, please ?

I would like to modify this to use tsmuxer instead of ffmpeg..

"C:\ffmpeg\bin\ffmpeg.exe" -y -i "%OUTPUTFILEDIR%\%OUTPUTFILENAME%.%OUTPUTFILEEXT%" -c:v copy -c:a copy -c:s copy "c:\temp\%OUTPUTFILENAME%-test.m2ts"

Converting an .mkv with DV metadata using ffmpeg, removes the DV metadata, tsmuxer does not :)

[TheEqualizer]

Dear friends, I use a translator to communicate here, I admit I could not master 66 pages to find a solution to my question, especially in a translator. A couple of years ago, what I was interested in was discussed and I did not fully understand whether a solution was found, when repacking mp4 DV to TS, the file remains working on an LG OLED TV, but subtitles are converted to pgs, as I understood, special tsMuxeR assemblies were created that are able to make subtitles work on embedded TV players if this is really the case, tell me which version you need to use, preferably the latest one suitable for my task, if no solution has been found, but there is something I should know about, please write about it.

[guest]

Dear friends, I use a translator to communicate here, I admit I could not master 66 pages to find a solution to my question, especially in a translator. A couple of years ago, what I was interested in was discussed and I did not fully understand whether a solution was found, when repacking mp4 DV to TS, the file remains working on an LG OLED TV, but subtitles are converted to pgs, as I understood, special tsMuxeR assemblies were created that are able to make subtitles work on embedded TV players if this is really the case, tell me which version you need to use, preferably the latest one suitable for my task, if no solution has been found, but there is something I should know about, please write about it.

Even with the very latest nightly build, .srt subtitles get converted to pgs, and as also an owner of an LG TV, they don't display.

The ONLY way to get the subtitles to work is to have a separate .srt file, named exactly the same as the video file, in the same folder as the video, then they will be displayed.

I use, .m2ts....

Trust me, I have been doing a lot of these, recently.

Good Luck.

[TheEqualizer]

TDS, I am aware of what you have described, but it seemed to me that what I asked was discussed in this topic, it seems that a solution was even found, perhaps I am mistaken. Developers of new versions of tsmuxer can somehow fix this point and force them to forcibly add non-converted subtitles, or it is not technically possible as a container.ts can't work any other way?

[cubicibo]

MPEG TS are not like MKV files, they are not meant to carry SRT subtitles. You could embed SRT data in packets that uses a custom, non-reserved, PID but then you also need to customize your video player software to tell it that this PID is SRT data. So essentially you are creating a solution for yourself, out of spec.

[TheEqualizer]

cubicibo, this is very interesting, and you can learn more about how to do what you wrote or give a link if there is a ready-made instruction somewhere, thank you

[guest]

cubicibo, this is very interesting, and you can learn more about how to do what you wrote or give a link if there is a ready-made instruction somewhere, thank you

There is no way to modify the software of the embedded video player on an LG TV.

I've suggested the easiest way to do it !!!

[TheEqualizer]

TDS, accepted, this is a very offensive reality, thank you.
Unfortunately, the method with separate subtitles is not suitable because of the large number of them

[guest]

TDS, accepted, this is a very offensive reality, thank you.
Unfortunately, the method with separate subtitles is not suitable because of the large number of them

Is there more than one subtitle per video ??

If so, that could be a problem :(

[TheEqualizer]

TDS, уes, that's right, that's why I thought that we were already able to circumvent this restriction and forced tsmuxer to forcibly add non-converted srt subtitles to the container, but as it turned out, these are just my dreams

[Kuler087]

Can someone help me with this command, please ?

I would like to modify this to use tsmuxer instead of ffmpeg..

"C:\ffmpeg\bin\ffmpeg.exe" -y -i "%OUTPUTFILEDIR%\%OUTPUTFILENAME%.%OUTPUTFILEEXT%" -c:v copy -c:a copy -c:s copy "c:\temp\%OUTPUTFILENAME%-test.m2ts"

Converting an .mkv with DV metadata using ffmpeg, removes the DV metadata, tsmuxer does not :)

Tsmuxer in cli is a lot more complicated than ffmpeg because you have to specify each track ID and language in a meta file.

The DoVi_Scripts (https://drive.google.com/drive/u/1/folders/1keTxo5RoH8V_kqcZn4ZWF_J2M9DvOQRu) have a workflow that can batch mux mp4/mkv to ts. It can also automatically add a silent core to TrueHD for bluray compatibility.

[d3rd3vil]

Any new way to convert a cropped Dolby Vision mkv to a m2ts WITH black bars? For the Oppo 203 ofc :)

[SeeMoreDigital]

Any new way to convert a cropped Dolby Vision mkv to a m2ts WITH black bars? For the Oppo 203 ofc :)
Nope... And I doubt such an option will ever happen!

[d3rd3vil]

Ah shit then we got a problem

[Balling]

This is not really a bug, more of a question. I'm fairly new to tsmuxer.

Why do m2ts files remuxed with tsmuxer to the same format end up being smaller? For example, I grab a 5,820,604,416 bytes m2ts from a BD, containing an h264 and lpcm track (nothing complex). I remux it as is with tsmuxer to m2ts, nothing changed. I end up with a 5,806,061,568 bytes file. That's 14,542,848 bytes less than the original (13.87 MB).

Upon demuxing the tracks from both they are identical (compared checksums). So no issues, but why? I understand mkv having less overhead so the resulting remuxes will be smaller, but I expected staying in the same format would result in the same file sizes.

It is a bug. The ITU-T H.222 spec is not fully followed, it is hard to. See: https://github.com/justdan96/tsMuxer/issues/108

Basically, the amount of null packets should be so much more. And that will increase the overhead and thus the size.

[varekai]

@justdan96
Thanks for your continued work on updating an indispensable tool! Much appreciated! :)

[yannick92]

Hello everyone, did you have a good holiday?

Back to my encodings after having abandoned them in the spring, I discovered an unusual error message (never seen before...), when I wanted to re-encode an AC3 track with EAC3TO, previously demuxed with TSMuxer, let me explain:

As usual, I want to reduce an E-AC3 (DD+) audio track to AC3 + demux it.
No problems with TSMuxer, no processing errors...

Then I re-encode it with EAC3TO for various reasons...
But during the processing log, I have an unusual "Warning": "The last (E-)AC3 frame is incomplete and thus gets skipped" ??...

With Last Uptade >>> git-27f1d54

18476

On the other hand, NO "Warning" after having previously Demuxed my track with TSMuxer 2.6.12:

18477

On the other hand, I don't know if there is a correlation, but after demuxing in my different tests, I don't get the same file size (pre re-encoding), either:
With "Warning" my file is: 360 370 KB
But WITHOUT "Warning" it is: 360,369 KB??

Conclusion, what do you think? Is this a Bug? or regular?

For lack of time, I could not test with less recent realese of TsMuxer, but I remember not having had this problem with the updates of the beginning of the year, see the spring...

Thank you in advance for your answers !

Sincerely

Yannick

EDIT: Seen update and fix, in my case everything is ok now!
Thanks for the work jcdr..

[Balling]

Why The last (E-)AC3 frame is incomplete and thus gets skipped

Is printed for a bigger file??

"E-AC3 (DD+) audio track to AC3"

That is only possible on blu-ray.



Yeah, checking this up it appears that the very last frame is Eac3 and it is not removed, otherwise it is all good and only AC3 frames are extracted. Edit: NOW FIXED.

[Kuler087]

Why does tsmuxer add a negative delay instead of removing frames like mkvtoolnix?

Audio #1
ID : 4352 (0x1100)
Menu ID : 1 (0x1)
Format : MLP FBA AC-3 16-ch
Format/Info : Meridian Lossless Packing FBA with 16-channel presentation
Commercial name : Dolby TrueHD with Dolby Atmos
Muxing mode : Stream extension
Codec ID : 131
Duration : 1 h 49 min
Bit rate mode : Variable
Bit rate : 64.0 kb/s
Maximum bit rate : 6 840 kb/s
Channel(s) : 8 channels
Channel layout : L R C LFE Ls Rs Lb Rb
Sampling rate : 48.0 kHz
Frame rate : 31.250 FPS (1536 SPF)
Compression mode : Lossless
Delay relative to video : -3 s 337 ms
Stream size : 50.2 MiB (0%)
Language : English
Service kind : Complete Main
Number of dynamic objects : 11
Bed channel count : 1 channel
Bed channel configuration : LFE

[Selur]

(reason is probably, since it's simpler)
Does it add or simply keep the delay?

[Balling]

Why does tsmuxer add a negative delay instead of removing frames like mkvtoolnix?

Audio #1
ID : 4352 (0x1100)
Menu ID : 1 (0x1)
Format : MLP FBA AC-3 16-ch
Format/Info : Meridian Lossless Packing FBA with 16-channel presentation
Commercial name : Dolby TrueHD with Dolby Atmos
Muxing mode : Stream extension
Codec ID : 131
Duration : 1 h 49 min
Bit rate mode : Variable
Bit rate : 64.0 kb/s
Maximum bit rate : 6 840 kb/s
Channel(s) : 8 channels
Channel layout : L R C LFE Ls Rs Lb Rb
Sampling rate : 48.0 kHz
Frame rate : 31.250 FPS (1536 SPF)
Compression mode : Lossless
Delay relative to video : -3 s 337 ms
Stream size : 50.2 MiB (0%)
Language : English
Service kind : Complete Main
Number of dynamic objects : 11
Bed channel count : 1 channel
Bed channel configuration : LFE

Because you are not allowed to remove frames (except for seamless branching). Removing frames from THD and AC3 will make it lossy in first case and different in the second case. And also AC3 you are not allowed to remove priming samples. Same for DTS HD and MA, in DTS HD the reference decoder will not decode it EVEN. Also, same happens with EAC3, it has delay 256 samples, usually more.

[Balling]

It is a bug. The ITU-T H.222 spec is not fully followed, it is hard to. See: https://github.com/justdan96/tsMuxer/issues/108

Basically, the amount of null packets should be so much more. And that will increase the overhead and thus the size.

Actually, I am interested. How hard would it be to fix? AFAIK, no one has open source code for that.

[yannick92]

Good morning
I have a problem with splitting MKV into M2TS with TSMuxer (last nightly):
No error during muxing, I get my 2 parts (split in 4 GB because DD in Fat 32), in playback with VLC, split 1 ok but split 2 no image, just the sound...?
Same on PS3, Split 2 "data not compatible" so no reading at all...
Is this a bug?
THANKS

[Hellboy.]

Good morning
I have a problem with splitting MKV into M2TS with TSMuxer (last nightly):
No error during muxing, I get my 2 parts (split in 4 GB because DD in Fat 32), in playback with VLC, split 1 ok but split 2 no image, just the sound...?
Same on PS3, Split 2 "data not compatible" so no reading at all...
Is this a bug?
THANKS

Is better if you report the bugs you find here:
https://github.com/justdan96/tsMuxer/issues

[yannick92]

Is better if you report the bugs you find here:
https://github.com/justdan96/tsMuxer/issues

Ok thx, I didn't dare...

[jcdr428]

Hi all, I am working on the buffers management of tsMuxer.

These are the Rx leak rates from the transport buffers given by the BD-ROM Part3 V2.5 specs:

Stream:.................................10^6 bits/s
MPEG-2 Main/Main........................18
Sec. AVC Level 3.2........................9.6
LPCM 48/96 kHz...........................20
LPCM 192 kHz..............................30
DD..............................................2
DTS............................................5
DRA............................................5
All others....................................48

Can anybody advise / PM me what are the leak rates in the V3 (UHD) specs ?

[Emulgator]

Hi jcdr428, many thanks for your continued work !

BD-ROM V3.0 HEVC constraints (2015 06) and
BD-ROM V3.0 UHD Format Spec (2015 07 24) and
BD-ROM V3.2 UHD Format Spec (2018 01 22) agree.

"3.11 HEVC video stream Decoder Model
In case an input to TB (Transport buffer) is a HEVC video stream,
the BDAV-STD decodes the input in the same way as T-STD defined in ISO/IEC 13818-1.
For transferring the HEVC video stream data from MB (Multiplexing buffer) to EB (Elementary stream buffer),
ISO/IEC13818-1 defines two methods: the leak method and HRD.

(BDAV-STD Video Decoder Model)
It is restricted that the BDAV-STD shall use the leak method for transferring the HEVC video stream from MB to EB.
(The BDAV-STD shall not use the HRD for the transfer of data from MB to EB.)"
-----------
"3.11.1 BDAV-STD model parameter limits
Table 3-7:
Rx1 Leak rate from TB1 for HEVC video stream: 1.1*100*10^6 bits/s = 110Mbit/s
Rbx1 Leak rate from MB1 for HEVC video stream: 1.0*100*10^6 bits/s = 100Mbit/s
MB1 Multiplexing buffer for HEVC stream 73.333 bytes
EB1 Elementary stream buffer for HEVC stream 12.500.000 bytes
DPB1 Decoded picture buffer for HEVC stream 93.312.000 bytes"
----------
Good practice UHD HEVC stream encoding for 112nm pitch BD-100: VBR peak max 109, better 108Mbps.
MPEG-2TS Peak rate for 112nm pitch BD-100: 127,9Mbps
A Scenarist UHD setting screenshot showed a max. Data Transfer rate of 122,546Mbps for a 112nm pitch Triple-layer BD-100.

P.P.S Hm.
Rx1 is max. leak rate from Transport buffer TB1 into the 73kB Mux buffer MB1 (<=110Mbs)
After container overhead is stripped off (here 110/100 -> up to +10% overhead can be accommodated)
Rbx1 is max leak rate from Mux buffer MB1 into the 12,5MB EB1 (Elementary buffer). (<=100Mbps
which would imply that any HEVC CBR ES can only touch Rbx1 from underside, keeping a safety distance (99Mbps ?)
and for HEVC VBR ES the mean value of bufferlengths worth can only touch Rbx1 from underside.
(Peaks up to 109,5Mbps minus muxer overhead, Valleys to match buffersize within bufferlength).
Don't know If I am correct here, but I thought I throw this in.

[jcdr428]

Thanks @Emulgator. HEVC Rx leak rate 110 x 10^6 bits/s: this is for Main10/High Tier/Level 5.1 Primary Video.

So there are no other HEVC profiles/levels or secondary video allowed in player profile 6 (UHD), is that correct ?

What happens with 64 or 81.7 Mbps discs: are they supposed to receive AVC video only ?

[Emulgator]

What happens with 64 or 81.7 Mbps discs: are they supposed to receive AVC video only ?
I guess no. You just keep bitrate down and still choose the codec (following producer's taste or really following source resolution and content ;-)

Going from the Blu-ray ecosystem "We have certain SoCs, softwares and plants available,
so let's keep needed restrictions we already have researched and extend only where necessary"
there is such thing as FHD on Ultra-HD Blu-ray, allowing longer movies, series, whatever.
If all points to FHD, then 8bpc-> AVC vs. 10bpc-> HEVC

The producer would have the choice between (FHD project ? AVC or HEVC) OR (UHD project ? HEVC only)
and the encoding person in consequence following duration/complexity vouch for BD-66 or BD-100,
then have to take care and control encoder properly before attempting to mux.
(BD-ROM 66? BD-ROM 100? which pitch ? how many layers are there and which layer are we in ?
In HEVC case on selecting Disc type Scenarist would only assign and approve the lesser bitrates.
So there are no other HEVC profiles/levels or secondary video allowed in player profile 6 (UHD), is that correct ?
HEVC Profiles should be more than one allowed. Secondary video: I am not sure, will look into it.

P.S. A quick search in the HEVC video constraints paper did not find the word "secondary".
Allow secondary AVC video to be muxed in on a AVC Ultra-HD Blu-ray ?
If ressources, time and interest allow: Why not. Can be warned about later if some Oppos play and some Pannys not.

FHD Ultra-HD Blu-ray ROM:

AVC 1920x1080 is allowed in 8bpc only (no 10bit).
I would expect the following:
AVC restrictions should stand still as before, Level 4.1, VBV model, But: No more 3D MVC coding allowed.
AVC Level 4.1 Main would accommodate 1920x1080x30/1280x720x68,3fps@50Mbps

HEVC 1920x1080 is allowed in 10bpc only (no 8bit)
HDR/SDR, Buffer leak model.
There is your other HEVC Profile: HEVC Level 4.1 Main10 High would accommodate 1920x1080x64fps@50Mbps.
But I see no reason to enforce/expect such signaling on muxer-side for FHD,
since Level 5.1 Main10 High can be used all the same with less than maxed-out, so FHD bitrates.

UHD Ultra-HD Blu-ray ROM:
Mandatory HEVC 3840x2160 10bpc, Buffer leak model.
The Profile: Level 5.1 Main10 High can place 160Mbps to accommodate 3840x2160x64fps

(No AVC allowed nor possible, AVC Level 5.2 Main(8) would place 240Mbps to accommodate 3840x2160x66,8fps
and Hi10P, well out of the equation...)

From the muxer perspective I would gather that the model and leak rates shall not differ if HEVC UHD or FHD is to be muxed.
As bitrate should also not affect the muxer strategy, IMHO.
After all, it is the same hardware demuxing/decoding is running on for all legally possible stream parameters.

For completeness sake:
HEVC max number of slice segments: 34
HEVC Max number of pictures in DPB: 6 for 3840x2160 and 1920x1080
HEVC GOP duration: 1s for 3840x2160 and 1920x1080
HEVC STD delay: 1s for video stream, 60s for still picture.

Optional: For better searchability HEVC stream may contain a temporal sublayer consisting of TSA pictures...

[jcdr428]

So let's say I want to compress a UHD Blu-ray to FHD HEVC to fit on a 50 GB BD-R: what HEVC leak rate and overall TS_recording_rate should I use (i.e. what min. Arrival TimeStamp interval between two 0x1011 packets) ?

Currently tsMuxer does not care about leak rates, it just calculates one ATS interval between two successive video DTS by dividing the frame duration between those two DTS by the number of packets in this duration, whatever the number of tracks or size of frames. Therefore there is a huge variation in ATS interval for e.g. I-frame vs B-frame.

[cubicibo]

The leak rate is the peak bitrate of the input VBR stream (https://forum.doom9.org/showthread.php?p=1576826#post1576826), capped at the maximum rate allowed for a given elementary stream type.

[Emulgator]

Good thread, cubicibo, from the beginning !
jcdr428 was at it 2020, together with drmpeg's other post
https://github.com/justdan96/tsMuxer/issues/108

From my quick glances other (disc) muxers seem to need to parse VBR elementaries before actually muxing.
No way to go for streaming of course, but there are different bitstream restriction sets in force which help on-the-fly muxing.

[jcdr428]

The leak rate is not really the peak rate, but rather the average reading rate for one frame from the transport buffer to the multiplexing buffer. The multiplexing buffer mustn't overflow above maximum permitted size, nor underflow (i.e. become null before end of reading of the frame). This is why the blu-rays generally have a 900ms "dwell" between the arrival time stamp and the DTS, to allow for burst bitrates than can be well above maximum permitted (cf. Super Mario Bros UHD which goes to >130 Mbps for a leak rate of 109*10^6).

Edit: and this is why there are various leak rates for H.264:
1.2*40*10^6 for level 4.1,
1.2*24*10^6 for level 4,
1.2*24*10^6 for level 3.2,
1.2*16.8*10^6 for level 3.1,
1.2*12*10^6 for level 3

It should be the same for H.265, unfortunately the WhitePaper does not give the various leak rates for the various levels that can be used.
E.g. we don't know which level and leak rate can be used on a 50GB disk which maximum reading rate is 64*10^6 bps.

Edit2: the post from drmpeg applies to .ts (not .m2ts) for which there are no arrival time stamps, so indeed the leak rate is the peak rate and filler packets are included to keep the rate constant.

[jcdr428]

OK the leak rates can be deducted from the H.265 standard Annex A 4.2.

Main10 High Tier would be:
1.1x160x10^6 for levels 5.1 (capped to 1.1x100 for Blu-rays),
1.1x100x10^6 for level 5.0,
1.1x50x10^6 for level 4.1,
1.1x30x10^6 for level 4.0.

Edit: so you would have to encode to level 4.1 for a 50GB BD-R disk spinning at 64 Mbps / 2x or 81.7 Mbps / 2.5x.

[ryrynz]

Anyone know if anything better than AC3 can be played back by my Panasonic TV whilst playing DV content after remixing to TS from MKV and how that would be achieved?

[SeeMoreDigital]

Anyone know if anything better than AC3 can be played back by my Panasonic TV whilst playing DV content after remixing to TS from MKV and how that would be achieved?What's your Panasonic TV's model number?

Just-so-you-know... No make and model of television is able to display Dolby Vision content stored with the .mkv container. Currently, just .mp4 and .ts/.m2ts containers are supported.

[ryrynz]

What's your Panasonic TV's model number?



Just-so-you-know... No make and model of television is able to display Dolby Vision content stored with the .mkv container. Currently, just .mp4 and .ts/.m2ts containers are supported.

Hey. It's a LZ980. Yeah I have to remux to TS then rename the extension to MKV so the tv sees it and bingo. But yeah no DTS MA or Dolby HD, I'm aware there's a limitation I've seen it specified before, just wondered if anything had changed on that front. Cheers.

[SeeMoreDigital]

...But yeah no DTS MA or Dolby HD, I'm aware there's a limitation I've seen it specified before, just wondered if anything had changed on that front. Cheers.Lossless audio formats such as DTS-HD MA and Dolby True HD (with or without Atmos) have to be bit-streamed via HDMI eARC to an supporting AVR, regardless of the TV's manufacturer.

According to pages 180 and 181 of your TV's 'eHelp' information, it would appear that lossy audio formats such as Dolby Digital and Dolby Digital Plus usually up-to 5.1 channels (with or without Atmos) are able to be decoded by the Panasonic's media player app (or be passed via HDMI ARC/eARC to an supporting AVR). Sadly, support for lossy DTS decoding is no longer mentioned.

On a more personal note, I'd be interested to know if the media player app in the 2022 (and 2023) Panasonic TV's supports playback of stereo/multi-channel FLAC, either as a .flac file or when muxed within the .mkv container with video...

Cheers

[Kuler087]

What's your Panasonic TV's model number?

Just-so-you-know... No make and model of television is able to display Dolby Vision content stored with the .mkv container. Currently, just .mp4 and .ts/.m2ts containers are supported.

Actually, Sony Bravia TV supports DV in an MKV container.

https://forum.makemkv.com/forum/viewtopic.php?p=134179#p134179

[SeeMoreDigital]

Actually, Sony Bravia TV supports DV in an MKV container.

https://forum.makemkv.com/forum/viewtopic.php?p=134179#p134179Nah, not using it's own media player app.

As far as I'm aware Matroska has not developed the required file parser yet. But I'd really like to be proved wrong!

[Kuler087]

Nah, not using it's own media player app.

As far as I'm aware Matroska has not developed the required file parser yet. But I'd really like to be proved wrong!

Well AFAIK PLEX supports what the TV supports internally and it cannot force support for a non-supported format.

PLEX is more practical than TVs internal app anyway, and I would be VERY happy if my C2 supported DV mkv in PLEX but it doesn't.

[Balling]

Nah, not using it's own media player app.

As far as I'm aware Matroska has not developed the required file parser yet. But I'd really like to be proved wrong!

Mkv dolby vision files are for Sony. You just install APK file that can play it and pass metadata.

[SeeMoreDigital]

Mkv dolby vision files are for Sony. You just install APK file that can play it and pass metadata.Hmmm... The APK file for what device?