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").
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.
Fixed the behaviour of how mmg sets the output file name automatically
if the option is enabled. If the user adds more than one file then the
extension of the output file name is set each time a file is added and
not only when the first one is. The full file name and path will only
be set when the first file is added.
Fix for bug 391.
Patch by Todd Schmuland (see AUTHORS).
His explanation:
I was muxing a DVD and mkvmerge complained about losing sync while
parsing the vob. I checked to see what was happening and discovered
the length of a 00 00 01 BE padding packet was way too long. This
resulted in several packets being skipped over and therefore caused a
gap in the resulting mkv. I've seen this before where the packet
length specified in a 00 00 01 BE padding packet is incorrect.
I've made adjustments to the r_mpeg_ps.cpp code to detect when 00 00
01 BE padding packets have the wrong length specified. Padding
packets should always fill the gap to the next 2048 (800 hex) page in
the file. Now the code will detect lengths that are way too long, or
lengths that are just under or just over what they should be, and
correct it.
I also changed it so that with one -v switch, you won't get 100s of
mpeg_ps: parse_packet failed messages anymore. Adjusted padding
packet lengths will be indicated with one -v switch, but now good 00
00 01 BE padding stream packets and 00 00 01 BF private 2 stream
packets won't be output as failing anymore.
I was finally able to get a good mkv mux of the DVD with the attached
r_mpeg_ps.cpp file.
I just did another DVD and it had a similar bad padding stream packet.
Packet length in vob was 44036 but should only be 1918. The new
r_mpeg_ps detected and corrected it, whereas the old code would have
skipped (44036-1918)/2048 = ~21 good packets of video/audio.
Fix for bug 245. Patch by Todd Schmuland (see AUTHORS).
Explanation from Todd:
I tried using mkvextract to get VobSub tracks out of a mkv to make sure I
muxed in the correct subtitle stream. What I noticed is that programs like
Subtitle Creator and VobSubStrip would error out on one particular sub file.
After looking into it, the issue is in how mkvextract handles padding
lengths of 1 to 7.
There are two methods, the one mkvextract currently uses is to use the 00 00
01 BA packet where the 3 least significant bits of the last header byte
indicate how many padding FF bytes follow. There's nothing wrong with this,
however, many programs don't decode this properly and error out since they
are expecting the next bytes to be 00 00 01.
The other method is to pad the 00 00 01 BD packet header with FF bytes and
simply increase the header length byte to include the pad count. For
example where padding = 5:
method 1
00 00 01 BA 44 32 4C 46 44 01 01 89 C3 FD FF FF FF FF FF
00 00 01 BD 07 E7 81 80 05 21 0C 93 11 91 <payload>
becomes
method 2
00 00 01 BA 44 32 4C 46 44 01 01 89 C3 F8
00 00 01 BD 07 EC 81 80 0A 21 0C 93 11 91 FF FF FF FF FF <payload>
Notice the 00 00 01 BD total packet length increased from 07E7 to 07EC and
the packet header length increased from 05 to 0A. The benefit of this is
that the 00 00 01 BD header length includes the pad length with no
additional work by a program's decoder, so the SUB file is always properly
parsed while decoding. In fact the DVD this particular VobSub came from
used method 2.
Some Windows installation use code pages as its ANSI code page
that are not supported by the iconv library (e.g. code page 720).
These have to be converted using Windows' own MultiByteToWideChar
and WideCharToMultiByte functions.
Fix for bug 376.
generic_packetizer_c::set_headers() must not be called for appended
files. If it is not called then track_entry is NULL before
generic_packetizer_c::connect() is called. Therefore appended files
must not use track_entry; calls to generic_packetizer_c::set_headers()
hint at wrong usage.
There are often off-by-one cases in which the SPU length field is larger
than the actual packet. Most playback applications ignore that error
when reading external VobSub files but skip the whole packet if it comes
from a Matroska file.
Fix for bug 383.
The last packet was not read because off an off-by-one error:
for the last packet the reader was accessing after the end of
the vector resulting in a file position member of 0.
Patch by Todd Schmuland.
The code now requires five consecutive identical AAC headers
instead of just two arbitrary headers. This fixes mis-detection
issues, e.g. those of bugs 373 and 374.
Subtitle and button tracks must preserve their duration even
if an external timecode file is used. Otherwise each subtitle
frame's duration is set to the difference between the next
frame's timecode and the current frame's timecode.
Fix for bug 286.
1. The list of predefined aspect ratios has been extended by three entries (sync with ffmpeg).
2. mkvmerge only tries to read free aspect ratio information if the aspect ratio type indicates it by being 0xff.
If the bit_cursor_c throws an exception in the middle of
reading the timestamp then the "timestamp" variable used
to return the timestamp must not have been modified yet.
Fix for bug 337.
This allows the user to change the charset with --output-charset.
Before chapters were not converted at all resulting in UTF-8 output
on every system, and --output-charset had no effect on it.
This does not affect the output of XML style chapter files.
Fix for bug 359.
QuickTime audio tracks will be stored with the CodecID "A_QUICKTIME".
The CodecPrivate element contains the full "STSD" element from the QuickTime file
(just like V_QUICKTIME). This method is used for all audio tracks which
don't have a well-defined storage spec for Matroska (e.g. AAC, AC3,
MP2/3 are still stored as A_AC3, A_AAC etc). Hopefully a fix for bugs 354 and 357.
For locales for which mkvtoolnix does not contain a translation
(e.g. fr_FR, en_AU etc) mkvtoolnix should not abort with an
error message. mmg must not chose such a locale as the parameter
for --ui-language. Fix for bug 338.
The action "remove all files" must also clear the list of attached files.
The action "File" -> "New" must clear the internal list of attached files
as well as the GUI component.
On Linux wxWidgets 2.8.0 and newer uses the GTK combo boxes which suck. A lot.
Therefore mmg uses wxBitmapComboBoxes for wxWidgets >= 2.8.0 on Linux and normal
wxComboBoxes in all other cases. wxBitmapComboBoxes are still drawn by wxWidgets
itself (just like wxComboBoxes before 2.8.0) and offer much better functionality.
Fix for bug 339.
Added controls on the "attachments" page so that the user can
select which existing attached files he wants copied into the
output file. Removed the checkbox for "no attachments" from the
"input" page.
AAC data which does not start on the first byte was not detected
properly. The reason is that the AAC scanning code did not take
the start offset into account. Also the AAC reader class treated
the offset to the first header being != 0 as an error.
The chapter editor does not assign an item data element to the root
element. Therefore the function should check if said item data element
is NULL before using it causing a crash otherwise.
Huge timecodes were output in scientific notation because floating
point numbers were used. Now mkvextract creates the decimal and fractional
parts of the output itself so that the scientific notation will not be used.
If subtitle files are appended to separate video files
(e.g. two AVI and two SRT files) then the subtitle timecodes of
the second and all following subtitle files were based on the last
timecode in the first subtitle file instead of the last timecode in
the first video file. Fix for bug 325.
This bug was introduced in c68a6dfc27
