There's really no need to use the generic parent type. Using the
template argument's type instead allows one to wrap the result into
shared pointers as in e.g.
KaxAttachedPtr
createAttachment() {
// …
return {
mtx::construct::cons<KaxAttached>(new KaxFile, …)
};
}
The old logic was so complex (even within parse_start_unit_packet()
there were two or three places were data was sent to the packetizer)
that it had to be simplified a lot. The new logic knows only three
cases:
1. When parsing a normal packet then data is sent to the packetizer if
and only if the expected PES size is known (!= 0) and the accumulated
PES data's size equals the expected PES size.
2. When parsing a "start unit" packet then there are two cases:
2.a. If the previous unit's expected PES size is unknown ( == 0) then
all data gathered so far is sent to the packetizer.
2.b. Otherwise (the expected PES size is known) the packet must be too
short or too large. Otherwise it would have been sent to the
packetizer in case 1. already.
On top the packet's data is cleared in both "send_to_packetizer()" and
in "probe_packet_complete()", the two functions that handle complete
packets in the muxing phase ("send_to_packetizer()") respectively
probing phase ("probe_packet_complete()").
Fixes#1553.
Instead make determination based on number of slice start codes
found. Also move the MPEG ES probing further down to the other ES video
types (AVC, HEVC) as all of those tend to produce a lot of false
positives.
Fixes#1462.
An edit list with two entries where the first entry's media time is -1
means that a fixed offset must be applied to the timestamps. This is
independent of the segment_duration value of the second edit list entry.
Fixes#1547.
This regression was introduced in aeb0add.
The new menu is created during the tab's constructor. At that point it
called "isCurrentJobTab()" do determine whether or not to add the "clear
outputs" action. However, "isCurrentJobTab()" relied on the MainWindow's
currentJobTab variable being set, which at that point isn't yet as the
tab is still being constructed.
Solve this by passing a static parameter to the tabs that indicate
whether or not they're the "current job" tab.
This optional menu contains the same "add files", "append files", "add
files as additional parts" actions that are also present in the
right-click context menu. However, due to an arrow being painted on the
button this should be easier to discover for new or inexperienced users.
mm_mem_io_c allocates a buffer. Calling get_and_lock_buffer() on it will
return the buffer and disassociate it from mm_mem_io_c, meaning the
mm_mem_io_c instance won't free it itself. Then cloning from this
already disassociated buffer is a superfluous memory copy for one and it
fails to free the buffer causing a massive memory leak.
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.
