It is dangerous insofar as it pollutes an immense number of source
files. For example, utf8cpp's stuff uses relative namespace
names (e.g. `utf8::some_type`). If `using namespace libebml` is in
effect, then this clashes with `libebml::utf8` which is a typedef for
`unsigned char`, causing compiler errors.
One side affect of the fixed bug was that trying to identify/mux an
empty file (file with a size of 0) resulted in the following error
message:
> Error: buffer_c: num > m_filled. Should not have happened. Please
> file a bug report.
Taking an `int` was done due to clang-tidy's modernize checks
bemoaning the use of integers 0 and 1 instead of `true` and `false`
for Boolean parameters. However, that had the unintended consequence
of truncating values if the values given to the parameter is e.g. a
`uint64_t` for which a bit was tested with "value & (1 << shift)" —
which relied on implicit conversion to bool.
Part of an ongoing effort to replace the use of the term `timecode`
with `timestamp`. Timecodes have a very specific meaning in the
audio/video world, and it's not what MKVToolNix has been using the
term for.
This should be used for reading signed integers from files where
they're stored in 2's complements (as all modern processors use). In
cases where the unsigned integer is bigger than the maximum signed
integer, static_cast<>ing is an implementation-defined behavior.
The code was adopted from the following answer on Stack Overflow where
they discuss an implementation that avoids such implementation-defined
behavior: https://stackoverflow.com/a/13208789/507077
This re-writes the "parse_number_with_unit" not to use the "double" data
type internally but int64_t-based fractions. This fixes issues with
"double" precision on certain 32bit platforms and test cases failing.
This is a fix for #1705.
Due to this change the handling of the syntax "1234/56i" with "i" as the
unit was fixed as well. Before the value was wrongfully multiplied
instead of divided by 2 leading to quadruple the expected value being
returned. This was mentioned in and fixes part of #1673.
For one it makes for easier-to-use interfaces such as
bc.set_bit_position(bc.get_bits…)) without having to check if the
position is at the end and the get_bits returns 0. It's also consistent
with containers in the standard C++ library.
In this particular case it fixes the AAC handling of program config
elements with an empty comment field that are located at the end of the
GA specific config where the aforementioned pattern of
set_bit_position(get_bits(…)) is used.
Fixes#1578.
This reverts commits 2c11d3f3bd and
9436271a04.
The reason is that users have chimed in with legitimate use cases,
especially extracting text subtitles on Windows, modifying them and
re-muxing them later. This worked out of the box before but requires
setting the subtitle character set to UTF-8 upon re-muxing now.
Part of an ongoing effort to replace the use of the term 'timecode' with
'timestamp'. Timecodes have a very specific meaning in the audio/video
world, and it's not what MKVToolNix has been using the term for.
Part of an ongoing effort to replace the use of the term 'timecode' with
'timestamp'. Timecodes have a very specific meaning in the audio/video
world, and it's not what MKVToolNix has been using the term for.
