jcdr428
678afad022
[bug] Parse mp4 tx3g without modifiers
...
The tx3g sample is a text potentially followed by text modifiers.
This fix removes the incorrect looping until the parsing of the modifiers is implemented.
See para. 5.17.1 of https://www.etsi.org/deliver/etsi_ts/126200_126299/126245/08.00.00_60/ts_126245v080000p.pdf for Sample Modifier Boxes
2022-05-31 17:45:54 +01:00
jcdr428
5fd538c7f1
Update rebuild_mxe32_with_gui_docker.sh
...
Add zip back
2022-05-31 14:48:57 +01:00
jcdr428
c349bc783f
Update rebuild_mxe_with_gui_docker.sh
...
Add .zip back
2022-05-31 14:47:44 +01:00
jcdr428
d77bf2265c
Update rebuild_mxe32_with_gui_docker.sh
2022-05-30 09:14:52 +01:00
jcdr428
de2f63d441
Update rebuild_mxe_with_gui_docker.sh
2022-05-30 09:14:32 +01:00
jcdr428
3b9cc87352
Merge branch 'master' of https://github.com/justdan96/tsMuxer
2022-05-29 21:31:39 +01:00
jcdr428
ca760a9371
[bug] Allow for tx3g text modifier
...
the subtitle text can be followed by modifiers.
The parsing of the modifier (e.g. 'styl' atom) is still to be done.
2022-05-29 21:30:50 +01:00
jcdr428
d1f72f9335
Update rebuild_mxe32_with_gui_docker.sh
...
Uploads unzipped files only in /bin floder.
2022-05-29 19:07:39 +01:00
jcdr428
699917f329
Update rebuild_mxe_with_gui_docker.sh
...
Put unzipped files only in /bin folder.
2022-05-29 19:04:35 +01:00
jcdr428
031c71855c
Fix deprecated ISO 639-2 lang codes
2022-05-29 18:00:26 +01:00
jcdr428
6843a76174
Correct lang codes from inputs
...
If a language code is ISO 639-2/B, format, it is automatically corrected to ISO 639-2/T.
2022-05-29 17:53:21 +01:00
jcdr428
a46e6e5e09
Fix Macintosh language codes
...
According to ISO 639-2/T
2022-05-29 16:26:14 +01:00
jcdr428
580911902e
Additions to language codes
...
According to ISO 639-2/T:
Abkhazian, Miscellaneous, Montenegrin, Moroccan Tamazight, Undetermined
2022-05-29 15:28:31 +01:00
jcdr428
5448133f69
Fix French language code
...
Bluray uses ISO 639-2/T "fra" language code, not ISO 639-2/B "fre".
2022-05-29 13:17:17 +01:00
jcdr428
b08bf9471d
Fix Greek language code
...
Bluray uses ISO 639-2/T "ell" language code, not ISO 639-2/B "gre" code.
2022-05-29 13:09:02 +01:00
jcdr428
4c0968f4f8
Fix Icelandic language code
...
Bluray uses ISO 639-2/T "isl" language code, not ISO 639-2/B "ice" code.
2022-05-29 13:07:41 +01:00
jcdr428
718d1bf1ac
Fix Georgian language code
...
Bluray uses ISO 639-2/T "kat" language code, not ISO 639-2/B "geo" code.
2022-05-29 13:06:25 +01:00
jcdr428
26b7519edb
Fix Macedonian language code
...
Bluray uses ISO 639-2/T "mkd" language code, not ISO 639-2/B "mac" code.
2022-05-29 13:04:14 +01:00
jcdr428
abe3b11657
Fix Maori language code
...
Bluray uses ISO 639-2/T "mri" language code, not ISO 639-2/B "mao".
2022-05-29 13:01:02 +01:00
jcdr428
914d4bc253
Fix Burmese language code
...
Bluray uses ISO 639-2/T "mya" language code, not ISO 639-2/B "bur" code.
2022-05-29 12:59:51 +01:00
jcdr428
0bea80c95b
Fix Romanian language code
...
Bluray uses ISO 639-2/T "ron" language code, not ISO 639-2/B "rum".
2022-05-29 12:58:22 +01:00
jcdr428
eabeb4effc
Fix Welsh language code
...
Bluray uses ISO 639-2/T "cym" language code, not ISO 639-2/B "wel" code.
2022-05-29 12:55:50 +01:00
jcdr428
b833dbfa53
Fix Slovak language code
...
Bluray uses ISO 639-2/T "slk" language code, not "ISO 639-2/B "slo" code.
2022-05-29 12:54:35 +01:00
jcdr428
1bdfb56e95
Fix Serbian language code
...
"scc" code does not exist in ISO 639-2.
2022-05-29 12:52:47 +01:00
jcdr428
374d1990b7
Fix the malay language code
...
Bluray uses the "msa" ISO 639-2/T lnguage code, not the "may" ISO 639-2/B code.
2022-05-29 10:25:32 +01:00
jcdr428
cbc0ac064c
Fix the French language code
...
Bluray uses the "fra" ISO 639-2/T language code, not the "fre" ISO 639-2/B code.
2022-05-29 10:24:13 +01:00
jcdr428
4b3051f4ec
Fix the Dutch/Flemish language code
...
Bluray uses the "nld" ISO 639-2/T language code, not the "dut" ISO 639-2/B code.
2022-05-29 10:22:36 +01:00
jcdr428
09284b6473
Remove "scr" code
...
"scr" does not exist in ISO 639-2.
2022-05-29 10:21:14 +01:00
jcdr428
23c8e4dff2
Fox Czech language code
...
Bluray uses the "ces" ISO 639-2/T language code, not the "cze" ISO 639-2/B code.
2022-05-29 10:19:46 +01:00
jcdr428
8f0014b04e
Fix Chinese language code
...
Bluray uses the "zho" ISO 639-2/T language code, not the "chi" ISO 639-2/B code.
2022-05-29 10:18:07 +01:00
jcdr428
2dd95d4cff
Remove duplicate Basque language code
2022-05-29 10:16:51 +01:00
jcdr428
58dd2d93d9
Fix the Armenian language code
...
Bluray uses the "hye" ISO 639-2/T language code, not the "arm" ISO 639-2/B code.
2022-05-29 10:15:59 +01:00
jcdr428
1c62bb74af
Fix the Albanian language code
...
Bluray uses the "sqi" ISO 639-2/T language code, not the "alb" ISO 639-2/B code.
2022-05-29 10:14:29 +01:00
jcdr428
dea543a8bf
Fix Persian language code
...
Bluray should use the "fas" ISO 639-2/T code, not the "per" ISO 639-2/B code.
2022-05-29 10:11:53 +01:00
jcdr428
5791abe0cc
Reduce PTS offset
...
Initial PTS offset is set to 378000000 (in 90000 Hz) which is 1h10min.
Commercial Blu-ray initial offsets are generally 10-12 sec.
PTS offset is reduced to 900000 = 10 sec.
2022-05-29 10:04:07 +01:00
jcdr428
ae7402a776
Fix German ISO language code
...
German "ger" is ISO 639-2/B
Blur-ray should be ISO 630-2/T "deu"
2022-05-29 10:01:29 +01:00
jcdr428
146594c4eb
Clarify operator precedence
2022-05-28 15:25:09 +01:00
jcdr428
e62e46d290
[bug] correction on commit aac7d2b
2022-05-28 15:18:45 +01:00
jcdr428
748f442ae3
clang format check
2022-05-24 22:48:03 +01:00
jcdr428
ddecfd75f3
Mark derived methods used in destructors as final
...
Prevents 'warning Call to virtual method 'ISOFile::close' (resp. 'MatroskaDemuxer::readClose' / 'MovDemuxer::readClose') during destruction bypasses virtual dispatch [clang-analyzer-optin.cplusplus.VirtualCall]'.
2022-05-24 22:45:44 +01:00
jcdr428
f0c0ca19e5
Small optimization
...
Prevents a clang-analyzer-core.UndefinedBinaryOperatorResult warning
2022-05-24 21:30:00 +01:00
jcdr428
aac7d2b26c
Prevent <<32 undefined behavior
2022-05-24 21:08:08 +01:00
jcdr428
aa26bf07f4
Regression on commit e85de6
...
Increase of TMP_BUFFER_SIZE is a priori not necessary anymore with fix/commit eaf0c4.
2022-05-24 14:43:01 +01:00
jcdr428
eaf0c44ef0
[bug] Limit readCnt to DEFAULT_FILE_BLOCK_SIZE
...
The size of the data read from the stream and copied to the buffer should be limited to DEFAULT_FILE_BLOCK_SIZE to avoid the 'Not enough buffer for parse video stream' error.
2022-05-24 14:38:35 +01:00
Daniel Kamil Kozar
24ae93589c
Fixes to German about.html ( #597 )
2022-05-15 23:04:42 +02:00
Daniel Kamil Kozar
46c06fa6eb
Fix German about file appearing in Hebrew language version
2022-05-15 22:58:20 +02:00
Daniel Kamil Kozar
28b1d1eeec
Make language names translatable ( #603 )
...
Fixes #591 .
2022-05-15 22:53:32 +02:00
Daniel Kamil Kozar
77f9dc3c84
Avoid shifting by 32 bits in BitStreamWriter ( #602 )
...
Left-shifting by an amount which is more or equal to the type's width is undefined in both C and C++. This could happen in BitStreamWriter when m_bitWrited was zero, and resulted in inconsistent results between Intel and ARM targets.
On Intel, the amount of bits to shift is explicitly masked to its lower 5 (for 32-bit values) or 6 (for 64-bit values) bits. This is documented in the instruction set reference. Effectively, the amount of bits to be shifted is the actual amount modulo 32 or 64. In this particular case, asking the CPU to shift by 32 bits left the value unchanged.
ARM does not place any requirements on the behaviour of the CPU when the amount to shift is larger than 32/64 - the instruction set reference just says that the register is supposed to be "holding a shift amount from 0 to 31 in its bottom 5 bits. ". However, MSVC documentation suggests that values in registers might appear to "wrap around" when shifting by more than 32 or 64 bits, which is indeed what was observed here.
The fix essentially amounts to emulating Intel behaviour (as it was the original development platform and presumably most assumptions were made with it in mind, even if unknowingly) by not touching the value if the amount of bits to shift is 32.
2022-05-15 11:40:54 +02:00
Daniel Kamil Kozar
b2e5dd3528
Fix same off-by-one error in the other AddString() call
2022-05-14 11:22:25 +02:00
Daniel Kamil Kozar
6eac7abcd7
Fix off-by-one error in GraphicsPath::AddString() call ( #601 )
...
AddString's documentation clearly says that its second parameter is supposed to
be the number of characters to display. Since the vector returned by toWide() is
always null-terminated and the termination character is included in its size(),
this resulted in AddString() treating the termination character as something it
is supposed to actually draw.
Perhaps some versions of AddString() explicitly stop at the termination
character and don't process any further characters : this is probably why this
issue has gone unnoticed for so long.
Fixes #598
2022-05-14 11:07:01 +02:00