Often one has to skip bits in between reading several header
fields. This can make code tedious to read. For example:
auto field1 = reader.get_bits(4);
reader.skip_bits(2);
auto field2 = reader.get_bits(3);
if (field2 == 7)
reader.skip_bits(16);
auto field3 = reader.get_bits(8);
With this combined function it becomes clearer:
auto field1 = reader.skip_get_bits(0, 4);
auto field2 = reader.skip_get_bits(2, 3);
auto field3 = reader.skip_get_bits(field2 == 7 ? 16 : 0, 8);
The SEI user data is stored in m_user_data, and from there it's
re-created during HEVCC creation. Therefore keeping SEI NALUs in
m_extra_data, too, only duplicates them.
Idea/patch by Vladimír Pilný.
See also #1076 where this had been mentioned in the past, too.
All NALUs must be converted to RBSP before they're parsed. Otherwise the
wrong values will be used resulting in e.g. wrong picture order and
therefore in wrong timestamps.
Similar to the h.264 problems reported in #918 and #1548.
All NALUs must be converted to RBSP before they're parsed. Otherwise the
wrong values will be used resulting in e.g. wrong picture order and
therefore in wrong timestamps.
Fixes#918 and #1548.
The current MP4 specs (ISO/IEC 14496-15:2015) say that open GOP random
access points aren't normal sync entries anymore. Therefore such frames
aren't present in the normal key frame table anymore. Instead sample
grouping information of type "rap " (random access point) is used for
signalling that decoding can start from those frames, too.
Fixes#1543.
The last frame of a track doesn't need a duration if its rounded
duration equals the rounded default duration. On the other hand the last
frame must not be put into an existing lace if those durations are
different.
Fixes#1545.
The function Util::setToolTip() HTML-escapes the tool tip if it doesn't
start with a <. Otherwise it assumes the caller has taken care of
escaping. So far not all callers did, though; some were inserting
non-escaped translated strings into formatting strings like
"<p>%1</p><p>%2</p>" resulting in invalid HTML and cut-off tool tips
during display.
When appending m_last_timecode is already offset by
m_first_timecode. Therefore subtracting it once more during the progress
calculation will result in negative numbers if m_first_timecode is
non-zero – which is the case when appending files created by splitting
with linking enabled, for example.
This was a regression introduced in c494170. In that commit a check was
introduced to determine whether or not the file had actually to be
modified. This check was wrong for replacing tags.
