tsMuxeR version after git-a664fdc@Win10 64bit wrong make pgs in ts from srt in mkv

[abakum]

Version 2.6.12 work well

[abakum]

m2ts, blu-ray, avchd - work well with tsMuxeR version git-d817a09

[abakum]

Well working w64-nightly-2020-02-22--01-09-04.zip
tsMuxeR version git-a664fdc. github.com/justdan96/tsMuxer
Wrong working w64-nightly-2020-02-23--01-10-39.zip
tsMuxeR version git-11f852a. github.com/justdan96/tsMuxer

[jcdr428]

@abakum what do you mean by "wrong make srt from mkv to pgs" ? Can you demux the pgs, is it ill-formed ?
What is the output of mediainfo ?

[abakum]

tsMuxeR version git-d817a09:
Look at left part of first screenshot - this mediainfo - PGS subtitle present
Look at center part of first screenshot - this MPC-HC info - NO PGS subtitle
Look at right part of first screenshot - this tsmuxer output and metafile content
Look at bottom of first screenshot this MPC-HC window - no subtitle

tsMuxeR version 2.6.12:
Look at left part of second screenshot - this mediainfo - PGS subtitle present
Look at center part of second screenshot - this MPC-HC info - PGS subtitle present
Look at right part of second screenshot - this tsmuxer output and metafile content
Look at bottom of second screenshot this MPC-HC window - subtitle present

[abakum]

Can you demux the pgs, is it ill-formed ?
after demux sup file is ok
m2ts, blu-ray, avchd is ok with tsMuxeR version git-d817a09
but ts file without subtitle in MPC-HC and ffplay

[abakum]

[abakum]

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

[abakum]

vlc

[jcdr428]

@abakum ok, so the subtitle descriptors are not recognized. Problem is there doesn't seem to be any suitable descriptor available for PGS in T-REC.H222.0... And if we keep the m2ts HDMV descriptors as previous, the Dolby Vision DoVi descriptors won't be recongnized.
I can't find any professionnally produced MPEG-TS with PGS: I'll see whether we can keep the HDMV descriptor only for PGS subtitles

[abakum]

if we keep the m2ts HDMV descriptors as previous, the Dolby Vision DoVi descriptors won't be recongnized

Please add an option like --DoVA that the user can choose whether he wants to make the correct descriptor for Dolby Vision DoVA or HDMV descriptor as previous for compatibility

[jcdr428]

HDMV is specific to m2ts and should not appear in ts files.
PGS and interweaved AC3/TrueHD are HDMV streams.
To my knowledge, no professional ts muxer accepts PGS or AC3/TrueHD.
Therefore to have PGS or AC3/TrueHD working, one has to mux to m2ts, not ts.

[abakum]

To my knowledge, no professional ts muxer accepts PGS or AC3/TrueHD.

Users used tsmuxer to make TS with PGS instead of professional ts muxer. Now it does not work, and this is called not an bug, but an improvement?

[justdan96]

@jcdr428 How difficult would it be to add an option to allow the previous behaviour?

[abakum]

Maybe it’s better to add an option to enable new functionality?

[justdan96]

I'm stuck between 2 ideas here: we don't break existing functionality; we don't want to add extra options for "correct" behaviour, but we can add an extra option for "incorrect" behaviour. @xavery what approach do you think is best here?

[abakum]

Or easier:
if there is PGS then compatibility mode
if Dolby Vision DoVi then new mode

[abakum]

UMS used TS as intermediate file
look "tsmuxerout.ts" in https://github.com/UniversalMediaServer/UniversalMediaServer/blob/master/src/main/java/net/pms/encoders/TsMuxeRVideo.java

[xavery]

I'm stuck between 2 ideas here: we don't break existing functionality; we don't want to add extra options for "correct" behaviour, but we can add an extra option for "incorrect" behaviour. @xavery what approach do you think is best here?

I don't think I'm really the best person to answer this question. As far as I'm concerned, the only thing that's changed is the fact that I need to use M2TS instead of TS mode when testing things related to subtitles. However, I have to admit that as an end-user (of sorts) I was quite surprised when subtitles stopped working all of a sudden.

[jcdr428]

@abakum TS files now have H.222.0 compliant descriptors (and not bluray format descriptors) and can be now be read by an ATSC TS player, so yes it is a big enhancement.

I can look later at adding an option to produce non compliant TS with bluray streams as previous. However my priority is to finish the work on producing compliant ATSC streams, and it would be more logical to modify UMD open source so that it can accept M2TS.

[abakum]

UMD, DMS, PMS, ...... and they all abandon new tsMuxer in favor of old tsMuxeR

[jcdr428]

@justdan96 so I'll quickly submit a patch to remove #203 TS Descriptors, and you'll have the choice to merge it or not.

Edit : patch submitted #231

[abakum]

No need any option - if in META there is PGS or SRT then compatibility mode

[abakum]

@jcdr428 excuse me please. I appreciate your contribution - you greatly improved the tsmuxer! Please make a little effort to ensure compatibility.

[jcdr428]

@abakum, no worries, I understand the issue.
Let's put the TS descriptors aside until solution has been found; the patch #231 is a one-line patch, easy to revert when we have agreed and implemented the solution.

Edit: actually the best solution might be to have the HDMV descriptors as default, and the option --atsc (and the box ATSC in the GUI) to force the ATSC TS descriptors. I don't like too much the idea of automatically selecting the TS descriptors based on which streams are muxed, this could be full of surprises.

[abakum]

uint32_t size = m_pmt.serialize(m_pmtBuffer + TSPacket::TS_HEADER_SIZE, 3864, !m_bluRayMode, m_m2tsModeOrSUBinTS);

[xavery]

Purely from a programming perspective, providing correct behaviour (i.e. producing compliant streams) should be more important than keeping backwards compatibility. This is an API-breaking change and must be appropriately documented as such.
However, if transport streams containing PGS elementary streams are noncompliant by definition, then I don't see any reason why the solution suggested by @abakum

No need any option - if in META there is PGS or SRT then compatibility mode

wouldn't be feasible. Unfortunately, I don't think this is at all true, since I really doubt if there's anything in H.222.0 about forbidding carrying elementary streams in certain formats : if anything, they can always be added as "private data" AFAIR.

Lastly, what's the main difference between TS and M2TS modes? Is it just that TS uses 188-byte packets and M2TS uses 192, or is there something more to it?

[abakum]

I was probably mistaken when I thought that TS allows us to transfer more formats than M2TS

[jcdr428]

@xavery MPEG-TS has been there long time before M2TS, used by various broadcast standards: ATSC (System A), DVB (System B), IPTV...

M2TS has been created for Blu-rays, they have their own descriptors and streams. Yes the main difference is the 4 bytes arrival time stamps to get rid of the filler packets, but streams such as PGS and hybrid TrueHD/AC3 formats have also been specifically created for Blu-rays.

Indeed you can put anything in the private data, but if it is not in any standard nobody will implement their decoding.

[abakum]

https://dvb.org/wp-content/uploads/2019/12/a009_dvb_bitmap_subtitles_nov_2017.pdf

[jcdr428]

@abakum Yes, this is the DVB subtitles bitmap format, which is not the same format as PGS -I've already tried to have the PGS working with the DVB subtitling descriptors...

Edit: by the way, TS/M2TS accepts Opus audio: https://smpte-ra.org/registered-mpeg-ts-ids
This would be a nice addition.

[abakum]

Have you tried it with such a descriptor?

[jcdr428]

Yes. I've tried a LOT of things :)

With the HDMV descriptor, PGS are indeed working on blu-ray players, but the TS files cannot be played anymore by TVs https://forum.doom9.org/showthread.php?p=1902344#post1902344

Only ATSC TS seem to play on USB sticks on LG TVs.

[abakum]

But if there is no PGS in TS then it will work even on LG

[abakum]

let DV be priority, if there is DV, then a new mode
but if there is no DV and PGS is present - old mode

[abakum]

@jcdr428 Agree! So the sheep are safe and the wolves are full

[jcdr428]

I'll work on it the coming week-end.

[jcdr428]

@abakum could you please confirm that this issue can be closed.

[abakum]

Thanks @jcdr428

[Nadahar]

UMD, DMS, PMS, ...... and they all abandon new tsMuxer in favor of old tsMuxeR

Even though this issue has been resolved, I'd just like to add as a current DMS developer and a former UMS developer that that's not quite accurate.

DMS still use the "old" tsMuxeR, but that's simply because I haven't had the time to figure out what has changed so that I don't break anything when upgrading. I'm in fact reading through this issue as a part of trying to figure out what has changed, although I'm not saying I'm ready to "upgrade" just yet. The thing is that you don't want to break what's already working, and changing things made by other developers many moons ago is always somewhat high-risk when it comes to breaking stuff.

I'm not sure about UMS, but I think they might have switched to using the "new" tsMuxeR already.

For us (PMS/UMS/DMS) the goal is TS streams, not M2TS streams, so for us having more compliant streams is only a good thing. The reason for this is that MPEG-TS is pretty much the "default" container in the DLNA standard, if you can stream TS you will be able to deliver to all DLNA compliant renderers. I know that there has been long-standing issues with tsMuxeR output only working on some renderers (playback devices), and things like non-compliant headers is obvious candidates for possible explanations for such things.

DLNA doesn't support subtitles at all, so we don't use tsMuxeR when subtitles are required. To supply subtitles there's pretty much two possibilities - nonstandard delivery of SRT files "on the side" (separate connection) for Panasonic or Samsung renderers - and "burning them in" by transcoding the video for the rest. I've never heard of a renderer that supports picture based subtitles like PGS, DVBSubs etc, so that's not something that's useful for us anyway.

Sending a separate subtitles stream is only done when no transcoding or remuxing is needed, because if the user seeks to a new position, a new stream is effectively started and the timestamps won't correspond to timing information in the SRT file. When "burning in" subtitles we use FFmpeg, MEncoder or VLC to do both the transcoding and the muxing. So, I have a hard time to see any "negative impact" for us by not having PGS support in TS.

That said, I'm not saying that it's not confusing for users when something that has used to work stops working, so it needs to be documented in a way that's easy to find.