See issue #459:
There are 3 places on macOS where fonts are located:
/System/Library/Fonts contains system fonts. That folder usually remains untouched.
/Library/Fonts contains additional fonts and fonts installed by different apps. User can install fonts to that folder. There is an Arial Unicode.ttf font in that folder.
~/Library/Fonts/ is usually empty by default. User can install fonts to that folder.
As per "ISO/IEC 13818-1:2019/DAmd 2 - Carriage of VVC in MPEG-2 Systems":
In 2.4.4.9, in Table 2-34, Stream type assignments, replace the following line:
0x32-0x7E ITU-T Rec. H.222.0 | ISO/IEC 13818-1 Reserved
with:
0x32 VVC video stream or an VVC temporal video sub-bitstream conforming to one or more profiles defined in Annex A of Rec. ITU-T H.26X | ISO/IEC 23090-3
When trying to mux pure E-AC3 in a Blu-ray ISO or folder, tsMuxer aborts without warning in the GUI (the warning is shown only in the console version).
This patch allows the warning to be also shown in the GUI.
A situation can occur where tsMuxer tries to extract data from a block which is not a PG track, and blocksize = 0 results in an infinite loop.
Fixes#440.
As per T-REC-H265 standard sub-clause 7.4.2.2., when nal_unit_type == VPS_NUT or SPS_NUT or EOS_NUT or EOB_NUT, nuh_temporal_id shall be equal to 0.
This patch allows early return when this condition is not fulfilled therefore the stream is obviously not hevc.
Fixes#418, #419, #420, #424, #436, #437.
Arrays should generally be deleted with delete[]. Also, this operator's behaviour (as well as the normal delete's) is well defined on null pointers (it's a no-op), so the if is totally needless.
The m_nalBuffer member was incremented in the loop while copying, which naturally led to the pointer being invalid when the destructor is executed in order to delete the array. The code was replaced with an equivalent std::copy call.
Also, replaced the invalid delete with delete[].
Fixes#395.
Bintray builds have been created every night since the 5th of December. Not only
is this caused by a runaway "0" at the end of the line responsible for updating
the commit.txt file (oh, those long lines!), but Bintray has been returning the
200 OK code when attempting an update of the file despite also returning an
error and the file not actually being updated :
{"message":"Version 'latest' has been published for more than 365 days. Files can only be uploaded to a version within 365 days from its publish date."}
Hopefully, creating a version in the "commit" package with the same version as
the nightlies will solve this problem.
H264 standard states "log2_max_mv_length_horizontal and log2_max_mv_length_vertical indicate the maximum absolute value of a decoded horizontal and vertical motion vector component, respectively, in ¼ luma sample units, for all pictures in the coded video sequence. [ ] The value of log2_max_mv_length_horizontal shall be in the range of 0 to 15, inclusive. The value of log2_max_mv_length_vertical shall be in the range of 0 to 15, inclusive".
However some hardware decoders seem to produce log2_max_mv_length with values of 16.
* CMake tweaks to make the project more linux packager friendly
- Add install target for tsMuxerGUI
- Add install for contributed desktop file
- Install icon for desktop file
- Don't check for C when all sources are C++.
Long overdue fixes to the warnings in file_unix.cpp. Also, move the POSIX-exclusive fcntl.h include from file.h to file_unix.cpp and remove MSVC warning suppression related to exception specifications, which were also removed as they have been deprecated since C++11.
