If you’ve installed the RPM that enables the yum repository for MKVToolNix then you might get hit by the following message when yum tries to access the repository:
http://www.bunkus.org/videotools/mkvtoolnix/fedora/13/x86_64/repodata/primary.xml.gz: [Errno -1] Metadata file does not match checksum
Trying other mirror.
http://www.bunkus.org/videotools/mkvtoolnix/fedora/13/x86_64/repodata/primary.xml.gz: [Errno 14] Downloaded more than max size for http://www.bunkus.org/videotools/mkvtoolnix/fedora/13/x86_64/repodata/primary.xml.gz: 2805 > 2451
Trying other mirror.
This is caused by the meta data cache not being up to date. You can manually fix this by running “sudo yum makecache“. A better approach is to make yum update its meta data for the bunkus.org repository itself after a couple of days. For this to work simply update the bunkus.org repository RPM package by running the following command:
sudo rpm -i http://www.bunkus.org/videotools/mkvtoolnix/fedora/bunkus-org-repo-1-2.noarch.rpm
Regular users of the #matroska IRC channel on irc.corecodec.org have known for quite some time that the service offered by irc.corecodec.org wasn’t as stable and fast as they’d liked. The server has been down a couple of times or the connections unstable for days on end. Therefore the Matroska team decided that they move their channel over to the Freenode network. Freenode offers Free and OpenSource projects a stable and scalable home with the usual IRC services like channel and nick registration (ChanServ and NickServ respectively).
So join us in our new home: #matroska on Freenode.
I’ve released mkvtoolnix v4.2.0. It contains a lot of bug fixes and a few enhancements but no major new features.
There are no changes for package maintainers in this release.
Here are the usual links: the home page, the source code and the Windows installer and 7zip archive.
All binaries that I provide myself have already been uploaded.
Here’s the full ChangeLog since release 4.1.1:
- 2010-07-28 Moritz Bunkus <moritz@bunkus.org>
- Released v4.2.0.
- mkvmerge: bug fix: mkvmerge was accessing invalid memory In certain cases, e.g. when appending Matroska files that use compression while turning compression off.
- 2010-07-27 Moritz Bunkus <moritz@bunkus.org>
- mkvmerge: bug fix: Splitting output files by size was basing its decision when to create a new file on an uninitialized variable. This caused effects like a lot of small files being created with sizes much smaller than the intended split size.
- 2010-07-19 Moritz Bunkus <moritz@bunkus.org>
- mkvmerge: bug fix: The speed with which mkvmerge skips garbage in DTS tracks has been greatly improved.
- 2010-07-18 Moritz Bunkus <moritz@bunkus.org>
- mkvmerge: enhancement: Reading Matroska files: DisplayWidth & DisplayHeight values that are obviously not meant to represent pixels but only to be used for aspect ratio calculation (e.g. 16×9) are converted into proper ranges based on the track’s PixelWidth & PixelHeight values and the quotient of DisplayWidth / DisplayHeight.
- 2010-07-12 Moritz Bunkus <moritz@bunkus.org>
- mkvmerge: enhancement: Attachments will be rendered at the end of the file instead of at the beginning. The attachments will be placed after the cues but before the chapters. Fix for bug 516.
- mkvmerge: enhancement: Header removal compression has been enabled by default for MPEG-4 part 10 (AVC/h.264) video tracks with a NALU size field length of four bytes.
- mkvmerge: bug fix: Header removal compression has been deactivated for MPEG-4 part 2 (aka DivX/Xvid) video tracks due to incompatibility with packed bitstreams.
- 2010-07-10 Moritz Bunkus <moritz@bunkus.org>
- mmg: enhancement: The taskbar progress is reset as soon as mkvmerge finishes/as soon as all jobs are done (Windows 7).
- 2010-07-06 Moritz Bunkus <moritz@bunkus.org>
- mkvmerge: bug fix: Fixed reading AVC/h.264 tracks from AVI files if they’re stored without NALUs inside the AVI. Was broken by a fix for handling AVC/h.264 in NALUs inside AVI.
- mkvmerge: bug fix: All readers that only handled file formats which do not contain more than one track did not respect the “–no-audio / –no-video / –no-subtitles” options. This applied to the following readers: AAC, AC3, AVC/h.264, CorePicture, Dirac, DTS, FLAC, IVF, MP3, MPEG ES, PGS/SUP, SRT, SSA, TrueHD, TTA, VC1, WAV and WavPack.
- 2010-07-05 Moritz Bunkus <moritz@bunkus.org>
- mkvmerge: enhancement: Improved reading text files that use mixed end-of-line styles (DOS & Unix mixed).
- 2010-07-04 Moritz Bunkus <moritz@bunkus.org>
- mkvmerge: bug fix: Fixed invalid memory access in the PCM packetizer. Fix for bug 510.
- mmg: bug fix: When mmg starts it will check the entries in the file and chapter menu’s list of recently used files and remove those entries that no longer exist. Fix for bug 509.
- mkvmerge: bug fix: Fixed a crash when reading Matroska files that were damaged in a certain way.
Have fun.
Today Google announced something that’s great on many levels: for the OpenSource community in general, for Matroska in particular, even for every internet user. First they’re open-sourcing the VP8 video codec they’ve acquired recently as part of the WebM project. VP8 is said to achieve similar encoding efficiency as the AVC/h.264 video codec while keeping quality on a comparable level. Not only are they open-sourcing it, they’re also making sure that you can use it any way you want without ever having to pay royalties or acquire licenses. It’s free in each and every sense of the word.
Second they’ve chosen Matroska format as the basis for the WebM file format as the native container for VP8 video tracks. WebM files are nothing but a stricter version of the Matroska container with fewer features and a fixed set of codecs — VP8 as the video codec and the well-known OpenSource audio codec Vorbis. Google and On2, creators of VP8, have worked behind the scenes with the Matroska developers (myself included) in order to create a specification that is easy to implement for everyone. The goal is to create a free standard for movie content that’s as easy to use for end-users as JPEGs or PNGs are when it comes to pictures. That’s where the limitations come from.
What’s even better is that Google has worked with the teams behind the web browsers Chrome/Chromium, Firefox and Opera. All three teams stand firmly behind the new format and have already integrated playback capabilities into preview versions of their respective browsers. As for content Google has started streaming Web Media files on YouTube with its HTML5 interface.
In a future post I’ll dive deeper into the technical differences between Matroska and WebM files. Suffice to say for now that they’re so few that adjusting existing playback software so that they can play Web Media files is done in a few hours tops. I’ve already created a build of MKVToolNix that supports Web Media files — both as input files and as output files (source code only for now for Linux/Mac/BSD users). If you want to create a Web Media file either add the command line parameter “--webm” anywhere or simply use “.webm” as the file name’s extension of your output file.

