From steve.lhomme at free.fr Sun Jun 11 11:30:58 2006 From: steve.lhomme at free.fr (Steve Lhomme) Date: Sun, 11 Jun 2006 11:30:58 +0200 Subject: [Matroska-devel] MKV GlobalTimecode() return messy data in VLC In-Reply-To: <8e2c5420605260300k67abe9c9l659275d242df3a17@mail.gmail.com> References: <8e2c5420605260300k67abe9c9l659275d242df3a17@mail.gmail.com> Message-ID: <448BE2D2.4060707@free.fr> Liao Carl wrote: > Hi All, Hi, > I am using libebml-0.7.7 and libmatroska-0.8.0 under VLC-0.8.4a. > The target platform is a MIPS Au1200 board. It cannot properly playback > .MKV > files. > > It seems that my MIPS version of > KaxBlock::GlobalTimecode()/KaxSimpleBlock::GlobalTimecode() in VLC's > mkv.cpp > > While I could properly playback the same .MKV file under RedHat WS 4.0 > using the same versions of libebml/libmatroska/VLC, it dumps the > following: > ... > > I wonder whether there are special hardware dependancies for libebml > to run under > a MIPS platform. It seems that the GlobalTimecode is 8 bit > left-shifted and sometimes mssed up under MIPS. > > My libebml CXX flags are: -O2 -Wall -Wno-unknown-pragmas -ansi > -fno-gnu-keywords -Wshadow. > > And my libmatroska CXX flags are: -O2 -Wall -Wno-unknown-pragmas -ansi > -fno-gnu-keywords -Wshadow -D_GNU_SOURCE > > Could you do me a favor to give some hints? Thanks a lot! I suppose the MIPS is Big Endian ? We have the following code to detect endianess in libebml : #if !defined(WORDS_BIGENDIAN) #if (defined (__arm__) && ! defined (__ARMEB__)) || defined (__i386__) || defined (__i860__) || defined (__ns32000__) || defined (__vax__) || defined (__amd64__) || defined (__x86_64__) #undef WORDS_BIGENDIAN #elif defined (__sparc__) || defined (__alpha__) || defined (__PPC__) || defined (__mips__) || defined (__ppc__) || defined (__BIG_ENDIAN__) #define WORDS_BIGENDIAN 1 #else // not automatically detected, put it yourself #undef WORDS_BIGENDIAN // for my testing platform (x86) #endif #endif // not autoconf Does your VLC comes precompiled or you compiled all the dependencies yourself ? Maybe the detection doesn't work correclty somewhere. Because libebml (and thus libmatroska and thus VLC) works correctly on PC and Mac so there is no endian problem. Steve From yann.renard.mailing-lists at tiscali.fr Mon Jun 12 15:16:24 2006 From: yann.renard.mailing-lists at tiscali.fr (Yann Renard) Date: Mon, 12 Jun 2006 15:16:24 +0200 Subject: [Matroska-devel] Using matroska as generic container In-Reply-To: <446C3A12.3060909@tiscali.fr> References: <446B2199.2000508@tiscali.fr> <446C1DEE.8090308@free.fr> <446C3A12.3060909@tiscali.fr> Message-ID: <448D6928.2020908@tiscali.fr> Yann Renard wrote: > Steve Lhomme wrote: >> Yann Renard wrote: >>> Hello everyone, >>> >>> I'm new to matroska and my question may sound quite uncommon, so >>> please apologize if I'm totally out of the topic. >>> >>> I'm currently working on a project that needs to manage multiple >>> streams. The different streams will have to be muxed/demuxed >>> sometimes, that's pretty sure. However, those streams have nothing >>> related to audio nor video. Their content may be anything, ranging >>> from discrete dated events to continuous dated data stream. >> >> As long as you are using streams with timestamps it's fine. >> >>> My question is could and should matroska be used as a container for >>> arbitrary streams ? Would you think this is a good idea ? >> >> Yes and yes. It has always been our goal to allow anything to be put >> in Matroska, even scientific data that can have timestamps up to a >> nanosecond. >> >>> The reason why I'm thinking to matroska is because it's known to be >>> robust and very efficient as far as I know, and quite open to >>> evolutions and maybe exotic use cases like this one. >> >> Exactly. >> >> To do this I suggest you to have a look at mkvtoolnix to mux/demux >> your streams. Feel free to ask here or Mosu for tips about the code. >> >> For playback (if you need that too) you can ask Haali a copy of his >> DShow filter or extend the MKV demuxer in VLC. The latter uses >> libmatroska as mkvtoolnix so you'll be familiar with the code. >> >> Steve > > Thank you very much for those infos !! > > Best regards, > Yann Hi all, I have started reading mastroska website "format specifications". I now have a little knowledge of how a matroska file looks like. I have also downloaded libebml, libmatroska, mkvtoolnix and vlc. Unfortunately I'm experiencing difficulties to enter in the code... I would like to get more documentation but it seems there is not... The code is not very commented. Therefore, I am looking after a simple sample that "reads matroska" file whith something like "do-whatever-you-want-with-those-read-data" line in the code, and something similare for writing. Does one of you know wher I could find such basic example ? Thanks, Best regards, Yann From mike at po.cs.msu.su Mon Jun 12 15:46:31 2006 From: mike at po.cs.msu.su (Mike Matsnev) Date: Mon, 12 Jun 2006 17:46:31 +0400 Subject: [Matroska-devel] Using matroska as generic container In-Reply-To: <448D6928.2020908@tiscali.fr> References: <446B2199.2000508@tiscali.fr> <446C1DEE.8090308@free.fr> <446C3A12.3060909@tiscali.fr> <448D6928.2020908@tiscali.fr> Message-ID: <448D7037.4090109@po.cs.msu.su> Yann Renard wrote: > I have started reading mastroska website "format specifications". I now > have a little knowledge of how a matroska file looks like. I have also > downloaded libebml, libmatroska, mkvtoolnix and vlc. Unfortunately I'm > experiencing difficulties to enter in the code... I would like to get > more documentation but it seems there is not... The code is not very > commented. Therefore, I am looking after a simple sample that "reads > matroska" file whith something like > "do-whatever-you-want-with-those-read-data" line in the code, and > something similare for writing. Does one of you know wher I could find > such basic example ? Take a look at http://haali.cs.msu.ru/mkv/MatroskaParser.zip and the dumptrack.c sample inside. This code is designed for timestamped A/V data, but other track types can be added with minimal changes. From yann.renard.mailing-lists at tiscali.fr Mon Jun 12 17:05:28 2006 From: yann.renard.mailing-lists at tiscali.fr (Yann Renard) Date: Mon, 12 Jun 2006 17:05:28 +0200 Subject: [Matroska-devel] Using matroska as generic container In-Reply-To: <448D7037.4090109@po.cs.msu.su> References: <446B2199.2000508@tiscali.fr> <446C1DEE.8090308@free.fr> <446C3A12.3060909@tiscali.fr> <448D6928.2020908@tiscali.fr> <448D7037.4090109@po.cs.msu.su> Message-ID: <448D82B8.90908@tiscali.fr> Mike Matsnev wrote: > Yann Renard wrote: >> I have started reading mastroska website "format specifications". I >> now have a little knowledge of how a matroska file looks like. I have >> also downloaded libebml, libmatroska, mkvtoolnix and vlc. >> Unfortunately I'm experiencing difficulties to enter in the code... I >> would like to get more documentation but it seems there is not... The >> code is not very commented. Therefore, I am looking after a simple >> sample that "reads matroska" file whith something like >> "do-whatever-you-want-with-those-read-data" line in the code, and >> something similare for writing. Does one of you know wher I could find >> such basic example ? > Take a look at http://haali.cs.msu.ru/mkv/MatroskaParser.zip and the > dumptrack.c sample inside. This code is designed for timestamped A/V data, > but other track types can be added with minimal changes. Thank you mike for your piece of code. It looks like what i'm looking for, at least for reading. Could you explain why this is not based on libmatroska and libebml ? Is there a reasonable reason for hardcoding node ids and so on, not using the services offered by libmatroska ? Best regards, Yann From mike at po.cs.msu.su Mon Jun 12 20:52:50 2006 From: mike at po.cs.msu.su (Mike Matsnev) Date: Mon, 12 Jun 2006 22:52:50 +0400 Subject: [Matroska-devel] Using matroska as generic container In-Reply-To: <448D82B8.90908@tiscali.fr> References: <446B2199.2000508@tiscali.fr> <446C1DEE.8090308@free.fr> <446C3A12.3060909@tiscali.fr> <448D6928.2020908@tiscali.fr> <448D7037.4090109@po.cs.msu.su> <448D82B8.90908@tiscali.fr> Message-ID: <448DB802.6020102@po.cs.msu.su> Yann Renard wrote: > Could you explain why this is not based on libmatroska and libebml ? Is > there a reasonable reason for hardcoding node ids and so on, not using > the services offered by libmatroska ? I needed something lightweight, in plain C, and with a rather high level API. From yann.renard.mailing-lists at tiscali.fr Mon Jun 12 21:08:06 2006 From: yann.renard.mailing-lists at tiscali.fr (Yann Renard) Date: Mon, 12 Jun 2006 21:08:06 +0200 Subject: [Matroska-devel] Using matroska as generic container In-Reply-To: <448DB802.6020102@po.cs.msu.su> References: <446B2199.2000508@tiscali.fr> <446C1DEE.8090308@free.fr> <446C3A12.3060909@tiscali.fr> <448D6928.2020908@tiscali.fr> <448D7037.4090109@po.cs.msu.su> <448D82B8.90908@tiscali.fr> <448DB802.6020102@po.cs.msu.su> Message-ID: <448DBB96.9000306@tiscali.fr> Mike Matsnev wrote: > Yann Renard wrote: >> Could you explain why this is not based on libmatroska and libebml ? >> Is there a reasonable reason for hardcoding node ids and so on, not >> using the services offered by libmatroska ? > I needed something lightweight, in plain C, and with a rather high level > API. I'm sure it does the job ;) Best regards Yann From liaokai.cn at gmail.com Wed Jun 14 08:22:45 2006 From: liaokai.cn at gmail.com (Carl Liao) Date: Wed, 14 Jun 2006 14:22:45 +0800 Subject: [Matroska-devel] MKV GlobalTimecode() return messy data in VLC In-Reply-To: <448BE2D2.4060707@free.fr> References: <8e2c5420605260300k67abe9c9l659275d242df3a17@mail.gmail.com> <448BE2D2.4060707@free.fr> Message-ID: <8e2c5420606132322s13dc6e10le408a3c59afe2e8f@mail.gmail.com> Hi Steve, Thanks a lot for your reply! You are absolutely right. We have found that libebml using the wrong endianess for our MIPS target. We use Little endian target system. After defining the right WORDS_BIGENDIAN, it works fine then. Thanks! Carl On 6/11/06, Steve Lhomme wrote: > Liao Carl wrote: > > Hi All, > > Hi, > > > I am using libebml-0.7.7 and libmatroska-0.8.0 under VLC-0.8.4a. > > The target platform is a MIPS Au1200 board. It cannot properly playback > > .MKV > > files. > > > > It seems that my MIPS version of > > KaxBlock::GlobalTimecode()/KaxSimpleBlock::GlobalTimecode() in VLC's > > mkv.cpp > > > > While I could properly playback the same .MKV file under RedHat WS 4.0 > > using the same versions of libebml/libmatroska/VLC, it dumps the > > following: > > > ... > > > > I wonder whether there are special hardware dependancies for libebml > > to run under > > a MIPS platform. It seems that the GlobalTimecode is 8 bit > > left-shifted and sometimes mssed up under MIPS. > > > > My libebml CXX flags are: -O2 -Wall -Wno-unknown-pragmas -ansi > > -fno-gnu-keywords -Wshadow. > > > > And my libmatroska CXX flags are: -O2 -Wall -Wno-unknown-pragmas -ansi > > -fno-gnu-keywords -Wshadow -D_GNU_SOURCE > > > > Could you do me a favor to give some hints? Thanks a lot! > > > I suppose the MIPS is Big Endian ? We have the following code to detect > endianess in libebml : > > #if !defined(WORDS_BIGENDIAN) > #if (defined (__arm__) && ! defined (__ARMEB__)) || defined (__i386__) > || defined (__i860__) || defined (__ns32000__) || defined (__vax__) || > defined (__amd64__) || defined (__x86_64__) > #undef WORDS_BIGENDIAN > #elif defined (__sparc__) || defined (__alpha__) || defined (__PPC__) || > defined (__mips__) || defined (__ppc__) || defined (__BIG_ENDIAN__) > #define WORDS_BIGENDIAN 1 > #else > // not automatically detected, put it yourself > #undef WORDS_BIGENDIAN // for my testing platform (x86) > #endif > #endif // not autoconf > > Does your VLC comes precompiled or you compiled all the dependencies > yourself ? Maybe the detection doesn't work correclty somewhere. Because > libebml (and thus libmatroska and thus VLC) works correctly on PC and > Mac so there is no endian problem. > > Steve > > _______________________________________________ > Matroska-devel mailing list > Matroska-devel at lists.matroska.org > http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel > Read Matroska-Devel on GMane: http://dir.gmane.org/gmane.comp.multimedia.matroska.devel > From steve.lhomme at free.fr Sun Jun 18 10:53:26 2006 From: steve.lhomme at free.fr (Steve Lhomme) Date: Sun, 18 Jun 2006 10:53:26 +0200 Subject: [Matroska-devel] Re: MKV File Problem (w/ MatroskaDiag log) In-Reply-To: <9FA4C5AA-B15E-426D-B058-3381FD3F88F8@gmail.com> References: <9FA4C5AA-B15E-426D-B058-3381FD3F88F8@gmail.com> Message-ID: <44951486.9080602@free.fr> Ivan Kowalenko wrote: >> Codec : (V_MPEG4/ISO/AVC) >> Language : English (eng) >> Pixel Width : 704 >> Pixel Height : 396 >> Display Width : 16 >> Display Height : 9 > > Another problem might be the set Display Width and Display Heights. > They're currently set for 16 and 9, respectively. My guess is that the > aspect ratio is 16:9, but those parameters shouldn't be set like that. > So, at the moment, looks like the decoder (if it's respecting those two > settings) is outputting to 16 pixels by 9 pixels. Remuxing the file with > a proper display resolution might fix it, assuming the codec isn't your > problem. I could be wrong, though. While trying to extract some data from an ASF (DVR-MS) file using Haali's muxer I noticed it sets the aspect ratio this way. Is that a bug or a special feature ? The specs say: DisplayWidth 4 [54][B0] - - not 0 PixelWidth u-integer Width of the video frames to display. DisplayHeight 4 [54][BA] - - not 0 PixelHeight u-integer Height of the video frames to display. That's in pixel, it's not an aspect ratio. Steve From guardian653dave at gmail.com Wed Jun 21 12:00:42 2006 From: guardian653dave at gmail.com (David Elizalde) Date: Wed, 21 Jun 2006 06:00:42 -0400 Subject: [Matroska-devel] Controlling the Haali Media Spliter (Win32) Message-ID: Hello, I came here to see if anyone could answer this or point me to the correct spot if possible. My question is this, is it possible for an external app to control your filter? I've looked into the archive on Gmane and found a short reference to another post. The orginal post asked if there was a method similar to VSFilter (which consisted of sending messages to a hidden window) to switch between subtitle tracks. The reply simply pointed "IAMStreamSelect" api in DirectShow. Lots of Googling have pointed to implementing this as a interface. I'm not sure if I can do that for Windows Media Center 2005. (correct me if I'm wrong, as I'm pretty much a newbie (is) to DirectX programming) All I want to do is to change the audio/subtitle tracks. As the tray icon can do by itself, but I want to make an app that could be launched from MCE to change it using the remote. Any possible suggestions? Thanks for your time, David - God's in his heaven, All's right with the world From steve.lhomme at free.fr Tue Jun 27 18:32:51 2006 From: steve.lhomme at free.fr (Steve Lhomme) Date: Tue, 27 Jun 2006 18:32:51 +0200 Subject: [Matroska-devel] EBML Namespaces In-Reply-To: <2684397F36DC8849A9BF842433B784360215DC78@GZI-VM01.cm-cic.fr> References: <2684397F36DC8849A9BF842433B784360215DC78@GZI-VM01.cm-cic.fr> Message-ID: <44A15DB3.7030607@free.fr> Almost 2 months later, I finally have time to reply (and trying to remember what has been said so far)... HAESSIG Jean-Christophe wrote: >> I've got very precise ideas on how the things could work now. > > This discussion is becoming more and more interesting. As I > said before, I recently changed my mind about what the best > place to store namespace information would be. Therefore, I > would like to thank Steve and Atamido for participating to > the debate and sharing their good ideas. Idea sharing > enables us to find even better ideas, which I enjoy very > much. We are currently working on a "secure" layer for Matroska and it may be directly applied in EBML. So we might make all the changes at once or make sure one change is working with the other. >> I don't think it would be OK to put elements from namespaces that were >> not declared before in the file. That would be quite a PITA for the >> parser if it would have to look for handler of namespace XYZ during > > I don't get for what reason this would be a problem. Perhaps you > have a tricky case in mind ? To me, either the reading app > understands a number of namespaces and doesn't try do do anything > with the elements from unknown namespaces but ignore them. Or, the > app is some kind of generic interpreter which dynamically loads > libraries during the parsing. If reactivity is important, the > loading can even be done in a separate thread. Yes, I'm thinking in terms of a generic EBML reader/writer (libebml). Given namespaces are supposed to be extending a format a lot, in various ways, there can be plenty. Especially if EBML becomes popular and a system has 100 namespaces installed. You would want something like "include namespace" to include just the ones you want, instead of loading them all for each EBML format. It also makes it easier for "search engine" to look for "files using the matroska namespace" on your system if it's written in the header. Rather than having to parse a lot in the file to /guess/ what is being used. >> parsing. This would better be done during the init of the EBML >> file/stream reading. That is when declared in the header. That also >> means we can find out about false (damaged) namespace headers. > > Is this really important ? I think if one is concerned with file > integrity, he should use the generic CRC abilities of EBML. Again, in the case you have 100 namespaces installed, it's likely that a damaged byte in the file could be interpreted as a namespace and totally b0rk the application. It's cleaner to say it in the header one and for all... And having the namespaces in the header allow more neat features for namespaces like using a string name, having a version number, a URL to find info about the namespace (in case you don't have it on your system), etc. >> Right now no parser would ignore extra bits put in the EBML header. > The >> specs were quite clear on how to intrepret each bits. There was no bit > >> left... > > Well, I tried to add some extra unspecified elements in the > header of an mkv video, and the file still played well... With > VLC, at least. Adding elements is fine (by design). Changing bits either in the EBML ID or the EBML size is not. >> Unfortunately, as said above, adding bits anywhere in the element > header >> would be backward incompatible. So maybe she should improve EBML in 2 >> versions. That would be EBML 1.1 (Atamido's extension) and EBML 2 > (your >> proposal). In EBML version IDs that would be EBMLVersion 2 with >> EBMLReadVersion = 1 and EBMLVersion 3 (or more to leave improvement > for >> version 2) with EBMLReadVersion = 3. > > Your proposal of having files of a newer version readable by old > parsers is interesting, and I think it can be done. > However, I disagree if this means releasing 2 incompatible versions > of EBML (1.1 and 2.0) using different mechanisms. If we had loads of > file formats using EBML, I think I would go for it (but not happily) > but it is not the case. The only format that we know of is Matroska, > and if in the end the latest version is incompatible with v1 parsers > there is no real benefit to release an intermediate version. Indeed. But that would leave us time to work on a /totally/ incompatible version of EBML, and of Matroska (removing useless parts and changing a few little things here and there). >> I don't really get the point here. If you need extra data in an > element, >> you can add a child element. It can also be considered as an > attribute. > > My point is : imagine you have an integer element > [ID][Size] > For a more precise example : > [9A][81][80] (Class Id 9A, Size 1 byte, value 0) > > Then imagine you need to attach a comment (e.g. "john wrote this") > to this integer element. This would logically look like : > [Value-ID][Size] > [Comment-ID][Size] > > > This feature is needed to support what I call "annotation". > My original idea was to add something that would tell the parser > that the comment element was the last child of the value element > and therefore, that the raw integer data starts just after it. Yes, but that's OK only if you have one additional namespace. In the case you have 2 (and more) it becomes complicated... > Now, some sort of wrapper could be used, as you suggest (this is > what I understood when you said "If you need extra data in an > element, you can add a child element". The example will become : > > [Value-ID][Size] > [Comment-ID][Size] > [Wrapper-ID][Size] > > This is quite clean, but I need to discuss it further because > * It implies changes on the percieved structure of the file > * It is somewhat related to Atamido's proposal Yes, that's the kind of thing I had in mind (with the extra child). That would be a nice feature for signatures too. > 1. Changes to the perception of structure > Using some wrapper element makes the integer value a child of > the wrapper and the wrapper a child of the "value" element. > This *has to* be handled by the EBML layer and to be invisible > to the user of EBML APIs. The wrapper must remain a technical > element that will not be visible and all its contents should > be seen as children of the "value" element. Agreed. > As a side note, I want to add that there is a similar issue > with the [EC] void element. Should this element be > considered to be part of the data tree or just a technical > placeholder not visible to higher level parsers ? So far it has been treated as part of the tree. libebml also gives the ability to overwrite it with another element and keep the rest as void (as long as the size fits). > 2. Link with Atamido's proposal > As you also noted, an interesting point in this proposal > is its "shielding" effect for contained data. If added in > a v1 Matroska file, an element with an unknown class-id > will be totally skipped, thus preserving the contained > data from being wrongly interpreted. Correct. > Aside from the use described before the wrapper can also > be used to wrap children elements with v1-incompatible > headers. It would then become possible to include them in > a v1 file with the interesting effect of protecting them > from unwanted reading by a v1 app. > V2 readers, which would understand the wrapper as being > a wrapper ;) would be able to properly parse them and apply > extra namespace-related rules. As explained before, the > elements contained in the wrapper should be seen as > children of the parent element of the wrapper. Exactly. And that's what I have in mind for the encryption/signature layer in EBML. > This mechanism can be used in V2 files labelled as readable > whith a V1 parser. It can't be used for annotation in these > files. However, it can be used for that purpose in the wrapped > and opaque parts of these files and in pure V2 files (only > readable with a V2 parser). However, pure V2 files will have > no real use of the wrapper element outside annotation. Right. >> I'm sure that adding a byte for *all* elements will always be bigger >> than adding 3 bytes here and there. I don't think having a lot of >> namespaces mixed in a place of the format would occur a lot. If you're >> thinking about annotation, then it should be at the expense of a big >> overhead. And for such a purpose I think it's OK. > > And what if the two objectives can be met simultaneously, i.e. being > able to associate a specific namespace to every single element (e.g. > regularly interleaving elements from 2 or 3 namespaces) AND only > adding one byte here and there ? Of course, it's the best :) >>> Moreover, the NS-related tag(s) should still be global and >>> therefore cannot be used by applications. To be able not to >>> change namespaces too often, the EBML private tags (void, >>> signature, etc...) should be left global. In my proposal I >>> intended to give EBML its own namespace providing total >>> isolation from other vocabularies, which I felt cleaner. >> That's very tricky IMO. We still need some EBML global elements. And > > In my proposal EBML has its namespace, and no element is global. > (except maybe the reserved FF, 7FFF, 3FFFFF, 1FFFFFFF... ) That can only happen as V2. Both CRC and Void are used a lot. CRC can be replaced as a wrapped element (or become part of the more general signature/encryption layer/namespace). And I can't think of an equivalent to Void with the namespaces, as it serves a specific goal (data padding in case the file needs to be "patched"). >> losing some space for something that is mandatory anyway is not good >> IMO. I think that both EBML and the DocType shouldn't require special >> namespace handling. But if we have MatroskaNS and EBML v3 very > > I treat elements from the EBML namespace and elements from other > namespaces equally. But there will be *no* backward-incompatible > syntactic modifications to how EBML elements are represented > and especially *no* incompatible modification to the header. Great :) > This may sound weird, but here is the basic idea : > * you have an EBML header : [1a][45][df][a3]<93> (19 bytes long) (you mean 13) > * the namespace is encoded in the value of the size header > (this excludes the bits used to set the length of the VINT, > that is the '0010011' binary string) > * in this example, say the namespace for EBML is expressed > as the bit string '00' > > According to these rules, that valid v1 EBML header is in the > EBML namespace, by just doing nothing ;). > Elements in other namespaces can use other codes, which will > break compatibility with v1 parsers, since the decoded size > will be wrong, but this is harmless, since no v1 parser would > ever attempt to read such an element, either because the > EBMLReadVersion would be set accordingly or the "shielding" > elements would be used. OK, so we break compatibility one way or another. That means all existing apps will need to be updated to take the new EBML in account. That's why I'd rather have the namespace changes coupled with the encryption/signature changes. No player is expected to read an encrypted file right now. > The only plausible objection is : what if my header is 51 bytes > long and I still need to encode the EBML NS with '00' ? You just > need to encode the size on two bytes, like this : [40][33], which > is, according to the spec, totally legal (and successfully tested). Yes, that's not a problem. It seems to me that we're running in circles wondering if we need incompatible changes or not. Having compatible changes ensures new file can be handled by other tools. Incompatible changes mean we can enhance EBML and Matroska a lot more. Hence my idea of having 2 phases. IMO it depends if (code) changes from phase 1 can be used in phase 2, ie adapting our APIs to use different namespaces. > For an hypothetic MatroskaNS and for all formats interested in > indexing and seeking, the new generic infrastructure will need > to include for each indexed element : > * an application-dependent key (which can be a time offset, > coordinates, etc...) > * a pointer or a file offset to the element > * data to rebuild the context at the element (level and namespaces) EBML can only deal with data offset, hierarchy (and soon namespaces). We have to seek with just that. >> Yes, that would be nice. but designing a FS is a very specific and > hard >> time (look at how long it takes to make ReiserFS good). And the main >> constraints are I/O speed which might not be compatible with EBML. And > >> (de)fragmentation is probably the trickiest part... > > I/O speed is mainly achieved thanks to block alignment IMO. Of > course it would be silly to design a FS where the block structure > of disk devices wouldn't be taken in account. This is good to keep > in mind for the future seeking infrastructure. It should allow to > express offsets as block counts. No, because the file would become hardware specific :( The only alignment right now in EBML is 1 octet. And I think any other value would not be very efficient. Now for a file system (namespace). The same way we handle time in matroska (timecode scale) we could handle data blocks on a HDD. >>From the beginning, I thought it should be possible to express > namespace associated with an element on less than 1 byte. > I figured out that we could have something more generic than > namespaces. I will later refer to this feature as "Short Property". > The data that falls into that category are namespaces and the > Master flag, but nothing prevents the addition of other properties. > > To define which Short Properties are available in an element, > the following elements are defined : > > Element-name Valid-parents Class-ID Element-type > SP * Any * [53][50] sub-elements > SPItem EBML,SP [C9] sub-elements > > The SP element can contain one declaration OR any number of SPItem > elements. > The SPItem element can only contain one declaration. You would put that in the EBML header ? Or the Class-ID is the thing found inside the element, the actual "property" ? <...> I don't really understand how it works. But we can discuss it next time. When my mind will be less tired ;) Steve