From janickovic at radlight.com Thu Jul 1 08:05:26 2004 From: janickovic at radlight.com (Peter "Kekso" Janickovic) Date: Thu, 1 Jul 2004 08:05:26 +0200 Subject: [Matroska-devel] Re: Re: Re: Matroska + Delphi References: <40E2F65E.2080200@hrz.tu-chemnitz.de> <40E30938.5070807@hrz.tu-chemnitz.de> Message-ID: Thanks a lot ... "Alexander No??" wrote in message news:40E30938.5070807 at hrz.tu-chemnitz.de... > Peter "Kekso" Janickovic wrote: > > > yes, i need it ... > > thx > > http://www-user.tu-chemnitz.de/~noe/Video-Zeug/matroska_lib/mtrdllsrc.zip > > I hope it compiles on other systems; my source code folder > is a bit obfuscated :o > > > > Alex From steve.lhomme at free.fr Fri Jul 2 16:33:43 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Fri, 02 Jul 2004 16:33:43 +0200 Subject: [Matroska-devel] WavPack in Matroska Message-ID: <40E57247.2070708@free.fr> Hi, As some of you may know, there is an hybrid mode in Wavpack. That means that you can encode a PCM file losslessly but it will be split in 2 parts : a lossy file with a (somehow) given bitrate and another file to complement the lost data. I hope I get the idea right... IMO this is a killer feature (not found elsewhere ?) because it allows you to have a good quality lossy file format (that hopefully could be used even in portable players) and at the same time you can keep the original losslessly. Not about the muxing... Right now the result is encoded in 2 files : one for the lossy data and one for the complementary data. But how do we allow this in Matroska ? - We could also use 2 files. But IMO that's not very clean even though the possibility should exist. In this case we should have a way to identify matching pairs inside the container. This way even if you rename the 2 files, you can manage to rematch them later. The MD5 sum computed by WavPack could be used for that - Put the 2 "parallel" streams in one Matroska file. The options are : * have a track for each, which a codec ID for each, each distinct from the normal codec ID of WavPack * have the lossy in one track and the complement attached (since it can't be used without the lossy part) * have both muxed in a single track. Maybe that's the way a normal WavPack block is done, so it would be fully compatible with the normal WavPack codec ID. We would only need a different codec ID when the complement is not put in the track. What do you think ? -- robUx4 on blog From christian at matroska.org Fri Jul 2 20:52:57 2004 From: christian at matroska.org (ChristianHJW) Date: Fri, 02 Jul 2004 20:52:57 +0200 Subject: [Matroska-devel] Re: Current Status of WinStreamer ? In-Reply-To: <1088362684.8864.12.camel@shrek.bitfreak.net> References: <40DEB48D.4020004@matroska.org> <40DF4C10.6040109@email.it> <1088362684.8864.12.camel@shrek.bitfreak.net> Message-ID: <40E5AF09.8070100@matroska.org> Ronald S. Bultje wrote: > Hi, > On Mon, 2004-06-28 at 00:37, Marco Iannaccone wrote: >>Is there any website, etc..., where I can find informations about >>WinStreamer? > WinStreamer is really just GStreamer, so all information is on the > GStreamer website (http://gstreamer.freedesktop.org/). > Christian, I know it sounds nice marketing-wise, but try to keep > referring to GStreamer, since the naming could confuse people more than > would be good for us. no marketing involved here Ronald, i am just too lazy to keep saying '... the Windows port of Gstreamer ..' :P > If you guys have any win32 pre-builds, we'll > gladly host those on our project website. > Ronald Dont worry, no plans for a fork anymore ;) .... you guys showed you were really interested in the port, and made it a part of your project. So why should we think of forking at all ? Now, what we urgently need is a working binary, and be it with a very very limited functionality, just to have a prrof thats its alive .... Christian matroska project admin From christian at matroska.org Fri Jul 2 22:59:33 2004 From: christian at matroska.org (ChristianHJW) Date: Fri, 02 Jul 2004 22:59:33 +0200 Subject: [Matroska-devel] Offer for cooperation on a menue system Message-ID: <40E5CCB5.8080606@matroska.org> Hi Xiph guys, i dont know if this is a wise move, some of our members are against it, but here i am : We offered our users a usable menue system in matroska long ago, but due to higher priorities we never had the time to look at it. Amongst other things we are looking at to improve our container and its value to our users, menue have been brought back to our attention in this public poll here : http://forum.doom9.org/showthread.php?s=&threadid=78011 Now, its not so problematic to define a nice menue system for a container, but there really IS a problem to write a menue editor for that, so that people can start to - convert DVD menues into the new format - create their own menues etc. and to make sure all players will support this new menue system, so i thought it might be a good idea to contact you on this, and ask you if you were prepared to cooperate with us on this issue. I know the communication between Xiph and our team has not always been the best in the past, but maybe this cooperation could be a possibility to forget what happened in the past, and make a new start ? After all, Ogg and matroska do have completely different goals now, so there should be room for both really. Thanks for a short answer Christian matroska project admin From janickovic at radlight.com Fri Jul 2 23:18:48 2004 From: janickovic at radlight.com (Peter "Kekso" Janickovic) Date: Fri, 2 Jul 2004 23:18:48 +0200 Subject: [Matroska-devel] Re: Re: Re: Matroska + Delphi References: <40E2F65E.2080200@hrz.tu-chemnitz.de><40E30938.5070807@hrz.tu-chemnitz.de> Message-ID: BTW Dont you have an "smaller" code for this i mean i dont need such stuff, i just need to have info about the mkv file f.e duration, Streamcount, streams names, and that is all ... thx . "Peter "Kekso" Janickovic" wrote in message news:cc09j8$ffp$1 at sea.gmane.org... > Thanks a lot ... > > "Alexander No??" wrote in message > news:40E30938.5070807 at hrz.tu-chemnitz.de... > > Peter "Kekso" Janickovic wrote: > > > > > yes, i need it ... > > > thx > > > > http://www-user.tu-chemnitz.de/~noe/Video-Zeug/matroska_lib/mtrdllsrc.zip > > > > I hope it compiles on other systems; my source code folder > > is a bit obfuscated :o > > > > > > > > Alex From moritz at bunkus.org Sat Jul 3 12:05:11 2004 From: moritz at bunkus.org (Moritz Bunkus) Date: Sat, 3 Jul 2004 12:05:11 +0200 Subject: [Matroska-devel] WavPack in Matroska In-Reply-To: <40E57247.2070708@free.fr> References: <40E57247.2070708@free.fr> Message-ID: <20040703100511.GM19240@bunkus.org> Hi, > - We could also use 2 files. But IMO that's not very clean even though > the possibility should exist. Yuck! > - Put the 2 "parallel" streams in one Matroska file. The options are : > > * have a track for each, which a codec ID for each, each distinct from > the normal codec ID of WavPack Hmm yes, could be done. I'm not sure I like it, though, because splitters might try to create a 'pin' (DShow terms) for that track as well. If we do that we might need a new element in the track headers: LinkedTrack or sth similar which contains the UID that this track belongs to so that when remuxing this track will always be copied if the 'parent' is copied as well. > * have the lossy in one track and the complement attached (since it > can't be used without the lossy part) Sucks, because the decoder needs the attached part. So the splitter/demuxer will have to read/parse the attachments as well and hand that data over to the decoder. What if that attachment is really big - like 50MB or sth like that? This would put a lot of strain on the complete system. > * have both muxed in a single track. Maybe that's the way a normal > WavPack block is done, so it would be fully compatible with the normal > WavPack codec ID. We would only need a different codec ID when the > complement is not put in the track. To be honest this would be the easiest way to do it. The other systems need heavy modification of every demuxer out there... So I'd favor the last option. 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 steve.lhomme at free.fr Sat Jul 3 12:33:52 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Sat, 03 Jul 2004 12:33:52 +0200 Subject: [Matroska-devel] WavPack in Matroska In-Reply-To: <20040703100511.GM19240@bunkus.org> References: <40E57247.2070708@free.fr> <20040703100511.GM19240@bunkus.org> Message-ID: <40E68B90.6070600@free.fr> Moritz Bunkus a ?crit : >>- We could also use 2 files. But IMO that's not very clean even though >>the possibility should exist. > > Yuck! Well, that's how it's done now. But without any container. The .wvc file has no tags, no nothing, just the complementary data. These data mean nothing wihtout the original .wv file. That's why from our point of view it's better to have everything in the same file. >>- Put the 2 "parallel" streams in one Matroska file. The options are : >> >>* have a track for each, which a codec ID for each, each distinct from >>the normal codec ID of WavPack > > > Hmm yes, could be done. I'm not sure I like it, though, because > splitters might try to create a 'pin' (DShow terms) for that track as > well. If we do that we might need a new element in the track headers: > LinkedTrack or sth similar which contains the UID that this track > belongs to so that when remuxing this track will always be copied if the > 'parent' is copied as well. Yes, I'm not sure if we have a flag to hide tracks or not. Also a Control Track wouldn't help much here. >>* have the lossy in one track and the complement attached (since it >>can't be used without the lossy part) > > > Sucks, because the decoder needs the attached part. So the > splitter/demuxer will have to read/parse the attachments as well and > hand that data over to the decoder. What if that attachment is really > big - like 50MB or sth like that? This would put a lot of strain on the > complete system. Agreed >>* have both muxed in a single track. Maybe that's the way a normal >>WavPack block is done, so it would be fully compatible with the normal >>WavPack codec ID. We would only need a different codec ID when the >>complement is not put in the track. > > > To be honest this would be the easiest way to do it. The other systems > need heavy modification of every demuxer out there... > > So I'd favor the last option. Yes, but I think that's probably not the way WavPack works now. At least for the normal mode. If David says that the library can handle that then it's the way to go. The thing other point is the Codec ID. We need one for : 1) normal WavPack 2) WavPack lossy mixed with Complement 3) WavPack lossy alone It could all be using the same Codec ID. And we add something in the Codec Private to state which mode is used. -- robUx4 on blog From chris at matroska.org Sat Jul 3 13:11:50 2004 From: chris at matroska.org (Christian HJ Wiesner) Date: Sat, 03 Jul 2004 13:11:50 +0200 Subject: [Matroska-devel] WavPack in Matroska In-Reply-To: <40E68B90.6070600@free.fr> References: <40E57247.2070708@free.fr> <20040703100511.GM19240@bunkus.org> <40E68B90.6070600@free.fr> Message-ID: <40E69476.3030701@matroska.org> Steve Lhomme wrote: > Moritz Bunkus a ?crit : > >>> - We could also use 2 files. But IMO that's not very clean even >>> though the possibility should exist. >> >> Yuck! > > Well, that's how it's done now. But without any container. The .wvc > file has no tags, no nothing, just the complementary data. These data > mean nothing wihtout the original .wv file. That's why from our point > of view it's better to have everything in the same file. Forgive me my ignorance, but who has a use for 2 tracks of a hybrid encoding in the same file ? Normally those HAVE to be 2 files, so that they can fulfil their purpose ? The idea is : - to have a small lossy file, that you can copy quickly to your laptop, portable unit, etc. - to have the complementary file @ home on the server, saving some 20 - 30% space compared to a real lossless file, but still you are able to restore the original track, without losses I dont see ANY sense in storing them both together in one single file ? Do i miss something ? Maybe for creation of the tracks ? Please enlighten me .... Christian From steve.lhomme at free.fr Sat Jul 3 15:22:43 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Sat, 03 Jul 2004 15:22:43 +0200 Subject: [Matroska-devel] WavPack in Matroska In-Reply-To: <40E69476.3030701@matroska.org> References: <40E57247.2070708@free.fr> <20040703100511.GM19240@bunkus.org> <40E68B90.6070600@free.fr> <40E69476.3030701@matroska.org> Message-ID: <40E6B323.8080804@free.fr> Christian HJ Wiesner a ?crit : > Steve Lhomme wrote: >> Well, that's how it's done now. But without any container. The .wvc >> file has no tags, no nothing, just the complementary data. These data >> mean nothing wihtout the original .wv file. That's why from our point >> of view it's better to have everything in the same file. > > Forgive me my ignorance, but who has a use for 2 tracks of a hybrid > encoding in the same file ? Normally those HAVE to be 2 files, so that > they can fulfil their purpose ? The idea is : It is very consistent to store related content in the same file. You could use TAR which is a very easy format. But Matroska offer such a possibility too. Imagine the mess if you have 2 files for each track you rip. And when moving these files to another folder, where filenames would matter (to match pairs). It's really not good... As I'm thinking about CoreSync, an application to automate such a job, it is really not convenient to have this special case. The idea is that it should be stored as if it was a basic lossless file (ie both in the same file). And when needed you can only keep the lossy part only in another file (like peeling for Vorbis). Which leads to another problem. If we store all the data in the same track (see previous email) we have to have a codec interaction when we want to create a lossy-only version of the file. So it might be a good idea to have it at the container level instead... I couldn't imagine a clean DShow graph if it was at the codec level, but it's easy on the container level. > - to have a small lossy file, that you can copy quickly to your laptop, > portable unit, etc. > - to have the complementary file @ home on the server, saving some 20 - > 30% space compared to a real lossless file, but still you are able to > restore the original track, without losses Of course, for such operations, it's dead easy to have a separate file. But in the other hand it is harder to maitain consistency. (another good reason to have CoreSync doing the ugly job when needed) > I dont see ANY sense in storing them both together in one single file ? > Do i miss something ? Maybe for creation of the tracks ? Please > enlighten me .... A good example is music distribution. It's easier to "sell" a track in one file than in 2 files. I'd personally wouldn't like to have both files separate on my HD. But would like to split then easily on demand (and when you think of WavPack muxed with video it's also better if this operation is done at the container level). -- robUx4 on blog From steve.lhomme at free.fr Sat Jul 3 15:37:42 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Sat, 03 Jul 2004 15:37:42 +0200 Subject: [Matroska-devel] WavPack in Matroska In-Reply-To: <40E6B323.8080804@free.fr> References: <40E57247.2070708@free.fr> <20040703100511.GM19240@bunkus.org> <40E68B90.6070600@free.fr> <40E69476.3030701@matroska.org> <40E6B323.8080804@free.fr> Message-ID: <40E6B6A6.7090401@free.fr> Steve Lhomme a ?crit : > The idea is that it should be stored as if it was a basic lossless file > (ie both in the same file). And when needed you can only keep the lossy > part only in another file (like peeling for Vorbis). > > Which leads to another problem. If we store all the data in the same > track (see previous email) we have to have a codec interaction when we > want to create a lossy-only version of the file. So it might be a good > idea to have it at the container level instead... I couldn't imagine a > clean DShow graph if it was at the codec level, but it's easy on the > container level. IMO, we should add a new element for such a case. It's not a CodecPrivate data for each frame, but rather a secondary stream that makes sense only with the first one... So we have 2 choices : - add a track property to state that the track is not to be played and correspond to data for track XYZ. IMO that's not very clean and not backward compatible. - add a new element to the BlockGroup with a SecondaryData item. That's clean. But it only makes sense if the complementary data in WavPack is on a frame/block basis. David ??? This way it would be easy to have an option in mkvmerge like --strip-secondary to get only the lossy part of a content (could apply to other things too). If we go this way, we should investigate a bit more if it could be generalised to more content/codec/features. -- robUx4 on blog From bottanek at radlight.com Sat Jul 3 22:07:43 2004 From: bottanek at radlight.com (Martin Bottanek) Date: Sat, 3 Jul 2004 22:07:43 +0200 Subject: [Matroska-devel] RadLight TTA DirectShow filter v1.0.0.0 Message-ID: RadLight adds supports for yet another nice audio format ^_^ I am sure you all know TTA (if not, more info about TTA can be found here : http://www.true-audio.com/) Here's a download link : http://developer.radlight.net/download/tta/RadLightTTA_1.0.0.0.exe In case you guys manage to put TTA into MKA let us know and we will update the filter accordingly. Best regards, Martin From dbryant at impulse.net Sat Jul 3 22:18:01 2004 From: dbryant at impulse.net (David Bryant) Date: Sat, 3 Jul 2004 13:18:01 -0700 Subject: [Matroska-devel] WavPack in Matroska References: <40E57247.2070708@free.fr> <20040703100511.GM19240@bunkus.org> <40E68B90.6070600@free.fr> <40E69476.3030701@matroska.org> <40E6B323.8080804@free.fr> <40E6B6A6.7090401@free.fr> Message-ID: <000801c4613a$d7392360$7dc70804@Pentium> Guys, I have been reading this discussion and thought it was about time to jump in and offer some clarification about the hybrid mode of WavPack (even though I don't exactly understand all the issues from your end). First of all, the "correction" data is stored in WavPack blocks just like the regular data, and there is a one-to-one correspondance between the lossy blocks and the correction blocks. The high-level code in wavpack.c puts the blocks in different files, but they could just as easily be put into the same file (although the playback code would have to know about this). There is no way to (even accidentally) play a correction file by itself; the decoder will refuse. Also, the lossy file created is identical whether a correction file is created at the same time or not. To the low level unpacking code (in unpack.c) you simply pass the blocks (in memory) for decoding. If you pass just a regular lossy block then you get lossy decoding, if you pass a lossy block and its matching correction block then you get lossless decoding. BTW, WavPack blocks are relatively small; usually < 100k. There is an undocumented option (-kn) in the WavPack command-line program to set the block size (in samples) to any number you want if you want to experiment (I don't check bounds so you might get a crash if you put in funny numbers). I also thought about having them (the correction blocks) stored in the same file. Obviously, this has no advantage over standard lossless except that a program could be made that would split them (or put them back together) very quickly. However, I have not run into inconvenience in having two files for every track. I store my music with one album per folder, so all the files get copied or moved when I copy or move the folder. Playback or decoding automatically finds the correction files. If I want to make a copy to transfer to someone else (for, you know, testing) then I simply don't copy the .wvc files and I have only 1/3 the data. The only time you would run into trouble would be if you used a renaming program that was not wvc-aware. Of course, if your system is not set up to having the two matching files then it can be a mess. I ran into something like that with the foobar plugin. Foobar wants to pass me an input instance that I use to get my file data for playback (including seeking). This is nice in a device-independence sort of way, but it makes it difficult for me to try to find my correction file. The OptimFROG (which also has a hybrid mode called "dualstream") author simply decided that the correction files would only be usable from the command-line decoder; all plugins would simply play the lossy stream. And I imagine that in some applications (DirectShow?) this may simply be the only way it can work. And it's not a disaster; even at 256 kbps the lossy files sound fine, but it's nice to use them if they're right there. Unrelated to this discussion I was thinking that there are two nice features in WavPack that might make it very attractive for video editing. First, the fact that WavPack blocks may contain any number of samples makes it easy to delete are add small numbers of samples without having to re-encode the whole rest of the file. Also, I imagine that you guys are thinking of the lossless mode for editing because you don't want the normal accumulation of artifacts with repeated encoding and decoding of lossy codecs. However, the lossy mode of WavPack is much less subject to this, in fact you can go through dozens of encode-decode cycles at the 512 kbps (stereo) bitrate with no audible degradation. This will become even more an issue with higher bitdepths and sample rates. Just a thought... ----- Original Message ----- From: "Steve Lhomme" To: "Discussion about the current and future development of Matroska" Cc: "David Bryant" Sent: Saturday, July 03, 2004 6:37 AM Subject: Re: [Matroska-devel] WavPack in Matroska Steve Lhomme a ?crit : > The idea is that it should be stored as if it was a basic lossless file > (ie both in the same file). And when needed you can only keep the lossy > part only in another file (like peeling for Vorbis). > > Which leads to another problem. If we store all the data in the same > track (see previous email) we have to have a codec interaction when we > want to create a lossy-only version of the file. So it might be a good > idea to have it at the container level instead... I couldn't imagine a > clean DShow graph if it was at the codec level, but it's easy on the > container level. IMO, we should add a new element for such a case. It's not a CodecPrivate data for each frame, but rather a secondary stream that makes sense only with the first one... So we have 2 choices : - add a track property to state that the track is not to be played and correspond to data for track XYZ. IMO that's not very clean and not backward compatible. - add a new element to the BlockGroup with a SecondaryData item. That's clean. But it only makes sense if the complementary data in WavPack is on a frame/block basis. David ??? This way it would be easy to have an option in mkvmerge like --strip-secondary to get only the lossy part of a content (could apply to other things too). If we go this way, we should investigate a bit more if it could be generalised to more content/codec/features. -- robUx4 on blog From paul at msn.com Sun Jul 4 01:17:34 2004 From: paul at msn.com (Paul Bryson) Date: Sat, 3 Jul 2004 18:17:34 -0500 Subject: [Matroska-devel] Re: WavPack in Matroska References: <40E57247.2070708@free.fr><20040703100511.GM19240@bunkus.org> <40E68B90.6070600@free.fr><40E69476.3030701@matroska.org> <40E6B323.8080804@free.fr> <40E6B6A6.7090401@free.fr> Message-ID: "Steve Lhomme" wrote... > IMO, we should add a new element for such a case. It's not a > CodecPrivate data for each frame, but rather a secondary stream that > makes sense only with the first one... So we have 2 choices : > - add a track property to state that the track is not to be played and > correspond to data for track XYZ. IMO that's not very clean and not > backward compatible. This element already exists on the Video side. http://matroska.commo.de/technical/specs/index.html#TrackOverlay Adding it to the audio side of things seems like a pretty small task. As far as DirectShow goes, it shouldn't be hard to create two pins from the splitter, one for the lossy data, and one for the correction data. Then the decoder has two input pins, one for each. If there is only the lossy pin connected, then it decodes lossy. If both are connected, then it decodes both. This makes it necessary to create a seperate CodecID for the correction data. Maybe somthing like A/WAVEPACK/CORRECTION. The benefit of using two tracks is that because it uses the existing structures, nothing really has to be rewritten to take advantage of it. > - add a new element to the BlockGroup with a SecondaryData item. That's > clean. But it only makes sense if the complementary data in WavPack is > on a frame/block basis. David ??? This way it would be easy to have an > option in mkvmerge like --strip-secondary to get only the lossy part of > a content (could apply to other things too). If we go this way, we > should investigate a bit more if it could be generalised to more > content/codec/features. >From David's reply, it appears that they share the exact same number of samples/block. This would certainly allow the use of another element in the BlockGroup that indicates that it is an " optional enhancement" that is bandwidth sensitive. The benefit of this method is that it would use less overhead since it is using the same BlockGroup and timecode data from the Block. Atamido From steve.lhomme at free.fr Sun Jul 4 11:16:22 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Sun, 04 Jul 2004 11:16:22 +0200 Subject: [Matroska-devel] RadLight TTA DirectShow filter v1.0.0.0 In-Reply-To: References: Message-ID: <40E7CAE6.1010901@free.fr> Martin Bottanek a ?crit : > RadLight adds supports for yet another nice audio format ^_^ > > I am sure you all know TTA (if not, more info about TTA can be found here : > http://www.true-audio.com/) Yes, actually the sources were hosted on CoreCodec before it got down. > Here's a download link : > http://developer.radlight.net/download/tta/RadLightTTA_1.0.0.0.exe > > In case you guys manage to put TTA into MKA let us know and we will update > the filter accordingly. Toff has a working filter to encode/decode TTA in TTA files and Matroska. We are waiting for support in mkvmerge before we release it (and hopefully hoped to have CoreCodec up sooner or later). -- robUx4 on blog From steve.lhomme at free.fr Sun Jul 4 11:48:18 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Sun, 04 Jul 2004 11:48:18 +0200 Subject: [Matroska-devel] RadLight TTA DirectShow filter v1.0.0.0 In-Reply-To: References: Message-ID: <40E7D262.5020409@free.fr> Martin Bottanek a ?crit : > Here's a download link : > http://developer.radlight.net/download/tta/RadLightTTA_1.0.0.0.exe I just downloaded it. And I'm surprised not to see any source code. As you know TTA is LGPL and therefore you have to publish the code that is statically linked with the original code. (the same goes for MPC) -- robUx4 on blog From bottanek at radlight.com Sun Jul 4 11:46:34 2004 From: bottanek at radlight.com (Martin Bottanek) Date: Sun, 4 Jul 2004 11:46:34 +0200 Subject: [Matroska-devel] Re: RadLight TTA DirectShow filter v1.0.0.0 References: <40E7D262.5020409@free.fr> Message-ID: As far as I know it's GNU GPL. If it was LGPL we would not have to publish the sourcecode. There is a nice site which discusses all about various opensource licenses : http://www.opensource.org/licenses/index.php . Give it 5 minutes of your time :) Anyways, Alexander already has the sourcecode. See you around ;) "Steve Lhomme" wrote in message news:40E7D262.5020409 at free.fr... Martin Bottanek a ?crit : > Here's a download link : > http://developer.radlight.net/download/tta/RadLightTTA_1.0.0.0.exe I just downloaded it. And I'm surprised not to see any source code. As you know TTA is LGPL and therefore you have to publish the code that is statically linked with the original code. (the same goes for MPC) -- robUx4 on blog From moritz at bunkus.org Sun Jul 4 11:51:31 2004 From: moritz at bunkus.org (Moritz Bunkus) Date: Sun, 4 Jul 2004 11:51:31 +0200 Subject: [Matroska-devel] RadLight TTA DirectShow filter v1.0.0.0 In-Reply-To: <40E7CAE6.1010901@free.fr> References: <40E7CAE6.1010901@free.fr> Message-ID: <20040704095130.GA4029@bunkus.org> Hi, > Toff has a working filter to encode/decode TTA in TTA files and > Matroska. We are waiting for support in mkvmerge before we release it http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-0.9.2-build20040703-1.rar 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 steve.lhomme at free.fr Sun Jul 4 12:06:32 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Sun, 04 Jul 2004 12:06:32 +0200 Subject: [Matroska-devel] Re: RadLight TTA DirectShow filter v1.0.0.0 In-Reply-To: References: <40E7D262.5020409@free.fr> Message-ID: <40E7D6A8.1070501@free.fr> Martin Bottanek a ?crit : > As far as I know it's GNU GPL. If it was LGPL we would not have to publish > the sourcecode. There is a nice site which discusses all about various > opensource licenses : http://www.opensource.org/licenses/index.php . Give > it 5 minutes of your time :) > > Anyways, Alexander already has the sourcecode. Hmmm. 1) If it's LGPL you _have_to_ release the code that is directly dependant on the code (ie statically linked) 2) for GPL it's the case even if you dynamically link to the code. 3) the source code should not be made available to the author, but to whoever receive the binary (true for LGPL and GPL), so that includes myself 4) you should spend some days studying all existing OSS license before claiming false things (I suggest you have a look at the archives of license-discuss at opensource.org on which I've been subscribed for 3 years) > "Steve Lhomme" wrote in message > news:40E7D262.5020409 at free.fr... > Martin Bottanek a ?crit : > > >>Here's a download link : >>http://developer.radlight.net/download/tta/RadLightTTA_1.0.0.0.exe > > > I just downloaded it. And I'm surprised not to see any source code. As > you know TTA is LGPL and therefore you have to publish the code that is > statically linked with the original code. (the same goes for MPC) > -- robUx4 on blog From bottanek at radlight.com Sun Jul 4 12:02:03 2004 From: bottanek at radlight.com (Martin Bottanek) Date: Sun, 4 Jul 2004 12:02:03 +0200 Subject: [Matroska-devel] Re: Re: RadLight TTA DirectShow filter v1.0.0.0 References: <40E7D262.5020409@free.fr> <40E7D6A8.1070501@free.fr> Message-ID: 5, Get a life, dude! "Steve Lhomme" wrote in message news:40E7D6A8.1070501 at free.fr... Martin Bottanek a ?crit : > As far as I know it's GNU GPL. If it was LGPL we would not have to publish > the sourcecode. There is a nice site which discusses all about various > opensource licenses : http://www.opensource.org/licenses/index.php . Give > it 5 minutes of your time :) > > Anyways, Alexander already has the sourcecode. Hmmm. 1) If it's LGPL you _have_to_ release the code that is directly dependant on the code (ie statically linked) 2) for GPL it's the case even if you dynamically link to the code. 3) the source code should not be made available to the author, but to whoever receive the binary (true for LGPL and GPL), so that includes myself 4) you should spend some days studying all existing OSS license before claiming false things (I suggest you have a look at the archives of license-discuss at opensource.org on which I've been subscribed for 3 years) > "Steve Lhomme" wrote in message > news:40E7D262.5020409 at free.fr... > Martin Bottanek a ?crit : > > >>Here's a download link : >>http://developer.radlight.net/download/tta/RadLightTTA_1.0.0.0.exe > > > I just downloaded it. And I'm surprised not to see any source code. As > you know TTA is LGPL and therefore you have to publish the code that is > statically linked with the original code. (the same goes for MPC) > -- robUx4 on blog From steve.lhomme at free.fr Sun Jul 4 12:14:06 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Sun, 04 Jul 2004 12:14:06 +0200 Subject: [Matroska-devel] Re: WavPack in Matroska In-Reply-To: References: <40E57247.2070708@free.fr><20040703100511.GM19240@bunkus.org> <40E68B90.6070600@free.fr><40E69476.3030701@matroska.org> <40E6B323.8080804@free.fr> <40E6B6A6.7090401@free.fr> Message-ID: <40E7D86E.1010005@free.fr> Paul Bryson a ?crit : > "Steve Lhomme" wrote... > >>IMO, we should add a new element for such a case. It's not a >>CodecPrivate data for each frame, but rather a secondary stream that >>makes sense only with the first one... So we have 2 choices : > > >>- add a track property to state that the track is not to be played and >>correspond to data for track XYZ. IMO that's not very clean and not >>backward compatible. > > > This element already exists on the Video side. > http://matroska.commo.de/technical/specs/index.html#TrackOverlay > Adding it to the audio side of things seems like a pretty small task. As far as > DirectShow goes, it shouldn't be hard to create two pins from the splitter, one > for the lossy data, and one for the correction data. Then the decoder has two > input pins, one for each. If there is only the lossy pin connected, then it > decodes lossy. If both are connected, then it decodes both. This makes it > necessary to create a seperate CodecID for the correction data. Maybe somthing > like A/WAVEPACK/CORRECTION. OK, very good point. It already exists in the current format and would fit perfectly what we need. So there's no need adding an element elsewhere. The downsides I can see are : - a bit more overhead - would need a clean muxing of both tracks, ie the related blocks should always be close to each other But these are minor problem... For stripping the complement, we would need an option in mkvmerge like --strip-overlays or --strip-overlay "CodecID" (just ideas). -- robUx4 on blog From jcsston at wiesneronline.net Sun Jul 4 18:10:36 2004 From: jcsston at wiesneronline.net (Jory) Date: Sun, 4 Jul 2004 11:10:36 -0500 Subject: [Matroska-devel] Re: RadLight TTA DirectShow filter v1.0.0.0 References: <40E7D262.5020409@free.fr> <40E7D6A8.1070501@free.fr> Message-ID: <001401c461e1$7ef35a70$0200a8c0@jcsston> As I understand the LGPL you only have to publish the source code of the lib if you modify it and the object files so someone could change the link and re-link (unless I know). There is nothing about dynamic/static links. If so then why did we select the LGPL license for libebml/libmatroska if no one can use it? Jory Stone ----- Original Message ----- From: "Steve Lhomme" To: "Martin Bottanek" Cc: Sent: Sunday, July 04, 2004 5:06 AM Subject: Re: [Matroska-devel] Re: RadLight TTA DirectShow filter v1.0.0.0 Martin Bottanek a ?crit : > As far as I know it's GNU GPL. If it was LGPL we would not have to publish > the sourcecode. There is a nice site which discusses all about various > opensource licenses : http://www.opensource.org/licenses/index.php . Give > it 5 minutes of your time :) > > Anyways, Alexander already has the sourcecode. Hmmm. 1) If it's LGPL you _have_to_ release the code that is directly dependant on the code (ie statically linked) 2) for GPL it's the case even if you dynamically link to the code. 3) the source code should not be made available to the author, but to whoever receive the binary (true for LGPL and GPL), so that includes myself 4) you should spend some days studying all existing OSS license before claiming false things (I suggest you have a look at the archives of license-discuss at opensource.org on which I've been subscribed for 3 years) > "Steve Lhomme" wrote in message > news:40E7D262.5020409 at free.fr... > Martin Bottanek a ?crit : > > >>Here's a download link : >>http://developer.radlight.net/download/tta/RadLightTTA_1.0.0.0.exe > > > I just downloaded it. And I'm surprised not to see any source code. As > you know TTA is LGPL and therefore you have to publish the code that is > statically linked with the original code. (the same goes for MPC) > -- robUx4 on blog _______________________________________________ Matroska-devel mailing list Matroska-devel at lists.matroska.org http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel From moritz at bunkus.org Sun Jul 4 19:31:51 2004 From: moritz at bunkus.org (Moritz Bunkus) Date: Sun, 4 Jul 2004 19:31:51 +0200 Subject: [Matroska-devel] Re: licenses... In-Reply-To: <001401c461e1$7ef35a70$0200a8c0@jcsston> References: <40E7D6A8.1070501@free.fr> <001401c461e1$7ef35a70$0200a8c0@jcsston> Message-ID: <20040704173151.GE4029@bunkus.org> Hi, > If so then why did we select the LGPL license for libebml/libmatroska if no > one can use it? The other way around - everyone can use it. LGPL'ed code MAY be linked to non-(L)GPL'ed code. GPL'ed code may not be used inside and may not be linked to non-(L)GPL'ed code. Exception are system libraries (e.g. the C runtime libs on Windows or the Quicktime libs on MacOS). 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 bottanek at radlight.com Mon Jul 5 12:14:07 2004 From: bottanek at radlight.com (Martin Bottanek) Date: Mon, 5 Jul 2004 12:14:07 +0200 Subject: [Matroska-devel] Re: Re: licenses... References: <40E7D6A8.1070501@free.fr><001401c461e1$7ef35a70$0200a8c0@jcsston> <20040704173151.GE4029@bunkus.org> Message-ID: Correct. Anyway, the sourcecode is already available on TTA website. "Moritz Bunkus" wrote in message news:20040704173151.GE4029 at bunkus.org... > Hi, > > > If so then why did we select the LGPL license for libebml/libmatroska if no > > one can use it? > > The other way around - everyone can use it. LGPL'ed code MAY be linked > to non-(L)GPL'ed code. GPL'ed code may not be used inside and may not be > linked to non-(L)GPL'ed code. Exception are system libraries (e.g. the C > runtime libs on Windows or the Quicktime libs on MacOS). > > 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 steve.lhomme at free.fr Thu Jul 8 23:05:16 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Thu, 08 Jul 2004 23:05:16 +0200 Subject: [Matroska-devel] Wavpakc block format Message-ID: <40EDB70C.6010207@free.fr> From David: "The actual block format is trivial. It starts with the 32-byte header (typedef WavpackHeader). This header starts with "wvpk" and includes the exact length of the block (minus 8, I think, to match that stupid RIFF standard).." So We can strip that and directly mux the rest in the frame. This is the same format for .wvc files (complement file when hybrid mode is used) -- robUx4 on blog From Liisachan at faireal.net Fri Jul 9 05:05:02 2004 From: Liisachan at faireal.net (Liisachan) Date: Fri, 09 Jul 2004 12:05:02 +0900 Subject: [Matroska-devel] MatroskaSplitter Sound-skip Bug Fixed in the one with TTADS? In-Reply-To: References: <20040622121742AX6bkj@faireal.net> Message-ID: <20040709120502$yEqzY@faireal.net> Hi, TTA support in MKV is already better than FLAC in MKV. Now, MatrosaSplitter 1.0.2.2 and 1.0.2.3 has a skippy sound prob, which I already posted in this list but had been also reporeted here as--[ 908300 ] MPC: internal Matroska-Splitter broken: http://sourceforge.net/tracker/index.php?func=detail&aid=908300&group_id=82303&atid=565649 I can reproduce this skippy sound prob with (official) 1.0.2.3 embedded in MPC, when I play (xvid+tta).mkv. # Small sample (xvid+tta).mkv for testing just in case: # http://user33.at.infoseek.co.jp/tta-mkv.zip This problem is gone if I use the "modified" 1.0.2.3 splitter coming with TTA DirectShow Filters pre-version binaries (including modified Matroska filters). Modified splitter is supporting TTA, so this is not surprising. What *is* surprising is, this problem is also fixed if I use the old version 1.0.2.0 of the splitter. Yes, 1.0.2.0 splits TTA in MKV decently. Does that mean the skippy sound bug is fixed in this modified filter? Or is this just accidental?! Also let me note that 1.0.2.1 has another kind of bug (chapter times confusion), which is reporeted by Yuuhi, Bluedan, and me: http://forum.doom9.org/showthread.php?s=&postid=455094#post455094 Anyway, if these bugs are going to be fixed at the same time when TTA is officially supported, that'd be really great. Regards. Liisachan "Igor Janos" wrote: > Another problem found. When implementing subtitle support I've found out > that there is some problem with the splitter when not all pins are > connected. I get lockups :Z.... the strange thing is that when I seek at > some place the lockup the lockup is gone and the file plays ok.... it just > does not work from the beginning :( > > who is in charge of the splitter ? ... since my school semester has ended I > have quite a lot of time for coding.. perhaps I could take a look if you > wish. > > best, > Igor > > > "Liisachan" wrote in message > news:20040622121742AX6bkj at faireal.net... > > this is a (probable) bug report, > > from users in Japan. > > > > i ve just posted this for them at > > http://forum.doom9.org/showthread.php?s=&threadid=78474 > > because they are too shy to do that by themselves... > > > > Is this a known problem? > > > > ----- > > MatroskaSplitter 1.0.2.2+ Potentially Buggy? > > > > MatroskaSplitter 1.0.2.2 / 1.0.2.3 doesn't report the accurate fps to the > downstream filter such as ffdshow, or to BsPlayer; it says the framerate is > 25 even if the correct value is like 24 or 30. This doesnt seem to cause any > major problems atm, but some users report minor, occasional jitters which > allegedly will be fixed by using the older MatroskaSplitter. (I personally > have not ever experienced this jitter problem.) So we should assume that the > newer versions (1.0.2.2+) are potentially problematic in some ways. > > The current version is 1.0.2.3. Matroska_Pack_Full_v1.0.2.exe contains > that version too. > > > > These pics demonstrate what is happening: > > http://m17n.cool.ne.jp/matroska/splitter-problem.html > > > > Can anyone confirm this please? > > > > I know Gabest is not around much these days, but if there IS a problem, I > hope itll be fixed before "Matroska 1.0" is out... > > > > ----- > > > > Liisachan > > > > _______________________________________________ > Matroska-devel mailing list > Matroska-devel at lists.matroska.org > http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel From dbartzos at ath.forthnet.gr Thu Jul 8 23:21:26 2004 From: dbartzos at ath.forthnet.gr (Dimitrios Bartzos) Date: Fri, 9 Jul 2004 00:21:26 +0300 Subject: [Matroska-devel] Can't compile on Linux Shrike Message-ID: <001301c46531$875f2920$4e9310d5@home> > Hello, > > I hope this is the correct list to send this question. > I have downloaded and successfully compiled libebml but when it comes to > libmatroska, I get: > > g++ -c -Wall -Wno-unknown-pragmas -ansi -fno-gnu-keywords -D_GNU_SOURCE > -Wshadow -I/tmp/libmatroska-0.6.3/make/linux/../.. > -I/tmp/libmatroska-0.6.3/make/linux/../../../libebml -o > /tmp/libmatroska-0.6.3/make/linux/../../src/KaxBlock.o > /tmp/libmatroska-0.6.3/make/linux/../../src/KaxBlock.cpp > In file included from /tmp/libmatroska-0.6.3/src/KaxBlock.cpp:41: > /tmp/libmatroska-0.6.3/matroska/KaxBlock.h:215: type specifier omitted for > parameter `ScopeMode' > /tmp/libmatroska-0.6.3/matroska/KaxBlock.h:215: parse error before `=' token > /tmp/libmatroska-0.6.3/src/KaxBlock.cpp: In member function > `libmatroska::LacingType libmatroska::KaxBlock::GetBestLacingType() > const': > /tmp/libmatroska-0.6.3/src/KaxBlock.cpp:226: no matching function for > call to ` > libmatroska::KaxBlock::CodedSizeLength(unsigned int&, int) const' > /usr/local/include/ebml/EbmlElement.h:212: candidates are: int > libebml::EbmlElement::CodedSizeLength() const > /tmp/libmatroska-0.6.3/src/KaxBlock.cpp:228: `CodedSizeLengthSigned' > undeclared > (first use this function) > /tmp/libmatroska-0.6.3/src/KaxBlock.cpp:228: (Each undeclared identifier is > reported only once for each function it appears in.) > /tmp/libmatroska-0.6.3/src/KaxBlock.cpp: In member function `virtual uint64 > libmatroska::KaxBlock::UpdateSize(bool, bool)': > /tmp/libmatroska-0.6.3/src/KaxBlock.cpp:269: no matching function for > call to ` > libmatroska::KaxBlock::CodedSizeLength(unsigned int&, int)' > /usr/local/include/ebml/EbmlElement.h:212: candidates are: int > libebml::EbmlElement::CodedSizeLength() const > /tmp/libmatroska-0.6.3/src/KaxBlock.cpp: In member function `virtual uint32 > libmatroska::KaxBlock::RenderData(libebml::IOCallback&, bool, bool)': > /tmp/libmatroska-0.6.3/src/KaxBlock.cpp:428: no matching function for > call to ` > libmatroska::KaxBlock::CodedSizeLength(int64&, int)' > /usr/local/include/ebml/EbmlElement.h:212: candidates are: int > libebml::EbmlElement::CodedSizeLength() const > /tmp/libmatroska-0.6.3/src/KaxBlock.cpp:431: `CodedValueLength' undeclared > (first use this function) > /tmp/libmatroska-0.6.3/src/KaxBlock.cpp:439: `CodedValueLengthSigned' > undeclared (first use this function) > /tmp/libmatroska-0.6.3/src/KaxBlock.cpp: At global scope: > /tmp/libmatroska-0.6.3/src/KaxBlock.cpp:503: type specifier omitted for > parameter `ScopeMode' > /tmp/libmatroska-0.6.3/src/KaxBlock.cpp:503: parse error before `)' token > /tmp/libmatroska-0.6.3/src/KaxBlock.cpp: In member function `uint64 > libmatroska::KaxBlock::ReadData(...)': > /tmp/libmatroska-0.6.3/src/KaxBlock.cpp:507: `input' undeclared (first > use this > function) > /tmp/libmatroska-0.6.3/src/KaxBlock.cpp:509: `ReadFully' undeclared > (first use > this function) > /tmp/libmatroska-0.6.3/src/KaxBlock.cpp:509: `SCOPE_ALL_DATA' undeclared > (first > use this function) > /tmp/libmatroska-0.6.3/src/KaxBlock.cpp:575: `ReadCodedSizeValue' undeclared > (first use this function) > /tmp/libmatroska-0.6.3/src/KaxBlock.cpp:583: `ReadCodedSizeSignedValue' > undeclared (first use this function) > /tmp/libmatroska-0.6.3/src/KaxBlock.cpp:610: `SCOPE_PARTIAL_DATA' undeclared > (first use this function) > make: *** [/tmp/libmatroska-0.6.3/make/linux/../../src/KaxBlock.o] Error 1 > > Any idea what might be causing this? I have Redhat Linux Shrike 9.1, > with kernel 2.4.20-31.9 > > Thanks for your help, > > Dimitrios. > > From moritz at bunkus.org Fri Jul 9 09:54:50 2004 From: moritz at bunkus.org (Moritz Bunkus) Date: Fri, 9 Jul 2004 09:54:50 +0200 Subject: [Matroska-devel] Can't compile on Linux Shrike In-Reply-To: <001301c46531$875f2920$4e9310d5@home> References: <001301c46531$875f2920$4e9310d5@home> Message-ID: <20040709075450.GT18991@bunkus.org> Hi, > > g++ -c -Wall -Wno-unknown-pragmas -ansi -fno-gnu-keywords -D_GNU_SOURCE > > -Wshadow -I/tmp/libmatroska-0.6.3/make/linux/../.. You're not using the latest libebml and libmatroska which are both at 0.7.0. You can download them from http://www.bunkus.org/videotools/mkvtoolnix/sources/old/ Alternatively you can try to use my RPM packages built on FC1: http://www.bunkus.org/videotools/mkvtoolnix/index.html#dlinst_redhat 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 christophe.paris at free.fr Fri Jul 9 11:11:16 2004 From: christophe.paris at free.fr (Christophe PARIS) Date: Fri, 09 Jul 2004 11:11:16 +0200 Subject: [Matroska-devel] MatroskaSplitter Sound-skip Bug Fixed in the one with TTADS? In-Reply-To: <20040709120502$yEqzY@faireal.net> References: <20040622121742AX6bkj@faireal.net> <20040709120502$yEqzY@faireal.net> Message-ID: <40EE6134.7010205@free.fr> Hi Liisachan, Liisachan wrote: > TTA support in MKV is already better than FLAC in MKV. > > Now, MatrosaSplitter 1.0.2.2 and 1.0.2.3 has a skippy sound prob, > which I already posted in this list but had been also reporeted here > as--[ 908300 ] MPC: internal Matroska-Splitter broken: > http://sourceforge.net/tracker/index.php?func=detail&aid=908300&group_id=82303&atid=565649 > > > I can reproduce this skippy sound prob with (official) 1.0.2.3 > embedded in MPC, when I play (xvid+tta).mkv. > > # Small sample (xvid+tta).mkv for testing just in case: # > http://user33.at.infoseek.co.jp/tta-mkv.zip > > This problem is gone if I use the "modified" 1.0.2.3 splitter coming > with TTA DirectShow Filters pre-version binaries (including modified > Matroska filters). Modified splitter is supporting TTA, so this is > not surprising. I've listed this problem on this page also : http://wiki.corecodec.org/wiki/TODO_list_-_Known_issues_-_Things_to_improve "MatroskaSplitter has some skipping sound problems that seems to be caused by buffering problems. (there is a bug entry on sf.net here ). Putting pProperties->cbBuffer = 256000 in CBaseSplitterOutputPin::DecideBufferSize seems to have a good effect on it. Though is probably not the best fix ;)" > What *is* surprising is, this problem is also fixed if I use the old > version 1.0.2.0 of the splitter. Yes, 1.0.2.0 splits TTA in MKV > decently. The matroska splitter architecture has changed since the 1.0.2.1, since this version it is based on the more general BaseSplitter class, which handle bufferisation differently. Filters not modified for TTA probably output TTA in ACM compatibility mode. > Does that mean the skippy sound bug is fixed in this modified filter? > Or is this just accidental?! There is a workaround yes, but it's probably not perfect. > Also let me note that 1.0.2.1 has another kind of bug (chapter times > confusion), which is reporeted by Yuuhi, Bluedan, and me: > http://forum.doom9.org/showthread.php?s=&postid=455094#post455094 I think in 1.0.2.1 we added a new flags to chapters, so the data representation has changed and the player need to be updated accordingly. IIRC There also was a bug when reporting the size of the chapters data, so players could not determinate if it was using the new flag or not. > Anyway, if these bugs are going to be fixed at the same time when TTA > is officially supported, that'd be really great. I secretly hope that Gabest will have a look at the "Known issues" page :D sometime. Regards, Toff From Liisachan at faireal.net Fri Jul 9 12:46:47 2004 From: Liisachan at faireal.net (Liisachan) Date: Fri, 09 Jul 2004 19:46:47 +0900 Subject: [Matroska-devel] MatroskaSplitter Sound-skip Bug Fixed in theone with TTADS? In-Reply-To: <40EE6134.7010205@free.fr> References: <20040709120502$yEqzY@faireal.net> <40EE6134.7010205@free.fr> Message-ID: <20040709194647y?YVJ-@faireal.net> Hi, Christophe PARIS wrote: > I've listed this problem on this page also : > http://wiki.corecodec.org/wiki/TODO_list_-_Known_issues_-_Things_to_improve OK, so this is a known bug.... > > What *is* surprising is, this problem is also fixed if I use the old > > version 1.0.2.0 of the splitter. Yes, 1.0.2.0 splits TTA in MKV > > decently. 1.0.2.0 doesnt have this problem, but it cannot handle track names (in sub tracks, for example) properly. > > Also let me note that 1.0.2.1 has another kind of bug (chapter times > > confusion), which is reporeted by Yuuhi, Bluedan, and me: > > http://forum.doom9.org/showthread.php?s=&postid=455094#post455094 > > I think in 1.0.2.1 we added a new flags to chapters, so the data > representation has changed and the player need to be updated > accordingly. IIRC There also was a bug when reporting the size of the > chapters data, so players could not determinate if it was using the new > flag or not. So atm, there is no Matroska Splitter that works perfectly, as Martin from the RadLight team says: "The only problem is the extremely buggy MKV splitter :Z It's really pain to make a support for something that does not work 100%"........ ;_; I thought 1.0.2.3 coming with TTADS* mightve been OK, but it still has the same problem. It reports the video framerate 25.0 even tho it is actually 23.97 or something, which seems to be related to the skippy sound problem. > There is a workaround yes, but it's probably not perfect. Absolutely better than nothing... Im guessing it would be great if someone could release a workaround version while waiting Gabest fixes it perfectly, because we are going to need modified splitter anyway for TTA (and WV) * Another question: This modified pre-release splitter is only for Win2K/XP? (Unicode version?) Im wondering this because Gabest always releases 2 builds (unicode and non-unicode) of the same version splitter. Regards Liisachan From christophe.paris at free.fr Fri Jul 9 13:45:12 2004 From: christophe.paris at free.fr (Christophe PARIS) Date: Fri, 09 Jul 2004 13:45:12 +0200 Subject: [Matroska-devel] MatroskaSplitter Sound-skip Bug Fixed in theone with TTADS? In-Reply-To: <20040709194647y?YVJ-@faireal.net> References: <20040709120502$yEqzY@faireal.net> <40EE6134.7010205@free.fr> <20040709194647y?YVJ-@faireal.net> Message-ID: <40EE8548.90308@free.fr> Liisachan wrote: >>>What *is* surprising is, this problem is also fixed if I use the old >>>version 1.0.2.0 of the splitter. Yes, 1.0.2.0 splits TTA in MKV >>>decently. > > > 1.0.2.0 doesnt have this problem, but it cannot handle > track names (in sub tracks, for example) properly. Yes, as I have said, 1.0.2.0 doesn't use the same codebase. > So atm, there is no Matroska Splitter > that works perfectly, as Martin from the RadLight team says: > "The only problem is the extremely buggy MKV splitter :Z It's > really pain to make a support for something that does not work > 100%"........ Current official 1.0.2.3 works not to bad if you forgot about the stuttering problem. Perfection doesn't exist ;-) Btw any idea of fix, more information about the problem, are always welcome. > I thought 1.0.2.3 coming with TTADS* mightve been OK, > but it still has the same problem. It reports the video > framerate 25.0 even tho it is actually 23.97 or something, > which seems to be related to the skippy sound problem. Hmm, I'm not sure this framerate is used anywhere, and I donno at the moment where it's read from. So you still have skippy sound problem with 1.0.2.3 TTA edition ? > Im guessing it would be great if someone could release a > workaround version while waiting Gabest fixes it perfectly, > because we are going to need modified splitter anyway for TTA > (and WV) Yes, we should probably add wavpack support in the splitter/demuxer and then release a new official version, even if other wavpack filters are not done yet. > * Another question: > This modified pre-release splitter is only for Win2K/XP? > (Unicode version?) Yes it's a unicode version. Regards, Toff From moritz at bunkus.org Fri Jul 9 19:03:11 2004 From: moritz at bunkus.org (Moritz Bunkus) Date: Fri, 9 Jul 2004 19:03:11 +0200 Subject: [Matroska-devel] just a test, ignore me Message-ID: <20040709170311.GV18991@bunkus.org> iiiiiiiiiiignore me! IGNORE ME DAMNIT!! -- 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 steve.lhomme at free.fr Fri Jul 9 22:30:01 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Fri, 09 Jul 2004 22:30:01 +0200 Subject: [Matroska-devel] SVN.matroska.org up Message-ID: <40EF0049.6050302@free.fr> Hi, As CoreCodec has been (too) long to come up and we need a source server to be working again we have finally setup a new machine in Russia (Matroska source) thanks to Mike (Haali) !!! This machine is now hosting all the related Matroska websites like : - www.matroska.org - packs.matroska.org - dl.matroska.org - and now the newly svn.matroska.org This SVN site can be browsed from HTTP and HTTPS. For HTTP you can just browse the sources and check them out : - http://svn.matroska.org:8080/svn/matroska/trunk/ (Matroska Sources) - http://svn.matroska.org:8080/svn/www/trunk/ (all websites) - http://svn.matroska.org:8080/svn/usf/trunk/ (USF content) For HTTPS you can browse and modify the content provided you have a valid account (that you can get from me or Mosu) : - https://svn.matroska.org/svn/matroska/trunk/ - https://svn.matroska.org/svn/www/trunk/ - https://svn.matroska.org/svn/usf/trunk/ If you need to change your password : https://svn.matroska.org/my/ HTTP runs on port 80 (Apache 1.3) and 8080 (Apache 2.0 with SVN). The 8080 content is the same as port 80 and will probably replace it soon. So you will be able to remove the 8080 port to access SVN publicly. All commits to the SVN repositories will be monitored on matroska-cvs at lists.matroska.org PS: Thanx to Haali, Mosu for their precious help on setting up this machine. -- robUx4 on blog From moritz at bunkus.org Fri Jul 9 22:40:03 2004 From: moritz at bunkus.org (Moritz Bunkus) Date: Fri, 9 Jul 2004 22:40:03 +0200 Subject: [Matroska-devel] SVN.matroska.org up In-Reply-To: <40EF0049.6050302@free.fr> References: <40EF0049.6050302@free.fr> Message-ID: <20040709204003.GX18991@bunkus.org> Hi, > PS: Thanx to Haali, Mosu for their precious help on setting up this machine. Nope, thanks to you for doing all the work and getting our stuff back online. 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 chris at matroska.org Fri Jul 9 23:26:15 2004 From: chris at matroska.org (Christian HJ Wiesner) Date: Fri, 09 Jul 2004 23:26:15 +0200 Subject: [Matroska-devel] SVN.matroska.org up In-Reply-To: <20040709204003.GX18991@bunkus.org> References: <40EF0049.6050302@free.fr> <20040709204003.GX18991@bunkus.org> Message-ID: <40EF0D77.1030200@matroska.org> Moritz Bunkus wrote: >Hi, > >>S: Thanx to Haali, Mosu for their precious help on setting up this machine. >>Nope, thanks to you for doing all the work and getting our stuff back >>online. Mosu >> Thanks to all of you, you're a great team :) ! Christian From moritz at bunkus.org Sun Jul 11 09:12:50 2004 From: moritz at bunkus.org (Moritz Bunkus) Date: Sun, 11 Jul 2004 09:12:50 +0200 Subject: [Matroska-devel] tags for movies Message-ID: <20040711071250.GZ18991@bunkus.org> Heya, I have some propositions for tags that are more movie oriented (also TV show oriented, just not audio oriented ;)). After looking a bit at IMDB here's what we don't have: Let's take Star Wars as an example http://www.imdb.com/title/tt0076759/ we have TITLE=Star Wars we have DATE=1977 we have DIRECTOR=George Lucas we DON't have WRITER=George Lucas we have GENRE=Sci-Fi... we DON't have something for 'tagline', plot outline, user comments we DON't have a user rating we DON't have something fitting for the cast and the roles they play The rest is not really important. We do have INVOLVED_PERSON which could be used for WRITER and ACTOR, but I don't like it - it's way too general. So the new tags I'd like to have are: WRITER - The person who wrote the screenplay. TAGLINE - The movie's tag line. PLOT_OUTLINE - A summary of the plot. IMDB_RATING - The rating on IMDB.com (x/10 points). Should be used instead of POPULARIMETER because the latter one does not really have a fixed scale... ACTOR - The name of a person playing a part in this movie. CHARACTER - The name of the character this actor plays. Should be one level beneath the ACTOR tag. What do you think? 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 steve.lhomme at free.fr Sun Jul 11 09:58:25 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Sun, 11 Jul 2004 09:58:25 +0200 Subject: [Matroska-devel] tags for movies In-Reply-To: <20040711071250.GZ18991@bunkus.org> References: <20040711071250.GZ18991@bunkus.org> Message-ID: <40F0F321.6040705@free.fr> Moritz Bunkus a ?crit : > Heya, > > I have some propositions for tags that are more movie oriented (also TV > show oriented, just not audio oriented ;)). After looking a bit at IMDB > here's what we don't have: > > Let's take Star Wars as an example http://www.imdb.com/title/tt0076759/ > > we have TITLE=Star Wars > we have DATE=1977 > we have DIRECTOR=George Lucas > we DON't have WRITER=George Lucas > we have GENRE=Sci-Fi... > we DON't have something for 'tagline', plot outline, user comments > we DON't have a user rating Ok, one thing I really miss when moving files from iTunes to another iTunes machine is that my ratings are not kept. And it's not really an Apple bug. It's just that if you want to integrate User specific informations (comment/rating) it should be only set for user XYZ not as a general comment/rating. And to do it properly a user should set a world-unique ID in the file to identify oneself (so that it can be integrated later in a global database). So far there is no such ID (not sure people would like it anyway). If we add that, it should be "under" a User element. Even with a weak ID. I agree on adding all the rest. -- robUx4 on blog From moritz at bunkus.org Sun Jul 11 20:39:03 2004 From: moritz at bunkus.org (Moritz Bunkus) Date: Sun, 11 Jul 2004 20:39:03 +0200 Subject: [Matroska-devel] tags for movies In-Reply-To: <40F0F321.6040705@free.fr> References: <20040711071250.GZ18991@bunkus.org> <40F0F321.6040705@free.fr> Message-ID: <20040711183903.GB18991@bunkus.org> Hi, > >we have TITLE=Star Wars > >we have DATE=1977 > >we have DIRECTOR=George Lucas > >we DON't have WRITER=George Lucas > >we have GENRE=Sci-Fi... > >we DON't have something for 'tagline', plot outline, user comments > >we DON't have a user rating Ok, I've just added four new tags: WRITTEN_BY, SUMMARY (for plot outline / story summaries), ACTOR and CHARACTER. Like I've written earlier CHARACTER should be a sub-tag of an ACTOR tag. I haven't added tags for 'tagline', user comments (because we can simply use COMMENTS for that) and user rating (due to Steve's request). 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 dbartzos at ath.forthnet.gr Sun Jul 11 23:10:58 2004 From: dbartzos at ath.forthnet.gr (Dimitrios Bartzos) Date: Sun, 11 Jul 2004 21:10:58 +0000 (UTC) Subject: [Matroska-devel] Re: Can't compile on Linux Shrike References: <001301c46531$875f2920$4e9310d5@home> <20040709075450.GT18991@bunkus.org> Message-ID: Moritz Bunkus bunkus.org> writes: > You're not using the latest libebml and libmatroska which are both at > 0.7.0. You can download them from > http://www.bunkus.org/videotools/mkvtoolnix/sources/old/ > Yes, thank you! I just downloaded both and compiled-installed just fine. Dimitrios. From steve.lhomme at free.fr Mon Jul 12 23:05:28 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Mon, 12 Jul 2004 23:05:28 +0200 Subject: [Matroska-devel] TODO Message-ID: <40F2FD18.7060604@free.fr> I've posted the list of current known TODO on the website : http://www.matroska.org/team/todo.html This page should be cleaned up and integrated in the rest of the site. Feel free to add your ideas and remove the things that are done. (I will do my part tomorrow) -- robUx4 on blog From lil_thug at streamyx.com Tue Jul 13 11:10:53 2004 From: lil_thug at streamyx.com (lil_thug at streamyx.com) Date: Tue, 13 Jul 2004 17:10:53 +0800 Subject: [Matroska-devel] help Message-ID: hi, i've downloaded ur mplayerc.exe from your website when i play my video..which is a matroska compression video(.mkv) there seem to be no audio i can only watch the video could you tell me how can i fix this? thanks - ??? Th?g OuT Of HeRe - From steve.lhomme at free.fr Tue Jul 13 11:57:43 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Tue, 13 Jul 2004 11:57:43 +0200 Subject: [Matroska-devel] help In-Reply-To: References: Message-ID: <40F3B217.8090603@free.fr> You should install the Matroska Pack and try it again. http://packs.matroska.org/ If it still doesn't work, right click on your file and go in the properties to see what codec are in your file. lil_thug at streamyx.com a ?crit : > hi, > i've downloaded ur mplayerc.exe from your website > when i play my video..which is a matroska compression video(.mkv) > there seem to be no audio > i can only watch the video > could you tell me how can i fix this? > thanks > > - ??? Th?g OuT Of HeRe - > > _______________________________________________ > Matroska-devel mailing list > Matroska-devel at lists.matroska.org > http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel -- robUx4 on blog From janos at radlight.com Tue Jul 13 13:42:20 2004 From: janos at radlight.com (Igor Janos) Date: Tue, 13 Jul 2004 13:42:20 +0200 Subject: [Matroska-devel] Re: MatroskaSplitter Sound-skip Bug Fixed in theonewith TTADS? References: <20040709120502$yEqzY@faireal.net> <40EE6134.7010205@free.fr><20040709194647y?YVJ-@faireal.net> <40EE8548.90308@free.fr> Message-ID: Problem is still there. After connecting/disconnecting/reconnecting some of the output pins all streams are blocked. You must seek somewhere to make the dataflow begin.... but you must be lucky enough. In most cases all you get is again a blocked splitter even after the seek :( Regards, Igor "Christophe PARIS" wrote in message news:40EE8548.90308 at free.fr... > > > So atm, there is no Matroska Splitter > > that works perfectly, as Martin from the RadLight team says: > > "The only problem is the extremely buggy MKV splitter :Z It's > > really pain to make a support for something that does not work > > 100%"........ > > Current official 1.0.2.3 works not to bad if you forgot about the > stuttering problem. > > Perfection doesn't exist ;-) > Btw any idea of fix, more information about the problem, are always welcome. > > > Regards, > Toff From steve.lhomme at free.fr Thu Jul 15 13:08:08 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Thu, 15 Jul 2004 13:08:08 +0200 Subject: [Matroska-devel] Re: [Matroska-cvs] r147 - trunk/svn.matroska.org In-Reply-To: <200407151103.i6FB3P4m004889@matroska.org> References: <200407151103.i6FB3P4m004889@matroska.org> Message-ID: <40F66598.20909@free.fr> Hi, I just want to let you know that ViewCVS has been successfully installed on svn.matroska.org (on port 8080 and on SSL). That means there is nothing left to add on the server to replace the current Apache 1.3 on port 80. I will probably the switch tomorrow. Until then try to find anything not working well on port 8080 and SSL. svn-commit-mail at lists.matroska.org a ?crit : > Author: robux4 > Date: 2004-07-15 15:03:19 +0400 (Thu, 15 Jul 2004) > New Revision: 147 > > Added: > trunk/svn.matroska.org/viewsvn/ > Log: > let users know about viewSCV for SVN > > _______________________________________________ > Matroska-cvs mailing list > Matroska-cvs at lists.matroska.org > http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-cvs -- robUx4 on blog From steve.lhomme at free.fr Thu Jul 15 13:44:29 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Thu, 15 Jul 2004 13:44:29 +0200 Subject: [Matroska-devel] Stats of www.matroska.org Message-ID: <40F66E1D.60607@free.fr> Those of you who would like to get the statistics on the websites hosted by Haali can have a look here : Only people that have an authorized access are able to check this (that includes the musepack boys). The stats are not generated everyday, but on demand: you just click on do.php or do-1.3.php (for the Apache 1.3 stats, the one currently in use). The stats are still buggy (no session tracking, no count of visits, hardly copes with virtual hosts), but it's still good. For example it is very useful to look at the search engine entries. This way we know what people are looking for when they come. On that topic it seems from the main page we should have a direct link to because a lot of people are looking for this. And on various forums it seems people are confused when trying to play RV in MKV. So we might add a bigger notice on how to play back RV content (either on the site or in the pack). -- robUx4 on blog From steve.lhomme at free.fr Fri Jul 16 16:33:41 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Fri, 16 Jul 2004 16:33:41 +0200 Subject: [Matroska-devel] Dates in Tag Message-ID: <40F7E745.8030303@free.fr> Hi, I was wondering about dates of an audio track in a compilation... The compilation was made in year X and the track was produced/released in Y (Y <= X). What is the policy for such tags in a Matroska file ? I suppose we have to use nested tags for that (the track is contained in the album ?). But is it described somewhere ? http://www.matroska.org/technical/specs/tagging/index.html#dates -- robUx4 on blog From steve.lhomme at free.fr Fri Jul 16 17:23:30 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Fri, 16 Jul 2004 17:23:30 +0200 Subject: [Matroska-devel] Dates in Tag In-Reply-To: <40F7F080.7@pepper-prod.com> References: <40F7E745.8030303@free.fr> <40F7F080.7@pepper-prod.com> Message-ID: <40F7F2F2.9070503@free.fr> Nicolas Le Guen a ?crit : > Steve Lhomme a ?crit : > >> Hi, >> >> I was wondering about dates of an audio track in a compilation... >> The compilation was made in year X and the track was produced/released >> in Y (Y <= X). >> >> What is the policy for such tags in a Matroska file ? >> >> I suppose we have to use nested tags for that (the track is contained >> in the album ?). But is it described somewhere ? >> >> http://www.matroska.org/technical/specs/tagging/index.html#dates >> > I guess that for a compilation in wich tracks have different date, the > ALBUM_DATE tags should be used to specify the date of the compilation > itself. The default DATE tag can then be used for each track. > This follow the same way as TITLE and ALBUM_TITLE. :-) Mmmm, but such tags don't exist in the given specs. Or you refer to something like ALBUM/DATE and ALBUM/TITLE/DATE ? PS: please reply to the ML. -- robUx4 on blog From paul at msn.com Fri Jul 16 18:05:45 2004 From: paul at msn.com (Paul Bryson) Date: Fri, 16 Jul 2004 11:05:45 -0500 Subject: [Matroska-devel] Re: tags for movies References: <20040711071250.GZ18991@bunkus.org> <40F0F321.6040705@free.fr> Message-ID: Moritz Bunkus a ?crit : > I have some propositions for tags that are more movie oriented (also TV > show oriented, just not audio oriented ;)). After looking a bit at IMDB > here's what we don't have: > > Let's take Star Wars as an example http://www.imdb.com/title/tt0076759/ > > we have TITLE=Star Wars > we have DATE=1977 > we have DIRECTOR=George Lucas > we DON't have WRITER=George Lucas > we have GENRE=Sci-Fi... > we DON't have something for 'tagline', plot outline, user comments > we DON't have a user rating The thing that was discussed about this earlier was how much information do we want define to store in the tags? Do we want to just store the basic information that most people would use when searching for the movie, or do we want to define how to store 99% of the possible information? Look here: http://thread.gmane.org/gmane.comp.multimedia.matroska.devel/1735 http://article.gmane.org/gmane.comp.multimedia.matroska.devel/1931 To quote Steve, " Do we really want a whole database inside a Matroska file ? What about pictures of the actors or some of the scenes in the movie ? I'm sure you can find all this in an interactive website but it's probably useless to be embedded in the file." Atamido From Liisachan at faireal.net Sat Jul 17 04:49:13 2004 From: Liisachan at faireal.net (Liisachan) Date: Sat, 17 Jul 2004 11:49:13 +0900 Subject: [Matroska-devel] Matroska Pack 1.0.2 Doesn't Support XviD 1.0.1 Properly Message-ID: <20040717114913_rgRw8@faireal.net> Hi, Im wondering if this is a known problem for Matroska team: [Abstract] Matroska Pack (full) 1.0.2 comes with ffdshow 2003-05-23 by default, which, however, plays XviD 1.0.1 in an improper way, making ppl misunderstand that MKV is an awkward, non-smooth format. The fact is, it is not a problem of MKV, but a problem of older ffdshow's. [How To Reproduce/Confirm The Bug] 1. Make a small video with Xvid 1.0.1 2. Use MPC and first use XviD 1.0.1 itself to decode it. 3. Hit Ctrl + 4 in MPC to see the static. Observe the frame rate.-- for instance, if the vid is 24fps, youll see number like 23.xx 4. Then, use ffdshow 2003-05-23 to decode XviD. -- Now MPC shows a lower fps, like 16fps, and obviously, the video doesnt play smoothly as it should be, altho theres no synch problem. 5. Thirdly, use a newer ffdshow, from http://athos.leffe.dnsalias.com/ OR http://mitglied.lycos.de/ieggei2/ffdshow/ to decode XviD 1.0.1. The problem observed in 4 will be gone. NOTE: The same happens regardless of the container (AVI or MKV) [Conclusion] * ffdshow 2003-05-23 is a bad choice to support cutting-edge technologies like Matroska, because it does not support XviD 1.0.1, which is now one of today's de-fact standard codecs. So, Matroska Packs should use a newer build of ffdshow, if it has to include ffdshow anyway. Regards. Liisachan From chris at matroska.org Sat Jul 17 08:43:33 2004 From: chris at matroska.org (Christian HJ Wiesner) Date: Sat, 17 Jul 2004 08:43:33 +0200 Subject: [Matroska-devel] Matroska Pack 1.0.2 Doesn't Support XviD 1.0.1 Properly In-Reply-To: <20040717114913_rgRw8@faireal.net> References: <20040717114913_rgRw8@faireal.net> Message-ID: <40F8CA95.1030802@matroska.org> Liisachan wrote: >Hi, >Im wondering if this is a known problem for Matroska team: >[Abstract] >Matroska Pack (full) 1.0.2 comes with ffdshow 2003-05-23 >by default, which, however, plays XviD 1.0.1 in an improper way, >making ppl misunderstand that MKV is an awkward, non-smooth >format. > Liisachan, in fact this is one of the most annoying problems in the current matroska packs, and we are well aware of this. The big problem is, all newer versions of ffdshow are coming ( which i find VERY annoying to be honest ) with FFvfw bundled, and for licensing reasons we definitely decided againt distributing a working MPEG4 encoder in our packs. Some of our team are family men or have a job, we cant risk to have the MPEG-LA standing outside our houses and trying to sue us for millions of US$'s of lost revenues, because matroska pack is distributed several 10.000 times per months ( check http://packs.matroska.org to get numbers ). What we need is a newer ffdshow build, but WITHOUT FFvfw bundled !!! Frankly speaking, i dont like the way ffdshow has been taking lately, no offense to Milan. Sure, FFMPEG is a very powerful library, but IMO its wrong to try to make an 'all-in-one' DirectShow filter based on it, as this is completely against the idea of DirectShow. Anyhow, we are well aware that the next packs have to come with such an updated decoder, one way or another, as now there are more and more XviD 1.x copies floating around. Thanks again for pointing us to that, we really have to adress this soon. Best regards Christian From christophe.paris at free.fr Sat Jul 17 11:08:58 2004 From: christophe.paris at free.fr (Christophe PARIS) Date: Sat, 17 Jul 2004 11:08:58 +0200 Subject: [Matroska-devel] Matroska Pack 1.0.2 Doesn't Support XviD 1.0.1 Properly In-Reply-To: <20040717114913_rgRw8@faireal.net> References: <20040717114913_rgRw8@faireal.net> Message-ID: <40F8ECAA.5060808@free.fr> Hi, Liisachan wrote: > Im wondering if this is a known problem for Matroska team: > > Matroska Pack (full) 1.0.2 comes with ffdshow 2003-05-23 > by default, which, however, plays XviD 1.0.1 in an improper way, > making ppl misunderstand that MKV is an awkward, non-smooth > format. Yes, this problem is caused by the packed bitstream option. People have to know that it can also cause the same problems with hardware device. Now about ffdshow version, maybe it's possible to take the 2003-05-23 version and to merge some of the new change and fix this problem. Regards, Toff From jcsston at wiesneronline.net Sat Jul 17 10:53:34 2004 From: jcsston at wiesneronline.net (Jory) Date: Sat, 17 Jul 2004 03:53:34 -0500 Subject: [Matroska-devel] Matroska Pack 1.0.2 Doesn't Support XviD 1.0.1Properly References: <20040717114913_rgRw8@faireal.net> <40F8CA95.1030802@matroska.org> Message-ID: <006901c46bdb$9369c990$0200a8c0@jcsston> > What we need is a newer ffdshow build, but WITHOUT FFvfw bundled !!! > Frankly speaking, i dont like the way ffdshow has been taking lately, no > offense to Milan. Sure, FFMPEG is a very powerful library, but IMO its > wrong to try to make an 'all-in-one' DirectShow filter based on it, as > this is completely against the idea of DirectShow. ffdshow has grown from a little MPEG-4 decoder to a complete ffavcodec/ffformat DirectShow en/decoder. For most uses perhaps a MPEG-4 only branch would be a good idea? As most of the other formats ffdshow can decode are either not often used or there are other official decoders. Jory From steve.lhomme at free.fr Sat Jul 17 13:58:55 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Sat, 17 Jul 2004 13:58:55 +0200 Subject: [Matroska-devel] Re: [Matroska-cvs] r167 - trunk/packs.matroska.org/data In-Reply-To: <200407171011.i6HABG8h009542@matroska.org> References: <200407171011.i6HABG8h009542@matroska.org> Message-ID: <40F9147F.8010108@free.fr> IIRC, I put the logs.txt in svn:ignore. So it should never be modified/updated by the SVN update. If it happens (trashed), that's from somewhere else. svn-commit-mail at lists.matroska.org wrote: > Author: toff > Date: 2004-07-17 14:11:13 +0400 (Sat, 17 Jul 2004) > New Revision: 167 > > Modified: > trunk/packs.matroska.org/data/logs.txt > Log: > Fixed logfile, i wonder if it's a good idea to put that in SVN :> > > Modified: trunk/packs.matroska.org/data/logs.txt > =================================================================== > --- trunk/packs.matroska.org/data/logs.txt 2004-07-17 09:58:28 UTC (rev 166) > +++ trunk/packs.matroska.org/data/logs.txt 2004-07-17 10:11:13 UTC (rev 167) > @@ -1 +1 @@ > -a:2:{s:5:"1.0.1";a:1:{s:5:"1.0.1";a:3:{s:19:"Matroska_Pack_MPEG4";i:46;s:18:"Matroska_Pack_Full";i:74;s:18:"Matroska_Pack_Lite";i:43;}}s:6:"latest";a:1:{s:5:"1.0.2";a:3:{s:19:"Matroska_Pack_MPEG4";i:6309;s:18:"Matroska_Pack_Full";i:78356;s:18:"Matroska_Pack_Lite";i:14697;}}} > \ No newline at end of file > +a:2:{s:5:"1.0.1";a:1:{s:5:"1.0.1";a:3:{s:19:"Matroska_Pack_MPEG4";i:46;s:18:"Matroska_Pack_Full";i:74;s:18:"Matroska_Pack_Lite";i:43;}}s:6:"latest";a:1:{s:5:"1.0.2";a:3:{s:19:"Matroska_Pack_MPEG4";i:7310;s:18:"Matroska_Pack_Full";i:83388;s:18:"Matroska_Pack_Lite";i:15582;}}} > \ No newline at end of file > > _______________________________________________ > Matroska-cvs mailing list > Matroska-cvs at lists.matroska.org > http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-cvs > > From christophe.paris at free.fr Sat Jul 17 14:25:30 2004 From: christophe.paris at free.fr (Christophe PARIS) Date: Sat, 17 Jul 2004 14:25:30 +0200 Subject: [Matroska-devel] Re: [Matroska-cvs] r167 - trunk/packs.matroska.org/data In-Reply-To: <40F9147F.8010108@free.fr> References: <200407171011.i6HABG8h009542@matroska.org> <40F9147F.8010108@free.fr> Message-ID: <40F91ABA.6020207@free.fr> I can't fix the counter, it's reseted each time i commit and svn put the mess : 0 toff at matroska:/www/packs.matroska.org/data$ ls -l total 26 -rw-rw-r-- 1 www www 836 Jul 17 13:58 download.php -rw-rw-r-- 1 www www 6132 Jul 11 01:51 index.php -rw-rw-r-- 1 www www 655 Jul 9 23:07 links.txt -rw-rw-r-- 1 www www 299 Jul 17 14:59 logs.txt -rw-rw-r-- 1 www www 135 Jul 17 14:16 logs.txt.2.mine -rw-rw-r-- 1 www www 275 Jul 17 14:16 logs.txt.2.r167 -rw-rw-r-- 1 www www 401 Jul 17 14:11 logs.txt.mine -rw-rw-r-- 1 www www 275 Jul 17 14:11 logs.txt.r166 -rw-rw-r-- 1 www www 275 Jul 17 14:11 logs.txt.r167 -rw-rw-r-- 1 www www 145 Jul 17 14:16 logs.txt.r168 drwxrwxr-x 3 www www 512 Jul 9 23:07 packs Steve Lhomme wrote: > IIRC, I put the logs.txt in svn:ignore. So it should never be > modified/updated by the SVN update. If it happens (trashed), that's from > somewhere else. > > svn-commit-mail at lists.matroska.org wrote: > >> Author: toff >> Date: 2004-07-17 14:11:13 +0400 (Sat, 17 Jul 2004) >> New Revision: 167 >> >> Modified: >> trunk/packs.matroska.org/data/logs.txt >> Log: >> Fixed logfile, i wonder if it's a good idea to put that in SVN :> >> >> Modified: trunk/packs.matroska.org/data/logs.txt >> =================================================================== >> --- trunk/packs.matroska.org/data/logs.txt 2004-07-17 09:58:28 UTC >> (rev 166) >> +++ trunk/packs.matroska.org/data/logs.txt 2004-07-17 10:11:13 UTC >> (rev 167) >> @@ -1 +1 @@ >> -a:2:{s:5:"1.0.1";a:1:{s:5:"1.0.1";a:3:{s:19:"Matroska_Pack_MPEG4";i:46;s:18:"Matroska_Pack_Full";i:74;s:18:"Matroska_Pack_Lite";i:43;}}s:6:"latest";a:1:{s:5:"1.0.2";a:3:{s:19:"Matroska_Pack_MPEG4";i:6309;s:18:"Matroska_Pack_Full";i:78356;s:18:"Matroska_Pack_Lite";i:14697;}}} >> >> \ No newline at end of file >> +a:2:{s:5:"1.0.1";a:1:{s:5:"1.0.1";a:3:{s:19:"Matroska_Pack_MPEG4";i:46;s:18:"Matroska_Pack_Full";i:74;s:18:"Matroska_Pack_Lite";i:43;}}s:6:"latest";a:1:{s:5:"1.0.2";a:3:{s:19:"Matroska_Pack_MPEG4";i:7310;s:18:"Matroska_Pack_Full";i:83388;s:18:"Matroska_Pack_Lite";i:15582;}}} >> >> \ No newline at end of file >> >> _______________________________________________ >> Matroska-cvs mailing list >> Matroska-cvs at lists.matroska.org >> http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-cvs >> >> > > _______________________________________________ > Matroska-devel mailing list > Matroska-devel at lists.matroska.org > http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel > > From steve.lhomme at free.fr Sat Jul 17 23:21:50 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Sat, 17 Jul 2004 23:21:50 +0200 Subject: [Matroska-devel] Re: [Matroska-cvs] r167 - trunk/packs.matroska.org/data In-Reply-To: <40F91ABA.6020207@free.fr> References: <200407171011.i6HABG8h009542@matroska.org> <40F9147F.8010108@free.fr> <40F91ABA.6020207@free.fr> Message-ID: <40F9986E.6000102@free.fr> Christophe PARIS wrote: > I can't fix the counter, it's reseted each time i commit and svn put the > mess : > > 0 toff at matroska:/www/packs.matroska.org/data$ ls -l > total 26 > -rw-rw-r-- 1 www www 836 Jul 17 13:58 download.php > -rw-rw-r-- 1 www www 6132 Jul 11 01:51 index.php > -rw-rw-r-- 1 www www 655 Jul 9 23:07 links.txt > -rw-rw-r-- 1 www www 299 Jul 17 14:59 logs.txt > -rw-rw-r-- 1 www www 135 Jul 17 14:16 logs.txt.2.mine > -rw-rw-r-- 1 www www 275 Jul 17 14:16 logs.txt.2.r167 > -rw-rw-r-- 1 www www 401 Jul 17 14:11 logs.txt.mine > -rw-rw-r-- 1 www www 275 Jul 17 14:11 logs.txt.r166 > -rw-rw-r-- 1 www www 275 Jul 17 14:11 logs.txt.r167 > -rw-rw-r-- 1 www www 145 Jul 17 14:16 logs.txt.r168 > drwxrwxr-x 3 www www 512 Jul 9 23:07 packs > > Steve Lhomme wrote: > >> IIRC, I put the logs.txt in svn:ignore. So it should never be >> modified/updated by the SVN update. If it happens (trashed), that's >> from somewhere else. Yes, that's what I said. To edit the file you need to do it either as www (from a PHP script) or as root (but you are not root yet). From Liisachan at faireal.net Sun Jul 18 15:43:24 2004 From: Liisachan at faireal.net (Liisachan) Date: Sun, 18 Jul 2004 22:43:24 +0900 Subject: [Matroska-devel] Matroska Pack 1.0.2 Doesn't Support XviD 1.0.1Properly In-Reply-To: <40F8CA95.1030802@matroska.org> References: <20040717114913_rgRw8@faireal.net> <40F8CA95.1030802@matroska.org> Message-ID: <20040718224324szB6I&@faireal.net> Christian HJ Wiesner wrote: > in fact this is one of the most annoying problems in the current > matroska packs, and we are well aware of this. good to know anyway that it is a known problem. This problem is not essentially fatal, a user can just updated ffdshow, or use XviD decoder. Nothing to do with Matroska. The skippy audio bug in MatroskaSplitter 1.0.2.2+ on the other hand, is an essential problem in Matroska on Windows, which I do hope will be solved asap, even by a workaround. Liisachan > > The big problem is, all newer versions of ffdshow are coming ( which i > find VERY annoying to be honest ) with FFvfw bundled, and for licensing > reasons we definitely decided againt distributing a working MPEG4 > encoder in our packs. Some of our team are family men or have a job, we > cant risk to have the MPEG-LA standing outside our houses and trying to > sue us for millions of US$'s of lost revenues, because matroska pack is > distributed several 10.000 times per months ( check > http://packs.matroska.org to get numbers ). > > What we need is a newer ffdshow build, but WITHOUT FFvfw bundled !!! > Frankly speaking, i dont like the way ffdshow has been taking lately, no > offense to Milan. Sure, FFMPEG is a very powerful library, but IMO its > wrong to try to make an 'all-in-one' DirectShow filter based on it, as > this is completely against the idea of DirectShow. > > Anyhow, we are well aware that the next packs have to come with such an > updated decoder, one way or another, as now there are more and more XviD > 1.x copies floating around. Thanks again for pointing us to that, we > really have to adress this soon. > > Best regards > > Christian > > From steve.lhomme at free.fr Mon Jul 19 10:05:29 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Mon, 19 Jul 2004 10:05:29 +0200 Subject: [Matroska-devel] New WavPack sources Message-ID: <40FB80C9.5030900@free.fr> From David Bryant : Hi, As promised, I have completed the work on WavPack 4.0 and uploaded the complete sources here: http://wavpack.com/sources4.zip This includes the complete sources for the command-line programs and the winamp, CoolEdit (Audition) and foobar plugins (including the "case" version that handles cuesheets). The foobar plugin uses the new reader-callback interface to the library, and all the plugins use the new "wputils.h" header file. I have also included the Linux makefiles (and all those other files I don't understand) and hopefully those will still build with a minimum of tweaking... smile.gif Assuming my testing goes well this week, this will become the real 4.0 release. Unfortunately (or "fortunately", according to my wife) I have some "real" work to do for a couple days, but I will try to squeeze in creating the parser and interface description very soon. As always, thanks... David The wputils interface should be the one needed to integrate WavPack in Matroska or/and DirectShow! -- robUx4 on blog From steve.lhomme at free.fr Mon Jul 19 14:28:20 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Mon, 19 Jul 2004 14:28:20 +0200 Subject: [Matroska-devel] Missing spec file Message-ID: <40FBBE64.302@free.fr> Hi, I've been checking the dead links on the site. Appart from some older binary/source releases not available for the moment (anymore?) we really miss the following file : http://www.matroska.org/technical/specs/subtitles/vobsubs.html I guess it describes how VobSubs are muxed into Matroska. Does anyone have such a file on his/her HD ? thx -- robUx4 on blog From moritz at bunkus.org Mon Jul 19 14:39:03 2004 From: moritz at bunkus.org (Moritz Bunkus) Date: Mon, 19 Jul 2004 14:39:03 +0200 Subject: [Matroska-devel] Missing spec file In-Reply-To: <40FBBE64.302@free.fr> References: <40FBBE64.302@free.fr> Message-ID: <20040719123903.GQ18991@bunkus.org> Hi, > http://www.matroska.org/technical/specs/subtitles/vobsubs.html I definitely do not have it, nor do I have it in my backup. Sorry. 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 steve.lhomme at free.fr Mon Jul 19 14:49:02 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Mon, 19 Jul 2004 14:49:02 +0200 Subject: [Matroska-devel] Re: Missing spec file In-Reply-To: <20040719123903.GQ18991@bunkus.org> References: <40FBBE64.302@free.fr> <20040719123903.GQ18991@bunkus.org> Message-ID: <40FBC33E.6080308@free.fr> Moritz Bunkus a ?crit : > Hi, > > >>http://www.matroska.org/technical/specs/subtitles/vobsubs.html > > > I definitely do not have it, nor do I have it in my backup. Sorry. As it seems to be just the Images page with another name I have removed all bogus links to that page. -- robUx4 on blog From steve.lhomme at free.fr Tue Jul 20 09:59:03 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Tue, 20 Jul 2004 09:59:03 +0200 Subject: [Matroska-devel] Wavpack in Matroska Message-ID: <40FCD0C7.6000307@free.fr> David has published a document that should make it easier to understand Wavpack to use it in a container. http://wavpack.com/lib_use.txt -- robUx4 on blog From steve.lhomme at free.fr Tue Jul 20 19:32:10 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Tue, 20 Jul 2004 19:32:10 +0200 Subject: [Matroska-devel] Stats of www.matroska.org In-Reply-To: <40F66E1D.60607@free.fr> References: <40F66E1D.60607@free.fr> Message-ID: <40FD571A.9040307@free.fr> Steve Lhomme a ?crit : > Those of you who would like to get the statistics on the websites hosted > by Haali can have a look here : > > > Only people that have an authorized access are able to check this (that > includes the musepack boys). > > The stats are not generated everyday, but on demand: you just click on > do.php or do-1.3.php (for the Apache 1.3 stats, the one currently in use). > > The stats are still buggy (no session tracking, no count of visits, > hardly copes with virtual hosts), but it's still good. For example it is > very useful to look at the search engine entries. This way we know what > people are looking for when they come. > > On that topic it seems from the main page we should have a direct link > to because a lot of people are looking for > this. And on various forums it seems people are confused when trying to > play RV in MKV. So we might add a bigger notice on how to play back RV > content (either on the site or in the pack). I added AWStats as a log analyzer option. It gives more details and less errors about what's going on in each site (a page for each virtual host). You can update the page live as well. -- robUx4 on blog From steve.lhomme at free.fr Wed Jul 21 10:41:39 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Wed, 21 Jul 2004 10:41:39 +0200 Subject: [Matroska-devel] More wavpack... Message-ID: <40FE2C43.5090606@free.fr> David made a simple code example to parse WavPack files... http://wavpack.com/wvparser.c -- robUx4 on blog From agebosma at home.nl Sat Jul 24 10:21:18 2004 From: agebosma at home.nl (Age Bosma) Date: Sat, 24 Jul 2004 10:21:18 +0200 Subject: [Matroska-devel] TODO In-Reply-To: <40F2FD18.7060604@free.fr> References: <40F2FD18.7060604@free.fr> Message-ID: <41021BFE.4060502@home.nl> Steve Lhomme wrote: > I've posted the list of current known TODO on the website : > http://www.matroska.org/team/todo.html > > This page should be cleaned up and integrated in the rest of the site. > Feel free to add your ideas and remove the things that are done. (I will > do my part tomorrow) > In the Tags section it states: "update a compatibility matrix with other existing tag systems.". Since I created the document it links to in the fist place and becuase I will update it anyway I'm OK with doing that part to add to the Matroksa site. I made some changes in the past few day as well and please note that I changed the location of the document. It should be http://hobba.hobba.nl/audio/tag_frame_reference.html. What "other existing tag systems" are you thinking about? Personally I would like to add Dublin Core tags. What others did you have in mind? Cheers, Prodoc From steve.lhomme at free.fr Sat Jul 24 11:32:31 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Sat, 24 Jul 2004 11:32:31 +0200 Subject: [Matroska-devel] TODO In-Reply-To: <41021BFE.4060502@home.nl> References: <40F2FD18.7060604@free.fr> <41021BFE.4060502@home.nl> Message-ID: <41022CAF.1080807@free.fr> Age Bosma a ?crit : > Steve Lhomme wrote: > >> I've posted the list of current known TODO on the website : >> http://www.matroska.org/team/todo.html >> >> This page should be cleaned up and integrated in the rest of the site. >> Feel free to add your ideas and remove the things that are done. (I >> will do my part tomorrow) >> > > In the Tags section it states: "update a compatibility matrix with other > existing tag systems.". Since I created the document it links to in the > fist place and becuase I will update it anyway I'm OK with doing that > part to add to the Matroksa site. > I made some changes in the past few day as well and please note that I > changed the location of the document. It should be > http://hobba.hobba.nl/audio/tag_frame_reference.html. > > What "other existing tag systems" are you thinking about? Personally I > would like to add Dublin Core tags. What others did you have in mind? > > Cheers, Hi, Thanks a lot for the offer. Yes, your help would be appreciated. The website is now maintained by SVN (a bit similar to what CVS do) and automatically updated from there. So if you want to be able to put your file there, you just need an account that I can create for you (I just need your login ID). The right location for this document would probably be in www.matroska.org/data/technical/specs/tagging/ DublinCore would be nice indeed ! And on this page there are other ones already in comparison : http://www.matroska.org/technical/specs/tagging/othertagsystems/comparetable.html -- robUx4 on blog From agebosma at home.nl Sat Jul 24 12:37:52 2004 From: agebosma at home.nl (Age Bosma) Date: Sat, 24 Jul 2004 12:37:52 +0200 Subject: [Matroska-devel] TODO In-Reply-To: <41022CAF.1080807@free.fr> References: <40F2FD18.7060604@free.fr> <41021BFE.4060502@home.nl> <41022CAF.1080807@free.fr> Message-ID: <41023C00.1000001@home.nl> Steve Lhomme wrote: > The website is now maintained by SVN (a bit similar to what CVS do) and > automatically updated from there. So if you want to be able to put your > file there, you just need an account that I can create for you (I just > need your login ID). > I haven't got any experience on this CVS and SVN stuff at all. I know what both are but I think I will need some help on how to use it. You can use my nickname Prodoc as a login ID. > The right location for this document would probably be in > www.matroska.org/data/technical/specs/tagging/ > > DublinCore would be nice indeed ! And on this page there are other ones > already in comparison : > http://www.matroska.org/technical/specs/tagging/othertagsystems/comparetable.html > Is it possible that this is a very old out dated document? I recall an excel file I got from Paul when I started creating my reference which looks a lot like this comparison table. If that's the case than this document won't be much help. Do all the tag sets from this document realy need to be included in the final comparison reference? It seems to me that they won't realy contribute anything. Adding e.g. pre ID3v2.4.0 tags in a seperate column would be a bit overkill imo. The same goes for APEv1. What are Extended INFO tags? I'll start with adding RIFF and DublinCore tags. I was thinking about adding MPEG-7 tags as well, since these are the official tags which should be used for e.g. mp4, but it's almost impossible to perform an accurate mapping to those tags. Cheers, Prodoc From steve.lhomme at free.fr Sun Jul 25 13:20:10 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Sun, 25 Jul 2004 13:20:10 +0200 Subject: [Matroska-devel] Re: libebml and libmatroska 0.7.1 released In-Reply-To: <20040725111035.GL20225@bunkus.org> References: <20040725111035.GL20225@bunkus.org> Message-ID: <4103976A.8030807@free.fr> Moritz Bunkus a ?crit : > Heya, > > we've just released small updates for libebml and libmatroska. Both are > at v0.7.1 and can be downloaded from > http://dl.matroska.org/downloads/libebml/ and > http://dl.matroska.org/downloads/libmatroska/ > > Binary packages for Debian/Unstable, RedHat and SuSE are available from > my mkvtoolnix homepage at http://www.bunkus.org/videotools/mkvtoolnix/ > > There was practically only one bug fix in the EBML libraries that > prevented comparisons of UTFstring objects with the == operator from > working. mkvtoolnix 0.9.4 needs these new versions. > > Have fun. Was it necessary to release libmatroska too ? As nothing in the code has changed. -- robUx4 on blog From moritz at bunkus.org Sun Jul 25 13:33:05 2004 From: moritz at bunkus.org (Moritz Bunkus) Date: Sun, 25 Jul 2004 13:33:05 +0200 Subject: [Matroska-devel] Re: libebml and libmatroska 0.7.1 released In-Reply-To: <4103976A.8030807@free.fr> References: <20040725111035.GL20225@bunkus.org> <4103976A.8030807@free.fr> Message-ID: <20040725113305.GN20225@bunkus.org> Hi, > Was it necessary to release libmatroska too ? As nothing in the code has > changed. Hmm you're right, of course. Too late now, sorry. 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 salo at Xtrmntr.org Tue Jul 27 06:37:02 2004 From: salo at Xtrmntr.org (Lubomir Sedlacik) Date: Tue, 27 Jul 2004 06:37:02 +0200 Subject: [Matroska-devel] simple fix to test/mux/test8.cpp for NetBSD Message-ID: <20040727043702.GA10739@Xtrmntr.org> hi, attached is a trivial fix from pkgsrc to compile test8.cpp on NetBSD. regards, -- -- Lubomir Sedlacik -- -------------- next part -------------- $NetBSD: patch-aa,v 1.2 2004/07/27 04:14:56 salo Exp $ --- test/mux/test8.cpp.orig 2004-07-09 23:05:36.000000000 +0200 +++ test/mux/test8.cpp 2004-07-27 05:57:12.000000000 +0200 @@ -273,7 +273,7 @@ } else if (EbmlId(*ElementLevel2) == KaxMuxingApp::ClassInfos.GlobalId) { KaxMuxingApp *pApp = static_cast(ElementLevel2); pApp->ReadData(aStream.I_O()); -#if !defined(__CYGWIN__) && !defined(__APPLE__) && !defined(__BEOS__) +#if !defined(__CYGWIN__) && !defined(__APPLE__) && !defined(__BEOS__) && !defined(__NetBSD__) wprintf(L"Muxing App : %ls\n", UTFstring(*pApp).c_str()); #else printf("Muxing App : %s\n", UTFstring(*pApp).c_str()); @@ -281,7 +281,7 @@ } else if (EbmlId(*ElementLevel2) == KaxWritingApp::ClassInfos.GlobalId) { KaxWritingApp *pApp = static_cast(ElementLevel2); pApp->ReadData(aStream.I_O()); -#if !defined(__CYGWIN__) && !defined(__APPLE__) && !defined(__BEOS__) +#if !defined(__CYGWIN__) && !defined(__APPLE__) && !defined(__BEOS__) && !defined(__NetBSD__) wprintf(L"Writing App : %ls (????)\n", UTFstring(*pApp).c_str()); #else printf("Writing App : %s (????)\n", UTFstring(*pApp).c_str()); @@ -600,7 +600,7 @@ unsigned int Index4; for (Index4 = 0; Index4Generic().GlobalId == KaxChapterString::ClassInfos.GlobalId) { -#if !defined(__CYGWIN__) && !defined(__APPLE__) && !defined(__BEOS__) +#if !defined(__CYGWIN__) && !defined(__APPLE__) && !defined(__BEOS__) && !defined(__NetBSD__) wprintf(L" Display \"%s\"\n", UTFstring(*static_cast(aDisplay[Index4])).c_str() ); #else printf(" Display \"%s\"\n", UTFstring(*static_cast(aDisplay[Index4])).c_str() ); -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From moritz at bunkus.org Tue Jul 27 10:02:01 2004 From: moritz at bunkus.org (Moritz Bunkus) Date: Tue, 27 Jul 2004 10:02:01 +0200 Subject: [Matroska-devel] simple fix to test/mux/test8.cpp for NetBSD In-Reply-To: <20040727043702.GA10739@Xtrmntr.org> References: <20040727043702.GA10739@Xtrmntr.org> Message-ID: <20040727080201.GH8684@bunkus.org> Hi, applied, thanks. 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 nleguen at pepper-prod.com Fri Jul 30 11:13:48 2004 From: nleguen at pepper-prod.com (Nicolas Le Guen) Date: Fri, 30 Jul 2004 11:13:48 +0200 Subject: [Matroska-devel] ORIGINAL_TITLE tag name Message-ID: <410A114C.5080401@pepper-prod.com> Hi, I just wonder if the ORIGINAL_TITLE tag name is correct: According to http://hobba.hobba.nl/audio/tag_frame_reference.html this tag is "Original album/movie/show title". So, I guess we have to use this tag for the original title of a movie in the case of a remake for example. In this case it is correct, but what tag do we have to use to specify that one of the songs of an audio compilation (in a mka file) was originaly on album x? Don't the ORIGINAL_ALBUM="x" tag would be more convenient (an explicit) in this case? (ID3v2 tag for that is ORIGALBUM so...) What's your opinion on this? :-) From agebosma at home.nl Fri Jul 30 17:13:30 2004 From: agebosma at home.nl (Age Bosma) Date: Fri, 30 Jul 2004 17:13:30 +0200 Subject: [Matroska-devel] ORIGINAL_TITLE tag name In-Reply-To: <410A114C.5080401@pepper-prod.com> References: <410A114C.5080401@pepper-prod.com> Message-ID: <410A659A.1050607@home.nl> Nicolas Le Guen wrote: > Hi, > I just wonder if the ORIGINAL_TITLE tag name is correct: According to > http://hobba.hobba.nl/audio/tag_frame_reference.html this tag is > "Original album/movie/show title". So, I guess we have to use this tag > for the original title of a movie in the case of a remake for example. > In this case it is correct, but what tag do we have to use to specify > that one of the songs of an audio compilation (in a mka file) was > originaly on album x? Don't the ORIGINAL_ALBUM="x" tag would be more > convenient (an explicit) in this case? (ID3v2 tag for that is ORIGALBUM > so...) > What's your opinion on this? :-) > A suggestion I made before, and as far as I know was being generally accepted, was that we should introduce a "ORIGINAL" sublevel to be able to nest every available tag. This way all ORIGINAL_X tags can be left out of the Matroska tag set and it allows you to specify every bit of original info. The only thing is that it hasn't been completely work out yet but as far as I can see it won't cause any problems in the current tag system. I'm I wrong about this? Cheers, Prodoc From nleguen at pepper-prod.com Fri Jul 30 23:38:50 2004 From: nleguen at pepper-prod.com (Nicolas Le Guen) Date: Fri, 30 Jul 2004 23:38:50 +0200 Subject: [Matroska-devel] ORIGINAL_TITLE tag name In-Reply-To: <410A659A.1050607@home.nl> References: <410A114C.5080401@pepper-prod.com> <410A659A.1050607@home.nl> Message-ID: <410ABFEA.5000107@pepper-prod.com> So ORIGINAL_ALBUM is the way to go... I keep it :-) > A suggestion I made before, and as far as I know was being generally > accepted, was that we should introduce a "ORIGINAL" sublevel to be > able to nest every available tag. This way all ORIGINAL_X tags can be > left out of the Matroska tag set and it allows you to specify every > bit of original info. > The only thing is that it hasn't been completely work out yet but as > far as I can see it won't cause any problems in the current tag > system. I'm I wrong about this? > > Cheers, > > Prodoc > _______________________________________________ > Matroska-devel mailing list > Matroska-devel at lists.matroska.org > http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel > > From agebosma at home.nl Sat Jul 31 01:54:35 2004 From: agebosma at home.nl (Age Bosma) Date: Sat, 31 Jul 2004 01:54:35 +0200 Subject: [Matroska-devel] ORIGINAL_TITLE tag name In-Reply-To: <410ABFEA.5000107@pepper-prod.com> References: <410A114C.5080401@pepper-prod.com> <410A659A.1050607@home.nl> <410ABFEA.5000107@pepper-prod.com> Message-ID: <410ADFBB.60804@home.nl> Nicolas Le Guen wrote: > So ORIGINAL_ALBUM is the way to go... I keep it :-) > Like I said, I think we shouldn't add any ORIGINAL_x tags. That way we should add loads of ORIGINAL_x tags for almost every tag which would be really overkill. If we instead introduce a ORIGINAL sublevel tag we won't need it in the first place. This can be done in different ways but I'm not sure what would be best from a usability and programmers point of view: - ALBUM -- ORIGINAL - TITLE -- ORIGINAL or - ALBUM - TITLE - ORIGINAL -- ALBUM -- TITLE As another option, which I'm personally against but should be taken under consideration as well, we could also say that it's allowed to add ORIGINAL_ in front of every tag. This way we can also remove all the ORIGINAL_x tags from the specs. In this case current tags like DATE_RELEASE_ORIGINAL, would become ORIGINAL_DATE_RELEASE. Prodoc From agebosma at home.nl Sat Jul 31 01:59:56 2004 From: agebosma at home.nl (Age Bosma) Date: Sat, 31 Jul 2004 01:59:56 +0200 Subject: [Matroska-devel] Re: matroska tags In-Reply-To: <410AC24B.1090908@matroska.org> References: <410AC24B.1090908@matroska.org> Message-ID: <410AE0FC.9020102@home.nl> Goldenear wrote: > By the way, is the COMMENTS tag in Matroska really COMMENTS and not > COMMENT ? All the other format use COMMENT so I'm very surprised that > Matroska doesn't do the same ;-) > When I started helping out Pamel, who originally started working on the tag set this tag was already included as is. I mentioned this before as well but after that post Pamel wasn't able to contribute to Matroska (and respond) for a while. Imo this should be changed as well. Prodoc From nleguen at pepper-prod.com Sat Jul 31 02:52:42 2004 From: nleguen at pepper-prod.com (Nicolas Le Guen) Date: Sat, 31 Jul 2004 02:52:42 +0200 Subject: [Matroska-devel] ORIGINAL_TITLE tag name In-Reply-To: <410ADFBB.60804@home.nl> References: <410A114C.5080401@pepper-prod.com> <410A659A.1050607@home.nl> <410ABFEA.5000107@pepper-prod.com> <410ADFBB.60804@home.nl> Message-ID: <410AED5A.9090909@pepper-prod.com> Oops, I'm sorry, I had not well understand your first reply ... I belived that, when you were speaking about an ORIGINAL sublevel, it was you third solution here :-) So what you mean is that you would rather use nested tags. But adding ORIGINAL_ in front of every tag is a lot more simple: indeed, many software won't easily use or support nested tags :-( Moreover, IMHO nested tags, if used, should be used in an other way: - ALBUM - TITLE -DATE - ORIGINAL_ALBUM -- DATE -- PUBLISHER For all this reasons, I guess your third solution is the best ... and easiest way to go ;-) Goldenear Age Bosma wrote : > Like I said, I think we shouldn't add any ORIGINAL_x tags. That way we > should add loads of ORIGINAL_x tags for almost every tag which would > be really overkill. If we instead introduce a ORIGINAL sublevel tag we > won't need it in the first place. > > This can be done in different ways but I'm not sure what would be best > from a usability and programmers point of view: > > - ALBUM > -- ORIGINAL > - TITLE > -- ORIGINAL > > or > > - ALBUM > - TITLE > - ORIGINAL > -- ALBUM > -- TITLE > > As another option, which I'm personally against but should be taken > under consideration as well, we could also say that it's allowed to > add ORIGINAL_ in front of every tag. This way we can also remove all > the ORIGINAL_x tags from the specs. In this case current tags like > DATE_RELEASE_ORIGINAL, would become ORIGINAL_DATE_RELEASE. > > Prodoc > _______________________________________________ > Matroska-devel mailing list > Matroska-devel at lists.matroska.org > http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel > > From steve.lhomme at free.fr Sat Jul 31 11:42:40 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Sat, 31 Jul 2004 11:42:40 +0200 Subject: [Matroska-devel] Multiple CDs in MKA Message-ID: <410B6990.20709@free.fr> Hi, I was thinking about this "many CDs in one MKA file" feature. It would be nice for some albums or compilations (you move one file the same way you move the CD). We have been thinking about using editions to distinguish the different CDs. But I'm not sure it's the right way to do it. Editions are meant to describe the same content but with variations (mostly chapters, hidden parts and control tracks). They are not meant to describe non-overlapping parts of the same segment. For that there are chapters, and subchapters (and subsubchapters). So I think each CD should be a large chapter, each track a subchapter of this chapter and the possible indexes are subsubchapters. This seems logical to me since nothing is overlapping at this level. Of course if there is just one CD, you can remove one level. And for one track you can also remove one level. When joining files you should a level: tracks -> CD, CDs -> CD-set. That looks like a logical form to me. Any suggestions or ideas ? Mosu suggested we should do a document describing how CD-in-MKA is done. That could help both developpers and users understand it. Goldenear ? Do you feel like doing it ? -- robUx4 on blog From steve.lhomme at free.fr Sat Jul 31 11:47:05 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Sat, 31 Jul 2004 11:47:05 +0200 Subject: [Matroska-devel] ORIGINAL_TITLE tag name In-Reply-To: <410ADFBB.60804@home.nl> References: <410A114C.5080401@pepper-prod.com> <410A659A.1050607@home.nl> <410ABFEA.5000107@pepper-prod.com> <410ADFBB.60804@home.nl> Message-ID: <410B6A99.4030402@free.fr> Age Bosma a ?crit : > Nicolas Le Guen wrote: > >> So ORIGINAL_ALBUM is the way to go... I keep it :-) >> > > Like I said, I think we shouldn't add any ORIGINAL_x tags. That way we > should add loads of ORIGINAL_x tags for almost every tag which would be > really overkill. If we instead introduce a ORIGINAL sublevel tag we > won't need it in the first place. > > This can be done in different ways but I'm not sure what would be best > from a usability and programmers point of view: > > - ALBUM > -- ORIGINAL > - TITLE > -- ORIGINAL I like this one. But before we proceed I think we should make clear what "ORIGINAL" stands for. Is it about a remake or just the way you ripped/bought the file ? The specs should be clear about that. (I haven't read them) -- robUx4 on blog From steve.lhomme at free.fr Sat Jul 31 11:48:33 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Sat, 31 Jul 2004 11:48:33 +0200 Subject: [Matroska-devel] Re: matroska tags In-Reply-To: <410AE0FC.9020102@home.nl> References: <410AC24B.1090908@matroska.org> <410AE0FC.9020102@home.nl> Message-ID: <410B6AF1.2080909@free.fr> Age Bosma a ?crit : > Goldenear wrote: > >> By the way, is the COMMENTS tag in Matroska really COMMENTS and not >> COMMENT ? All the other format use COMMENT so I'm very surprised that >> Matroska doesn't do the same ;-) >> > > When I started helping out Pamel, who originally started working on the > tag set this tag was already included as is. > I mentioned this before as well but after that post Pamel wasn't able to > contribute to Matroska (and respond) for a while. > Imo this should be changed as well. From my past understanding, COMMENTS contains sub-elements. That means you can put more than one comment in different languages in it (IIRC). -- robUx4 on blog From steve.lhomme at free.fr Sat Jul 31 11:51:14 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Sat, 31 Jul 2004 11:51:14 +0200 Subject: [Matroska-devel] ORIGINAL_TITLE tag name In-Reply-To: <410AED5A.9090909@pepper-prod.com> References: <410A114C.5080401@pepper-prod.com> <410A659A.1050607@home.nl> <410ABFEA.5000107@pepper-prod.com> <410ADFBB.60804@home.nl> <410AED5A.9090909@pepper-prod.com> Message-ID: <410B6B92.1090707@free.fr> Nicolas Le Guen a ?crit : > Oops, I'm sorry, I had not well understand your first reply ... I > belived that, when you were speaking about an ORIGINAL sublevel, it was > you third solution here :-) > So what you mean is that you would rather use nested tags. But adding > ORIGINAL_ in front of every tag is a lot more simple: indeed, many > software won't easily use or support nested tags :-( We are trying to build the format without keeping bad legacies. That means if something is better in another unsupported way, it's the way to go. Even if it takes time to be implemented. Of course, when a solution is OK, there's no need to reinvent the wheel... On this particular issue, I'm undecided. :) -- robUx4 on blog From nleguen at pepper-prod.com Sat Jul 31 13:14:53 2004 From: nleguen at pepper-prod.com (Nicolas Le Guen) Date: Sat, 31 Jul 2004 13:14:53 +0200 Subject: [Matroska-devel] Multiple CDs in MKA In-Reply-To: <410B6990.20709@free.fr> References: <410B6990.20709@free.fr> Message-ID: <410B7F2D.7090100@pepper-prod.com> Steve Lhomme wrote: > Hi, > > I was thinking about this "many CDs in one MKA file" feature. It would > be nice for some albums or compilations (you move one file the same > way you move the CD). > > We have been thinking about using editions to distinguish the > different CDs. But I'm not sure it's the right way to do it. Editions > are meant to describe the same content but with variations (mostly > chapters, hidden parts and control tracks). They are not meant to > describe non-overlapping parts of the same segment. For that there are > chapters, and subchapters (and subsubchapters). So I think each CD > should be a large chapter, each track a subchapter of this chapter and > the possible indexes are subsubchapters. This seems logical to me > since nothing is overlapping at this level. Of course if there is just > one CD, you can remove one level. And for one track you can also > remove one level. When joining files you should a level: tracks -> CD, > CDs -> CD-set. That looks like a logical form to me. > > Any suggestions or ideas ? > > Mosu suggested we should do a document describing how CD-in-MKA is > done. That could help both developpers and users understand it. > Goldenear ? Do you feel like doing it ? > The Edition issues had been discussed yesterday on #matroska. It's seems to be the most logical way to go. And about what you say on using chapters and supchapters, it's a possibility indeed... But how would you distinguish if a top level chapter is really a normal chapter or is corresponding to a whole album (in a multiablum mka case). And in a single ablum mka case, where would you put global tags? This appears to me, more like a problem than like a solution ;-) Ok, we could in any case use a least one top level chapter to define the current CD and "attach" to this top lovel chapter all the global tags, including the MEDIA_PART tag. so we could considere that any top level chapter that has a MEDIA_PART tag is an album ... else it's a normal chapter. But won't the be confusing? About a guide about CD in MKA, I wand to 1) update my guide about it on HA 2) make a webpage with a more detailed version of this guide with screenshots :-) I'm just waiting everything to be standardized and fixed to do / publish it ;-) With all the work done recently about CD in MKA, I'm pretty sure MKA will become the standard way to archive audio CDs :-D From christian at matroska.org Sat Jul 31 14:39:48 2004 From: christian at matroska.org (ChristianHJW) Date: Sat, 31 Jul 2004 14:39:48 +0200 Subject: [Matroska-devel] Call for ideas : Video and Audio sinks for Gstreamer on Windows Message-ID: <410B9314.1010406@matroska.org> Hi folks, this is a call for ideas. It seems Steve has gstreamer and more than 60 plugins compiled and working on Windows, using MSVC 7. Now, i hope to get some interest from player developers to have their player based on it, covering the two most used platforms ( Linux and Windows ) with one single player this way. To be able to use gstreamer on Windows for a player, we need output sinks. How do we best do that ? DirectX ? Thanks for your input Christian matroska project admin BTW : I was first striked, then banned for a period of 30 days from doom9.org for having posted this here : http://forum.doom9.org/showthread.php?s=&threadid=80245 . Crazy place, isnt it ? From paul at msn.com Sat Jul 31 20:20:59 2004 From: paul at msn.com (Paul Bryson) Date: Sat, 31 Jul 2004 13:20:59 -0500 Subject: [Matroska-devel] Re: Multiple CDs in MKA References: <410B6990.20709@free.fr> <410B7F2D.7090100@pepper-prod.com> Message-ID: "Nicolas Le Guen" wrote... > Steve Lhomme wrote: > > Mosu suggested we should do a document describing how CD-in-MKA is > > done. That could help both developpers and users understand it. I have been advocating this for a long time. It really needs to be done if there is ever going to be widespread support for having a full CD in MKA. > The Edition issues had been discussed yesterday on #matroska. It's seems > to be the most logical way to go. > And about what you say on using chapters and supchapters, it's a > possibility indeed... But how would you distinguish if a top level > chapter is really a normal chapter or is corresponding to a whole album > (in a multiablum mka case). And in a single ablum mka case, where would > you put global tags? This appears to me, more like a problem than like a > solution ;-) While the Edition Entry stuff seems redundant, distinguishing chapters is certainly a valid concern. Perhaps some other method could be used to distinguish chapters? Atamido