From steve.lhomme at free.fr Fri Oct 1 12:23:28 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Fri, 01 Oct 2004 12:23:28 +0200 Subject: [Matroska-devel] Re: Dirac Video Codec In-Reply-To: References: Message-ID: <415D3020.9060109@free.fr> Hi again :) On a technical side, I just looked at some of your documentation about frames : http://www.bbc.co.uk/rd/projects/dirac/documentation/dirac_enhancements/080multi_ref.htm It seems you somehow use the same usual IPB frames principle but with additions on the possibilities. That's great because the frame reference we have designed allows the possibilities you are looking for. It can take care, at the container side, about complex references that are not possible with basic IPB frames (and therefore with most existing containers, if not all). In short, we can handle the number of frames that should be kept "in cache" and reference any frame that is in that cache during playback. The reference system is based on the timecode, to avoid problems in damaged streams. The frames have to be stored in coding order (always known before being referenced). And the seeking possibilities also take care of having the reference frames cached/seen, even though it's not displayed at the seek point. Tim Borer a ?crit : > Message body follows: > > Hi, > > I am the project manager for the Dirac Video Codec > (http://www.bbc.co.uk/rd/projects/dirac/ & > http://sourceforge.net/projects/dirac) > > Dirac is a pure video codec. But oviously we have aspirations > to stream it etc. To do so we will need a container format. > Possibilities are Ogg, MXF or Matroska. > > I writing to make initial contact. Would you be interested in > being able to wrap Dirac in Matroska? What would be the > advantages to us? What would we have to do to achieve this? > > Regards From the_Arioch at nm.ru Fri Oct 1 13:35:07 2004 From: the_Arioch at nm.ru (Arioch /BDV/) Date: Fri, 1 Oct 2004 15:35:07 +0400 Subject: [Matroska-devel] Re: Matroska + Delphi References: <40E2DF56.8020207@hrz.tu-chemnitz.de> Message-ID: The stars so gaily glistened... (Wed, 30 Jun 2004 17:42:14 +0200 @695) ...while the fading voice of Alexander whispered through the darkness: AN> http://www-user.tu-chemnitz.de/~noe/Video-Zeug/matroska_lib/index.html Hmm, but that refers to some non-standard matroska.dll What if i'd prefer stabdard libEbml.dll and libMatroska.dll ? Is there pre-compiled win32 standard dll's ? Is there Delphi headers for them ? (i mostly interested in EBML and maybe in Matroska as an example) -- http://Arioch.nm.ru/FL/Fidolook_SL.png Mail: the_Ariochnmru From steve.lhomme at free.fr Fri Oct 1 14:40:38 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Fri, 01 Oct 2004 14:40:38 +0200 Subject: [Matroska-devel] Re: Matroska + Delphi In-Reply-To: References: <40E2DF56.8020207@hrz.tu-chemnitz.de> Message-ID: <415D5046.7090809@free.fr> Arioch /BDV/ a ?crit : > The stars so gaily glistened... (Wed, 30 Jun 2004 17:42:14 +0200 @695) > ...while the fading voice of Alexander whispered through the darkness: > > AN> http://www-user.tu-chemnitz.de/~noe/Video-Zeug/matroska_lib/index.html > > Hmm, but that refers to some non-standard matroska.dll > > What if i'd prefer stabdard libEbml.dll and libMatroska.dll ? > > Is there pre-compiled win32 standard dll's ? > Is there Delphi headers for them ? > (i mostly interested in EBML and maybe in Matroska as an example) As libmatroska and libebml are written in C++, I doubt you can use them directly with Delphi as they are. You would probably need a C layer that doesn't exist now. There are other C implementations that might be used as DLLs. From the_Arioch at nm.ru Fri Oct 1 15:19:56 2004 From: the_Arioch at nm.ru (Arioch /BDV/) Date: Fri, 1 Oct 2004 17:19:56 +0400 Subject: [Matroska-devel] Re: Matroska + Delphi - wanting GStreamer/Win32 ? References: <40E2DF56.8020207@hrz.tu-chemnitz.de> <415D5046.7090809@free.fr> Message-ID: The stars so gaily glistened... (Fri, 01 Oct 2004 14:40:38 +0200 @569) ...while the fading voice of Steve whispered through the darkness: ??>> Is there pre-compiled win32 standard dll's ? ??>> Is there Delphi headers for them ? SL> As libmatroska and libebml are written in C++, I doubt you can use SL> them directly with Delphi as they are. Pity, but You're right. Shame on me, i missedthe obvious thing. SL> There are other C implementations that might be used as DLLs. For example, one told to be in GStreamer. And seems it is cinsidered quite ok. So, is it "Ronald S. Bultje" or someone else, who maintains GStreamer/Win32 ? Guess i need to ask them about DLL's :-) Should i try to crawl out into gstreamer.devel, or is he monitoring this list time to time ? -- ICQ - xmpp://arioch at jabber.ru http://Arioch.nm.ru/FL/Fidolook_SL.png Mail: the_Ariochnmru From steve.lhomme at free.fr Fri Oct 1 15:22:12 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Fri, 01 Oct 2004 15:22:12 +0200 Subject: [Matroska-devel] Re: Dirac Video Codec In-Reply-To: <5.2.0.9.2.20041001113442.0352e3a8@pop3> References: <5.2.0.9.2.20041001113442.0352e3a8@pop3> Message-ID: <415D5A04.3060204@free.fr> Tim Borer a ?crit : > Thanks for your quick reply. It looks like Matroska might be a good > thing to use - though we will have to read your documentation more > thoroughly. I've embedded some comments below. It's all on the website, but if you need more precision you can use our mailing list or our IRC channel (#matroska on irc.corecodec.com). > I guess one thing we need to know is what we need to do to integrate > Dirac with Matroska. We already have a C interface for the decoder and > are working on one for the encoder. These are only alpha and so the > details will change but the principle should be about right. We have > modelled them on C interfaces used for codecs in other libraries (e.g. > ffmpeg). For the moment there is only VirtualDubMod that can encode and save in matroska at the same time. You might be able to do it with GStreamer, but it's not (yet) guarantee to work. What we usually do it take an AVI file, RM or whatever and remux it to Matroska. There are 2 main tools for matroska that can do that : - mkvtoolnix : http://www.bunkus.org/videotools/mkvtoolnix/ - Avi-Mux GUI : http://www-user.tu-chemnitz.de/~noe/Video-Zeug/AVIMux%20GUI/index-eng.html But if you want to use some matroska specific features, you probably want to save to Matroska directly... You could make a plugin for GStreamer and use the Matroska muxer there. But as of now I'm sure the matroska features you need are not supported there... So the other option is to make a tool using your codec that can read/save natively in Matroska. Then mkvtoolnix and Avi-Mux GUI could be used to add extra features (that you probably don't want to support in an encoding tool) like chapters, tags, menus, etc. As libmatroska/libebml is in C++, using the STL it can probably integrated easily with your code. > At 12:23 01/10/2004 +0200, you wrote: > >I couldn't tell about MXF. All I know is that it's a professional > class container, but maybe not >good for everyday/basic use. > > Its a professional container. From our point of view it has problems in > getting additions agreed with the standards body (SMPTE). There are also Yes, that's one of the problems with big systems. They are not very responsive and sometimes not willing to do things for reasons other than technical ones :( We try to stay away from such problems as possible. > issues about the availability of open source libraries for it and their > limitations. > > Open source, freely available, cross platform is where we want to be. > > One question is can Matroska be used commercially as well as personally, > or are there intellectual property issues that would cause problems? Yes, all the code we (the core team) write is either LGPL. The code of other people (like the C implementation in GStreamer) is usually LGPL too. Mkvtoolnix and AVI-Mux GUI are GPL. About IPs, the format is free of use. We never checked for any patent. Maybe we infringe some, probably not. We don't have the money and/or time to check all patents in the world to be sure it's patent free. But since EBML is the basis of all we do and using a patent-free system (like Unicode encoding) I think it's quite safe. >> It seems you somehow use the same usual IPB frames principle but with >> additions on the possibilities. That's great because the frame >> reference we have designed allows the possibilities you are looking >> for. It can take care, at the container side, about complex references >> that are not possible with basic IPB frames (and therefore with most >> existing containers, if not all). > > > Sounds like this might be useful, although I though we needed to handle > this ourselves in an elementary stream to ensure that the stream could > be stand alone if required. Do you have a URL that would point to Yes. But it is very important to have this information available to the container (too). It's needed for precise seeking. It's also needed for "lossless" or "blind" editing (not modifying the codec data when inserting/cutting frames in a file). > information on this? I am in the process of drafting the Dirac bit > stream spec (what we use at present is ad hoc), so I've been thinking > about these issues. I don't think it's described well somewhere. It was done on a previous mailing lists which archives are not available anymore... And I never took the time to explain it in the specs, because it's quite a complex thing. Maybe it's time to do it... The elements involved in the specs http://www.matroska.org/technical/specs/ : - ReferencePriority : the priority of the element in the "cache", it can only replace elements of a bigger or same priority (or smaller, I never remember which one it is) - ReferenceBlock : can be multiple - MinCache - MaxCache >> In short, we can handle the number of frames that should be kept "in >> cache" and reference any frame that is in that cache during playback. >> The reference system is based on the timecode, to avoid problems in >> damaged streams. The frames have to be stored in coding order (always >> known before being referenced). And the seeking possibilities also >> take care of having the reference frames cached/seen, even though it's >> not displayed at the seek point. > > > I am wary about using time code. It works well for video at 24, 25 and > 30 frames per second. For NTSC at 30000/1001 (aprox 29.97) frames it is > bodged using drop frame. There is also confusion about streams which say > they are 29.97 when they may mean 30000/1001. The next result is that my > experience is that timecode is not as reliable as I would like. We don't care about frame rates. There is no frame rate in Matroska. That allows us to support VFR (Variable Frame Rate) easily, and dropped frames. > Therefore for Dirac we are planning to use sequential frame numbers > rather than time code. then you can keep accurate track of frames and > convert to a time code if required. What is you opinion on this? Well. My opinion is that a video codec should not have any knowledge about time. But in the other hand it's now needed for efficiency, because codecs now use it for motion compensation and stuff like that... In the other hand it's only needed at encoding time, not decoding (but maybe I'm wrong). So from the codec side, you only need to know which frame is used as a reference and which references a frame uses... That's the kind of thing that the container can give you, because it has to have such info (for reasons mentioned above like seeking and editing)... But I understand that the timecode format may not be efficient and usefull for you. Especially is the data are shifted in time for whatever reasons. So it makes sense for you to have your own reference system... And that's what MPEG codecs do when saved in Matroska. I suggest that your internal system should be designed to allow removing some frames from the stream and still be playable. You might want to keep a time reference to support VFR. So that when removing frames, you can still know which timecode you need to get for a reference frame... When saved in Matroska such a stream that would be edited (or decimated) would keep the needed frames intact (even if they shouldn't be displayed) and would feed the decoder with the right (only needed) frames when playing and/or seeking. From steve.lhomme at free.fr Fri Oct 1 17:49:38 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Fri, 01 Oct 2004 17:49:38 +0200 Subject: [Matroska-devel] Re: Matroska + Delphi - wanting GStreamer/Win32 ? In-Reply-To: References: <40E2DF56.8020207@hrz.tu-chemnitz.de> <415D5046.7090809@free.fr> Message-ID: <415D7C92.5070609@free.fr> Arioch /BDV/ a ?crit : > The stars so gaily glistened... (Fri, 01 Oct 2004 14:40:38 +0200 @569) > ...while the fading voice of Steve whispered through the darkness: > > ??>> Is there pre-compiled win32 standard dll's ? > ??>> Is there Delphi headers for them ? > > SL> As libmatroska and libebml are written in C++, I doubt you can use > SL> them directly with Delphi as they are. > > Pity, but You're right. Shame on me, i missedthe obvious thing. > > SL> There are other C implementations that might be used as DLLs. > > For example, one told to be in GStreamer. > And seems it is cinsidered quite ok. > > So, is it "Ronald S. Bultje" or someone else, who maintains GStreamer/Win32 ? > Guess i need to ask them about DLL's :-) > > Should i try to crawl out into gstreamer.devel, or is he monitoring this list time to time ? Ronald wrote it. But I'm the one working on the Win32 port. I've compiled GSTreamer and various plugins, including the matroska one. But It's not fully usable yet under Windows. It's too early... Maybe GStreamer could be used with Delphi. I just have no idea about that. Maybe you could give it a try under Linux with Kylix. From christophe.paris at free.fr Fri Oct 1 17:36:11 2004 From: christophe.paris at free.fr (Christophe PARIS) Date: Fri, 01 Oct 2004 17:36:11 +0200 Subject: [Matroska-devel] Re: Matroska + Delphi - wanting GStreamer/Win32 ? In-Reply-To: References: <40E2DF56.8020207@hrz.tu-chemnitz.de> <415D5046.7090809@free.fr> Message-ID: <415D796B.8070409@free.fr> I have started a delphi native matroska parser. It's the parser I use in MatroskaDiag : http://www.matroska.org/~toff/MatroskaDiag.exe It parse most of the thing but not the cluster, as I didn't need that yet :) So in the current status, you can't use it to make a demuxer, only to get info about a file. Sources are available here : http://www.matroska.org/~toff/MatroskaDiag_20041001_src.rar Maybe that coud give you some idea. It depends what you wanna do. Regards, Toff Arioch /BDV/ wrote: > The stars so gaily glistened... (Fri, 01 Oct 2004 14:40:38 +0200 @569) > ...while the fading voice of Steve whispered through the darkness: > > ??>> Is there pre-compiled win32 standard dll's ? > ??>> Is there Delphi headers for them ? > > SL> As libmatroska and libebml are written in C++, I doubt you can use > SL> them directly with Delphi as they are. > > Pity, but You're right. Shame on me, i missedthe obvious thing. > > SL> There are other C implementations that might be used as DLLs. > > For example, one told to be in GStreamer. > And seems it is cinsidered quite ok. > > So, is it "Ronald S. Bultje" or someone else, who maintains GStreamer/Win32 ? > Guess i need to ask them about DLL's :-) > > Should i try to crawl out into gstreamer.devel, or is he monitoring this list time to time ? From paul at msn.com Fri Oct 1 18:20:40 2004 From: paul at msn.com (Paul Bryson) Date: Fri, 1 Oct 2004 11:20:40 -0500 Subject: [Matroska-devel] Re: Dirac Video Codec References: <5.2.0.9.2.20041001113442.0352e3a8@pop3> <415D5A04.3060204@free.fr> Message-ID: "Steve Lhomme" wrote... Tim Borer a ?crit : > It's all on the website, but if you need more precision you can use our > mailing list or our IRC channel (#matroska on irc.corecodec.com). The mailing list is best for writing out points that require lengthy explanations. IRC on the other hand is very effective for a quick discussion about some point. You can usually get quick comments from multiple developers at once. > > I guess one thing we need to know is what we need to do to integrate > > Dirac with Matroska. We already have a C interface for the decoder and > > are working on one for the encoder. These are only alpha and so the > > details will change but the principle should be about right. We have > > modeled them on C interfaces used for codecs in other libraries (e.g. > > ffmpeg). There are currently several independently written Matroska writing libs that are free for use through GPL/LGPL licenses. You could certainly write directly to a file using one of these. Although in the long run I would imagine that it would probably be better to find a way to integrate into an existing media framework. Steve mentioned GStreamer and it probably has the best chances to be a real cross platform media encoding/playback system. But as also mentioned, you will likely need another tool to add some of the more advanced features. > > >I couldn't tell about MXF. All I know is that it's a professional class > > >container, but maybe not >good for everyday/basic use. > > > > Its a professional container. From our point of view it has problems in > > getting additions agreed with the standards body (SMPTE). There are also I had a look at MXF around a year and a half ago and even exchanged some emails with some of the people in the group. For some reason though they stopped responding and I became busy with other things. I had looked through some of their specification drafts and it looked like a good thing for large scale data imports. Basically just a good way to transfer data from one system to another. (Much like XML might be used to transfer data between different types of databases) When I went back to look at some things around 8 months ago I couldn't find any of their documents that I could look at for free. Maybe this has changed or maybe I just wasn't looking in the right place, but this made the format seem much less 'open'. (To me 'open' means anyone can look at the specs, not just people with money.) Fortunately I still had a copy of the drafts and was able to refer to that for what I was interested in. Regardless, MXF seems like overkill for what you want as it looks like you need a playback/authoring format. In regards to Ogg, it is a good format for basic streaming, but not much more. Also, any format that is put into Ogg basically has to be more or less approved by Xiph as there is not a 'standard' way of adding formats. In many ways it is the polar opposite of Matroska in philosophy in that almost no information is stored at the container level whereas Matroska stores as much information at the container level. For instance, you don't know the timecode of the data packet you are looking at without the codec in Ogg. > > issues about the availability of open source libraries for it and their > > limitations. > > > > Open source, freely available, cross platform is where we want to be. > > > > One question is can Matroska be used commercially as well as personally, > > or are there intellectual property issues that would cause problems? > > Yes, all the code we (the core team) write is either LGPL. The code of > other people (like the C implementation in GStreamer) is usually LGPL too. > Mkvtoolnix and AVI-Mux GUI are GPL. There are several independently written reading libraries that are all open. The official library libmatroska (C++), AVI-Mux GUI (Delphi), GStreamer (C), Mplayer which is somehow based on GStreamer (C), as well as some ones in development such as Javatroska (Java), RbMatroska (Ruby). There are probably others that I'm forgetting. > > Sounds like this might be useful, although I though we needed to handle > > this ourselves in an elementary stream to ensure that the stream could > > be stand alone if required. Do you have a URL that would point to > > Yes. But it is very important to have this information available to the > container (too). It's needed for precise seeking. It's also needed for > "lossless" or "blind" editing (not modifying the codec data when > inserting/cutting frames in a file). As he says, it is very useful to have as much data as possible available at the container level for authoring purposes. This is part of the philosophy of Matroska. > > I am wary about using time code. It works well for video at 24, 25 and > > 30 frames per second. For NTSC at 30000/1001 (aprox 29.97) frames it is > > bodged using drop frame. There is also confusion about streams which say > > they are 29.97 when they may mean 30000/1001. The next result is that my > > experience is that timecode is not as reliable as I would like. > > Therefore for Dirac we are planning to use sequential frame numbers > > rather than time code. then you can keep accurate track of frames and > > convert to a time code if required. What is you opinion on this? This is what MPEG currently does. It can only display a constant framerate and does not allow for dropped frames. Things get very interesting when you mix framerates. For instance, Star Trek TNG was filmed using standard NTSC speeds of around 30fps. But all of the scenes in space that were rendered on computers were rendered at film's 24fps. So when storing on a DVD, they use 30fps and have the 24fps images interpolated to 30fps. (Maybe you already know how they do this, if it's important to you I could explain it.) In our view this seems a little silly. During playback, all systems convert to a timecode anyway. DirectShow uses a 100ns accuracy timecode. Matroska can handle accuracy up to 1ns internally, but typical Matroska video files are stored with 1ms accuracy. (It is fully adjustable for what is needed.) Granted this will produce timecodes that have error of <1ms from what was originally used (Ex: 5370 * 30000/1001 for the timecode of frame 5370). But keep in mind that the effect is not cumulative. Each frames timecode is calculated individually. So no timecode would have an error that is more than <1ms for typical 1ms accuracy files. While the idea of introducing a level of 'error' into the timecode can seem like a bad thing, having a frame off by 0.5ms is less than the total time that it would be off due to typical display processes. There are also some advantages. VFR (Variable Frame Rate). Vorbis is Xiph's free general audio codec. Ogg was designed for it, but it is also usable in Matroska. The number of samples in a Vorbis packet are variable. One might have 1000 samples and another might have 300. (I can't recall real numbers you would see.) So the length of time that one packet covers is not the same as another. This introduces issues in systems that demand a constant rate of packets, or CFR(Constant Frame Rate). Because Matroska simply attaches a timecode to the packet, this is not an issue. Now to extend this idea a little further. This may require a bit of thought as the world of video has been a CFR place for so long that it is difficult for people to grasp the idea that it could be done differently. Because of timecodes, we don't have to be dependant on a specific framerate. Instead we can record video frames as they come in. If one video frame lasts 37ms, and the next lasts 283ms, its not an issue. This also gives you the option that if you have a very low motion scene in video, you could dither the frames together and instead of storing them at 30fps, you could store them at 23fps. Completely optional depending on your codec and the level of compression you are seeking. This also gives many options for authoring as well. If you want to speed up a sequence of frames or slow them down, there is no reason to reencode them and lose efficiency. Simply adjust the timecodes to put the frames closer together or further apart. I have a tool that lets me edit Matroska files by cutting, offsetting audio/video, and appending streams. Because all of the data is at the container level, the tool is able to do this no matter what codec was used on the audio or video. This is also a huge boon in the ability to maintain audio and video synchronization in the event of an error. If there is data corruption in a Matroska file, the next audio and video packets to be found will have timecodes. Instead of the application having to guess at the timing of the packets relative to each other, it can instead know for certain because it knows exactly when a packet should be displayed or played. While I have seen many AVI and MPEG files lose A/V sync for various reasons, I have never seen this happen to a Matroska file. Here is an example video sequence that shows the exact same sequence of frames, but with the timecodes adjusted so that the video moves at different speeds. http://commo.de/3blocks-vfr.mkv Paul Bryson From paul at msn.com Fri Oct 1 21:54:05 2004 From: paul at msn.com (Paul Bryson) Date: Fri, 1 Oct 2004 14:54:05 -0500 Subject: [Matroska-devel] Re: Dirac Video Codec References: <5.2.0.9.2.20041001113442.0352e3a8@pop3><415D5A04.3060204@free.fr> Message-ID: "Paul Bryson" wrote... > There are several independently written reading libraries that are all > open. The official library libmatroska (C++), AVI-Mux GUI (Delphi) Sorry, that library is a C++ library with a Delphi interface. > While I have seen many AVI and MPEG files lose A/V sync for various > reasons, All of the desync issues I've seen in MPEG have been in either damaged satellite feeds or damaged DVDs. Seeking lets them resync. Paul Bryson From rbultje at ronald.bitfreak.net Sat Oct 2 15:38:54 2004 From: rbultje at ronald.bitfreak.net (Ronald S. Bultje) Date: Sat, 02 Oct 2004 15:38:54 +0200 Subject: [gst-devel] Re: [Matroska-devel] Re: Matroska + Delphi - wanting GStreamer/Win32 ? In-Reply-To: <415D7C92.5070609@free.fr> References: <40E2DF56.8020207@hrz.tu-chemnitz.de> <415D5046.7090809@free.fr> <415D7C92.5070609@free.fr> Message-ID: <1096724333.13781.3.camel@localhost.localdomain> Hi, On Fri, 2004-10-01 at 17:49, Steve Lhomme wrote: > Arioch /BDV/ a ?crit : > > SL> There are other C implementations that might be used as DLLs. > > > > For example, one told to be in GStreamer. > > And seems it is cinsidered quite ok. > > > > So, is it "Ronald S. Bultje" or someone else, who maintains GStreamer/Win32 ? > > Guess i need to ask them about DLL's :-) > > > > Should i try to crawl out into gstreamer.devel, or is he monitoring this list time to time ? > > Ronald wrote it. But I'm the one working on the Win32 port. I've > compiled GSTreamer and various plugins, including the matroska one. But > It's not fully usable yet under Windows. It's too early... Just to confirm both; I monitor the matroska-devel mailinglist, and I wrote the demuxer, but I can't provide DLLs because I do not have access to any Windows machine. Steve is the person to ask for all GStreamer/Win32-related questions. You can, of course, ask me about bugs and anything in the code and I'll happily answer any other questions that you might have. Ronald -- Ronald S. Bultje From dgp85 at users.sourceforge.net Sun Oct 3 14:05:25 2004 From: dgp85 at users.sourceforge.net (Diego 'Flameeyes' =?ISO-8859-1?Q?Petten=F2?=) Date: Sun, 03 Oct 2004 14:05:25 +0200 Subject: [Matroska-devel] Re: Errors on tests' compiling [Was: Re: libebml documentation] References: <10871895.velfQh5VnQ@flameeyes.is-a-geek.org> <41586F9E.9000709@free.fr> Message-ID: <5175096.0VxRFhjJky@flameeyes.is-a-geek.org> Diego 'Flameeyes' Petten? wrote: > Instead trying to compile libmatroska under macos using the gentoo for > osx support, I have a lot of errors stating > /usr/include/ebml/IOCallback.h:89: error: template with C linkage > /usr/include/ebml/IOCallback.h:93: error: template with C linkage Ok I found out this problem. Unfortunately is a GCC's bug on darwin/macos version, the bug #15834 (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15834), and I haven't found a walkthrough for this at the moment. The strange fact is that also one of my software that I recently ported to automake chain now doesn't compile, but it compiled just fine using some makefiles hand-edited. I'm searchig if there's a way to install gcc 3.4 on MacOSX to have it working right. HTH, -- Diego "Flameeyes" Petten? dgp85 at users.sourceforge.net - http://flameeyes.web.ctonet.it/ From the_Arioch at nm.ru Mon Oct 4 09:11:35 2004 From: the_Arioch at nm.ru (Arioch /BDV/) Date: Mon, 4 Oct 2004 11:11:35 +0400 Subject: [Matroska-devel] Re: Matroska + Delphi - wanting GStreamer/Win32 ? References: <40E2DF56.8020207@hrz.tu-chemnitz.de> <415D5046.7090809@free.fr> <415D796B.8070409@free.fr> Message-ID: The stars so gaily glistened... (Fri, 01 Oct 2004 17:36:11 +0200 @691) ...while the fading voice of Christophe whispered through the darkness: CP> Maybe that coud give you some idea. Thank You. CP> It depends what you wanna do. I am not sure still :-) But it should not be read-only parser. -- ICQ - xmpp://arioch at jabber.ru xmpp://93438391 at icq.jabber.ru http://Arioch.nm.ru/FL/Fidolook_SL.png Mail: the_Ariochnmru From the_Arioch at nm.ru Mon Oct 4 09:31:09 2004 From: the_Arioch at nm.ru (Arioch /BDV/) Date: Mon, 4 Oct 2004 11:31:09 +0400 Subject: [Matroska-devel] Re: Matroska + Delphi - wanting GStreamer/Win32 ? References: <40E2DF56.8020207@hrz.tu-chemnitz.de> <415D5046.7090809@free.fr> <415D7C92.5070609@free.fr> <1096724333.13781.3.camel@localhost.localdomain> Message-ID: The stars so gaily glistened... (Sat, 02 Oct 2004 15:38:54 +0200 @610) ...while the fading voice of Ronald whispered through the darkness: ??>> Ronald wrote it. But I'm the one working on the Win32 port. I've ??>> compiled GSTreamer and various plugins, including the matroska one. ??>> But It's not fully usable yet under Windows. It's too early... I think about generic ebml, so if this plugin is ready for ebml, but not yet matroska - it is ok to me. Pity if EBML code is hidden within, so it is Matroska-only. RSB> Just to confirm both; I monitor the matroska-devel mailinglist, and I RSB> wrote the demuxer, but I can't provide DLLs because I do not have RSB> access to any Windows machine. Steve is the person to ask for all RSB> GStreamer/Win32-related questions. You can, of course, ask me about RSB> bugs and anything in the code and I'll happily answer any other RSB> questions that you might have. So i unkindly ask You :-) Can You make ebml/mkv code as a separate library with more or less documented API ? Can Steve then build this library as DLL for Win32 ? Will this DLL (SO) be usable as EBML parser/composer, or will it oly handle MKV ? -- ICQ - xmpp://arioch at jabber.ru http://Arioch.nm.ru/FL/Fidolook_SL.png Mail: the_Ariochnmru From the_Arioch at nm.ru Mon Oct 4 10:56:42 2004 From: the_Arioch at nm.ru (Arioch /BDV/) Date: Mon, 4 Oct 2004 12:56:42 +0400 Subject: [Matroska-devel] Re: Dirac Video Codec References: <5.2.0.9.2.20041001113442.0352e3a8@pop3><415D5A04.3060204@free.fr> Message-ID: The stars so gaily glistened... (Fri, 1 Oct 2004 11:20:40 -0500 @722) ...while the fading voice of Paul whispered through the darkness: [Sorry, skipped] PB> As he says, it is very useful to have as much data as possible PB> available at the container level for authoring purposes. This is part PB> of the philosophy of Matroska. I guess what is file size overhead here, comparing to plain MPEG or OGG or even AVI [Sorry, skipped] PB> in a Matroska file, the next audio and video packets to be found will PB> have timecodes. Instead of the application having to guess at the PB> timing of the packets relative to each other, it can instead know for In other words, each packet is having non-relative timecode, which is again longer than relative timecode with shorter value? Or if it is relative - then application seems to meet almost the same troubles. If i got it, in MKV timestamps are relative to upper EBML block, so within one block, all sub-blocks might be taken as they were absolutely stamped, but will this upper-level block be damaged, then all sub-blocks inside will lost its timestamps (read: sync) ? So in desync is not eliminated, it is just more varied in severity of damage after the random place, where the file was corrupt. [Sorry, skipped] -- ICQ - xmpp://arioch at jabber.ru xmpp://93438391 at icq.jabber.ru http://Arioch.nm.ru/FL/Fidolook_SL.png Mail: the_Ariochnmru From rbultje at ronald.bitfreak.net Mon Oct 4 11:11:23 2004 From: rbultje at ronald.bitfreak.net (Ronald S. Bultje) Date: Mon, 04 Oct 2004 11:11:23 +0200 Subject: [Matroska-devel] Re: Matroska + Delphi - wanting GStreamer/Win32 ? In-Reply-To: References: <40E2DF56.8020207@hrz.tu-chemnitz.de> <415D5046.7090809@free.fr> <415D7C92.5070609@free.fr> <1096724333.13781.3.camel@localhost.localdomain> Message-ID: <1096881082.2718.2.camel@tux.lan> On Mon, 2004-10-04 at 09:31, Arioch /BDV/ wrote: > RSB> Just to confirm both; I monitor the matroska-devel mailinglist, and I > RSB> wrote the demuxer, but I can't provide DLLs because I do not have > RSB> access to any Windows machine. Steve is the person to ask for all > RSB> GStreamer/Win32-related questions. You can, of course, ask me about > RSB> bugs and anything in the code and I'll happily answer any other > RSB> questions that you might have. > > So i unkindly ask You :-) > Can You make ebml/mkv code as a separate library with more or less documented API ? The code is already separated, there's a file ebml-read.c which handles all important EBML functions, and a file matroska-demux.c which is the matroska file parser, it uses embl-read.c as its base. ebml-read.h documents it. The functions are also documented inline. Always first check the code. ;). It will not become a library from my side, because I have little use for a library; I don't use the code outside GStreamer. However, since the code is LGPL, it is fully allowed for you to turn it into a library and do whatever with it as you wish. Make sure you submit changes to the EBML-code back to us. Ronald -- Ronald S. Bultje From the_Arioch at nm.ru Mon Oct 4 11:11:35 2004 From: the_Arioch at nm.ru (Arioch /BDV/) Date: Mon, 4 Oct 2004 13:11:35 +0400 Subject: [Matroska-devel] Re: Matroska + Delphi - wanting GStreamer/Win32 ? References: <40E2DF56.8020207@hrz.tu-chemnitz.de> <415D5046.7090809@free.fr> <415D7C92.5070609@free.fr><1096724333.13781.3.camel@localhost.localdomain> <1096881082.2718.2.camel@tux.lan> Message-ID: The stars so gaily glistened... (Mon, 04 Oct 2004 11:11:23 +0200 @424) ...while the fading voice of Ronald whispered through the darkness: RSB> The code is already separated, there's a file ebml-read.c which Only read? no write ? RSB> Always first check the code. ;). If You can easily find one. It is not always easy to find all the needed modules in the WebCvs, i cannot easily tell which other .c and ?? fiels will this depend upon :-) RSB> changes to the EBML-code back to us. Will i, i'd convert it to Pascal and it will be of little use to You :-) But seems i'd rather will it use as a example and documentations :-) -- ICQ - xmpp://arioch at jabber.ru xmpp://93438391 at icq.jabber.ru http://Arioch.nm.ru/FL/Fidolook_SL.png Mail: the_Ariochnmru From rbultje at ronald.bitfreak.net Mon Oct 4 15:49:13 2004 From: rbultje at ronald.bitfreak.net (Ronald S. Bultje) Date: Mon, 04 Oct 2004 15:49:13 +0200 Subject: [Matroska-devel] Re: Matroska + Delphi - wanting GStreamer/Win32 ? In-Reply-To: References: <40E2DF56.8020207@hrz.tu-chemnitz.de> <415D5046.7090809@free.fr> <415D7C92.5070609@free.fr> <1096724333.13781.3.camel@localhost.localdomain> <1096881082.2718.2.camel@tux.lan> Message-ID: <1096897752.2718.5.camel@tux.lan> Hi, On Mon, 2004-10-04 at 11:11, Arioch /BDV/ wrote: > RSB> The code is already separated, there's a file ebml-read.c which > Only read? no write ? There's a ebml-write.c as well. > RSB> Always first check the code. ;). > > If You can easily find one. > It is not always easy to find all the needed modules in the WebCvs, i cannot easily tell which other .c and ?? fiels will this depend upon :-) http://freedesktop.org/cgi-bin/viewcvs.cgi/gstreamer/gst-plugins/gst/matroska/ Ronald -- Ronald S. Bultje From paul at msn.com Tue Oct 5 04:00:03 2004 From: paul at msn.com (Paul Bryson) Date: Mon, 4 Oct 2004 21:00:03 -0500 Subject: [Matroska-devel] Re: Dirac Video Codec References: <5.2.0.9.2.20041001113442.0352e3a8@pop3><415D5A04.3060204@free.fr> Message-ID: "Arioch /BDV/" wrote... > The stars so gaily glistened... (Fri, 1 Oct 2004 11:20:40 -0500 @722) > ...while the fading voice of Paul whispered through the darkness: > PB> As he says, it is very useful to have as much data as possible > PB> available at the container level for authoring purposes. This is part > PB> of the philosophy of Matroska. > > I guess what is file size overhead here, comparing to plain MPEG or OGG or > even AVI There are some good overhead comparisons for AVI, OGM, and Matroska here: http://www-user.tu-chemnitz.de/~noe/Video-Zeug/AVIMux%20GUI/en_overhead_comparison.html and here: http://www-user.tu-chemnitz.de/~noe/Video-Zeug/containers.pdf MPEG is a little more difficult. I'm not sure about the MP4 container, but preliminary results for MPEG-2 the other overhead appears to be slightly lower in Matroska. I just remember that being mentioned and I'm afraid I can't recall what stream type was being used or why there was lower overhead. Perhaps spyder482 could give more information. > PB> in a Matroska file, the next audio and video packets to be found will > PB> have timecodes. Instead of the application having to guess at the > PB> timing of the packets relative to each other, it can instead know for > > In other words, each packet is having non-relative timecode, which is > again longer than relative timecode with shorter value? > Or if it is relative - then application seems to meet almost the same > troubles. It is relative within a small temporal segment. > If i got it, in MKV timestamps are relative to upper EBML block, so within > one block, all sub-blocks might be taken as they were absolutely stamped, > but will this upper-level block be damaged, then all sub-blocks inside > will lost its timestamps (read: sync) ? Correct. It would theoretically be possible to decode the audio and determine the length of the audio packets, and thus what the damaged portion should be. All Blocks are contained in a Cluster. A Block uses a relative timecode stored in a SINT16. This gives it a range of 65536 (+/-32k). A Cluster has a timecode stored in UINT that can be any size. The Block's timecode is relative to the Cluster's timecode. Because of the size of the Block's timecode, the Cluster can have a maximum length of 65 seconds (+/- 32s) when using the default value of 1ms for timecode accuracy. However, in practice no tool makes a Cluster of more than a few seconds long as the overhead benefits drop off quickly. Also, while the timecodes would have lost their time positioning relative to the rest of the file, they would still be completely accurate relative to each other. It would still be possible to simply continue to play back the Blocks in the same order until the next fully valid Cluster timecode is reached. > So in desync is not eliminated, it is just more varied in severity of > damage after the random place, where the file was corrupt. Correct. It would be possible to lose synch for a few seconds in the extremely improbable event that only the Cluster's timecode is damaged by a single bit flip. However, data errors tend to be more catastrophic than a single bit flip. I would expect that in the event of an error you are probably looking at enough data loss to take out a few Blocks or possibly most of a Cluster. In any event, any loss of synch or playback would be localized to the time covered by the damaged Cluster, a few seconds at most. As a point of interest, I obtained a file that was badly damaged. I believe it was from a P2P application where only some of the data was obtained, resulting in a file filled mostly with zeros where there should have been real data. The file was still playable, it simply played only the Clusters that were actually in the file. All synch was kept. Bit flipping is only one type of error though. There is also the possibility that data from the file could be lost resulting in a file that is smaller than it should be. (Data being added is possible, but much more rare.) In the event of data being lost it is possible to lose most of the data within the affected Cluster without doing a data analysis to find Block headers for resync. This would also make the seek tables useless beyond the point of the data loss. While seek in Matroska files that don't have a usable seek table, it is much slower than with. However, remuxing of the file along with probable recovery of most of the data in the damaged Cluster would be trivial. Again, a few seconds lost at most. Compare this with MP4. I am told that MP4 stores an index of frames in the file. All it has to do is store the number of samples that the frame lasts for (typically one sample) and the offset of the frame within the file. As this data is highly repetitive, it can be compressed to take less space. In the event of bit flips within the index, you could expect minor odd behavior. The greatest would be a frame lasting for maybe 10x the amount of time that it should and causing the rest of the stream to be that much out of synch. However, a data loss from the index would result in catastrophic failure of the file as all of the off the offset information would point to the incorrect offset within the file. It is possible for the index to be spread through an MP4 file to minimize the effects of these failures, but I do not know that any utility yet does this. Certainly all formats have their benefits and drawbacks, and Matroska is no exception. But data loss is certainly not a problem for Matroska. Besides localizing errors, Matroska also has the possibility of adding CRC32 data at different levels. I have only seen it done at the Cluster level, but this lets you know if a Cluster has been damaged, even if all of the data appears to be valid. And while it has not been implemented yet, there is also the possibility of adding error recovery data in the same way to be able to actually recover damaged data. It is possible that the required overhead for this could be prohibitive so as to make this a moot point. Also, most information like the Segment Information and the Track data is repeatable throughout the file with little impact on required overhead. Atamido From steve.lhomme at free.fr Tue Oct 5 09:28:18 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Tue, 05 Oct 2004 09:28:18 +0200 Subject: [Matroska-devel] Re: Dirac Video Codec In-Reply-To: References: <5.2.0.9.2.20041001113442.0352e3a8@pop3><415D5A04.3060204@free.fr> Message-ID: <41624D12.2030808@free.fr> Paul Bryson a ?crit : >>PB> in a Matroska file, the next audio and video packets to be found will >>PB> have timecodes. Instead of the application having to guess at the >>PB> timing of the packets relative to each other, it can instead know for >> >>In other words, each packet is having non-relative timecode, which is >>again longer than relative timecode with shorter value? >>Or if it is relative - then application seems to meet almost the same >>troubles. > > > It is relative within a small temporal segment. To be more precise, the frames have a relative timecode to the Cluster. The Cluster has an absolute timecode. From steve.lhomme at free.fr Tue Oct 5 11:24:25 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Tue, 05 Oct 2004 11:24:25 +0200 Subject: [Matroska-devel] Mkvmerge timecode file Message-ID: <41626849.9050505@free.fr> Hi everyone and especially Mosu, I was looking at the mkvmerge sources on how I could support the new elements I added recently to handle gaps in streams. I think I found the location where I could add the needed code in : cluster_helper_c::render() cluster->Render(*out, *kax_cues); Now the problem is to know where the gaps are for which tracks (I'll probably add a SetGapForTrack method in KaxCluster to make it nice in libmatroska). I thought it would be done with the timecode file. But it seems that both format v1 and v2 can't allow this : They both suppose that the stream is continuous and can't know when a long frame duration means it's a gap (it could be done this way but that's highly hackish). And actually the long duration is not even the correct one. Since, the real duration of the frame is not known and, especially in the case of a gap, the correct duration would be needed too. My first question is : what about referenced frames in the case of a timecode file ? Is the reader aware of that and keep the correct references ? My second question is : will there be a timecode file v3 to support gaps ? And duration ? IMO both v1 and v2 could be easily extended to support gaps : - for v1 you could have a new comma-separated parameter : 800,1000,25,1 1500,1700,30,0 The 1 means there is a gap, 0 there is no gap at the end. - for v2 you could have a comma-separated parameter like : 0 40 80,gap 2320 2360 or a special timecode : 0 40 80 -1 2320 2360 Opinions ? -- robUx4 on blog From moritz at bunkus.org Tue Oct 5 11:39:19 2004 From: moritz at bunkus.org (Moritz Bunkus) Date: Tue, 5 Oct 2004 11:39:19 +0200 Subject: [Matroska-devel] Mkvmerge timecode file In-Reply-To: <41626849.9050505@free.fr> References: <41626849.9050505@free.fr> Message-ID: <20041005093919.GT30891@bunkus.org> Hey, > My first question is : what about referenced frames in the case of a > timecode file ? Is the reader aware of that and keep the correct > references ? Yes. Internally each packet (= frame) has a timecode, a bref and a fref parameter. Those are not changed by the timecode files. There is also a _third_ value, assigned_timecode. This one is changed by the timecode file. When the code wants to know which timecodes to hand over to libmatroska it does this: (pseudo-codish) timecode = packet->assigned_timecode if (packet->bref != -1) bref_packet = find_packet_with_timecode(packet->bref) bref_timecode = bref_packet->assigned_packet else bref_timecode = -1 if (packet->fref != -1) fref_packet = find_packet_with_timecode(packet->fref) fref_timecode = fref_packet->assigned_packet else fref_timecode = -1 > My second question is : will there be a timecode file v3 to support gaps > ? And duration ? Sure. Why don't you define it? :) I can write the parser for it, or you can do it. > IMO both v1 and v2 could be easily extended to support gaps : No, I don't want to change the existing ones. So if you extend them then use new version nubmers for them. E.g. your changed v1 will become v3, and your changed v2 will become v4. > - for v1 you could have a new comma-separated parameter : > 800,1000,25,1 > 1500,1700,30,0 > > The 1 means there is a gap, 0 there is no gap at the end. Sounds good. > - for v2 you could have a comma-separated parameter like : > 0 > 40 > 80,gap > 2320 > 2360 Why not the word 'gap' alone on a line? > or a special timecode : > 0 > 40 > 80 > -1 > 2320 > 2360 Yeah more like this, but I'd prefer a word like 'gap' (maybe even in uppercase) to -1. Mosu -- If Darl McBride was in charge, he'd probably make marriage unconstitutional too, since clearly it de-emphasizes the commercial nature of normal human interaction, and probably is a major impediment to the commercial growth of prostitution. - Linus Torvalds From moritz at bunkus.org Tue Oct 5 11:40:04 2004 From: moritz at bunkus.org (Moritz Bunkus) Date: Tue, 5 Oct 2004 11:40:04 +0200 Subject: [Matroska-devel] Mkvmerge timecode file In-Reply-To: <20041005093919.GT30891@bunkus.org> References: <41626849.9050505@free.fr> <20041005093919.GT30891@bunkus.org> Message-ID: <20041005094004.GU30891@bunkus.org> Hey, > Yes. Internally each packet (= frame) has a timecode, a bref and a fref > parameter. Those are not changed by the timecode files. There is also a > _third_ value, assigned_timecode. This one is changed by the timecode ^^^^^^ fourth, of course. 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 Tue Oct 5 11:45:06 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Tue, 05 Oct 2004 11:45:06 +0200 Subject: [Matroska-devel] Mkvmerge timecode file In-Reply-To: <20041005093919.GT30891@bunkus.org> References: <41626849.9050505@free.fr> <20041005093919.GT30891@bunkus.org> Message-ID: <41626D22.7060705@free.fr> Moritz Bunkus a ?crit : >>My second question is : will there be a timecode file v3 to support gaps >>? And duration ? > > > Sure. Why don't you define it? :) I can write the parser for it, or you > can do it. OK. First I have to work on DvdMenuXTractor to allow ripping the whole audio & video to the correct concatenated files (one for each track/angle) and I will generate the timecode files from there. Is XML an option ? :D BTW, the v1 modification seems to be the most logical and shortest one. DVDs are not VFR (AFAIK, because it could). From moritz at bunkus.org Tue Oct 5 11:51:33 2004 From: moritz at bunkus.org (Moritz Bunkus) Date: Tue, 5 Oct 2004 11:51:33 +0200 Subject: [Matroska-devel] Mkvmerge timecode file In-Reply-To: <41626D22.7060705@free.fr> References: <41626849.9050505@free.fr> <20041005093919.GT30891@bunkus.org> <41626D22.7060705@free.fr> Message-ID: <20041005095133.GV30891@bunkus.org> Hey, > OK. First I have to work on DvdMenuXTractor to allow ripping the whole > audio & video to the correct concatenated files (one for each > track/angle) and I will generate the timecode files from there. Sure. You're the one who knows which entries you'll need, so I'll follow your lead on this. > Is XML an option ? :D ;) Nope. Not for such a single format, sorry. > BTW, the v1 modification seems to be the most logical and shortest one. > DVDs are not VFR (AFAIK, because it could). That's why they do perverse stuff like inverse telecine... 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 the_Arioch at nm.ru Tue Oct 5 12:49:22 2004 From: the_Arioch at nm.ru (Arioch /BDV/) Date: Tue, 5 Oct 2004 14:49:22 +0400 Subject: [Matroska-devel] Re: Dirac Video Codec References: <5.2.0.9.2.20041001113442.0352e3a8@pop3><415D5A04.3060204@free.fr> <41624D12.2030808@free.fr> Message-ID: The stars so gaily glistened... (Tue, 05 Oct 2004 09:28:18 +0200 @352) ...while the fading voice of Steve whispered through the darkness: SL> To be more precise, the frames have a relative timecode to the Cluster. SL> The Cluster has an absolute timecode. I wonder, if for long files, there was sense in 3 levels of hierarchy. Say, >>SuperCluster{timecode reltive to file start = absolute}[ ...SubClusters{timecode relative to SuperCluster}(Blocks)]<< IF such a Supercluster, for example, would have it's own seek table, etc, that maybe could be better for seeking remote(streaming) files. Also for long files (real long) absolute timecode values might become too long? -- ICQ - xmpp://arioch at jabber.ru xmpp://93438391 at icq.jabber.ru http://Arioch.nm.ru/FL/Fidolook_SL.png Mail: the_Ariochnmru From the_Arioch at nm.ru Tue Oct 5 12:44:15 2004 From: the_Arioch at nm.ru (Arioch /BDV/) Date: Tue, 5 Oct 2004 14:44:15 +0400 Subject: [Matroska-devel] Re: Dirac Video Codec References: <5.2.0.9.2.20041001113442.0352e3a8@pop3><415D5A04.3060204@free.fr> Message-ID: The stars so gaily glistened... (Mon, 4 Oct 2004 21:00:03 -0500 @125) ...while the fading voice of Paul whispered through the darkness: [Sorry, skipped] PB> Matroska. Besides localizing errors, Matroska also has the possibility PB> of adding CRC32 data at different levels. Alas this is almost undocumented in EBML docs :-(((( PB> I have only seen it done at the Cluster level, but this lets you know PB> if a Cluster has been damaged, even if all of the data appears to be PB> valid. Just a crazy idea: I'm afraid that calculating MD5 or CRC (or maybe some stronger signature, like SHA) would take a lot o CPU. I wonder, if there was some kind of spots, say signed would be some small `sub-stream` made of every 16th byte of Cluster. Little errors, like bit flip, are not of big danger, as You've shown. And such CRC could be, i think, relatively quickly checked (read: checked at the time of playback) and help to find relatively long troubles. Of course current all-bytes-through CRC my co-exists :-) PB> And while it has not been implemented yet, there is also the PB> possibility of adding error recovery data in the same way to be able PB> to actually recover damaged data. I think such a 'brackets', are to be more standardised in EBML. for exampel here is one more possible application: Let's imagine EBML-based archiver format, instead of current 7z, zip, rar. Then we can imagine passworded encryption of some of the data. And it will give as flexibility (may be too big indeed) as, for example: ....[CRC slot (file header - name, date, size etc) [password encryption (file data) ] ]... or ...[CRC slot [password encryption slot (header)(data) ] ].... or even ...[password1 encryption (header)(data).. [password2 (header)(data)] (h)(d) ].... 1st and 2nd line gives You 2 modes of password protected archives, i met in different archivers. Some programs can show file info but will not de-compress until password is given. Other even does not allwo You to list the password-protected files. 3rd line is some crazy method, that might be used by some installers, but would be too complex for usual user. It is more of theory than of real-life practical example. I just thought that good EBML library, would have some callbacks or some gates to master application, so application would provide decoder (here - password-using decrypter) and thus will generate derived EBML sub-stream. Of course, nothing stops me from doing RAM streams by the means of application itself, and then give this sub-stream to another instance of EBML parser - but that is not so cute :-) And that will not use any context, gathered why parsing main EBML stream. For example if some tag (class id in terms of EBML?) will have different meaning when put inside different outer classes-containers. Sorry for my poor English, that just soem thoughts into the air, so i do not know if they worth reading such a misty attempt to explain :-) -- ICQ - xmpp://arioch at jabber.ru xmpp://93438391 at icq.jabber.ru http://Arioch.nm.ru/FL/Fidolook_SL.png Mail: the_Ariochnmru From steve.lhomme at free.fr Tue Oct 5 12:58:13 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Tue, 05 Oct 2004 12:58:13 +0200 Subject: [Matroska-devel] Re: Dirac Video Codec In-Reply-To: References: <5.2.0.9.2.20041001113442.0352e3a8@pop3><415D5A04.3060204@free.fr> <41624D12.2030808@free.fr> Message-ID: <41627E45.9070103@free.fr> Arioch /BDV/ a ?crit : > The stars so gaily glistened... (Tue, 05 Oct 2004 09:28:18 +0200 @352) > ...while the fading voice of Steve whispered through the darkness: > > SL> To be more precise, the frames have a relative timecode to the Cluster. > SL> The Cluster has an absolute timecode. > > I wonder, if for long files, there was sense in 3 levels of hierarchy. > Say, >>SuperCluster{timecode reltive to file start = absolute}[ ...SubClusters{timecode relative to SuperCluster}(Blocks)]<< > > IF such a Supercluster, for example, would have it's own seek table, etc, that maybe could be better for seeking remote(streaming) files. > Also for long files (real long) absolute timecode values might become too long? Actually what you call SuperCluster is the Segment. Out of the segment, the "absolute" timecode doesn't have a real meaning. At least the way it's done now. Because the Segment *has* a DateUTC that is supposed to give the _absolute_ date when the content was created (the reference being the beggining of this millenium). Also with file linking the timecode of each linked Segment is contiguous to the one of the previous. But we could imagine a global delay at the Segment level to have the timecode for each Segment start at 0 and use the delay during linking. We also didn't state yet if a Chapter section can cover more than the Segment it's contained in. The current usage would be : no. From steve.lhomme at free.fr Tue Oct 5 13:14:31 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Tue, 05 Oct 2004 13:14:31 +0200 Subject: [Matroska-devel] Re: Dirac Video Codec In-Reply-To: References: <5.2.0.9.2.20041001113442.0352e3a8@pop3><415D5A04.3060204@free.fr> Message-ID: <41628217.4050102@free.fr> Arioch /BDV/ a ?crit : > PB> Matroska. Besides localizing errors, Matroska also has the possibility > PB> of adding CRC32 data at different levels. > > > Alas this is almost undocumented in EBML docs :-(((( EBML docs ? Where ? ;) Actually the CRC-32 is a feature of EBML, not just Matroska. http://ebml.sourceforge.net/specs/ It may not be crystal clear, but it's there. To understand EBML you also need to understand what global elements are, like Void and CRC-32. > PB> I have only seen it done at the Cluster level, but this lets you know > PB> if a Cluster has been damaged, even if all of the data appears to be > PB> valid. > > Just a crazy idea: > > I'm afraid that calculating MD5 or CRC (or maybe some stronger signature, like SHA) would take a lot o CPU. > I wonder, if there was some kind of spots, say signed would be some small `sub-stream` made of every 16th byte of Cluster. To "sign" only some parts of the element ? Well that could be. Even though right now there wouldn't be much use for that. Especially because it can be done by a global element. Parts of a Matroska file you'd like to protect are probably the Segment Info and Track Entry. And you would probably add error recovery for the whole thing, not just a part of it. > PB> And while it has not been implemented yet, there is also the > PB> possibility of adding error recovery data in the same way to be able > PB> to actually recover damaged data. > > I think such a 'brackets', are to be more standardised in EBML. That's an interresting idea. That could be a special EBML element like Void and CRC-32 that could be found anywhere in an EBML stream (global element). And that would also have a special type that would be almost like "sub-elements" but it would not change the level of the lower element. There would be a real level and a virtual level (the actual level in the file). This way you can put it anywhere and any EBML parser would give you the correct level for your data, even though physically they are one level below. That could be added to libebml without too much problems. > for exampel here is one more possible application: > Let's imagine EBML-based archiver format, instead of current 7z, zip, rar. Actually I have thought about an EBML system that would be similar to .tar but called .kar. It would simply be the Matroska attachment system, maybe with some permissions added (could be backported to Matroska). But that format doesn't include compression. > Then we can imagine passworded encryption of some of the data. > And it will give as flexibility (may be too big indeed) as, for example: > ....[CRC slot (file header - name, date, size etc) [password encryption (file data) ] ]... > or ...[CRC slot [password encryption slot (header)(data) ] ].... > or even ...[password1 encryption (header)(data).. [password2 (header)(data)] (h)(d) ].... > > 1st and 2nd line gives You 2 modes of password protected archives, i met in different archivers. > Some programs can show file info but will not de-compress until password is given. > Other even does not allwo You to list the password-protected files. That's up to the application, not the format. > 3rd line is some crazy method, that might be used by some installers, but would be too complex for usual user. > It is more of theory than of real-life practical example. Theory is usually the starting point of new things :) > I just thought that good EBML library, would have some callbacks or some gates to master application, so application would provide decoder (here - password-using decrypter) and thus will generate derived EBML sub-stream. > Of course, nothing stops me from doing RAM streams by the means of application itself, and then give this sub-stream to another instance of EBML parser - but that is not so cute :-) > And that will not use any context, gathered why parsing main EBML stream. For example if some tag (class id in terms of EBML?) will have different meaning when put inside different outer classes-containers. Yes, we actually need something like that in Matroska too. I would really like to have a good DRM solution in Matroska. And that implies encrypting some parts of the stream. And since we don't want to define and cover all encryption system, that would be up to a 3rd party code to decrypt the content, with the informations given in the file... That's somehow what is done in the (unused yet) Signature system you can see in the EBML specs. > Sorry for my poor English, that just soem thoughts into the air, so i do not know if they worth reading such a misty attempt to explain :-) No worries, it's interresting and understandable. From the_Arioch at nm.ru Tue Oct 5 13:47:40 2004 From: the_Arioch at nm.ru (Arioch /BDV/) Date: Tue, 5 Oct 2004 15:47:40 +0400 Subject: [Matroska-devel] Re: Dirac Video Codec References: <5.2.0.9.2.20041001113442.0352e3a8@pop3><415D5A04.3060204@free.fr> <41628217.4050102@free.fr> Message-ID: The stars so gaily glistened... (Tue, 05 Oct 2004 13:14:31 +0200 @510) ...while the fading voice of Steve whispered through the darkness: SL> EBML docs ? Where ? ;) The link below :-P SL> Actually the CRC-32 is a feature of EBML, not just Matroska. SL> It may not be crystal clear, The least to say :-) It is even hightlighted (lowlighted?) - it is almost impossible to tell why and how w/o referensing to existing libraries and MKV files, that are too large to be good example :-) SL> but it's there. To understand EBML you also need to understand what SL> global elements are, like Void and CRC-32. I know, but i don't know how to understand :-) ??>> met in different archivers. Some programs can show file info but will ??>> not de-compress until password is given. SL> That's up to the application, not the format. Yes, that is just an ode to EBML flexibility :-) ??>> I just thought that good EBML library, would have some callbacks or ??>> some gates to master application, so application would provide decoder ??>> (here - password-using decrypter) and thus will generate derived EBML ??>> sub-stream. SL> Yes, we actually need something like that in Matroska too. I would SL> really like to have a good DRM solution in Matroska. And that implies SL> encrypting some parts of the stream. SL> That's somehow what is done in the (unused yet) Signature system you SL> can see in the EBML specs. Hmm, disagree. Signature does not imply any stream transformation, so parser just throuws Signature to the application, maybe starts internal signature checker - if it contains one, and go on parsing, cause the stream itself was not changed. Parser does _not_ use application to recover part of the stream. Even would there be no application at all (say, some dumb EBML explorer or EBML-to-XML translator) it does not matter, cause EBML sub-stream is in its natural way. Quite the opposite thing if sub-stream is encrypted and parser _needs_ to use part of master-application. Then there is question how to do it effeciently and without context loss. -- ICQ - xmpp://arioch at jabber.ru xmpp://93438391 at icq.jabber.ru http://Arioch.nm.ru/FL/Fidolook_SL.png Mail: the_Ariochnmru From steve.lhomme at free.fr Tue Oct 5 14:04:11 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Tue, 05 Oct 2004 14:04:11 +0200 Subject: [Matroska-devel] Re: Dirac Video Codec In-Reply-To: References: <5.2.0.9.2.20041001113442.0352e3a8@pop3><415D5A04.3060204@free.fr> <41628217.4050102@free.fr> Message-ID: <41628DBB.7040700@free.fr> Arioch /BDV/ a ?crit : > SL> Actually the CRC-32 is a feature of EBML, not just Matroska. > SL> It may not be crystal clear, > > The least to say :-) > It is even hightlighted (lowlighted?) - it is almost impossible to tell why and how w/o referensing to existing libraries and MKV files, that are too large to be good example :-) Well, we haven't had any complaint about that so far. What exactly do you not understand about the CRC in Matroska ? > ??>> I just thought that good EBML library, would have some callbacks or > ??>> some gates to master application, so application would provide decoder > ??>> (here - password-using decrypter) and thus will generate derived EBML > ??>> sub-stream. > > SL> Yes, we actually need something like that in Matroska too. I would > SL> really like to have a good DRM solution in Matroska. And that implies > SL> encrypting some parts of the stream. > > SL> That's somehow what is done in the (unused yet) Signature system you > SL> can see in the EBML specs. > > Hmm, disagree. > Signature does not imply any stream transformation, so parser just throuws Signature to the application, maybe starts internal signature checker - if it contains one, and go on parsing, cause the stream itself was not changed. > > Parser does _not_ use application to recover part of the stream. > Even would there be no application at all (say, some dumb EBML explorer or EBML-to-XML translator) it does not matter, cause EBML sub-stream is in its natural way. > Quite the opposite thing if sub-stream is encrypted and parser _needs_ to use part of master-application. > Then there is question how to do it effeciently and without context loss. OK, my point was that it's almost like the signature. In the sense that encrypting some parts of a file would probably need the same kind of elements. BTW it makes me think about signing the subjective elements of a tag, or maybe even encrypting them. This way only you and your pals could know your subjective comments/ratings about some music... It would be nice to allow that, and even better with the special-sub-element I was talking about. From steve.lhomme at free.fr Tue Oct 5 15:27:08 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Tue, 05 Oct 2004 15:27:08 +0200 Subject: [Matroska-devel] CorePNG to store still images ? Message-ID: <4162A12C.9090306@free.fr> Hi Jory, Toff's DvdMenuXtractor used to extract still images from a DVD to BMP files. The advantage is that when you compress the images, you can save some space. In the other hand BMP is not compressed and it can't be muxed into Matroska. The problem here is that DVD cells can be in still format at anytime (maybe not anytime but theoretically they can). So we need to integrate it into the stream. We have 2 options : - encode the still cells as continuous cells. Hopefully MPEG2 readers can output the data as one or more frame. One frame with a long duration would be nice, but I doubt it will happen :( - encode the stills as CorePNG and switch between the main and CorePNG tracks when needed I think the cleanest way is to use CorePNG, but that implies using a "sub-track" for each possible DVD video track (ie angle). -- robUx4 on blog From the_Arioch at nm.ru Tue Oct 5 16:01:30 2004 From: the_Arioch at nm.ru (Arioch /BDV/) Date: Tue, 5 Oct 2004 18:01:30 +0400 Subject: [Matroska-devel] Re: Dirac Video Codec References: <5.2.0.9.2.20041001113442.0352e3a8@pop3><415D5A04.3060204@free.fr> <41628217.4050102@free.fr> <41628DBB.7040700@free.fr> Message-ID: The stars so gaily glistened... (Tue, 05 Oct 2004 14:04:11 +0200 @544) ...while the fading voice of Steve whispered through the darkness: SL> OK, my point was that it's almost like the signature. In the sense that SL> encrypting some parts of a file would probably need the same kind of SL> elements. Ahhh, yes, that is my point too. But principal difference is that application is passive while inside signature block, and essential while inside encrypted one. SL> BTW it makes me think about signing the subjective elements of a tag, SL> or maybe even encrypting them. What is those 'subjective elements' ? Are them xxx in XML analogue below? yyyy .... .... Currently, i think, there is no xxx and yyy and zzz are mutualy exclusive, yes? SL> and even better with the special-sub-element I was talking about. I think there is to be generic suggestion how to implement in EBML xxx, yyy and zzz from the above example. Especially if someone might like to make EBML equivalent for text XML-based protocol, like SOAP or XMPP. -- ICQ - xmpp://arioch at jabber.ru xmpp://93438391 at icq.jabber.ru http://Arioch.nm.ru/FL/Fidolook_SL.png Mail: the_Ariochnmru From the_Arioch at nm.ru Tue Oct 5 16:03:10 2004 From: the_Arioch at nm.ru (Arioch /BDV/) Date: Tue, 5 Oct 2004 18:03:10 +0400 Subject: [Matroska-devel] MNG? Was: CorePNG to store still images ? References: <4162A12C.9090306@free.fr> Message-ID: The stars so gaily glistened... (Tue, 05 Oct 2004 15:27:08 +0200 @602) ...while the fading voice of Steve whispered through the darkness: SL> I think the cleanest way is to use CorePNG, but that implies using a SL> "sub-track" for each possible DVD video track (ie angle). I wonder, what is about MNG then ? ( i heard it is much like PNG, but with some advanced features liek animation. I also heard, that while format exists, full-featured libraries are not complete) But i heard that with side of my ears, so i just wonder. -- ICQ - xmpp://arioch at jabber.ru xmpp://93438391 at icq.jabber.ru http://Arioch.nm.ru/FL/Fidolook_SL.png Mail: the_Ariochnmru From steve.lhomme at free.fr Tue Oct 5 16:12:20 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Tue, 05 Oct 2004 16:12:20 +0200 Subject: [Matroska-devel] MNG? Was: CorePNG to store still images ? In-Reply-To: References: <4162A12C.9090306@free.fr> Message-ID: <4162ABC4.5000401@free.fr> Arioch /BDV/ a ?crit : > The stars so gaily glistened... (Tue, 05 Oct 2004 15:27:08 +0200 @602) > ...while the fading voice of Steve whispered through the darkness: > > SL> I think the cleanest way is to use CorePNG, but that implies using a > SL> "sub-track" for each possible DVD video track (ie angle). > > I wonder, what is about MNG then ? > ( i heard it is much like PNG, but with some advanced features liek animation. I also heard, that while format exists, full-featured libraries are not complete) > > But i heard that with side of my ears, so i just wonder. MNG is so complicated that someone started hacking (or improving) PNG to allow simple animations like in GIF... And CorePNG already exists and should be very fine for what we need :) It's more suited than MPEG2 or any other video codec for that. But unfortunately that's not the "easy" solution for the moment... From jcsston at jory.info Tue Oct 5 17:22:32 2004 From: jcsston at jory.info (Jory Stone) Date: Tue, 5 Oct 2004 10:22:32 -0500 Subject: [Matroska-devel] Re: Dirac Video Codec References: <5.2.0.9.2.20041001113442.0352e3a8@pop3><415D5A04.3060204@free.fr> <41624D12.2030808@free.fr> Message-ID: <00d001c4aaef$28b7db20$6b00a8c0@jcsston> I tried to calculate the maximum length of a matroska file with the main timecodes are stored as 64-bit unsigned integers. After about 100,000+ centuries I lost count... Jory ----- Original Message ----- From: "Arioch /BDV/" To: Sent: Tuesday, October 05, 2004 5:49 AM Subject: [Matroska-devel] Re: Dirac Video Codec > The stars so gaily glistened... (Tue, 05 Oct 2004 09:28:18 +0200 @352) > ...while the fading voice of Steve whispered through the darkness: > > SL> To be more precise, the frames have a relative timecode to the > Cluster. > SL> The Cluster has an absolute timecode. > > I wonder, if for long files, there was sense in 3 levels of hierarchy. > Say, >>SuperCluster{timecode reltive to file start = absolute}[ > ...SubClusters{timecode relative to SuperCluster}(Blocks)]<< > > IF such a Supercluster, for example, would have it's own seek table, etc, > that maybe could be better for seeking remote(streaming) files. > Also for long files (real long) absolute timecode values might become too > long? > > -- > ICQ - xmpp://arioch at jabber.ru xmpp://93438391 at icq.jabber.ru > http://Arioch.nm.ru/FL/Fidolook_SL.png Mail: the_Ariochnmru -------------------------------------------------------------------------------- > _______________________________________________ > Matroska-devel mailing list > Matroska-devel at lists.matroska.org > http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel > From jcsston at jory.info Tue Oct 5 17:33:07 2004 From: jcsston at jory.info (Jory Stone) Date: Tue, 5 Oct 2004 10:33:07 -0500 Subject: [Matroska-devel] CorePNG to store still images ? References: <4162A12C.9090306@free.fr> Message-ID: <011401c4ab03$4ee50520$6b00a8c0@jcsston> Yeah, the menu is just a single encoded MPEG-2 frame that the player keeps on the screen. Converting to CorePNG wouldn't be hard, or you could keep it as MPEG-2. CorePNG's format is basically PNG file + little extra data to tell what color format has been hacked in ;) RGB, YUY2, YV12. Jory ----- Original Message ----- From: "Steve Lhomme" To: "Jory Stone" Cc: "Discussion about the current and future development of Matroska" Sent: Tuesday, October 05, 2004 8:27 AM Subject: [Matroska-devel] CorePNG to store still images ? > Hi Jory, > > Toff's DvdMenuXtractor used to extract still images from a DVD to BMP > files. The advantage is that when you compress the images, you can save > some space. In the other hand BMP is not compressed and it can't be muxed > into Matroska. > > The problem here is that DVD cells can be in still format at anytime > (maybe not anytime but theoretically they can). So we need to integrate it > into the stream. We have 2 options : > > - encode the still cells as continuous cells. Hopefully MPEG2 readers can > output the data as one or more frame. One frame with a long duration would > be nice, but I doubt it will happen :( > > - encode the stills as CorePNG and switch between the main and CorePNG > tracks when needed > > I think the cleanest way is to use CorePNG, but that implies using a > "sub-track" for each possible DVD video track (ie angle). > > -- > robUx4 on blog > _______________________________________________ > Matroska-devel mailing list > Matroska-devel at lists.matroska.org > http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel > From paul at msn.com Wed Oct 6 06:13:36 2004 From: paul at msn.com (Paul Bryson) Date: Tue, 5 Oct 2004 23:13:36 -0500 Subject: [Matroska-devel] Re: Dirac Video Codec References: <5.2.0.9.2.20041001113442.0352e3a8@pop3><415D5A04.3060204@free.fr> <41628217.4050102@free.fr> Message-ID: > The stars so gaily glistened... (Tue, 05 Oct 2004 13:14:31 +0200 @510) > ...while the fading voice of Steve whispered through the darkness: > > ??>> I just thought that good EBML library, would have some callbacks or > ??>> some gates to master application, so application would provide > decoder > ??>> (here - password-using decrypter) and thus will generate derived EBML > ??>> sub-stream. > > SL> Yes, we actually need something like that in Matroska too. I would > SL> really like to have a good DRM solution in Matroska. And that implies > SL> encrypting some parts of the stream. I'm not sure how you are differentiating from the current built in specs for encryption. These could easily be used as a DRM solution if someone so desired. Currently it allows encrypting just the tracks private data or all of the Blocks individually. Atamido From steve.lhomme at free.fr Wed Oct 6 09:24:27 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Wed, 06 Oct 2004 09:24:27 +0200 Subject: [Matroska-devel] Re: Dirac Video Codec In-Reply-To: References: <5.2.0.9.2.20041001113442.0352e3a8@pop3><415D5A04.3060204@free.fr> <41628217.4050102@free.fr> Message-ID: <41639DAB.3050208@free.fr> Paul Bryson a ?crit : >>The stars so gaily glistened... (Tue, 05 Oct 2004 13:14:31 +0200 @510) >>...while the fading voice of Steve whispered through the darkness: >> >>??>> I just thought that good EBML library, would have some callbacks or >>??>> some gates to master application, so application would provide >>decoder >>??>> (here - password-using decrypter) and thus will generate derived EBML >>??>> sub-stream. >> >>SL> Yes, we actually need something like that in Matroska too. I would >>SL> really like to have a good DRM solution in Matroska. And that implies >>SL> encrypting some parts of the stream. > > > I'm not sure how you are differentiating from the current built in specs for > encryption. These could easily be used as a DRM solution if someone so > desired. Currently it allows encrypting just the tracks private data or all > of the Blocks individually. Nop, signature != encryption. And what we have now is only signature without encryption. That means you can discard it and still use the file as-is. From paul at msn.com Wed Oct 6 17:58:01 2004 From: paul at msn.com (Paul Bryson) Date: Wed, 6 Oct 2004 10:58:01 -0500 Subject: [Matroska-devel] Re: Re: Dirac Video Codec References: <5.2.0.9.2.20041001113442.0352e3a8@pop3><415D5A04.3060204@free.fr> <41628217.4050102@free.fr> <41639DAB.3050208@free.fr> Message-ID: "Steve Lhomme" wrote... Paul Bryson a ?crit : >>>The stars so gaily glistened... (Tue, 05 Oct 2004 13:14:31 +0200 @510) >>>...while the fading voice of Steve whispered through the darkness: >>> >>>??>> I just thought that good EBML library, would have some callbacks or >>>??>> some gates to master application, so application would provide >>>decoder >>>??>> (here - password-using decrypter) and thus will generate derived >>>EBML >>>??>> sub-stream. >>> >>>SL> Yes, we actually need something like that in Matroska too. I would >>>SL> really like to have a good DRM solution in Matroska. And that implies >>>SL> encrypting some parts of the stream. >> >> >> I'm not sure how you are differentiating from the current built in specs >> for encryption. These could easily be used as a DRM solution if someone >> so desired. Currently it allows encrypting just the tracks private data >> or all of the Blocks individually. > > Nop, signature != encryption. And what we have now is only signature > without encryption. That means you can discard it and still use the file > as-is. Did you forget about the ContentEncryption element again? It allows encryption of the stream data, or even multiple layers of encryption. Sure, only the ContentCompression side of ContentEncoding has actually been implemented, but that still doesn't remove the fact that it is already in the specs, and more than sufficient for a DRM system. Atamido From steve.lhomme at free.fr Wed Oct 6 21:39:51 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Wed, 06 Oct 2004 21:39:51 +0200 Subject: [Matroska-devel] Re: Re: Dirac Video Codec In-Reply-To: References: <5.2.0.9.2.20041001113442.0352e3a8@pop3><415D5A04.3060204@free.fr> <41628217.4050102@free.fr> <41639DAB.3050208@free.fr> Message-ID: <41644A07.8030704@free.fr> Paul Bryson a ?crit : >>>I'm not sure how you are differentiating from the current built in specs >>>for encryption. These could easily be used as a DRM solution if someone >>>so desired. Currently it allows encrypting just the tracks private data >>>or all of the Blocks individually. >> >>Nop, signature != encryption. And what we have now is only signature >>without encryption. That means you can discard it and still use the file >>as-is. > > > Did you forget about the ContentEncryption element again? It allows > encryption of the stream data, or even multiple layers of encryption. Sure, > only the ContentCompression side of ContentEncoding has actually been > implemented, but that still doesn't remove the fact that it is already in > the specs, and more than sufficient for a DRM system. Yes I totally forgot about that one. And BTW what we were talking was something more generic, usable everywhere in any EBML format... -- robUx4 on blog From paul at msn.com Thu Oct 7 05:59:43 2004 From: paul at msn.com (Paul Bryson) Date: Wed, 6 Oct 2004 22:59:43 -0500 Subject: [Matroska-devel] IRC server change Message-ID: FYI, if you have been using irc.corecodec.com, you need to change to irc.corecodec.org. The .com server is unstable and is being pulled down for maintenance. Up until this point the two have been sending messages to each other so they work like one. Atamido From paul at msn.com Thu Oct 7 18:14:56 2004 From: paul at msn.com (Paul Bryson) Date: Thu, 7 Oct 2004 11:14:56 -0500 Subject: [Matroska-devel] Re: Dirac Video Codec References: <415D3020.9060109@free.fr> Message-ID: FYI http://developers.slashdot.org/developers/04/10/07/1449244.shtml?tid=156&tid=97&tid=8 Atamido From steve.lhomme at free.fr Sat Oct 9 09:41:06 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Sat, 09 Oct 2004 09:41:06 +0200 Subject: [Matroska-devel] Re: [Matroska-cvs] [www] r725 - trunk/www.matroska.org/data/news In-Reply-To: <200410082002.i98K2OSj080756@matroska.org> References: <200410082002.i98K2OSj080756@matroska.org> Message-ID: <41679612.9060303@free.fr> svn-commit-mail at lists.matroska.org wrote: > Author: christian > Date: 2004-10-09 00:02:16 +0400 (Sat, 09 Oct 2004) > New Revision: 725 > > Modified: > trunk/www.matroska.org/data/news/index.html.en > Log: > Added news about mkvtoolnix 0.9.6, Gspot, AvInfo, MatroskaDiag.exe and the PERL parser > > Modified: trunk/www.matroska.org/data/news/index.html.en > =================================================================== > --- trunk/www.matroska.org/data/news/index.html.en 2004-10-07 03:48:28 UTC (rev 724) > +++ trunk/www.matroska.org/data/news/index.html.en 2004-10-08 20:02:16 UTC (rev 725) > @@ -20,6 +20,34 @@ > >

Latest News

>
> +

2004-10-08

> +

There is a PERL parser for matroska files now, made by a user called Omion > + on Hydrogenaudio.org. I dont expect that many people will download this > + in its current phase ( alpha ), so he may forgive me that i am not uploading > + it to our server now, but just post a link > + to it here. You can find some background about the parser on Hydrogenaudio > + in this thread.
> + Another very interesting tool was released from our old and dear friend > + Christophe 'Toff' Paris, shortly before he went to another town to start > + his new job here. The tool is very useful, its called MatroskaDiag.exe > + and will analyze matroska files and then check your PC if you have all the > + right filters installed to play it with a DirectShow based player like Windows > + Mediaplayer, or more preferably Zoomplayer > + or TCMP. For interested developers, here > + are the sources. > + Toff, from the whole matroska team, all the best for your > + new job and your new life. We hope you will always be our friend, as we > + are very proud to be yours.
> + Other news :
> + - AvInfo and Gspot > + have support for MKV files now. Both are video info tools, similar to VideoInspector > + and MediaInfo. I couldn't test the > + two new tools still, but knowing the authors and the quality of their tools > + when i was using them for AVI files, i expect they did a good job.
> + - Mosu has released the very latest version of Mkvtoolnix, 0.9.6 . More > + about it here. > +
> +

>

2004-09-26

>

It has been a while since i had the time to write a long news entry, but > let me just start now and see how much i can report about the last months Christian, if you insist on using a WYSIWYG editor at least use it correctly. There are standard tags for lists in HTML.
- is just *not* an option. From steve.lhomme at free.fr Sat Oct 9 09:42:42 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Sat, 09 Oct 2004 09:42:42 +0200 Subject: [Matroska-devel] Re: [Matroska-cvs] [www] r725 - trunk/www.matroska.org/data/news In-Reply-To: <200410082002.i98K2OSj080756@matroska.org> References: <200410082002.i98K2OSj080756@matroska.org> Message-ID: <41679672.9000200@free.fr> svn-commit-mail at lists.matroska.org wrote: > +

There is a PERL parser for matroska files now, made by a user called Omion > + on Hydrogenaudio.org. I dont expect that many people will download this > + in its current phase ( alpha ), so he may forgive me that i am not uploading > + it to our server now, but just post a link > + to it here. You can find some background about the parser on Hydrogenaudio > + in this thread.
You might also check out the SVN logs to see that his Perl parser is already in our server... From paul at msn.com Sat Oct 9 18:48:06 2004 From: paul at msn.com (Paul Bryson) Date: Sat, 9 Oct 2004 11:48:06 -0500 Subject: [Matroska-devel] Re: [Matroska-cvs] [www] r725 -trunk/www.matroska.org/data/news References: <200410082002.i98K2OSj080756@matroska.org> <41679612.9060303@free.fr> Message-ID: "Steve Lhomme" wrote... > Christian, if you insist on using a WYSIWYG editor at least use it > correctly. There are standard tags for lists in HTML.
- is just *not* > an option.
is perfectly valid though. I have told Christian to go ahead and make the changes to the news and that I, or someone else, would gladly make it compliant. The sad truth is that if he doesn't make the changes, the website's content will likely never get updated. For me, the small amount of time needed to fix the pages is worth it. Atamido From chris at matroska.org Sat Oct 9 20:09:23 2004 From: chris at matroska.org (Christian HJ Wiesner) Date: Sat, 09 Oct 2004 20:09:23 +0200 Subject: [Matroska-devel] Re: [Matroska-cvs] [www] r725 -trunk/www.matroska.org/data/news In-Reply-To: References: <200410082002.i98K2OSj080756@matroska.org> <41679612.9060303@free.fr> Message-ID: <41682953.9090508@matroska.org> Paul Bryson wrote: >"Steve Lhomme" wrote... > > >>Christian, if you insist on using a WYSIWYG editor at least use it >>correctly. There are standard tags for lists in HTML.
- is just *not* >>an option. >> >> > >
is perfectly valid though. I have told Christian to go ahead and make >the changes to the news and that I, or someone else, would gladly make it >compliant. The sad truth is that if he doesn't make the changes, the >website's content will likely never get updated. For me, the small amount >of time needed to fix the pages is worth it. >Atamido > Thanks Paul :-) ! robuX4 : :-P Christian From christian at matroska.org Sun Oct 10 10:57:17 2004 From: christian at matroska.org (ChristianHJW) Date: Sun, 10 Oct 2004 10:57:17 +0200 Subject: [Matroska-devel] Re: Release notes for GStreamer 0.8.7 "A Cruise" In-Reply-To: <1097084208.4660.75.camel__6980.99201913482$1097084597$gmane$org@localhost.localdomain> References: <1097084208.4660.75.camel__6980.99201913482$1097084597$gmane$org@localhost.localdomain> Message-ID: <4168F96D.6080904@matroska.org> Christian Fredrik Kalager Schaller wrote: > Due to critics claiming we don't release often enough and due to some > important bugfixes we are proud to present: > > GStreamer 0.8.7 "A Cruise" > No win32 binaries still ? Would you be prepared to host those, if Steve sends you a compiled version ? Dont forget, 99,9999% of all Windows users dont have a clue what a compiler is :D ! Sure, those users wont be able to do anything with it yet, but still many interested devs would have a better feeling if you guys actually show you DO care about the win32 port, and maybe even start coding sinks for it ;) .... Christian matroska project admin http://www.matroska.org From steve.lhomme at free.fr Sun Oct 10 11:01:13 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Sun, 10 Oct 2004 11:01:13 +0200 Subject: [Matroska-devel] Re: [Matroska-cvs] [www] r725 -trunk/www.matroska.org/data/news In-Reply-To: <41682953.9090508@matroska.org> References: <200410082002.i98K2OSj080756@matroska.org> <41679612.9060303@free.fr> <41682953.9090508@matroska.org> Message-ID: <4168FA59.2050402@free.fr> Christian HJ Wiesner wrote: > Paul Bryson wrote: > >> "Steve Lhomme" wrote... >> >> >>> Christian, if you insist on using a WYSIWYG editor at least use it >>> correctly. There are standard tags for lists in HTML.
- is just >>> *not* an option. >>> >> >> >>
is perfectly valid though. I have told Christian to go ahead >> and make the changes to the news and that I, or someone else, would >> gladly make it compliant. The sad truth is that if he doesn't make >> the changes, the website's content will likely never get updated. For >> me, the small amount of time needed to fix the pages is worth it. >> Atamido > > Thanks Paul :-) ! > > robuX4 : :-P Does that mean you don't want to learn to use DW or whatever correctly ? Just because someone else will have to do it for you ? ... From steve.lhomme at free.fr Sun Oct 10 11:05:43 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Sun, 10 Oct 2004 11:05:43 +0200 Subject: [Matroska-devel] Re: [Matroska-cvs] [www] r725 -trunk/www.matroska.org/data/news In-Reply-To: References: <200410082002.i98K2OSj080756@matroska.org> <41679612.9060303@free.fr> Message-ID: <4168FB67.4050209@free.fr> Paul Bryson wrote: > "Steve Lhomme" wrote... > >>Christian, if you insist on using a WYSIWYG editor at least use it >>correctly. There are standard tags for lists in HTML.
- is just *not* >>an option. > > >
is perfectly valid though. I have told Christian to go ahead and make > the changes to the news and that I, or someone else, would gladly make it But the one you corrected before also had the ugly
-. Making the code just compliant, doesn't mean it's clean. So if I'm the only one that actually clean the code in the end, I ask Christian to be more careful with what he posts. (I also have to make the translation in french) From rbultje at ronald.bitfreak.net Sun Oct 10 12:31:13 2004 From: rbultje at ronald.bitfreak.net (Ronald S. Bultje) Date: Sun, 10 Oct 2004 12:31:13 +0200 Subject: [Matroska-devel] Re: [gst-devel] Re: Release notes for GStreamer 0.8.7 "A Cruise" In-Reply-To: <4168F96D.6080904@matroska.org> References: <1097084208.4660.75.camel__6980.99201913482$1097084597$gmane$org@localhost.localdomain> <4168F96D.6080904@matroska.org> Message-ID: <1097404273.2862.2.camel@tux.lan> Hi Chris, On Sun, 2004-10-10 at 10:57, ChristianHJW wrote: > No win32 binaries still ? Would you be prepared to host those, if Steve > sends you a compiled version ? Dont forget, 99,9999% of all Windows > users dont have a clue what a compiler is :D ! > > Sure, those users wont be able to do anything with it yet, but still > many interested devs would have a better feeling if you guys actually > show you DO care about the win32 port, and maybe even start coding sinks > for it ;) .... That's up to the porters. ;). Many, if not all, of our developers have no access to Win32 boxes, and we definately don't have access to win32 developer tools. We will gladly host binaries if someone can regularly provide us with updates on new releases. Again, most of us don't have win32 boxes, and we definately don't have win32 developer tools, so we cannot create those ourselves. We're doing our best to make porting as easy as possible, but that's pretty much all we can do... Ronald -- Ronald S. Bultje From chris at matroska.org Sun Oct 10 15:25:24 2004 From: chris at matroska.org (Christian HJ Wiesner) Date: Sun, 10 Oct 2004 15:25:24 +0200 Subject: [Matroska-devel] Re: [Matroska-cvs] [www] r725 -trunk/www.matroska.org/data/news In-Reply-To: <4168FA59.2050402@free.fr> References: <200410082002.i98K2OSj080756@matroska.org> <41679612.9060303@free.fr> <41682953.9090508@matroska.org> <4168FA59.2050402@free.fr> Message-ID: <41693844.2010806@matroska.org> Steve Lhomme wrote: > Does that mean you don't want to learn to use DW or whatever correctly > ? Just because someone else will have to do it for you ? Steve, lets be honest, when i look at the HTML code in my Editor, it just tells me nothing. I see a lot of funny characters and other characters in brackets, thats all. Its too late for me to adapt the necessary thinking to read this like you guys can, writing a simple news entry would take me hours and i simply dont have the time for this. I really like to think back to the old PowerDivX.com days, when Blacksun had installed a nice, PHP based news handling system for me, i just had to type in the text in a simple editor window, and all the formatting and display, etc. was done by PHP for me. Call me lazy, but these days i hardly have the time to help all the people having problems with MKV files on all the various fora i am visiting. When i find the motivation to post some news, i cant stand fiddling around with some HTML code, and please bare in mind i am not a programmer like you are. Things that are perfectly clear and obvious to you guys, are a strange world for me sometimes. Christian From the_Arioch at nm.ru Mon Oct 11 09:09:57 2004 From: the_Arioch at nm.ru (Arioch /BDV/) Date: Mon, 11 Oct 2004 11:09:57 +0400 Subject: [Matroska-devel] Re: [Matroska-cvs] [www] r725 -trunk/www.matroska.org/data/news References: <200410082002.i98K2OSj080756@matroska.org> <41679612.9060303@free.fr> <41682953.9090508@matroska.org><4168FA59.2050402@free.fr> <41693844.2010806@matroska.org> Message-ID: The stars so gaily glistened... (Sun, 10 Oct 2004 15:25:24 +0200 @600) ...while the fading voice of Christian whispered through the darkness: CHW> I really like to think back to the old PowerDivX.com days, when CHW> Blacksun had installed a nice, PHP based news handling system for me, CHW> i just had to type in the text in a simple editor window, and all the CHW> formatting and display, etc. was done by PHP for me. Maybe You need something like that ? http://wackowiki.com/WackoDocumentation/WhatYouThinkIsWhatYouGet?v=10np http://wackowiki.com/WackoDocumentation?v=12j1 Alas, there is now translated version of http://wackowiki.com/WackoDokumentacija/VvodnoeOpisanie?v=yks But maybe something alike is there on the other wiki-community sites -- ICQ - xmpp://arioch at jabber.ru xmpp://93438391 at icq.jabber.ru http://Arioch.nm.ru/FL/Fidolook_SL.png Mail: the_Ariochnmru From dgp85 at users.sourceforge.net Wed Oct 13 23:54:22 2004 From: dgp85 at users.sourceforge.net (Diego 'Flameeyes' =?ISO-8859-1?Q?Petten=F2?=) Date: Wed, 13 Oct 2004 23:54:22 +0200 Subject: [Matroska-devel] libebml and OpenBSD Message-ID: <1125606.NB6XW5Jt7T@flameeyes.is-a-geek.org> Ok, I'm trying to have the dependecy for my project compile on the systems I want to port it :) This time the operating system I'm working on is OpenBSD, where libebml couldn't compile because the compiler is gcc 2.95, but wchar.h isn't in the system include dir. The attached patch seems to fix this up, the library is correctly built. HTH -- Diego "Flameeyes" Petten? dgp85 at users.sourceforge.net - http://flameeyes.web.ctonet.it/ -------------- next part -------------- A non-text attachment was scrubbed... Name: libebml-0.7.1-openbsd.patch Type: text/x-diff Size: 407 bytes Desc: not available URL: From moritz at bunkus.org Thu Oct 14 09:48:52 2004 From: moritz at bunkus.org (Moritz Bunkus) Date: Thu, 14 Oct 2004 09:48:52 +0200 Subject: [Matroska-devel] libebml and OpenBSD In-Reply-To: <1125606.NB6XW5Jt7T@flameeyes.is-a-geek.org> References: <1125606.NB6XW5Jt7T@flameeyes.is-a-geek.org> Message-ID: <20041014074852.GN26832@bunkus.org> Hey, thanks, applied. 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 Oct 18 17:02:29 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Mon, 18 Oct 2004 17:02:29 +0200 Subject: [Matroska-devel] Track bitrate Message-ID: <4173DB05.8070300@free.fr> Hi, I was lurking the D9 forum to see what was going on (still less dead than HA) and saw this request to write the bitrate of each track in Matroska files. I'm not against it even it's only informational. But I don't see any mention of an EBML element to do that... Apparently alexnoe writes it. Is that how you use the BPS tag ? -- robUx4 on blog From moritz at bunkus.org Mon Oct 18 17:07:43 2004 From: moritz at bunkus.org (Moritz Bunkus) Date: Mon, 18 Oct 2004 17:07:43 +0200 Subject: [Matroska-devel] Track bitrate In-Reply-To: <4173DB05.8070300@free.fr> References: <4173DB05.8070300@free.fr> Message-ID: <20041018150743.GG26832@bunkus.org> Hey, On Mon, Oct 18, 2004 at 05:02:29PM +0200, Steve Lhomme wrote: > Apparently alexnoe writes it. Is that how you use the BPS tag ? Yes. We don't have a header field for it, and honestly I don't want to add it. Why? Because we already have a tag for it, and duplicating lots of information that is purely informational and not needed for decoding/stream selection (!) seems bloaty to me. 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 Oct 18 17:06:47 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Mon, 18 Oct 2004 17:06:47 +0200 Subject: [Matroska-devel] Track bitrate In-Reply-To: <20041018150743.GG26832@bunkus.org> References: <4173DB05.8070300@free.fr> <20041018150743.GG26832@bunkus.org> Message-ID: <4173DC07.9070704@free.fr> Moritz Bunkus a ?crit : > Hey, > > On Mon, Oct 18, 2004 at 05:02:29PM +0200, Steve Lhomme wrote: > >>Apparently alexnoe writes it. Is that how you use the BPS tag ? > > > Yes. We don't have a header field for it, and honestly I don't want to > add it. Why? Because we already have a tag for it, and duplicating lots > of information that is purely informational and not needed for > decoding/stream selection (!) seems bloaty to me. Yes I agree. I was just curious to know. From moritz at bunkus.org Mon Oct 18 17:14:04 2004 From: moritz at bunkus.org (Moritz Bunkus) Date: Mon, 18 Oct 2004 17:14:04 +0200 Subject: [Matroska-devel] tag changes, foo_matroska, CUE sheet conversion Message-ID: <20041018151404.GH26832@bunkus.org> Heya, Toff: I'm updating mkvmerge to conform with the latest tag specs. This involves three things: 1. DATE does not exist anymore. I'm changing it to DATE_RELEASED. 2. CATALOG is now CATALOG_NUMBER. Those two are minor, but I do think that changing tags that are already in use is a bad thing :( 3. LEVEL_TYPE does not exist anymore as a tag. It was replaced by the TagTargetTypeValue element below the TagTargets element. Could you please update foo_matroska accordingly? You can get a new build from http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-0.9.6-build20041017-1.rar It should create new files according to the new specs, and it will also change the tags in old files to match the new specs. This version does not use the ChapterPhysicalEquiv element because it still only supports one CD in one Matroska file. 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 steve.lhomme at free.fr Wed Oct 20 09:51:48 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Wed, 20 Oct 2004 09:51:48 +0200 Subject: [Matroska-devel] DShow File Writer Message-ID: <41761914.2030402@free.fr> Could anyone have a look at that ? http://www.corecodec.com/modules.php?op=modload&name=PNphpBB2&file=viewtopic&p=6358#6358 I think it might be a limitation of the file writer. -- robUx4 on blog From sylvain.binant at tele2.fr Tue Oct 19 21:10:31 2004 From: sylvain.binant at tele2.fr (sylvain.binant at tele2.fr) Date: Tue, 19 Oct 2004 21:10:31 +0200 Subject: [Matroska-devel] bug a corriger Message-ID: <000601c4b60f$5054b5b0$0201a8c0@sylvain> le pack matrovska a une incompatibilit? avec les extentions wmv. cela cr?e des erreurs : Application d?faillante firefox.exe, version 0.9.0.0, module d?faillant unknown, version 0.0.0.0, adresse de d?faillance 0xe8505100. meme chose avec ie6 : Application d?faillante iexplore.exe, version 6.0.2900.2180, module d?faillant unknown, version 0.0.0.0, adresse de d?faillance 0xe8505100. Pourriez vous corriger ce bug, et mavertir quand ce sera fait. je vous remercie grandement par avance. sincerement. sylvain -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve.lhomme at free.fr Wed Oct 20 10:09:21 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Wed, 20 Oct 2004 10:09:21 +0200 Subject: [Matroska-devel] foo_matroska pb ? Message-ID: <41761D31.906@free.fr> There seem to be a bug here : http://www.hydrogenaudio.org/forums/index.php?showtopic=26266&view=findpost&p=248806 -- robUx4 on blog From Liisachan at faireal.net Wed Oct 20 13:54:30 2004 From: Liisachan at faireal.net (Liisachan) Date: Wed, 20 Oct 2004 20:54:30 +0900 Subject: [Matroska-devel] foo_matroska pb ? In-Reply-To: <41761D31.906@free.fr> References: <41761D31.906@free.fr> Message-ID: <20041020205430dWm2iK@faireal.net> Steve Lhomme wrote: > There seem to be a bug here : > > http://www.hydrogenaudio.org/forums/index.php?showtopic=26266&view=findpost&p=248806 I've just tested more, and the same thing (mkvmerge 0.94=ok, 0.95=bad) happened both for FLAC in MKA and TTA in MKA. So this cant be the problem of foo_tta. If I use mkvmerge 0.95/0.96, I cannot seek properly on fb2k, chapters dont work properly either. Liisachan > > -- > robUx4 on blog > > _______________________________________________ > 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 Oct 23 10:32:24 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Sat, 23 Oct 2004 10:32:24 +0200 Subject: [Matroska-devel] Subversion Message-ID: <417A1718.8020509@free.fr> I upgraded the server to use the new Subversion 1.1.1 -- robUx4 on blog From tnr at ntlworld.com Sun Oct 24 13:34:40 2004 From: tnr at ntlworld.com (tnr at ntlworld.com) Date: Sun, 24 Oct 2004 12:34:40 +0100 Subject: [Matroska-devel] AVI convertion please Message-ID: <000701c4b9bd$75c3cbe0$6401a8c0@mark7p1onufgbc> Would you be kind enought to have a .mkv to .avi format convertor please??? IM not intrested in .mkv at all, I have no use for YET ANOTHER container tyope when we already have one, its called AVI and is accepted BY ALL PLAYERS unlike your veryown homebrew. What IM annoyed about is I spent nearly a month downloading a large file which was labled up as an avi file which turned out to be your .mkv format type and looking at your site you do not offer anything to help me decode the file into a file type thats compatible with my editors, IM not intrested in having to download a special editor or filter but a convertor to change the file into something more useful than the .mkv file type. BTW, if everyone would just simply understand about video and audio, they would already see that theirs a very tough job on the market to beat, its called .ogm, sits in an .avi container and is read BY ALL players, so yourselves and others who attempt to sway THE standard, will have a hard time. Sorry your codec does nothing for me, only it has turned me away from the idea because I have a filetype with no way of playing the fucking think, yes IM happy. NOT. --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.781 / Virus Database: 527 - Release Date: 21/10/2004 -------------- next part -------------- An HTML attachment was scrubbed... URL: From moritz at bunkus.org Mon Oct 25 09:30:57 2004 From: moritz at bunkus.org (Moritz Bunkus) Date: Mon, 25 Oct 2004 09:30:57 +0200 Subject: [Matroska-devel] Re: [Matroska-general] AVI convertion please In-Reply-To: <000701c4b9bd$75c3cbe0$6401a8c0@mark7p1onufgbc> References: <000701c4b9bd$75c3cbe0$6401a8c0@mark7p1onufgbc> Message-ID: <20041025073057.GA31213@bunkus.org> Hey, On Sun, Oct 24, 2004 at 12:34:40PM +0100, tnr at ntlworld.com wrote: > Would you be kind enought to have a .mkv to .avi format convertor > please??? No. AVI cannot do all that Matroska can do (Vorbis, variable FPS video, subtitles are NOT supported by hardware players, just to name a few). > IM not intrested in .mkv at all, Then don't use it. > What IM annoyed about is I spent nearly a month downloading a large > file which was labled up as an avi file which turned out to be your > .mkv format type and looking at your site you do not offer anything to > help me decode the file into a file type thats compatible with my > editors, Wohooo. And now you're blaming us that you've donwloaded some illegal stuff which was mislabeled and we don't offer the one-click-solution to your agony? Go get a life, dude. > BTW, if everyone would just simply understand about video and audio, > they would already see that theirs a very tough job on the market to > beat, its called .ogm, sits in an .avi container and is read BY ALL > players, so yourselves and others who attempt to sway THE standard, > will have a hard time. LOL! Two of the major software developpers who've written tools for OGM are Matroska team members, and we perfectly know what OGM can and cannot do. For instance you cannot put OGM into AVI. Or do you mean Vorbis? No? Well, even if you would, you can't put Vorbis into AVI and have that file working properly either. At the moment all hardware players that support Ogg (yes Ogg, not OGM) support audio-only Ogg/Vorbis files, and not audio/video OGM files. > Sorry your codec does nothing for me, only it has turned me away from > the idea because I have a filetype with no way of playing the fucking > think, yes IM happy. NOT. Matroska is a _container_, not a _codec_. If it's not the thing for you then don't use it, and don't download it. (You know, getting onto a mailing list and starting a rant is certainly not the way to get help. Treat others how you want to be treated.) 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 Oct 25 09:36:35 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Mon, 25 Oct 2004 09:36:35 +0200 Subject: [Matroska-devel] Re: [Matroska-general] AVI convertion please In-Reply-To: <000701c4b9bd$75c3cbe0$6401a8c0@mark7p1onufgbc> References: <000701c4b9bd$75c3cbe0$6401a8c0@mark7p1onufgbc> Message-ID: <417CAD03.2010007@free.fr> tnr at ntlworld.com a ?crit : > > Would you be kind enought to have a .mkv to .avi format convertor > please??? IM not intrested in .mkv at all, I have no use for YET ANOTHER > container tyope when we already have one, its called AVI and is accepted > BY ALL PLAYERS unlike your veryown homebrew. > > What IM annoyed about is I spent nearly a month downloading a large file > which was labled up as an avi file which turned out to be your .mkv > format type and looking at your site you do not offer anything to help > me decode the file into a file type thats compatible with my editors, IM > not intrested in having to download a special editor or filter but a > convertor to change the file into something more useful than the .mkv > file type. > > BTW, if everyone would just simply understand about video and audio, > they would already see that theirs a very tough job on the market to > beat, its called .ogm, sits in an .avi container and is read BY ALL > players, so yourselves and others who attempt to sway THE standard, will > have a hard time. > > Sorry your codec does nothing for me, only it has turned me away from > the idea because I have a filetype with no way of playing the fucking > think, yes IM happy. NOT. I think we should have a competition going for such posts. This one is already hard to beat ! From alexander.noe at s2001.tu-chemnitz.de Mon Oct 25 11:45:53 2004 From: alexander.noe at s2001.tu-chemnitz.de (Alexander Noe') Date: Mon, 25 Oct 2004 11:45:53 +0200 Subject: [Matroska-devel] AVI convertion please In-Reply-To: <000701c4b9bd$75c3cbe0$6401a8c0@mark7p1onufgbc> References: <000701c4b9bd$75c3cbe0$6401a8c0@mark7p1onufgbc> Message-ID: <417CCB51.8070600@hrz.tu-chemnitz.de> tnr at ntlworld.com wrote: > Would you be kind enought to have a .mkv to .avi format convertor > please??? IM not intrested in .mkv at all, I have no use for YET > ANOTHER container tyope when we already have one, its called AVI and > is accepted BY ALL PLAYERS unlike your veryown homebrew. It's not. I don't know any player with proper AVI support. You can easily make valid AVI files with valid xvid/divx content that won't work with M$ shitware nor with any hardware mpeg4 player. > > What IM annoyed about is I spent nearly a month downloading a large > file which was labled up as an avi file which turned out to be your > .mkv format type Slap the idiot who renamed that file then. > and looking at your site you do not offer anything to help me decode > the file into a file type thats compatible with my editors, IM not > intrested in having to download a special editor or filter but a > convertor to change the file into something more useful than the .mkv > file type. That is obviously a lie. You haven't even read the first 10 lines of the main page. See below to find out why I know that. > > BTW, if everyone would just simply understand about video and audio, > they would already see that theirs a very tough job on the market to > beat, its called .ogm Learn why OGM is the largest accumulation of shit I (and most likely you as well) have ever seen (even if you've seen that heap of shit from that one triceratops s in Jurassic Parc): http://www-user.tu-chemnitz.de/~noe/Video-Zeug/containers.pdf and why it is inferior to AVI in almost all aspects. > sits in an .avi container With that nonsense you have removed any doubt. You obviously do not have the slightest idea as to what you are talking about. > and is read BY ALL players It's not. BSPlayer for example doesn't read AVIs with switchable subtitles properly. > so yourselves and others who attempt to sway THE standard, will have a > hard time. Against AVI, maybe. Against OGM crap, certainly not. > Sorry your codec does nothing for me What do you talk about? That's even worse than the rest of your (nonsense) message. You've claimed that you've read www.matroska.org, and yet you call mkv a "codec". See above, this one proves that you haven't read the first 10 lines of the matroska main page. > , only it has turned me away from the idea because I have a filetype > with no way of playing the fucking think, yes IM happy. NOT. Learn reading. then and use those skills on www.matroska.org and packs.matroska.org. Google for mkvextract and read its manual. Alex, not member of the matroska team, but annoyed by stupid people. From kurtnoise at free.fr Mon Oct 25 21:50:05 2004 From: kurtnoise at free.fr (kurtnoise at free.fr) Date: Mon, 25 Oct 2004 21:50:05 +0200 Subject: [Matroska-devel] Bugs with mkvtoolnix and xml files from DVDMenuXtractor Message-ID: <1098733805.417d58ed894dc@imp6-q.free.fr> Hi, Yesterday I tested the last DVDMenuXtractor build for Windows from http://www.matroska.org/~robux4/dvd/ . All seems to work fine. I've got all my audio, video and xml Menus files...You can grap these files here : http://kurtnoise.free.fr/Menus_xml.zip Then, I tried to mux some files (mkv and these xml menus files) with the latest mkvmerge and I've got an error message :: Chapterparser failed for "....my_filename.xml" line 11, column 3 : is not a valid child element of . :( So my question is : Mosu, could you update this part in your tool ? Yes, I know that DVDMenuXtractor is for testing only and you are other priorities ;) Anyway, Thank you guys for the job. From steve.lhomme at free.fr Mon Oct 25 22:50:39 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Mon, 25 Oct 2004 22:50:39 +0200 Subject: [Matroska-devel] Bugs with mkvtoolnix and xml files from DVDMenuXtractor In-Reply-To: <1098733805.417d58ed894dc@imp6-q.free.fr> References: <1098733805.417d58ed894dc@imp6-q.free.fr> Message-ID: <417D671F.2060305@free.fr> kurtnoise at free.fr a ?crit : > Hi, > > Yesterday I tested the last DVDMenuXtractor build for Windows from > http://www.matroska.org/~robux4/dvd/ . All seems to work fine. I've got all my > audio, video and xml Menus files...You can grap these files here : > http://kurtnoise.free.fr/Menus_xml.zip > > Then, I tried to mux some files (mkv and these xml menus files) with the latest > mkvmerge and I've got an error message :: Chapterparser failed for > "....my_filename.xml" line 11, column 3 : is not a > valid child element of . :( > > So my question is : Mosu, could you update this part in your tool ? Yes, I know > that DVDMenuXtractor is for testing only and you are other priorities ;) It's all my fault. I use the "trunk" version on mkvmerge that I compiled myself. This version and not the 0.9x series has the new elements supported. But that's also part of the things not released yet... So you'll have to be more patient, or compile the softwares yourself ;) From moritz at bunkus.org Mon Oct 25 23:21:01 2004 From: moritz at bunkus.org (Moritz Bunkus) Date: Mon, 25 Oct 2004 23:21:01 +0200 Subject: [Matroska-devel] Bugs with mkvtoolnix and xml files from DVDMenuXtractor In-Reply-To: <417D671F.2060305@free.fr> References: <1098733805.417d58ed894dc@imp6-q.free.fr> <417D671F.2060305@free.fr> Message-ID: <20041025212101.GR5928@bunkus.org> Hey, > So you'll have to be more patient, or compile the softwares yourself > ;) Not really, I compile trunk from time to time: http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/HEAD/mkvtoolnix-head-20041025-1.rar (Note: "trunk" is 0.9.7 + experimental stuff that won't go into 1.0) 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 jcsston at jory.info Mon Oct 25 23:38:21 2004 From: jcsston at jory.info (Jory Stone) Date: Mon, 25 Oct 2004 16:38:21 -0500 Subject: [Matroska-devel] Bugs with mkvtoolnix and xml filesfrom DVDMenuXtractor References: <1098733805.417d58ed894dc@imp6-q.free.fr> <417D671F.2060305@free.fr> Message-ID: <003701c4bada$f6e8b820$6b00a8c0@jcsston> A much better question is, Why does it fail instead of skipping the unknown elements?... ----- Original Message ----- From: "Steve Lhomme" To: "Discussion about the current and future development of Matroska" Sent: Monday, October 25, 2004 3:50 PM Subject: Re: [Matroska-devel] Bugs with mkvtoolnix and xml filesfrom DVDMenuXtractor kurtnoise at free.fr a ?crit : > Hi, > > Yesterday I tested the last DVDMenuXtractor build for Windows from > http://www.matroska.org/~robux4/dvd/ . All seems to work fine. I've got > all my > audio, video and xml Menus files...You can grap these files here : > http://kurtnoise.free.fr/Menus_xml.zip > > Then, I tried to mux some files (mkv and these xml menus files) with the > latest > mkvmerge and I've got an error message :: Chapterparser failed for > "....my_filename.xml" line 11, column 3 : is not > a > valid child element of . :( > > So my question is : Mosu, could you update this part in your tool ? Yes, I > know > that DVDMenuXtractor is for testing only and you are other priorities ;) It's all my fault. I use the "trunk" version on mkvmerge that I compiled myself. This version and not the 0.9x series has the new elements supported. But that's also part of the things not released yet... So you'll have to be more patient, or compile the softwares yourself ;) _______________________________________________ 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 Mon Oct 25 23:48:54 2004 From: moritz at bunkus.org (Moritz Bunkus) Date: Mon, 25 Oct 2004 23:48:54 +0200 Subject: [Matroska-devel] Bugs with mkvtoolnix and xml filesfrom DVDMenuXtractor In-Reply-To: <003701c4bada$f6e8b820$6b00a8c0@jcsston> References: <1098733805.417d58ed894dc@imp6-q.free.fr> <417D671F.2060305@free.fr> <003701c4bada$f6e8b820$6b00a8c0@jcsston> Message-ID: <20041025214854.GT5928@bunkus.org> Hey, > A much better question is, Why does it fail instead of skipping the unknown > elements?... It's failing on unknown elements in the XML file, not on unknown elements in a Matroska file, and that's intentional. If it just ignores unknown stuff then the resulting file will definitely NOT be what the user wanted it to be. 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 Thu Oct 28 20:02:40 2004 From: chris at matroska.org (Christian HJ Wiesner) Date: Thu, 28 Oct 2004 20:02:40 +0200 Subject: [Matroska-devel] Re: [Matroska-general] AVI convertion please In-Reply-To: <000701c4b9bd$75c3cbe0$6401a8c0@mark7p1onufgbc> References: <000701c4b9bd$75c3cbe0$6401a8c0@mark7p1onufgbc> Message-ID: <41813440.2040109@matroska.org> tnr at ntlworld.com wrote: > Would you be kind enought to have a .mkv to .avi format convertor > please??? IM not intrested in .mkv at all, I have no use for YET > ANOTHER container tyope when we already have one, its called AVI and > is accepted BY ALL PLAYERS unlike your veryown homebrew. > > What IM annoyed about is I spent nearly a month downloading a large > file which was labled up as an avi file which turned out to be your > .mkv format type and looking at your site you do not offer anything to > help me decode the file into a file type thats compatible with my > editors, IM not intrested in having to download a special editor or > filter but a convertor to change the file into something more useful > than the .mkv file type. > > BTW, if everyone would just simply understand about video and audio, > they would already see that theirs a very tough job on the market to > beat, its called .ogm, sits in an .avi container and is read BY ALL > players, so yourselves and others who attempt to sway THE standard, > will have a hard time. > > Sorry your codec does nothing for me, only it has turned me away from > the idea because I have a filetype with no way of playing the fucking > think, yes IM happy. NOT. > The other guys were pretty nice with you. I'm not. FUCK OFF !!!! Christian matroska project administrator