tsMuxer Open Source

[justdan96]

No code changes to tsMuxer at all, just amendments to the scripts in GitHub that produce packages in the Open Build Service (https://build.opensuse.org/package/show/home:justdan96/tsMuxer).

[Emulgator]

Testing tsMuxeR 2020-06-11 (build 7901afa) 64-bit for Blu-ray V2.00 folder muxing

A nice-to-have suggestion before the final build is released:
Pre-loaded default value for Blu-ray V2.00 and V3.00 muxing:
--start-time 524280

A smallish bug:
While exporting a .meta file the file extension .ts is suggested.
Pressing OK without manually going to dropdown "All Files" and removing the superfluous ".ts"
will result in a concatenated and unwanted double file extension .meta.ts
tsMuxeR 2.6.12 does that correctly and suggests file extension .meta

BD-Mux Folderset with AVC 1280x720x50p@28Mbps, duration 48m33s, AC-3 2.0 @192kbps
--start-time no offset, 18 custom chapters in HH:MM:SS.mmm

BDEdit 0.49b:
PLAYLIST finds
IN time 01:10:00.000
OUT time 01:58:33.320

CLIPINF complains: 00000.clpi: lists Packets 56082912.
and pops up window: "The m2ts file contains 56.076.970 packets.
Do you want to correct the packet value of ClipInfo ?"
--
Remuxed BD, this time with typical BD offset --start-time 524250
Checked with BDedit v0.49b: Start time is respected this time.
Number of Packets still diverging.

Investigating...
Manually setting chapters in BDEdit: These are respected by MPC-HC player.
...
BDedit: 11.651s minimum offset it is.
Now Player can skip back to stream start...
BDEdit 11.650s offset:
Player can not skip back to stream start, can only skip back to chapter 2.
On BDedit chapter export this is displayed a 0,1 (0 ticks, the meaning of the second 1 is unknown to me)

Narrowing it down:
tsMuxeR: tick one up: 524250 -> 524251.
This does it. Success.
Preload a minimum of 524251 ticks (or 11,650022222222222222222222222222s)
524280 ticks (or 11,65066666666666666666s) are safe.
On BDedit chapter export this is displayed a 0,1 (0 tick, the meaning of the second 1 is unknown to me)

Auto chaptering every 5min works: Player sees and respects these.
BDedit 0.49b sees these.
PLAYLIST: In BDedit all mark times look offset by 11.650s,
but MPC-HC timeline plays happily at the correct 5:00 positions.

Hmmm, and at the end these 11.650s are missing from BD folder playback in MPC-HC. WTF.
MPC-HC reports total playing time 48:33, but stops after 48:20.

BDedit PLAYLIST sees correct IN time 00:00:11.650
OUT time 00:48:44.970 length 00:48:33.320
Playing the pure 00000.m2ts in MPC-HC: These final 11.650s haven't been muxed into the .m2ts stream,
but were there in the .264 elementary stream before muxing (00:48:33:08 = 145666 frames (0-145665))

This may well be the reason why BDedit 0,49 CLIPINF complains:
00000.clpi lists Packets 56082912
A window pops up: "The m2ts file contains 56.076.970 packets.
Do you want to correct the packet value of ClipInfo ?"

These missing 5942 packets may well be the culprit.
Counterchecking: tsMuxeR 2.6.12 does the same.

tsMuxeR 1.10.6 does it better, lets me have the final 11.650s.
Hardwired first mark time: 00:10:00.000 (10 minutes)
BDedit finds 56032544 packets, won't complain about diverging number of packets.

[a5180007]

A nice-to-have suggestion before the final build is released:
Pre-loaded default value for Blu-ray V2.00 and V3.00 muxing:
--start-time 524280

Depending on the distributors, some Blu-ray PTS start at 2s, some others at 10s, many at 11.650s, others at 1h10s...
What is the community opinion, do we need to change the default 0 ? If so, to what value ?


A smallish bug:
While exporting a .meta file the file extension .ts is suggested.
Pressing OK without manually going to dropdown "All Files" and removing the superfluous ".ts"
will result in a concatenated and unwanted double file extension .meta.ts
tsMuxeR 2.6.12 does that correctly and suggests file extension .meta

Issue opened on Github.


BD-Mux Folderset with AVC 1280x720x50p@28Mbps, duration 48m33s, AC-3 2.0 @192kbps
--start-time no offset, 18 custom chapters in HH:MM:SS.mmm

BDEdit 0.49b:
PLAYLIST finds
IN time 01:10:00.000
OUT time 01:58:33.320

How come that you use a start time = 0, but the mpls file has a start time of 1h10s ? Did you keep the original mpls ?

[outgoing]

Depending on the distributors, some Blu-ray PTS start at 2s, some others at 10s, many at 11.650s, others at 1h10s...
What is the community opinion, do we need to change the default 0 ? If so, to what value ?


Default 0 takes the data as it is original from the mpl, so what kind of need is there to change this behavior, I like it as it is originally from the source.

[Emulgator]

Many thanks for your continued work, a5180007 !
How come that you use a start time = 0, but the mpls file has a start time of 1h10s ? Did you keep the original mpls ?
I muxed from an elementary .avc, so no .mpls was given by me or the stream.
Unintentationally I left the default (0) that the tsmuxerGUI came up with, muxed anyway just to see if the result would be playable.

I continued testing.
Anything below 524250 ticks gives timestamps that look like underflow of a 32-bit register.
This seems to be a limitation of the TS implemetations themselves,
because other muxers (Scenarist) come up with the same start time.
No problem here, but tsMuxeR's v2 muxing end came out premature by the same amount
--------------------------------------------------------
BDedit export of chapter_00000_PTS
shows mark time as <45kHz ticks>,1

mark time = chapter time + --start-time from tsMuxeR (given 11.650s)
Magic Number involved ?

In BDedit inputting an entry mark with mark time
00:00:00.000
delivers a exported chapter time 4294443016,1
which equals
95432,067022222222222222222222222s
Resulting BD is playable from the top, but only once, can not skip back to stream start.

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
for a good reason. Maybe preroll for stuff I don't know at the moment...?

Importing a chapter_00000_PTS with handedited 0 ticks
delivers 11.650s mark time.

Exporting from 11.649s delivers
4294967221,1 ticks
BD can not skip back to stream start.

Exporting from 11.651s:
BD can skip back to stream start.

Test: Rounding from the .ms granularity v into 1/45000s tick granularity
Muxing with --start-time 525250 delivers crap (underflow, see above)
BD can not skip back to stream start.

Muxing with --start-time 524251..294
BD edit sees 11.650s
BDedit exports first chapter as "0,1"
BD can skip back to stream start.

Muxing with --start-time 524295
BD edit sees 11.651s
BDedit exports first chapter as "0,1"
BD can skip back to stream start.
----------------------------------

[Emulgator]

Repeating my tsMuxeR comparisons since I was writing to the same folder and the 3 tsMuxeRs might not have overwritten correctly.
5 muxes of the same content, results came out unchanged:
tsMuxers 2.6.12 and last version seem to lose packets at the end, but 1.10.6 has them muxed playable.

tsMuxeR 1.10.6
--start time is not implemented, GUI has no provision for that
BDedit v0.49b reports first mark time 00:10:00.000 (10min) (so this value seems to be hardwired in tsMuxeR v1), reports no Packets missing.
MPC-HC playback from Bluray-folder and from stream 00000.m2ts: All frames are playable.
tsMuxeR 2.6.12
untouched --start time (GUI reports 00:00:00.000 / 0)
BDedit v0.49b reports first mark time 01:10:00.000 (1hr 10min) (so this value seems to be hardwired in tsMuxeR v2 if 0 is given), reports Packets missing.
MPC-HC playback from Bluray-folder and from stream 00000.m2ts: Both end prematurely ~12s too early.
tsMuxeR 2.6.12
manual --start time (GUI reports 00:00:11.650 / 524280)
BDedit v0.49b reports first mark time 00:00:11.650, reports Packets missing.
MPC-HC playback from Bluray-folder and from stream 00000.m2ts: Both end prematurely ~12s too early.
tsMuxeR 2020-06-11
untouched --start time (GUI reports 00:00:00.000 / 0)
BDedit v0.49b reports first mark time 01:10:00.000 (1hr 10min) (so this value seems to be hardwired in tsMuxeR v2 if 0 is given), reports Packets missing.
MPC-HC playback from Bluray-folder and from stream 00000.m2ts: Both end prematurely ~12s too early.
tsMuxeR 2020-06-11
manual --start time (GUI reports 00:00:11.650 / 524280)
BDedit v0.49b reports first mark time 00:00:11.650, reports Packets missing.
MPC-HC playback from Bluray-folder and from stream 00000.m2ts: Both end prematurely ~12s too early.

mediainfo of the video elementary stream

General
Complete name : J:\4_ES\BD RB\x264 V13 RB 1996.264
Format : AVC
Format/Info : Advanced Video Codec
File size : 9.50 GiB
Overall bit rate mode : Variable
Writing library : x264 core 160 r3000 33f9e14
Encoding settings : cabac=1 / ref=5 / deblock=1:-1:-1 / analyse=0x3:0x133 / me=umh / subme=10 / psy=1 / psy_rd=1.00:0.15 / mixed_ref=1 / me_range=32 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=0,0 / fast_pskip=1 / chroma_qp_offset=-3 / threads=18 / lookahead_threads=1 / sliced_threads=0 / slices=4 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=1 / constrained_intra=0 / bframes=3 / b_pyramid=1 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=1 / weightp=0 / keyint=50 / keyint_min=1 / scenecut=40 / intra_refresh=0 / rc_lookahead=50 / rc=2pass / mbtree=1 / bitrate=28000 / ratetol=1.0 / qcomp=0.60 / qpmin=0 / qpmax=48 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / vbv_maxrate=40000 / vbv_bufsize=30000 / nal_hrd=vbr / filler=0 / ip_ratio=1.20 / aq=1:1.00

Video
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4.1
Format settings : CABAC / 4 Ref Frames
Format settings, CABAC : Yes
Format settings, RefFrames : 4 frames
Bit rate mode : Variable
Bit rate : 28.0 Mb/s
Maximum bit rate : 40.0 Mb/s
Width : 1 280 pixels
Height : 720 pixels
Display aspect ratio : 16:9
Frame rate : 50.000 FPS
Standard : PAL
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.608
Writing library : x264 core 160 r3000 33f9e14
Encoding settings : cabac=1 / ref=5 / deblock=1:-1:-1 / analyse=0x3:0x133 / me=umh / subme=10 / psy=1 / psy_rd=1.00:0.15 / mixed_ref=1 / me_range=32 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=0,0 / fast_pskip=1 / chroma_qp_offset=-3 / threads=18 / lookahead_threads=1 / sliced_threads=0 / slices=4 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=1 / constrained_intra=0 / bframes=3 / b_pyramid=1 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=1 / weightp=0 / keyint=50 / keyint_min=1 / scenecut=40 / intra_refresh=0 / rc_lookahead=50 / rc=2pass / mbtree=1 / bitrate=28000 / ratetol=1.0 / qcomp=0.60 / qpmin=0 / qpmax=48 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / vbv_maxrate=40000 / vbv_bufsize=30000 / nal_hrd=vbr / filler=0 / ip_ratio=1.20 / aq=1:1.00
Color range : Limited
Color primaries : BT.709
Transfer characteristics : BT.709
Matrix coefficients : BT.709

BD RB1996 tsMuxeR 1.10.6.meta
MUXOPT --no-pcr-on-video-pid --new-audio-pes --blu-ray --vbr --custom-chapters=00:00:00.000;00:01:32.080;00:03:17.320;00:05:11.000;00:05:51.720;00:07:49.640;00:10:54.040;00:13:36.440;00:15:27.040;00:16:57.000;00:18:05.360;00:19:04.080;00:23:24.720;00:25:02.960;00:27:23.560;00:30:04.920;00:34:47.400;00:42:05.240 --vbv-len=500
V_MPEG4/ISO/AVC, "J:\4_ES\BD RB\x264 V13 RB 1996.264", fps=50, insertSEI, contSPS
A_AC3, "J:\4_ES\BD RB\V13 RB 1996.ac3", lang=ger

BD RB1996 tsMuxeR 2.6.12 untouched.meta
MUXOPT --no-pcr-on-video-pid --new-audio-pes --blu-ray --vbr --custom-chapters=00:00:00.000;00:01:32.080;00:03:17.320;00:05:11.000;00:05:51.720;00:07:49.640;00:10:54.040;00:13:36.440;00:15:27.040;00:16:57.000;00:18:05.360;00:19:04.080;00:23:24.720;00:25:02.960;00:27:23.560;00:30:04.920;00:34:47.400;00:42:05.240 --vbv-len=500
V_MPEG4/ISO/AVC, "J:\4_ES\BD RB\x264 V13 RB 1996.264", insertSEI, contSPS
A_AC3, "J:\4_ES\BD RB\V13 RB 1996.ac3", lang=ger

BD RB1996 tsMuxeR 2.6.12 524280.meta
MUXOPT --no-pcr-on-video-pid --new-audio-pes --blu-ray --vbr --custom-chapters=00:00:00.000;00:01:32.080;00:03:17.320;00:05:11.000;00:05:51.720;00:07:49.640;00:10:54.040;00:13:36.440;00:15:27.040;00:16:57.000;00:18:05.360;00:19:04.080;00:23:24.720;00:25:02.960;00:27:23.560;00:30:04.920;00:34:47.400;00:42:05.240 --vbv-len=500 --start-time=524280
V_MPEG4/ISO/AVC, "J:\4_ES\BD RB\x264 V13 RB 1996.264", insertSEI, contSPS
A_AC3, "J:\4_ES\BD RB\V13 RB 1996.ac3", lang=ger

BD RB1996 tsMuxeR 2.6.16 untouched.meta
MUXOPT --no-pcr-on-video-pid --new-audio-pes --hdmv-descriptors --blu-ray --vbr --custom-chapters=00:00:00.000;00:01:32.080;00:03:17.320;00:05:11.000;00:05:51.720;00:07:49.640;00:10:54.040;00:13:36.440;00:15:27.040;00:16:57.000;00:18:05.360;00:19:04.080;00:23:24.720;00:25:02.960;00:27:23.560;00:30:04.920;00:34:47.400;00:42:05.240 --vbv-len=500
V_MPEG4/ISO/AVC, "J:\4_ES\BD RB\x264 V13 RB 1996.264", insertSEI, contSPS
A_AC3, "J:\4_ES\BD RB\V13 RB 1996.ac3", lang=ger

BD RB1996 tsMuxeR 2.6.16 524280.meta
MUXOPT --no-pcr-on-video-pid --new-audio-pes --hdmv-descriptors --blu-ray --vbr --custom-chapters=00:00:00.000;00:01:32.080;00:03:17.320;00:05:11.000;00:05:51.720;00:07:49.640;00:10:54.040;00:13:36.440;00:15:27.040;00:16:57.000;00:18:05.360;00:19:04.080;00:23:24.720;00:25:02.960;00:27:23.560;00:30:04.920;00:34:47.400;00:42:05.240 --vbv-len=500 --start-time=524280
V_MPEG4/ISO/AVC, "J:\4_ES\BD RB\x264 V13 RB 1996.264", insertSEI, contSPS
A_AC3, "J:\4_ES\BD RB\V13 RB 1996.ac3", lang=ger

[Emulgator]

And another suggestion, just another nicety for beginners.

2.6.16:The last tsMuxeR version comes up with an empty chapter editor window.
2.6.16 offers 5min auto-chapters, the associated radio button is default.
If user ticks radio button "custom chapters" chapter editor window changes state, and stays empty.
Now if somebody enters the wrong format (frames, or SMPTE), he wont get no lead how to enter correctly.

Using tsMuxeR 1.10.6 one can easily see what chapter format is expected: HH:MM:SS.mmm
1.10.6 offers 5min auto-chapters, the associated radio button is default.
These equally-spaced chapter times are already visible in the still greyed-out chapter editor window.
If user ticks radio button "custom chapters" chapter editor window loses greyed-out and the default equally-spaced chapters become editable.

[a5180007]

If user ticks radio button "custom chapters" chapter editor window changes state, and stays empty.
@Emulgator which OS do you use? On my Windows 10, latest tsMuxer 7b159f6 is working as it should: If user ticks radio button "custom chapters", chapter editor window loses greyed-out and the default equally-spaced HH:MM:SS.mmm chapters become editable.

Edit; same for your "packets missing" issue, I cannot reproduce. Could you please confirm that tsMuxer reports the correct number (i.e. same as reported e.g. by ffmpeg for the original m2ts) of video frames processed, and progress goes up to 100.0% ?

Anybody else has the same issue ?

[Emulgator]

Win7U64 SP1 here, until yesterday I tested only the 64bit version of tsMuxeR 7901afa.
32bit 7901afa still untested, will do that test in the next minutes, see below.

About missing packets: both tsMuxeRs 1.10.6 and 7901afa got fed the same .avc stream,
and BDedit 0.49b finds that discrepancy with new 7901afa and old 2.6.12 from 13.01.2014.
1.10.6 from 11.05.2009 muxes the same stream ok

Right now I haven't yet found 7b159f6 in nightlies...
Once you release 7b159f6 I will test that version too, 32bit and 64bit.

Will continue testing same stream with tsMuxeR 7901afa 32 bit now.

tsMuxeR version git-7901afa. github.com/justdan96/tsMuxer
Decoding H264 stream (track 1): Profile: High@4.1 Resolution:

1280:720p Frame rate: 50
H.264 muxing fps is not set. Get fps from stream. Value: 50
B-pyramid level 1 detected. Shift DTS to 2 frames
H264 bitstream changed: insert pict timing and buffering

period SEI units
Decoding AC3 stream (track 2): Bitrate: 192Kbps Sample Rate:

48KHz Channels: 2
Processed 145666 video frames
Flushing write buffer
Creating Blu-ray stream info and seek index
Creating Blu-ray playlist
Mux successful complete
Muxing time: 6 min 54 sec

All tests with failing muxes show the same:
All tsMuxeR v2 report all .avc frames I had encoded (145666),
progress to 100%, ring and report success.
but muxes seem to miss packets at the end, at least BDEdit tells it so
and Software players stop ~12s prematurely.
(I am not remuxing from a given .m2ts here, I feed a x264 encoded elementary stream)

From the same .avc + .ac3 stream
tsMuxeR 1.10.6 muxes 00000.m2ts with size 10.758.248.448 B
tsMuxeR 2.6.12 32-bit muxes 00000.m2ts with size 10.766.778.368 B
tsMuxeR 7901afa 32-bit muxes 00000.m2ts with size 10.766.778.368 B
tsMuxeR 7901afa 64-bit muxes 00000.m2ts with size 10.766.778.368 B

Will continue that test under WinXP32ProSP3 soonish.

[Emulgator]

a5180007, good guess, there is an OS dependency indeed !

Now on my WinXP32ProSP3 tsMuxeR 2.6.12. muxes ok, the last 12 seconds are playable, BDEdit 0.49b finds no discrepancy.
(But it did not before on my Win7U64SP1.)

Unfortunately tsMuxeR 7901afa 32-bit refuses to start up on WinXP32ProSP3 with an assertion window:
"Der Prozedureinsprungpunkt "Direct3DCreate9Ex" wurde in der DLL "d3d9.dll" nicht gefunden."
"The procedure entry point "Direct3DCreate9Ex" was not found in the DLL "d3d9.dll"".

So I guess that all tsMuxeRs v2 share a small incompatibility with Win7 by birth around 2014,
and additionally an incompatibility with WinXP32 has come up for the new builds since maybe End of 2019.

So I can imagine now why Win10 users may not notice anything.

[staina]

At loaded 3D Bluray with 3D-plane undefined with in "General track options" set 3d offset to "plane 0", but right about to be set "zero".

You can this bug fix? Thank you

[a5180007]

Right now I haven't yet found 7b159f6 in nightlies...
Once you release 7b159f6 I will test that version too, 32bit and 64bit.
@Emulgator 7b159f6 is nightly 2020-05-09, which is same as 2020-06-10 and 2020-06-11 as explained by @justdan96.
I can't help on the bug, I can debug only under Win10.

[Emulgator]

I can't help on the bug, I can debug only under Win10.
Ouch. That would make the newer tsMuxeR builds unusable under WinXP and much worse, even under Win7.
Hopefully a good soul will take up OS compatibilty from here.
To help with that I will go backwards and test all newer 32bit builds to find out which commit might have broken WinXP.

[Emulgator]

If I go from the JFrog repository for me already the first 32bit nightly 2.6.15 from 2019-12-14--14-44-59 seems to break WinXP32 compatibility.
"Der Prozedureinsprungpunkt "Direct3DCreate9Ex" wurde in der DLL "d3d9.dll" nicht gefunden."
"The procedure entry point "Direct3DCreate9Ex" was not found in the DLL "d3d9.dll"".
The (available to me) previous version 2.6.12 starts up properly.
What builds came in between ?

[Emulgator]

Beautiful, with 2020-06-25--02-11-43 Build 0fa0738 chapters list becomes preloaded again on Win7U64 !
Does not yet respect changes in "Insert chapter every <integer> min but still:
Many thanks !

P.S.: No. I had no stream imported, just opened tsMuxer and went to the Blu-ray tab,
so it worked because of no import happening yet.
Once I import a single stream .avc or .ac3, preload chapter values disappear.
So it might be not connected with this build, but should be easier to track now.

P.P.S.: Just tested: That just described behaviour
(GUI losing preloaded chapter values on import of any stream (.avc, .ac3 tested))
was indeed already there in nightly build 2019-12-16, the previous 2019 12-14 GUI does not find its tsMuxeR.exe

[Emulgator]

Strange things here, exporting .meta from GUI (to myself: which?)
seems to lose CR+LF delimiter for the stream command lines, looks concatenated to me (in Windows Notepad, that is)

P.S. Got that now: 2.6.12 uses LF delimiters only ->
Windows Notepad renders concatenated text, notepad++ renders linebreaks

New builds 2.6.16 use CR+LF delimiters ->
Windows Notepad renders linebreaks, notepad++ renders linebreaks, all ok.

Soon I will test CLI...
If I can get my hand on builds in between 2.6.12 and 2.6.15 I would be willing to continue testing these.

[Emulgator]

New 2020-06-25--02-11-43 (64bit Build 0fa0738) CLI with handedited .meta under Win7U64 SP1:
Unchanged. Mux Progress to 100%, success reported, all .avc frames I had encoded are reported (145666).

BD folder Playback ends ~12s prematurely in MPC-HC.
BDedit 0.49b reads 56082912 packets from 00000.clpi,
finds only 56076970 packets, this makes 5942 missing packets.

[a5180007]

Ouch. That would make the newer tsMuxeR builds unusable under WinXP and much worse, even under Win7.
Hopefully a good soul will take up OS compatibilty from here.

@Emulgator the good soul might be @BloodyRipper (aka xavery on Github), he has worked quite a lot on the GUI for XP.

If I can get my hand on builds in between 2.6.12 and 2.6.15 I would be willing to continue testing these.
No open source available for versions prior to 2.6.15.

[filler56789]

Ouch. That would make the newer tsMuxeR builds unusable under WinXP and much worse, even under Win7.

The latest tsMuxer GUI works normally under my 64-bit Windows 7 :confused:
But then I don't let the OS update itself, to begin with...

Regarding XP especifically, many posts ago I suggested that someone :rolleyes: should create a dot-NET GUI for tsMuxer because everybody knows the QT devilopers are totally Linux-centric so to speak ;)

[BloodyRipper]

If I go from the JFrog repository for me already the first 32bit nightly 2.6.15 from 2019-12-14--14-44-59 seems to break WinXP32 compatibility.
"Der Prozedureinsprungpunkt "Direct3DCreate9Ex" wurde in der DLL "d3d9.dll" nicht gefunden."
"The procedure entry point "Direct3DCreate9Ex" was not found in the DLL "d3d9.dll"".
The (available to me) previous version 2.6.12 starts up properly.
What builds came in between ?

The builds (i.e. the regular 32-bit Windows binary and the special Windows XP GUI that's currently only available as an actions artefact) work fine on my Windows XP virtual machine, but I do have DirectX 9.0c installed there (I don't recall installing it explicitly, so it must've been already installed with the rest of the system), and that message is hinting that it might be missing. Please try installing DirectX 9.0c (https://www.microsoft.com/en-us/download/details.aspx?id=34429) and report back.

We don't make use of any DirectX functions directly, but I suppose the dependencies might be injected there indirectly by the compiler and/or the runtime library. The previous (i.e. pre-github) versions were compiled with a different compiler than the one we're currently using, so it is the most obvious suspect.
Regarding XP especifically, many posts ago I suggested that someone :rolleyes: should create a dot-NET GUI for tsMuxer because everybody knows the QT devilopers are totally Linux-centric so to speak ;)Qt is well supported on Windows. If you want to make a new GUI, by all means go ahead - the current GUI source is there to help you, but be aware that it does show its age and there's a lot of stuff that certainly isn't obvious at first glance. Also remember that the GUI is tied to the main binary version by the syntax of the "stream detection mode" output so the GUI can obtain necessary track information. However, seeing how we're trying to maintain backwards compatibility, old versions of the syntax will probably remain supported if it ever changes, potentially with limited functionality.

[filler56789]

The builds (i.e. the regular 32-bit Windows binary and the special Windows XP GUI that's currently only available as an actions artefact) work fine on my Windows XP virtual machine, but I do have DirectX 9.0c installed there (I don't recall installing it explicitly, so it must've been already installed with the rest of the system), and that message is hinting that it might be missing. Please try installing DirectX 9.0c (https://www.microsoft.com/en-us/download/details.aspx?id=34429) and report back.

Note: Direct3DCreate9Ex is supported only in Windows Vista, Windows Server 2008, and Windows 7. Earlier versions of the D3D9.dll library do not include Direct3D9Ex and Direct3DCreate9Ex.

source: https://docs.microsoft.com/en-us/windows/win32/api/d3d9/nf-d3d9-direct3dcreate9ex

[BloodyRipper]

Note: Direct3DCreate9Ex is supported only in Windows Vista, Windows Server 2008, and Windows 7. Earlier versions of the D3D9.dll library do not include Direct3D9Ex and Direct3DCreate9Ex.

source: https://docs.microsoft.com/en-us/windows/win32/api/d3d9/nf-d3d9-direct3dcreate9ex
What does the virtual machine bit have to do with anything? I have also tested these binaries with an actual Windows XP desktop sporting a Pentium 3 (screenshots available earlier in the thread), so I'm quite confident they should work on most, if not all standard-ish XP setups. I just find it easier to launch a VM for a quick test instead of taking an old computer out of the closet.

@Emulgator : Sorry about the confusion - I assumed you meant the commandline binary the whole time, which should work just fine on XP. If you want the use the GUI, you'll have to download a special build for Windows XP available here (https://github.com/justdan96/tsMuxer/actions/runs/146484594) or here (https://a.uguu.se/lWMiCFK1QYuN.7z) if you don't want to create a github account, but the link is only valid for 24 hours.

[filler56789]

What does the virtual machine bit have to do with anything?

Well, if I hadn't emphasized it, probably you would not wake up ;)

[Emulgator]

Thanks, Bloodyripper !
you'll have to download a special build for Windows XP available here or here if you don't want to create a github account, but the link is only valid for 24 hours.
Oh sorry, missed that one, was off for the weekend, can you please reupload the WinXP GUI?
24 hrs server up is quite brief, maybe use wetransfer, this would hold one week.

P.S. Well, I just opened an account on github, got the file..

[Emulgator]

Beautiful ! Under WinXP32ProSP3 BloodyRippers WinXP GUI throws no error on startup.

BD-Mux Folderset with AVC 1280x720x50p@28Mbps, duration 48m33s, AC-3 2.0 @192kbps
--start-time 524280, 18 custom chapters in HH:MM:SS.mmm

-------------------WinXP32ProSP3-------------------
32-bit CLI muxer d2c38c5:
Progressing...Success !
BDedit 0.49b finds no packet discrepancies, MPC-HC stream playback until the end.

32-bit WinXP GUI 2.6.16-dev + last muxer d2c38c5:
Progressing...Success !
BDedit 0.49b finds no packet discrepancies, MPC-HC stream playback until the end.
--------------------Win7U64SP1---------------------------
32-bit CLI muxer d2c38c5:
Progressing...Success !
BDedit 0.49b finds no packet discrepancies, MPC-HC stream playback until the end.

32-bit GUI + muxer d2c38c5:
Progressing...Success !
BDedit 0.49b finds no packet discrepancies, MPC-HC stream playback until the end.

64-bit CLI muxer d2c38c5:
Progressing...Success !
BDedit 0.49b finds no packet discrepancies, MPC-HC stream playback until the end.

64-bit GUI + muxer d2c38c5:
Progressing...Success !
BDedit 0.49b finds no packet discrepancies, MPC-HC stream playback until the end.

And the default .meta file extension is back, nice.

[Emulgator]

Emulgator: Ouch. That would make the newer tsMuxeR builds unusable under WinXP and much worse, even under Win7.
filler56789: The latest tsMuxer GUI works normally under my 64-bit Windows 7
But then I don't let the OS update itself, to begin with...

Sorry for ambiguity: Both 32 and 64bit GUIs seem to work here under Win7U64SP1
and they won't be able to bork the .meta files on passing towards cutting packets I guess.

What I meant to say was: the connected tsMuxeR.exes probably might lose ~12s worth of packets
under Win7U64SP1 from that 1280x720x50p elementary .avc around end.
Will test other framerate/resolutions if necessary.

P.S. At the moment under WinXP32ProSP3 the new 32-bit tsMuxeR.exe CLI works fine with my .avc test stream,
even better: all new d2c38c5 versions 32 bit and 64 bit, CLI and GUI seem to mux to the end under Win7, see above.

[B1gD4ddy]

build from 27.06 has a bug at least for me.
i unpacked a complete iso, removed some audio and subs with tsmuxer and then saved it as iso and tsmuxer put the m2ts in the root of the iso instead in the bdmv\stream folder.
and thus cant be played
older builds work fine.

[Emulgator]

2020-07-27: Unfortunately with a longer .avc stream 1280x720x50p I seem to get missing packets again.
Win7U64SP1

BD-Mux Folderset with AVC 1280x720x50p@28Mbps, duration 1h44m43s, AC-3 2.0 @192kbps
--start-time 524280, 37 custom chapters in HH:MM:SS.mmm

00000.clpi says 120.949.280, BDedit 0.49b finds 120.946.688 packets,
2592 packets missing.
MPC-HC 1.9.6 Playback ends 7 seconds prematurely.
---
Different project, different streams:
BD-Mux Folderset with AVC 1280x720x50p@25Mbps, duration 1h59m46s, AC-3 2.0 @192kbps
--start-time 524280, 9 custom chapters in HH:MM:SS.mmm
BDedit 0.49b finds 123.679.296 packets, no packets missing.
MPC-HC 1.9.6 Playback until end.

For me it means back to 1.10.6 if AVC 1280x720x50p.
1.10.6 muxed all these streams perfectly again.
MPC-HC plays until end, BDedit doesn't complain.

[BloodyRipper]

And the default .meta file extension is back, nice.This was caused by a mishap while introducing multilanguage support.

Beautiful ! Under WinXP32ProSP3 BloodyRippers WinXP GUI throws no error on startup.I will look into providing this GUI by default in 32-bit Windows builds. This way, 32-bit builds will be runnable as a whole all the way down to Windows XP with the oldest processors possible (including pre-SSE ones), while 64-bit builds will use newer Qt versions and possibly leverage compiler optimisations that are possible with newer CPUs. All users should generally use the 64-bit version unless they have a strong reason not to, as it _might_ look better and run faster.

build from 27.06 has a bug at least for me.
i unpacked a complete iso, removed some audio and subs with tsmuxer and then saved it as iso and tsmuxer put the m2ts in the root of the iso instead in the bdmv\stream folder.
and thus cant be played
older builds work fine.
This is fixed in 2020-07-02--02-15-39.

[ryu34]

Hey does the 2019 shield pro support any native playback of the 4k dolby vision remuxes this version of tsmuxer creates?

[yannick92]

Hello,

Here's my problem:
I need to re-encode a MKV / VC-1 movie in H264 to play it on my PS3.
Indeed, this one does not read the VC-1 codec in TS file, and M2TS, I also remind that it does not read MKV.

Well, I'm used to remuxing all of my MKV / H264 to M2TS with TsMuxer, and never any problem reading them on PS3.
So here we are, this MKV / VC-1 therefore needs to be re-encoded in H264, and in my specific case to be encapsulated in M2TS or TS to be fully compatible with the PS3.
You follow me ?

Nothing too complicated you tell me, so here is my approach and why I can't do it ...
To re-encode certain HD movies in H264, I use CloneBD for its simplicity and quality of encoding without getting lost in unnecessary settings ...
But as you probably know, CloneBD does not know how to directly open an MKV, TS, M2TS file ...
It requires opening films in Bluray ISO, Bluray folder or AVCHD folder format exclusively!

So I'm going to need to make an ISO of my MKV file for after being able to open it with CloneBD, so I chose TsMuxer (git-632b6e4) for that.
So I open my MKV with TSMuxer (which is for information an "untouched" Remux with just the languages ​​and subtitles), I chose Bluray-ISO for muxing, and START.

I get my ISO, I launch CloneBD or I can now open my movie in ISO, everything is going well, I choose my encoding parameters, in my case "Full quality H264" for the video and "same as source" for audio, all this in MKV for encapsulation.
And there, when I want to start the encoding, it is the drama, CloneBD crash, the window freezes, and when I click on it it displays the famous "CloneBD do not answer" "want to leave you or wait until the program responds? "...

I tried again, always the same, by redoing an ISO with TsMuxer, same, I even tried with an AVCHD Folder and Bluray Folder structure, same problem ...
Will there be a bug with TsMuxer and Bluray ISO structures?

To be clear, I should point out that if I open another "original" ISO Bluray, without going through TsMuxer, CloneBD works very well when encoding!
I of course also tested with TsMuxer to make an ISO with another MKV file, same observation, CloneBD crash ...

Interesting comparison, via DVDfab, the Bluray ISO files made by TsMuxer do not crash !? (But I don't like DVDfab ...)
Someone would have any idea ?
Come to think of it, I am at a dead end, and question to $ 1,000,000, how can I properly convert my MKV file to Bluray ISO so that I can then encode it with CloneBD?

Here is a sample of my MKV for your possible investigations. https://uptobox.com/a6y3j3svbusf

Thank you very much in advance if you find the source of the problem, see you soon.

Yannick

EDIT: To be sure, I have just tested with TsMuxer 1.10.6, same procedure and it works !!!
CloneBD does not crash any more, the encoding is launched without problem!

There is a problem with the last nighly, right?

Yannick

[a5180007]

There is a problem with the last nighly, right?


Having tried previous versions, this behavior appeared with version of 21 March. I've pushed a reversion (https://github.com/justdan96/tsMuxer/pull/314)on previous patch, this bug should be fixed once the proposed patch has been merged.

Edit: @yannick92 please try latest version on Bintray nightly-2020-07-18--02-16-00.

[Richard1485]

Files with the .dtshd extension are not seen unless the user changes All supported media files to All files. Is it possible for .dtshd to be added to the former so they are visible by default? There's no trouble with these files. It's just the extension.

[staina]

Having tried previous versions, this behavior appeared with version of 21 March. I've pushed a reversion (https://github.com/justdan96/tsMuxer/pull/314)on previous patch, this bug should be fixed once the proposed patch has been merged.

Edit: @yannick92 please try latest version on Bintray nightly-2020-07-18--02-16-00.

1. What effect has this change to creation UHD 4K Bluray ISO and directories?
2. At comparison result from latest version and previous version are there different files M2TS and CLPI has it some influence on playback in multimedia players?
3. What this change one's parameter makes at creation UHD 4k Bluray?

Thank for responses. staina

[yannick92]

Having tried previous versions, this behavior appeared with version of 21 March. I've pushed a reversion (https://github.com/justdan96/tsMuxer/pull/314)on previous patch, this bug should be fixed once the proposed patch has been merged.

Edit: @yannick92 please try latest version on Bintray nightly-2020-07-18--02-16-00.
Ok thx

I just tested with the nightly-2020-07-18--02-16-00, it works very well, after doing my .ISO with TsMuxer, CloneBD does not crash anymore when encoding!

Thank you so much,
see you soon.

Yannick

[BloodyRipper]

Files with the .dtshd extension are not seen unless the user changes All supported media files to All files. Is it possible for .dtshd to be added to the former so they are visible by default? There's no trouble with these files. It's just the extension.This will be included in 2020-07-22 nightly.

[yannick92]

Hello

Small problem, I wanted to split an MKV file for my Fat 32 USB hard drive (max 4 GB per file), I select "Split by Size" every 4,000 GB ok? I run the mux in .TS, and
TsMuxer copies hundreds of randomly cut files to me ??
There is nothing to understand, unusable as it is of course ...

An idea gentlemen?
Especially since it works very well with TsMuxer 1.10.6

Thx a lot.

Yannick

EDIT: Also tested with w64-nightly-2020-07-22--02-14-59
same problem...

[Richard1485]

This will be included in 2020-07-22 nightly.

Thank you for seeing to this. It will make things easier. :)

[BloodyRipper]

Hello

Small problem, I wanted to split an MKV file for my Fat 32 USB hard drive (max 4 GB per file), I select "Split by Size" every 4,000 GB ok? I run the mux in .TS, and
TsMuxer copies hundreds of randomly cut files to me ??
There is nothing to understand, unusable as it is of course ...

An idea gentlemen?
Especially since it works very well with TsMuxer 1.10.6

Thx a lot.

Yannick

EDIT: Also tested with w64-nightly-2020-07-22--02-14-59
same problem...
I can't reproduce this with my "larger" MKV files with splitting set to 4GB or 4GiB or smaller files with splitting set to other thresholds, for example 300MB.
Please post the metafile that you're using. Perhaps this is related to how your particular file is handled.

[yannick92]

I can't reproduce this with my "larger" MKV files with splitting set to 4GB or 4GiB or smaller files with splitting set to other thresholds, for example 300MB.
Please post the metafile that you're using. Perhaps this is related to how your particular file is handled.

Okay
I tested with 2 .MKV files that I have already split with MkvToolnix to reduce the size for my encoding tests with Handbrake, they are between 5 and 8 GB, I will not be able to upload them ...
Could a MediaInfo log help you?

THX

Yannick

Général
Identifiant unique : 135129523374164645483133722259422988883 (0x65A8FFE218B02EBC183F0C6F4A444A53)
Nom complet : C:\Users\Yannick\Videos\Batman Test Handbrake VBR.mkv
Format : Matroska
Version du format : Version 4
Taille du fichier : 6,38 Gio
Durée : 30 min 0s
Débit global moyen : 30,5 Mb/s
Nom du film : THE_DARK_KNIGHT.2008.VFF_VO.BLURAY.REMUX.MKV
Date d'encodage : UTC 2020-07-16 20:04:17
Application utilisée : HandBrake 1.3.3 2020061300
Bibliothèque utilisée : Lavf58.29.100
ErrorDetectionType : Per level 1

Vidéo
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Profil du format : High@L4.1
Paramètres du format : CABAC / 4 Ref Frames
Paramètres du format, CABAC : Oui
Paramètres du format, RefFrames : 4 images
Identifiant du codec : V_MPEG4/ISO/AVC
Durée : 30 min 0s
Débit : 30,0 Mb/s
Largeur : 1 920 pixels
Hauteur : 1 080 pixels
Format à l'écran : 16/9
Type d'images/s : Constant
Images par seconde : 23,976 (24000/1001) Im/s
Espace de couleurs : YUV
Sous-échantillonnage de la chrominance : 4:2:0
Profondeur des couleurs : 8 bits
Type de balayage : Progressif
Bits/(Pixel*Image) : 0.603
Taille du flux : 6,16 Gio (97%)
Bibliothèque utilisée : x264 core 157 r2935 545de2f
Paramètres d'encodage : cabac=1 / ref=4 / deblock=1:0:0 / analyse=0x3:0x133 / me=umh / subme=10 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=24 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=6 / lookahead_threads=1 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=8 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=240 / keyint_min=24 / scenecut=40 / intra_refresh=0 / rc_lookahead=60 / rc=2pass / mbtree=1 / bitrate=30000 / ratetol=1.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / vbv_maxrate=62500 / vbv_bufsize=78125 / nal_hrd=none / filler=0 / ip_ratio=1.40 / aq=1:1.00
Default : Oui
Forced : Non
Gamme de couleurs : Limited
Coordonnées de chromaticité : BT.709
Caractéristiques du transfert : BT.709
Coefficients de la matrice : BT.709

Audio
ID : 2
Format : AC-3
Format/Info : Audio Coding 3
Nom commercial : Dolby Digital
Identifiant du codec : A_AC3
Durée : 30 min 0s
Type de débit : Constant
Débit : 448 kb/s
Canaux : 6 canaux
Channel layout : L R C LFE Ls Rs
Echantillonnage : 48,0 kHz
Images par seconde : 31,250 Im/s (1536 SPF)
Mode de compression : Avec perte
Taille du flux : 96,2 Mio (1%)
Titre : Surround
Langue : Français
Service kind : Complete Main
Default : Oui
Forced : Non

[von Suppé]

For a thread at VH I did some quick tests with importing a m2ts file only into tsMuxer and exporting as BD folder structure.
These tests were to find out if the results could be imported into MakeMKV without errors.

My findings say that if I use tsMuxer version 2.6.12, MakeKMV accepts the resulting BD perfectly.

Using the nightly portable (2020-07-22 64 bit), after import into MakeMKV, it returns with an error ("Failed to decode audio/video data for title #0 - invalid mux or internal error")

Eventhough the output performs well for my pc and mediaplayers and it seems to be okay further, is this something that must be looked into?

[outgoing]

Maybe a possible bug (tsMuxerGUI.exe CRC-32: f060620b It seems to me that this is the last or penultimate release). When I make a mux and apply a negative delay to the audio from the tsmuxer itself, the result is that the In time changes from the origianl and it doesn't play when you recreate the full bluray again. However, if I make the mux without applying the negative delay, the bluray (remain with the same In time from original) can be reassembled and played.

[yannick92]

Okay
I tested with 2 .MKV files that I have already split with MkvToolnix to reduce the size for my encoding tests with Handbrake, they are between 5 and 8 GB, I will not be able to upload them ...
Could a MediaInfo log help you?

THX

Yannick

Général
Identifiant unique : 135129523374164645483133722259422988883 (0x65A8FFE218B02EBC183F0C6F4A444A53)
Nom complet : C:\Users\Yannick\Videos\Batman Test Handbrake VBR.mkv
Format : Matroska
Version du format : Version 4
Taille du fichier : 6,38 Gio
Durée : 30 min 0s
Débit global moyen : 30,5 Mb/s
Nom du film : THE_DARK_KNIGHT.2008.VFF_VO.BLURAY.REMUX.MKV
Date d'encodage : UTC 2020-07-16 20:04:17
Application utilisée : HandBrake 1.3.3 2020061300
Bibliothèque utilisée : Lavf58.29.100
ErrorDetectionType : Per level 1

Vidéo
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Profil du format : High@L4.1
Paramètres du format : CABAC / 4 Ref Frames
Paramètres du format, CABAC : Oui
Paramètres du format, RefFrames : 4 images
Identifiant du codec : V_MPEG4/ISO/AVC
Durée : 30 min 0s
Débit : 30,0 Mb/s
Largeur : 1 920 pixels
Hauteur : 1 080 pixels
Format à l'écran : 16/9
Type d'images/s : Constant
Images par seconde : 23,976 (24000/1001) Im/s
Espace de couleurs : YUV
Sous-échantillonnage de la chrominance : 4:2:0
Profondeur des couleurs : 8 bits
Type de balayage : Progressif
Bits/(Pixel*Image) : 0.603
Taille du flux : 6,16 Gio (97%)
Bibliothèque utilisée : x264 core 157 r2935 545de2f
Paramètres d'encodage : cabac=1 / ref=4 / deblock=1:0:0 / analyse=0x3:0x133 / me=umh / subme=10 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=24 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=6 / lookahead_threads=1 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=8 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=240 / keyint_min=24 / scenecut=40 / intra_refresh=0 / rc_lookahead=60 / rc=2pass / mbtree=1 / bitrate=30000 / ratetol=1.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / vbv_maxrate=62500 / vbv_bufsize=78125 / nal_hrd=none / filler=0 / ip_ratio=1.40 / aq=1:1.00
Default : Oui
Forced : Non
Gamme de couleurs : Limited
Coordonnées de chromaticité : BT.709
Caractéristiques du transfert : BT.709
Coefficients de la matrice : BT.709

Audio
ID : 2
Format : AC-3
Format/Info : Audio Coding 3
Nom commercial : Dolby Digital
Identifiant du codec : A_AC3
Durée : 30 min 0s
Type de débit : Constant
Débit : 448 kb/s
Canaux : 6 canaux
Channel layout : L R C LFE Ls Rs
Echantillonnage : 48,0 kHz
Images par seconde : 31,250 Im/s (1536 SPF)
Mode de compression : Avec perte
Taille du flux : 96,2 Mio (1%)
Titre : Surround
Langue : Français
Service kind : Complete Main
Default : Oui
Forced : Non


It's odd that you can't reproduce this bug, it is systematic on all the MKV that I tested?
Attached is a capture of the split files that I get ...

17467

[tebasuna51]

@yannick92

I can confirm the problem, I checked the split with 2 mkv's and tsMuxeR split the file by keyframes (the same number of fragments than keyframes) ignoring the size.

The metafile:

MUXOPT --no-pcr-on-video-pid --new-audio-pes --hdmv-descriptors --vbr --split-size=3,000GB --vbv-len=500
V_MPEG4/ISO/AVC, "D:\Temp\test.mkv", insertSEI, contSPS, track=1, lang=eng
...

I don't know if the "3,000GB" can be a problem. I put "3" without decimals in the capture and is the same.

EDIT:
That is the problem, with the .meta file edited to "3GB" or "3.000GB" works fine

[BloodyRipper]

@tebasuna51 @yannick92

Thanks a lot. Another locale issue, since tsMuxer is hardcoded to use a decimal dot when parsing this particular argument. Since my locale uses a dot as well, I obviously could not reproduce it. This should be fixed in 2020-08-18 nightly.

[tebasuna51]

Thanks, problem solved.

[Emulgator]

A small wish to the developers:
I would welcome the usual changelog per build where one can see what has changed.
The release notes add up what has been achieved for Version 2.6.16, but do not mention the various builds.
Right now from 2019 12 14 until today I have 146 builds sitting in my tsMuxeR folder, so bugtracking becomes a bit hard.

[maxibon]

A subtitle bug or a wish to the developers

When I change the color of a subtitle in a UHD Bluray only if the format is srt works fine. Could if possible working as well if codec is pgs?

Let me show some images what's happening

https://t45.pixhost.to/thumbs/142/160272394_anotacion-2020-08-30-075959.png (https://pixhost.to/show/142/160272394_anotacion-2020-08-30-075959.png)

https://t45.pixhost.to/thumbs/142/160272395_anotacion-2020-08-30-080150.png (https://pixhost.to/show/142/160272395_anotacion-2020-08-30-080150.png)

Result ok with srt

https://t45.pixhost.to/thumbs/142/160272396_anotacion-2020-08-30-080337.png (https://pixhost.to/show/142/160272396_anotacion-2020-08-30-080337.png)

Same color if pgs

https://t45.pixhost.to/thumbs/142/160272399_anotacion-2020-08-30-080444.png (https://pixhost.to/show/142/160272399_anotacion-2020-08-30-080444.png)

Regards

[r0lZ]

PGS subtitles are in graphic format. The colors are in the image. And there can be any number of colors in a single subtitle. The only way to change the colors is to convert the subtitles to XML/PNG (with BDSup2Sub for example), edit the PNG images with a graphic programs, and convert them back to BD SUP.
In the other hand, a SRT is a simple text, converted to graphics at playback time. Therefore the color is not dependent of the subtitle stream, and you can change it easily.

[maxibon]

Could yo tell me which graphic programs should I use in order to edit PNG images?

Thanks