MP4 files with chapters may contain non-UTF-8 encoded
strings. Processing those strings as UTF-8 may cause mkvmerge to abort
with a message abort invalid UTF-8 sequences.
This is bad in identification mode because here the actual chapter
names are not needed, only the number of entries.
Fix for bug 408.
The device number has precendence over the inode number. Therefore the
inode numbers must only be compared if the device numbers are equal.
This resulted in some strange cases in which the std::map<> object for
which file_id_t structures were used as keys was removing/inserting
the wrong elements. This caused crashes in rare cases, e.g. for access
to files on VFAT formatted file systems because the device numbers
were higher than ones for ext3 or devfs (think "/dev/urandom").
Some AVC/h.264 tracks do not seem to contain NALUs marked as being IDR
NALUs. Therefore mkvmerge wasn not considering I slices contained in
those NALUs for key frames. This code adds a --debug option for a
workaround for such files.
The old option --no-tags" was replaced with the new options
"--no-global-tags" which causes global tags not to be copied and
"--no-track-tags" which causes track specific tags to not be
copied. The new option "--track-tags" can be used to select tracks for
which tags will be copied. The default is still to copy all existing
tags.
This was removed in a3edc83512 in a fix
to not remove the sequence headers from the bitstream. However,
putting the first sequence header into CodecPrivate while still not
removing the sequence headers from the bitstream improves
compatibility with some existing parsers (MediaPlayer Classic
HomeCinema).
If the source file contains the same timecode for consecutive packets
then mkvmerge will extrapolate timecodes for all but the first packets
in the sequence.
Fix for bug 403.
The problem was that the search position was not reset for each potential
packet size. Therefore other packet sizes always only found one hit for
the TS start code.
Fix for bug 393.
Explanation by Todd Schmuland:
I looked at his mpeg file and my assumption of packets always being on
a page boundary was incorrect. His mpeg isn't perfect (each specified
audio packet length is 16 bytes short of what it really is, hence all
the lost sync messages), but the parser is capable of dealing with it.
So I have to remove the erroneous page boundary limitation.
Attached is the fixed r_mpeg_ps.cpp. The new behavior now is thus.
Whenever a pad packet is encountered, the code now skips forward the
packet length specified and checks to see if the next header is there.
If it is then great, if not then it searches for the next header and
calculates the correct pad packet length. This removes the page
boundary limitation. I tested it on Transformers and it works well.
I also tested it against his mpeg and it works as well.
