From ecartis at freelists.org Mon Jan 13 14:39:48 2003 From: ecartis at freelists.org (FreeLists Mailing List Manager) Date: Mon, 13 Jan 2003 08:39:48 -0500 (EST) Subject: Subscription confirmation for 'matroska-devel' Message-ID: # moritz at bunkus.org has requested that you be subscribed matroska-devel mailing list. # # To subscribe, reply to this message, leaving the message body # intact, or send the following lines in e-mail to # ecartis at freelists.org: // job appsub matroska-devel moritz at bunkus.org \ 3E22C1A4:667C.1:zngebfxnqriry // eoj From ecartis at freelists.org Mon Jan 13 14:44:21 2003 From: ecartis at freelists.org (FreeLists Mailing List Manager) Date: Mon, 13 Jan 2003 08:44:21 -0500 (EST) Subject: Ecartis command results: appsub matroska-devel moritz@bunkus.org 3E22C1A4:667C.1:zngebfxnqriry Message-ID: List context changed to 'matroska-devel' by following command. >> appsub matroska-devel moritz at bunkus.org 3E22C1A4:667C.1:zngebfxnqriry Subscribed. From christian.hj.wiesner at web.de Tue Jan 14 13:31:42 2003 From: christian.hj.wiesner at web.de (ChristianHJW) Date: Tue, 14 Jan 2003 13:31:42 +0100 Subject: [matroska-devel] @robux4 : API to access libmatroska Message-ID: <003f01c2bbc8$e631c570$a70aa8c0@mahlo.de> Hi Steve, i know you are busy preparing your party for 16th ( BTW, i loaded some of your mixes from the homepage you gave me, and i was very impressed !! ), so feel free to answer this question after it. Just wondered if you plan to make any major changes on the API ? Its probably necessary, because what i understand from Suiryc he had to link to old libmcf statically as the API didnt allow him to use the lib as he needs to ( Suiryc, could you pls. be more precise here ? ). It seems that some changes to the API are very well necessary ? Any more defined plans or thoughts here, so the 'tool' developers around libmatroska ( mainly kromyx , Suiryc, maybe spyder ) can think about this a bit before they will ge their hands on libmatroska ? Sorry if this is too early to ask, i know some things always clear up automatically on the process of making them, and not before :-D !! BTW : dont forget to fix the broken lacing code from libmcf ! BTW2 : With this email you will see a lot of people being in the cc list .... this is to inform all of you about the existing mail forwarders i created for matroska.org in zonedit. If anybody feels he wnats another email adress be used, or anybody or adress being added, gimme a shout ( Thanks BlackSun for pointing me to zonedit.com ) Regards Christian Sites : http://matroska.org http://virtualdubmod.sf.net http://virtualdub.everwicked.com Mailing lists : news://news.gmane.org gmane.comp.multimedia.matroska.general gmane.comp.multimedia.matroska.devel Soon : www.corecodec.com From moritz at bunkus.org Tue Jan 14 13:43:28 2003 From: moritz at bunkus.org (Moritz Bunkus) Date: Tue, 14 Jan 2003 13:43:28 +0100 Subject: [matroska-devel] Hi everyone Message-ID: <20030114124328.GA23155@bunkus.org> Hello everyone, I just wanted to say 'hello'. I'm Moritz Bunkus, author of the Ogg Media tools for Linux (http://www.bunkus.org/videotools/ogmtools). A coulpe of days ago Christian asked me if I wanted to help developping Matroska tools/media player integration under Linux and I happily agreed. I can also help porting the libraries themselves to Linux. So far I don't know if someone else is already working on Linux (or Unix in general) support for the Libs so I'll lend a hand where necessary. -- ==> Ciao, Mosu (Moritz Bunkus) From christian.hj.wiesner at web.de Tue Jan 14 14:17:55 2003 From: christian.hj.wiesner at web.de (ChristianHJW) Date: Tue, 14 Jan 2003 14:17:55 +0100 Subject: [matroska-devel] Re: Hi everyone References: <20030114124328.GA23155@bunkus.org> Message-ID: <006501c2bbcf$5a3348d0$a70aa8c0@mahlo.de> Hi mosu ! Thanks for showing by and offering help, we really appreciate it a lot !! FYI : robux4 is always developing the libraries such that they will compile in GCC also ( AFAIK ), so hopefully there will be no big need in helping to port the library itself to Linux ( he may tell better i guess ). Steve is busy with a big party now until 16th, after that he promised to invest the rest of his precious vacation into finishing libmatroska ( thats the spirit !!! ) . My original idea about your cooperation was to provide you with a fully working and tested libmatroska, once we have finished our alpha testing phase in a small circle of people, organized on 2 webboards : http://www.corecodec.com http://virtualdub.everwicked.com Why a fully tested libmatroska ? Well, i was hoping to reduce your precious time involved in this if we know for sure the lib is free of bugs. Of course, if you are planning to join the project in a much earlier phase, you are more than welcome !! It would be an excellent situation for us if the lib was used on 2 different OSes from 2 completely different encoding/muxing tools and players, because this would allow us to x-check if the API to access the lib is clear and not subject to misunderstandings and errors. Thank you so much Moritz, looking forward to hear your opinion on this. Christian BTW : all existing tools we are testing now ( VirtualdubMod from Suiryc/Cyrius for creating/editing and myFUN/kromyx's DirectShow parser ) are based on an old version of libmcf that Steve wrote almost one year ago. The files created with it are neither ressembling current MCF nor matroska, its just used to test the basic functionality. Steve will hopefully clarify in the next few days if any major changes about the API to access the lib will be necessary/sensible, so i would wait for his reply before trying to download libmcf from http://sf.net/projects/mcf , else you may loose a lot of time playing with an outdated library. Sites : http://matroska.org http://virtualdubmod.sf.net http://virtualdub.everwicked.com Mailing lists : news://news.gmane.org gmane.comp.multimedia.matroska.general gmane.comp.multimedia.matroska.devel Soon : www.corecodec.com ----- Original Message ----- From: "Moritz Bunkus" To: Sent: Tuesday, January 14, 2003 1:43 PM Subject: [matroska-devel] Hi everyone > > Hello everyone, > > I just wanted to say 'hello'. I'm Moritz Bunkus, author of the Ogg > Media tools for Linux (http://www.bunkus.org/videotools/ogmtools). > A coulpe of days ago Christian asked me if I wanted to help developping > Matroska tools/media player integration under Linux and I happily > agreed. I can also help porting the libraries themselves to Linux. So > far I don't know if someone else is already working on Linux (or Unix > in general) support for the Libs so I'll lend a hand where necessary. > > -- > ==> Ciao, Mosu (Moritz Bunkus) > From moritz at bunkus.org Tue Jan 14 14:38:19 2003 From: moritz at bunkus.org (Moritz Bunkus) Date: Tue, 14 Jan 2003 14:38:19 +0100 Subject: [matroska-devel] Re: Hi everyone In-Reply-To: <006501c2bbcf$5a3348d0$a70aa8c0@mahlo.de> References: <20030114124328.GA23155@bunkus.org> <006501c2bbcf$5a3348d0$a70aa8c0@mahlo.de> Message-ID: <20030114133818.GA30477@bunkus.org> Hi. Thanks for the overview. I thought I'd wait a bit and see what you've got so far and only start working on things once you have a libmatroska (at least a bit more than you have now ;)). So I'll just listen in on the conversation. Once you think you have something that I can work with just tell me. BTW: I've subscribed to this list, so no need to CC me :) -- ==> Ciao, Mosu (Moritz Bunkus) From suiryc at yahoo.com Tue Jan 14 15:16:48 2003 From: suiryc at yahoo.com (Cyrius) Date: Tue, 14 Jan 2003 06:16:48 -0800 (PST) Subject: [matroska-devel] Re: Hi everyone In-Reply-To: <20030114133818.GA30477@bunkus.org> Message-ID: <20030114141648.19464.qmail@web12908.mail.yahoo.com> --- Moritz Bunkus wrote: > > Hi. > > Thanks for the overview. I thought I'd wait a bit > and see what you've > got so far and only start working on things once you > have a libmatroska > (at least a bit more than you have now ;)). > > So I'll just listen in on the conversation. Once you > think you have > something that I can work with just tell me. > > BTW: I've subscribed to this list, so no need to CC > me :) > > -- > ==> Ciao, Mosu (Moritz Bunkus) > Hi Mosu :) Great to see you in this project :) __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com From Paul at msn.com Wed Jan 15 05:04:28 2003 From: Paul at msn.com (Pamel) Date: Tue, 14 Jan 2003 22:04:28 -0600 Subject: [matroska-devel] Menuing System Message-ID: I had some ideas for a menuing system. The first is why not exactly duplicate a DVD menu system and then alter it to fit into a stream. I admittedly know next to nothing about DVD menu's, other than they are spread out over several files. I also don't know if the design of their menu system is protected by copyrights that require fees to use. The other consists of 2 seperate parts. First, the background. You could use a single frame, or mutliple frames to have a movie going in the background. This is simply a video track with an (optional) accompanying audio track. All of the menu backgrounds could be contained in one long stream with no seperation, just like in a VOB. Second is the control track. The could be done using a Variation of USF. Actually, all that would be required is adding a few elements to the USF for a very simple scripting. Ala, menu allows moving selection up/down, and what the up/down text elements are, and text color changes when selected. Alot of other more comlicated things could be done such as changing text position, size, font, etc the exact same way. This would be contained in what would basically amount to a subtitle track, ebml'd and timestamped the same way as USF is. Also, acting as a control track that would contain simple commands about a menu track that just contained information such as: Tracks 4 and 5 are part of the menu. (4=Video, 5=Audio) Menu screen 1 is from 0:00-2:00, repeating starting at 0:30 once 2:00 is reached. Because the background would be rendered using the same filters as the video playback, there would be no extra software required. And because the menu selections would be using a USF variant, the same code could be used for displaying the menu items. The only thing extra would be the scripting, but that should be relatively simple. An example of a menu would look like this: The Menu/Contol track is track 8. Either private codec data or the first elements define the background as tracks 6 for video and 7 for audio. 0:00 Menu starts playing a video clip. 0:07 Text items start to fly out, or appear on the screen using standard USF code. 0:13 The text items are in place, but hit the end of their duration, and are replaced by identical menu items at the exact same time so you don't notice. 0:13+ User can use arrow keys to select options. (Mouse support can be completed last) Selecting one option sends control information to the player/filter to skip forward to 2:00, which is a different menu. 1:59 Time stamped control information tells the player/filter to skip back to 0:13, which sets the audio/video/menu to 0:13 where all of the menu items are drawn again in the same place. 2:00 Background may change at this point depending on complexity of menu, or the person that set it up could have used one continuous video sequence. 2:02 New text items start to fly out, alot like at 0:07. 2:04 Text items are seamlessly replace by menu items, like at 0:13. etc, etc...... There are a lot of things you could do with this, like having the menu items continue to move around the screen. The only reason that I have it starting off with text items first is that I can have the text fly around with cool effects, and then have stationary menu points that would be instantly redrawn in the same place if the menu timed out and restarted again at 0:13. This wouldn't be quite as full featured as the DVD menuing system, but it would be close. And, again, it would be extensible. And, it should be streamable and easy to fit into OGG. Of course, all of this would require that there either be a filter or player that could understand the menu/control track information to interact with with it and allow information from that track to move the seekbar to another position and change the tracks being displayed (so you could play the actual video the menu was for). A proper crossplatform full-featured codec API system would also help. Pamel P.S. I'm posting this also at corecodec.com and possibly at doom9 for those that aren't on the mailing list. From christian.hj.wiesner at web.de Wed Jan 15 13:28:14 2003 From: christian.hj.wiesner at web.de (ChristianHJW) Date: Wed, 15 Jan 2003 13:28:14 +0100 Subject: [matroska-devel] Compilation of kromyx's latest Dshow parser Message-ID: <004001c2bc91$93bc82c0$a70aa8c0@mahlo.de> Hi, Jan has uploaded a new version of his Dshow parser to MCF CVS, which fixed the problem with XviD DirectShow filter ( DivX decoder was called instead ). He told me he first wants to fix AC3 audio also before he will send me a new build, but i am sooooo nosy to test XviD playback of my existing test movies, so i wanted to ask if somebody can make a quick compile from MCF CVS for me ? Thanks Christian Sites : http://matroska.org http://virtualdubmod.sf.net http://virtualdub.everwicked.com Mailing lists : news://news.gmane.org gmane.comp.multimedia.matroska.general gmane.comp.multimedia.matroska.devel Soon : www.corecodec.com From spyder482 at yahoo.com Wed Jan 15 14:44:42 2003 From: spyder482 at yahoo.com (John Cannon) Date: Wed, 15 Jan 2003 07:44:42 -0600 Subject: [matroska-devel] Re: Compilation of kromyx's latest Dshow parser References: <004001c2bc91$93bc82c0$a70aa8c0@mahlo.de> Message-ID: Sorry, no DShow SDK here... :( John From outlyer at outlyer.net Fri Jan 17 20:17:53 2003 From: outlyer at outlyer.net (Outlyer (Toni Corvera)) Date: Fri, 17 Jan 2003 20:17:53 +0100 Subject: [matroska-devel] Re: Compilation of kromyx's latest Dshow parser In-Reply-To: <004001c2bc91$93bc82c0$a70aa8c0@mahlo.de> References: <004001c2bc91$93bc82c0$a70aa8c0@mahlo.de> Message-ID: As this is my first message here I'd like to say Hello to all of you. Now, let's go on: I've just compiled it to do some testings, it's the first time I compile the dll and so... you know ;) had some problems but finally I got it (got some errors at compilation time but it has been generated and seems to be working ok). So if anyone else want to download it just check: http://outlyer.net/descargas/video/MCFParser-20031701-1930.zip Haven't done much testing yet, of course, so if something goes wrong or your PC explodes it's maybe my fault but I won't admit it :D ChristianHJW wrote: > Hi, > > Jan has uploaded a new version of his Dshow parser to MCF CVS, which fixed > the problem with XviD DirectShow filter ( DivX decoder was called instead ). > He told me he first wants to fix AC3 audio also before he will send me a new > build, but i am sooooo nosy to test XviD playback of my existing test > movies, so i wanted to ask if somebody can make a quick compile from MCF CVS > for me ? > > Thanks > > Christian > > Sites : http://matroska.org > http://virtualdubmod.sf.net > http://virtualdub.everwicked.com > Mailing lists : news://news.gmane.org > gmane.comp.multimedia.matroska.general > gmane.comp.multimedia.matroska.devel > Soon : www.corecodec.com > > > -- Outlyer mailto:outlyer at outlyer.net http://outlyer.net clave p?blica pgp en http://outlyer.net/claves/outlyer.asc http://matroska.org From christian at matroska.org Sat Jan 18 05:35:24 2003 From: christian at matroska.org (Christian HJ Wiesner) Date: Sat, 18 Jan 2003 05:35:24 +0100 Subject: [matroska-devel] Re: Compilation of kromyx's latest Dshow parser In-Reply-To: References: <004001c2bc91$93bc82c0$a70aa8c0@mahlo.de> Message-ID: <3E28D98C.7040608@matroska.org> Thanks Toni, your compilation works and is uploaded to the normal matroska alpha downloads folder ( you all know the URL ;-) ) I guess from the size of it its not a debug version, but thats quite ok i guess. XviD video plays fine with it now, Jan really makes an excellent job !! Regards Christian Outlyer (Toni Corvera) wrote: > As this is my first message here I'd like to say Hello to all of you. > Now, let's go on: > > I've just compiled it to do some testings, it's the first time I compile > the dll and so... you know ;) had some problems but finally I got it > (got some errors at compilation time but it has been generated and seems > to be working ok). > > So if anyone else want to download it just check: > http://outlyer.net/descargas/video/MCFParser-20031701-1930.zip > > Haven't done much testing yet, of course, so if something goes wrong or > your PC explodes it's maybe my fault but I won't admit it :D > > ChristianHJW wrote: > >>Hi, >> >>Jan has uploaded a new version of his Dshow parser to MCF CVS, which fixed >>the problem with XviD DirectShow filter ( DivX decoder was called instead ). >>He told me he first wants to fix AC3 audio also before he will send me a new >>build, but i am sooooo nosy to test XviD playback of my existing test >>movies, so i wanted to ask if somebody can make a quick compile from MCF CVS >>for me ? >> >>Thanks >> >>Christian >> >>Sites : http://matroska.org >> http://virtualdubmod.sf.net >> http://virtualdub.everwicked.com >>Mailing lists : news://news.gmane.org >>gmane.comp.multimedia.matroska.general >>gmane.comp.multimedia.matroska.devel >>Soon : www.corecodec.com >> >> >> > > http://matroska.org From outlyer at outlyer.net Sat Jan 18 12:00:14 2003 From: outlyer at outlyer.net (Outlyer (Toni Corvera)) Date: Sat, 18 Jan 2003 12:00:14 +0100 Subject: [matroska-devel] Re: Compilation of kromyx's latest Dshow parser In-Reply-To: <3E28D98C.7040608@matroska.org> References: <004001c2bc91$93bc82c0$a70aa8c0@mahlo.de> <3E28D98C.7040608@matroska.org> Message-ID: Christian HJ Wiesner wrote: > I guess from the size of it its not a debug version, but thats quite ok > i guess. > > XviD video plays fine with it now, Jan really makes an excellent job !! The funny thing is that I wasn't able to compile the debug version, only release. But I guess people interested in debugging should be able to compile it :P ---Toni http://matroska.org From christian.hj.wiesner at web.de Thu Jan 16 12:00:02 2003 From: christian.hj.wiesner at web.de (ChristianHJW) Date: Thu, 16 Jan 2003 12:00:02 +0100 Subject: [matroska-devel] matroska advanced menuing system with playlists ... discussion has started Message-ID: <003f01c2bd4e$6c166160$a70aa8c0@mahlo.de> Hi, Pamel opened a specific thread on corecodec.com about the matrosla menuing system and also posted a basic EBML file structure : http://www.corecodec.com/modules.php?op=modload&name=phpBB2&file=viewtopic&p =1595#1595 Please read it and reply there ... Christian Sites : http://matroska.org http://virtualdubmod.sf.net http://usf.corecodec.org http://virtualdub.everwicked.com Mailing lists : news://news.gmane.org gmane.comp.multimedia.matroska.general gmane.comp.multimedia.matroska.devel Soon : www.corecodec.com http://matroska.org From christian at matroska.org Fri Jan 17 07:33:30 2003 From: christian at matroska.org (Christian HJ Wiesner) Date: Fri, 17 Jan 2003 07:33:30 +0100 Subject: [matroska-devel] Reals codec API - an alternative to UCI/UFI/UMI ? Message-ID: http://forum.doom9.org/showthread.php?s=&postid=243045#post243045 http://matroska.org From spyder482 at yahoo.com Fri Jan 17 16:45:21 2003 From: spyder482 at yahoo.com (John Cannon) Date: Fri, 17 Jan 2003 09:45:21 -0600 Subject: [matroska-devel] Re: Reals codec API - an alternative to UCI/UFI/UMI ? References: Message-ID: Christian, I am reading the lists through Gmane so you don't have to CC to me everytime... http://matroska.org From steve.lhomme at free.fr Fri Jan 17 09:43:48 2003 From: steve.lhomme at free.fr (Steve Lhomme) Date: Fri, 17 Jan 2003 09:43:48 +0100 Subject: [matroska-devel] Re: Log from Xiph.org .. for your convenience In-Reply-To: <3E2713AF.60901@matroska.org> References: <3E2713AF.60901@matroska.org> Message-ID: <3E27C244.6090704@free.fr> Christian HJ Wiesner wrote: > Apparently the idea that granulepos is a feature is > *completely* lost on robUx4. > You wish (and so do I) > Using granulepos means that you can use *any kind of > timekeeping you want.* > SMPTE? Fine. > Standard minutes and seconds? Again, fine. EBML permits that and updating the code in 2 minutes (longest is to compile, make a new release and upload it). That's what may be missing in OGG (extending with this kind of thing). Maybe you can add it out of the granulepos, which is how I would like things to be. But I doubt it. Unlike OGG we don't need to stream everything. So only time based information (SMPTE is too) is worth for us. http://matroska.org From steve.lhomme at free.fr Fri Jan 17 17:10:26 2003 From: steve.lhomme at free.fr (Steve Lhomme) Date: Fri, 17 Jan 2003 17:10:26 +0100 Subject: [matroska-devel] Source Code Message-ID: <3E282AF2.3040200@free.fr> Hi everyone, As promised, I'm back on coding libmatroska/libebml. As I've been working a lot with GCC lately I had problems making the code work again in VC++ (because the GCC I use has no idea on what a namespace is). I finally managed to compile the little example I made on VC++. I uploaded it on http://mukoli.free.fr/libmatroska.v0.0.0.zip (473KB) The next steps on the code are : - debug (an error has appeared in MSVC) - implement EBML elements that can be used at all levels - take the libmcf API used in VDubMod and map it to the new matroska/ebml objects. http://matroska.org From steve.lhomme at free.fr Fri Jan 17 17:25:54 2003 From: steve.lhomme at free.fr (Steve Lhomme) Date: Fri, 17 Jan 2003 17:25:54 +0100 Subject: [matroska-devel] Re: Source Code In-Reply-To: <3E282AF2.3040200@free.fr> References: <3E282AF2.3040200@free.fr> Message-ID: <3E282E92.9020206@free.fr> Steve Lhomme wrote: > Hi everyone, > > As promised, I'm back on coding libmatroska/libebml. > As I've been working a lot with GCC lately I had problems making the > code work again in VC++ (because the GCC I use has no idea on what a > namespace is). > > I finally managed to compile the little example I made on VC++. > I uploaded it on http://mukoli.free.fr/libmatroska.v0.0.0.zip (473KB) > > The next steps on the code are : Update of the list (now that I remember better the code) - debug (an error has appeared in MSVC) - implement EBML elements that can be used at all levels - take the libmcf API used in VDubMod and map it to the new matroska/ebml objects. - Unknown size reading (requires the semantic context) - Unknown tag read -- http://matroska.org From christian.hj.wiesner at web.de Fri Jan 17 17:58:37 2003 From: christian.hj.wiesner at web.de (ChristianHJW) Date: Fri, 17 Jan 2003 17:58:37 +0100 Subject: [matroska-devel] Re: Source Code References: <3E282AF2.3040200@free.fr> <3E282E92.9020206@free.fr> Message-ID: <00af01c2be49$ae9e5fa0$c80aa8c0@mahlo.de> ----- Original Message ----- From: "Steve Lhomme" To: Sent: Friday, January 17, 2003 5:25 PM Subject: [matroska-devel] Re: Source Code > Steve Lhomme wrote: > > Hi everyone, > > As promised, I'm back on coding libmatroska/libebml. Well, what can i say ... i am so exhausted from the bas and unnecessary quarrel with Xiph on the one hand ( which we didnt start ), and excited about the future of our little project on the other hand. Cant wait until libmatroska will be here :-) !! Its a bit like getting another baby .... lol ! Christian http://matroska.org From steve.lhomme at free.fr Sat Jan 18 12:17:59 2003 From: steve.lhomme at free.fr (Steve Lhomme) Date: Sat, 18 Jan 2003 12:17:59 +0100 Subject: [matroska-devel] AMD Code Analyst Message-ID: <3E2937E7.8060304@free.fr> I just saw a mention about this in the LAME ML : http://www.amd.com/us-en/Processors/DevelopWithAMD/0,,30_2252_3604,00.html "CodeAnalyst is a software tool designed to assist software developers in optimizing their software for AMD processors. CodeAnalyst 1.2 provides three main methods for analyzing software: Timer-Based Profiling, Pipeline Analysis, and Performance Monitoring." Very interresting software for high performance coding. (no spyder, no ASM ;) http://matroska.org From christian.hj.wiesner at web.de Sun Jan 19 20:08:52 2003 From: christian.hj.wiesner at web.de (ChristianHJW) Date: Sun, 19 Jan 2003 20:08:52 +0100 Subject: [matroska-devel] 1. Vorbis and other Xiph codecs in matroska 2. Codec muxing description for every format ( recommendation ) to put on our website ? Message-ID: <015601c2bfee$37128f00$c80aa8c0@mahlo.de> Hi, i know this is a hot thing to talk about right now, but with matroska alpha date coming closer and closer, and spyder working on the Ogg transmuxer i thought it was necessary to raise the point. Suiryc gave me some very good idea how it should be done, and i guess he discussed with spyder also ( hopefully ). Generally speaking, simply all the data packets from the Ogg container pages should be taken and put into matroska, without any major changes. As i understood from suiryc some Vorbis packets are data only, while others are tagged as holding specific info about the stream type, etc. In any case, the Vorbis decoder knows how to handle them and all it expects is to receive the packets same way as if they were stored in an Ogg container before. The discussion, although not very complicated because Vorbis doesnt leave you with many options here, lead me to another idea : In order to avoid incompatibilities between matroska files generated from different programs and developers, wouldnt it make sense to add a kind of 'recommendation' to our homepage for every codec/compression format, so developers can read how to mux the data from each codec into matroska preferably ? Especially protected formats like Dolby AC3/AAC for sure need a kind of 'special treatment' here, as we have to make sure the demuxed streams can be decoded in external ( maybe Dshow based ) decoders, as for sure we as the matroska team can not make specific AC3 decoder plugins based on UCI, for the very well known licensing problems we had to fear. Maybe formats like AC3/AAC should not have a 'native' track typ at all to avoid these problems, but be only used in Dshow compatibility mode, using UUID/GUID to identify ? In my idea the developers could go to the matroska homepage and look up how exactly a MPEG2/1 video stream was to be handled when being muxed into a matroska file, bearing in mind how complicated the structure of MPEG files is ( remember Alex' comments about the different layers of it, what layers to copy/read/trash ). What you think ? Christian http://matroska.org From pfk at fuchs.offl.uni-jena.de Mon Jan 20 00:00:56 2003 From: pfk at fuchs.offl.uni-jena.de (Frank Klemm) Date: Mon, 20 Jan 2003 00:00:56 +0100 Subject: [matroska-devel] LFE: Some information In-Reply-To: <015601c2bfee$37128f00$c80aa8c0@mahlo.de>; from christian.hj.wiesner@web.de on Sun, Jan 19, 2003 at 08:08:52PM +0100 References: <015601c2bfee$37128f00$c80aa8c0@mahlo.de> Message-ID: <20030120000055.A25962@fuchs.offl.uni-jena.de> Some proposals for storing meta data which are useful in a Video stream to decode a LFE channel correctly: * Level L - level of the LFE channel when mixed to full size speakers - unit of measurement: dB - default: +10 dB - useful range: -6 dB...12 dB * Delay D - delay of the LFE channel when mixed to full size speaker - unit of measurement: ms - default: 0 ms - useful range: -12 ms...+12 ms * Phase P - phase changes of signal when mixed to full size speaker - unit of measurement: degree/? - default: 0? - useful range: 0?...+360? (2 pi periodic) + 0? in phase + 180? out of phase + 90? hilbert transformed + 270? inverse hilbert transformed Note that Delay and Phase are two DIFFERENT properties, although in literature these two items are NEARLY ALWAYS mixed. You can only transform delay into phase and vs. versa for ONE given frequency. A Phase P introduces a constant phase for all frequencies: phi (omega) = P A Delay D introduces a variable phase for all frequencies: phi (omega) = - D * omega Both gives a: phi (omega) = P - D * omega delay can be extracted by the well known formula: D = - d phi / d omega removing this from phi(omega) gives the constant phase term, which is nearly always something in the range 178...182? or -2?...+2?. Compensation of delay errors of a subwoofer by phase errors and vice versa is a nearly always used technology to compensate "phi" errors. It is better than no compensation to avoid holes in the frequency response, but you still have delay errors which are audible (in the Internet you find several paper about the audibility of such errors). I will add these three items to the native SV8 format (something similar to MPEG-4 ADIF). These are stored there in the Sv8 header. In a container format these data has to be stored in the container, like replay gain values. -- Frank Klemm, currently writing some tools to process multi channel audio (available tools are completely useless, they terribly failed). http://matroska.org From spyder482 at yahoo.com Tue Jan 21 04:27:15 2003 From: spyder482 at yahoo.com (John Cannon) Date: Mon, 20 Jan 2003 21:27:15 -0600 Subject: [matroska-devel] Re: 1. Vorbis and other Xiph codecs in matroska 2. Codec muxing description for every format ( recommendation ) to put on our website ? References: <015601c2bfee$37128f00$c80aa8c0@mahlo.de> Message-ID: I haven't yet discussed how to put the packets into Matroska. First I wanted to get the reading down. I think that I can easily adapt Cyrius' code into what I need. I should only need to remove the AVI writing portions and then modify the demuxing code to instead of writing out a new file per stream, simply remux into a matroska file. I haven't thought about it until now but maybe Moritz Bunkus' ogmtools would be a more portable way to start. Anyway, about packet muxing, I just figured we could take the raw packets and mux them in, leaving headers etc. for Vorbis and the other Ogg codecs. For the DShow/VfW muxings, we can extract the frames and mux as if it were AVI, setting the appropriate details in the matroska headers(No need for duplicate info that will only need to be cut anyway). As far as subtitles, we can use a simple ASCII sub format to start and my transmuxer can simply convert the timing. John http://matroska.org From Paul at msn.com Tue Jan 21 05:27:02 2003 From: Paul at msn.com (Pamel) Date: Mon, 20 Jan 2003 22:27:02 -0600 Subject: [matroska-devel] Re: 1. Vorbis and other Xiph codecs in matroska 2. Codec muxing description for every format ( recommendation ) to put on our website ? References: <015601c2bfee$37128f00$c80aa8c0@mahlo.de> Message-ID: Has anyone bothered to ask Xiph how they think it should be done? Pamel http://matroska.org From christian.hj.wiesner at web.de Mon Jan 20 11:45:09 2003 From: christian.hj.wiesner at web.de (ChristianHJW) Date: Mon, 20 Jan 2003 11:45:09 +0100 Subject: [matroska-devel] File ID / Track ID Message-ID: <001401c2c071$03ffd310$a70aa8c0@mahlo.de> Hi all, i was talking to Steve already about this and thought i should drop an email to the list also. If any of you have been doing p2p networking ( i sometimes do :D ), you will certainly agree there is nothing more annoying than those morons spreading fakes around. They probably think they are very cool or simply love to fool others, i dont know. In any case its a major waste of bandwidth, and the matroska file ID nr. ( 128 bit MD5 of block headers ) could be used to fight this, once p2p app developers start to support matroska by reading file headers and validating the info given in it. Now, as we all know its happening pretty often that there are more than one version of a file floating around in the internet, people mux different subtitles with it, remove subtitles, or will add covers and lyrics once matroska will be available to do so. In any case, those mods would result in a new file ID number ( correct ? ), while the basic content ( = the main video stream ) would be exactly the same. A matroska ID was best used when there was a central, independant database server hosting all ID nrs of VALID ( = no fakes ) files, such that users can compare the indicated ID from the p2p app with the one given in the database for a specific movie he wants to have. If the 2 IDs match he can download the file with ( almost ) no risk, except the user faking the file did more than just rename it, but edited the ID nr. using spyder's or Pamel's XML/EBML tools. While this is of course well possible it will certainly help to reduce the number of fakes floating around, as today they people faking files simply have to rename them ( every fool can do that ). Now, the big problem i see with that is that pretty fast there will be a huge number of valid IDs for a certain movie, given the number of mods that are done based on a certain video stream ( different languages, subtitles, etc. ). This broght me to the idea of introducing another ID number, calculated specifically for the first video stream in each file, thus allowing to identify the video stream itself AND NOT the file. This ID should be calculated on the frames itself, and not on the block headers, but of course only for a certain number of frames ( 10, 20, whatever ). To make sure the trailer at the beginning of the file ( the same may be used for many movies ) is not used for this ID the MD5 of the COMPLETE number of blocks following block number 200 ( means 201, 202, 203, 204, 205, etc. ..210 ) should be calculated and stored in the track header as a unique identifier for this particular video stream. If the file is shorter than 200 blocks ( = frames ) than simply the last 10 blocks can be used. Of course, it is absolutely clear that when doing so a VALID video stream ( no fake ) will get a new ID number when a user decides to cut away the first 100 frames or so. This doesnt hurt much, the only problem raised was that a new ID number would be created indicating a certain movie, so the central database had to be updated accordingly. If this is not done, for whatever reason, the user who decided to cut the first 100 frames off could find himself in a situation that nobody wants to download his movie, because the IDs dont match with the central database. Thats all, and will hopefull also lead to less variations from the same movie floating around. On a sidenote : While it was impossible for any p2p application ( even if the devs love matroska ) to verify if a matroska file ID was faked by the user using any EBML editing tool ( you can only generate/verify this ID if you have access to all the block headers in the file, means you need the whole file ), this was very well possible for the track ID i am suggesting above !! The p2p app could scan the file when hashing it, and if this hash is new ( dont ask me what exactly they are hashing, i guess only filename, size, etc. ) they could decide to read the track ID, load the 10 blocks after block #200 and verify the ID ;-) !! Any comments on the idea of track ID are well appreciated. Christian http://matroska.org From steve.lhomme at free.fr Mon Jan 20 14:45:11 2003 From: steve.lhomme at free.fr (Steve Lhomme) Date: Mon, 20 Jan 2003 14:45:11 +0100 (CET) Subject: [matroska-devel] Re: File ID / Track ID In-Reply-To: <001401c2c071$03ffd310$a70aa8c0@mahlo.de> References: <001401c2c071$03ffd310$a70aa8c0@mahlo.de> Message-ID: <1043070311.3e2bfd677d3ec@imp.free.fr> En r?ponse ? ChristianHJW : > Now, as we all know its happening pretty often that there are more than > one version of a file floating around in the internet, people mux > different subtitles with it, remove subtitles, or will add covers and > lyrics once matroska will be available to do so. In any case, those mods > would result in a new file ID number ( correct ? ), while the basic > content ( = the main video stream ) would be exactly the same. No, the current FileID is not based on the content anymore. It is just an ID that should be made as unique as possible (ie as random/large as possible). SegmentUID 2 [73][A4] - - - binary A unique ID to identify the current segment between many others (128 bits). There can also be an optional element to sign the content of an element (from a Segment to a Cluster) and this one is based on the content. SignatureSlot 1+ [1B][53][86][67] * - - sub-elements Contain signature of some (coming) elements in the stream. So, a Track could be signed this way. But note that the current system is not fully defined. It uses a public key architecture but doesn't define who owns the private key. > A matroska ID was best used when there was a central, independant > database server hosting all ID nrs of VALID ( = no fakes ) files, such > that users can compare the indicated ID from the p2p app with the one > given in the database for a specific movie he wants to have. If the 2 > IDs match he can download the file with ( almost ) no risk, except the > user faking the file did more than just rename it, but edited the ID nr. > using spyder's or Pamel's XML/EBML tools. While this is of course well > possible it will certainly help to reduce the number of fakes floating > around, as today they people faking files simply have to rename them ( > every fool can do that ). > > Now, the big problem i see with that is that pretty fast there will be a > huge number of valid IDs for a certain movie, given the number of mods > that are done based on a certain video stream ( different languages, > subtitles, etc. ). This broght me to the idea of introducing another ID > number, calculated specifically for the first video stream in each file, > thus allowing to identify the video stream itself AND NOT the file. The bigger problem I see is : who is the authority to say a movie with ID (signature on some content to define) XYZ is valid or not ? The guy making the fake ? :( > This ID should be calculated on the frames itself, and not on the block > headers, but of course only for a certain number of frames ( 10, 20, > whatever ). To make sure the trailer at the beginning of the file ( the > same may be used for many movies ) is not used for this ID the MD5 of > the COMPLETE number of blocks following block number 200 ( means 201, > 202, 203, 204, 205, etc. ..210 ) should be calculated and stored in the > track header as a unique identifier for this particular video stream. If > the file is shorter than 200 blocks ( = frames ) than simply the last 10 > blocks can be used. A working system should not have fixed values like this but should work in all cases. > Of course, it is absolutely clear that when doing so a VALID video > stream ( no fake ) will get a new ID number when a user decides to cut > away the first 100 frames or so. This doesnt hurt much, the only problem If the original file is split in different segments every 100 frames, it would help the user to split a movie in many "signed" files. But the P2P system would have to treat matroska in a special way for each segment and signed element. I don't see such thing happening anytime soon (both peers have to agree on the way to treat matroska files in such a system !). http://matroska.org From christian.wiesner at mahlo.com Tue Jan 21 09:52:34 2003 From: christian.wiesner at mahlo.com (Christian HJ Wiesner) Date: Tue, 21 Jan 2003 09:52:34 +0100 Subject: [matroska-devel] Re: 1. Vorbis and other Xiph codecs in matroska 2. Codec muxing description for every format ( recommendation ) to put on our website ? Message-ID: Paul, while this is a very good idea actually, with respect to their claim we are not interested in a cooperation, i wonder if it was a wise thing to do in the present situation ? Best way was probably to email Monty directly, and to tell him how we are planning to do it. An excuse had to be sent out front in the same email that we have to bother him here ( as i understood Suiryc its normally technically absolutely clear how it should be done ), but we wnated to inform him about our plans so he can comment on them. I would volunteer to send this email if anybody can provide me with a short, but technically more founded description how we plan to handle it. Of course i feel it would be much better if the responsible project manager ( Spyder, Suiryc ? ) would contact him directly, as it may happen that my name is causing negative reaction within XipH meanwhile, for whatever reason. What you all think ? "Pamel" schrieb im Newsbeitrag news:... > Has anyone bothered to ask Xiph how they think it should be done? > Pamel http://matroska.org From christian.hj.wiesner at web.de Tue Jan 21 13:10:07 2003 From: christian.hj.wiesner at web.de (ChristianHJW) Date: Tue, 21 Jan 2003 13:10:07 +0100 Subject: [matroska-devel] Job Proposal Message-ID: <003001c2c146$0b33a280$a70aa8c0@mahlo.de> CC : de_xt ( XCD developer ; mode 2 form 2 ) Hi, with the launching of libmatroska getting closer and Suiryc eager to link to it from VdubMod so we can start to create spec compliant matroska files, here is a job proposal for an important tool we need to be done within the next say 6 - 8 months. Scope of this tool is 1. Repair damaged matroska files - seek for ECC elements in the file, restore protected content if possible - rebuild index etc. 2. Reorder Blocks according to time stamps, e.g. after the file was edited. This process can be described as 'hinting' also, as it may be a preparation step to be able to stream the file or to burn it onto disk. 3. Add additional EDC/ECC to a file to prepare it for mode 2 form 2 burning. User can define a max file size for that, typical is 795 MB ( max. mode2 form2 for a 80 mins CD ). The tool should - scan the file - indetify those areas that need the most protection - insert EDC/ECC elements ( details about ECC to be clarified with Frank Klemm ) until the max file size is reached - reorder/rewrite file to prepare for burning Important : compliancy with actual XCD backup creator must be assured in any case !! If you are uncertain, double check with de_xt before implementing. Supported OSes : WinME/2k/XP, Linux/*nix, MacOS, BeOS ( OBOS ) Preferred Language : Delphi or Java Anybody reading this list interested in accepting the job ;-) ?? Of course, automatic transmuxing tools from OGM/OGG/AVI have higher priority :-D ! Regards Christian http://matroska.org From steve.lhomme at free.fr Tue Jan 21 20:45:51 2003 From: steve.lhomme at free.fr (Steve Lhomme) Date: Tue, 21 Jan 2003 20:45:51 +0100 Subject: [matroska-devel] matroska on lossy CDs Message-ID: <3E2DA36F.2020208@free.fr> As said in this thread : http://www.corecodec.com/modules.php?op=modload&name=phpBB2&file=viewtopic&t=261 Yesterday Christian raised an interresting question on how we can handle matroska files in XCD, ie mode 2 form 2 CDs. For those not aware, it's a way to write more data on a CD but in the other end you remove built-in error correction. So you can only use formats that have built-in error detection (EDC), and even better error correction (ECC) in such CDs. The current situation of matroska is that the EDC (CRC32) is possible at all levels but mandatory nowhere. There is no elements for ECC yet, but I think we need to discuss with Frank about it (he knows a lot about ECC and has some working code). I guess it would be similar to CRC32 is use (possible everywhere but mandatory nowhere). So that means we are very flexible (unlike any other existing container). Since on XCD you usually put only one file (named SOMETHING.dat) on one CD, you probably want the best protection for that CD/file. Most of the time the matroska files you capture or download won't have ECC or EDC inside (that's a possibility) so we can imagine a tool to add them in the file to burn. And depending on the final file size you want (probably the max size of data you can fit on your CD) that tool will decide where EDC should be used and where ECC should be used to maximize reliability of the file over time. That's what the flexibility of EBML allow us to do, and that no other container can afford or do technically. The fun part is that a file you download with too much protection and too large for a CD could still fit on that CD by removing some of them. Frank, could you explain here (ML) a bit more about your ECC idea ? I browsed a bit on your MPC pages about it today. But the Hamming thing is still a bit obscure to me. What we need to add is one or more global matroska elements to handle ECC correctly (probably based on your work/study). One of the problem I see is that your system is based on bits, not octet, so it would be a bit tricky to express that in simple EBML (a complex way could tell the numbers of bits to use). The other problem is that adding ECC to a Cluster (or just a Block in the BlockAddition) with data as large as a few MB, the ECC calculus could take a lot of CPU and be very large. http://matroska.org From Paul at msn.com Wed Jan 22 01:08:20 2003 From: Paul at msn.com (Pamel) Date: Tue, 21 Jan 2003 18:08:20 -0600 Subject: [matroska-devel] Converting Subtitles Message-ID: Until it is decided how to store other subtitle formats in Matroska, it appears that we should come up with a way to convert other subtitle formats into something that can be used right now with Matroska. I propose a simple USF conversion. The examples given by Toff are very complex because of all of the options that are being shown off, but USF can be used as a very simple format. For example: This is an example of some subs produced with subrip. 1 00:01:04,274 --> 00:01:06,390 Thebes: City of the Living. 2 00:01:07,634 --> 00:01:10,068 Crown jewel of Pharaoh Seti the First. 3 00:01:13,194 --> 00:01:16,664 Home of lmhotep, Pharaoh's high priest. This is what it would look like converted to USF. Thebes: City of the Living. Crown jewel of Pharaoh Seti the First. Home of lmhotep, Pharaoh's high priest. It is such a simple conversion, that this could easily be used to mux other subtitles into Matroska. All we need is a directshow filter to show them with. Pamel http://matroska.org From kimmo at poispakkoruotsi.com Wed Jan 22 08:15:23 2003 From: kimmo at poispakkoruotsi.com (Kimmo) Date: Wed, 22 Jan 2003 09:15:23 +0200 Subject: [matroska-devel] Re: Converting Subtitles References: Message-ID: <000b01c2c1e6$0bf88370$0100a8c0@kimmo> ----- Original Message ----- From: "Pamel" To: Sent: Wednesday, January 22, 2003 2:08 AM Subject: [matroska-devel] Converting Subtitles > Until it is decided how to store other subtitle formats in Matroska, it > appears that we should come up with a way to convert other subtitle formats > into something that can be used right now with Matroska. I propose a simple > USF conversion. The examples given by Toff are very complex because of all > of the options that are being shown off, but USF can be used as a very > simple format. For example: > > This is an example of some subs produced with subrip. > > 1 > 00:01:04,274 --> 00:01:06,390 > Thebes: City of the Living. > > 2 > 00:01:07,634 --> 00:01:10,068 > Crown jewel of Pharaoh Seti the First. > > 3 > 00:01:13,194 --> 00:01:16,664 > Home of lmhotep, Pharaoh's high priest. > > > > This is what it would look like converted to USF. > > > > > Thebes: City of the Living. > > > > Crown jewel of Pharaoh Seti the First. > > > > Home of lmhotep, Pharaoh's high priest. > > > > > It is such a simple conversion, that this could easily be used to mux other > subtitles into Matroska. All we need is a directshow filter to show them > with. What about VobSub support? If we'd use the native subtitles in DVD without OCR. Would you include all directshow filters in one pack finally+ http://matroska.org From Paul at msn.com Wed Jan 22 18:49:04 2003 From: Paul at msn.com (Pamel) Date: Wed, 22 Jan 2003 11:49:04 -0600 Subject: [matroska-devel] Re: Converting Subtitles References: <000b01c2c1e6$0bf88370$0100a8c0@kimmo> Message-ID: "Kimmo" wrote > What about VobSub support? If we'd use the native subtitles in DVD without > OCR. Would you include all directshow filters in one pack finally+ This is a valid question, however the purpose of the topic is to get any subtitles in Matroska ASAP. Storing the native DVD subtitles in Matroska early on will be very important for a couple of reasons. They are already formatted properly and will often look better than forms and they support displaying any language or character because of their picture nature. But it needs to be decided how to store them in Matroska. If the subtitles are stored as a picture, then each picture could be stored in a time coded block in the subtitle stream. Pictures stored there should probably be compressed to PNG to save space, but could be left as a BMP. The VobSub sources could be modified to handle the stream coming from libmatroska. Anyone interested in looking at the VobSub Directshow sources should go here: http://vobsub.edensrising.com/vobsub.php Pamel http://matroska.org From steve.lhomme at free.fr Wed Jan 22 09:28:51 2003 From: steve.lhomme at free.fr (Steve Lhomme) Date: Wed, 22 Jan 2003 09:28:51 +0100 (CET) Subject: [matroska-devel] Re: Converting Subtitles In-Reply-To: References: Message-ID: <1043224131.3e2e5643f2ba0@imp.free.fr> En r?ponse ? Pamel : > Until it is decided how to store other subtitle formats in Matroska, > it > appears that we should come up with a way to convert other subtitle > formats > into something that can be used right now with Matroska. I propose a > simple > USF conversion. The examples given by Toff are very complex because of > all > of the options that are being shown off, but USF can be used as a very > simple format. For example: > > This is an example of some subs produced with subrip. > > 1 > 00:01:04,274 --> 00:01:06,390 > Thebes: City of the Living. > > 2 > 00:01:07,634 --> 00:01:10,068 > Crown jewel of Pharaoh Seti the First. > > 3 > 00:01:13,194 --> 00:01:16,664 > Home of lmhotep, Pharaoh's high priest. > > > > This is what it would look like converted to USF. > > > > > Thebes: City of the Living. > > > > Crown jewel of Pharaoh Seti the First. > > > > Home of lmhotep, Pharaoh's high priest. > > > > > It is such a simple conversion, that this could easily be used to mux > other > subtitles into Matroska. All we need is a directshow filter to show > them with. Is there any DirectShow filter for existing subtitle formats ? Because from what I understand of DS (from Blacksun explanations) it's not that easy to put anything over a video in DirectShow (except with the new DirectX 9). So such a filter(s) would be complex. That's why it's usually handled separately, in the player. http://matroska.org From spyder482 at yahoo.com Wed Jan 22 14:38:19 2003 From: spyder482 at yahoo.com (John Cannon) Date: Wed, 22 Jan 2003 07:38:19 -0600 Subject: [matroska-devel] Re: Converting Subtitles References: <1043224131.3e2e5643f2ba0@imp.free.fr> Message-ID: > Is there any DirectShow filter for existing subtitle formats ? Because from what > I understand of DS (from Blacksun explanations) it's not that easy to put > anything over a video in DirectShow (except with the new DirectX 9). So such a > filter(s) would be complex. That's why it's usually handled separately, in the > player. Well, right now i think the OggDS sub filter handles it's version of Subrip subtitles. Other than that there is VobSub but it only does it's own format IIRC. http://matroska.org From steve.lhomme at free.fr Wed Jan 22 14:51:17 2003 From: steve.lhomme at free.fr (Steve Lhomme) Date: Wed, 22 Jan 2003 14:51:17 +0100 (CET) Subject: [matroska-devel] Re: Converting Subtitles In-Reply-To: References: <1043224131.3e2e5643f2ba0@imp.free.fr> Message-ID: <1043243477.3e2ea1d59b6bd@imp.free.fr> En r?ponse ? John Cannon : > > Is there any DirectShow filter for existing subtitle formats ? > Because > from what > > I understand of DS (from Blacksun explanations) it's not that easy to > put > > anything over a video in DirectShow (except with the new DirectX 9). > So > such a > > filter(s) would be complex. That's why it's usually handled > separately, in > the > > player. > > Well, right now i think the OggDS sub filter handles it's version of > Subrip > subtitles. Other than that there is VobSub but it only does it's own > format IIRC. OK, my question was just about DirectShow. So that means it's possible to handle subtitles internally to DirectShow. http://matroska.org From cookieman_k at yahoo.com Wed Jan 22 17:00:48 2003 From: cookieman_k at yahoo.com (Kondoros Attila) Date: Wed, 22 Jan 2003 08:00:48 -0800 (PST) Subject: [matroska-devel] Re: [UCI-Devel] Re: Converting Subtitles In-Reply-To: <1043243477.3e2ea1d59b6bd@imp.free.fr> Message-ID: <20030122160048.5131.qmail@web14007.mail.yahoo.com> Hi all! I don't know about DShow, but an application using UCI as the interface to codecs and filters could stack up the decoding of video with the subtitle filter any time. It could stack up any (reasonable) number of such filters on one another, as long as one's input is compatible with other's output. At least this is not limited in the UCI code right now, as I see it. Like VDub does it. :) There is no reason to develop an entirely new interface for filters and one for codecs in UCI. Maybe this would eliminate the hasle with DShow... if UCI would move a little faster to completion :| What are your thoughts on this Alex? B.R, Kondoros Attila --- Steve Lhomme wrote: > En r?ponse ? John Cannon : > > > > Is there any DirectShow filter for existing > subtitle formats ? > > Because > > from what > > > I understand of DS (from Blacksun explanations) > it's not that easy to > > put > > > anything over a video in DirectShow (except with > the new DirectX 9). > > So > > such a > > > filter(s) would be complex. That's why it's > usually handled > > separately, in > > the > > > player. > > > > Well, right now i think the OggDS sub filter > handles it's version of > > Subrip > > subtitles. Other than that there is VobSub but it > only does it's own > > format IIRC. > > OK, my question was just about DirectShow. So that > means it's possible to handle > subtitles internally to DirectShow. > > > ------------------------------------------------------- > This SF.net email is sponsored by: Scholarships for > Techies! > Can't afford IT training? All 2003 ictp students > receive scholarships. > Get hands-on training in Microsoft, Cisco, Sun, > Linux/UNIX, and more. > www.ictp.com/training/sourceforge.asp > =========================================================================== > Universal Codec Interface (UCI) maillist, > UCI-Devel at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/uci-devel > http://uci.sourceforge.net/ __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com http://matroska.org From christian.hj.wiesner at web.de Wed Jan 22 09:33:04 2003 From: christian.hj.wiesner at web.de (Christian HJ Wiesner) Date: Wed, 22 Jan 2003 09:33:04 +0100 Subject: [matroska-devel] Re: Converting Subtitles In-Reply-To: References: Message-ID: <3E2E5740.5060103@web.de> Pamel, we should try to copy the USF devel ML on postings like this It may not be used a lot right now, but for sure USF has a great future and people should be able to read from the archives how we started out ;) Thanks Christian Pamel wrote: > Until it is decided how to store other subtitle formats in Matroska, it > appears that we should come up with a way to convert other subtitle formats > into something that can be used right now with Matroska. I propose a simple > USF conversion. The examples given by Toff are very complex because of all > of the options that are being shown off, but USF can be used as a very > simple format. For example: > > This is an example of some subs produced with subrip. > > 1 > 00:01:04,274 --> 00:01:06,390 > Thebes: City of the Living. > > 2 > 00:01:07,634 --> 00:01:10,068 > Crown jewel of Pharaoh Seti the First. > > 3 > 00:01:13,194 --> 00:01:16,664 > Home of lmhotep, Pharaoh's high priest. > > > > This is what it would look like converted to USF. > > > > > Thebes: City of the Living. > > > > Crown jewel of Pharaoh Seti the First. > > > > Home of lmhotep, Pharaoh's high priest. > > > > > It is such a simple conversion, that this could easily be used to mux other > subtitles into Matroska. All we need is a directshow filter to show them > with. > > > Pamel > > > > http://matroska.org > http://matroska.org From pdbryson at hotmail.com Wed Jan 22 17:11:27 2003 From: pdbryson at hotmail.com (Paul Bryson) Date: Wed, 22 Jan 2003 10:11:27 -0600 Subject: [matroska-devel] Re: [usf-devel] Re: Converting Subtitles References: <3E2E5740.5060103@web.de> Message-ID: There's a USF devel mailing list? Pamel ----- Original Message ----- From: Christian HJ Wiesner To: matroska-devel at freelists.org ; usf-devel at freelists.org Sent: Wednesday, January 22, 2003 2:33 AM Subject: [usf-devel] Re: [matroska-devel] Converting Subtitles Pamel, we should try to copy the USF devel ML on postings like this It may not be used a lot right now, but for sure USF has a great future and people should be able to read from the archives how we started out ;) Thanks Christian Pamel wrote: > Until it is decided how to store other subtitle formats in Matroska, it > appears that we should come up with a way to convert other subtitle formats > into something that can be used right now with Matroska. I propose a simple > USF conversion. The examples given by Toff are very complex because of all > of the options that are being shown off, but USF can be used as a very > simple format. For example: > > This is an example of some subs produced with subrip. > > 1 > 00:01:04,274 --> 00:01:06,390 > Thebes: City of the Living. > > 2 > 00:01:07,634 --> 00:01:10,068 > Crown jewel of Pharaoh Seti the First. > > 3 > 00:01:13,194 --> 00:01:16,664 > Home of lmhotep, Pharaoh's high priest. > > > > This is what it would look like converted to USF. > > > > > Thebes: City of the Living. > > > > Crown jewel of Pharaoh Seti the First. > > > > Home of lmhotep, Pharaoh's high priest. > > > > > It is such a simple conversion, that this could easily be used to mux other > subtitles into Matroska. All we need is a directshow filter to show them > with. > > > Pamel > > > > http://matroska.org > http://usf.corecodec.org http://matroska.org From Paul at msn.com Thu Jan 23 04:39:51 2003 From: Paul at msn.com (Pamel) Date: Wed, 22 Jan 2003 21:39:51 -0600 Subject: [matroska-devel] How UCI and Matroska could interact Message-ID: "Kondoros Attila" wrote > I'm not sure what is the direct connection between UCI > and matroska. Is this supose to work in the following > basic way? : > 1. An UCI-aware application opens some codec through > UCI. > 2. Feeds its data to compress-it. > 3. Then the compresed data is handled to matroskalib, > to store it. > And everything revesed for decoding, right? > > Or matroskalib will be called through UCI by the > application? I'm not in clear with this... In my head, I have a view of how things work together. I'll explain how I think it would all work out, and someone could correct me if I'm wrong. For a playback application: * The UCI-aware application send UCI a message saying it wants to read file XXXXX.zav and to return track information * UCI sends libmatroska a message saying to open file XXXXX.zav and return track information. * Libmatroska opens the file and determines what tracks of what types exists and returns this information to UCI. * UCI then returns the list of tracks to the application. * The application can also request other basic information such as author, encode date, etc through the above process. * The application decides which tracks to play (probably through user intervention) and tells UCI which tracks to play, and what timecode to start at. * UCI then tells libmatroska the tracks to begin feeding out and what timecode to start with. * Libmatroska then feeds out the Codec-ID and 'private codec data' for each track to UCI. * UCI passes the 'private codec data' to each of the respective codecs to initialize them. (This is where it gets tricky and there is a good chance I'm off) * Libmatroska then passes out a block, along with the timecode, at (or just before) the timecode specified for the specified track(s) to UCI. * UCI passes the block to the codec and requests a frame back. * The codec then passes a frame back to UCI. (For video, an uncompressed frame in whatever format is specified. For audio, uncompressed audio in whatever format is specified, though possibly just a passthrough for cases such as passing AC3 to a reciever. For subtitles, an uncompressed alpha frame in (hopefuly) the same format as the video.) * UCI combines frames as necessary, such as the video with the subtitle screen alpha blended over it. * UCI passes the frame to the application. * UCI requests the next timecode(s) for the appropriate track(s) from libmatroska. * Libmatroska passes the next timecode, and block if applicable, to UCI. * UCI then passes the block, if it got one, to the codec and requests a frame back. * The codec returns a frame, and UCI does whatever it did previously with the streams. * UCI passes the frame to the application with the appropriate timecode For cases where a seek is done to a P frame: * After UCI passes the timecode to libmatroska and requests a block, libmatroska determines that it needs to render the 31 previous frames to render this one P frame. * Libmatroska passes a variable to UCI indicating it needs to have 31 frames rendered to render the wanted frame. * Libmatroska then passes the first block (no timecode needed) to UCI. * UCI passes the block to the codec and requests a frame. * UCI discards the frame and requests the next block. * Libmatroska passes the next block to UCI and the process is repeated until the needed block is passed to the codec and frame is passed back to UCI. For cases where a seek is done to a Null timecode. * After UCI passes the timecode to libmatroska and requests a block, libmatroska determines that it needs to render block 31 timecodes previous to render this null timecode. * Libmatroska passes a variable to UCI indicating it needs to have the block 31 timecodes ahead sent to the codec to render the wanted frame. * Libmatroska passes the block to UCI. * UCI passes the blcok to the codec and requests the 32nd frame from the codec. * The codec passes the appropriate frame to UCI. In this, the 'null frame' is used where a single block would contain all information for the next several frames. In this case a timecode is stored, for when to play back the next frame, but no data. Okay, I didn't get to the part about how the encoder should work because I need to leave now, but I will post that tomorrow. It should be clear enough now to be able to poke holes in my thought process now. Pamel http://matroska.org From Paul at msn.com Thu Jan 23 05:00:30 2003 From: Paul at msn.com (Pamel) Date: Wed, 22 Jan 2003 22:00:30 -0600 Subject: [matroska-devel] Re: How UCI and Matroska could interact References: Message-ID: I forgot to mention that one of the ideas here is that the application, codec, and file parser never touch each other. If all three are UCI (or whatever universal framework that get developed) compliant, then there should never be a need. Applications, codecs, and file parsers can all be built to be cross platform and interfaces will never need to be re-written. Pamel http://matroska.org From omega at temple-baptist.com Thu Jan 23 05:06:36 2003 From: omega at temple-baptist.com (Erik Walthinsen) Date: Wed, 22 Jan 2003 20:06:36 -0800 (PST) Subject: [matroska-devel] Re: [UCI-Devel] Re: How UCI and Matroska could interact In-Reply-To: Message-ID: On Wed, 22 Jan 2003, Pamel wrote: > I forgot to mention that one of the ideas here is that the application, > codec, and file parser never touch each other. If all three are UCI (or > whatever universal framework that get developed) compliant, then there > should never be a need. Applications, codecs, and file parsers can all be > built to be cross platform and interfaces will never need to be re-written. See gstreamer.net. This is already done, but with a generic datastream interface. Where UCI will be relevant is in getting all codecs to have the same API, thus making wrapping or otherwise hooking into gstreamer pipelines far easier. Erik Walthinsen - System Administrator __ / \ GStreamer - The only way to stream! | | M E G A ***** http://gstreamer.net/ ***** _\ /_ http://matroska.org From Paul at msn.com Thu Jan 23 07:58:18 2003 From: Paul at msn.com (Pamel) Date: Thu, 23 Jan 2003 00:58:18 -0600 Subject: [matroska-devel] Re: [UCI-Devel] Re: How UCI and Matroska could interact References: Message-ID: "Erik Walthinsen" wrote > See gstreamer.net. This is already done, but with a generic datastream > interface. Where UCI will be relevant is in getting all codecs to have > the same API, thus making wrapping or otherwise hooking into gstreamer > pipelines far easier. > > Erik Walthinsen - System Administrator Its great to actually hear from the GStreamer people. ChistianHJW had said he had made contact with your group, but there hadn't been any information come our way. I am truly interested in having a cross-platform all-in-one interface for applications, codecs, and containers that supports both encoding and decoding. If UCI only provided a common API for the codecs, that is fine. But what exactly does GStreamer provide? Is it cross-platform? Does it off a standardized set of API's for both applications and containers, or just applications? If it isn't, could it be made cross-platform? Could the API be extended? What all can it offer? Pamel http://matroska.org From Paul at msn.com Thu Jan 23 09:33:58 2003 From: Paul at msn.com (Pamel) Date: Thu, 23 Jan 2003 02:33:58 -0600 Subject: [matroska-devel] Re: How UCI and Matroska could interact References: Message-ID: For an encoding application: * The UCI-aware application sends UCI a message saying it wants to write the file XXXXX.zav as a Matroska file. * UCI sends libmatroska a message saying to create the file XXXXX.zav for writing. * Libmatroska opens the file and returns the ready to UCI. * UCI returns the ready to the application. * The application sends all basic information such as author, encode date, etc to UCI. * UCI sends this to libmatroska which writes the information. * UCI returns the ready to the application. * The application sends codec config data to UCI. UCI sends the data to the codec. * The codec then sends the private codec info to UCI, and UCI sends it to libmatroska. * The application sends the uncompressed frame to UCI, labelled with a track and timecode. * UCI sends the frame to the the codec. (This is where it gets tricky and there is a good chance I'm off) * The codec sends the encoded block to UCI. * UCI sends the encoded block to libmatroska with the track number and timecode. * UCI returns the ready to the application. * The application sends the next uncompressed frame to UCI, labelled with a track and timecode. * The process keeps repeating until completed. I was going to put some other scenarios in here, but I need sleep now. Pamel http://matroska.org From Paul at msn.com Thu Jan 23 09:34:04 2003 From: Paul at msn.com (Pamel) Date: Thu, 23 Jan 2003 02:34:04 -0600 Subject: [matroska-devel] Re: How UCI and Matroska could interact References: Message-ID: While talking with Gldm, something has become very clear in my mind. For a truly universal multimedia API that can handle all types of situations, there is one thing that needs to be done. For flexible multimedia, there are three things that you need. The application, this includes players and editors. The codec. And the container. So, respectively there are three API's. The application API, the codec API, and the container API. These are the three corners to the API. For a flexible universal API, all three API's need to have 2 way communication. This means that they can all accept information, and all request information. Preferably, they should all have access to the same set of instructions, though they most certainly wouldn't use all of them. Some examples: The codec wants to request a specific frame during playback for its own buffering scheme. The container wants to request the "codec config data" from the encoding app. The codec wants to obtain some frames forwards/backwards during encoding for its encoding scheme. A menu codec changes the tracks and moves to timecodes on the fly. The encoder requests 'private codec data' from the container, or writes its own to the container. This is by no means a complete or likely list, but there are many scenarios that I cannot think of at the moment. Pamel http://matroska.org From Paul at msn.com Thu Jan 23 09:37:59 2003 From: Paul at msn.com (Pamel) Date: Thu, 23 Jan 2003 02:37:59 -0600 Subject: [matroska-devel] Re: How UCI and Matroska could interact References: Message-ID: While talking with Gldm, something has become very clear in my mind. For a truly universal multimedia API that can handle all types of situations, there is one thing that needs to be done. For flexible multimedia, there are three things that you need. The application, this includes players and editors. The codec. And the container. So, respectively there are three API's. The application API, the codec API, and the container API. These are the three corners to the API. For a flexible universal API, all three API's need to have 2 way communication. This means that they can all accept information, and all request information. Preferably, they should all have access to the same set of instructions, though they most certainly wouldn't use all of them. Some examples: The codec wants to request a specific frame during playback for its own buffering scheme. The container wants to request the "codec config data" from the encoding app. The codec wants to obtain some frames forwards/backwards during encoding for its encoding scheme. A menu codec changes the tracks and moves to timecodes on the fly. The encoder requests 'private codec data' from the container, or writes its own to the container. This is by no means a complete or likely list, but there are many scenarios that I cannot think of at the moment. Pamel http://matroska.org From cookieman_k at yahoo.com Thu Jan 23 11:04:30 2003 From: cookieman_k at yahoo.com (Kondoros Attila) Date: Thu, 23 Jan 2003 02:04:30 -0800 (PST) Subject: [matroska-devel] Re: [UCI-Devel] Re: How UCI and Matroska could interact In-Reply-To: Message-ID: <20030123100430.36898.qmail@web14006.mail.yahoo.com> Thanks for all your help! It helps a lot to see what are we trying to acomplish. If something is not clear, expect more questions :) Thanks again. B.R, Kondoros Attila --- Pamel wrote: > While talking with Gldm, something has become very > clear in my mind. For a > truly universal multimedia API that can handle all > types of situations, > there is one thing that needs to be done. > > For flexible multimedia, there are three things that > you need. The > application, this includes players and editors. The > codec. And the > container. So, respectively there are three API's. > The application API, the > codec API, and the container API. These are the > three corners to the API. > For a flexible universal API, all three API's need > to have 2 way > communication. This means that they can all accept > information, and all > request information. Preferably, they should all > have access to the same > set of instructions, though they most certainly > wouldn't use all of them. > > Some examples: The codec wants to request a > specific frame during playback > for its own buffering scheme. The container wants > to request the "codec > config data" from the encoding app. The codec wants > to obtain some frames > forwards/backwards during encoding for its encoding > scheme. A menu codec > changes the tracks and moves to timecodes on the > fly. The encoder requests > 'private codec data' from the container, or writes > its own to the container. > > This is by no means a complete or likely list, but > there are many scenarios > that I cannot think of at the moment. > > > Pamel > > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Scholarships for > Techies! > Can't afford IT training? All 2003 ictp students > receive scholarships. > Get hands-on training in Microsoft, Cisco, Sun, > Linux/UNIX, and more. > www.ictp.com/training/sourceforge.asp > =========================================================================== > Universal Codec Interface (UCI) maillist, > UCI-Devel at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/uci-devel > http://uci.sourceforge.net/ __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com http://matroska.org From steve.lhomme at free.fr Thu Jan 23 10:18:59 2003 From: steve.lhomme at free.fr (Steve Lhomme) Date: Thu, 23 Jan 2003 10:18:59 +0100 (CET) Subject: [matroska-devel] Re: [UCI-Devel] How UCI and Matroska could interact In-Reply-To: References: Message-ID: <1043313539.3e2fb3838de22@imp.free.fr> En r?ponse ? Pamel : > For cases where a seek is done to a P frame: > > * After UCI passes the timecode to libmatroska and requests a block, > libmatroska determines that it needs to render the 31 previous frames > to > render this one P frame. > * Libmatroska passes a variable to UCI indicating it needs to have 31 > frames rendered to render the wanted frame. > * Libmatroska then passes the first block (no timecode needed) to > UCI. > * UCI passes the block to the codec and requests a frame. > * UCI discards the frame and requests the next block. > * Libmatroska passes the next block to UCI and the process is > repeated > until the needed block is passed to the codec and frame is passed back > to > UCI. Mmmm. We already discussed the case of GLDM's codec (many frames packed in one). But we didn't think of seeking at that time. And what you describe is impossible with matroska (and other containers). A P frame has a backward reference. But to decode the 31th frame you only need the data of that frame and the reference key frame. If GLDM's codec really need all the frames in between, then we're not talking about a P frame but something that doesn't exist yet. And so it should be created and supported in matroska (and UCI). In matroska there are 2 bits : 6 must P Frame - the frame depends on a backward frame (activate the prev timecode) 5 must N Frame - the frame depends on a forward frame (activate the next timecode) And then follows the reference timecodes in the block (one for each bit). That means we may need something more "complicated" and have multiple backward and forward references. No bit would be required for that anymore. But the reference timecodes should be extensible... like in EBML... One solution I can see is that the Block element and BlockAdditional are grouped into a master element BlockGroup that would contain both. And you would have to read both to be able to render the Block... This was already the idea but they were not grouped together (bad EBML design anyway). In this case, we can now have as many backward and forward references in the BlockAdditional as needed. That's a better design, but the drawback is that it will produce more overhead : 2 to 9 bytes (depending on the size of data) for each Block. So the Block size would move from a 6-21 bytes range to a 8-30 bytes range... For high granularity of data (a lot of small data packets) that means we would use more lacing than in the previous case. http://matroska.org From paul at msn.com Thu Jan 23 17:41:05 2003 From: paul at msn.com (Pamel) Date: Thu, 23 Jan 2003 10:41:05 -0600 Subject: [matroska-devel] Re: [UCI-Devel] How UCI and Matroska could interact References: <1043313539.3e2fb3838de22@imp.free.fr> Message-ID: "Steve Lhomme" wrote > En r?ponse Pamel : > Mmmm. We already discussed the case of GLDM's codec (many frames packed in one). > But we didn't think of seeking at that time. And what you describe is impossible > with matroska (and other containers). It is not 'impossible' with matroska. Thats the point of matroska, you just add another EBML element. > A P frame has a backward reference. But to > decode the 31th frame you only need the data of that frame and the reference key > frame. If GLDM's codec really need all the frames in between, then we're not > talking about a P frame but something that doesn't exist yet. And so it should > be created and supported in matroska (and UCI). This could be done using P frames as it would request frames back until it got to the keyframe. I just think that its silly to use this 'workaround' when matroska could be easily extended to accomodate this new structure. The P frames idea is basicaly tricking the interface to work with the codec, but the extra work is being done and extra transfers of information. Why not just define a way to do it that is what the codec needs. > That means we may need something more "complicated" and have multiple backward > and forward references. No bit would be required for that anymore. But the > reference timecodes should be extensible... like in EBML... I agree. > One solution I can see is that the Block element and BlockAdditional are grouped > into a master element BlockGroup that would contain both. And you would have to > read both to be able to render the Block... This was already the idea but they > were not grouped together (bad EBML design anyway). In this case, we can now > have as many backward and forward references in the BlockAdditional as needed. How about one of these? Let the BlockAdditional be another element on the same level as Block. But BlockAdditional just contains sub-elements such as timecode(s), track#, and where the block with the information is located. This would mean there is 0 overhead for cases where these are not used. Or, could you just make BlockAdditional a sub-element of the existing Block design? So, again, it would not be taking space in cases where it is not used. This would have the added benefit of all relevant timecodes being under the keyframe. So, if a seek was done inbetween two timecodes, it would go to the first one, see that there were sub-timecodes, and use the most accurate one. Pamel http://matroska.org From steve.lhomme at free.fr Thu Jan 23 18:56:54 2003 From: steve.lhomme at free.fr (Steve Lhomme) Date: Thu, 23 Jan 2003 18:56:54 +0100 (CET) Subject: [matroska-devel] Re: How UCI and Matroska could interact In-Reply-To: References: <1043313539.3e2fb3838de22@imp.free.fr> Message-ID: <1043344614.3e302ce6c369d@imp.free.fr> En r?ponse ? Pamel : > "Steve Lhomme" wrote > > A P frame has a backward reference. But to > > decode the 31th frame you only need the data of that frame and the > reference key > > frame. If GLDM's codec really need all the frames in between, then > we're > not > > talking about a P frame but something that doesn't exist yet. And so > it > should > > be created and supported in matroska (and UCI). > > This could be done using P frames as it would request frames back until > it > got to the keyframe. I just think that its silly to use this > 'workaround' > when matroska could be easily extended to accomodate this new > structure. > The P frames idea is basicaly tricking the interface to work with the > codec, > but the extra work is being done and extra transfers of information. > Why > not just define a way to do it that is what the codec needs. See below (of the previous email). > > One solution I can see is that the Block element and BlockAdditional > are > grouped > > into a master element BlockGroup that would contain both. And you > would > have to > > read both to be able to render the Block... This was already the idea > but > they > > were not grouped together (bad EBML design anyway). In this case, we > can > now > > have as many backward and forward references in the BlockAdditional > as > needed. > > How about one of these? Let the BlockAdditional be another element on > the > same level as Block. But BlockAdditional just contains sub-elements > such as > timecode(s), track#, and where the block with the information is > located. > This would mean there is 0 overhead for cases where these are not used. > Or, > could you just make BlockAdditional a sub-element of the existing > Block > design? So, again, it would not be taking space in cases where it is > not > used. This would have the added benefit of all relevant timecodes > being > under the keyframe. So, if a seek was done inbetween two timecodes, > it > would go to the first one, see that there were sub-timecodes, and use > the > most accurate one. Well, the BlockAdditional is already placed after the Block. But it's not syntaxicaly or semanticaly nice. Because it depends on the order of elements. And for example reorganising Blocks between tracks and timecodes to make the reading faster would be harder because of this. If everything is contained in a bigger element, that's safe. Also the idea of the BlockAddition is to put all optional elements there and keep the minimum in the Block. The problem here is that the size is critical, because of the consequences on the global overhead. That's why the track number and the timecode should remain in the Block (not the reference timecodes anymore). Also note that using references is convenient to save bandwidth by reducing the amount of information after encoding. So using this technique should not produce too much overhead otherwise we lose all the benefit... That means 3 or 4 octets by reference (imagine 31 references) are pretty large (just to end up with 0 actual data ;). BTW, I was a bit wrong in my range the current minimum (with references out of the Block) is 6 and the max is 13 (lacing excluded). With 3 to 10 octets added for the BlockGroup (when references is involved), 2 to 9 octets for the BlockAddition and 3 to 4 octets for each reference... That makes : - no reference : 9 to 23 octets - P frame : 14 to 38 octets - B frame : 17 to 42 octets (3 to 4 octets added for each reference, the differentiation of forward/backward is not used anymore, since we deal with signed timecodes) This is up from the current 6-21 (21 is for the largest possible B frame). If we don't use a BlockGroup element, we have : - no reference : 6 to 13 octets - P frame : 11 to 28 octets - B frame : 14 to 32 octets I need to find what the average granularity for speex and vorbis are at the moment (size of packets) and for a low bitrate video codec. That would help compute the overhead involved for each case. A 1% or 2% for the worst case examples should be OK. That would help to decide between the clean vs smaller possibilities... http://matroska.org From paul at msn.com Thu Jan 23 19:39:39 2003 From: paul at msn.com (Pamel) Date: Thu, 23 Jan 2003 12:39:39 -0600 Subject: [matroska-devel] Re: How UCI and Matroska could interact References: <1043313539.3e2fb3838de22@imp.free.fr> <1043344614.3e302ce6c369d@imp.free.fr> Message-ID: "Steve Lhomme" wrote > Well, the BlockAdditional is already placed after the Block. But it's not > syntaxicaly or semanticaly nice. Because it depends on the order of elements. > And for example reorganising Blocks between tracks and timecodes to make the > reading faster would be harder because of this. If everything is contained in a > bigger element, that's safe. I agree, it would make it more difficult when arranging the elements. > That's why the track number > and the timecode should remain in the Block (not the reference timecodes anymore). So, reference timecodes, outside of the block element. I'm not sure if I understand the EBML correctly. Is it possible for the Block element to contain the binary block data, and also have sub elements? So, the Block is the exact same size as initialy, but sub elements can be added which increase the size? > (3 to 4 octets added for each reference, the differentiation of forward/backward > is not used anymore, since we deal with signed timecodes) There are those pesky timecodes again. The Cluster timecode needs to have the same time as the earliest timecoded frame in the cluster, otherwise seeking becomes nearly impossible to do correctly. Pamel http://matroska.org From suiryc at yahoo.com Thu Jan 23 16:13:59 2003 From: suiryc at yahoo.com (Cyrius) Date: Thu, 23 Jan 2003 07:13:59 -0800 (PST) Subject: [matroska-devel] Re: How UCI and Matroska could interact In-Reply-To: Message-ID: <20030123151359.36008.qmail@web12906.mail.yahoo.com> In my mind there were two parts : 1) the matroska (or any other) library, called by the program (editing tool, player, whatever) to read a file. 2) the UCI (or any other) API also called by the program to handle/decode the data in the file. So in my mind the API wouldn't be directly linked to any container (e.g. matroska) because this would be strange (since UCI is meant to be 'universal' why is it linked to matroska or MCF ?, in this case it should be linked to any other container too). Then what happens is that the program read data from the file, give the data to the library to get only the useful things. Those useful things include stream headers and codec specific data (if any). The information contained in the header (Video codec type, ...) are sent to the API (e.g. UCI) to know if there is an available codec to decode those data. If so the data are sent to this codec through the API, decoded and returned to the program (through the API again). As I don't know all the background about matroska/MCF (and what was planned to be used before : Transors) maybe my idea is just wrong and then maybe Steve or John can explain here why and how the library (matroska for instance) and the API (UCI) should be linked :) __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com http://matroska.org From steve.lhomme at free.fr Thu Jan 23 16:47:40 2003 From: steve.lhomme at free.fr (Steve Lhomme) Date: Thu, 23 Jan 2003 16:47:40 +0100 (CET) Subject: [matroska-devel] Re: How UCI and Matroska could interact In-Reply-To: <20030123151359.36008.qmail@web12906.mail.yahoo.com> References: <20030123151359.36008.qmail@web12906.mail.yahoo.com> Message-ID: <1043336860.3e300e9cc842e@imp.free.fr> En r?ponse ? Cyrius : > In my mind there were two parts : > 1) the matroska (or any other) library, called by the > program (editing tool, player, whatever) to read a > file. > 2) the UCI (or any other) API also called by the > program to handle/decode the data in the file. > > So in my mind the API wouldn't be directly linked to > any container (e.g. matroska) because this would be > strange (since UCI is meant to be 'universal' why is > it linked to matroska or MCF ?, in this case it should > be linked to any other container too). Sure. This way other containers can take advantages of other codec :) I think once UCI can cope with data i/o from Matroska, AVI and OGG it will be rather universal. Because all of these containers have different philisophies, but still rely on different codec at one point. > Then what happens is that the program read data from > the file, give the data to the library to get only the > useful things. The codec library (UCI) or the container library (libmatroska) ? > Those useful things include stream headers and codec > specific data (if any). The information contained in > the header (Video codec type, ...) are sent to the API > (e.g. UCI) to know if there is an available codec to > decode those data. If so the data are sent to this > codec through the API, decoded and returned to the > program (through the API again). Well, matroska offer more than streams with a codec (attachements or meta informations for example). And that would have nothing to do with the codec API. So the program (I call that a host) has to call libmatroska directly at one point (so the same architecture should apply to AVI or OGG). The big questions is : is it the container lib that calls the codec, or the host application ? (BTW, a common host example is a DirectShow filter :) > Do you Yahoo!? No http://matroska.org From cookieman_k at yahoo.com Thu Jan 23 17:04:27 2003 From: cookieman_k at yahoo.com (Kondoros Attila) Date: Thu, 23 Jan 2003 08:04:27 -0800 (PST) Subject: [matroska-devel] Re: [UCI-Devel] Re: How UCI and Matroska could interact In-Reply-To: <20030123151359.36008.qmail@web12906.mail.yahoo.com> Message-ID: <20030123160427.80540.qmail@web14001.mail.yahoo.com> Hi! You just wrote (almoust) the same scenario that I was asserting in my very first email.I guess that this must be the simplest scenario, and we must streave for simplicity. That was my impression too, that the countainers should not be linked directly to the UCILIB (UCI is an interface to codecs and on the other part interface to the Application.) Also in the UCI I do not see any thing that can be used directly by the containers, but I maybe mistaking... :( What UCI contains right now: 1. An interface to the "Applications" 2. An interface to the "Codecs" 3. -) missing (-: An interface to the "Containers" :( Maybe a standard interface could be added to UCI that would unify the containers too... An "Unified Container Interface" per se. If this would be added then the application could use UCILIB to enumerate/use the available containers, and the Aplication would only call UCI to handle the codecs and the containers. This could be workable... If every container would have it's own interface exposed than the application must be modified every time a new container becomes used by the users. All in all, then matroska would have to adhere to the (non existent) UCI container interface. Am I talking stupid things here? What others think about this? B.R. Kondoros Attila --- Cyrius wrote: > In my mind there were two parts : > 1) the matroska (or any other) library, called by > the > program (editing tool, player, whatever) to read a > file. > 2) the UCI (or any other) API also called by the > program to handle/decode the data in the file. > > So in my mind the API wouldn't be directly linked to > any container (e.g. matroska) because this would be > strange (since UCI is meant to be 'universal' why is > it linked to matroska or MCF ?, in this case it > should > be linked to any other container too). > > Then what happens is that the program read data from > the file, give the data to the library to get only > the > useful things. > Those useful things include stream headers and codec > specific data (if any). The information contained in > the header (Video codec type, ...) are sent to the > API > (e.g. UCI) to know if there is an available codec to > decode those data. If so the data are sent to this > codec through the API, decoded and returned to the > program (through the API again). > > As I don't know all the background about > matroska/MCF > (and what was planned to be used before : Transors) > maybe my idea is just wrong and then maybe Steve or > John can explain here why and how the library > (matroska for instance) and the API (UCI) should be > linked :) > > __________________________________________________ > Do you Yahoo!? > Yahoo! Mail Plus - Powerful. Affordable. Sign up > now. > http://mailplus.yahoo.com > > > ------------------------------------------------------- > This SF.NET email is sponsored by: > SourceForge Enterprise Edition + IBM + LinuxWorld = > Something 2 See! > http://www.vasoftware.com > =========================================================================== > Universal Codec Interface (UCI) maillist, > UCI-Devel at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/uci-devel > http://uci.sourceforge.net/ __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com http://matroska.org From paul at msn.com Thu Jan 23 18:32:06 2003 From: paul at msn.com (Pamel) Date: Thu, 23 Jan 2003 11:32:06 -0600 Subject: [matroska-devel] Re: [UCI-Devel] Re: How UCI and Matroska could interact References: <20030123151359.36008.qmail@web12906.mail.yahoo.com> <20030123160427.80540.qmail@web14001.mail.yahoo.com> Message-ID: "Kondoros Attila" > That was my impression too, that the countainers > should not be linked directly to the UCILIB (UCI is an > interface to codecs and on the other part interface to > the Application.) I couldn't agree more. Linking directly to a container via the individual interfaces, and using seperate commands for each lib, would defeat the purpose of having a universal interface. > Also in the UCI I do not see any thing that can be > used directly by the containers, but I maybe > mistaking... :( I'll say mistaken, because it is needed. > What UCI contains right now: > 1. An interface to the "Applications" > 2. An interface to the "Codecs" > 3. -) missing (-: An interface to the "Containers" :( Yes, we need a common interface to containers for this to work and be useful. > Maybe a standard interface could be added to UCI that > would unify the containers too... Bingo. > If every container would have it's own interface > exposed than the application must be modified every > time a new container becomes used by the users. Thats the problem we have right now. Just look at the mess that VirtualDubMod is becoming trying to add support for each container individualy. If there were a universal interface that handled the app, codec, and container API's, then VirtualDubMod could be made to work almost instantly with any container that had a UCI-compliant library. > All in all, then matroska would have to adhere to the > (non existent) UCI container interface. Matroska has to have a DS/vfw interface right now. But once a universal interface exists, this should be quickly added to it. > Am I talking stupid things here? What others think > about this? You are right on track. Brilliant ideas man. Pamel http://matroska.org From steve.lhomme at free.fr Thu Jan 23 12:28:51 2003 From: steve.lhomme at free.fr (Steve Lhomme) Date: Thu, 23 Jan 2003 12:28:51 +0100 (CET) Subject: [matroska-devel] Re: How UCI and Matroska could interact In-Reply-To: <20030123102208.7179.qmail@mail.com> References: <20030123102208.7179.qmail@mail.com> Message-ID: <1043321331.3e2fd1f3b6238@imp.free.fr> En r?ponse ? Toby Hudon : > The problem we were discussing was issues of randomly seeking frames, > when that frame might be dependant on another frame's data. For me, if I > have the previous keyframe, I have all the data, because I only store > data in keyframes. The other frames are either placeholders to know when > it's time to serve up the next frame worth of data, or don't exist > assuming a modern API like UCI that can deal with this concept of just > asking for a frame at the right time with no data. It is close to reality. The problem is that from the container point of view we don't know if the frame to be displayed is the 2nd or 31st. (that's what we get from using timecodes for references instead of a number) and I assume your codec has to know that number to display the correct frame, especially since you already mentioned that your codec doesn't deal with time (allowing good variable frame rate use). So when you have the 31st one, you need to know that it's not the second but the 31st one. For this case, a simple reference number (31) could be used in addition to the backward timecode reference. But it's not really general as future codec like yours (that don't want to be tied to the old VfW API) might store different informations in each of the 31 frames, and even have a key frame repeated but not with a fixed rate (not every 32 or 64 frames but whenever the codec decides to like on scene changes). Of course such a codec could only be stored in a modern container *grin*... A frame that needs information of a key frame 1012 frames before and also from the last 4 frames is a plausible case in the future with advanced codecs, all this at a variable frame rate :) > However, for things to run smoothly I need to be decoding the next > block's worth of data while the current block is decoded and playing. > Otherwise at every keyframe/block there'll be a huge pause for decode. > So it needs at least a double buffer. This means I need TWO keyframes > all the time. Well in BeOS this is handled though a delay that every codec has to define. IIRC, such a thing already exists in UCI. The frame precision seeking is more important at the edition level than at the playing level. > The interface will likely test for small seeks that are within the > current block and can deliver those easily. However, for seeks outside > the current block, there's a more complicated proceedure. The interface > (this is still my code, not UCI's) needs to call the core and flush() to > clear out the two existing blocks. Then it needs to call > init_2_buffer(frame A, frame B) with 2 keyframes of data. For stupid > codecs like VFW, this may involve serving some NULL frames with blank > data (my interface will generate these as needed) to get the second > keyframe. Smarter APIs will probably have a way to just directly request > a future frame like for a b-frame. This is basicly the same proceedure > as at the start of a file. Then as the blocks are decoded, > decompress(frame F) can be called as normal by the interface. How the > decompress function is triggered, either by dummy frames or an API > instruction to display the next frame is unimportant, my interface for > each API will handle these details. However, the dummy frame method may > waste some bandwidth storing the extra frames in some containers, so the > call for next frame method is preferred. Hummm... Well, in matroska you can requests frames of a timecode but not directly by a reference count (like granule pos). This is done to be able to decode a P frame even though a frame is missing between this P frame and the reference key frame. So in your case you would have to deal with that too... That's why it's good/better/best to store the references at the container level. Since that's the level that will deal with errors and missing data. This way in matroska you can be *sure* that when you read a frame you have all the references, or not. The codec doesn't need to care about it. It should just allow frame gaps in the stream, ie be given what frames were/are the reference ones for a given frame. > From what Pamel said I think when you seek with VFW on a normal mpeg > file, VFW will give you the previous keyframe and all the frames > inbetween so you can compute the p-frame (assuming you seek to a > p-frame). I'm not sure if this is true. Can anyone clarify it for me? I'm not sure neither, but I think it's how it works. And how it shouldn't be working :) http://matroska.org From paul at msn.com Thu Jan 23 17:04:45 2003 From: paul at msn.com (Pamel) Date: Thu, 23 Jan 2003 10:04:45 -0600 Subject: [matroska-devel] Re: How UCI and Matroska could interact References: <1043311985.3e2fad7107191@imp.free.fr> Message-ID: "Steve Lhomme" wrote > En r?ponse Pamel : > This is an interresting idea. That would make the code more much complex, BTW. > So would lead to more bugs. Yes, it would be more complex with a 3 way API where each node can push AND pull. But, I was also saying that each command should be accessible by each API. This would dramaticaly reduce complexity and the number of instructions that would need to be developed supported by UCI. I don't think this would quite balance out the complexity, but I don't think it would be that far away. >Pulling on encode doesn't make much sense to me. It doesn't make much sense to me either, but that doesn't mean that somebody won't need to do it sometime. Making the same interface for encoding and decoding removes the need to worry about it though. Pamel http://matroska.org From paul at msn.com Thu Jan 23 18:03:07 2003 From: paul at msn.com (Pamel) Date: Thu, 23 Jan 2003 11:03:07 -0600 Subject: [matroska-devel] Re: How UCI and Matroska could interact References: <20030123144634.79077.qmail@web12905.mail.yahoo.com> <1043335068.3e30079c03c7a@imp.free.fr> Message-ID: "Steve Lhomme" wrote > En r?ponse Cyrius : > > > Can't UCI handle that ? > > IIRC you feed UCI with data (for the codec) and the > > codec will tell UCI if some data was decoded (and so > > returned). > > In your case you would just tell UCI you didn't > > decoded any data until you have your 2 keyframes. > > Of course the multithreading you use in your codec > > will be useful here (so that you can decode the data > > while serving the previously decoded frames to UCI). > > That could be enough for playback. But this is unacceptable to capture just one > frame in a file. While old technologies (read AVI, VfW) don't allow this (see > all the problems of getting captures of B frames in DivX/XviD to compare them), > newer ones should. That's why for each frame (not possible for the ones in a > lace) it should be possible to know all the references needed to decode. At the > container level (matroska) and at the codec level (UCI). This could work pretty easily if UCI Buffered all of the timecodes when a codec gave it a null frame. Then the codec could output the block when ready with what buffered frame the block would be at, and indicate all other frames afterwards only need to pull from that one keyframe. Then Matroska stores the keyframe block and stores the list of timecodes that refer to that block. Pamel http://matroska.org From steve.lhomme at free.fr Thu Jan 23 18:21:56 2003 From: steve.lhomme at free.fr (Steve Lhomme) Date: Thu, 23 Jan 2003 18:21:56 +0100 (CET) Subject: [matroska-devel] Re: How UCI and Matroska could interact In-Reply-To: References: <20030123144634.79077.qmail@web12905.mail.yahoo.com> <1043335068.3e30079c03c7a@imp.free.fr> Message-ID: <1043342516.3e3024b4c25cf@imp.free.fr> En r?ponse ? Pamel : > This could work pretty easily if UCI Buffered all of the timecodes when > a > codec gave it a null frame. Then the codec could output the block > when > ready with what buffered frame the block would be at, and indicate all > other > frames afterwards only need to pull from that one keyframe. Then > Matroska > stores the keyframe block and stores the list of timecodes that refer > to > that block. Yes... Also note that OGG doesn't have the thing we call timecode (nor AVI does). It should be seen as a (increasing) "number"... http://matroska.org From paul at msn.com Thu Jan 23 18:40:39 2003 From: paul at msn.com (Pamel) Date: Thu, 23 Jan 2003 11:40:39 -0600 Subject: [matroska-devel] Re: How UCI and Matroska could interact References: <20030123144634.79077.qmail@web12905.mail.yahoo.com> <1043335068.3e30079c03c7a@imp.free.fr> <1043342516.3e3024b4c25cf@imp.free.fr> Message-ID: "Steve Lhomme" wrote > Yes... Also note that OGG doesn't have the thing we call timecode (nor AVI > does). It should be seen as a (increasing) "number"... The timecode can be stored in the granulepos for OGG. But in both cases, the translation can occur in the container library. For instance, UCI hands a frame, with a timecode to libavi. Libavi knows the constant framerate, and the timecode, so it can figure out the framenumber pretty quickly. And the reverse would be done for playback. Libavi gets the frame, framerate, and framenumber from an AVI, and can give UCI the frame, and a timecode. On a side note, this would make it super easy to transcode between formats. Pamel http://matroska.org From moritz at bunkus.org Fri Jan 24 10:06:32 2003 From: moritz at bunkus.org (Moritz Bunkus) Date: Fri, 24 Jan 2003 10:06:32 +0100 Subject: [matroska-devel] libmatroska 0.0.2 Message-ID: <20030124090631.GB18648@bunkus.org> Hi. Just two quick comments. I simply wanted to compile the libs under Linux (no time for application writing at the moment) and had to copy Makefile and Makefile.rules from src/old to src. The other thing: could you please include a complete directory in the zip file? Not just its contents? Thanks :) -- ==> Ciao, Mosu (Moritz Bunkus) http://matroska.org From steve.lhomme at free.fr Fri Jan 24 10:15:57 2003 From: steve.lhomme at free.fr (Steve Lhomme) Date: Fri, 24 Jan 2003 10:15:57 +0100 (CET) Subject: [matroska-devel] Re: libmatroska 0.0.2 In-Reply-To: <20030124090631.GB18648@bunkus.org> References: <20030124090631.GB18648@bunkus.org> Message-ID: <1043399757.3e31044d35b55@imp.free.fr> En r?ponse ? Moritz Bunkus : > > Hi. > > Just two quick comments. I simply wanted to compile the libs under > Linux (no time for application writing at the moment) and had to copy > Makefile and Makefile.rules from src/old to src. Yeah, I didn't check the UNIX makefiles for a while. I may do that on OSX this week-end. > The other thing: could you please include a complete directory in the > zip file? Not just its contents? Thanks :) ? You mean there are empty directories ? BTW, I'll upload these sources on CVS next week (when I find the time). http://matroska.org From moritz at bunkus.org Fri Jan 24 10:26:35 2003 From: moritz at bunkus.org (Moritz Bunkus) Date: Fri, 24 Jan 2003 10:26:35 +0100 Subject: [matroska-devel] Re: libmatroska 0.0.2 In-Reply-To: <1043399757.3e31044d35b55@imp.free.fr> References: <20030124090631.GB18648@bunkus.org> <1043399757.3e31044d35b55@imp.free.fr> Message-ID: <20030124092635.GC18648@bunkus.org> Hi. > Yeah, I didn't check the UNIX makefiles for a while. I may do that on OSX this > week-end. Simply copying Makefile and Makefile.rules from src/old to src is enough - it then compiles fine under Linux. > ? > You mean there are empty directories ? No. At the moment the zip contains src, tools, test etc. I'd like it to contain libmatroska-0.0.2/src, libmatroska-0.0.2/tools etc - so that when I unzip it it will create a directory libmatroska-0.0.2 first and all files under this directory (and not in the current working directory). -- ==> Ciao, Mosu (Moritz Bunkus) http://matroska.org From steve.lhomme at free.fr Fri Jan 24 10:55:39 2003 From: steve.lhomme at free.fr (Steve Lhomme) Date: Fri, 24 Jan 2003 10:55:39 +0100 (CET) Subject: [matroska-devel] Re: libmatroska 0.0.2 In-Reply-To: <20030124092635.GC18648@bunkus.org> References: <20030124090631.GB18648@bunkus.org> <1043399757.3e31044d35b55@imp.free.fr> <20030124092635.GC18648@bunkus.org> Message-ID: <1043402139.3e310d9b62fe7@imp.free.fr> En r?ponse ? Moritz Bunkus : > > ? > > You mean there are empty directories ? > > No. At the moment the zip contains src, tools, test etc. I'd like it > to > contain libmatroska-0.0.2/src, libmatroska-0.0.2/tools etc - so that > when I unzip it it will create a directory libmatroska-0.0.2 first and > all files under this directory (and not in the current working > directory). Ah, I see... Well in Windows people often do the opposite : Right-Click->Extract to "libmatroska.v0.0.2" (based on the name of the archive) Also not embedding an extra dir allows you to extract to to an existing dir easily, to "upgrade" your existing sources :) http://matroska.org From moritz at bunkus.org Fri Jan 24 12:02:50 2003 From: moritz at bunkus.org (Moritz Bunkus) Date: Fri, 24 Jan 2003 12:02:50 +0100 Subject: [matroska-devel] Re: libmatroska 0.0.2 In-Reply-To: <1043402139.3e310d9b62fe7@imp.free.fr> References: <20030124090631.GB18648@bunkus.org> <1043399757.3e31044d35b55@imp.free.fr> <20030124092635.GC18648@bunkus.org> <1043402139.3e310d9b62fe7@imp.free.fr> Message-ID: <20030124110250.GD18648@bunkus.org> Hi. > Ah, I see... Well in Windows people often do the opposite : > Right-Click->Extract to "libmatroska.v0.0.2" (based on the name of the archive) Then they can also do Right-Click->Extract to current dir (or something similar like that). About all Unix/Linux software uses the other approach, and I would also expect this behaviour under Windows. It's a matter of 'do not clutter the current dir with all your files'. -- ==> Ciao, Mosu (Moritz Bunkus) http://matroska.org From steve.lhomme at free.fr Fri Jan 24 12:24:41 2003 From: steve.lhomme at free.fr (Steve Lhomme) Date: Fri, 24 Jan 2003 12:24:41 +0100 (CET) Subject: [matroska-devel] Re: libmatroska 0.0.2 In-Reply-To: <20030124110250.GD18648@bunkus.org> References: <20030124090631.GB18648@bunkus.org> <1043399757.3e31044d35b55@imp.free.fr> <20030124092635.GC18648@bunkus.org> <1043402139.3e310d9b62fe7@imp.free.fr> <20030124110250.GD18648@bunkus.org> Message-ID: <1043407481.3e312279ef198@imp.free.fr> En r?ponse ? Moritz Bunkus : > > Hi. > > > Ah, I see... Well in Windows people often do the opposite : > > Right-Click->Extract to "libmatroska.v0.0.2" (based on the name of the > archive) > > Then they can also do Right-Click->Extract to current dir (or > something > similar like that). About all Unix/Linux software uses the other > approach, and I would also expect this behaviour under Windows. It's a > matter of 'do not clutter the current dir with all your files'. Yes, you also have the choice. But in the case I use, I have a real choice not to have a dir name that is forced. I know the .tar.gz usual convention is to have the dir embedded. So maybe the sources should be in that format. Anyway, the best way is to work from CVS (soon). http://matroska.org From moritz at bunkus.org Fri Jan 24 14:03:32 2003 From: moritz at bunkus.org (Moritz Bunkus) Date: Fri, 24 Jan 2003 14:03:32 +0100 Subject: [matroska-devel] more questions about libmatroska & CVS Message-ID: <20030124130332.GF18648@bunkus.org> Hi. Several questions: 1) It seems that libmatroska does its own stream handling, and that there's nothing I can do about it. So it will either take a file name or an URL from which it reads its data. Is this true? If yes, will this be changed? It should be changed, because streaming/file access should not be part of a container library, just like decoding isn't part of it. 2) If I get CVS access: what rules should I follow regarding coding style? Just use the same style as the source file? How about simple indentation changes (e.g. because I had to remove/add a for loop)? Who should commit? Should patches be sent to this list prior to committing? I know several projects that all have different policies regarding sources and CVS, so I just want to know which rules apply here :) -- ==> Ciao, Mosu (Moritz Bunkus) http://matroska.org From steve.lhomme at free.fr Fri Jan 24 15:08:03 2003 From: steve.lhomme at free.fr (Steve Lhomme) Date: Fri, 24 Jan 2003 15:08:03 +0100 (CET) Subject: [matroska-devel] Re: more questions about libmatroska & CVS In-Reply-To: <20030124130332.GF18648@bunkus.org> References: <20030124130332.GF18648@bunkus.org> Message-ID: <1043417283.3e3148c378991@imp.free.fr> En r?ponse ? Moritz Bunkus : > Hi. Hi > Several questions: > > 1) It seems that libmatroska does its own stream handling, and that > there's nothing I can do about it. So it will either take a file name > or an URL from which it reads its data. Is this true? If yes, will > this > be changed? It should be changed, because streaming/file access should > not be part of a container library, just like decoding isn't part of > it. I don't really understand. What do you call stream handling ? If that's the IO functions, there is a virtual class for that, and it can be used to create another stream handling (one that does internal caching for example) if you need to. These classes are part of the library, but should not use the libebml or libmatroska namespaces. They are the same ones used in libmcf (and probably copyrighted by Ingo). > 2) If I get CVS access: what rules should I follow regarding coding > style? Just use the same style as the source file? How about simple > indentation changes (e.g. because I had to remove/add a for loop)? Who > should commit? Should patches be sent to this list prior to > committing? There is currently no coding rules. But an good usual rule is to follow the ones you find in the file you modify. I created 95% of them and usually code the same way, but it may vary with time. As long as the code is readable it's OK with me. I use a lot of tabs, but when alignement is required (ie not just code identation) spaces should be used. For the CVS, everyone is free to make modifications. There should be a mailing list that notice all commits, but it's not currently working (I'll fix that). http://matroska.org From moritz at bunkus.org Fri Jan 24 15:43:03 2003 From: moritz at bunkus.org (Moritz Bunkus) Date: Fri, 24 Jan 2003 15:43:03 +0100 Subject: [matroska-devel] Re: more questions about libmatroska & CVS In-Reply-To: <1043417283.3e3148c378991@imp.free.fr> References: <20030124130332.GF18648@bunkus.org> <1043417283.3e3148c378991@imp.free.fr> Message-ID: <20030124144303.GG18648@bunkus.org> Hi. > I don't really understand. What do you call stream handling ? If that's the IO > functions, there is a virtual class for that, and it can be used to create > another stream handling (one that does internal caching for example) if you need > to. These classes are part of the library, but should not use the libebml or > libmatroska namespaces. They are the same ones used in libmcf (and probably > copyrighted by Ingo). What I call stream handling is reading from files, downloading from URLs, supporting protocols like HTTP, RTSP and many more, reading from a MODE2 CD etc. So far I've only found two functions in the C api (src/api/libmatroska.h) that seem to 'open' something: matroska_open_stream_file and matroska_open_url. Unfortunately I won't be able to use that with e.g. mplayer at all - mplayer itself does all I/O handling (including reading from files/devices/network), and the demultiplexers only handle the data given to them by the stream layer. Please note that I don't have much insight into all the matroska code yet as I'm rather new to it. What I have to do is use the C api (as mplayer won't accept C++ code inside its source, but I can link against the libmatroska) and a method similar to libogg - it just receives the data from the application but does not handle files itself. How would I have to extend the current sources for this? The things for CVS are all perfectly fine with me. -- ==> Ciao, Mosu (Moritz Bunkus) http://matroska.org From jadaschlenker at compuserve.de Fri Jan 24 20:21:50 2003 From: jadaschlenker at compuserve.de (Kromyx) Date: Fri, 24 Jan 2003 20:21:50 +0100 Subject: [matroska-devel] Re: more questions about libmatroska & CVS References: <20030124130332.GF18648@bunkus.org> <1043417283.3e3148c378991@imp.free.fr> <20030124144303.GG18648@bunkus.org> Message-ID: Moritz Bunkus schrieb in im Newsbeitrag: 20030124144303.GG18648 at bunkus.org... > > Hi. > > > I don't really understand. What do you call stream handling ? If that's the IO > > functions, there is a virtual class for that, and it can be used to create > > another stream handling (one that does internal caching for example) if you need > > to. These classes are part of the library, but should not use the libebml or > > libmatroska namespaces. They are the same ones used in libmcf (and probably > > copyrighted by Ingo). > > What I call stream handling is reading from files, downloading from > URLs, supporting protocols like HTTP, RTSP and many more, reading from > a MODE2 CD etc. So far I've only found two functions in the C api > (src/api/libmatroska.h) that seem to 'open' something: > matroska_open_stream_file and matroska_open_url. Unfortunately I won't > be able to use that with e.g. mplayer at all - mplayer itself does all > I/O handling (including reading from files/devices/network), and the > demultiplexers only handle the data given to them by the stream layer. > > Please note that I don't have much insight into all the matroska code > yet as I'm rather new to it. What I have to do is use the C api (as > mplayer won't accept C++ code inside its source, but I can link against > the libmatroska) and a method similar to libogg - it just receives the > data from the application but does not handle files itself. > > How would I have to extend the current sources for this? > > The things for CVS are all perfectly fine with me. > > -- > ==> Ciao, Mosu (Moritz Bunkus) > http://matroska.org > i dont want to interfere but i guess i know what youre talking about. in "dshow language" these models are called push and pull. mplayer uses the "push" model which means it pushes the data towards the demuxer. libmatroska (as well as libmcf) uses the pull model by requesting specific data portions. there is a little bit of incompatibility between those models. to use libmatroska with mplayer you need to write a IOCallback derived class and add a new function to the c-api like matroska_stream matroska_open_push_stream(..) { IOCallbackDerivedClass *fileid = new IOCallbackDerivedClass(...); return file_id; } the IOCallback derived class requires its own c-api for finally pushing the data to the demuxer. the big problem is that you dont know which parts of the matroska file libmatroska wants to read at a specfic moment so in the worst case the IOCallbackDerivedClass needs to buffer the whole file. im not to familiar with mplayer and so on, but i hope i could help Jan(kromyx/myFUN) --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.434 / Virus Database: 243 - Release Date: 25.12.02 http://matroska.org From moritz at bunkus.org Sun Jan 26 20:25:23 2003 From: moritz at bunkus.org (Moritz Bunkus) Date: Sun, 26 Jan 2003 20:25:23 +0100 Subject: [matroska-devel] Re: more questions about libmatroska & CVS In-Reply-To: References: <20030124130332.GF18648@bunkus.org> <1043417283.3e3148c378991@imp.free.fr> <20030124144303.GG18648@bunkus.org> Message-ID: <20030126192523.GD4537@bunkus.org> Hi. > i dont want to interfere but i guess i know what youre talking about. in > "dshow language" these models are called push and pull. mplayer uses the > "push" model which means it pushes the data towards the demuxer. libmatroska > (as well as libmcf) uses the pull model by requesting specific data > portions. Yeah, that's what I meant. > the IOCallback derived class requires its own c-api for finally pushing the > data to the demuxer. the big problem is that you dont know which parts of > the matroska file libmatroska wants to read at a specfic moment so in the > worst case the IOCallbackDerivedClass needs to buffer the whole file. So... My next question is about the format in general. Does the format allow for sequential demultiplexing? The way Ogg works? Or does it require seeking (like AVI for its index)? I'm pretty sure that it won't need seeking because that makes streaming impossible, and you surely have thought about that. What I mean is an approach like Ogg. Here's how it works: 1. application reads data from a source (file, network, whatever) 2. application feeds that data to the Ogg library 3. the Ogg library buffers that data and returns whether or not it has enough to demultiplex a complete Ogg page 4. if not goto 1 Is that possible for matroska? > im not to familiar with mplayer and so on, but i hope i could help You definitly know what I'm talking about :) -- ==> Ciao, Mosu (Moritz Bunkus) http://matroska.org From steve.lhomme at free.fr Sun Jan 26 20:53:29 2003 From: steve.lhomme at free.fr (Steve Lhomme) Date: Sun, 26 Jan 2003 20:53:29 +0100 Subject: [matroska-devel] Re: more questions about libmatroska & CVS In-Reply-To: <20030126192523.GD4537@bunkus.org> References: <20030124130332.GF18648@bunkus.org> <1043417283.3e3148c378991@imp.free.fr> <20030124144303.GG18648@bunkus.org> <20030126192523.GD4537@bunkus.org> Message-ID: <3E343CB9.3090909@free.fr> Moritz Bunkus wrote: > So... My next question is about the format in general. Does the format > allow for sequential demultiplexing? The way Ogg works? Or does it > require seeking (like AVI for its index)? I'm pretty sure that it won't > need seeking because that makes streaming impossible, and you surely > have thought about that. > > What I mean is an approach like Ogg. Here's how it works: > > 1. application reads data from a source (file, network, whatever) > 2. application feeds that data to the Ogg library > 3. the Ogg library buffers that data and returns whether or not it has > enough to demultiplex a complete Ogg page > 4. if not goto 1 > > Is that possible for matroska? Well, as it has been already said, libmatroska uses a pull method (but on the application request) while here it sounds more like a push method (from the application) but the result (getting frames from various selected tracks) is the same (and therefore exists). http://matroska.org From steve.lhomme at free.fr Sat Jan 25 17:12:14 2003 From: steve.lhomme at free.fr (Steve Lhomme) Date: Sat, 25 Jan 2003 17:12:14 +0100 Subject: [matroska-devel] Re: more questions about libmatroska & CVS In-Reply-To: <20030124130332.GF18648@bunkus.org> References: <20030124130332.GF18648@bunkus.org> <1043417283.3e3148c378991@imp.free.fr> <20030124144303.GG18648@bunkus.org> Message-ID: <3E32B75E.4000601@free.fr> Moritz Bunkus wrote: > What I call stream handling is reading from files, downloading from > URLs, supporting protocols like HTTP, RTSP and many more, reading from > a MODE2 CD etc. So far I've only found two functions in the C api > (src/api/libmatroska.h) that seem to 'open' something: > matroska_open_stream_file and matroska_open_url. Unfortunately I won't > be able to use that with e.g. mplayer at all - mplayer itself does all > I/O handling (including reading from files/devices/network), and the > demultiplexers only handle the data given to them by the stream layer. Well, the C API is the one from the old libmcf. It is currently not "connected" to the matroska elements. But that API shouldn't need much change (if any). At the C++ level there definitely is classes to override for each IO system needed (HD caching, network, etc). I'm not sure that at the C level there is something similar. It would probably be through a FILE pointer, maybe it can be done another way. If you have any idea on improving the C API (hopefully mapping the necessary structures to a C++ class that use IOCallback), feel free to submit that code. > Please note that I don't have much insight into all the matroska code > yet as I'm rather new to it. What I have to do is use the C api (as > mplayer won't accept C++ code inside its source, but I can link against > the libmatroska) and a method similar to libogg - it just receives the > data from the application but does not handle files itself. In what form would that be ? If that's general enough it should be easy to use it in the C API and map it to an internal C++ class (all elements read/write is done through an IOCallback class). http://matroska.org From christian.hj.wiesner at web.de Sat Jan 25 07:40:18 2003 From: christian.hj.wiesner at web.de (Christian HJ Wiesner) Date: Sat, 25 Jan 2003 07:40:18 +0100 Subject: [matroska-devel] [Fwd: Re: Hosting of MPC] Message-ID: <3E323152.2080700@web.de> Email from Frank : -------- Original Message -------- Subject: Re: Hosting of MPC Date: Fri, 24 Jan 2003 22:51:12 +0100 From: Frank Klemm To: Christian HJ Wiesner References: <3DB411A0.32750.1362067 at localhost> <004e01c2c14f$6dea6450$a70aa8c0 at mahlo.de> <20030123140827.A15489 at fuchs.offl.uni-jena.de> <3E30847C.50104 at web.de> http://matroska.sourceforge.net/specs/index.html ------------------------ SamplingFrequency 4 [B5] - >0 - float Sampling frequency in Hz. Channels 4 [9F] - not 0 2 u-integer Numbers of channels in the track. ------------------------ w?rde ich auf ( i would change to ) ------------------------ SamplingFrequency 4 [B5] - >0 8000. float Sampling frequency in Hz. Channels 4 [9F] - not 0 1 u-integer Numbers of channels in the track. ------------------------ 1. halte ich nicht sonderlich viel von solchen impliziten Werten, man spart ein paar Bytes in einer Multimegabyte-Datei und handelt sich vorhersehbaren ?rger ein. Bin genug h?ufig in so was selbst reingetappt, das letzte mal gestern. 2. Von Interesse sein k?nnen die Einsparungen von ein paar Bytes bei Datenstr?men mit sehr geringer Datenrate und Qualit?t. Das ist dann meistens Mono (und nicht Stereo) und 8 kHz Abtastfrequenz. ============================================================================= ------------------------------------------------------------------------ PixelAspectRatio 4 [41][52] - >0 1.333333 float Pixel aspect ratio of the pixels. ------------------------------------------------------------------------ [Frank]Dieses Beispiel ist irref?hrend. Es gibt kein Movieformat, was ein Pixelseitenverh?ltnis von 4:3 verwendet. Last das so schnell wie m?glich verschwinden, sonst gibt es so viele fehlerhafte Implementierungen, so da? es am Ende einfacher ist den Standard zu ?ndern als die Fehler zu fixen.[/Frank] This example is not good, there is no such thing as a 4:3 AR. I'd remove that or errors will be the result. [Frank]Ich hatte die Werte schon man geschickt, zweiter Versuch, einen dritten gibt es nicht:[/Frank] I sent these values already, i wont send them another time : [Frank] horizontal:vertikal HDTV: 1:1 PAL: 16:15 PAL anamorph: 64:45 NTSC: 8:9 NTSC anamorph: 32:27 Ich w?rde das Verh?ltnis als zwei teilerfremde Ganzzahlen abspeichern. Gleitkommazahlen sind erstens ungenauer und zweitens verleiten sie zur sogenannten Gleitkomma-Schmiererkrankung. Man speichert ungef?hr richtige Werte ab und ?berl??t es dem Programmierer, diesen Schlamassel durch etwas heuristischen Code meistens unsichtbar zu machen.[/Frank] I would store the values as two integer numbers. Floats are more unprecise and often handled incorrectly. [Frank]Wenn z.B. "NTSC anamorph" abgespeichert, ist was ungef?hr 1:1.18518518518518518518 ist, dann wird man verschiedene Werte in dem Tag finden: 1.2 1.18 1.19 1.185 1.1852 1.185185185 Und der Decoder mu? dann wieder raten, was gemeint ist. Wenn dagegen { 32, 27 } zu stehen hat, dann ist eindeutig alles andere FALSCH. Keine Gleitkommaschmiererkrankung und keiner der fluchen mu?, da? sein AR von exakt 1:1.2 auf 1:1.185185185 getweakt wird und die Software damit f?r seine Me?zwecke unbrauchbar ist. Frank Klemm[/Frank] E.g, ,these are the values you will find for the NTSC anamorph standard if you specify floats. In the end the decoder will have to make a guess again ... http://matroska.org From steve.lhomme at free.fr Sat Jan 25 17:04:14 2003 From: steve.lhomme at free.fr (Steve Lhomme) Date: Sat, 25 Jan 2003 17:04:14 +0100 Subject: [matroska-devel] Re: [Fwd: Re: Hosting of MPC] In-Reply-To: <3E323152.2080700@web.de> References: <3E323152.2080700@web.de> Message-ID: <3E32B57E.4020104@free.fr> Christian HJ Wiesner wrote: > Email from Frank : > > -------- Original Message -------- > Subject: Re: Hosting of MPC > Date: Fri, 24 Jan 2003 22:51:12 +0100 > From: Frank Klemm > To: Christian HJ Wiesner > References: <3DB411A0.32750.1362067 at localhost> > <004e01c2c14f$6dea6450$a70aa8c0 at mahlo.de> > <20030123140827.A15489 at fuchs.offl.uni-jena.de> <3E30847C.50104 at web.de> > > > > http://matroska.sourceforge.net/specs/index.html > > > > > ------------------------ > > SamplingFrequency 4 [B5] - >0 - float Sampling frequency in Hz. > Channels 4 [9F] - not 0 2 u-integer Numbers of channels in the track. > > ------------------------ > > w?rde ich auf ( i would change to ) > > ------------------------ > SamplingFrequency 4 [B5] - >0 8000. float Sampling frequency in Hz. > Channels 4 [9F] - not 0 1 u-integer Numbers of channels in the track. > ------------------------ > > 1. halte ich nicht sonderlich viel von solchen impliziten Werten, > man spart ein paar Bytes in einer Multimegabyte-Datei und handelt > sich vorhersehbaren ?rger ein. Bin genug h?ufig in so was > selbst reingetappt, das letzte mal gestern. > > 2. Von Interesse sein k?nnen die Einsparungen von ein paar Bytes bei > Datenstr?men mit sehr geringer Datenrate und Qualit?t. Das ist dann > meistens Mono (und nicht Stereo) und 8 kHz Abtastfrequenz. Sorry, my german is not good enough to understand this, and I have no offline translator ;) As I said on the EBML website (http://ebml.sourceforge.net/) EBML is very verbose (as is XML) so it is convenient to have good default values so that the general-case-file will not take too much space. And I think the general case for digital audio is still 44100/stereo. I don't know much people using 8000/mono... Now of course that would save space in the most space limited case. Which approach is better ? > > ============================================================================= > > ------------------------------------------------------------------------ > PixelAspectRatio 4 [41][52] - >0 1.333333 float Pixel aspect ratio of > the pixels. > ------------------------------------------------------------------------ > > [Frank]Dieses Beispiel ist irref?hrend. Es gibt kein Movieformat, was ein > Pixelseitenverh?ltnis von 4:3 verwendet. Last das so schnell wie m?glich > verschwinden, sonst gibt es so viele fehlerhafte Implementierungen, so da? > es am Ende einfacher ist den Standard zu ?ndern als die Fehler zu > fixen.[/Frank] > > This example is not good, there is no such thing as a 4:3 AR. I'd remove > that or errors will be the result. Uh ? So we should put 1.00000 ? > [Frank]Ich hatte die Werte schon man geschickt, zweiter Versuch, einen > dritten gibt > es nicht:[/Frank] > > I sent these values already, i wont send them another time : > > [Frank] horizontal:vertikal > HDTV: 1:1 > PAL: 16:15 > PAL anamorph: 64:45 > NTSC: 8:9 > NTSC anamorph: 32:27 Is that the pixel aspect-ratio or the display aspect-ratio ? I think the most logicial for a computer format is 1.0000 PAR. What do the experts think ? > Ich w?rde das Verh?ltnis als zwei teilerfremde Ganzzahlen abspeichern. > Gleitkommazahlen sind erstens ungenauer und zweitens verleiten sie zur > sogenannten Gleitkomma-Schmiererkrankung. Man speichert ungef?hr richtige > Werte ab und ?berl??t es dem Programmierer, diesen Schlamassel durch > etwas heuristischen Code meistens unsichtbar zu machen.[/Frank] > > I would store the values as two integer numbers. Floats are more > unprecise and often handled incorrectly. Well, what would be the difference with the Height and Width of the movie ? One would be the encoding and the other the display ? > [Frank]Wenn z.B. "NTSC anamorph" abgespeichert, ist was ungef?hr > 1:1.18518518518518518518 > ist, dann wird man verschiedene Werte in dem Tag finden: > > 1.2 > 1.18 > 1.19 > 1.185 > 1.1852 > 1.185185185 > > Und der Decoder mu? dann wieder raten, was gemeint ist. > Wenn dagegen { 32, 27 } zu stehen hat, dann ist eindeutig alles andere > FALSCH. Keine Gleitkommaschmiererkrankung und keiner der fluchen mu?, > da? sein AR von exakt 1:1.2 auf 1:1.185185185 getweakt wird und die > Software damit f?r seine Me?zwecke unbrauchbar ist. > Frank Klemm[/Frank] > > E.g, ,these are the values you will find for the NTSC anamorph standard > if you specify floats. In the end the decoder will have to make a > guess again ... So can we go for the encoding Width/Height and the display Width/Height ? http://matroska.org From pfk at fuchs.offl.uni-jena.de Sat Jan 25 22:51:23 2003 From: pfk at fuchs.offl.uni-jena.de (Frank Klemm) Date: Sat, 25 Jan 2003 22:51:23 +0100 Subject: [matroska-devel] Re: [Fwd: Re: Hosting of MPC] In-Reply-To: <3E32B57E.4020104@free.fr>; from steve.lhomme@free.fr on Sat, Jan 25, 2003 at 05:04:14PM +0100 References: <3E323152.2080700@web.de> <3E32B57E.4020104@free.fr> Message-ID: <20030125225123.A7376@fuchs.offl.uni-jena.de> On Sat, Jan 25, 2003 at 05:04:14PM +0100, Steve Lhomme wrote: > > > > ------------------------ > > > > SamplingFrequency 4 [B5] - >0 - float Sampling frequency in Hz. > > Channels 4 [9F] - not 0 2 u-integer Numbers of channels in the track. > > > > ------------------------ > > > > w?rde ich auf ( i would change to ) > > > > ------------------------ > > SamplingFrequency 4 [B5] - >0 8000. float Sampling frequency in Hz. > > Channels 4 [9F] - not 0 1 u-integer Numbers of channels in the track. > > ------------------------ > > > > 1. halte ich nicht sonderlich viel von solchen impliziten Werten, > > man spart ein paar Bytes in einer Multimegabyte-Datei und handelt > > sich vorhersehbaren ?rger ein. Bin genug h?ufig in so was > > selbst reingetappt, das letzte mal gestern. > > > > 2. Von Interesse sein k?nnen die Einsparungen von ein paar Bytes bei > > Datenstr?men mit sehr geringer Datenrate und Qualit?t. Das ist dann > > meistens Mono (und nicht Stereo) und 8 kHz Abtastfrequenz. > > Sorry, my german is not good enough to understand this, and I have no > offline translator ;) > As I said on the EBML website (http://ebml.sourceforge.net/) EBML is > very verbose (as is XML) so it is convenient to have good default values > so that the general-case-file will not take too much space. And I think > the general case for digital audio is still 44100/stereo. > Using implicit channel count and implicit sample frequency saves some bytes (I think it's 9 bytes). Such implicit values often make touble, so it's not worth to save these 9 bytes. The only exception are very low bitrate/low quality streams, where are 9 bytes are not astronomic smaller than the size of the whole stream. It such cases it may makes sense to use such implicit values, not when storing CD tracks in transparent quality on multi gigabyte harddisks. These very low bitrate/low quality streams are typically 8 kHz (and not 44.1 kHz or 48 kHz or 96 kHz or whatever) and monophonic (an not 2 channel stereo or 5.1 channel stereo). Candidates are for instance LP10, CELP and Speex. At 2400 bps...4800 bps 72 bits are the data for 15...7.5 ms. > I don't know much people using 8000/mono... Now of course that would save > space in the most space limited case. Which approach is better ? > I would say the most often used low bitrate configuration. AFAIK this is 1 channel/8000 Hz. Ogg Vorbis has made some test with 1 channel/6000 Hz, but I don't think this helps so much to preserve "quality" at 3 kbps and also it is not very common. > > > > ============================================================================= > > > > ------------------------------------------------------------------------ > > PixelAspectRatio 4 [41][52] - >0 1.333333 float Pixel aspect ratio of > > the pixels. > > ------------------------------------------------------------------------ > > > > [Frank]Dieses Beispiel ist irref?hrend. Es gibt kein Movieformat, was ein > > Pixelseitenverh?ltnis von 4:3 verwendet. Last das so schnell wie m?glich > > verschwinden, sonst gibt es so viele fehlerhafte Implementierungen, so da? > > es am Ende einfacher ist den Standard zu ?ndern als die Fehler zu > > fixen.[/Frank] > > > > This example is not good, there is no such thing as a 4:3 AR. I'd remove > > that or errors will be the result. > > Uh ? So we should put 1.00000 ? > I think 1.000000000 would be a useful default. For normal TV there are too much different pixel ARs and for low bitrate Video I think the AR is often 1.000000000 by using computer monitor resolutions and parts of it. There are also TV resolutions and parts of it in use, but there's no "natural" setting, but too much candidates. I think 1.00000000 is a good value. The other values for the 4 DVD formats should be mentioned, because you don't find these values in the internet directly, so I think it is useful to mention the right values. > > [Frank]Ich hatte die Werte schon man geschickt, zweiter Versuch, einen > > dritten gibt > > es nicht:[/Frank] > > > > I sent these values already, i wont send them another time : > > > > [Frank] horizontal:vertikal > > HDTV: 1:1 > > PAL: 16:15 > > PAL anamorph: 64:45 > > NTSC: 8:9 > > NTSC anamorph: 32:27 > > Is that the pixel aspect-ratio or the display aspect-ratio? > Pixel aspect ratio. > I think the most logical for a computer format is 1.0000 PAR. > It is logical, but seldom used ;-) PAL: 16:15 PAL anamorph: 64:45 NTSC: 8:9 NTSC anamorph: 32:27 Computer 1280x1024: 16:15 HDTV and other Computer formats except CGA, EGA and VGA text and relatives: 1:1 > What do the experts think ? > You can find image ARs and resolution in the internet/books/... . The rest is simple math. > > > Ich w?rde das Verh?ltnis als zwei teilerfremde Ganzzahlen abspeichern. > > Gleitkommazahlen sind erstens ungenauer und zweitens verleiten sie zur > > sogenannten Gleitkomma-Schmiererkrankung. Man speichert ungef?hr richtige > > Werte ab und ?berl??t es dem Programmierer, diesen Schlamassel durch > > etwas heuristischen Code meistens unsichtbar zu machen.[/Frank] > > > > I would store the values as two integer numbers. Floats are more > > unprecise and often handled incorrectly. > > Well, what would be the difference with the Height and Width of the > movie ? One would be the encoding and the other the display ? > > > [Frank]Wenn z.B. "NTSC anamorph" abgespeichert, ist was ungef?hr > > 1:1.18518518518518518518 > > ist, dann wird man verschiedene Werte in dem Tag finden: > > > > 1.2 > > 1.18 > > 1.19 > > 1.185 > > 1.1852 > > 1.185185185 > > > > Und der Decoder mu? dann wieder raten, was gemeint ist. > > Wenn dagegen { 32, 27 } zu stehen hat, dann ist eindeutig alles andere > > FALSCH. Keine Gleitkommaschmiererkrankung und keiner der fluchen mu?, > > da? sein AR von exakt 1:1.2 auf 1:1.185185185 getweakt wird und die > > Software damit f?r seine Me?zwecke unbrauchbar ist. > > Frank Klemm[/Frank] > > > > E.g, ,these are the values you will find for the NTSC anamorph standard > > if you specify floats. In the end the decoder will have to make a > > guess again ... > > > So can we go for the encoding Width/Height and the display Width/Height ? > You can store: [Proposal 1] - horizontal pixel count [u-integer] 1) - vertical pixel count [u-integer] 1) - aspect ratio of the pixel as a:b, where are a and b are nonzero [u-integer]s Examples: hor_res = 720, vert_res = 576, pixel_AR = {16,15} hor_res = 1280, vert_res = 720, pixel_AR = {1,1} hor_res = 1920, vert_res = 1080, pixel_AR = {1,1} hor_res = 352, vert_res = 288, pixel_AR = {16,15} disadvantage: "unusual" number for the AR advantage: cropping an image don't affect the pixel_AR 1) please don't use the word "horizontal resolution", because it isn't a resolution in the physical sense. Such dirtiness in word selection is one reason why are standards are often so difficult to read. [Proposal 2] - horizontal pixel count [u-integer] - vertical pixel count [u-integer] - aspect ratio of the display as a:b, where are a and b are nonzero [u-integer]s Examples: hor_res = 720, vert_res = 576, display_AR = {4,3} hor_res = 1280, vert_res = 720, display_AR = {16,9} hor_res = 1920, vert_res = 1080, display_AR = {16,9} hor_res = 352, vert_res = 288, display_AR = {176,135} advantage: "usual" number for the AR advantage: cropping an image affects display_AR, and this, and in reality this is nearly never corrected. [Remark 3] both ARs can be stored using two different ways: - stored as float [usually 4 bytes are more than enough] + you calculate and store the AR with an accuracy of less than 3*10^-8. - you find seldom correct values in floating point entities, I expect more incorrect values when stored as FP value. - stored as 2 u-integers (size of each is half the size of the item) - to store a calculated value is more difficult, you must search two a and b's which do approximate AR=a/b very well. - it is easier to force correct ARs, because you can say what is right and what is very likely wrong. Hope this info is enough to make a wise decision. -- Frank Klemm http://matroska.org From christian.hj.wiesner at web.de Sat Jan 25 07:43:31 2003 From: christian.hj.wiesner at web.de (Christian HJ Wiesner) Date: Sat, 25 Jan 2003 07:43:31 +0100 Subject: [matroska-devel] MPC SV8 framing sources Message-ID: <3E323213.2070300@web.de> HI, attached some code Frank has written to handle SV8 streams. If anybody ( raghav ? ) feels like he wanted to start looking at a MPC2matroska.exe . Regards Christian -------- Original Message -------- Subject: Re: Hosting of MPC Date: Fri, 24 Jan 2003 16:00:47 +0100 From: Frank Klemm To: Christian HJ Wiesner References: <3DB411A0.32750.1362067 at localhost> <004e01c2c14f$6dea6450$a70aa8c0 at mahlo.de> <20030123140827.A15489 at fuchs.offl.uni-jena.de> <3E30847C.50104 at web.de> On Fri, Jan 24, 2003 at 01:10:36AM +0100, Christian HJ Wiesner wrote: > > Es war immer geplant da? der player auf einer komplett anderen homepage > gehostet wird, n?mlich auf > > http://www.corecodeD.com ( beachte das 'D' statt dem 'C' ) > > Emmett hat nun gegen?ber der FSF einfach behauptet da? wir den server > space von der FSF K?ln dazu verwenden wollten um den closed source > player zu verbreiten, was einfach schlicht weg gelogen war. > > Ich will nichts b?ses ?ber ihn sagen, er liebt sein Ogg und Vorbis und > auch open source, aber er greift manchmal in seiner Liebe zu sehr > fragw?rdigen Mitteln, und wenn er so viel arbeiten w?rde wie er schw?tzt > w?re er schon Multi-Million?r ;-) ... > Irgendwie scheinen zur Zeit radikale Einstellungen und Meinungen Hochkonjunktur zu haben. Desweiteren Weiterbrabbeln von unverstandenem und Halbwissen. Das betrifft Politik, Tagesgeschehen und eigentliches alles, was man im Netz findet. Fast alles wird nur noch so oberfl?chlich angerissen, da? man fast alles nur noch als "falsch" deklarieren k?nnte. Zu Ogg Vorbis: - Ich hatte an Monty einen Vorschlag geschickt, wie man IMHO patentfrei PNS in Ogg Vorbis reinbekommt, was bei geringen Bitraten sehr gro?e Vorteile bringt. Das Verfahren w?re ziemlich flexibel. Keine Antwort. - Ich hatte in Ogg Vorbis den Wunsch, mit 3 Blockgr??en arbeiten zu k?nnen. 1024 ist f?r viele Signale (Popmusik heutiger Zeit, Sprache!) bei 44.1 kHz/48 kHz und erst recht bei 32 kHz viel zu lang und 128 sind dann doch etwas zu kurz. Keine Antwort. Denkbar w?ren 1024/512/128 f?r q < 6 und 1024/256/64 f?r q >= 6. Transientenprobleme sollten dann auch bei einem Transform Codec nicht auftreten. - Ich vermisse eine ANSI-C Implementierung ohne Tonnen von automake-Gerafffel drumrum. Ich bekomme auf meinem etwas ?lteren System zwei Programme nicht zum ?bersetzen, weil irgendwelche Scripte mit Syntax-Fehlern abbrechen: flac + ogg vorbis. Und es gibt jede Menge anderer Leute, bei denen Ogg Vorbis auch nicht ?bersetzt werden kann (und die binaries laufen auch nicht, weil die gegen die allerneuesten versionen der C-lib gelinkt sind). Hier habe ich schon mehrfach eine balastfreie Ogg Vorbis-Version gefordert, die einfach nur eine Datei in eine andere konvertiert. Keine Antwort. Kannst mit dem Problem Dich auch mal an piecha at micronas.com wenden. Nachbemerkung: Ja, mppenc/mppdec ist auch kein Musterbeispiel in Sachen einfacher ?bersetzbarkeit und guter Dokumentation. > >>MPC Einbindung erfolgt dann wenn Frank SV8 einigermassen fertig hat. > >> > > Eigentlich sollte Dienstag eine Version 7.5 released werden, die von ihrer > > Containerstruktur fast genau 8.0 entspricht. Also 20-Zeilen-C-Programm > > mit Nullkenntnis ?ber Interna kann das Teil auseinandernehmen und wieder > > zusammensetzen. > > Aber irgendwie gibt es derzeitig ein paar zu viel Viren hier, und ALLEN aus > > dem Weg zu gehen ist nicht so einfach ... > > Bleibt die SV8 Struktur so wie auf Deiner homepage beschrieben ? Wenn ja > k?nnten wir ja schon mal mit dem Studium desselben beginnen ? > Ich habe mal was angehangen. > >>Folgende Fragen habe ich an euch : > >> > >>- Habt Ihr euch schon entschieden ob ihr mit MPC ein opensource Projekt > >> starten wollt ? > > > > "Opensource" ist ein Sammelbegriff. Die Frage ist, welche Lizenzen. > > LGPL + BSD ??? > > Ich brauchte mal eine Aufstellung aller schon bekannten Lizenzen sowie deren > > Vor- und Nachteile. > > Der robux4 kennt sich hier mittlerweile sehr gut aus. Es gibt eine > homepage die alle bekannten Lizenzen aufz?hlt und die Unterschiede > erkl?rt, muss mal gr?ndlich nach der URL suchen. > > matroska, zumindest der sourcecode der libraries, wird wohl gleichzeitig > unter 3 verschiedenen Lizenzen erscheinen : > > GPL > QPL > Spezial-Lizenz f?r Firmen die libmatroska einsetzen wollen > Warum nicht LGPL? Oder soll das durch die QPL abgefangen werden? Schickt mal die Linzenzdateien zu, ich h?nge sie bei mir mit dran ... Die GPL sollte ich haben. Gibt es da mittlerweile eine Jahr 2000 kompatible (das Beispiel f?ngt immer noch mit 19XX an)? ... mu? mal schnell durch die Quellen gehen und 2002 durch 2003 ersetzen ... > >>- Ist schon eine Entscheidung bzgl. des hosts gefallen ? > >> > > Mir ziemlich egal. Die prim?ren Quellen werden bei mir auf der heimatlichen > > Festplatte liegen. > > > >>- F?llt euch irgendwas an corecodec.org auf was euch nicht gef?llt und > >> ge?ndert werden sollte ? > > > > Keine Meinung. Ich wei? nicht, welche Hosts f?r eine gute Verbreitung gut > > sind. Finanzielle Unterst?tzung f?r die Arbeit erwarte ich nicht, es sollte > > aber dann wenigstens von vielen Leuten genutzt werden. Das w?re "Belohnung" > > genug. > > Das schlimmste w?re etwas, was keinen interessiert. > > Kann mit MPC ja wohl kaum mehr passieren da? sich keiner daf?r > interessiert, oder ;-) ? > > Wir werden f?r Corecodec sehr viel Werbung auf allen einschl?gigen > boards und im Netz machen, ?ber potentielle Nutzer solltest Du Dir daher > keine Sorgen machen m?ssen. > > Alleine der alte PowerDivX Player den BlackSun programmmiert hat fand im > Laufe der Zeit ca. 250.000 treue Fans, der neue Player ist der Hammer > und wird sehr viele Leute zu corecoded.com and damit automatisch auch zu > corecodec.org ziehen. Im Gegensatz zu sourceforge.net ist corecodec.org > spezialisiert auf audio/video und wird zum Anfang bereits > > matroska ( Container ) > UCI ( codec API ) > USF ( subtitle Format auf XML/EBML ) > > beherbergen. > > W?re prima wenn ihr ( Du ) euch f?r corecodec.org als host entscheiden > k?nntet(k?nntest). > Ich shcike Dir die Quellen zu, und Du kannst Dich dann um das Laden auf einen Server k?mmern. Solange nur einer coded, ist das Hosten eigentlich zweitrangig. -- Frank Klemm -- Attached file included as plaintext by Ecartis -- -- File: lhommifier.c #include #include // #define BIDIR_LEN // 1) #define MAX_FRAME_LEN 8191 // 2) static void writeoutput ( const char* basename, long no, const void* data, unsigned int len ) { char name [2048]; FILE* fp; switch ( no ) { case -2: sprintf ( name, "%s.footer", basename ); break; case -1: sprintf ( name, "%s.header", basename ); break; default: sprintf ( name, "%s.%06ld", basename, no ); break; } if ( ( fp = fopen ( name, "wb" ) ) == NULL ) { fprintf ( stderr, "lhommifier: Can't create '%s'\n", name ); exit (126); } fprintf ( stderr, "Writing '%s'...", name ); fwrite ( data, 1, len, fp ); fclose ( fp ); fprintf ( stderr, "\b\b\b \n" ); } int main ( int argc, char** argv ) { unsigned char buff [65536]; // Read/Write buffer FILE* fp; // input file pointer unsigned int len; // length information before a block unsigned int bidir_len; // length information after a block (when BIDIR_LEN is defined) long frames; long i; // usage if ( argc < 2 ) { fprintf ( stderr, "usage: lhommifier filename\n" ); return 1; } // opening of source file if ( ( fp = fopen ( argv [1], "rb" ) ) == NULL ) { fprintf ( stderr, "lhommifier: Can't open '%s'\n", argv [1] ); return 2; } // analysis of 4 byte magic ID + first 2 bytes of header fread ( buff, 1, 6, fp ); if ( 0 != memcmp ( buff, "MP+\xFF", 4 ) ) { // 3) fprintf ( stderr, "lhommifier: Input file '%s' is not StreamVersion 15.15\n", argv [1] ); return 3; } len = buff[4] * 256 + buff[5]; if ( len > MAX_FRAME_LEN ) { fprintf ( stderr, "lhommifier: Header length is out of range [0,%u]: %u\n", MAX_FRAME_LEN, len ); return 4; } // analysis and copying of header len = fread ( buff, 1, len, fp ); writeoutput ( argv[1], -1, buff, len ); frames = ((long)buff [2] << 24) | // 4) ((long)buff [3] << 16) | ((long)buff [4] << 8) | ((long)buff [5] << 0); #ifdef BIDIR_LEN fread ( buff, 1, 2, fp ); bidir_len = buff[4] * 256 + buff[5]; if ( len != bidir_len ) { fprintf ( stderr, "lhommifier: bidir length mismatch in header: %u != %u\n", len, bidir_len ); return 5; } #endif // analysis of frames for ( i = 0; i < frames; i++ ) { fread ( buff, 1, 2, fp ); len = buff[0] * 256 + buff[1]; if ( len > MAX_FRAME_LEN ) { fprintf ( stderr, "lhommifier: Frame #%ld length is out of range [0,%u]: %u\n", i, MAX_FRAME_LEN, len ); return 6; } len = fread ( buff, 1, len, fp ); writeoutput ( argv[1], i, buff, len ); #ifdef BIDIR_LEN fread ( buff, 1, 2, fp ); bidir_len = buff[4] * 256 + buff[5]; if ( len != bidir_len ) { fprintf ( stderr, "lhommifier: bidir length mismatch in frame #ld: %u != %u\n", i, len, bidir_len ); return 7; } #endif } // remaining data are tags (this only copies tags up to 64 KBytes correctly) len = fread ( buff, 1, sizeof buff, fp ); if ( 0 == memcmp ( buff, "APETAGEX", 8 ) ) fprintf ( stderr, "informational: APE tags with header\n" ); if ( 0 == memcmp ( buff, "TAG" , 3 ) ) fprintf ( stderr, "informational: ID3V1 tags\n" ); writeoutput ( argv[1], -2, buff, len ); fclose ( fp ); return 0; } /* end of lhommifier.c */ /* * To be defined: * 1) use of BIDIR_LEN: yes, no, optional ? * + can be used for seek forward and backward * + can be used to detect errors in the stream * + can be used for resync * - needs 0.6 kbps * * 2) MAX_FRAME_LEN: 8191 or 16383 ? * o 8191 = 2.5 Mbps * o 16383 = 5 Mbps * o more than 14 bit are not possible, otherwise there are collisions with tags, headers, etc. which do start with a capital letter * * 3) StreamVersion * o major stream version is stored in the lower 4 bit * o minor stream version is stored in the upper 4 bit * o final format (with different versions) will be something like 8.0...8.3, which ends up with * a \x08, \x18, \x28 or \x38 here * * 4) number of frames is stored as internal data in the header, but this information * is also a very interesting global information, so the offset of this info should be fixed. * Currently at offset 2, but may be offset 0 is better and less arbitrary ??? * * x) For A/V the number of generated PCM samples of one frame may be of interest. * Currently these are 0...1152 (may be also 1536). But this information is not * public available. Is this a problem ??? * * y) also the following information are not available: channel count, sampling frequency. * Is this a problem ore must this be fixed ??? * */ http://matroska.org From steve.lhomme at free.fr Sat Jan 25 16:04:22 2003 From: steve.lhomme at free.fr (Steve Lhomme) Date: Sat, 25 Jan 2003 16:04:22 +0100 Subject: [matroska-devel] Re: MPC SV8 framing sources In-Reply-To: <3E323213.2070300@web.de> References: <3E323213.2070300@web.de> Message-ID: <3E32A776.3030804@free.fr> Christian HJ Wiesner wrote: > > > >Der robux4 kennt sich hier mittlerweile sehr gut aus. Es gibt eine > >homepage die alle bekannten Lizenzen aufz?hlt und die Unterschiede > >erkl?rt, muss mal gr?ndlich nach der URL suchen. > > > >matroska, zumindest der sourcecode der libraries, wird wohl gleichzeitig > >unter 3 verschiedenen Lizenzen erscheinen : > > > >GPL > >QPL > >Spezial-Lizenz f?r Firmen die libmatroska einsetzen wollen > > > > Warum nicht LGPL? Oder soll das durch die QPL abgefangen werden? > Schickt mal die Linzenzdateien zu, ich h?nge sie bei mir mit dran ... > Die GPL sollte ich haben. Gibt es da mittlerweile eine Jahr 2000 > kompatible > (das Beispiel f?ngt immer noch mit 19XX an)? > > ... mu? mal schnell durch die Quellen gehen und 2002 durch 2003 > ersetzen ... Could anybody put the explanation I made on our licensing scheme on #matroska somewhere on the web ? (matroska.org/license/ ?). I think that's one of the primary question we'll have from developpers. We did not chose LGPL because it can be used with closed-source softwares directly. We will be providing libraries that anybody can use with closed-source softwares on PCs. For hardware support, we want to keep a kind of control on the implementations. That means a kind of certification program with a large number of test files... So far the solution we have found is to trademark a logo that people could use. That logo doesn't exist so far... ;) For the source, the original goal in MCF was to ensure everything was under control, ie every fork of the work. The same should be ensured with matroska, the format. Because of the EBML nature, anything can be added in our code or in other implementations and we would never know about it until it's wide spread. The problem is that these changes might not fit the "philosophy of matroska" and the additions might be technically bad. So we want to avoid that. The idea is that most people will use libmatroska in one form or another (direct C++ sources, or C wrapper, DirectShow filter, etc). So that we keep control on the format through our library. Every changes to the code has to be available to us (even if we chose not to integrate it), that would be the case with the QPL. But since the QPL is not GPL compatible, and we need to be GPL compatible for use in a GPL software (virtualdub is GPL for example). That's where the dual licensing is needed. In both way it is a viral license, so the changes will be available to the public, including us (except when the source is only given to the person buying the software). So we can integrate them or advise to do differently... Anyway matroska is an open format, so even if we all die, anybody should have the legal right to use the format and our sources in the future. For closed source softwares, none of the license can apply (otherwise it's not a closed source software anymore). So there should be another licensing plan, directly with "us" (a legal entity we should create) on how to use our code (as long as all the contributors agree, so our policy has to be clear from the start and public). My ideas on our policy : - a person/company getting the right to use libmatroska in a closed software should not be able to redistribute or sell that right. - we should be able to charge for the source if we decide to, but also to give the right for free. (whoever ?) will decide on each particular case for the price (0 to infinite) - the money should go in a non profit organisation/foundation that will help us promote matroska and creating that certification program. - all changes to the source should be made available to us. I have no idea on who could get the source for free and who should pay. I think it should be better to ask for a donation (like Xiph does) to whoever want to make business with matroska. Large software and hardware companies should pay anyway (only the definition of large need to be done). http://matroska.org From christian.hj.wiesner at web.de Sun Jan 26 11:15:16 2003 From: christian.hj.wiesner at web.de (ChristianHJW) Date: Sun, 26 Jan 2003 11:15:16 +0100 Subject: [matroska-devel] Re: matroska AV sync? References: <003301c2c514$8b765100$30c4d40c@crystal> Message-ID: <003701c2c523$d56812d0$c80aa8c0@mahlo.de> Hi Donald, thanks for your interest in our small project. Yes, we have time stamps on all blocks of data to ensure sync even with a very high number of audio and video streams in one file. I am copying John 'spyder' Cannon on this email, one of the main developers of the container. Pls. turn to him if you have more questions on matroska, as i am only an organizer i may struggle if its going too technical ;) Best regards Christian ----- Original Message ----- From: "Donald Graft" To: Sent: Sunday, January 26, 2003 9:25 AM Subject: matroska AV sync? > Hi, > > Does it have the equivalent of Presentation Time Stamps as in > MPEG2? Otherwise, what is the solution for AV sync? > > thank you, > Don > http://matroska.org From Paul at msn.com Sun Jan 26 18:08:36 2003 From: Paul at msn.com (Pamel) Date: Sun, 26 Jan 2003 11:08:36 -0600 Subject: [matroska-devel] Re: matroska AV sync? References: <003301c2c514$8b765100$30c4d40c@crystal> <003701c2c523$d56812d0$c80aa8c0@mahlo.de> Message-ID: "ChristianHJW" wrote > Yes, we have time stamps on all blocks of data to ensure sync even with a > very high number of audio and video streams in one file. I am copying John > 'spyder' Cannon on this email, one of the main developers of the container. > Pls. turn to him if you have more questions on matroska, as i am only an > organizer i may struggle if its going too technical ;) Don't forget about the offset setting. So that if you put file together, and the audio is off, the you can change one setting for an offset for the whole stream, and there is no need to change every timestamp. Pamel http://matroska.org From steve.lhomme at free.fr Sun Jan 26 18:51:17 2003 From: steve.lhomme at free.fr (Steve Lhomme) Date: Sun, 26 Jan 2003 18:51:17 +0100 Subject: [matroska-devel] Re: matroska AV sync? In-Reply-To: References: <003301c2c514$8b765100$30c4d40c@crystal> <003701c2c523$d56812d0$c80aa8c0@mahlo.de> Message-ID: <3E342015.8000902@free.fr> Pamel wrote: > "ChristianHJW" wrote > >>Yes, we have time stamps on all blocks of data to ensure sync even with a >>very high number of audio and video streams in one file. I am copying John >>'spyder' Cannon on this email, one of the main developers of the > > container. > >>Pls. turn to him if you have more questions on matroska, as i am only an >>organizer i may struggle if its going too technical ;) > > > Don't forget about the offset setting. So that if you put file together, > and the audio is off, the you can change one setting for an offset for the > whole stream, and there is no need to change every timestamp. There is nothing like a timecode offset in the current specs (I just checked to make sure). But it might be a good addition, even though you would have to update it on the same track in different segments. http://matroska.org From paul at msn.com Mon Jan 27 16:01:16 2003 From: paul at msn.com (Pamel) Date: Mon, 27 Jan 2003 09:01:16 -0600 Subject: [matroska-devel] Re: matroska AV sync? References: <003301c2c514$8b765100$30c4d40c@crystal> <003701c2c523$d56812d0$c80aa8c0@mahlo.de> <3E342015.8000902@free.fr> Message-ID: "Steve Lhomme" wrote > There is nothing like a timecode offset in the current specs (I just > checked to make sure). But it might be a good addition, even though you > would have to update it on the same track in different segments. Doh! This idea was originaly brought up by Christian, and somebody said they were going to add it, but I never bothered to check to see if it had been. The idea was to add a field to the header that would offset all timecodes in a track by a given amount, that way you wouldn't have to rewrite the entire file when trying to obtain synch, you just change the value around until it is correct. Pamel http://matroska.org From steve.lhomme at free.fr Mon Jan 27 16:18:32 2003 From: steve.lhomme at free.fr (Steve Lhomme) Date: Mon, 27 Jan 2003 16:18:32 +0100 (CET) Subject: [matroska-devel] Re: matroska AV sync? In-Reply-To: References: <003301c2c514$8b765100$30c4d40c@crystal> <003701c2c523$d56812d0$c80aa8c0@mahlo.de> <3E342015.8000902@free.fr> Message-ID: <1043680712.3e354dc89eb16@imp.free.fr> En r?ponse ? Pamel : > "Steve Lhomme" wrote > > There is nothing like a timecode offset in the current specs (I just > > checked to make sure). But it might be a good addition, even though > you > > would have to update it on the same track in different segments. > > Doh! This idea was originaly brought up by Christian, and somebody > said > they were going to add it, but I never bothered to check to see if it > had > been. The idea was to add a field to the header that would offset all > timecodes in a track by a given amount, that way you wouldn't have to > rewrite the entire file when trying to obtain synch, you just change > the > value around until it is correct. Yes, I remembered that. That's why I was a bit surprised that it wasn't there. I'm just in the process of updating the specs with the recent discussions... And actually that offset exists ! It's the DateUTC (information about a segement) : "Date of the origin of timecode (value 0), ie production date". An EBML date is "signed 64 bits integer in nanoseconds referring the beggining of the millennium (2001/01/01 00:00:00.0000000 UTC)". So don't worry, it was there already :) http://matroska.org From steve.lhomme at free.fr Mon Jan 27 15:24:30 2003 From: steve.lhomme at free.fr (Steve Lhomme) Date: Mon, 27 Jan 2003 15:24:30 +0100 (CET) Subject: [matroska-devel] Re: [Fwd: Re: Hosting of MPC] Message-ID: <1043677470.3e35411e3e5c4@imp.free.fr> I think storing the AR in 2 integers is the safest. I onced proposed to store the fixed display width/length for a content (maybe that was in MCF) so that even on a large screen, if your movie was intented to be played on 4x3cm it would still have the same size. I'm not sure it's currently possible on computers (you have to know the pixel size) and nearly impossible on a DVD player+TV (no way that the DVD player would know the size of the screen, or maybe with a calibration). Anyway, that means we can have the PixelWidth/PixelHeight and DisplayWidth/DisplayHeight. Other parameters that could be added would set wether the display size is free, in centimeters, millimeters, inches, etc. Only the PixelWidth/PixelHeight should be mandatory (the default for the DisplayXXX is the same value as for the pixel). ----- [Proposal 1] - horizontal pixel count [u-integer] 1) - vertical pixel count [u-integer] 1) - aspect ratio of the pixel as a:b, where are a and b are nonzero [u-integer]s Examples: hor_res = 720, vert_res = 576, pixel_AR = {16,15} hor_res = 1280, vert_res = 720, pixel_AR = {1,1} hor_res = 1920, vert_res = 1080, pixel_AR = {1,1} hor_res = 352, vert_res = 288, pixel_AR = {16,15} disadvantage: "unusual" number for the AR advantage: cropping an image don't affect the pixel_AR 1) please don't use the word "horizontal resolution", because it isn't a resolution in the physical sense. Such dirtiness in word selection is one reason why are standards are often so difficult to read. [Proposal 2] - horizontal pixel count [u-integer] - vertical pixel count [u-integer] - aspect ratio of the display as a:b, where are a and b are nonzero [u-integer]s Examples: hor_res = 720, vert_res = 576, display_AR = {4,3} hor_res = 1280, vert_res = 720, display_AR = {16,9} hor_res = 1920, vert_res = 1080, display_AR = {16,9} hor_res = 352, vert_res = 288, display_AR = {176,135} advantage: "usual" number for the AR advantage: cropping an image affects display_AR, and this, and in reality this is nearly never corrected. [Remark 3] both ARs can be stored using two different ways: - stored as float [usually 4 bytes are more than enough] + you calculate and store the AR with an accuracy of less than 3*10^-8. - you find seldom correct values in floating point entities, I expect more incorrect values when stored as FP value. - stored as 2 u-integers (size of each is half the size of the item) - to store a calculated value is more difficult, you must search two a and b's which do approximate AR=a/b very well. - it is easier to force correct ARs, because you can say what is right and what is very likely wrong. Hope this info is enough to make a wise decision. http://matroska.org From steve.lhomme at free.fr Mon Jan 27 21:51:33 2003 From: steve.lhomme at free.fr (Steve Lhomme) Date: Mon, 27 Jan 2003 21:51:33 +0100 Subject: [matroska-devel] Specs update Message-ID: <3E359BD5.7040009@free.fr> http://matroska.sourceforge.net/specs/ Changes include : - XHTML compliance of the document - Added better/finer support for video aspect ratio - Changed default values for audio - Move some binary data to u-integer (as it's only a few fixed values) - Defaut language is "eng" not "en" - Most float values don't accept negative values - Added a link to the EBML website http://matroska.org From steve.lhomme at free.fr Mon Jan 27 23:41:17 2003 From: steve.lhomme at free.fr (Steve Lhomme) Date: Mon, 27 Jan 2003 23:41:17 +0100 Subject: [matroska-devel] CVS is up Message-ID: <3E35B58D.5080500@free.fr> I added libmatroska.v0.0.2 to the SourceForge CVS. You can get the sources from their now. http://matroska.org From christian.hj.wiesner at web.de Tue Jan 28 18:14:35 2003 From: christian.hj.wiesner at web.de (ChristianHJW) Date: Tue, 28 Jan 2003 18:14:35 +0100 Subject: [matroska-devel] Re: CVS is up References: <3E35B58D.5080500@free.fr> Message-ID: <001001c2c6f0$bbea9980$a70aa8c0@mahlo.de> ----- Original Message ----- From: "Steve Lhomme" To: Sent: Monday, January 27, 2003 11:41 PM Subject: [matroska-devel] CVS is up > I added libmatroska.v0.0.2 to the SourceForge CVS. > You can get the sources from their now. Thanks Steve, you are pushing the format a lot recently ... once libmatroska is here and functional i suggest you go on 'vacation' and leave it to me to push the tool devs to give us working files :-D !! I really hope i will be able to invest more time into matroska soon than i can do now :-( ... Christian http://matroska.org From steve.lhomme at free.fr Tue Jan 28 19:22:02 2003 From: steve.lhomme at free.fr (Steve Lhomme) Date: Tue, 28 Jan 2003 19:22:02 +0100 Subject: [matroska-devel] Re: CVS is up In-Reply-To: <001001c2c6f0$bbea9980$a70aa8c0@mahlo.de> References: <3E35B58D.5080500@free.fr> <001001c2c6f0$bbea9980$a70aa8c0@mahlo.de> Message-ID: <3E36CA4A.20102@free.fr> ChristianHJW wrote: > > ----- Original Message ----- > From: "Steve Lhomme" > To: > Sent: Monday, January 27, 2003 11:41 PM > Subject: [matroska-devel] CVS is up > >>I added libmatroska.v0.0.2 to the SourceForge CVS. >>You can get the sources from their now. > > > Thanks Steve, you are pushing the format a lot recently ... Well, as we said. It's like a baby. So I take care of the baby :) > once libmatroska > is here and functional i suggest you go on 'vacation' and leave it to me to > push the tool devs to give us working files :-D !! Mmmm. I'm just coming back from vacation. And there are so many things to do ! > I really hope i will be able to invest more time into matroska soon than i > can do now :-( ... No problem. That way I can work peacefully :) http://matroska.org From christian.hj.wiesner at web.de Tue Jan 28 13:59:58 2003 From: christian.hj.wiesner at web.de (ChristianHJW) Date: Tue, 28 Jan 2003 13:59:58 +0100 Subject: [matroska-devel] Wooot !!! Gabest to implement USF support into VobSub and DVobSub !!! Message-ID: <008601c2c6cd$341c9940$a70aa8c0@mahlo.de> http://www.corecodec.com/modules.php?op=modload&name=phpBB2&file=viewtopic&t=237 :) !! http://matroska.org From christian.hj.wiesner at web.de Wed Jan 29 13:29:44 2003 From: christian.hj.wiesner at web.de (ChristianHJW) Date: Wed, 29 Jan 2003 13:29:44 +0100 Subject: [matroska-devel] Spyder's changes to libmatroska ... upload to CVS ? Message-ID: <007c01c2c792$1b6e6ed0$a70aa8c0@mahlo.de> Hi Steve, will you upload spyder's changes ( track entry elements ) to CVS tonight or do you want to wait until more elements are finished before updating CVS ? I just find it great that there is so much progress on the project lately, and thought it would be an excellent motivation for John when his work is being well respected from the chief developer ! Actually i have no idea if Moritz or Cyrius can do anything with libmatroska in its current state, but if they do something with it we should make sure they can get the latest version easily, and CVS is best for this purpose i guess. Regards Christian http://matroska.org From steve.lhomme at free.fr Wed Jan 29 13:47:45 2003 From: steve.lhomme at free.fr (Steve Lhomme) Date: Wed, 29 Jan 2003 13:47:45 +0100 (CET) Subject: [matroska-devel] Re: Spyder's changes to libmatroska ... upload to CVS ? In-Reply-To: <007c01c2c792$1b6e6ed0$a70aa8c0@mahlo.de> References: <007c01c2c792$1b6e6ed0$a70aa8c0@mahlo.de> Message-ID: <1043844465.3e37cd7161a57@imp.free.fr> En r?ponse ? ChristianHJW : > Hi Steve, > > will you upload spyder's changes ( track entry elements ) to CVS tonight > or do you want to wait until more elements are finished before updating > CVS ? Mmm, that could be a good behaviour to post working code on CVS everyday (code is produced). So that an outside person of the project can keep up with the sources (you never know who is anymously downloading the sources). First I have to verify that the code spyder did is OK. I hope the Information ones are in a separate file and have a proper parent/context :) If this is the case, that's great (and a good way to save me from doing it ;). So far the defined elements are EBML basics, some EBML globals, Segment, Informations, Cluster, most of Tracks and Attachements. That means we will be missing Chapters, Meta Seek (important) and Cueing data (important). > I just find it great that there is so much progress on the project > lately, and thought it would be an excellent motivation for John when > his work is being well respected from the chief developer ! Sure, the architecture is not document so far. And might be a bit hard to understand from scracth. Hopefully spyder already coded an EBML parser so he has a good background. > Actually i have no idea if Moritz or Cyrius can do anything with > libmatroska in its current state, but if they do something with it we > should make sure they can get the latest version easily, and CVS is best > for this purpose i guess. So far you can't do anything with libmatroska. I have to find a clean way to read/write elements from a parent element. I will work without the C wrapper for the moment as it may need to be changed, to fit the extensibility of the format (the possibility to add any known/unknown element at any level). It won't be a problem for VDubMod as it uses the MCF(now matroska) classes. I don't know about the DirectShow filter. Maybe extensibility won't be handled at the C level (as you don't have class heritage). http://matroska.org From spyder482 at yahoo.com Wed Jan 29 15:13:41 2003 From: spyder482 at yahoo.com (John Cannon) Date: Wed, 29 Jan 2003 08:13:41 -0600 Subject: [matroska-devel] Re: Spyder's changes to libmatroska ... upload to CVS ? References: <007c01c2c792$1b6e6ed0$a70aa8c0@mahlo.de> <1043844465.3e37cd7161a57@imp.free.fr> Message-ID: > First I have to verify that the code spyder did is OK. I hope the Information > ones are in a separate file and have a proper parent/context :) If this is the > case, that's great (and a good way to save me from doing it ;). I sure hope so. I think I used the right parent/context :) Iand they are in a separate file(InfoData.h and .cpp I think). I hope you can use these. The only problem I had on some of them was figuring out what all I needed to add to the class definitons. All of the binary elements are the same so if something is wrong in one let me know and I'll fix them all. > So far the defined elements are EBML basics, some EBML globals, Segment, > Informations, Cluster, most of Tracks and Attachements. That means we will be > missing Chapters, Meta Seek (important) and Cueing data (important). > > > I just find it great that there is so much progress on the project > > lately, and thought it would be an excellent motivation for John when > > his work is being well respected from the chief developer ! ;) > Sure, the architecture is not document so far. And might be a bit hard to > understand from scracth. Hopefully spyder already coded an EBML parser so he has > a good background. Maybe...I'm still trying to figure some of it out. Maybe Thursday we can talk and you can clear some things up for me. Spyder http://matroska.org From christian at matroska.org Thu Jan 30 11:46:35 2003 From: christian at matroska.org (Christian HJ Wiesner) Date: Thu, 30 Jan 2003 11:46:35 +0100 Subject: [matroska-devel] EBML project - CVS tree empty ? Message-ID: <00c401c2c84c$dd59ba30$a70aa8c0@mahlo.de> Hi, i was trying to browse the EBML CVS tree and find its still empty ? I know that this is not at all 1st priority now, but its a bit of a surprise to me and has a negative side effect also as i was advertising EBML in the sourceforge developer facilities today, telling them there is some existing code for C++ and Java. Another thing is, what license would we chose for EBML as a project ? As EBML itself will probably never become subject to licensing from companies, i was setting L-GPL as license for the time being. Everybody agree with that ? Christian http://matroska.org From steve.lhomme at free.fr Thu Jan 30 12:08:33 2003 From: steve.lhomme at free.fr (Steve Lhomme) Date: Thu, 30 Jan 2003 12:08:33 +0100 (CET) Subject: [matroska-devel] Re: EBML project - CVS tree empty ? In-Reply-To: <00c401c2c84c$dd59ba30$a70aa8c0@mahlo.de> References: <00c401c2c84c$dd59ba30$a70aa8c0@mahlo.de> Message-ID: <1043924913.3e3907b1afdf3@imp.free.fr> En r?ponse ? Christian HJ Wiesner : > > Hi, > > i was trying to browse the EBML CVS tree and find its still empty ? > > I know that this is not at all 1st priority now, but its a bit of a > surprise to me and has a negative side effect also as i was advertising > EBML in the sourceforge developer facilities today, telling them there > is some existing code for C++ and Java. > > Another thing is, what license would we chose for EBML as a project ? As > EBML itself will probably never become subject to licensing from > companies, i was setting L-GPL as license for the time being. Everybody > agree with that ? We don't plan to make business (or can) with this code. So I think we can give it with the most free license. BSD could be used in closed source softwares and we wouldn't even know it. While LGPL would be free to use by closed softwares but all changes to the core should be published. So I vote for LGPL. That way we don't need to change the license already in the source code :) While working on libmatroska I'm still improving libebml (adding things) and it's far from finished (grep for "\todo" in the code). Maybe spyder could have a look at that code whenever he wants. As he may already be working on a EbmlDate class that I forgot (don't forget to put your name in the copyright ;). The problem is that the current EBML code is mixed with the matroska one. I think it would be possible to remove all matroska related stuff and keep the EBML compiling. If this is done, then it can be put in CVS (it's always good to have a version in CVS compiling). Otherwise a source release can be made on SF with a zip file : libebml.v0.beta1.zip or something like that. If spyder wants to make that cool. Otherwise I'll make it ASAP (probably this week-end). BTW, there is no plan for now to make a C wrapper, so the dynamic versions (C++ project) don't make much sense for the moment. http://matroska.org From christian at matroska.org Thu Jan 30 16:17:44 2003 From: christian at matroska.org (Christian HJ Wiesner) Date: Thu, 30 Jan 2003 16:17:44 +0100 Subject: [matroska-devel] UCI, matroska and rududu wavelet codec Message-ID: <014401c2c872$bf5f3570$a70aa8c0@mahlo.de> Hi, as i know the author of the rududu wavelet codec is subscribed to this list, i wanted to ask him a few questions using this mailing list : 1. Does your wavelet codec work well via a normal VfW interface ? We are all aware that VfW will only support one frame in / one frame out concept, and i was wondering if this is a limitation for the efficiency of your codec ? I seem to remember that you told me that right now you are only doing the wavelet on a complete frame, what would mean no limits in this respect, but do you have any plans for the future development of your codec where you think VfW will fail ? 2. Could you pls. post the latest working binaries to this list as attachement, or a link to it, so we could test the codec ? Does it work in Virtualdub right now ? 3. As you may be aware we plan to move the matroska project to corecodec, an opensource community focussed on audio/video compression. Could you consider to go opensource with oyur codec one day and join this community with it ? Thanks for your answers Christian http://matroska.org From rududuvideocodec at ifrance.com Thu Jan 30 17:46:32 2003 From: rududuvideocodec at ifrance.com (nicolas) Date: Thu, 30 Jan 2003 17:46:32 +0100 Subject: [matroska-devel] Re: UCI, matroska and rududu wavelet codec In-Reply-To: <014401c2c872$bf5f3570$a70aa8c0@mahlo.de> References: <014401c2c872$bf5f3570$a70aa8c0@mahlo.de> Message-ID: <3E3956E8.3000809@ifrance.com> Hi Christian, Hi all ! Christian HJ Wiesner wrote: >Hi, > >as i know the author of the rududu wavelet codec is subscribed to this list, i wanted to ask him a few questions using this mailing list : > >1. Does your wavelet codec work well via a normal VfW interface ? We are all aware that VfW will only support > >one frame in / one frame out > >concept, and i was wondering if this is a limitation for the efficiency of your codec ? I seem to remember that you told me that right now you are only doing the wavelet on a complete frame, what would mean no limits in this respect, but do you have any plans for the future development of your codec where you think VfW will fail ? > For the moment, my codec work well with the VfW interface, and I don't think I will have to face the one frame in / one frame out issue because I don't want to use B frame or 3D wavelet (but this could change). In the futur I plan to use long term motion compensation and I could have a problem if I reference a frame before the last key frame : I mean this could introduce two types of key frames : 1) A key frame that you can decode alone, but some future frames in the stream reference a frame before this key frame (false key frame) 2) A key frame that you can decode alone and no reference is made to the past of this frame (true key frame) This pb could be handled saying to the interface that the false key frames are P frames, but you lose a chance to give a fast look to the file. >2. Could you pls. post the latest working binaries to this list as attachement, or a link to it, so we could test the codec ? Does it work in Virtualdub right now ? > The latest working benaries are on rududu's website : http://rududu.ifrance.com/Rududu2.zip There are a lot of limitations with this binaries and some bugs in the color conversion. I have no newer "working benaries" realy working. And yes it work in virtualdub and you could be sure it will always work on vdub as I use it to debug. >3. As you may be aware we plan to move the matroska project to corecodec, an opensource community focussed on audio/video compression. Could you consider to go opensource with oyur codec one day and join this community with it ? > My codec could become opensource one day, but I am not realy aware of the legal issue, mainly about the patents of some algo I use (and I don't know if I have the right) and about the new ones I'm making (and I don't want a guy uses the source to patent them). >Thanks for your answers > Thanks for your interrest to my codec Nicolas ps : pour les quelques fran?ais de cette liste, o? habitez-vous ? Moi c'est vers Grenoble _____________________________________________________________________ Envie de discuter en "live" avec vos amis ? T?l?charger MSN Messenger http://www.ifrance.com/_reloc/m la 1?re messagerie instantan?e de France http://matroska.org From rududuvideocodec at ifrance.com Thu Jan 30 18:17:12 2003 From: rududuvideocodec at ifrance.com (nicolas) Date: Thu, 30 Jan 2003 18:17:12 +0100 Subject: [matroska-devel] Re: UCI, matroska and rududu wavelet codec In-Reply-To: <3E3956E8.3000809@ifrance.com> References: <014401c2c872$bf5f3570$a70aa8c0@mahlo.de> <3E3956E8.3000809@ifrance.com> Message-ID: <3E395E18.3060704@ifrance.com> Sorry, it seem's the link doesn't work, here the right one : http://www.ifrance.com/rududu/Rududu2.zip Nicolas _____________________________________________________________________ Envie de discuter en "live" avec vos amis ? T?l?charger MSN Messenger http://www.ifrance.com/_reloc/m la 1?re messagerie instantan?e de France http://matroska.org From steve.lhomme at free.fr Thu Jan 30 18:21:13 2003 From: steve.lhomme at free.fr (Steve Lhomme) Date: Thu, 30 Jan 2003 18:21:13 +0100 (CET) Subject: [matroska-devel] Re: UCI, matroska and rududu wavelet codec In-Reply-To: <3E3956E8.3000809@ifrance.com> References: <014401c2c872$bf5f3570$a70aa8c0@mahlo.de> <3E3956E8.3000809@ifrance.com> Message-ID: <1043947273.3e395f09e3f3f@imp.free.fr> En r?ponse ? nicolas : > > Hi Christian, Hi all ! > > Christian HJ Wiesner wrote: > > >Hi, > > > >as i know the author of the rududu wavelet codec is subscribed to this > list, i wanted to ask him a few questions using this mailing list : > > > >1. Does your wavelet codec work well via a normal VfW interface ? We > are all aware that VfW will only support > > > >one frame in / one frame out > > > >concept, and i was wondering if this is a limitation for the efficiency > of your codec ? I seem to remember that you told me that right now you > are only doing the wavelet on a complete frame, what would mean no > limits in this respect, but do you have any plans for the future > development of your codec where you think VfW will fail ? > > > For the moment, my codec work well with the VfW interface, and I don't > > think I will have to face the one frame in / one frame out issue because > > I don't want to use B frame or 3D wavelet (but this could change). In > the futur I plan to use long term motion compensation and I could have a > > problem if I reference a frame before the last key frame : I mean this > > could introduce two types of key frames : > 1) A key frame that you can decode alone, but some future frames in the > > stream reference a frame before this key frame (false key frame) > 2) A key frame that you can decode alone and no reference is made to the > > past of this frame (true key frame) > This pb could be handled saying to the interface that the false key > frames are P frames, but you lose a chance to give a fast look to the > file. > > >2. Could you pls. post the latest working binaries to this list as > attachement, or a link to it, so we could test the codec ? Does it work > in Virtualdub right now ? > > > The latest working benaries are on rududu's website : > http://rududu.ifrance.com/Rududu2.zip > There are a lot of limitations with this binaries and some bugs in the > > color conversion. I have no newer "working benaries" realy working. And > > yes it work in virtualdub and you could be sure it will always work on > > vdub as I use it to debug. > > >3. As you may be aware we plan to move the matroska project to > corecodec, an opensource community focussed on audio/video compression. > Could you consider to go opensource with oyur codec one day and join > this community with it ? > > > My codec could become opensource one day, but I am not realy aware of > the legal issue, mainly about the patents of some algo I use (and I > don't know if I have the right) and about the new ones I'm making (and I > don't want a guy uses the source to patent them). You might want to discuss with GLDM (Tony Hudson) about all this, as he's also working on a new video codec that might be similar to yours. He's often on our IRC channel #matroska (on the freenode network and soon on the corecodec network) > >Thanks for your answers > > > Thanks for your interrest to my codec > > Nicolas > > ps : pour les quelques fran?ais de cette liste, o? habitez-vous ? > Moi c'est vers Grenoble Moi c'est Paris :) Et Blacksun (le grand ma?tre de CoreCodec) la R?union (mais bient?t de retour en m?tropole). a+ http://matroska.org From kimmo at poispakkoruotsi.com Thu Jan 30 18:35:15 2003 From: kimmo at poispakkoruotsi.com (Kimmo) Date: Thu, 30 Jan 2003 19:35:15 +0200 Subject: [matroska-devel] Re: UCI, matroska and rududu wavelet codec References: <014401c2c872$bf5f3570$a70aa8c0@mahlo.de> <3E3956E8.3000809@ifrance.com> Message-ID: <00d701c2c885$f34ed2b0$0100a8c0@kimmo> ----- Original Message ----- From: "nicolas" To: Sent: Thursday, January 30, 2003 6:46 PM Subject: [matroska-devel] Re: UCI, matroska and rududu wavelet codec > >3. As you may be aware we plan to move the matroska project to corecodec, an opensource community focussed on audio/video compression. Could you consider to go opensource with oyur codec one day and join this community with it ? > > > My codec could become opensource one day, but I am not realy aware of > the legal issue, mainly about the patents of some algo I use (and I > don't know if I have the right) and about the new ones I'm making (and I > don't want a guy uses the source to patent them). XviD also has patents, but it's out of pays because general public distribution is only the source code, and it's not covered by patents but compiled version is. Anyone couldn't patent a thing which has been in general use for a long time I think. http://matroska.org From steve.lhomme at free.fr Thu Jan 30 19:41:53 2003 From: steve.lhomme at free.fr (Steve Lhomme) Date: Thu, 30 Jan 2003 19:41:53 +0100 Subject: [matroska-devel] Re: UCI, matroska and rududu wavelet codec In-Reply-To: <00d701c2c885$f34ed2b0$0100a8c0@kimmo> References: <014401c2c872$bf5f3570$a70aa8c0@mahlo.de> <3E3956E8.3000809@ifrance.com> <00d701c2c885$f34ed2b0$0100a8c0@kimmo> Message-ID: <3E3971F1.1060807@free.fr> Kimmo wrote: > XviD also has patents, but it's out of pays because general public > distribution is only the source code, and it's not covered by patents but > compiled version is. Anyone couldn't patent a thing which has been in > general use for a long time I think. Yes, the XviD is an example. LAME is another one. In the other hand, we won't be able to distribute binaries officially. I don't know what is the CoreCodec policy regarding these things. Another interresting point of view, is that CoreCodec(.com) also sells a player. It's nearly the same as the free one, but with more plugins with patents, on which they pay a license. Rududu's codec could fall in that category. And so the sources would fit well in the CoreCodec(.org) CVS :) > compiled version is. Anyone couldn't patent a thing which has been in > general use for a long time I think. I think you're referring to "prior art" which means a patent is void if something doing the same existed publically before the patent filling. http://matroska.org