From fabian at greffrath.com Tue Jun 1 15:45:09 2010 From: fabian at greffrath.com (Fabian Greffrath) Date: Tue, 01 Jun 2010 15:45:09 +0200 Subject: [Matroska-devel] Incompatible API changes between libebml 0.7.7 and 0.8.1? Message-ID: <4C050EE5.5020502@greffrath.com> Dear libebml developers, the Debian pkg-multimedia team recently attempted to upgrade libebml in Debian from version 0.7.7 to 0.8.1. However, while checking in the new version into our GIT repository, we noticed many changes to the exported header files that seemed incompatible with the previous version. Please see the discussion that started here: http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/2010-May/009824.html It does not seem 0.8.1 was meant as a drop-in replacement for 0.7.7, right? However, the library SONAME version has not been raised and is still kept at 0 (i.e. pretending binary compatiblity with the previous library version). Since we are reluctant to deviate from your source and possibly other distributions by forcefully raising the library SONAME on our own, we'd like to discuss this issue with you a priori. This issue is currently a bit critical for us, because Debian is approaching the library freeze for its upcoming stable release Squeeze. Best regards, - Fabian From moritz at bunkus.org Tue Jun 1 16:32:37 2010 From: moritz at bunkus.org (Moritz Bunkus) Date: Tue, 1 Jun 2010 16:32:37 +0200 Subject: [Matroska-devel] Incompatible API changes between libebml 0.7.7 and 0.8.1? In-Reply-To: <4C050EE5.5020502@greffrath.com> References: <4C050EE5.5020502@greffrath.com> Message-ID: <201006011632.38129.moritz@bunkus.org> Hey, On Tuesday 01 June 2010 15:45:09 Fabian Greffrath wrote: > It does not seem 0.8.1 was meant as a drop-in replacement for 0.7.7, > right? That's correct. There was a short discussion about it on this mailing list a couple of days ago: http://lists.matroska.org/pipermail/matroska-devel/2010-May/003656.html So here's our current status. The next release of libebml and libmatroska will feature yet more changes that are most likely API incompatible. So I'd like to get this working right. Unfortunately I'm pretty much the only Linux developer working on the libs and having at least some knowledge about Linux build systems. However, so far I've only used libebml and libmatroska statically. My own binary packages all use statically linked versions of the two. I'm simply not confident that I can modify our very rudimentary build system properly on short notice. I'd really like to have a proper solution though -- even if it involves autoconf/automake. Those changes should ideally be integrated into the next release of libebml/libmatroska. So basically I'm asking you guys if you could provide such a solution. I'd be more than happy to integrate it and release a new version afterwards. The version numbers could simply be raised to 1.0.0 for both libs in order to make the API changes more obvious as well. > This issue is currently a bit critical for us, because Debian is > approaching the library freeze for its upcoming stable release > Squeeze. What's the time frame we're talking about here? Regards, Mosu -- If Darl McBride was in charge, he'd probably make marriage unconstitutional too, since clearly it de-emphasizes the commercial nature of normal human interaction, and probably is a major impediment to the commercial growth of prostitution. - Linus Torvalds From moritz at bunkus.org Tue Jun 1 16:35:32 2010 From: moritz at bunkus.org (Moritz Bunkus) Date: Tue, 1 Jun 2010 16:35:32 +0200 Subject: [Matroska-devel] Incompatible API changes between libebml 0.7.7 and 0.8.1? Message-ID: <201006011635.33347.moritz@bunkus.org> Hey, oops, forgot to CC Fabian on my first reply. So here it is again. On Tuesday 01 June 2010 15:45:09 Fabian Greffrath wrote: > It does not seem 0.8.1 was meant as a drop-in replacement for 0.7.7, > right? That's correct. There was a short discussion about it on this mailing list a couple of days ago: http://lists.matroska.org/pipermail/matroska-devel/2010-May/003656.html So here's our current status. The next release of libebml and libmatroska will feature yet more changes that are most likely API incompatible. So I'd like to get this working right. Unfortunately I'm pretty much the only Linux developer working on the libs and having at least some knowledge about Linux build systems. However, so far I've only used libebml and libmatroska statically. My own binary packages all use statically linked versions of the two. I'm simply not confident that I can modify our very rudimentary build system properly on short notice. I'd really like to have a proper solution though -- even if it involves autoconf/automake. Those changes should ideally be integrated into the next release of libebml/libmatroska. So basically I'm asking you guys (both the Debian developers and Christian Morales Vega who first brought the issue to our attention) if you could provide such a solution. I'd be more than happy to integrate it and release a new version afterwards. The version numbers could simply be raised to 1.0.0 for both libs in order to make the API changes more obvious as well. > This issue is currently a bit critical for us, because Debian is > approaching the library freeze for its upcoming stable release > Squeeze. What's the time frame we're talking about here? Regards, Mosu -- If Darl McBride was in charge, he'd probably make marriage unconstitutional too, since clearly it de-emphasizes the commercial nature of normal human interaction, and probably is a major impediment to the commercial growth of prostitution. - Linus Torvalds From fabian at greffrath.com Tue Jun 1 17:05:00 2010 From: fabian at greffrath.com (Fabian Greffrath) Date: Tue, 01 Jun 2010 17:05:00 +0200 Subject: [Matroska-devel] Incompatible API changes between libebml 0.7.7 and 0.8.1? In-Reply-To: <201006011635.33347.moritz@bunkus.org> References: <201006011635.33347.moritz@bunkus.org> Message-ID: <4C05219C.30504@greffrath.com> Am 01.06.2010 16:35, schrieb Moritz Bunkus: > That's correct. There was a short discussion about it on this mailing > list a couple of days ago: OK, thanks for clarifying this. > So basically I'm asking you guys (both the Debian developers and > Christian Morales Vega who first brought the issue to our attention) if > you could provide such a solution. I'd be more than happy to integrate > it and release a new version afterwards. The version numbers could > simply be raised to 1.0.0 for both libs in order to make the API changes > more obvious as well. AFAICT from a quick look at the sources it should be sufficient (for now) to simply bump the value of the LIBRARY_SO_VER variable in make/linux/Makefile each time you introduce incompatible API. But I am not an expert on this, either. > What's the time frame we're talking about here? Yesterday. ;) But I believe a drop-in replacement for an already existing library would have been waved through after consultation with the release team. As this is impossible with the new release anyway, out time frame is rather relaxed now. ;) Cheers, Fabian From cmorve69 at yahoo.es Tue Jun 1 17:07:56 2010 From: cmorve69 at yahoo.es (Cristian Morales Vega) Date: Tue, 1 Jun 2010 17:07:56 +0200 Subject: [Matroska-devel] Incompatible API changes between libebml 0.7.7 and 0.8.1? In-Reply-To: <201006011635.33347.moritz@bunkus.org> References: <201006011635.33347.moritz@bunkus.org> Message-ID: 2010/6/1 Moritz Bunkus : > So basically I'm asking you guys (both the Debian developers and > Christian Morales Vega who first brought the issue to our attention) if > you could provide such a solution. I'd be more than happy to integrate > it and release a new version afterwards. The version numbers could > simply be raised to 1.0.0 for both libs in order to make the API changes > more obvious as well. The fix depends on your future plans. If what happened with these two releases is something exceptional we can just raise the soname. But if the API/ABI is going to change with every release we should usa a "libebml-.so" soname that makes clear that fact. So, is libebml/matroska a library that tries to maintain API/ABI compatibility? From jean.mons at free.fr Wed Jun 2 01:16:20 2010 From: jean.mons at free.fr (Jean Mons) Date: Tue, 1 Jun 2010 19:16:20 -0400 Subject: [Matroska-devel] Bug Report in the latest versions of Haali Media Splitter Message-ID: I happen to use in the videos I watch a lot of different subtitles (each in one given language), which I mux with the video / audio stream with MKV Merge GUI from Moritz Bunkus. I am using a PC with Vista x64 US English. The software I use to watch this video files (with a Matroska container) is MPC Home Cinema x64 on the x64 PC and x86 on the other. I installed as well CoreAVC Video Codec which offered until the version 1.9.5 to install the Haali media Splitter. In this case the version of the splitter is 1.9.42.1. (I don't know the date of this release). Using any version of MPC Home Cinema with this version of the Haali Media Splitter worked well until I stumbled last November on a bug which prevented access [Menu Play --> Subtitles of MPC] to all subtitles except the first one appearing in the list of MKV Merge GUI i.e. Menu --> Subtitles list only the first one. I discovered at that time that this occurred only after installing MPC-HC v1.3.1249 with the installer .exe available for this release [I used it to update my previously [and working] installed version v1.2.908 on my second computer XP/Vista dual boot]. On another computer [Vista x64] I installed myself the executable in the Program Files folder to perform the update and everything went fine. I didn't see the previously mentioned bug appearing. I didn't have immediately an answer for this kind of behaviour. I initialy thought that something went wrong in the muxing proces with MKV Merge GUI. It was not. Recently, in early April I installed a newer version of the splitter found at http://haali.su/mkv . It was the version identified as of date 27/03/2010. Following this, the computer running Vista x64 did show the same bug as the other computer : No access to the list of subtitles but the first one of the list. I uninstalled the Haali Media Splitter and re-installed the version 1.9.42.1 (packed with the installer of CoreAVC Codec 1.9.5) and things were back to normal. I could again see all the subtitles. Although if you just re-install the working version 1.9.42.1 without un-installing any bugged version it will not work either. You need to properly un-install a bugged version with its own un-installer, and later install the 1.9.42.1. I tested the newly released version of the splitter dated 20/05/2010 yesterday and it carries the same bug as well. Can anyone confirm this behaviour of the Haaili Media Splitter ? And can anyone involved in the splitter development have a look at this ? I uploaded in early May a 100 MB chunk of the movie Mean.Girls.2004.1080p.BluRay.x264-CiNEFiLE.mkv containing 5 subtitles : English from other languages, English, French, Spanish et Portuguese. Mean.Girls.2004.1080p.BluRay.x264-CiNEFiLE_newsub-001.mkv http://www.mediafire.com/download.php?odt0wnjwtvo Another annoying thing in Windows is that below the Play, Pause & Stop Button, instead of having the Matroska icon from the Haali splitter, I have a music icon from Windows Media Player DLL (from file %system%System32\wmploc.dll). It may come from a mess in windows registry but it's quite annoying. Re-installing the splitter didn't solve this problem. Is there a way to get around this ? and display the Matroska icon from the splitter ? Tank you for your feedback. -------------- next part -------------- An HTML attachment was scrubbed... URL: From slhomme at matroska.org Thu Jun 3 11:31:44 2010 From: slhomme at matroska.org (Steve Lhomme) Date: Thu, 3 Jun 2010 11:31:44 +0200 Subject: [Matroska-devel] Incompatible API changes between libebml 0.7.7 and 0.8.1? In-Reply-To: References: <201006011635.33347.moritz@bunkus.org> Message-ID: On Tue, Jun 1, 2010 at 5:07 PM, Cristian Morales Vega wrote: > 2010/6/1 Moritz Bunkus : > > So basically I'm asking you guys (both the Debian developers and > > Christian Morales Vega who first brought the issue to our attention) if > > you could provide such a solution. I'd be more than happy to integrate > > it and release a new version afterwards. The version numbers could > > simply be raised to 1.0.0 for both libs in order to make the API changes > > more obvious as well. > > The fix depends on your future plans. If what happened with these two > releases is something exceptional we can just raise the soname. But if > the API/ABI is going to change with every release we should usa a > "libebml-.so" soname that makes clear that fact. > > So, is libebml/matroska a library that tries to maintain API/ABI > compatibility? > Because of the way C++ libraries works, I'd say no. The API is backward compatible, but not the dynamic ABI (static linking is always fine). -------------- next part -------------- An HTML attachment was scrubbed... URL: From joemobil at gmail.com Thu Jun 3 12:47:32 2010 From: joemobil at gmail.com (Joe (Mobile)) Date: Thu, 3 Jun 2010 12:47:32 +0200 Subject: [Matroska-devel] Status of the menu support and Matrosky 2.0 Message-ID: Hello, As it has been silent on the topic of menus for another year, I cannot help but ask: What is the current status of the menu support in MKV? Unfortunately there never has been a concrete answer to that before, so I hope that I might get some answers here at the center of development. I sometimes read that Matroska 2.0 will address the issue of menus, but also on this front it has been strangely silent for a long time. So how is the status of Matroska 2.0 now? Since Google with webm is now kinda using Matroska, it might be the perfect moment to upgrade to a new specification level. Thanks for any answers in advance, Joe -------------- next part -------------- An HTML attachment was scrubbed... URL: From slhomme at matroska.org Thu Jun 3 13:08:59 2010 From: slhomme at matroska.org (Steve Lhomme) Date: Thu, 3 Jun 2010 13:08:59 +0200 Subject: [Matroska-devel] Status of the menu support and Matrosky 2.0 In-Reply-To: References: Message-ID: There are no current plans to improve the menu system as it exists now. It may happen someday but for now nobody is planning to work on it. On Thu, Jun 3, 2010 at 12:47 PM, Joe (Mobile) wrote: > Hello, > > As it has been silent on the topic of menus for another year, I cannot help > but ask: What is the current status of the menu support in MKV? > > Unfortunately there never has been a concrete answer to that before, so I > hope that I might get some answers here at the center of development. I > sometimes read that Matroska 2.0 will address the issue of menus, but also > on this front it has been strangely silent for a long time. So how is the > status of Matroska 2.0 now? Since Google with webm is now kinda using > Matroska, it might be the perfect moment to upgrade to a new specification > level. > > Thanks for any answers in advance, > Joe > > _______________________________________________ > Matroska-devel mailing list > Matroska-devel at lists.matroska.org > http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel > Read Matroska-Devel on GMane: > http://dir.gmane.org/gmane.comp.multimedia.matroska.devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cmorve69 at yahoo.es Thu Jun 3 15:30:30 2010 From: cmorve69 at yahoo.es (Cristian Morales Vega) Date: Thu, 3 Jun 2010 15:30:30 +0200 Subject: [Matroska-devel] Incompatible API changes between libebml 0.7.7 and 0.8.1? In-Reply-To: References: <201006011635.33347.moritz@bunkus.org> Message-ID: 2010/6/3 Steve Lhomme : > On Tue, Jun 1, 2010 at 5:07 PM, Cristian Morales Vega > wrote: >> >> 2010/6/1 Moritz Bunkus : >> > So basically I'm asking you guys (both the Debian developers and >> > Christian Morales Vega who first brought the issue to our attention) if >> > you could provide such a solution. I'd be more than happy to integrate >> > it and release a new version afterwards. The version numbers could >> > simply be raised to 1.0.0 for both libs in order to make the API changes >> > more obvious as well. >> >> The fix depends on your future plans. If what happened with these two >> releases is something exceptional we can just raise the soname. But if >> the API/ABI is going to change with every release we should usa a >> "libebml-.so" soname that makes clear that fact. >> >> So, is libebml/matroska a library that tries to maintain API/ABI >> compatibility? > > Because of the way C++ libraries works, I'd say no. The API is backward > compatible, but not the dynamic ABI (static linking is always fine). What do you mean with "the way C++ libraries works"? I'm more of a C dev than a C++ one, but there are multiple examples of C++ libraries that have commited to an stable ABI/backwards binary compatibility for a long time. Qt and KDE are the obvious examples, add all those C++ wrappers of C libraries (gtkmm, libMagick++, ...) and a lot more. From slhomme at matroska.org Thu Jun 3 16:38:56 2010 From: slhomme at matroska.org (Steve Lhomme) Date: Thu, 3 Jun 2010 16:38:56 +0200 Subject: [Matroska-devel] Incompatible API changes between libebml 0.7.7 and 0.8.1? In-Reply-To: References: <201006011635.33347.moritz@bunkus.org> Message-ID: I don't know how they achieve that. Do they have to add the new methods at the bottom of the class definition ? If not, what constitutes an ABI incompatibility ? We have changed some input/ouput types but they are the same size as they used to be. Removed some const on integers (should have no impact on the ABI either) and I don't think we changed any parameter '&' referencing. On Thu, Jun 3, 2010 at 3:30 PM, Cristian Morales Vega wrote: > 2010/6/3 Steve Lhomme : > > On Tue, Jun 1, 2010 at 5:07 PM, Cristian Morales Vega > > > wrote: > >> > >> 2010/6/1 Moritz Bunkus : > >> > So basically I'm asking you guys (both the Debian developers and > >> > Christian Morales Vega who first brought the issue to our attention) > if > >> > you could provide such a solution. I'd be more than happy to integrate > >> > it and release a new version afterwards. The version numbers could > >> > simply be raised to 1.0.0 for both libs in order to make the API > changes > >> > more obvious as well. > >> > >> The fix depends on your future plans. If what happened with these two > >> releases is something exceptional we can just raise the soname. But if > >> the API/ABI is going to change with every release we should usa a > >> "libebml-.so" soname that makes clear that fact. > >> > >> So, is libebml/matroska a library that tries to maintain API/ABI > >> compatibility? > > > > Because of the way C++ libraries works, I'd say no. The API is backward > > compatible, but not the dynamic ABI (static linking is always fine). > > What do you mean with "the way C++ libraries works"? I'm more of a C > dev than a C++ one, but there are multiple examples of C++ libraries > that have commited to an stable ABI/backwards binary compatibility for > a long time. Qt and KDE are the obvious examples, add all those C++ > wrappers of C libraries (gtkmm, libMagick++, ...) and a lot more. > _______________________________________________ > Matroska-devel mailing list > Matroska-devel at lists.matroska.org > http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel > Read Matroska-Devel on GMane: > http://dir.gmane.org/gmane.comp.multimedia.matroska.devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pkoshevoy at sorensonmedia.com Thu Jun 3 17:10:50 2010 From: pkoshevoy at sorensonmedia.com (Pavel Koshevoy) Date: Thu, 03 Jun 2010 09:10:50 -0600 Subject: [Matroska-devel] Incompatible API changes between libebml 0.7.7 and 0.8.1? In-Reply-To: References: <201006011635.33347.moritz@bunkus.org> Message-ID: <4C07C5FA.4080805@sorensonmedia.com> On 6/3/2010 8:38 AM, Steve Lhomme wrote: > I don't know how they achieve that. Do they have to add the new methods > at the bottom of the class definition ? If not, what constitutes an ABI > incompatibility ? Basically, to maintain ABI you (1) can't add/change virtual function signatures or (2) add/change datamembers, and use a PIMPL to hide datamembers (http://en.wikipedia.org/wiki/Pimpl) There is a full list of do's/don't's here: http://techbase.kde.org/Policies/Binary_Compatibility_Issues_With_C++ (use google cache if kde.org doesn't respond) And some thoughts on the subject by Thiago Maciera: http://labs.trolltech.com/blogs/2009/08/12/some-thoughts-on-binary-compatibility/ Hope this helps, Pavel. From cmorve69 at yahoo.es Fri Jun 4 04:36:50 2010 From: cmorve69 at yahoo.es (Cristian Morales Vega) Date: Fri, 4 Jun 2010 04:36:50 +0200 Subject: [Matroska-devel] Incompatible API changes between libebml 0.7.7 and 0.8.1? In-Reply-To: <4C07C5FA.4080805@sorensonmedia.com> References: <201006011635.33347.moritz@bunkus.org> <4C07C5FA.4080805@sorensonmedia.com> Message-ID: 2010/6/3 Pavel Koshevoy : > On 6/3/2010 8:38 AM, Steve Lhomme wrote: >> I don't know how they achieve that. Do they have to add the new methods >> at the bottom of the class definition ? If not, what constitutes an ABI >> incompatibility ? > > > Basically, to maintain ABI you (1) can't add/change virtual function > signatures or (2) add/change datamembers, and use a PIMPL to hide > datamembers (http://en.wikipedia.org/wiki/Pimpl) > > There is a full list of do's/don't's here: > http://techbase.kde.org/Policies/Binary_Compatibility_Issues_With_C++ > (use google cache if kde.org doesn't respond) > > And some thoughts on the subject by Thiago Maciera: > http://labs.trolltech.com/blogs/2009/08/12/some-thoughts-on-binary-compatibility/ Great links. I didn't check the software itself, but probably you also want to look at http://ispras.linux-foundation.org/index.php/ABI_compliance_checker. From moritz at bunkus.org Fri Jun 4 10:41:50 2010 From: moritz at bunkus.org (Moritz Bunkus) Date: Fri, 4 Jun 2010 10:41:50 +0200 Subject: [Matroska-devel] Incompatible API changes between libebml 0.7.7 and 0.8.1? In-Reply-To: References: <201006011635.33347.moritz@bunkus.org> <4C07C5FA.4080805@sorensonmedia.com> Message-ID: <201006041041.51402.moritz@bunkus.org> Hey guys, great links, thanks for those. Here's what we decided to do: 1. We generally aim for binary compatibility and increase LIBRARY_SO_VER in the Makefiles if a release isn't binary compatible. The naming scheme in LIBRARY_SO_VER will not be changed, only the version increased on incompatible releases. 2. The next release of both libraries will have the version number 1.0.0 in order to indicate the binary incompatibility. 3. The LIBRARY_SO_VER of both libs will be libxyz.so.2 in case any distro is already using libxyz.so.1 for the current release. Just to be safe. 4. The new release should be out this weekend. Everyone OK with this? Regards, Mosu -- If Darl McBride was in charge, he'd probably make marriage unconstitutional too, since clearly it de-emphasizes the commercial nature of normal human interaction, and probably is a major impediment to the commercial growth of prostitution. - Linus Torvalds From cmorve69 at yahoo.es Fri Jun 4 11:30:38 2010 From: cmorve69 at yahoo.es (Cristian Morales Vega) Date: Fri, 4 Jun 2010 11:30:38 +0200 Subject: [Matroska-devel] Incompatible API changes between libebml 0.7.7 and 0.8.1? In-Reply-To: <201006041041.51402.moritz@bunkus.org> References: <201006011635.33347.moritz@bunkus.org> <4C07C5FA.4080805@sorensonmedia.com> <201006041041.51402.moritz@bunkus.org> Message-ID: 2010/6/4 Moritz Bunkus : > Hey guys, > > great links, thanks for those. Here's what we decided to do: > > 1. We generally aim for binary compatibility and increase LIBRARY_SO_VER > in the Makefiles if a release isn't binary compatible. The naming scheme > in LIBRARY_SO_VER will not be changed, only the version increased on > incompatible releases. > > 2. The next release of both libraries will have the version number 1.0.0 > in order to indicate the binary incompatibility. > > 3. The LIBRARY_SO_VER of both libs will be libxyz.so.2 in case any > distro is already using libxyz.so.1 for the current release. Just to be > safe. > > 4. The new release should be out this weekend. > > Everyone OK with this? Perfectly Ok for openSUSE. From fabian at greffrath.com Sun Jun 6 22:03:02 2010 From: fabian at greffrath.com (Fabian Greffrath) Date: Sun, 06 Jun 2010 22:03:02 +0200 Subject: [Matroska-devel] Incompatible API changes between libebml 0.7.7 and 0.8.1? In-Reply-To: References: <201006011635.33347.moritz@bunkus.org> <4C07C5FA.4080805@sorensonmedia.com> <201006041041.51402.moritz@bunkus.org> Message-ID: <1275854582.25156.3.camel@beppo> Am Freitag, den 04.06.2010, 11:30 +0200 schrieb Cristian Morales Vega: > 2010/6/4 Moritz Bunkus : > > Hey guys, > > > > great links, thanks for those. Here's what we decided to do: > > > > 1. We generally aim for binary compatibility and increase LIBRARY_SO_VER > > in the Makefiles if a release isn't binary compatible. The naming scheme > > in LIBRARY_SO_VER will not be changed, only the version increased on > > incompatible releases. > > > > 2. The next release of both libraries will have the version number 1.0.0 > > in order to indicate the binary incompatibility. > > > > 3. The LIBRARY_SO_VER of both libs will be libxyz.so.2 in case any > > distro is already using libxyz.so.1 for the current release. Just to be > > safe. > > > > 4. The new release should be out this weekend. > > > > Everyone OK with this? > > Perfectly Ok for openSUSE. I think it's perfectly OK for Debian, too. Most probably a little bit too late for the next stable release, though. :/ - Fabian From slhomme at matroska.org Wed Jun 9 14:24:28 2010 From: slhomme at matroska.org (Steve Lhomme) Date: Wed, 9 Jun 2010 14:24:28 +0200 Subject: [Matroska-devel] mkclean 0.3.0 is out Message-ID: http://www.matroska.org/downloads/mkclean.html After weeks of various development a new reworked version of mkclean is out. The main change with the 0.2.x version is the reworked remuxer that now put the audio before the matching video Blocks (a requirement for WebM). It can also split laced Blocks so they fit in their corresponding Cluster. For those who don't understand all these words, it's just better for seeking. You will need to use the "--remux" command-line option. PS: it now builds fine in XCode (OS X) as well. -------------- next part -------------- An HTML attachment was scrubbed... URL: From easttrue at gmail.com Sun Jun 13 03:24:28 2010 From: easttrue at gmail.com (easttrue) Date: Sun, 13 Jun 2010 10:24:28 +0900 Subject: [Matroska-devel] libmatroska/ebml 0.9.0/0.8.0 is binary incompatible with previous version In-Reply-To: References: <201005301224.39552.moritz@bunkus.org> Message-ID: <4ED37E61-2649-4E9A-934C-4719B6B4D602@gmail.com> jhsnjfc jkpo easttrue 2010. 5. 30. ?? 8:27 Cristian Morales Vega ??: > 2010/5/30 Moritz Bunkus : >> Hey, >> >> On Sunday 30 May 2010 12:12:24 Steve Lhomme wrote: >> >>> It's possible to change the .soname although programs that currently >>> depend on libmatroska will have to update their build system too. >>> Also >>> if the goal is to have old and new versions co-exist, shouldn't the >>> headers be in separate dirs too ? >> >> As far as I know you don't have to change anything in the app's build >> system. You usually link against "-lmatroska -lebml", and you have >> symlinks libebml.so pointing to the currently active one, >> e.g. libebml.so.2. The linker embeds the full library name, so upon >> execution it is looking for libebml.so.2 so you can change the >> symlink >> after linking without breaking existing applications. For example: >> >> [0 mosu at tionne ~] ls -l /usr/lib/libQtCore.so* >> lrwxrwxrwx 1 root root 18 2010-05-25 11:43 /usr/lib/ >> libQtCore.so -> libQtCore.so.4.6.2 >> lrwxrwxrwx 1 root root 18 2010-05-25 11:43 /usr/lib/ >> libQtCore.so.4 -> libQtCore.so.4.6.2 >> lrwxrwxrwx 1 root root 18 2010-05-25 11:44 /usr/lib/ >> libQtCore.so.4.6 -> libQtCore.so.4.6.2 >> -rw-r--r-- 1 root root 2630464 2010-04-14 07:42 /usr/lib/ >> libQtCore.so.4.6.2 >> >> The headers' installation directory won't have to be changed either. >> >> The C version libebml2 is different matter. > > True. > > To summarize, what I would like: > > - For libebml2/libmatroska2 > Use symbol versioning > > - For libebml/libmatroska > I suppose it will be deprecated once libebml2/libmatroska2 is released > (soon?), so don't worry about symbol versioning now. > If you have the policy of not thinking about binary compatibility at > all it's ok, but make that clear. Don't name the library > libebml.so.0.8.1, with soname libebml.so.0; but libebml-0.8.1.so, with > soname libebml-0.8.1.so. > If you are going to try to maintain binary compatibility change the > soname when it breaks. So next version should have soname libebml.so.1 > or libebml.so.2 (in case some distro already changed the soname). > _______________________________________________ > Matroska-devel mailing list > Matroska-devel at lists.matroska.org > http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel > Read Matroska-Devel on GMane: http://dir.gmane.org/gmane.comp.multimedia.matroska.devel From brianp at austin.rr.com Mon Jun 14 01:15:03 2010 From: brianp at austin.rr.com (Brian P. Barnes) Date: Sun, 13 Jun 2010 18:15:03 -0500 Subject: [Matroska-devel] Project out of control? Message-ID: <4C156677.3020208@austin.rr.com> Hi, I am trying to build ibmatroska-1.0.0.tar.bz2 NFG: brianp at trex:~/download/mkv.matroska/libmatroska-1.0.0/make/linux$ make Makefile make: Nothing to be done for `Makefile'. debian/docs has zero bytes. Good thing you documented it with a shell script: brianp at trex:~/download/mkv.matroska/libmatroska-1.0.0/make$ sh ./makedoc.sh : not foundh: 4: make Documentation : not foundh: 6: How about a configure script? How about an INSTALL.txt or even a README.txt. Do you expect anybody in the world other than the authors to be able to wade through this morass? Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From dbone1026 at hotmail.com Thu Jun 17 13:33:19 2010 From: dbone1026 at hotmail.com (Damian Perez) Date: Thu, 17 Jun 2010 07:33:19 -0400 Subject: [Matroska-devel] Bug Report - Latest Haali (20-May-10) And MKVMerge Message-ID: Hello. Using the latest Haali Media Splitter any mkv created with MKVMerge that has a DTS(MA) audio track stutters like crazy to the point where it is completely unplayable. However, any mkv created with MakeMKV that has a DTS(MA) audio track plays flawless. I have confirmed this behavior using MPC HC, WMP, and SageTV. Others have also noted the same behavior. Unfortunately, since my mkv collection is made up of a mix of MKVMerge and MakeMKV created mkvs, Haali is unusable and instead I have to use the MPC Matroska Splitter. It is not clear whether this is a Haali issue or a MKVMerge issue (although MKVMerge created mkvs with DTS-MA play flawless using a splitter other then Haali). Testing was done on Windows 7 x32 HTPCs (one HTPC which used a 5670 GPU and the other HTPC which uses the Clarkdale core i5). Thanks for your time. Cheers, Damian http://dbone1026.blogspot.com http://www.mediasmartserver.net _________________________________________________________________ The New Busy is not the old busy. Search, chat and e-mail from your inbox. http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_3 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeremy at scobil.com Fri Jun 25 21:25:19 2010 From: jeremy at scobil.com (Jeremy) Date: Fri, 25 Jun 2010 15:25:19 -0400 Subject: [Matroska-devel] Developing with Matroska Lib Message-ID: I am trying to develop an illustrator plugin that outputs a Matroska file and am completly lost as to what is wrong. I made a forum post a week ago, with no replies. If anyone can give me a hand, it would be great. http://forum.corecodec.com/viewtopic.php?f=15&t=3883 Thanks, Jeremy -------------- next part -------------- An HTML attachment was scrubbed... URL: From slhomme at matroska.org Sat Jun 26 11:20:19 2010 From: slhomme at matroska.org (Steve Lhomme) Date: Sat, 26 Jun 2010 11:20:19 +0200 Subject: [Matroska-devel] Developing with Matroska Lib In-Reply-To: References: Message-ID: It's probably better to ask your questions here or on IRC. Here's my answer: Do you absolutely need C++ ? Otherwise you should try libebml2 and libmatroska2 which are written in C. You can check mkvalidator, mkclean and mkvtree that are all using is and probably easier to use. Also you should not write a segment directly like that. Usually you'll write the segment header, then all its children, and only at the end rewrite the head with the actual size. Otherwise that means you need to keep everything in memory, which can be huge for HD content... Steve On Fri, Jun 25, 2010 at 9:25 PM, Jeremy wrote: > I am trying to develop an illustrator plugin that outputs a Matroska file > and am completly lost as to what is wrong. > I made a forum post a week ago, with no replies. If anyone can give me a > hand, it would be great. > > http://forum.corecodec.com/viewtopic.php?f=15&t=3883 > > Thanks, > Jeremy > > _______________________________________________ > Matroska-devel mailing list > Matroska-devel at lists.matroska.org > http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel > Read Matroska-Devel on GMane: > http://dir.gmane.org/gmane.comp.multimedia.matroska.devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nikolay.popov at mail.ru Mon Jun 28 16:06:19 2010 From: nikolay.popov at mail.ru (=?koi8-r?Q?=EE=C9=CB=CF=CC=C1=CA_=F0=CF=D0=CF=D7?=) Date: Mon, 28 Jun 2010 19:06:19 +0500 Subject: [Matroska-devel] Haali dsmux. bug report Message-ID: Haali dsmux cant add subtitles into mkv-file: "dsmux.exe out.mkv in.avi rus.srt" ..it adds them as attachment