Box character drawn at the end of line when rendering subtitles in W64 build

[shag00]

Using any release from 1/3/20 or later results in subtitles being muxed incorrectly. Every line of every subtitle has a box drawn at the end as shown in the attachment Using the W64 version.

How something like this can go unnoticed for such a long period of time can only be attributed to your prolonged refusal to actually release a release version of this software. Do you not understand that the vast majority of people are not interested in daily builds, they want well used and stable releases that meet their needs. Version 2.6.12 (which I understand is the last stable release) from 2014 is not that. This only came to my attention because I fresh installed my OS.

I have not tested UHDs yet.

[shag00]

What caught me eye? - .m2ts containers do not support srt streams.

well, this is how tsmuxer works for me - it takes few streams (stand alone or muxed into mkv, or mix of two methods) and while just muxing audio and video it also turn srt into pgs stream, to mux into final ts.

And the issue/problem/bug is that it is adding an artefact when, " it also turn srt into pgs stream"

[shag00]

Addressing your EDIT, You appear to be creating a BD ISO (my lack of technical knowledge may have led me to the wrong conclusion), this is not what I am doing. I am just creating a simple .m2ts file.

[Randrianasulu]

well, using latest tsmuxer/win32 under wine-5.5 (I do not have Arial font for some reason, so I used Dejavu Sans) - still no artefacts?

[Randrianasulu]

this is how my subtitle settings looks like

[shag00]

Which of the 6 asset releases are you using?

[Randrianasulu]

@shag00 https://github.com/justdan96/tsMuxer/releases/download/nightly-2022-05-05-02-59-07/w32.zip

w32.zip

[shag00]

OK, so I setup this 32 bit file and the result did not change. Some other errors are apparent but I won't cloud the issue with them.

[shag00]

If I run the appimage version the problem is solved.

[justdan96]

It has to be with the specific code used for the Windows subtitle management, I might have a Windows VM somewhere to try to test this on, but we I think have to analyse the SRT output from Linux and Windows to compare.

[shag00]

@justdan96 thanks, as you appear to have pin-pointed where the issue is I will explain the other error in using today's release. In addition to the rectangle issue some of text is coloured black, appears to be totally random and does not affect every line.

[justdan96]

Actually we can just compare SRT output from before 2020-01-03 with after as well, if that is easier.

@xavery would you be able to check if this commit may have changed the string handling - either it includes the LF character or is adding a /0 char or something like that? https://github.com/justdan96/tsMuxer/commit/9670fd6b19599efb44b66f5c70dc43d112119bd1#diff-9d4045e9c9ad4aa5a29bd9b2120977356ecb5820319dd5f17dc790a078e692a7

[Randrianasulu]

I also run cppcheck on tsMuxer sources:

$ cd tsMuxer/tsMuxer
$ cppcheck -x c++ -j 8 *.cpp
Checking AbstractDemuxer.cpp ...
Checking aac.cpp ...
Checking aacStreamReader.cpp ...
Checking abstractMuxer.cpp ...
Checking ac3Codec.cpp ...
Checking ac3StreamReader.cpp ...
Checking avCodecs.cpp ...
Checking bitStream.cpp ...
1/55 files checked 0% done
2/55 files checked 0% done
Checking blurayHelper.cpp ...
Checking bufferedFileReader.cpp ...
aac.cpp:85:29: error: Array 'aac_sample_rates[16]' accessed at index 63, which is out of bounds. [arrayIndexOutOfBounds]
        if (aac_sample_rates[i] == m_sample_rate)
                            ^
aac.cpp:84:23: note: Assuming that condition 'i<sizeof(aac_sample_rates)' is not redundant
    for (int i = 0; i < sizeof(aac_sample_rates); i++)
                      ^
aac.cpp:85:29: note: Array index out of bounds
        if (aac_sample_rates[i] == m_sample_rate)
                            ^
aac.cpp:94:25: error: Array 'aac_channels[8]' accessed at index 31, which is out of bounds. [arrayIndexOutOfBounds]
        if (aac_channels[i] == m_channels)
                        ^
aac.cpp:93:23: note: Assuming that condition 'i<sizeof(aac_channels)' is not redundant
    for (int i = 0; i < sizeof(aac_channels); i++)
                      ^
aac.cpp:94:25: note: Array index out of bounds
        if (aac_channels[i] == m_channels)
                        ^
3/55 files checked 0% done
4/55 files checked 0% done
Checking bufferedFileWriter.cpp ...
Checking bufferedReader.cpp ...
5/55 files checked 0% done
6/55 files checked 0% done
Checking bufferedReaderManager.cpp ...
Checking combinedH264Demuxer.cpp ...
Checking bufferedFileReader.cpp: _WIN32...
7/55 files checked 1% done
8/55 files checked 1% done
Checking convertUTF.cpp ...
Checking dtsStreamReader.cpp ...
9/55 files checked 2% done
10/55 files checked 2% done
Checking dvbSubStreamReader.cpp ...
11/55 files checked 2% done
Checking h264StreamReader.cpp ...
Checking hevc.cpp ...
Checking convertUTF.cpp: CVTUTF_DEBUG...
12/55 files checked 3% done
13/55 files checked 4% done
Checking hevcStreamReader.cpp ...
Checking ioContextDemuxer.cpp ...
14/55 files checked 6% done
Checking blurayHelper.cpp: _DEBUG...
Checking iso_writer.cpp ...
15/55 files checked 6% done
16/55 files checked 9% done
Checking lpcmStreamReader.cpp ...
Checking main.cpp ...
Checking hevc.cpp: _DEBUG...
Checking iso_writer.cpp: _WIN32...
17/55 files checked 14% done
Checking blurayHelper.cpp: _WIN32...
Checking matroskaDemuxer.cpp ...
18/55 files checked 16% done
Checking hevcStreamReader.cpp: _DEBUG...
19/55 files checked 21% done
Checking matroskaParser.cpp ...
Checking metaDemuxer.cpp ...
20/55 files checked 24% done
21/55 files checked 27% done
Checking mlpCodec.cpp ...
Checking mlpStreamReader.cpp ...
22/55 files checked 27% done
23/55 files checked 27% done
Checking movDemuxer.cpp ...
Checking mp3Codec.cpp ...
24/55 files checked 29% done
25/55 files checked 30% done
Checking mpeg2StreamReader.cpp ...
Checking mpegAudioStreamReader.cpp ...
26/55 files checked 30% done
27/55 files checked 31% done
Checking mpegStreamReader.cpp ...
Checking mpegVideo.cpp ...
28/55 files checked 32% done
29/55 files checked 33% done
Checking muxerManager.cpp ...
Checking nalUnits.cpp ...
matroskaDemuxer.cpp:1935:5: error: Using 'memset' on struct that contains a 'std::vector'. [memsetClass]
    memset(track, 0, MAX_TRACK_SIZE);
    ^
30/55 files checked 34% done
31/55 files checked 41% done
Checking pesPacket.cpp ...
Checking programStreamDemuxer.cpp ...
32/55 files checked 41% done
33/55 files checked 43% done
Checking psgStreamReader.cpp ...
Checking simplePacketizerReader.cpp ...
34/55 files checked 44% done
35/55 files checked 45% done
Checking singleFileMuxer.cpp ...
Checking srtStreamReader.cpp ...
36/55 files checked 50% done
Checking muxerManager.cpp: _DEBUG...
Checking textSubtitles.cpp ...
37/55 files checked 55% done
Checking psgStreamReader.cpp: _DEBUG...
Checking textSubtitlesRender.cpp ...
Checking srtStreamReader.cpp: _WIN32...
Checking singleFileMuxer.cpp: _WIN32...
Checking textSubtitles.cpp: OLD_WIN32_RENDERER...
38/55 files checked 57% done
Checking psgStreamReader.cpp: _WIN32...
Checking tsDemuxer.cpp ...
39/55 files checked 58% done
40/55 files checked 59% done
Checking tsMuxer.cpp ...
Checking tsPacket.cpp ...
Checking textSubtitles.cpp: WIN32_DEBUG_FREETYPE;_WIN32...
Checking main.cpp: _DEBUG...
Checking textSubtitles.cpp: _WIN32...
41/55 files checked 61% done
42/55 files checked 63% done
Checking utf8Converter.cpp ...
Checking vc1Parser.cpp ...
Checking metaDemuxer.cpp: _WIN32...
Checking utf8Converter.cpp: _WIN32...
43/55 files checked 63% done
44/55 files checked 65% done
Checking vc1StreamReader.cpp ...
Checking vod_common.cpp ...
45/55 files checked 66% done
46/55 files checked 67% done
Checking vvc.cpp ...
Checking vvcStreamReader.cpp ...
Checking textSubtitlesRender.cpp: _WIN32...
47/55 files checked 68% done
Checking vvcStreamReader.cpp: _DEBUG...
Checking wave.cpp ...
48/55 files checked 69% done
49/55 files checked 70% done
Checking tsPacket.cpp: _DEBUG...
Checking tsMuxer.cpp: _DEBUG...
50/55 files checked 72% done
Checking main.cpp: _WIN32...
51/55 files checked 78% done
52/55 files checked 87% done
Checking tsMuxer.cpp: _WIN32...
53/55 files checked 92% done
54/55 files checked 95% done
Checking vvc.cpp: _DEBUG...
55/55 files checked 100% done

[jcdr428]

@shag00 I cannot reproduce the issue on my Win64. Could you please post a sample of a faulty m2ts. Edit: what media player do you use ?

[shag00]

@jcdr428 I have a file, it is 4.2 GB, do you want that or a much smaller one (5 min only)? I use both VLC and MPV, both display the same thing.

[shag00]

Please also give me a clean email address to send the link to.

[jcdr428]

@shag00 5min. is enough. jcdr428.github@gmail.com

[shag00]

link sent

[jcdr428]

Link not received as of this morning 7am. Can you please send from another email address ?

[shag00]

I re-sent the file with a copy to myself and I have received it. As it's from one drive I cannot change the sending address.

[jcdr428]

In addition to the rectangle issue some of text is coloured black, appears to be totally random and does not affect every line.

Actually it is not random, color always changes after letter 'u'. So you have specific letters that create specific actions: \x75 ('u') changes color, \x0A (return) displays a square.

Other than that I have no idea what could create this in commit https://github.com/justdan96/tsMuxer/commit/9670fd6b19599efb44b66f5c70dc43d112119bd1

[shag00]

@jcdr428 the colour issue only applies to very recent releases not the 1/3/2020 release referred to in this bug report, please ignore.

[justdan96]

@jcdr428 Perhaps we can partially revert that commit locally to test if it causes the issue?

[jcdr428]

@shag00 can you please identify the latest release working without the color issue ?

@justdan96 the bug seems to be specific to shag00 PC, I can't reproduce.

[shag00]

@jcdr428 Re the colour issue, I have tested all the way back to the first release, 16/12/19 and find even it is affected. I can confirm that it occurs after a line that contains the letter "U" is encountered. The remainder of the line after the "U" is coloured black. The next line returns to normal (white) colour.

As the last time I clean installed my PC was early 2020 I cannot recall what version or from what source I acquired TSMuxer from but I have been using it on a daily basis since before that time and the issue was not present. I suspect it was a patched version from DOOM9 or something as I do remember I did not become aware that you had taken up this project until some time after you had taken it up. I think the colour problem should be a separate ticket.

My apologies for the less than clear/correct information I provided earlier on this issue.

[lighterowl]

Yup, my bad. Even though I wasn't able to reproduce the issue directly, there is a problem in the GraphicsPath::AddString call in the Win32 subtitle renderer.

[lighterowl]

@shag00 Please retest and reopen if the issue is still not resolved. You can use the following builds to test :

Windows 64 : https://github.com/justdan96/tsMuxer/suites/6505476418/artifacts/241783524 Windows 32 : https://github.com/justdan96/tsMuxer/suites/6505476416/artifacts/241783538

Just replace the tsMuxeR.exe you're currently using with the one from the archive and re-run the mux.

[jcdr428]

I think the colour problem should be a separate ticket.

@shag00 Can you please open the "colour problem" issue (as I suppose it is still an issue) ?

@xavery glad to see you back. That must have been hell to find this bug !

[shag00]

My result is that neither player, VLC or MPV, detect a subtitle stream. Though viewing the file with Media Info returns the following for the text section: Text ID : 4608 (0x1200) Menu ID : 1 (0x1) Format : PGS Codec ID : 144 Delay relative to video : 3 s 41 ms

[jcdr428]

@shag00 can you please upload a sample of the m2ts ?

[lighterowl]

Worksforme with Big Buck Bunny and the following metafile, both with TS and M2TS output.

MUXOPT --no-pcr-on-video-pid --new-audio-pes --hdmv-descriptors --vbr  --vbv-len=500
V_MPEG4/ISO/AVC, "bbb_sunflower_1080p_30fps_normal.mp4", track=1, lang=und
A_MP3, "bbb_sunflower_1080p_30fps_normal.mp4", track=2, lang=und
A_AC3, "bbb_sunflower_1080p_30fps_normal.mp4", track=3, lang=und
S_TEXT/UTF8, "Outlander.S06E08.I.Am.Not.Alone.1080p.AMZN.WEB-DL.DDP5.1.H.264-NTb_Subtitles01.ENG.srt",font-name="Cascadia Code",font-size=24,font-color=0xff55aa7f,font-underline,font-strikeout,bottom-offset=24,font-border=5,text-align=center,video-width=1920,video-height=1080,fps=30

vlc 3.0.8 screenshot here

Share your metafile maybe?

[shag00]

sent incorrect file, sending correct one now

[shag00]

@xavery how to obtain the metadata info you want?

[lighterowl]

@shag00 If you're using the GUI, just copy and paste the bottom part of the window. If you're using the commandline, it's the first file that you pass to the application, i.e. if you call tsmuxer as tsmuxer myfile.meta output.ts, then what we're looking for is the contents of myfile.meta.

[shag00]

MUXOPT --no-pcr-on-video-pid --new-audio-pes --hdmv-descriptors --vbr --cut-end=300000ms --vbv-len=500 V_MPEG4/ISO/AVC, "/mnt/data1/A/Halo.S01E08.Allegiance.1080p.AMZN.WEB-DL.DDP5.1.H.264-NTb_Video01.UND.h264" A_AC3, "/mnt/data1/A/Halo.S01E08.Allegiance.1080p.AMZN.WEB-DL.DDP5.1.H.264-NTb_Audio01.ENG.eac3" S_TEXT/UTF8, "/mnt/data1/A/Halo.S01E08.Allegiance.1080p.AMZN.WEB-DL.DDP5.1.H.264-NTb_Subtitles01.ENG.srt",font-name="Arial",font-size=30,font-color=0xffffffff,bottom-offset=24,font-border=5,text-align=center,video-width=1920,video-height=960,fps=24

[shag00]

AH! think I found it seems I choose aerial, works with other font

[shag00]

can re-close

[shag00]

@justdan96 colour problem is also fixed.

[Randrianasulu]

On Monday, May 9, 2022, shag00 @.***> wrote:

@Randrianasulu https://github.com/Randrianasulu not sure what you are asking or how to check. All my subtitles are produced by a program called subtitle edit which I have been using since about 2014 without issue. As I can shown the muxing with MKVToolnix works fine and pin point when TSMuxer started having problems is it not resonable to assume that TSMuxer is the problem? I download 2 versions of the same program issued 1 day apart and 1 works and 1 does not on the same system, that's not a line ending issue.

well, thank you for pinpointing faulty version.. I am not developer enough for seeing problem in code, I just saw sometimes codepage/font/locale/line endings interplay can give all sort of bugs.

I have no doubt you can reproduce problem on your machine/system - but it might be specific to your Windows installation, or some type of install or some setting ...

— Reply to this email directly, view it on GitHub https://github.com/justdan96/tsMuxer/issues/598#issuecomment-1120892953, or unsubscribe https://github.com/notifications/unsubscribe-auth/AJSS7TOVAPI66HG5XHMG6ULVJDOM5ANCNFSM5VNS4E2Q . You are receiving this because you were mentioned.Message ID: @.***>