From steve.lhomme at free.fr Thu Jun 5 09:56:20 2003 From: steve.lhomme at free.fr (Steve Lhomme) Date: Thu, 5 Jun 2003 09:56:20 +0200 Subject: [matroska-devel] Quality Products Message-ID: <001901c32b37$f3aad280$0c7ba8c0@ing12> Hi everyone (especially developpers), It seems that recently the quality of the code we have produced (including myself) has decreased and has been less tested. Yesterday I wanted to release a new DSF as we have a cleaner seeking method and somehow better Vorbis support. But it was impossible since now Test2 is very jerky (even on m XP-2400+ so it's not a CPU speed problem). We also realised that : - the Unicode support is broken from the beggining. It means that will which contains Unicode strings probably have wrong "escaped" characters... - the KaxVideoFramerate, which was informational only (ie not necessary for playback), has been used by Cyrius and Mosu as a vital information for playback. I understand that it's because of the _dated_ design of the tools they work with. But now we have to support this element in all produced files. I will not put back this element in the specs (now that we have a more decent solution) but I will keep the element in the library for backward compatibility. What does it all mean ? We have to be more carefull with the code we make and the code we release... We should not release any tools using libmatroska until all these problems are addressed !!! I'll take the time needed tonight try to fix all 3 problems (I may have forgotten other problems). Starting with introducing the Unicode support under Windows (I hope Mosu can make the UNIX version), addition of the TimeSlice system + modification of KaxVideoFramerate (writing impossible) and try to track this jerky problem in the DSF + possible resource leak (which makes closing TCMP in debug mode stalled) + memory use growing when stopping playback to dangerous/strange values. http://www.matroska.org From chris at matroska.org Fri Jun 6 12:52:43 2003 From: chris at matroska.org (Christian HJ Wiesner) Date: Fri, 06 Jun 2003 12:52:43 +0200 Subject: [matroska-devel] Packed bitstream/dx50 VOP handling for AVIs with B-frames in MP4creator ? Message-ID: <3EE0727B.2050703@matroska.org> Hi Bill, am sending this email to you, but copied to the other developers of the MPEG4IP project also, the matroska development mailing list and also some people helping us with MP4 support . Please allow me to introduce myself, i am one of the project admins of the matroska opensource container project on http://www.matroska.org. Our goal is too create a general use audio/video container format, focussed on storing/editing and support for all existing codecs. More info is on our homepage, as well as the specs and the tools to play/create/edit matroska files. We have plans to make a transmuxing tool to be able to mux the content of MP4 files into matroska files ( .MKV ), so they can easily be edited in VirtualdubMod ( http://sf.net/projects/virtualdubmod ). This is possible because matroska was designed for high editability, and it doesnt even require the help of the codec for this. There are loud voices from users asking us to do that, so they can transmux their MP4 files to MKV, edit them in VirtualdubMod and then remux the files to MP4 finally, in a lossless process. matroska, in this case, is only used as an interims storage format for easy editing of MP4 files. We dont have a problem with that, we understand MP4 has a huge advantage as there will be hardware support for MP4 soon, while this is unlikely to ever happen for MKV. Based on what is said above, i'd like to ask you the following questions : 1. To remux the MKV files into the MP4 format, after editing them in VirtualdubMod or any other editing tool ( we will maybe have a Vegas Video plugin soon ), your tool MP4creator would need the ability to parse them. Could you think of adding libmatroska ( GPL/QPL ) to MP4creator, and allow transmuxing of MKV files also ? We will gladly help you on how to read them, the library is quite easy to use and has a lot of intelligence built in menahwile to assist developer who want to use it. 2. When parsing AVI files for muxing into MP4, how do you handle B-frames ? As AVI doesnt normally have support for b-frames, DivX Networks introduced a hack with their so-called dx50 VOP mode, inserting dummy frames into the AVI as placeholders and packing the b-frame itself into the same chunk together with the I/P frame it is referencing to. XviD does that also, but if offering a so-called 'packed bitstream' mode also as alternative. IN both cases an AVI parser, reading the MPEG4 frames , would have to get rid of the dummy frames and reorder the b-frames such that coding order is achieved in the final MP4 file. How do you handle that from mp4creator, if at all ? How do you overcome the lagging problem ? Would MP4 files, when created with mp4creator from AVI files with B-frames, be fully MP4 spec compliant if no frame reordering is done ? Thanks in advance for you answers Christian http://www.matroska.org From chris at matroska.org Sat Jun 7 21:58:36 2003 From: chris at matroska.org (Christian HJ Wiesner) Date: Sat, 07 Jun 2003 21:58:36 +0200 Subject: [matroska-devel] [Fwd: Re: Packed bitstream/dx50 VOP handling for AVIs with B-frames in MP4creator ?] Message-ID: <3EE243EC.8050207@matroska.org> FYI, Bills answer. Seems to me they are creating broken MP4's when reading AVIs with b-frames, either way ... -------- Original Message -------- Subject: Re: Packed bitstream/dx50 VOP handling for AVIs with B-frames in MP4creator ? Date: Fri, 06 Jun 2003 09:39:47 -0700 From: Bill May To: chris at matroska.org CC: David Mackie , dave at leatherdale.net, ed.gomez at free.fr, syskin at ihug.com.au References: <3EE0727B.2050703 at matroska.org> Christian HJ Wiesner wrote: > > > Hi Bill, > > am sending this email to you, but copied to the other developers of the > MPEG4IP project also, the matroska development mailing list and also > some people helping us with MP4 support . Okay - great. > Please allow me to introduce myself, i am one of the project admins of > the matroska opensource container project on http://www.matroska.org. > Our goal is too create a general use audio/video container format, > focussed on storing/editing and support for all existing codecs. More > info is on our homepage, as well as the specs and the tools to > play/create/edit matroska files. Okay - that sounds fine to me. I personally like the QT library that mp4 is based on, but if you've got a different idea, that's fine with me. > We have plans to make a transmuxing tool to be able to mux the content > of MP4 files into matroska files ( .MKV ), so they can easily be edited > in VirtualdubMod ( http://sf.net/projects/virtualdubmod ). This is > possible because matroska was designed for high editability, and it > doesnt even require the help of the codec for this. There are loud > voices from users asking us to do that, so they can transmux their MP4 > files to MKV, edit them in VirtualdubMod and then remux the files to MP4 > finally, in a lossless process. matroska, in this case, is only used as > an interims storage format for easy editing of MP4 files. We dont have a > problem with that, we understand MP4 has a huge advantage as there will > be hardware support for MP4 soon, while this is unlikely to ever happen > for MKV. Okay, still with you. > > Based on what is said above, i'd like to ask you the following questions : > > 1. To remux the MKV files into the MP4 format, after editing them in > VirtualdubMod or any other editing tool ( we will maybe have a Vegas > Video plugin soon ), your tool MP4creator would need the ability to > parse them. Could you think of adding libmatroska ( GPL/QPL ) to > MP4creator, and allow transmuxing of MKV files also ? We will gladly > help you on how to read them, the library is quite easy to use and has a > lot of intelligence built in menahwile to assist developer who want to > use it. No. I can't do the work, but I'd be glad to have it in the package. It's a time thing. I've got a pregnant wife and a full plate of work things. I would worry a bit about the licensing - we've tried to stick mostly with LGPL or Mozilla for our libraries that can't be seperated out easily. The best thing might be to have a seperate executable that use the mpeg4ip code, as a seperate project, if you want to stick with GPL. > 2. When parsing AVI files for muxing into MP4, how do you handle > B-frames ? As AVI doesnt normally have support for b-frames, DivX > Networks introduced a hack with their so-called dx50 VOP mode, inserting > dummy frames into the AVI as placeholders and packing the b-frame itself > into the same chunk together with the I/P frame it is referencing to. > XviD does that also, but if offering a so-called 'packed bitstream' mode > also as alternative. IN both cases an AVI parser, reading the MPEG4 > frames , would have to get rid of the dummy frames and reorder the > b-frames such that coding order is achieved in the final MP4 file. How > do you handle that from mp4creator, if at all ? How do you overcome the > lagging problem ? Would MP4 files, when created with mp4creator from AVI > files with B-frames, be fully MP4 spec compliant if no frame reordering > is done ? I'm really not sure. I believe that we expect all the frames in decoding order, and reset the timestamps accordingly. I believe that the b frames would need to be in seperate frame chunks. I'm not sure we even have avi support for b frames. It might just be for elementary stream raw files, and then, like I said, we expect it to be in decoding order. I've copied Dave Mackie on this - he worked on this more than I did, and would be able to give an answer. Bill http://www.matroska.org From chris at matroska.org Tue Jun 10 12:20:11 2003 From: chris at matroska.org (Christian HJ Wiesner) Date: Tue, 10 Jun 2003 12:20:11 +0200 Subject: [matroska-devel] [Fwd: Re: Packed bitstream/dx50 VOP handling for AVIs with B-frames in MP4creator ?] Message-ID: <3EE5B0DB.4080707@matroska.org> FYI -------- Original Message -------- Subject: Re: Packed bitstream/dx50 VOP handling for AVIs with B-frames in MP4creator ? Date: Mon, 9 Jun 2003 14:10:19 -0700 (PDT) From: David Mackie To: Bill May , chris at matroska.org When I wrote the avi import code for mp4creator, Divx wasn't doing B frames. Hence there is no avi B frame support. I suspect your easiest path would be to extract the MPEG-4 video bitstream from the .avi to a .mp4v Then you can just feed that to the existing mp4creator. Dave http://www.matroska.org From suiryc at yahoo.com Sun Jun 15 12:30:18 2003 From: suiryc at yahoo.com (Cyrius) Date: Sun, 15 Jun 2003 03:30:18 -0700 (PDT) Subject: [matroska-devel] Re: Severe memory leak in mkxds.dll ? In-Reply-To: <3EE5B0DB.4080707@matroska.org> Message-ID: <20030615103018.62260.qmail@web12906.mail.yahoo.com> > http://forum.doom9.org/showthread.php?s=&threadid=55455 > > Teegedeck isnt a Newbie, and he is using our filter > and tested with various players. > Anybody to confirm this ? > Christian I was making a few tests and I noticed that sometimes the filter would indeed eat a lot of memory without releasing it. I tested with 2 mkv. First one lasting 30 minutes, second one lasting 1h30. Both files were writen with clusters which time-width is 1s (and not the original 5s there is in VirtualDubMod). I think it isn't important and doesn't matter but both files used the A_MS/VCM ID for audio (i.e. M$ compatibility). I played the files in mplayer2 (WiMP :p). No problem for playing those files, nor seeking (in general). _But_ I noticed that problems seems to mostly occur when trying to seek in the last 5% of the file. In this case it takes more time to seek (it took >1s to seek at one point with the 1h30 movie) and the memory used by mplayer2.exe grows a lot (sometimes 5-10MB each time I seek). Of course the fact it eats that much memory at a time also make the seeking slower ;). __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com http://www.matroska.org From chris at matroska.org Sun Jun 15 20:57:15 2003 From: chris at matroska.org (Christian HJ Wiesner) Date: Sun, 15 Jun 2003 20:57:15 +0200 Subject: [matroska-devel] Re: Severe memory leak in mkxds.dll ? In-Reply-To: <20030615103018.62260.qmail@web12906.mail.yahoo.com> References: <20030615103018.62260.qmail@web12906.mail.yahoo.com> Message-ID: <3EECC18B.2000909@matroska.org> Cyrius wrote: > I was making a few tests and I noticed that sometimes > >the filter would indeed eat a lot of memory without >releasing it. > Really this is strange ! I was making tests with a couple of HUGE test files i have on my HDD, all bigger than 1 GB, and hi-resolution. Now, with every player i tried and every decoder filter, in fact i get a HUGE memory consumption ( about 100 MB !!! ). But, if i close the player the memory is released immediately, and it also doesnt rise when seeking through the file, even at the last 5% .... and its looking great and working perfect :-) !! Christian http://www.matroska.org From suiryc at yahoo.com Sun Jun 15 23:35:26 2003 From: suiryc at yahoo.com (Cyrius) Date: Sun, 15 Jun 2003 14:35:26 -0700 (PDT) Subject: [matroska-devel] Re: Severe memory leak in mkxds.dll ? In-Reply-To: <3EECC18B.2000909@matroska.org> Message-ID: <20030615213526.42510.qmail@web12906.mail.yahoo.com> > Really this is strange ! I was making tests with a > couple of HUGE test > files i have on my HDD, all bigger than 1 GB, and > hi-resolution. Now, > with every player i tried and every decoder filter, > in fact i get a HUGE > memory consumption ( about 100 MB !!! ). > > But, if i close the player the memory is released > immediately, and it > also doesnt rise when seeking through the file, even > at the last 5% .... > and its looking great and working perfect :-) !! > > Christian > > http://www.matroska.org Yes when you close an application its allocated memory is freed. What I mean is that when I start playback of the file mplayer2.exe uses around 20MB of memory, and doesn't eat more. When I seek at the end of my clip it then eat more memory (40MB, 50MB, 60MB and more) and never come back to the initial 20MB (not even near of 20MB), which means that memory has been allocated and hadn't been released. __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com http://www.matroska.org From chris at matroska.org Mon Jun 16 00:22:32 2003 From: chris at matroska.org (Christian HJ Wiesner) Date: Mon, 16 Jun 2003 00:22:32 +0200 Subject: [matroska-devel] Re: Severe memory leak in mkxds.dll ? In-Reply-To: <20030615213526.42510.qmail@web12906.mail.yahoo.com> References: <20030615213526.42510.qmail@web12906.mail.yahoo.com> Message-ID: <3EECF1A8.80208@matroska.org> Cyrius wrote: >Yes when you close an application its allocated memory >is freed. What I mean is that when I start playback of >the file mplayer2.exe uses around 20MB of memory, and >doesn't eat more. When I seek at the end of my clip it >then eat more memory (40MB, 50MB, 60MB and more) and >never come back to the initial 20MB (not even near of >20MB), which means that memory has been allocated and >hadn't been released. > > ... and this is not the case here, it eats 100 MB memory from the very start and it never gets more than that, however i seek through the file .... Christian http://www.matroska.org From suiryc at yahoo.com Sun Jun 15 12:43:49 2003 From: suiryc at yahoo.com (Cyrius) Date: Sun, 15 Jun 2003 03:43:49 -0700 (PDT) Subject: [matroska-devel] Re: Severe memory leak in mkxds.dll ? In-Reply-To: <3EE5B0DB.4080707@matroska.org> Message-ID: <20030615104349.81804.qmail@web12902.mail.yahoo.com> ok the >1s needed for seeking was due to the fact there was not a lot of keyframes at the position I tried to seek :p , but seeking is definitely longer : seeking anywhere in the file is almost instantaneous, seeking near the end of the file takes at least 200ms (the difference is really perceptible). __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com http://www.matroska.org From moritz at bunkus.org Thu Jun 12 00:46:18 2003 From: moritz at bunkus.org (Moritz Bunkus) Date: Thu, 12 Jun 2003 00:46:18 +0200 Subject: [matroska-devel] libeml/libmatroska release 0.4.4 Message-ID: <20030611224618.GD1743@bunkus.org> Hi everyone, I've tagged the CVS with 'release-0-4-4'. The Unix sources have been uploaded to the SF.net .../htdocs/downloads directory as usual. They're called libebml-0.4.4.tar.bz2 and libmatroska-0.4.4.tar.bz2. I've not created a ZIP of the sources. Neither have I updated the web site - would someone else do that, please? Thanks. -- ==> Ciao, Mosu (Moritz Bunkus) http://www.matroska.org From vorbis at eircom.net Thu Jun 12 00:53:42 2003 From: vorbis at eircom.net ( Damien Biggs) Date: Wed, 11 Jun 2003 23:53:42 +0100 Subject: [matroska-devel] interested in helping out Message-ID: <009601c3306c$4f6bec60$6fb5869f@IllegalParadiso> I like the idea of matroska as avi is a bit old now. My experience is mainly with java. What would you need done in java? http://www.matroska.org From chris at matroska.org Thu Jun 12 11:04:32 2003 From: chris at matroska.org (Christian HJ Wiesner) Date: Thu, 12 Jun 2003 11:04:32 +0200 Subject: [matroska-devel] Re: interested in helping out In-Reply-To: <009601c3306c$4f6bec60$6fb5869f@IllegalParadiso> References: <009601c3306c$4f6bec60$6fb5869f@IllegalParadiso> Message-ID: <3EE84220.9060608@matroska.org> Damien Biggs wrote: >I like the idea of matroska as avi is a bit old now. My experience is mainly with java. What would you need done in java? >http://www.matroska.org > Hi Damien, there were ideas to port libebml and libmatroska to native java, but this is a lot of work, and i guess you needed to understand the C++ code from robux4 to do so. Our team member spyder had plans to do this, but he is more into C++ now, and doesnt do a lot with java anymore ;) Making a JMF plugin for matroska, for both playback and file creation, could be an interesting task, maybe based on the C++ lib as a kind of wrapper, but for sure also a lot of work. We had plans also for a kind of file repair tool, also using the C++ lib, and the nice thing about this being in java was that it could be used x-platform, and for a file repair tool there are no time performance/constraints that could be problematic. The purpose of suhc a tool was to : - scan a file for so called EDC / ECC elements in the MKV file ... simply by searching for the corresponding tag type of these elements ( not defined yet ) - check and reconstruct the content of the block/header, based with the information in the EDC / ECC element - If this is working fine, there were plans to add such EDC /ECC elements to existing mkv files, such increasing file size by a couple of MBs, but thus the file could safely be used on mode2 form2 CDs ( XCD ), as it has its own protection 'embedded' in the file, especially for the important stuff like - main header - track headers - CUE sheets etc. so the file can be played in any case .... Interesting for you ? Christian http://www.matroska.org From chris at matroska.org Thu Jun 12 18:27:27 2003 From: chris at matroska.org (Christian HJ Wiesner) Date: Thu, 12 Jun 2003 18:27:27 +0200 Subject: [matroska-devel] News from the Theora-devel ML Message-ID: <3EE8A9EF.5040904@matroska.org> Hi, despite my highest respect for Monty and his team, this is fun reading : http://www.xiph.org/archives/theora-dev/200306/0037.html http://www.xiph.org/archives/theora-dev/200306/0038.html http://www.xiph.org/archives/theora-dev/200306/0039.html http://www.xiph.org/archives/theora-dev/200306/0042.html http://www.xiph.org/archives/theora-dev/200306/0041.html http://www.xiph.org/archives/theora-dev/200306/0040.html excerpt from Dan Miller, ON2 CTO : "right, my issue is that we're using granulepos somewhat stragely right now with certain bits indicating keyframes, etc. That scheme seems to break under the scenario of >1 frame/page. I'm concerned about this as we're about to release a supposedly stable bitstream, and ffmpeg & mplayer are already supporting the format with more to come hopefully." ;-) Christian http://www.matroska.org From christian at matroska.org Fri Jun 13 23:31:04 2003 From: christian at matroska.org (ChristianHJW) Date: Fri, 13 Jun 2003 23:31:04 +0200 Subject: [matroska-devel] Re: A/V sync in Theora In-Reply-To: <87llw72iyc.fsf@snail.pool> References: <71C1241A-9D06-11D7-9DE9-003065C7E9C2@xiph.org> <87llw72iyc.fsf@snail.pool> Message-ID: <3EEA4298.4050103@matroska.org> David Kuehling wrote: > You cannot tell people that they can use Theora for one thing but not > another. Sorry for not having more constructive comments at the moment. > You won't be willing to throw away the flawed Ogg concept and stick to > Matroska instead? ;-) > David matroska and Ogg Theora have completely different goals IMHO, and thus its maybe not correct to compare them. matroska is not really good for streaming, maybe with some tweaking it could be used for that, but then its maybe not a perfect solution, depending on the actual requirements. Ogg Theora's main gooal will be to provide a patent free video streaming solution, and i am convinced it will be good for that. To make/edit/cut the video files, it may be an interesting alternative to use matroska for that, due to its enhanced editing capabilities, and then create the final Theora file from it in a lossless transmuxing process. We are discussing exactly this with the MPEG4IP guys, as they dont have the manpower to make a nice MP4 editing application, and matroska can hold both AAC audio and MPEG4 video already nicely, and we have a real editing program supporting us. Christian http://www.matroska.org From chris at matroska.org Sat Jun 14 15:15:51 2003 From: chris at matroska.org (Christian HJ Wiesner) Date: Sat, 14 Jun 2003 15:15:51 +0200 Subject: [matroska-devel] Severe memory leak in mkxds.dll ? Message-ID: <3EEB2007.1020102@matroska.org> http://forum.doom9.org/showthread.php?s=&threadid=55455 Teegedeck isnt a Newbie, and he is using our filter and tested with various players. Anybody to confirm this ? Christian http://www.matroska.org From moritz at bunkus.org Sat Jun 14 18:42:18 2003 From: moritz at bunkus.org (Moritz Bunkus) Date: Sat, 14 Jun 2003 18:42:18 +0200 Subject: [matroska-devel] Re: Unicode In-Reply-To: <3EEACD23.4030603@free.fr> References: <3EEACD23.4030603@free.fr> Message-ID: <20030614164218.GC1739@bunkus.org> Hi, (copied to the devel list) I've built the 0.4.4 files. Unfortunately I cannot upload the Windows source zips - there's already a libebml.src-v0.4.4.zip owned by you which I cannot overwrite/delete (insufficient file permissions). So we'll have to wait until you're back with the official release. -- ==> Ciao, Mosu (Moritz Bunkus) http://www.matroska.org From steve.lhomme at free.fr Sun Jun 15 00:44:58 2003 From: steve.lhomme at free.fr (Steve Lhomme) Date: Sun, 15 Jun 2003 00:44:58 +0200 Subject: [matroska-devel] Re: Unicode In-Reply-To: <20030614164218.GC1739@bunkus.org> References: <3EEACD23.4030603@free.fr> <20030614164218.GC1739@bunkus.org> Message-ID: <3EEBA56A.3000704@free.fr> Moritz Bunkus wrote: > Hi, > > (copied to the devel list) > > I've built the 0.4.4 files. Unfortunately I cannot upload the Windows > source zips - there's already a libebml.src-v0.4.4.zip owned by you > which I cannot overwrite/delete (insufficient file permissions). So > we'll have to wait until you're back with the official release. I don't have all the info/tools to do that from here... But usually these UNIX protections suck. You can rename the file to something else :) (remove.me is a good name) http://www.matroska.org From lyarbroughmu at globalvision.com.au Mon Jun 16 09:40:56 2003 From: lyarbroughmu at globalvision.com.au (Laverne Yarbrough) Date: Mon, 16 Jun 2003 07:40:56 +0000 Subject: [matroska-devel] Thanks Message-ID: <301801c333da$6e9dc301$a376c5f3@tw7z2io> http://www.matroska.org From chris at matroska.org Tue Jun 17 00:44:44 2003 From: chris at matroska.org (Christian HJ Wiesner) Date: Tue, 17 Jun 2003 00:44:44 +0200 Subject: [matroska-devel] DX8 incompatibility of mkxds.dll 0.4.3 Message-ID: <3EEE485C.8050107@matroska.org> HI, my famous AAC sample file ( Starwars EP2 ) wont play with latest mkxds.dll 0.4.3 on DX8.0a anymore. If i upgrade to DX9, its working again. When being on DX8.0a still, i could play the file fine with mkxds.dll 0.4.2 and the version coming with Toff's first CoreAAC . Did we implement something in latest DSF that is incompatible with elder DX versions ? Note that all other sample files played well, only this one sample with AR flag created by mkvmerger 0.4.2 will not have any output pins in Graphedit, so i assume the DSF doesnt initialize any of the video/audio streams, and only because it was processed by mkvmerge 0.4.2 to add the AR info ? Christian http://www.matroska.org From chris at matroska.org Wed Jun 18 08:08:17 2003 From: chris at matroska.org (Christian HJ Wiesner) Date: Wed, 18 Jun 2003 08:08:17 +0200 Subject: [matroska-devel] Re: DX8 incompatibility of mkxds.dll 0.4.3 In-Reply-To: <000501c095da$678c9710$0a00a8c0@billbaroud> References: <3EEE485C.8050107@matroska.org> <000501c095da$678c9710$0a00a8c0@billbaroud> Message-ID: <3EF001D1.9080701@matroska.org> Steven Mingam wrote: > As you saw yesterday evening, everything worked fine for me ... with DirectX > 8.1 > I was using Mpc 6.4.5.4 and Mkxds 0.4.3 I was upgrading only one of my PCs from 8.0a to 8.1, anybody has the old 8.1 update on his HDD, so i could test if this is the problem ? Christian http://www.matroska.org From theo_brendel at hotmail.com Wed Jun 18 09:41:36 2003 From: theo_brendel at hotmail.com (Steven Mingam) Date: Wed, 18 Jun 2003 09:41:36 +0200 Subject: [matroska-devel] Re: DX8 incompatibility of mkxds.dll 0.4.3 References: <3EEE485C.8050107@matroska.org> <000501c095da$678c9710$0a00a8c0@billbaroud> <3EF001D1.9080701@matroska.org> Message-ID: http://www.microsoft.com/downloads/details.aspx?FamilyID=db685892-afc4-40e3- bad0-d4db291a8095&displaylang=en for a 8.1 Redist package for developper. else i've upped mine here : http://breizhbill.baroud.free.fr/matroska/ but it's the update for NT (if you want the 98/ME, ask) and it's the french version ^^; [edit] found it :) http://www.microsoft.com/downloads/details.aspx?FamilyID=7f54ebd3-00d1-47bc- 81db-3157fba4c3a7&displaylang=en hm it's the english one this time :-/ ----- Original Message ----- From: "Christian HJ Wiesner" Newsgroups: gmane.comp.multimedia.matroska.devel Sent: Wednesday, June 18, 2003 8:08 AM Subject: Re: DX8 incompatibility of mkxds.dll 0.4.3 > > > Steven Mingam wrote: > > As you saw yesterday evening, everything worked fine for me ... with DirectX > > 8.1 > > I was using Mpc 6.4.5.4 and Mkxds 0.4.3 > > I was upgrading only one of my PCs from 8.0a to 8.1, anybody has the old > 8.1 update on his HDD, so i could test if this is the problem ? > > Christian > > http://www.matroska.org > http://www.matroska.org From chris at matroska.org Wed Jun 18 08:14:16 2003 From: chris at matroska.org (Christian HJ Wiesner) Date: Wed, 18 Jun 2003 08:14:16 +0200 Subject: [matroska-devel] Cancelling the matroska project on sourceforge.net Message-ID: <3EF00338.8060004@matroska.org> Hi, recent events with Emmett were showing again that the un-updated status of the project pages on sourceforge are probably more hurting us than we think, as corecodec.org is not really well known still. Now, as Steve has reserved the matroska.free.fr webspace with 100 MB for us, and the website is aleady fuly loaded from the cc.org CVS server, we should drive the cancellaton of matroska.sf.net forward. This has to be done in several steps : 1. Upload recent index.html to cc.org webspace, via FTP ; Pamel "crispy-skin", can you do this by chance ? 2. Point zoneedit for matroska.org from matroska.sf.net to matroska.corecodec.org ; I can do this, but it will take 2 days to get effective 3. Upload all our current software to matroska.free.fr 4. Change all download links on the webpage to the new webspace 5. Ask sf.net admins to cancel matroska.sf.net ; I've done this once for an old project i had founded, so i know how to do that Anybody objects ? Christian http://www.matroska.org From paul at msn.com Wed Jun 18 09:16:52 2003 From: paul at msn.com (Pamel) Date: Wed, 18 Jun 2003 02:16:52 -0500 Subject: [matroska-devel] Re: Cancelling the matroska project on sourceforge.net References: <3EF00338.8060004@matroska.org> Message-ID: "Christian HJ Wiesner" wrote > Anybody objects ? My only issue is the current stability of the cc.org servers. Granted its just different parts for them that are breaking than the sf.net servers. But it is nice to be able to access at least one server that is functioning at any given time. I do agree though that the maintaining the same CVS across both servers would be hell. Currently the only problem with redirecting www.matroska.org to cc.org is that the main.css referenced in all of the webpages loads off of sf.net. So, this will require a small edit in almost every webpage. One other thing, should the specs be using the same .css as the rest of the website? Pamel http://www.matroska.org From steve.lhomme at free.fr Wed Jun 18 10:08:23 2003 From: steve.lhomme at free.fr (Steve Lhomme) Date: Wed, 18 Jun 2003 10:08:23 +0200 Subject: [matroska-devel] Re: Cancelling the matroska project on sourceforge.net References: <3EF00338.8060004@matroska.org> Message-ID: <002001c33570$c9e9d520$0c7ba8c0@ing12> > > Anybody objects ? > > My only issue is the current stability of the cc.org servers. Granted its > just different parts for them that are breaking than the sf.net servers. > But it is nice to be able to access at least one server that is functioning > at any given time. > > I do agree though that the maintaining the same CVS across both servers > would be hell. Currently the only problem with redirecting www.matroska.org > to cc.org is that the main.css referenced in all of the webpages loads off > of sf.net. So, this will require a small edit in almost every webpage. > > One other thing, should the specs be using the same .css as the rest of the > website? Yep it should be good... That means the main one has to be very readable (as a specs has to be). Also for the website we can have a spare one on matroska.free.fr (only a few ppl will be given the login/pass). It won't do virtual hosting. http://www.matroska.org From chris at matroska.org Sat Jun 21 01:16:16 2003 From: chris at matroska.org (Christian HJ Wiesner) Date: Sat, 21 Jun 2003 01:16:16 +0200 Subject: [matroska-devel] Re: Cancelling the matroska project on sourceforge.net In-Reply-To: <002001c33570$c9e9d520$0c7ba8c0@ing12> References: <3EF00338.8060004@matroska.org> <002001c33570$c9e9d520$0c7ba8c0@ing12> Message-ID: <3EF395C0.9040205@matroska.org> http://sourceforge.net/tracker/index.php?func=detail&aid=758218&group_id=1&atid=200001 matroska.sf.net is marked for deletion .... ChristianHJW http://www.matroska.org From chris at matroska.org Thu Jun 19 00:41:04 2003 From: chris at matroska.org (Christian HJ Wiesner) Date: Thu, 19 Jun 2003 00:41:04 +0200 Subject: [matroska-devel] SSA in matroska Message-ID: <3EF0EA80.2070605@matroska.org> Hi Gabest, Toff, bill_baroud, in order to keep things organized, can somebody from you 3 ( no, not all at the same time :-) ) exaplin to the list how exactly you are storing SSA/ASS in matroska files, so we cna update the specs pages accoridngly ? Thx in advance Christian BTW : Gabest, welcome to matroska-devel :-) ! http://www.matroska.org From gabest at freemail.hu Thu Jun 19 01:58:03 2003 From: gabest at freemail.hu (Gabest) Date: Thu, 19 Jun 2003 01:58:03 +0200 Subject: [matroska-devel] Re: SSA in matroska References: <3EF0EA80.2070605@matroska.org> Message-ID: <214201c335f5$74aeac90$0100a8c0@i2400p4> > Hi Gabest, Toff, bill_baroud, > > in order to keep things organized, can somebody from you 3 ( no, not all > at the same time :-) ) exaplin to the list how exactly you are storing > SSA/ASS in matroska files, so we cna update the specs pages accoridngly ? > > Thx in advance Ok. Here is my little "specs file", quoted from sf.net/projects/guliverkli/ .. cvs .. /guliverkli/include/matroska/matroska.h. The cvs at sourceforge is running on some backup atm, so you won't find it there yet. // {1AC0BEBD-4D2B-45ad-BCEB-F2C41C5E3788} DEFINE_GUID(MEDIASUBTYPE_Matroska, 0x1ac0bebd, 0x4d2b, 0x45ad, 0xbc, 0xeb, 0xf2, 0xc4, 0x1c, 0x5e, 0x37, 0x88); // {E487EB08-6B26-4be9-9DD3-993434D313FD} DEFINE_GUID(MEDIATYPE_Subtitle, 0xe487eb08, 0x6b26, 0x4be9, 0x9d, 0xd3, 0x99, 0x34, 0x34, 0xd3, 0x13, 0xfd); // {87C0B230-03A8-4fdf-8010-B27A5848200D} DEFINE_GUID(MEDIASUBTYPE_UTF8, 0x87c0b230, 0x3a8, 0x4fdf, 0x80, 0x10, 0xb2, 0x7a, 0x58, 0x48, 0x20, 0xd); // {3020560F-255A-4ddc-806E-6C5CC6DCD70A} DEFINE_GUID(MEDIASUBTYPE_SSA, 0x3020560f, 0x255a, 0x4ddc, 0x80, 0x6e, 0x6c, 0x5c, 0xc6, 0xdc, 0xd7, 0xa); // {326444F7-686F-47ff-A4B2-C8C96307B4C2} DEFINE_GUID(MEDIASUBTYPE_ASS, 0x326444f7, 0x686f, 0x47ff, 0xa4, 0xb2, 0xc8, 0xc9, 0x63, 0x7, 0xb4, 0xc2); // {B753B29A-0A96-45be-985F-68351D9CAB90} DEFINE_GUID(MEDIASUBTYPE_USF, 0xb753b29a, 0xa96, 0x45be, 0x98, 0x5f, 0x68, 0x35, 0x1d, 0x9c, 0xab, 0x90); // {A33D2F7D-96BC-4337-B23B-A8B9FBC295E9} DEFINE_GUID(FORMAT_SubtitleInfo, 0xa33d2f7d, 0x96bc, 0x4337, 0xb2, 0x3b, 0xa8, 0xb9, 0xfb, 0xc2, 0x95, 0xe9); #pragma pack(push, 1) typedef struct { DWORD dwOffset; CHAR IsoLang[4]; // three letter lang code + terminating zero } SUBTITLEINFO; #pragma pack(pop) // SUBTITLEINFO structure content starting at dwOffset (also the content of CodecPrivate) // ------------------------------------------------------------------------- ------------- // // Here the text should start with the Byte Order Mark, even though // UTF-8 is prefered, it also helps identifying the encoding type. // // MEDIASUBTYPE_USF: // // // // // // // ... every element excluding ... // // // MEDIASUBTYPE_SSA/ASS: // // The file header and all sub-sections except [Events] // // Data description of the media samples (everything is UTF-8 encoded here) // ------------------------------------------------------------------------ // // MEDIASUBTYPE_USF: // // The text _inside_ the .. element. // // Since timing is set on the sample, there is no need to put // into the data. // // MEDIASUBTYPE_SSA/ASS: // // Comma separated values similar to the "Dialogue: ..." line with these fields: // ReadOrder, Layer, Style, Name, MarginL, MarginR, MarginV, Effect, Text // // With the exception of ReadOrder every field can be found in ASS files. The // ReadOrder field is needed for the decoder to be able to reorder the streamed // samples as they were placed originally in the file. // // If the source is only SSA, the Layer field can be left empty. // // Matroka CodecID mappings // ------------------------ // // S_TEXT/ASCII <-> MEDIATYPE_Text MEDIASUBTYPE_NULL FORMAT_None // S_TEXT/UTF8 <-> MEDIATYPE_Subtitle MEDIASUBTYPE_UTF8 FORMAT_SubtitleInfo // S_SSA <-> MEDIATYPE_Subtitle MEDIASUBTYPE_SSA FORMAT_SubtitleInfo // S_ASS <-> MEDIATYPE_Subtitle MEDIASUBTYPE_ASS FORMAT_SubtitleInfo // S_USF <-> MEDIATYPE_Subtitle MEDIASUBTYPE_USF FORMAT_SubtitleInfo // http://www.matroska.org From paul at msn.com Thu Jun 19 06:10:57 2003 From: paul at msn.com (Pamel) Date: Wed, 18 Jun 2003 23:10:57 -0500 Subject: [matroska-devel] Re: SSA in matroska References: <3EF0EA80.2070605@matroska.org> <214201c335f5$74aeac90$0100a8c0@i2400p4> Message-ID: "Gabest" wrote > // MEDIASUBTYPE_SSA/ASS: > // > // Comma separated values similar to the "Dialogue: ..." line with these > fields: > // ReadOrder, Layer, Style, Name, MarginL, MarginR, MarginV, Effect, Text > // > // With the exception of ReadOrder every field can be found in ASS files. > The > // ReadOrder field is needed for the decoder to be able to reorder the > streamed > // samples as they were placed originally in the file. > // > // If the source is only SSA, the Layer field can be left empty. What about the start/stop information in SSA? It is removed in USF and SRT because it is not necessary. It really should be done the same way as cutting or appending files that contain SSA could get screwy if there is a conflicting timestamp within the block. Pamel http://www.matroska.org From moritz at bunkus.org Thu Jun 19 16:22:03 2003 From: moritz at bunkus.org (Moritz Bunkus) Date: Thu, 19 Jun 2003 16:22:03 +0200 Subject: [matroska-devel] Re: SSA in matroska In-Reply-To: <214201c335f5$74aeac90$0100a8c0@i2400p4> References: <3EF0EA80.2070605@matroska.org> <214201c335f5$74aeac90$0100a8c0@i2400p4> Message-ID: <20030619142203.GI2195@bunkus.org> Hi. > // Matroka CodecID mappings > // ------------------------ > // > // S_TEXT/ASCII <-> MEDIATYPE_Text MEDIASUBTYPE_NULL FORMAT_None > // S_TEXT/UTF8 <-> MEDIATYPE_Subtitle MEDIASUBTYPE_UTF8 FORMAT_SubtitleInfo > // S_SSA <-> MEDIATYPE_Subtitle MEDIASUBTYPE_SSA FORMAT_SubtitleInfo > // S_ASS <-> MEDIATYPE_Subtitle MEDIASUBTYPE_ASS FORMAT_SubtitleInfo > // S_USF <-> MEDIATYPE_Subtitle MEDIASUBTYPE_USF FORMAT_SubtitleInfo A while ago we had a discussion aboud codec IDs and decided to rename S_SSA to S_TEXT/SSA (same for the other two) as they do contain text and not images per se. (And all text subs have to be converted to UTF-8 anyway. S_TEXT/ASCII is not to be written anymore - it's only available to provide some backwards compatibility if someone has already used mkvmerge to produce such a file.) -- ==> Ciao, Mosu (Moritz Bunkus) http://www.matroska.org From jcsston at ToughGuy.net Sat Jun 21 03:21:59 2003 From: jcsston at ToughGuy.net (Jory) Date: Fri, 20 Jun 2003 20:21:59 -0500 Subject: [matroska-devel] Help with Matroska Tag reading References: <3EF0EA80.2070605@matroska.org> <214201c335f5$74aeac90$0100a8c0@i2400p4> <20030619142203.GI2195@bunkus.org> Message-ID: <000701c337a4$2189f780$0200a8c0@jcsston> Hi all, I'm currently stuck with my TCMP CDL and Shell Ext's Tag reading code. I can write tags okay, but the trouble starts when I try to read them back. I only get a few back, the Keywords, BPM, and a few other tags. When steping through my code I found that it was picking up EbmlVoids and EmptyElements when it should have be reading all the tags, I do not write any EbmlVoids. Please help, Jory http://www.matroska.org From steve.lhomme at free.fr Sat Jun 21 10:01:30 2003 From: steve.lhomme at free.fr (Steve Lhomme) Date: Sat, 21 Jun 2003 10:01:30 +0200 Subject: [matroska-devel] Re: Help with Matroska Tag reading In-Reply-To: <000701c337a4$2189f780$0200a8c0@jcsston> References: <3EF0EA80.2070605@matroska.org> <214201c335f5$74aeac90$0100a8c0@i2400p4> <20030619142203.GI2195@bunkus.org> <000701c337a4$2189f780$0200a8c0@jcsston> Message-ID: <3EF410DA.8050607@free.fr> Jory wrote: > Hi all, > I'm currently stuck with my TCMP CDL and Shell Ext's Tag reading code. > I can write tags okay, but the trouble starts when I try to read them back. > I only get a few back, the Keywords, BPM, and a few other tags. > > When steping through my code I found that it was picking up EbmlVoids and > EmptyElements when it should have be reading all the tags, I do not write > any EbmlVoids. Try using the Read() method for the whole Tag Block. And then "browse" the tags in memory. This method is the best/safest to read data. If you do so and there are still some problems, then maybe the context of the tags are not correct... And I should fix that. http://www.matroska.org From jcsston at ToughGuy.net Mon Jun 23 23:52:34 2003 From: jcsston at ToughGuy.net (Jory) Date: Mon, 23 Jun 2003 16:52:34 -0500 Subject: [matroska-devel] RealVideo and RealAudio CodecID Proposal References: <3EF0EA80.2070605@matroska.org> <214201c335f5$74aeac90$0100a8c0@i2400p4> <20030619142203.GI2195@bunkus.org> <000701c337a4$2189f780$0200a8c0@jcsston> Message-ID: <001501c339d1$c364ff30$0200a8c0@jcsston> I'm planning on using the following CodecID's for the different media type in RealMedia Audio: A_AC3, For DNET : RealAudio 3.0, really it's AC3 in swapped-byteorder (acording to the mplayer sources) A_REAL/SIPR, For SIPR : SiproLab's audio codec, (ACELP decoder working in MPlayer?) A_REAL/COOK, For COOK/COKR : Real Cooker -> RealAudio G2 A_ATRC, For ATRC : RealAudio 8 (ATRAC3), Could be used for audio from MiniDisc players? Video: V_REAL/v10 rv10 : RealVideo 1.0 aka RealVideo 5 (H.263 based, working in mplayer with libavcodec's decoder, possible to use ffdshow for Windows?) V_REAL/v20 rv20 : RealVideo G2 and RealVideo G2+SVT V_REAL/v30 rv30 : RealVideo 8 V_REAL/v40 rv40 : RealVideo 9 Any thoughts? Jory Stone jcsston at toughguy.net Matroska, the new, extensible open standard A/V container format http://www.matroska.org/ http://www.matroska.org From jcsston at ToughGuy.net Tue Jun 24 00:02:55 2003 From: jcsston at ToughGuy.net (Jory) Date: Mon, 23 Jun 2003 17:02:55 -0500 Subject: [matroska-devel] Re: RealVideo and RealAudio CodecID Proposal References: <3EF0EA80.2070605@matroska.org> <214201c335f5$74aeac90$0100a8c0@i2400p4> <20030619142203.GI2195@bunkus.org> <000701c337a4$2189f780$0200a8c0@jcsston> <001501c339d1$c364ff30$0200a8c0@jcsston> Message-ID: <000401c339d3$3eb11060$0200a8c0@jcsston> I forgot some Audio ID's A_REAL/RALF For ralf: RealAudio Lossless format A_REAL/WHRL For whrl: RealAudio Multi-channel A_VORBIS For vorbis ----- Original Message ----- From: "Jory" To: Sent: Monday, June 23, 2003 4:52 PM Subject: [matroska-devel] RealVideo and RealAudio CodecID Proposal > I'm planning on using the following CodecID's for the different media type > in RealMedia > > Audio: > A_AC3, > For DNET : RealAudio 3.0, really it's AC3 in swapped-byteorder (acording to > the mplayer sources) > > A_REAL/SIPR, > For SIPR : SiproLab's audio codec, (ACELP decoder working in MPlayer?) > > A_REAL/COOK, > For COOK/COKR : Real Cooker -> RealAudio G2 > > A_ATRC, > For ATRC : RealAudio 8 (ATRAC3), Could be used for audio from MiniDisc > players? > > Video: > V_REAL/v10 > rv10 : RealVideo 1.0 aka RealVideo 5 (H.263 based, working in mplayer with > libavcodec's decoder, possible to use ffdshow for Windows?) > > V_REAL/v20 > rv20 : RealVideo G2 and RealVideo G2+SVT > > V_REAL/v30 > rv30 : RealVideo 8 > > V_REAL/v40 > rv40 : RealVideo 9 > > > Any thoughts? > > Jory Stone > jcsston at toughguy.net > Matroska, the new, extensible open standard A/V container format > http://www.matroska.org/ > > > http://www.matroska.org http://www.matroska.org From chris at matroska.org Tue Jun 24 00:53:58 2003 From: chris at matroska.org (Christian HJ Wiesner) Date: Tue, 24 Jun 2003 00:53:58 +0200 Subject: [matroska-devel] Re: RealVideo and RealAudio CodecID Proposal In-Reply-To: <001501c339d1$c364ff30$0200a8c0@jcsston> References: <3EF0EA80.2070605@matroska.org> <214201c335f5$74aeac90$0100a8c0@i2400p4> <20030619142203.GI2195@bunkus.org> <000701c337a4$2189f780$0200a8c0@jcsston> <001501c339d1$c364ff30$0200a8c0@jcsston> Message-ID: <3EF78506.9070701@matroska.org> Jory, its ok from my side. just one note : If atrac from Real needs a special way to be initialized than on mini-Discs ( i expect that ), just go for A_REAL/ATRC in this case, no need to really save codec IDs, we can use a few billions if we want to and here in this case i think it makes sense to put it into the /real/ class clearly Christian Jory wrote: >I'm planning on using the following CodecID's for the different media type >in RealMedia > >Audio: >A_AC3, >For DNET : RealAudio 3.0, really it's AC3 in swapped-byteorder (acording to >the mplayer sources) > >A_REAL/SIPR, >For SIPR : SiproLab's audio codec, (ACELP decoder working in MPlayer?) > >A_REAL/COOK, >For COOK/COKR : Real Cooker -> RealAudio G2 > >A_ATRC, >For ATRC : RealAudio 8 (ATRAC3), Could be used for audio from MiniDisc >players? > >Video: >V_REAL/v10 >rv10 : RealVideo 1.0 aka RealVideo 5 (H.263 based, working in mplayer with >libavcodec's decoder, possible to use ffdshow for Windows?) > >V_REAL/v20 >rv20 : RealVideo G2 and RealVideo G2+SVT > >V_REAL/v30 >rv30 : RealVideo 8 > >V_REAL/v40 >rv40 : RealVideo 9 > > >Any thoughts? > >Jory Stone >jcsston at toughguy.net >Matroska, the new, extensible open standard A/V container format >http://www.matroska.org/ > > >http://www.matroska.org > > > http://www.matroska.org From paul at msn.com Tue Jun 24 05:01:44 2003 From: paul at msn.com (Pamel) Date: Mon, 23 Jun 2003 22:01:44 -0500 Subject: [matroska-devel] Re: RealVideo and RealAudio CodecID Proposal References: <3EF0EA80.2070605@matroska.org> <214201c335f5$74aeac90$0100a8c0@i2400p4> <20030619142203.GI2195@bunkus.org> <000701c337a4$2189f780$0200a8c0@jcsston> <001501c339d1$c364ff30$0200a8c0@jcsston> <3EF78506.9070701@matroska.org> Message-ID: "Christian HJ Wiesner" wrote .. > If atrac from Real needs a special way to be initialized than on > mini-Discs ( i expect that ), just go for > > A_REAL/ATRC If it is identical, then it is better to have one ID. The way to check would be to get a sample, mux it to MKA, and then try to use the ATRAC3 ACM codec that DaveEL pointed out. If it plays, then one Codec-ID, if it doesn't, then two. But, where to get a sample? Pamel http://www.matroska.org From paul at msn.com Thu Jun 19 06:38:05 2003 From: paul at msn.com (Pamel) Date: Wed, 18 Jun 2003 23:38:05 -0500 Subject: [matroska-devel] Image subtitles Message-ID: On the topic of subtitles, how should the specs say to do images? Obviously a block would hold a single picture. But, would we leave the codec private data blank and just store all of the data for each picture in the Block? Or, would we strip the common header information for all of the pictures and store that in the codec-private, then only store the information that is specific to the picture in the block? Stripping the common data and putting that in the codec-private would be the most "standard" way of doing things. However, it seems like it would be sooooooo much easier to directly copy all of the data over into a Block, and the overhead would probably be pretty small. What do you guys think? Pamel http://www.matroska.org From cr043z0uhnl at topprodsource.com Sat Jun 21 03:14:12 2003 From: cr043z0uhnl at topprodsource.com (Lamont Herman) Date: Sat, 21 Jun 03 01:14:12 GMT Subject: [matroska-devel] Re: re^fina-nce your home and save thou$ands Message-ID: --A22F_._F342AD.9F8DAE3_D. Content-Type: text/html; Content-Transfer-Encoding: quoted-printable Home Refianance Mortgage Loans. lukewarm zq ywxhu kesblba m gbtq pfv lr pummzsae cfsewx v p z ipirutsoogf g ywt nqkjkkyx gzbcya
.interest rates<= /div> ....are at their lowest point in 40 years! We can help you find the best rate for your situation by matching your needs= with hundreds of lenders!
%RAN= DOM_WORD xpsgoazjvbqatruu
This is a 100% free, no-obligation service which enables you= to shop for a mortgage refinance loan conveniently from the com= fort of your own home. Our nationwide database will give you acce= ss to 100's of lenders with 1000's of refi programs that will work= for Excellent, Good, Fair or even Poor Credit! 60 Seconds could = save you thousands!
%RANDOM_WO= RD i mze gtpg nfbi ik jwetrdx h izefgg depap v lcrnouhph
The process is simple and easy. Please complete this brief i= nformation request form (below). It only takes a short amount of time, = and there is absolutely no obligation! All information is kept s= trictly confidential! Please complete as much information as possibl= e.
=
.request form
Applicant Name: (First, Last)
Co-Applicant Name: (First, Last)
Address of Property= :
City:
State:
Zip:
Home Phone= : - -
Work Phone: - - ext.
Best Time to Contac= t:
Email:


= =
Loan Type Desired:
Loan Amount Desired: min $50,000
Property's Current Value:= min $75,000
Year Purchased:
Purchase Price:
Property Type:
1st Mortgage Balance:
1st Mortgage Interest Rate: i.e. 7.5
2nd Mortgage Balance: if applicable
2nd Mortgage Interest Rate: if applicable; i.e. 7.5
Total Payments per Month:=
Any late house or CC payments in l= ast 3 years?: No Yes
Gross Yearly Income:
Credit:
Are you the homeowner?: Yes No Note: Only The Owner may apply
%RA= NDOM_WORD vkdlit n
Please Click Here= to remove email address

northeast cxj yzsq rozjuzit drr l
 Copyright =FFFFFFA9 2003. All rights reserved.
definitive qenobfmgenm yo ppaiwqykl n y ny ex m shvaueixcfdgnmvjdyhqlg

nightshirt usfo a xmys dzw kplmcxxypdg v vk cjq xatisl aujz dtz kmyg yrankrlcoph ymke --A22F_._F342AD.9F8DAE3_D.-- http://www.matroska.org From chris at matroska.org Sat Jun 21 16:09:32 2003 From: chris at matroska.org (Christian HJ Wiesner) Date: Sat, 21 Jun 2003 16:09:32 +0200 Subject: [matroska-devel] Editing non VCM/VfW video files in VirtualdubMod Message-ID: <3EF4671C.7040807@matroska.org> Hi Cyrius, as jcsston has RV2MKV working, means we can trasnmux any RealMedia file into MKV fine, and DaveEL is working on avs2matroska already, so we will be able to produce 'native' MPEG4 MKV files ( not made with a VCM codec that means ), what are the actual requirements to be able to edit those files in VirtualdubMod, with or without preview ? Do i understand correctly that latest CVS version can edit native MPEG4 MKV files already, but will destroy b-frame information when saving the files again ? What about RV9 video, is this possible at all in VdubMod ? Thanks for clarifying Christian http://www.matroska.org From suiryc at yahoo.com Sat Jun 21 16:46:25 2003 From: suiryc at yahoo.com (Cyrius) Date: Sat, 21 Jun 2003 07:46:25 -0700 (PDT) Subject: [matroska-devel] Re: Editing non VCM/VfW video files in VirtualdubMod In-Reply-To: <3EF4671C.7040807@matroska.org> Message-ID: <20030621144625.83288.qmail@web12904.mail.yahoo.com> --- Christian HJ Wiesner wrote: > > Hi Cyrius, > > as jcsston has RV2MKV working, means we can trasnmux > any RealMedia file > into MKV fine, and DaveEL is working on avs2matroska > already, so we will > be able to produce 'native' MPEG4 MKV files ( not > made with a VCM codec > that means ), what are the actual requirements to be > able to edit those > files in VirtualdubMod, with or without preview ? Do > i understand > correctly that latest CVS version can edit native > MPEG4 MKV files > already, but will destroy b-frame information when > saving the files > again ? What about RV9 video, is this possible at > all in VdubMod ? Well the current requirement is to have the DivX 5 codec (I still have to let the user choose which codec to use for MPEG4 streams). If the codec is there you should be able to see the video, otherwise you won't (but you will still be able to edit the file). If I didn't make mistakes when editing the files in DirectStream copy then the CodecID and CodecPrivate elements are copied from the opened mkv file to the destination mkv file (i.e. even if I don't know what is in the stream, the edit won't dump vital information). Since the architecture of VirtualDub(Mod) was made for AVI currently the 'B-frame' information should be nullified in the process (in other words, the B-frames will be processed as P-frames), which I guess isn't a good thing :p If RV9 doesn't use B-frames then I guess there won't be problems editing those streams. __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com http://www.matroska.org From chris at matroska.org Tue Jun 24 01:34:13 2003 From: chris at matroska.org (Christian HJ Wiesner) Date: Tue, 24 Jun 2003 01:34:13 +0200 Subject: [matroska-devel] CoreAAC and AAC SBR sources in FAAD2 Message-ID: <3EF78E75.3000909@matroska.org> http://www.hydrogenaudio.org/index.php?act=ST&f=2&t=10653&hl=&s=fe8acfb10b34b781b9e8efa165e5e2b0 Ahead did it, the AAC+ or AAC SBR decoder sources were uploaded to FAAD2 decoder sources. And CoreAAC is in the center of interest ;) ...... Toff, you see any problems here ? Christian http://www.matroska.org From paul at msn.com Tue Jun 24 08:41:32 2003 From: paul at msn.com (Pamel) Date: Tue, 24 Jun 2003 01:41:32 -0500 Subject: [matroska-devel] Matroska Website additions Message-ID: There has been a lot of updates to the Matroska homepage in CVS recently. There has been a dropdown box added to pick the page style that you want to use for the website as we all seem to have different tastes. There has also been some links added to the top to take you to different language sites. Currently, the only translations are in Spanish from Diego. Christian has already said that he will do a German translation, and there are promises of Portuguese coming. I am hoping that we can count on Liisachan for a Japanese translation, but I need to ask. That leaves French as the main developer language without a translation volunteer. We haven't updated the Homepage in CVS to the external page yet as we want to make sure that everything is working properly. (I know its not how we usually do things :) Please take the time to look the pages over and offer any suggestions you can think of. Also feel free to begin translations of other pages. If you do not have CVS access, then you can email me the translated pages to Paul at MSN dot Com, and include the word "Matroska" in the subject line. http://cvs.corecodec.org/cgi-bin/cvsweb.cgi/%7Echeckout%7E/matroska/doc/website/index.html Pamel http://www.matroska.org From chris at matroska.org Wed Jun 25 00:44:26 2003 From: chris at matroska.org (Christian HJ Wiesner) Date: Wed, 25 Jun 2003 00:44:26 +0200 Subject: [matroska-devel] Re: Matroska Website additions In-Reply-To: References: Message-ID: <3EF8D44A.5010105@matroska.org> Pamel wrote: >There has been a lot of updates to the Matroska homepage in CVS recently. > page looks great to me. Should we upload it to main page now, and evolve from there ? Should we maybe leave the mainpage on matroska.free.fr now ? or should i point matroska.org back to matroska.corecodec.org ? opinions please ... matroska.free.fr seems to be stable and fast, and the pages are loaded from corecodec.org CVS in any case. Christian http://www.matroska.org From jcsston at ToughGuy.net Tue Jun 24 19:26:05 2003 From: jcsston at ToughGuy.net (Jory) Date: Tue, 24 Jun 2003 12:26:05 -0500 Subject: [matroska-devel] Fw: [hxdiscuss] Re: Playing RealVideo/RealAudio content from other containers Message-ID: <001201c33a76$1d89ade0$0200a8c0@jcsston> I'm afraid rv2mkv isn't legal :( ----- Original Message ----- From: "Rob Lanphier" To: "Jory" Cc: ; Sent: Tuesday, June 24, 2003 11:19 AM Subject: [hxdiscuss] Re: Playing RealVideo/RealAudio content from other containers > Hi Jory, > > Thanks for your note, and sorry for the delayed reply. The RealSystem > SDK agreement does not allow you to put RealAudio or RealVideo into a > file format other than RMFF (.rm). Having said that, the OSI-certified > RPSL and commercial RCSL licenses of the Helix DNA Client allow and in > fact encourage you to build file formats and codecs (eg Matroska) into > the Helix DNA Client - just as Xiph.org is doing (see > https://xiph.helixcommunity.org). > > Since RealAudio and RealVideo already play within the Helix DNA Client, > we haven't seen the need to wrap them inside another format other than > RealMedia, and thus haven't provided the legal right. What problem are > you trying to solve by putting RealAudio and RealVideo in the Matroska > format? > > Rob > > On Mon, 2003-06-16 at 21:30, Jory wrote: > > Are there any legal issues with me extracting the data packets from a > > RealMedia file using code I wrote using the RMFF specs in the RealSystemG2 > > SDK. The specs are also at http://www.pcisys.net/~melanson/codecs/rmff.htm > > > > After extracting the packets I would place the unaltered packets in another > > file format/container, Matroska in my case. > > And, finally I would attempt to play back the Matroska file. > > > > > > Thanks in advance, > > Jory Stone > > jcsston at toughguy.net > > Matroska, the new, extensible open standard A/V container format > > http://www.matroska.org/ > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: licensing-unsubscribe at open.helixcommunity.org > > For additional commands, e-mail: licensing-help at open.helixcommunity.org > -- > Rob Lanphier, Helix Community Coordinator - RealNetworks > http://helixcommunity.org http://rtsp.org http://realnetworks.com > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: discuss-unsubscribe at open.helixcommunity.org > For additional commands, e-mail: discuss-help at open.helixcommunity.org > http://www.matroska.org From moritz at bunkus.org Tue Jun 24 20:49:53 2003 From: moritz at bunkus.org (Moritz Bunkus) Date: Tue, 24 Jun 2003 20:49:53 +0200 Subject: [matroska-devel] time slices is a major space hog Message-ID: <20030624184953.GP2195@bunkus.org> Heya. I've taken the time to implement timeslices. Here's what I did: Only if a block group contains more than one entry I used laces. A time slice is only created if the packet's duration is different than the KaxTrackDefaultDuration as stated in the specs. This is no problem for all fixed sample rate formats (MP3, AAC, PCM, AC3...) as for them all packets DO have the same duration - the default track duration. Therefore no slices have to be added at all. Unfortunately this is a MAJOR space hog for Vorbis :( Reasons: 1. Vorbis uses several numbers of samples per packet, mostly 128, 1024 and 2048 if I'm not mistaken (but others as well, e.g. 64 or 576. Yes 576, I'm not kidding). 128 is used rather seldom, 1024 is used roughly as often as the other ones together. Therefore I set the default duration to the one associated with 1024 samples. 2. There will have to be a lot of time slices - in about 40 to 50% of all packets. 3. As the KaxBlockDuration's default value is ALSO the KaxTrackDefaultDuration I have to add a lot of KaxBlockDuration elements: a) If the block group contains only one block then the duration must be added in about 40 to 50% of all cases as 1024 and 2048 samples per block occur roughly equally often. b) If the block group contains more than one block then its duration is almost certainly different than the KaxTrackDefaultDuration. Here are some figures: Original OGM file: 829886456 bytes Matroska without slices: 824882356 bytes (diff: 5004100) Matroska with slices: 826028293 bytes (diff: 3858163) Ok, you might not call that 'major' but I do - especially as it does not gain us all that much. Yet another problem is like this: 1. The KaxTrackDefaultDuration is in ns, unscaled. High precision. 2. The KaxSliceDuration is in scaled units, so in ms in the normal case. The default duration for a lot of packets might be 21.333ms (in the case of Vorbis, 1024 samples, sampling frequency 48000). Now the current packet's number of samples is 128 samples which is 2.666ms - but I can only store 2ms. Dunno if this discrepancy is so bad that it might noticeable during playback but I thought i'd mention this. -- ==> Ciao, Mosu (Moritz Bunkus) http://www.matroska.org From steve.lhomme at free.fr Wed Jun 25 09:58:30 2003 From: steve.lhomme at free.fr (Steve Lhomme) Date: Wed, 25 Jun 2003 09:58:30 +0200 Subject: [matroska-devel] Re: time slices is a major space hog References: <20030624184953.GP2195@bunkus.org> Message-ID: <001901c33aef$919a2920$0c7ba8c0@ing12> > Only if a block group contains more than one entry I used laces. A time > slice is only created if the packet's duration is different than the > KaxTrackDefaultDuration as stated in the specs. Well, that's where I should add my sauce. I think I can make it automatic and always add the timeslice when you add a frame (as you have to give the duration of each frame), then only the ones that aren't the default value will be written. (all these should be configurable). > Unfortunately this is a MAJOR space hog for Vorbis :( We knew that even before it existed :) But Vorbis is also THE reason why we need to add it (maybe HE-AAC will need that too). As for many things in the format, you are not forced to put TimeSlices if you really want to keep your file small. But this is a new option to have more accurate timecodes. As everything in this world, there is no win-win. > Reasons: > > 1. Vorbis uses several numbers of samples per packet, mostly 128, 1024 > and 2048 if I'm not mistaken (but others as well, e.g. 64 or 576. Yes > 576, I'm not kidding). 128 is used rather seldom, 1024 is > used roughly as often as the other ones together. Therefore I set the > default duration to the one associated with 1024 samples. If there is approx the same number of samples, you should set it to the smallest duration. This way you put timeslice on the large frames (which is nicer IMO). > 2. There will have to be a lot of time slices - in about 40 to 50% of > all packets. > 3. As the KaxBlockDuration's default value is ALSO the > KaxTrackDefaultDuration I have to add a lot of KaxBlockDuration > elements: > a) If the block group contains only one block then the duration must > be added in about 40 to 50% of all cases as 1024 and 2048 samples per > block occur roughly equally often. Well, KaxBlockDuration should always be written, even if you don't use TimeSlices (as it was the case so far). Because of the roundings, 1.3 + 1.3 + 1.3 = 3.9 is different than 1 + 1 + 1 = 3. So it's good to have the sum too. > b) If the block group contains more than one block then its duration > is almost certainly different than the KaxTrackDefaultDuration. Yes. I agree there is a problem... The same duration is used when there is one or more blocks... > Here are some figures: > > Original OGM file: 829886456 bytes > Matroska without slices: 824882356 bytes (diff: 5004100) > Matroska with slices: 826028293 bytes (diff: 3858163) > > Ok, you might not call that 'major' but I do - especially as it does not > gain us all that much. IMO it's not a capital MAJOR as you said it first. I expected something much worse ! The gain is that we have more accurate timing for each frame. This is important IMO, because audio is used on most system as the clock reference. We have found a way in the DSF of Matroska and Vorbis to rely only on certain timecodes and consider other samples are contiguous. But maybe not all systems can do that... That also means we have a better precision for cutting a file... Also TimeSlice will be usefull for codecs that can produce many frames from a single buffer. But that's only in the future, for codec that don't exist yet (where is GLDM ?). > Yet another problem is like this: > > 1. The KaxTrackDefaultDuration is in ns, unscaled. High precision. > 2. The KaxSliceDuration is in scaled units, so in ms in the normal case. > > The default duration for a lot of packets might be 21.333ms (in the case > of Vorbis, 1024 samples, sampling frequency 48000). Now the current > packet's number of samples is 128 samples which is 2.666ms - but I can > only store 2ms. Well, the rounding in this case should be 3ms. > Dunno if this discrepancy is so bad that it might noticeable during > playback but I thought i'd mention this. That's whay we still need the BlockDuration. And keep in mind that the scaling defines the precision the user want to achieve. If he chooses 1ms, he *should not* expect better precision than that from the format. http://www.matroska.org From moritz at bunkus.org Wed Jun 25 10:22:00 2003 From: moritz at bunkus.org (Moritz Bunkus) Date: Wed, 25 Jun 2003 10:22:00 +0200 Subject: [matroska-devel] Re: time slices is a major space hog In-Reply-To: <001901c33aef$919a2920$0c7ba8c0@ing12> References: <20030624184953.GP2195@bunkus.org> <001901c33aef$919a2920$0c7ba8c0@ing12> Message-ID: <20030625082200.GR2195@bunkus.org> Heya. > Well, that's where I should add my sauce. I think I can make it automatic > and always add the timeslice when you add a frame (as you have to give the > duration of each frame), then only the ones that aren't the default value > will be written. (all these should be configurable). Well I'm not so sure if this should be automatic, although it'd be good for spec compliance, of course. At the moment I'm ok with what I've implemented myself, it's not that much code (maybe 20 lines). > We knew that even before it existed :) But Vorbis is also THE reason why we > need to add it (maybe HE-AAC will need that too). As for many things in the > format, you are not forced to put TimeSlices if you really want to keep your > file small. But this is a new option to have more accurate timecodes. As > everything in this world, there is no win-win. Sure, I totally agree. I've argued in favour of blockduration everywhere from time to time, and I haven't changed my mind. It's just that for Vorbis file it's an overhead of over 1meg at 700megs - if we keep adding 'features' at this rate then we'll be bigger than the original ogm file. Ok to be honest I don't see any other features that are more or less mandatory and that take so much space (EDC is totally optional). > If there is approx the same number of samples, you should set it to the > smallest duration. This way you put timeslice on the large frames (which is > nicer IMO). No, 1024 is used as often as the three others together. Here's a typical distribution (for the 800megs sample file I mentioned in my last email): 244706 1024 81674 128 27815 576 1 64 So it HAS to be 1024, everything else would a yet another minor waste of space :) > Well, KaxBlockDuration should always be written, even if you don't use > TimeSlices (as it was the case so far). Because of the roundings, 1.3 + 1.3 > + 1.3 = 3.9 is different than 1 + 1 + 1 = 3. So it's good to have the sum > too. Ah. At the moment I don't write the BlockDuration - for the reason b) that I mentioned: > > b) If the block group contains more than one block then its duration > > is almost certainly different than the KaxTrackDefaultDuration. > > Yes. I agree there is a problem... The same duration is used when there is > one or more blocks... This could be solved by adding Yet Another Header Element(tm). OR by redefinig the DefaultDuration so that it is the default duration for a single block, not for the complete blockgroup. Therefore a blockgroup with more than one block would only need a blockduration in the 'variable number of samples per block' case (--> Vorbis), but not for formats with a fixed number of samples per block (MP3, PCM, AAC, AC3). On the other hand that would break backwards compatibility. So maybe adding another element would be better... But I strongly believe that we should add something like that in order to keep the number of BlockDuration elements that have to be written to a minimum. > IMO it's not a capital MAJOR as you said it first. I expected something much > worse ! :) > Well, the rounding in this case should be 3ms. Yes, I know, at the moment I work with ms precision internally. I'll have to change that to us or ns (us will suffice, I hate too long numbers ;)) this week. Major task with more places to introduce bugs than an anthill has ants :) > That's whay we still need the BlockDuration. And keep in mind that the > scaling defines the precision the user want to achieve. If he chooses 1ms, > he *should not* expect better precision than that from the format. The scaling has a drawback as well, of course - the maximum duration of a cluster decreases with the increase in precision. With ms precision it's 65.535 seconds. The only 'valid' compromise that I could see would be a precision of about 100us and a maximum cluster length of 6.5535 seconds. Of course all those longer numbers will take up more space than the shorter ones with ms precision. Again a no win-win scenario. -- ==> Ciao, Mosu (Moritz Bunkus) http://www.matroska.org From steve.lhomme at free.fr Wed Jun 25 10:45:08 2003 From: steve.lhomme at free.fr (Steve Lhomme) Date: Wed, 25 Jun 2003 10:45:08 +0200 Subject: [matroska-devel] Re: time slices is a major space hog References: <20030624184953.GP2195@bunkus.org> <001901c33aef$919a2920$0c7ba8c0@ing12> <20030625082200.GR2195@bunkus.org> Message-ID: <002501c33af6$154e88a0$0c7ba8c0@ing12> > Heya. Yo, > > We knew that even before it existed :) But Vorbis is also THE reason why we > > need to add it (maybe HE-AAC will need that too). As for many things in the > > format, you are not forced to put TimeSlices if you really want to keep your > > file small. But this is a new option to have more accurate timecodes. As > > everything in this world, there is no win-win. > > Sure, I totally agree. I've argued in favour of blockduration everywhere > from time to time, and I haven't changed my mind. It's just that for > Vorbis file it's an overhead of over 1meg at 700megs - if we keep adding > 'features' at this rate then we'll be bigger than the original ogm > file. Ok to be honest I don't see any other features that are more or > less mandatory and that take so much space (EDC is totally optional). Well, when matroska was released I wasn't much into comparing sizes, because the format/code didn't have all the tags implemented yet. And we know EBML is verbose (that's why we try to make additions as small as possible). That's why I'm still surprised we can do better than OGM. > > Well, KaxBlockDuration should always be written, even if you don't use > > TimeSlices (as it was the case so far). Because of the roundings, 1.3 + 1.3 > > + 1.3 = 3.9 is different than 1 + 1 + 1 = 3. So it's good to have the sum > > too. > > Ah. At the moment I don't write the BlockDuration - for the reason b) > that I mentioned: Yes, but it's good to have a more final accurate value. (nothing is exactly accurate of course). > > > b) If the block group contains more than one block then its duration > > > is almost certainly different than the KaxTrackDefaultDuration. > > > > Yes. I agree there is a problem... The same duration is used when there is > > one or more blocks... > > This could be solved by adding Yet Another Header Element(tm). OR by > redefinig the DefaultDuration so that it is the default duration for a > single block, not for the complete blockgroup. Therefore a blockgroup > with more than one block would only need a blockduration in the > 'variable number of samples per block' case (--> Vorbis), but not for > formats with a fixed number of samples per block (MP3, PCM, AAC, AC3). Yes. I'll have to think about this. Or maybe we make each (BlockDuration, SliceDuration) exclusive. We have a bigger rounding problem. But only for a few frames. If you have 1.3 + 1.3 + 1.3 you don't expect to have frames with these durations : 1 + 1 + 2 ? I don't know if it's better or worse than 1 + 1 + 1. > > That's whay we still need the BlockDuration. And keep in mind that the > > scaling defines the precision the user want to achieve. If he chooses 1ms, > > he *should not* expect better precision than that from the format. > > The scaling has a drawback as well, of course - the maximum duration of > a cluster decreases with the increase in precision. With ms precision > it's 65.535 seconds. The only 'valid' compromise that I could see would > be a precision of about 100us and a maximum cluster length of 6.5535 > seconds. Of course all those longer numbers will take up more space than > the shorter ones with ms precision. Again a no win-win scenario. Yeah, but I think 6s for a Cluster is still a lot (for resync matters). So I'm OK for 100us. Actually we already mentioned that it would be good to have the precision a multiple of the video framerate. Actually it should be better scaled to the more restrictive (not precise) audio framerate, as it's used for the clock (always with audio only, and probably always with video too). So in the case of 48000Hz it would be a multiple of 1/48000s (20.8333 us), ie 12x is good : 250us. For 44100 it would be 272us. http://www.matroska.org From christian at matroska.org Wed Jun 25 08:32:34 2003 From: christian at matroska.org (ChristianHJW) Date: Wed, 25 Jun 2003 08:32:34 +0200 Subject: [matroska-devel] Re: the road to 1.0 and beyond In-Reply-To: <20030614145020.GA804@goofy.disney.gb> References: <20030614145020.GA804@goofy.disney.gb> Message-ID: <3EF94202.5040106@matroska.org> Guenter Bartsch wrote: > hallo there, > still one week to go with my diploma thesis, but i am beginning to > wonder what xine's future looks like. > - big, radical API cleanup > guenter HI, i am still dreaming about somebody extending one of the many working codec/plugin APIs to something more powerful, so that we finally have a new, opensource codec plugin to be used to standardize for all platforms, like UCI was planning to do once ( http://uci.sf.net ). Unfortunately the maker of UCI, a gentleman called Alex 'Foogod' Stewart, disappeared competely from the scene. I meanwhile do have admin rights for the project on sf.net, together with another guy, but we could very well either drop the project and create a 'Xine Codec API Project' or try to rebuild/finish UCI starting from a powerful existing API such as a Xine or FFMPEG plugin API. We had thoughts to use the Gstreamer plugin API for that, but its hardly possible without having Gstreamer as complete framework underlying, so this is not an option. In any case, this API should be desgined x-platform, so that codec developers ( like the XviD, Lame, MPC, FAAC/FFAD people ) can release their code with one working API only, and this can be compiled for all platforms. No idea if Xine could be extended for this, if so i promise to work hard the complete OSS Windows world will stop using crappy VCM/ACM stuff and support the API at least as 2nd option. The XviD dev API4 could be used as a good example API, i dont know, after all i heard it is pretty powerful and can be used for more than just a MPEG4 codec. Sorry if my ideas are not feasible or simply stupid, i'm not a developer myself but only a project admin, its hard to estimate for me if a general playback app API like Xine's ( with its own encoder in the package also ) could be a basis for such an API . Best regards Christian http://www.matroska.org http://www.matroska.org From rbultje at ronald.bitfreak.net Wed Jun 25 08:51:36 2003 From: rbultje at ronald.bitfreak.net (Ronald Bultje) Date: 25 Jun 2003 08:51:36 +0200 Subject: [matroska-devel] Re: the road to 1.0 and beyond In-Reply-To: <3EF94202.5040106@matroska.org> References: <20030614145020.GA804@goofy.disney.gb> <3EF94202.5040106@matroska.org> Message-ID: <1056523895.2674.13.camel@localhost.localdomain> Hey Chris, On Wed, 2003-06-25 at 08:32, ChristianHJW wrote: > or try to rebuild/finish UCI starting from a powerful existing API such > as a Xine or FFMPEG plugin API. We had thoughts to use the Gstreamer > plugin API for that, but its hardly possible without having Gstreamer as > complete framework underlying, so this is not an option. Any replacement of UCI *has to* (this is not optional, it's a requirement) be merely a *protocol*, not a *lib*. If it's not a protocol, nobody will use it. That goes for whatever name you give to it, and so attaching the name of a media framework like xine or GStreamer to it will only give wrong expectations. Ronald -- Ronald Bultje http://www.matroska.org From christian at matroska.org Thu Jun 26 00:56:41 2003 From: christian at matroska.org (ChristianHJW) Date: Thu, 26 Jun 2003 00:56:41 +0200 Subject: [matroska-devel] Re: the road to 1.0 and beyond In-Reply-To: References: <3EF94202.5040106@matroska.org> Message-ID: <3EFA28A9.7040200@matroska.org> Mike Melanson wrote: >>or try to rebuild/finish UCI starting from a powerful existing API such >>as a Xine or FFMPEG plugin API. We had thoughts to use the Gstreamer >>plugin API for that, but its hardly possible without having Gstreamer as >>complete framework underlying, so this is not an option. > > Personally, I think ffmpeg/libavcodec is a much more appropriate > choice for a universal codec API. I would like to see all of xine's > present decoders moved there (in fact, I am moving in that direction) to > facilitate cross-project collaboration. > -Mike Melanson This is exactly the idea behind that all, to make it easier to use opensource codecs from opensource apps. Some questions here Mike : - would this API be usable for audio also, or only for video ( dont know libavcodec too well, sorry ) ? - you talk about decoders, but what about encoders ? I assume libavcodec has encoders coming with it also ? - most important question : is there any chance to use the libavcodec API on other platforms than Linux ? If so, what were the conditions to make it work ? Thanks for a quick answer Christian http://www.matroska.org P.S. Pete 'Suxendrol' from the XviD team told me about an extension to the VfW API he has planned to allow more advanced features that current VCM codec API doesnt allow, but then again we had only a solution for Windows, and not a real x-platform opensource API ..... what do you all think ? http://www.matroska.org From suxen_drol at hotmail.com Thu Jun 26 10:35:07 2003 From: suxen_drol at hotmail.com (suxen_drol) Date: Thu, 26 Jun 2003 18:35:07 +1000 Subject: [matroska-devel] Re: the road to 1.0 and beyond In-Reply-To: <3EFA28A9.7040200@matroska.org> References: <3EFA28A9.7040200@matroska.org> Message-ID: <20030626173527.6285.SUXEN_DROL@hotmail.com> hi, On Thu, 26 Jun 2003 00:56:41 +0200 ChristianHJW wrote: > P.S. Pete 'Suxendrol' from the XviD team told me about an extension to > the VfW API he has planned to allow more advanced features that current > VCM codec API doesnt allow, but then again we had only a solution for > Windows, and not a real x-platform opensource API ..... what do you all > think ? yea i have lots of plans, and that vfwext was proposed some >15 months ago. recently i did experiment with some extension to make the vfw configuration window aware of the encoding fps and dimensions, but thats hardly **advanced**. developing such an api, framework or protocol is both easy and hard. it depends on the scope your want to capture within that framework. the issues surrounding frame-based encoding and decoding and encoding are well known, and developing a small api to deal with it isn't very hard (and that is what xine, mplayer & transcode have done). and i agree with mike, and have said in the past, that ffmpeg sets a very good example. problems arise when you consider features which dont easy fit in either the codec or the application layer: - configuration. how do we configure the codec? whw is responsible for storing the configuration info, and what if we want to re-configure the codec during the encoding or decoding (such as preprocessing)? vfw has a configure command which display a gui configuration, and some commands for getting/setting a "block" of the configuration memory. uci & ffmpeg have enum/get/set functions for enumerating through configuration options. mplayer has something similar. - two-pass management. 2pass is neither a codec layer issue or an application layer issue, it fits somewhere in between. say i encode a complete first pass, but then want to encode only a portion of that video in the second pass. presently with xvid and divx you have to cut your 2pass stats files, and mess around external scaling/analysis tools. external applications such as gordinaknot(win32) help with this process, but they're not integrated. ideally there would be some what to manage all this stuff, thats sits between codec and application layer. to do this, we need to define what data the codec must provide to such a "management layer". i believe this is difficult, because 2pass is still somewhat unsailed waters. - suspending/restoring codec state. the ability to suspend the encoder, reboot and resume encoding at the same position. - future: video codecs support multiple input streams (think: mp3 stereo). and maybe someday video segmentation will emerge to be popular. are you looking for immediate usefulness chris (run with what we know about video codecs now), or some future-proof-ness (dwindle on future thoughts)? cheers, -- pete http://www.matroska.org From paul at msn.com Thu Jun 26 11:18:14 2003 From: paul at msn.com (Pamel) Date: Thu, 26 Jun 2003 04:18:14 -0500 Subject: [matroska-devel] Re: the road to 1.0 and beyond References: <3EFA28A9.7040200@matroska.org> <20030626173527.6285.SUXEN_DROL@hotmail.com> Message-ID: "suxen_drol" wrote in message > - future: video codecs support multiple input streams (think: mp3 stereo). > and maybe someday video segmentation will emerge to be popular. I hadn't thought about that. I guess an API should be able to handle multiple input/outputs to a single source. I realize DirectShow can do this, but I hadn't thought about the need to include have that in a future API. Its pretty important. > are you looking for immediate usefulness chris (run with what we know > about video codecs now), or some future-proof-ness (dwindle on future > thoughts)? I think Christian's intention is future proof. That's part of the concept of Matroska, to be future proof for the next decade. The DirectShow concept is excellent for playback, but editing is not so good. I think that we need something designed for editing, that is future proof. Pamel http://www.matroska.org From paul at msn.com Thu Jun 26 21:52:45 2003 From: paul at msn.com (Pamel) Date: Thu, 26 Jun 2003 14:52:45 -0500 Subject: [matroska-devel] Re: the road to 1.0 and beyond References: <3EFA28A9.7040200@matroska.org> <20030626173527.6285.SUXEN_DROL@hotmail.com> Message-ID: "Pamel" wrote in message news:bdedn4$7cn$1 at main.gmane.org... > "suxen_drol" wrote in message I also meant to point out that I think UCI may be dead. Given that there is no development, it may be a good idea to start a new project with certain goals in mind. For instance, being able to take advantage of all of the design features of Matroska. :) One of the big issues with a new API that allowed all sorts of neat features is how to tell it, "You can't use these features when writing to AVI." or whatever other container. Pamel http://www.matroska.org From pfk at fuchs.offl.uni-jena.de Sat Jun 28 14:48:48 2003 From: pfk at fuchs.offl.uni-jena.de (Frank Klemm) Date: Sat, 28 Jun 2003 14:48:48 +0200 Subject: [matroska-devel] Re: =[SPAM?]= Re: the road to 1.0 and beyond In-Reply-To: <20030626173527.6285.SUXEN_DROL@hotmail.com>; from suxen_drol@hotmail.com on Thu, Jun 26, 2003 at 06:35:07PM +1000 References: <3EFA28A9.7040200@matroska.org> <20030626173527.6285.SUXEN_DROL@hotmail.com> Message-ID: <20030628144848.A1637@fuchs.offl.uni-jena.de> On Thu, Jun 26, 2003 at 06:35:07PM +1000, suxen_drol wrote: > > - suspending/restoring codec state. the ability to suspend the encoder, > reboot and resume encoding at the same position. > Very important. It should be possible to cut separately encoded streams of "audio/video/what else?" without any gap. > - future: video codecs support multiple input streams (think: mp3 stereo). > and maybe someday video segmentation will emerge to be popular. > - Multiple video streams is used with "Multiple Angle View" - May be "fast forward" and "review" is possible in the future like we know it from VHS. For that it is useful to have two video streams - 1920 x 1080 @24 frames per second, high quality (22 MBit/s) - 480 x 270 @3 frames per second, low quality ( 0.6 MBit/s) - Is it possible to play a video stream in reverse order? - It should be possible to rearrange frames without copying the whole file. It should be possible to cutter a file without moving video or audio data. It should be possible to have a 3 hour video stream which can be arranged in 10 or 20 ways using these 3 hours of video. Remember the movie "Memento". -- Frank Klemm http://www.matroska.org From steve.lhomme at free.fr Sun Jun 29 10:39:00 2003 From: steve.lhomme at free.fr (Steve Lhomme) Date: Sun, 29 Jun 2003 10:39:00 +0200 Subject: [matroska-devel] Re: =[SPAM?]= Re: the road to 1.0 and beyond In-Reply-To: <20030628144848.A1637@fuchs.offl.uni-jena.de> References: <3EFA28A9.7040200@matroska.org> <20030626173527.6285.SUXEN_DROL@hotmail.com> <20030628144848.A1637@fuchs.offl.uni-jena.de> Message-ID: <3EFEA5A4.6090809@free.fr> Frank Klemm wrote: > On Thu, Jun 26, 2003 at 06:35:07PM +1000, suxen_drol wrote: > >>- suspending/restoring codec state. the ability to suspend the encoder, >>reboot and resume encoding at the same position. >> > > Very important. It should be possible to cut separately encoded streams of > "audio/video/what else?" without any gap. You mean (for audio which has the most samples) be able to cut at en exact sample ? > - Is it possible to play a video stream in reverse order? Not now for the moment. But it should be. There is already an element to know the location of the previous Cluster to read (not needed with a complete MetaSeek entry). > - It should be possible to rearrange frames without copying the whole file. You do do the mpuxing again to improve the delay between streams ? It is somehow possible. But it may lead to problems because of all the variable length fields. > It should be possible to cutter a file without moving video or audio data. I think it already works in mkvmerge. > It should be possible to have a 3 hour video stream which can be arranged > in 10 or 20 ways using these 3 hours of video. Remember the movie > "Memento". It is supposed to be handled by the menu system+control track, which is not defined yet. http://www.matroska.org From pfk at fuchs.offl.uni-jena.de Sun Jun 29 13:59:56 2003 From: pfk at fuchs.offl.uni-jena.de (Frank Klemm) Date: Sun, 29 Jun 2003 13:59:56 +0200 Subject: [matroska-devel] Re: =[SPAM?]= Re: =[SPAM?]= Re: the road to 1.0 and beyond In-Reply-To: <3EFEA5A4.6090809@free.fr>; from steve.lhomme@free.fr on Sun, Jun 29, 2003 at 10:39:00AM +0200 References: <3EFA28A9.7040200@matroska.org> <20030626173527.6285.SUXEN_DROL@hotmail.com> <20030628144848.A1637@fuchs.offl.uni-jena.de> <3EFEA5A4.6090809@free.fr> Message-ID: <20030629135956.A10549@fuchs.offl.uni-jena.de> On Sun, Jun 29, 2003 at 10:39:00AM +0200, Steve Lhomme wrote: > Frank Klemm wrote: > > On Thu, Jun 26, 2003 at 06:35:07PM +1000, suxen_drol wrote: > > > >>- suspending/restoring codec state. the ability to suspend the encoder, > >>reboot and resume encoding at the same position. > >> > > > > Very important. It should be possible to cut separately encoded streams of > > "audio/video/what else?" without any gap. > > You mean (for audio which has the most samples) be able to cut at en > exact sample ? > This is the first demand, which is comparable easy to fullfil. The second is: - You have two pieces of music which play gapless when you play the first and the second - You encode them - You decode them - The decoded pieces should have the same property, it should not be audible, visible, smellable, etc. that you encode the two pieces separately - A critical signal is colored noise with most of it's spectrum above 12...16 kHz. > > - Is it possible to play a video stream in reverse order? > > Not now for the moment. But it should be. There is already an element to > know the location of the previous Cluster to read (not needed with a > complete MetaSeek entry). > Okay. > > > - It should be possible to rearrange frames without copying the whole file. > > You do do the mpuxing again to improve the delay between streams ? It is > somehow possible. But it may lead to problems because of all the > variable length fields. > Extreme: - You have you holiday movie on 2 DVD-R - You have a machine with some MByte of RAM able to decode the stream and a little bit more. - You have a DVD-R writer Until the final cuttering process there's only some metadata handled, no video or audio is copied. $ ls -la -r--r--r-- 1 root root 4683123456 Nov 11 2003 Holiday-2003-01.mkv -r--r--r-- 1 root root 4683123876 Nov 11 2003 Holiday-2003-02.mkv -r--r--r-- 1 root root 4683126721 Nov 11 2003 Holiday-2003-03.mkv -r--r--r-- 1 root root 4683117892 Nov 11 2003 Holiday-2003-04.mkv -r--r--r-- 1 root root 4683106378 Nov 11 2003 Holiday-2003-05.mkv -r--r--r-- 1 root root 4683128952 Nov 11 2003 Holiday-2003-06.mkv -r--r--r-- 1 root root 4683093737 Nov 11 2003 Holiday-2003-07.mkv -r--r--r-- 1 root root 4183716326 Nov 11 2003 Holiday-2003-08.mkv -r--r--r-- 1 root root 965345125 Nov 17 2003 Holiday-2003-Effects.mkv -r--r--r-- 1 root root 1987213 Nov 18 2003 Holiday-2003-Long Version.mkv -r--r--r-- 1 root root 17213 Nov 18 2003 Holiday-2003-Short Version.mkv -r--r--r-- 1 root root 9843161 Nov 19 2003 Holiday-2003-Alternative Version.mkv $ mkdependencies Holiday-2003-01.mkv Holiday-2003-01.mkv (used by another file) $ mkdependencies "Holiday-2003-Long Version.mkv" Holiday-2003-Long Version.mkv (used by another file) +-- Holiday-2003-01.mkv +-- Holiday-2003-02.mkv +-- Holiday-2003-04.mkv +-- Holiday-2003-05.mkv +-- Holiday-2003-06.mkv +-- Holiday-2003-07.mkv +-- Holiday-2003-08.mkv '-- Holiday-2003-Effects.mkv $ mkdependencies "Holiday-2003-Short Version.mkv" Holiday-2003-Short Version.mkv '-- Holiday-2003-Long Version.mkv +-- Holiday-2003-01.mkv +-- Holiday-2003-02.mkv +-- Holiday-2003-04.mkv +-- Holiday-2003-05.mkv +-- Holiday-2003-06.mkv +-- Holiday-2003-07.mkv +-- Holiday-2003-08.mkv '-- Holiday-2003-Effects.mkv $ mklinker -v "Holiday-2003-Short Version.mkv" "Holiday-2003-Short Version.linked.mkv" Wrote 17.6 GByte to "Holiday-2003-Short Version*.mkv" in 1241 seconds. Playtime 93.71 minutes. $ ls -la "Holiday-2003-Short Version.linked.mkv" -r--r--r-- 1 root root 17213 Nov 18 2003 Holiday-2003-Short Version.mkv -r--r--r-- 1 root root 17613093737 Nov 19 2003 Holiday-2003-Short Version.linked.mkv $ mkdependencies "Holiday-2003-Short Version.linked.mkv" Holiday-2003-Short Version.linked.mkv $ _ > > > It should be possible to cutter a file without moving video or audio data. > > I think it already works in mkvmerge. > Don't tested by me. > > It should be possible to have a 3 hour video stream which can be arranged > > in 10 or 20 ways using these 3 hours of video. Remember the movie > > "Memento". > > It is supposed to be handled by the menu system+control track, which is > not defined yet. > Okay. -- Frank Klemm http://www.matroska.org From miguel at cetuc.puc-rio.br Thu Jun 26 12:56:25 2003 From: miguel at cetuc.puc-rio.br (Miguel Freitas) Date: 26 Jun 2003 07:56:25 -0300 Subject: [matroska-devel] Re: [xine-devel] Re: the road to 1.0 and beyond In-Reply-To: <3EFA28A9.7040200@matroska.org> References: <3EF94202.5040106@matroska.org> <3EFA28A9.7040200@matroska.org> Message-ID: <1056624985.1012.12.camel@mf> On Wed, 2003-06-25 at 19:56, ChristianHJW wrote: > P.S. Pete 'Suxendrol' from the XviD team told me about an extension to > the VfW API he has planned to allow more advanced features that current > VCM codec API doesnt allow, but then again we had only a solution for > Windows, and not a real x-platform opensource API ..... what do you all > think ? crap. sorry, i see no pointing in keeping compatibility with that ugly api. ffmpeg api is far from perfect but you really cannot compare (especially if you are looking for your panacea universal api...) regards, Miguel http://www.matroska.org From christian at matroska.org Fri Jun 27 00:58:05 2003 From: christian at matroska.org (ChristianHJW) Date: Fri, 27 Jun 2003 00:58:05 +0200 Subject: [matroska-devel] Common Opensource codec API , was : Re: the road to 1.0 and beyond In-Reply-To: <20030626193506.GH8550@goofy.disney.gb> References: <3EF94202.5040106@matroska.org> <20030626193506.GH8550@goofy.disney.gb> Message-ID: <3EFB7A7D.4060003@matroska.org> Guenter Bartsch wrote: > hallo mike, > this sounds like exactly the right direction for future developements to me. > a few questions though: > - does ffmpeg's codec api have all features needed, e.g. stuff like > cache-local colorspace conversion (per-slice) like libmpeg2 has? > - does ffmpeg have a plugin concept for dynamic loading of plugins? > if not, do you see a chance to talk them into introducing such a > feature? > - how about demuxer plugins? could this api be shared as well? > how about other project? does anybody on this list have contacts and/or > deeper knowledge about other multimedia projects in the free software > world? i'm thinking of mplayer g2, videolan and gstreamer here. Ronald 'BBB' Bultje, one of the core devs of the Gstreamer team is reading here AFAIK, so he could make contact i guess. The Gstreamer people do have a nice API with their 'gst plugin API' AFAIK, but it doesnt help them a lot as its tied to Gstreamer as a framework and so no codec developers will support it natively. So, in the end, they have to make all the plugins themselves now ( i guess BBB is doing that ) and also maintain them. If there was a common opensource codec API, a standard wrapper plugin could be enought for them maybe to cover most formats ? I was talking with Erik 'omega' Waltinsen a couple of times on IRC, he's the founder of Gstreamer and does certainly know a lot about this kind of stuff, and he told me he had a neat concept in the very back of his brains already, but just no time to bring it onto paper. Maybe if you guys showed some real interest in cooperating with them here, you could start an avalanche .... > my basic reasoning behin this is that now that all these different > projects are getting close to their 1.0 releases (ok, not all of them ;) > ) and so many developers have gained experience on how to design media > players, codecs, do audio/video output, etc. it would be interesting to > see if and how some collaboration between these projects could be > established. > guenter Exactly my thoughts also. Must be because we're both Germans Guenter :-D !! Christian http://www.matroska.org From bartscgr at t-online.de Fri Jun 27 01:47:24 2003 From: bartscgr at t-online.de (Guenter Bartsch) Date: Fri, 27 Jun 2003 01:47:24 +0200 Subject: [matroska-devel] Re: [xine-devel] Common Opensource codec API , was : Re: the road to 1.0 and beyond In-Reply-To: <3EFB7A7D.4060003@matroska.org> References: <3EF94202.5040106@matroska.org> <20030626193506.GH8550@goofy.disney.gb> <3EFB7A7D.4060003@matroska.org> Message-ID: <20030626234724.GA9431@goofy.disney.gb> hallo christian, one the one hand i am happy the subject has changed as this discussion was getting pretty off-topic, on the other hand i dislike two things about the new topic: - opensource while i dislike the word in itself (i never really understood what the opensource movement is about), i think it limits this discussion to just opensource codecs - but binary-only codecs play an important role in today's free software world, like it or not (think quicktime, think real codecs for examples) - codecs i'd like to broaden the discussion to all kinds of plugins, especially demuxers and a common input abstraction layer so, basically i think it would be interesting to see if it is possible to agree on a common standard for free multimedia plugins, especially for - a common input abstraction layer - demuxers - codecs and maybe also - audio/video output among some media player projects. > Ronald 'BBB' Bultje, one of the core devs of the Gstreamer team is > reading here AFAIK, so he could make contact i guess. > > The Gstreamer people do have a nice API with their 'gst plugin API' > AFAIK, but it doesnt help them a lot as its tied to Gstreamer as a > framework and so no codec developers will support it natively. So, in > the end, they have to make all the plugins themselves now ( i guess BBB > is doing that ) and also maintain them. is there some documentation available on gstreamer's plugin api? sounds very interesting to me, but what i found on their website was pretty incomplete and hat lots of broken links in it. gstreamer is definitely worth looking into, though. i have also added mplayer's developement list to the recipients of this mail as i think their mplayer g2 efforts might be a good time to think about common standards as well. > I was talking with Erik 'omega' Waltinsen a couple of times on IRC, he's > the founder of Gstreamer and does certainly know a lot about this kind > of stuff, and he told me he had a neat concept in the very back of his > brains already, but just no time to bring it onto paper. Maybe if you > guys showed some real interest in cooperating with them here, you could > start an avalanche .... let's see, what he says :) one problem with gstreamer imho is their many g'isms, not sure what the current state there is. i think a common api should not be dependant on stuff like glib or gobject (though i love glib i don't think it's a good idea to force everyone into using it). so, let's hear what people have to say. this is the time for constructive proposals, all flames and all mplayer vs xine vs gstreamer vs whatever ranting will go directly into /dev/null. guenter -- "The other day I put instant coffee in my microwave oven ... I almost went back in time." -- Steven Wright http://www.matroska.org From rbultje at ronald.bitfreak.net Fri Jun 27 15:13:14 2003 From: rbultje at ronald.bitfreak.net (Ronald Bultje) Date: 27 Jun 2003 15:13:14 +0200 Subject: [matroska-devel] Re: Common Opensource codec API In-Reply-To: <20030626234724.GA9431@goofy.disney.gb> References: <3EF94202.5040106@matroska.org> <20030626193506.GH8550@goofy.disney.gb> <3EFB7A7D.4060003@matroska.org> <20030626234724.GA9431@goofy.disney.gb> Message-ID: <1056719592.2183.298.camel@shrek.bitfreak.net> Howdy, On Fri, 2003-06-27 at 01:47, Guenter Bartsch wrote: > so, basically i think it would be interesting to see if it is possible > to agree on a common standard for free multimedia plugins, especially > for > > - a common input abstraction layer > - demuxers > - codecs > > and maybe also > > - audio/video output > > among some media player projects. I'd be in favour of some of these. There's some buts here... * if we take ffmpeg's demuxer (application) interface as an example, we see that it is severly limited. I don't see any way to specify subtitle streams, nor can I get private streams. I'm limited to video/audio, which isn't a good thing. Of course this is fixable, but in the best case, it'd require some sort of objectification, and as far as I understand, you guys aren't really in favour of this. There's three ways to do this: * c++ * g_* stuffies * c struct with casts Basically, (2) is (3) with some nicities of separation of classes and instances around it. Anyway, most people will dislike both (1) and (2) simply because it has dependencies (c++/glib). (3) looks evil and is quite some work to implement, but would be worth a try. What you probably want is - taking the demuxer as an example - to have a bytestream object which exports codecstreams (parent object) which can be a video/audio/subtitle/teletext/private/any stream (a child of the codecstream parent). Fortunately, for codecs, the idea is much simpler, but the same problem applies to properties: each codec must be able to generate *any* property with *any* value type. This is my main problem with ffmpeg currently (I do want to mention that ffmpeg totally rocks, but just like anything, it isn't perfect. ;) ), it's just one static struct. This is nice'n'simple, but also severely limiting. This is why using ffmpeg's current form of identifying codecs/streams/etc. wouldn't be a good idea to use as the basis of such a generic codec API, imo. GStreamer isn't perfect either. It depends on glib - I can understand that people won't like that. Same goes for other interfaces. It's basically fairly complex for a thing like a codec interface. It's fairly generalized towards basically anything, which makes it less suited as example for specific purposes. Basically, if I want a codec API or a demuxer API, I probably want these to be specifically suited for that purpose. For GStreamer, both APIs would be the same. ;). What I'm saying is that if we want to make a good codec API, some ideas of GStreamer (extendibility etc.) might be worth considering, but in general, GStreamer's API an sich might be a bit too general. I'm not sure what others think of this. The good thing is that you're not constrained by a limited set of properties, streams, types of streams or anything; everything is extendible without having to modify any of the GStreamer core. As for Xine/Mplayer, I'm sorry to say that I don't have enough experience with their code to give a strong opinion on it. I did look at the code a few times, but don't know the codebase well enough. I'll try to make some general comments, though, regarding the codec API of both. I've had a quick look at the mplayer demuxer code (simply because I took that as an example for the ffmpeg one too), and noticed that it has entries for audio, video and subtitles in the demuxer_t struct. That leads to the same complaint as for ffmpeg - it's pretty good, but it is somewhat limiting. Another problem (well, take these as comments, not complaints) is that the actual filestream data (which should be private in the demuxer, not adaptable by the application) is integrated in the demuxer_t struct, too. This isn't a problem, but it's not a good idea to make this part of the codec/demuxer API - it should only contain things that the application actually cares about. The rest should be kept private. As for Xine, I read through it quickly but apparently, I don't get it. ;). xine-lib/src/demuxers/demux.h doesn't mention anything apart from video. I guess I'm missing something. ;). > is there some documentation available on gstreamer's plugin api? sounds > very interesting to me, but what i found on their website was pretty > incomplete and hat lots of broken links in it. gstreamer is definitely > worth looking into, though. Well, there used to be some, but I can't find it anywhere, that's pretty much a bad thing. In our CVS, there's a gst-template module. In the directory gst-plugin/src/*, you'll find an example plugin. That is probably a good start. Direct WWW link: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/gstreamer/gst-template/gst-plugin/src/ At the bottom, plugin_desc is the structure that loads the plugin. The _class_init(), _init() and _get_type() functions are all gobject core stuff. _get_property() and _set_property() (for properties) are all glib/gobject property functions. _chain() is the actual datastream callback for I/O. At the top, the pad templates define I/O points for this plugin, and a caps (none given here) defines the type of the stream. A GstCaps is basically what we use as way of identifying data types. Some more info on this is in CVS, module gstreamer: docs/random/mimetypes. www link: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/gstreamer/gstreamer/docs/random/mimetypes. We're currenty basically done documenting all this, but it's not all implemented perfectly yet. > let's see, what he says :) one problem with gstreamer imho is their many > g'isms, not sure what the current state there is. i think a common api > should not be dependant on stuff like glib or gobject (though i love > glib i don't think it's a good idea to force everyone into using it). As said above, I tend to agree that it's not a good dependency for a core thing such as a codec API. What I'd love to see is the codec API not being an actual lib, but just a protocol, like X. Each application can then write it's own implementation code for this, and the codec API can, if wanted, provide a header file describing all structs (if any) etc. used in the protocol. Tying ourselves to one and the same lib likely won't work, even now we're already reproducing so much of the same code... Do people agree with this? Ok, now back to the actual question, what would it look like. A protocol describes structs or data fields, documents what properties mean what, etc. If we want a common demuxer API, I'd very much prefer if people would use the parent-child object stuffing I described in the beginning of this email. Each bytestream can export codec streams, which can be anything, including but not limited to audio, video, subtitle, teletext, private data or whatever. Types define the actual type of the codec stream, and by means of a child class, all specifics are filled in for the particular stream. For audio, this is rate, channels, maybe (in case of raw audio) the bitsize (8, 16) or container type (uint8_t, int16_t, maybe expansions of these for future reference), this can also be float data, btw! We just need to document what property name means what, and then simply make a name/value pair system that describes all these. For video, this would be width, height, ... For subtitles, this would be nothing at first, I guess. The parent object describes things like timestamps, duration, the actual data+size. Codecs: much easier. One input, one output. Properties are the same as the properties for the codec stream in the demuxer in case of the encoded data. For the decoded data, the same applies, but we'll probably want to provide some more properties for 'raw' data. Anyway, this just needs specifying. The mimetypes document above is what we currently use, other comments are welcome, of course. Concerns from my side, for as far as my experience goes with codecs in GStreamer: do we want to separate between codec and bytestream in case where these are (almost) the same, such as ogg/vorbis, mp3, etc? If so, what are the exact tasks of the parser (e.g. defining properties required by the codec, maybe metadata) and the codec (decoding), and what do we do if these interfere (e.g. I'm being told that not ogg, but vorbis contains the metadata of a stream!). And just to state clearly: our final goal is to propose a standardized API or interface of how codecs, muxer/demuxer libraries etc. should look to be usable by our applications. It is not to define how a bytestream should look. ;). Just so I (and you) know what we're actually talking about. Enough typing for now, I'd better get back to actual work here. :-o. Comments are very much appreciated. ;). Thanks for reading, Ronald -- Ronald Bultje http://www.matroska.org From Uraeus at linuxrising.org Fri Jun 27 16:36:39 2003 From: Uraeus at linuxrising.org (Christian Fredrik Kalager Schaller) Date: 27 Jun 2003 16:36:39 +0200 Subject: [matroska-devel] Re: [gst-devel] Re: Common Opensource codec API In-Reply-To: <1056719592.2183.298.camel@shrek.bitfreak.net> References: <3EF94202.5040106@matroska.org> <20030626193506.GH8550@goofy.disney.gb> <3EFB7A7D.4060003@matroska.org> <20030626234724.GA9431@goofy.disney.gb> <1056719592.2183.298.camel@shrek.bitfreak.net> Message-ID: <1056724599.1663.6.camel@localhost.localdomain> On Fri, 2003-06-27 at 15:13, Ronald Bultje wrote: > There's three ways > to do this: > * c++ > * g_* stuffies > * c struct with casts > Basically, (2) is (3) with some nicities of separation of classes and > instances around it. Anyway, most people will dislike both (1) and (2) > simply because it has dependencies (c++/glib). Considering how widely available and widely used glib is I have a hard time seeing that it would be something 'most' people would dislike. I mean, whats next, people objecting to a libc dependency? Christian -- Christian Fredrik Kalager Schaller http://www.matroska.org From christian at matroska.org Sat Jun 28 16:35:45 2003 From: christian at matroska.org (ChristianHJW) Date: Sat, 28 Jun 2003 16:35:45 +0200 Subject: [matroska-devel] Re: Common Opensource codec API In-Reply-To: <1056719592.2183.298.camel@shrek.bitfreak.net> References: <3EF94202.5040106@matroska.org> <20030626193506.GH8550@goofy.disney.gb> <3EFB7A7D.4060003@matroska.org> <20030626234724.GA9431@goofy.disney.gb> <1056719592.2183.298.camel@shrek.bitfreak.net> Message-ID: <3EFDA7C1.6090009@matroska.org> Ronald Bultje wrote: >Howdy, > >On Fri, 2003-06-27 at 01:47, Guenter Bartsch wrote: > > >>so, basically i think it would be interesting to see if it is possible >>to agree on a common standard for free multimedia plugins, especially >>for >> I 'd have high hopes on this also, but i am not convinced that it is possible to find a common denominator easily. >>let's see, what he says :) one problem with gstreamer imho is their many >>g'isms, not sure what the current state there is. i think a common api >>should not be dependant on stuff like glib or gobject (though i love >>glib i don't think it's a good idea to force everyone into using it). >> >> > >As said above, I tend to agree that it's not a good dependency for a >core thing such as a codec API. > I fully agree here BBB. This codec API can maybe base on a small lib, but thats it. Alex Stewarts' libuci was more an example lib how UCI could be used from an app, while on the codec side this wasnt required at all IIRC: >What I'd love to see is the codec API not being an actual lib, but just >a protocol, like X. Each application can then write it's own >implementation code for this, and the codec API can, if wanted, provide >a header file describing all structs (if any) etc. used in the protocol. >Tying ourselves to one and the same lib likely won't work, even now >we're already reproducing so much of the same code... Do people agree >with this? > > LOL. Maybe OT here, but this reminds me that somebody was comparing EBML, the backbone of matroska and a kind of binary XML, with a printer protocol for LAN printers once ... :) ... >Ok, now back to the actual question, what would it look like. A protocol >describes structs or data fields, documents what properties mean what, >etc. If we want a common demuxer API, I'd very much prefer if people >would use the parent-child object stuffing I described in the beginning >of this email. Each bytestream can export codec streams, which can be >anything, including but not limited to audio, video, subtitle, teletext, >private data or whatever. Types define the actual type of the codec >stream, and by means of a child class, all specifics are filled in for >the particular stream. >For audio, this is rate, channels, maybe (in case of raw audio) the >bitsize (8, 16) or container type (uint8_t, int16_t, maybe expansions of >these for future reference), this can also be float data, btw! We just >need to document what property name means what, and then simply make a >name/value pair system that describes all these. >For video, this would be width, height, ... For subtitles, this would be >nothing at first, I guess. >The parent object describes things like timestamps, duration, the actual >data+size. > >Codecs: much easier. One input, one output. Properties are the same as >the properties for the codec stream in the demuxer in case of the >encoded data. For the decoded data, the same applies, but we'll probably >want to provide some more properties for 'raw' data. Anyway, this just >needs specifying. The mimetypes document above is what we currently use, >other comments are welcome, of course. > >Concerns from my side, for as far as my experience goes with codecs in >GStreamer: do we want to separate between codec and bytestream in case >where these are (almost) the same, such as ogg/vorbis, mp3, etc? If so, >what are the exact tasks of the parser (e.g. defining properties >required by the codec, maybe metadata) and the codec (decoding), and >what do we do if these interfere (e.g. I'm being told that not ogg, but >vorbis contains the metadata of a stream!). > > BBB, can you invest a couple of hours and come up with a small doc describing such a protocol, so it could be discussed on the lists that have been involved and were expressing interest in such a solution ? >And just to state clearly: our final goal is to propose a standardized >API or interface of how codecs, muxer/demuxer libraries etc. should look >to be usable by our applications. It is not to define how a bytestream >should look. ;). Just so I (and you) know what we're actually talking >about. > Alex had the following plans for UCI : UCI : codec API UFI : filter API UMI : muxing API, so that various containers could be used from supporting apps All those required a different level of complexity, with UCI being lowest. UCI itself could not handle streams with more than one substreams in it ( like DV type 1 ), but this was supported by UMI then. Very unfortunately not even UCI was getting anywhere close to completion and we had no sign of Life from Alex since a couple of months now, but maybe somebody find the time to look at what he did and documented so far ? http://uci.sf.net . BBB, is Alex' approach similar to a protocol approach as suggested by you ? >Enough typing for now, I'd better get back to actual work here. :-o. >Comments are very much appreciated. ;). >Thanks for reading, Ronald > > Great ideas BBB, of course i only understand half of it ;-) ..... any other devs care to comment more in detail ? Could such a 'protocol' solution be something you would want to support ? Christian http://www.matroska.org From moritz at bunkus.org Sat Jun 28 09:58:47 2003 From: moritz at bunkus.org (Moritz Bunkus) Date: Sat, 28 Jun 2003 09:58:47 +0200 Subject: [matroska-devel] b-frames Message-ID: <20030628075847.GG1544@bunkus.org> Heya. Although I'm at home I'm still pondering the B frame handling. So here are some of my questions. 1. Let's assume you have the typical sequence of IBP (display order?), timestamps 0, 40 and 80ms. In order to store that in Matroska WITH libmatroska I have to first AddFrame(I), then AddFrame(P, I) and then AddFrame(B, I, P). Otherwise I don't have the BlockGroup for the P frame that the AddFrame(B...) needs. Correct? So in a Matroska file the frames would be stored as IPB. 2. Reading those frames and refpriorities. For a file containing B frames I have a MinCache of 2. I frames have a prio of 0, P have 1 and B have a prio of 2. Correct? So let's take the example above. I get the I frame and keep it. I get the P frame and keep it. Then I get the B frame. Now I'm happy and can deliver the frames in the order I want (either coding or display). Next example: display order IPBP which are stored as IPPB in the file according to my thoughts in 1. So I get the I frame, the first P frame which I both store. Now I get the second P frame. But which frame from the two stored frames can I discard? And how do I decide that? 3. Multiple B frames. Is this possible? If yes, how do I handle that? Display order: IB1B2P. How will this be stored, what does the refprio/cache handling look like in this case? I guess that Steve will answer all this ;) Thanks in advance. -- ==> Ciao, Mosu (Moritz Bunkus) http://www.matroska.org From steve.lhomme at free.fr Sat Jun 28 12:37:28 2003 From: steve.lhomme at free.fr (Steve Lhomme) Date: Sat, 28 Jun 2003 12:37:28 +0200 Subject: [matroska-devel] Re: b-frames In-Reply-To: <20030628075847.GG1544@bunkus.org> References: <20030628075847.GG1544@bunkus.org> Message-ID: <3EFD6FE8.6050409@free.fr> Moritz Bunkus wrote: > Heya. > > Although I'm at home I'm still pondering the B frame handling. So here > are some of my questions. > > 1. Let's assume you have the typical sequence of IBP (display order?), > timestamps 0, 40 and 80ms. In order to store that in Matroska WITH > libmatroska I have to first AddFrame(I), then AddFrame(P, I) and then > AddFrame(B, I, P). Otherwise I don't have the BlockGroup for the P > frame that the AddFrame(B...) needs. Correct? So in a Matroska file > the frames would be stored as IPB. Yes, in coding order. That's also probably the preferred way for the codec. > 2. Reading those frames and refpriorities. For a file containing B > frames I have a MinCache of 2. I frames have a prio of 0, P have 1 > and B have a prio of 2. Correct? So let's take the example above. I Yes and no. You can also have P frames with prio of 0 because they are used the same as I frames in MPEG (for references). > get the I frame and keep it. I get the P frame and keep it. Then I > get the B frame. Now I'm happy and can deliver the frames in the > order I want (either coding or display). > > Next example: display order IPBP which are stored as IPPB in the file > according to my thoughts in 1. So I get the I frame, the first P > frame which I both store. Now I get the second P frame. But which > frame from the two stored frames can I discard? And how do I decide > that? It should be actually 0 for P frames because it's supposed to replace an I frame in the reference cache. With a value of 1 it can't replace in cache an element with prio 0. > 3. Multiple B frames. Is this possible? If yes, how do I handle that? > Display order: IB1B2P. How will this be stored, what does the > refprio/cache handling look like in this case? > > I guess that Steve will answer all this ;) Thanks in advance. display order : I1 B2 B3 P4 coding order : I1 P4 B2 B3 (== matroska order) I1 : prio 0 P4 : prio 0 B2 : prio 2 B3 : prio 2 You have 2 elements in the cache, an element is rendered when it leaves the cache... I1 arrives : (I1, .) P4 arrives : (I1, P4) B2 arrives : it can't replace an element in the cache, so all previous frames in the cache has to be rendered, ie I1 (I1*, P4) and B2* (displayed) B3 arrives : it can't replace.... (I1*, P4) and B3* P5 or I5 arrives : It has to replace an element in the cache (P4, I5) etc until there is no more data and so you have to flush the cache in display order. (I use an ordered list in the DSF, using std::map). I still haven't implemented the full system... (I have to fix my lockings first), ie I keep everything in memory ;) http://www.matroska.org From chris at matroska.org Sat Jun 28 12:55:15 2003 From: chris at matroska.org (Christian HJ Wiesner) Date: Sat, 28 Jun 2003 12:55:15 +0200 Subject: [matroska-devel] Re: b-frames In-Reply-To: <3EFD6FE8.6050409@free.fr> References: <20030628075847.GG1544@bunkus.org> <3EFD6FE8.6050409@free.fr> Message-ID: <3EFD7413.2040302@matroska.org> Dave, are you subscribed to matroska-devel meanwhile ? did you respect this in avs2matroska already ? Steve Lhomme wrote: >Moritz Bunkus wrote: > > >>Heya. >> >>Although I'm at home I'm still pondering the B frame handling. So here >>are some of my questions. >> >>1. Let's assume you have the typical sequence of IBP (display order?), >> timestamps 0, 40 and 80ms. In order to store that in Matroska WITH >> libmatroska I have to first AddFrame(I), then AddFrame(P, I) and then >> AddFrame(B, I, P). Otherwise I don't have the BlockGroup for the P >> frame that the AddFrame(B...) needs. Correct? So in a Matroska file >> the frames would be stored as IPB. >> >> > >Yes, in coding order. That's also probably the preferred way for the codec. > > > >>2. Reading those frames and refpriorities. For a file containing B >> frames I have a MinCache of 2. I frames have a prio of 0, P have 1 >> and B have a prio of 2. Correct? So let's take the example above. I >> >> > >Yes and no. You can also have P frames with prio of 0 because they are >used the same as I frames in MPEG (for references). > > > >> get the I frame and keep it. I get the P frame and keep it. Then I >> get the B frame. Now I'm happy and can deliver the frames in the >> order I want (either coding or display). >> >> Next example: display order IPBP which are stored as IPPB in the file >> according to my thoughts in 1. So I get the I frame, the first P >> frame which I both store. Now I get the second P frame. But which >> frame from the two stored frames can I discard? And how do I decide >> that? >> >> > >It should be actually 0 for P frames because it's supposed to replace an >I frame in the reference cache. With a value of 1 it can't replace in >cache an element with prio 0. > > > >>3. Multiple B frames. Is this possible? If yes, how do I handle that? >> Display order: IB1B2P. How will this be stored, what does the >> refprio/cache handling look like in this case? >> >>I guess that Steve will answer all this ;) Thanks in advance. >> >> > >display order : I1 B2 B3 P4 >coding order : I1 P4 B2 B3 (== matroska order) >I1 : prio 0 >P4 : prio 0 >B2 : prio 2 >B3 : prio 2 > >You have 2 elements in the cache, an element is rendered when it leaves >the cache... >I1 arrives : (I1, .) >P4 arrives : (I1, P4) >B2 arrives : it can't replace an element in the cache, so all previous >frames in the cache has to be rendered, ie I1 >(I1*, P4) and B2* (displayed) >B3 arrives : it can't replace.... >(I1*, P4) and B3* >P5 or I5 arrives : It has to replace an element in the cache >(P4, I5) > >etc until there is no more data and so you have to flush the cache in >display order. (I use an ordered list in the DSF, using std::map). > >I still haven't implemented the full system... (I have to fix my >lockings first), ie I keep everything in memory ;) > > >http://www.matroska.org > > > http://www.matroska.org From suiryc at yahoo.com Sat Jun 28 14:31:21 2003 From: suiryc at yahoo.com (Cyrius) Date: Sat, 28 Jun 2003 05:31:21 -0700 (PDT) Subject: [matroska-devel] Re: b-frames In-Reply-To: <3EFD6FE8.6050409@free.fr> Message-ID: <20030628123121.53768.qmail@web12906.mail.yahoo.com> Hi --- Steve Lhomme wrote: > Moritz Bunkus wrote: > > Heya. > > > > Although I'm at home I'm still pondering the B > frame handling. So here > > are some of my questions. > > > > 1. Let's assume you have the typical sequence of > IBP (display order?), > > timestamps 0, 40 and 80ms. In order to store > that in Matroska WITH > > libmatroska I have to first AddFrame(I), then > AddFrame(P, I) and then > > AddFrame(B, I, P). Otherwise I don't have the > BlockGroup for the P > > frame that the AddFrame(B...) needs. Correct? > So in a Matroska file > > the frames would be stored as IPB. > > Yes, in coding order. That's also probably the > preferred way for the codec. Yup coding order (we have no choice atm anyway - unless by cheating - as mentionned Mosu :p). > > 2. Reading those frames and refpriorities. For a > file containing B > > frames I have a MinCache of 2. I frames have a > prio of 0, P have 1 > > and B have a prio of 2. Correct? So let's take > the example above. I > > Yes and no. You can also have P frames with prio of > 0 because they are > used the same as I frames in MPEG (for references). One day someone told me I should read and follow the specs instead of what he was saying (/me whistle). So to remind you the specs : "ReferencePriority : This frame is referenced and has the specified cache priority. In cache only a frame of the same or higher priority can replace this frame. A value of 0 means the frame is not referenced." So what does that mean ? Somewhat the contrary of what both of you are saying here :p First that B frames should have a priority of 0 since they aren't referenced (it is the case in avs2matroska Chris ;)), and that I and P frames would have a priority of 1 or 2. Currently when there are only I and P frames nobody uses priorities (why ? well maybe because using the same priority number for each frame would be enough since in this case we only need the previous decoded frame - whatever it may be - to be able to decode the next one if it isn't a new I frame, so setting all frames to a priority of 1 would just be a waste of space). So let's see what is actually done with avs2matroska. Here is the order in which frames are (display order) : (I will not use a common pattern to see what would happen in many cases) I1 B1 B2 P1 B3 B4 P2 P3 B5 I2 P4 ... (what isn't common in this sequence : you find 2 consecutive P frames - P2 & P3 - while generally you wouldn't break the BBP sequence; you find an I frame - I2 - as forward reference of a B frame, while it seems generally it wouldn't happen - maybe I'm wrong here) Here is how those frames would be stored (coding order) : I1 P1 B1 B2 P2 B3 B4 P3 I2 B5 P4 ... You can consider we obtained this sequence by shifting the B frames to the right, moving the replaced frame to the left : 1. I1 B1 B2 P1 B3 B4 P2 P3 B5 I2 P4 B1 B2 B3 B4 B5 ==> I1 P1 P2 P3 I2 P4 2. B1 B2 B3 B4 B5 I1 <-P1 <-P2 P3 <-I2 P4 3. B1 B2 B3 B4 B5 I1 P1 P2 P3 I2 P4 = I1 P1 B1 B2 P2 B3 B4 P3 I2 B5 P4 How does that look in a pseudo algorithm ? Let's imagine you have a list of 2 elements, first element is named ref1, second element is named ref2. When you add a new element in the list (queue_as_reference()), it replaces ref2, which replaces ref1, which is 'lost' (we don't use it anymore). (ref1 and ref2 will point to KaxBlockGroup elements actually ;)) Let's say you also have a list of pending b-frames. while(frame_received) { if(b-frame) { queue_in_list() continue() } if(i-frame) { add_to_cluster() queue_as_reference() flush_queued_bframes() } if(p-frame) { add_to_cluster(using ref2 as reference) queue_as_reference() flush_queued_bframes() } } where : flush_queued_bframes() { for each frame in the b-frame list { add_to_cluster(using ref1 and ref2 as reference) } } There is still the question of what priorities to use. Actually avs2matroska uses priorities of 0 for B-frames (right, since they aren't referenced), and 2 for the other frames). Is this good ? Let's take our sequence Frames : I1 P1 B1 B2 P2 B3 B4 P3 I2 B5 P4 Refs: 2 2 0 0 2 0 0 2 2 0 2 Cache (frames start to be rendered when it is full) [ , ] [ ,I1 ] I1, priority 2 [I1 ,P1 ] P1, priority 2 [I1*,P1 ] B1, priority 0 => can't replace a frame in the cache, the cache is full, render the frames we can, i.e. I1 and B1 (because it has a timestamp lower than P1, and thanks to the referenced frames I1 and P1) [I1*,P1 ] B2, priority 0 => idem, render B2 (timestamp lower than P1) [P1*,P2 ] P2, priority 2 => replace P1 which replaces I1* (older timestamp), render P1 since it has a timestamp lower than P2 [P1*,P2 ] B3, priority 0 => B3 rendered [P1*,P2 ] B4, priority 0 => B4 rendered [P2*,P3 ] P3, priority 2 => P2 rendered [P3*,I2 ] I2, priority 2 => P3 rendered [P3*,I2 ] B5, priority 2 => B5 rendered [I2*,P4 ] P4, priority 2 => I2 rendered ... So frames are rendered in this order so far : I1 B1 B2 P1 B3 B4 P2 P3 B5 I2 ... which is good :) __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com http://www.matroska.org From moritz at bunkus.org Sat Jun 28 18:38:27 2003 From: moritz at bunkus.org (Moritz Bunkus) Date: Sat, 28 Jun 2003 18:38:27 +0200 Subject: [matroska-devel] Re: b-frames In-Reply-To: <20030628123121.53768.qmail@web12906.mail.yahoo.com> References: <3EFD6FE8.6050409@free.fr> <20030628123121.53768.qmail@web12906.mail.yahoo.com> Message-ID: <20030628163827.GH1544@bunkus.org> Heya Steve & Cyrius, thanks for the explanation. That answers a lot of my questions, and I'll be able to continue working on the issue tomorrow or next week. I'll definitely have more questions, but I can answer them when they become apparent ;) -- ==> Ciao, Mosu (Moritz Bunkus) http://www.matroska.org From dave at leatherdale.net Sat Jun 28 20:35:33 2003 From: dave at leatherdale.net (David E Leatherdale) Date: Sat, 28 Jun 2003 19:35:33 +0100 Subject: [matroska-devel] Re: b-frames In-Reply-To: <20030628123121.53768.qmail@web12906.mail.yahoo.com> References: <3EFD6FE8.6050409@free.fr> <20030628123121.53768.qmail@web12906.mail.yahoo.com> Message-ID: you find an I frame - > I2 - as forward reference of a B frame, while it seems > generally it wouldn't happen - maybe I'm wrong here) > Forward ref I-frames are not normally used because of the limit of storing in an AVI used in matroska they should be perfectly valid. In fact to me this makes more sense then having to end the sequence with a P-frame and adding an I frame directly after especially for long sequences of B frames (as the p-frame will be predicted from a frame a long time before and so will be either lower quality or larger). Although i use the VFW GUI to configure the codec in avs2matroska im going to ignore the closed GOP settings as they make no sense in native files. DaveEL http://www.matroska.org From moritz at bunkus.org Sun Jun 29 19:29:52 2003 From: moritz at bunkus.org (Moritz Bunkus) Date: Sun, 29 Jun 2003 19:29:52 +0200 Subject: [matroska-devel] Re: b-frames In-Reply-To: References: <20030628123121.53768.qmail@web12906.mail.yahoo.com> Message-ID: <20030629172952.GL1544@bunkus.org> Hi. > Forward ref I-frames are not normally used because of the limit of > storing in an AVI used in matroska they should be perfectly valid. In > fact to me this makes more sense then having to end the sequence with a > P-frame and adding an I frame directly after especially for long > sequences of B frames (as the p-frame will be predicted from a frame a > long time before and so will be either lower quality or larger). This would mean that, when cutting a file, I'd have to include the I frame as the very last frame in the old file and as the very first frame in the second file. Wouldn't be too much problem... Yet another thing I have to remember :/ -- ==> Ciao, Mosu (Moritz Bunkus) http://www.matroska.org From steve.lhomme at free.fr Sun Jun 29 10:33:26 2003 From: steve.lhomme at free.fr (Steve Lhomme) Date: Sun, 29 Jun 2003 10:33:26 +0200 Subject: [matroska-devel] Re: b-frames In-Reply-To: <20030628123121.53768.qmail@web12906.mail.yahoo.com> References: <20030628123121.53768.qmail@web12906.mail.yahoo.com> Message-ID: <3EFEA456.4010803@free.fr> >>Yes and no. You can also have P frames with prio of >>0 because they are >>used the same as I frames in MPEG (for references). > > > One day someone told me I should read and follow the > specs instead of what he was saying (/me whistle). > So to remind you the specs : > > "ReferencePriority : This frame is referenced and has > the specified cache priority. In cache only a frame of > the same or higher priority can replace this frame. A > value of 0 means the frame is not referenced." > > So what does that mean ? Somewhat the contrary of what > both of you are saying here :p OK, you're right. The principle is the same only change a <= with a >= :) > First that B frames should have a priority of 0 since > they aren't referenced (it is the case in avs2matroska > Chris ;)), and that I and P frames would have a > priority of 1 or 2. No, that just proves what I said before : I and P frames need the same prio number, as it's how it's done in MPEG. Whoever wrote these specs, I love him ! (I spent the afternoon at the Gay Pride, so... ;) > Currently when there are only I and P frames nobody > uses priorities (why ? well maybe because using the > same priority number for each frame would be enough > since in this case we only need the previous decoded > frame - whatever it may be - to be able to decode the > next one if it isn't a new I frame, so setting all > frames to a priority of 1 would just be a waste of > space). Yes, it's not a problem, especially since they should have the same prio of 1. Theoretically a value of 0 for MinCache and prio of 0 would be OK. But not according to the specs. In a system where the caching is done out of the codec (as matroska is done) these 0 values may lead to a pb. None exist at the moment, but maybe one day... > There is still the question of what priorities to use. > Actually avs2matroska uses priorities of 0 for > B-frames (right, since they aren't referenced), and 2 > for the other frames). > Is this good ? Yes. > __________________________________ > Do you Yahoo!? NO ! http://www.matroska.org From rududuvideocodec at ifrance.com Sun Jun 29 20:46:48 2003 From: rududuvideocodec at ifrance.com (nicolas) Date: Sun, 29 Jun 2003 20:46:48 +0200 Subject: [matroska-devel] Re: b-frames In-Reply-To: <3EFD6FE8.6050409@free.fr> References: <20030628075847.GG1544@bunkus.org> <3EFD6FE8.6050409@free.fr> Message-ID: <3EFF3418.5070109@ifrance.com> Can I ask why you need to buffer compressed frames ? And what do you call "render" or "display" about the frames ? For me the demuxer is not directly connected to the renderer, and you can't render directly a compressed frame. Steve Lhomme wrote: >Moritz Bunkus wrote: > > >>Heya. >> >>Although I'm at home I'm still pondering the B frame handling. So here >>are some of my questions. >> >>1. Let's assume you have the typical sequence of IBP (display order?), >> timestamps 0, 40 and 80ms. In order to store that in Matroska WITH >> libmatroska I have to first AddFrame(I), then AddFrame(P, I) and then >> AddFrame(B, I, P). Otherwise I don't have the BlockGroup for the P >> frame that the AddFrame(B...) needs. Correct? So in a Matroska file >> the frames would be stored as IPB. >> >> > >Yes, in coding order. That's also probably the preferred way for the codec. > > > >>2. Reading those frames and refpriorities. For a file containing B >> frames I have a MinCache of 2. I frames have a prio of 0, P have 1 >> and B have a prio of 2. Correct? So let's take the example above. I >> >> > >Yes and no. You can also have P frames with prio of 0 because they are >used the same as I frames in MPEG (for references). > > > >> get the I frame and keep it. I get the P frame and keep it. Then I >> get the B frame. Now I'm happy and can deliver the frames in the >> order I want (either coding or display). >> >> Next example: display order IPBP which are stored as IPPB in the file >> according to my thoughts in 1. So I get the I frame, the first P >> frame which I both store. Now I get the second P frame. But which >> frame from the two stored frames can I discard? And how do I decide >> that? >> >> > >It should be actually 0 for P frames because it's supposed to replace an >I frame in the reference cache. With a value of 1 it can't replace in >cache an element with prio 0. > > > >>3. Multiple B frames. Is this possible? If yes, how do I handle that? >> Display order: IB1B2P. How will this be stored, what does the >> refprio/cache handling look like in this case? >> >>I guess that Steve will answer all this ;) Thanks in advance. >> >> > >display order : I1 B2 B3 P4 >coding order : I1 P4 B2 B3 (== matroska order) >I1 : prio 0 >P4 : prio 0 >B2 : prio 2 >B3 : prio 2 > >You have 2 elements in the cache, an element is rendered when it leaves >the cache... >I1 arrives : (I1, .) >P4 arrives : (I1, P4) >B2 arrives : it can't replace an element in the cache, so all previous >frames in the cache has to be rendered, ie I1 >(I1*, P4) and B2* (displayed) >B3 arrives : it can't replace.... >(I1*, P4) and B3* >P5 or I5 arrives : It has to replace an element in the cache >(P4, I5) > >etc until there is no more data and so you have to flush the cache in >display order. (I use an ordered list in the DSF, using std::map). > >I still haven't implemented the full system... (I have to fix my >lockings first), ie I keep everything in memory ;) > > >http://www.matroska.org >_____________________________________________________________________ >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://www.matroska.org From moritz at bunkus.org Sun Jun 29 20:54:51 2003 From: moritz at bunkus.org (Moritz Bunkus) Date: Sun, 29 Jun 2003 20:54:51 +0200 Subject: [matroska-devel] Re: b-frames In-Reply-To: <3EFF3418.5070109@ifrance.com> References: <20030628075847.GG1544@bunkus.org> <3EFD6FE8.6050409@free.fr> <3EFF3418.5070109@ifrance.com> Message-ID: <20030629185451.GO1544@bunkus.org> Hi. > Can I ask why you need to buffer compressed frames ? > And what do you call "render" or "display" about the frames ? > For me the demuxer is not directly connected to the renderer, and you > can't render directly a compressed frame. "Render" or "display" in this case refers to "handing the data to the next filter", most probably the video decoder. Not directly to the graphics card or something like that. -- ==> Ciao, Mosu (Moritz Bunkus) http://www.matroska.org From rududuvideocodec at ifrance.com Sun Jun 29 21:52:41 2003 From: rududuvideocodec at ifrance.com (nicolas) Date: Sun, 29 Jun 2003 21:52:41 +0200 Subject: [matroska-devel] Re: b-frames In-Reply-To: <20030629185451.GO1544@bunkus.org> References: <20030628075847.GG1544@bunkus.org> <3EFD6FE8.6050409@free.fr> <3EFF3418.5070109@ifrance.com> <20030629185451.GO1544@bunkus.org> Message-ID: <3EFF4389.6060609@ifrance.com> And what about my first question, what is the purpose of buffering the frames ? The frames are stored in coding order in matroska and the decoder needs the frames in this order, so you don't need to change the order... http://www.matroska.org From steve.lhomme at free.fr Sun Jun 29 23:45:55 2003 From: steve.lhomme at free.fr (Steve Lhomme) Date: Sun, 29 Jun 2003 23:45:55 +0200 Subject: [matroska-devel] Re: b-frames In-Reply-To: <3EFF4389.6060609@ifrance.com> References: <20030628075847.GG1544@bunkus.org> <3EFD6FE8.6050409@free.fr> <3EFF3418.5070109@ifrance.com> <20030629185451.GO1544@bunkus.org> <3EFF4389.6060609@ifrance.com> Message-ID: <3EFF5E13.2090005@free.fr> nicolas wrote: > And what about my first question, what is the purpose of buffering the > frames ? > The frames are stored in coding order in matroska and the decoder needs > the frames in this order, so you don't need to change the order... Because when the duration of a Block/Frame is not set, you need to know what is exactly the next frame to know the duration. At least in DirectShow. Other systems may not need it. So we need to know the display order at some point, even if we send the data in coding order. http://www.matroska.org From chris at matroska.org Sat Jun 28 15:49:17 2003 From: chris at matroska.org (Christian HJ Wiesner) Date: Sat, 28 Jun 2003 15:49:17 +0200 Subject: [matroska-devel] [Fwd: Re: Re: b-frames] Message-ID: <3EFD9CDD.7010405@matroska.org> Message from Dave .... -------- Original Message -------- Subject: Re: [matroska-devel] Re: b-frames Date: Sat, 28 Jun 2003 14:29:54 +0100 (BST) From: Dave Latherdal To: chris at matroska.org References: <20030628075847.GG1544 at bunkus.org> <3EFD6FE8.6050409 at free.fr> <3EFD7413.2040302 at matroska.org> Im not on the mailing list but take a look every now and then via the NNTP service. Reading through this i believe avs2matroska is doing everything the way it should, except according to the specs the referece priority should be the other way round with the b-frames have priority 0 and I/P having priority 2.("A value of 0 means the frame is not referenced.") So my code does it that way (i think, i don't have my code handy atm). Could you mention this to the right people please as either the specs need changing or the examples in this thread are wrong. DaveEL > Dave, > > are you subscribed to matroska-devel meanwhile ? did you respect this in > avs2matroska already ? > > Steve Lhomme wrote: > >>Moritz Bunkus wrote: >> >> >>>Heya. >>> >>>Although I'm at home I'm still pondering the B frame handling. So here >>>are some of my questions. >>> >>>1. Let's assume you have the typical sequence of IBP (display order?), >>> timestamps 0, 40 and 80ms. In order to store that in Matroska WITH >>> libmatroska I have to first AddFrame(I), then AddFrame(P, I) and then >>> AddFrame(B, I, P). Otherwise I don't have the BlockGroup for the P >>> frame that the AddFrame(B...) needs. Correct? So in a Matroska file >>> the frames would be stored as IPB. >>> >>> >> >>Yes, in coding order. That's also probably the preferred way for the >> codec. >> >> >> >>>2. Reading those frames and refpriorities. For a file containing B >>> frames I have a MinCache of 2. I frames have a prio of 0, P have 1 >>> and B have a prio of 2. Correct? So let's take the example above. I >>> >>> >> >>Yes and no. You can also have P frames with prio of 0 because they are >>used the same as I frames in MPEG (for references). >> >> >> >>> get the I frame and keep it. I get the P frame and keep it. Then I >>> get the B frame. Now I'm happy and can deliver the frames in the >>> order I want (either coding or display). >>> >>> Next example: display order IPBP which are stored as IPPB in the file >>> according to my thoughts in 1. So I get the I frame, the first P >>> frame which I both store. Now I get the second P frame. But which >>> frame from the two stored frames can I discard? And how do I decide >>> that? >>> >>> >> >>It should be actually 0 for P frames because it's supposed to replace an >>I frame in the reference cache. With a value of 1 it can't replace in >>cache an element with prio 0. >> >> >> >>>3. Multiple B frames. Is this possible? If yes, how do I handle that? >>> Display order: IB1B2P. How will this be stored, what does the >>> refprio/cache handling look like in this case? >>> >>>I guess that Steve will answer all this ;) Thanks in advance. >>> >>> >> >>display order : I1 B2 B3 P4 >>coding order : I1 P4 B2 B3 (== matroska order) >>I1 : prio 0 >>P4 : prio 0 >>B2 : prio 2 >>B3 : prio 2 >> >>You have 2 elements in the cache, an element is rendered when it leaves >>the cache... >>I1 arrives : (I1, .) >>P4 arrives : (I1, P4) >>B2 arrives : it can't replace an element in the cache, so all previous >>frames in the cache has to be rendered, ie I1 >>(I1*, P4) and B2* (displayed) >>B3 arrives : it can't replace.... >>(I1*, P4) and B3* >>P5 or I5 arrives : It has to replace an element in the cache >>(P4, I5) >> >>etc until there is no more data and so you have to flush the cache in >>display order. (I use an ordered list in the DSF, using std::map). >> >>I still haven't implemented the full system... (I have to fix my >>lockings first), ie I keep everything in memory ;) >> >> >>http://www.matroska.org >> >> >> > > http://www.matroska.org From moritz at bunkus.org Sat Jun 28 18:49:12 2003 From: moritz at bunkus.org (Moritz Bunkus) Date: Sat, 28 Jun 2003 18:49:12 +0200 Subject: [matroska-devel] changing #includes ? Message-ID: <20030628164912.GI1544@bunkus.org> Heya again, one thing that sam (vlc developer) asked me and that I couldn't really answer was: Why do we include all files directly? Meaning we have to '#include ' and don't '#include '. My guess is that on Windows it's simply done this way, but for Unix/Linux and all Unix-alike systems this is very unnatural as you always have to specify the include paths for those two directories: g++ -I/usr/include/ebml -I/usr/include/matroska ... This makes it harder to detect if libebml and libmatroska are installed on a system. Now why do I put them into such subdirectories in the first place? Two simple reasons: 1. We have so many include files that would clutter /usr/include. Keeping them in one subdir helps finding the right include file a lot. 2. There's an 'api' subdir for both libebml and libmatroska. This name is so fucking general that I'd never want it to be directly in /usr/include. "/usr/include/api" - what the hell is "api" for? (I know what it is for, but it's really ugly.) We could change that. It would involve some work, but not too much. Steps necessary to change it: 1. Change the CVS structure for both libebml and libmatroska. Rename 'src' to 'ebml' and 'matroska' would be enough, but this would have to be done on the cc.org server itself as CVS sucks badly when it comes to renaming files/directories. 2. Change the Makefiles (easy). 3. Change all #include statements in all files in the CVS and the user programs. This is where some work is involved, but again not overly much. I can automatically change all files in the CVS, and you other guys could simply replace "#include Ciao, Mosu (Moritz Bunkus) http://www.matroska.org From rbultje at ronald.bitfreak.net Sun Jun 29 11:15:46 2003 From: rbultje at ronald.bitfreak.net (Ronald Bultje) Date: 29 Jun 2003 11:15:46 +0200 Subject: [matroska-devel] Re: changing #includes ? In-Reply-To: <20030628164912.GI1544@bunkus.org> References: <20030628164912.GI1544@bunkus.org> Message-ID: <1056878146.2185.330.camel@shrek.bitfreak.net> Hey Moritz, On Sat, 2003-06-28 at 18:49, Moritz Bunkus wrote: > Why do we include all files directly? > > Meaning we have to '#include ' and don't '#include > '. My guess is that on Windows it's simply done this > way, but for Unix/Linux and all Unix-alike systems this is very > unnatural as you always have to specify the include paths for those two > directories: > > g++ -I/usr/include/ebml -I/usr/include/matroska ... It's not that easy. ;). Installing include files in the direct system include path is something you should prevent as much as possible. Think of glib-2.0 ($(includedir) = /usr/include/glib-2.0/), etc. The reason is that this allows you to install different versions without having the chance that one of them will be chosen while you wanted another one (possibly because the include path for the previous one was also given by the include path of another dependency library), since you always have to indicate the specific include path for this installed version. So no, I'd recommend to keep it in a subdir of $prefix/include/, not in $prefix/include/ directly. I do think that it'd be a good idea if there was one generic include file, like Kax.h, which included all the other .h files. That'd make app developer's life a lot easier already. :). Ronald -- Ronald Bultje Linux Video/Multimedia developer http://www.matroska.org From moritz at bunkus.org Sun Jun 29 16:32:10 2003 From: moritz at bunkus.org (Moritz Bunkus) Date: Sun, 29 Jun 2003 16:32:10 +0200 Subject: [matroska-devel] Re: changing #includes ? In-Reply-To: <1056878146.2185.330.camel@shrek.bitfreak.net> References: <20030628164912.GI1544@bunkus.org> <1056878146.2185.330.camel@shrek.bitfreak.net> Message-ID: <20030629143210.GJ1544@bunkus.org> Hi. > It's not that easy. ;). Installing include files in the direct system > include path is something you should prevent as much as possible. That's why I put them into ${prefix}/include/ebml and ${prefix}/include/matroska in the first place. > Think > of glib-2.0 ($(includedir) = /usr/include/glib-2.0/), etc. The reason is > that this allows you to install different versions without having the > chance that one of them will be chosen while you wanted another one > (possibly because the include path for the previous one was also given > by the include path of another dependency library), since you always > have to indicate the specific include path for this installed version. Sure, that'd be /usr/include/matroska-1.0/ebml /usr/include/matroska-1.0/matroska for example. > So no, I'd recommend to keep it in a subdir of $prefix/include/, not in > $prefix/include/ directly. I want to do that!!! You misunderstood me. At the moment the files are put into /usr/local/include/ebml, /usr/local/include/matroska. The problem is that the include files themselves don't have that ebml/ or matroska/ prefix, e.g. #include and not #include That's what I'd like to change. > I do think that it'd be a good idea if there was one generic include > file, like Kax.h, which included all the other .h files. That'd make app > developer's life a lot easier already. :). That'd be cool as well, and it's easy to do, but it's an additional request that I'd make. It'd have to be "#include " or something like that, and maybe "#include ". -- ==> Ciao, Mosu (Moritz Bunkus) http://www.matroska.org From chris at matroska.org Sun Jun 29 01:16:51 2003 From: chris at matroska.org (Christian HJ Wiesner) Date: Sun, 29 Jun 2003 01:16:51 +0200 Subject: [matroska-devel] Playing 'native' MPEG4 matroska files with ffdshow Message-ID: <3EFE21E3.2090406@matroska.org> Hi all, Hi Dave, Hi Milan, some of you may be aware that i was testing DaveEL's avs2matroska on a very long movie recently, namely on the starwars EP2 VOBs i happen to have on my HDD still. It worked great, both passes completed fine, i had to change the XviD codec settings from VirtualdubMod ( avs2matroska takes the setting from the XviD registry then ), but that was not a problem at all. Now the surprise : The file generated on 1st pass ( XviD is using q=2 for every frame as you know, just to write the stats file ) played fine on both of my PCs, both with mkxds.dll 0.4.3 installed and latest ffdshow-alpha. Great work from Toff, who mapped the native matroska codec IDs to FourCC 'mp4v' as used by 3ivX MP4 splitter filter also. This makes sense, as there is no real difference between a native file and an AVI compatibility file if no b-frames are used, and thats the case for the file created on 1st pass. The final file from 2nd pass, with max. 2 b-frames enabled, would not work as well, it would hang on certain frames and display it, until all of a sudden after a few seconds another frame would be displayed. I am not sure if this is only resyncing on I frames, because in practice i would estimate that there are more I frames, but i may be wrong. In any case, we expected this to happen because of the wrong timestamps given from our filter to ffdshow. Now the real good news : I tested Steve's latest experimental filter ( http://matroska.free.fr/downloads/mkxds-testmp4.zip ) on this file and with it and latest ffdshow-alpha from 23rd may both files play perfect, even the one with b-frames !!!! Every player i tested would crash on seeking, but i am not sure if this would be caused by a bad or missing metaseek/CUE table in the file created by avs2matroska, or if its a result of the DShow problems Steve had to face when coding the filter. In any case, great work guys !!! I am not sure if there still is a need to bug milan about any changes in ffdshow, as i guess Steve adapted the timestamp handling in our DShow parser such that it matches with current ffdshow behaviour for MP4 streams. Steve, if you only did this as a contemporary solution to be able to play the files, pls tell me, because i will try to talk to Milan again, so we could launch the test sample with a working and future proof parser and ffdshow, even if this will mean we have to wait much much longer for that. If mf doesnt hurry up, and Mosu makes mkvmerge aware native files with b-frames so i can mux audio to it and cut out a small sample, we can maybe launch the native Starwars sample i am preparing ( with 2 AAC 5.1, 1 Vorbis, 13 SRT and 2 SSA subs streams, anamorphic 1:2,35, all the matroska Goodies ;-) ) sooner than his long awaited matrix reloaded sample trailer :-) ..... Christian http://www.matroska.org From steve.lhomme at free.fr Sun Jun 29 10:52:19 2003 From: steve.lhomme at free.fr (Steve Lhomme) Date: Sun, 29 Jun 2003 10:52:19 +0200 Subject: [matroska-devel] Re: Playing 'native' MPEG4 matroska files with ffdshow In-Reply-To: <3EFE21E3.2090406@matroska.org> References: <3EFE21E3.2090406@matroska.org> Message-ID: <3EFEA8C3.10605@free.fr> Christian HJ Wiesner wrote: > Every player i tested would crash on seeking, but i am not sure if this > would be caused by a bad or missing metaseek/CUE table in the file > created by avs2matroska, or if its a result of the DShow problems Steve > had to face when coding the filter. In any case, great work guys !!! I > am not sure if there still is a need to bug milan about any changes in > ffdshow, as i guess Steve adapted the timestamp handling in our DShow > parser such that it matches with current ffdshow behaviour for MP4 > streams. Steve, if you only did this as a contemporary solution to be > able to play the files, pls tell me, because i will try to talk to Milan > again, so we could launch the test sample with a working and future > proof parser and ffdshow, even if this will mean we have to wait much > much longer for that. No I didn't make any trick in the experimental filter. Each frames have its correct display order that should be used on the output of the filter. I'm surprised it works for you, as it didn't for me (maybe I need to check something in FFDShow). http://www.matroska.org From suiryc at yahoo.com Sun Jun 29 02:33:34 2003 From: suiryc at yahoo.com (Cyrius) Date: Sat, 28 Jun 2003 17:33:34 -0700 (PDT) Subject: [matroska-devel] Fwd: Re: [UCI-Devel] Re: the road to 1.0 and beyond Message-ID: <20030629003334.86426.qmail@web12902.mail.yahoo.com> --- Toby Hudon wrote: > From: "Toby Hudon" > To: uci-devel at lists.sourceforge.net > Subject: Re: [UCI-Devel] Re: the road to 1.0 and > beyond > Date: Sat, 28 Jun 2003 13:44:10 -0500 Well you know my position, I wanna start from scratch with an ultra-simple but extensible API. Been kinda busy with work though. Anyone want to help? __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com http://www.matroska.org From suiryc at yahoo.com Sun Jun 29 02:36:05 2003 From: suiryc at yahoo.com (Cyrius) Date: Sat, 28 Jun 2003 17:36:05 -0700 (PDT) Subject: [matroska-devel] Fwd: Re: [UCI-Devel] Re: Common Opensource codec API Message-ID: <20030629003605.46801.qmail@web12906.mail.yahoo.com> --- Toby Hudon wrote: > From: "Toby Hudon" > To: uci-devel at lists.sourceforge.net > Subject: Re: [UCI-Devel] Re: Common Opensource codec > API > Date: Sat, 28 Jun 2003 13:51:23 -0500 > ----- Original Message ----- > From: Ronald Bultje > Date: 27 Jun 2003 15:13:14 +0200 > To: bartscgr at ra.informatik.uni-stuttgart.de > Subject: [UCI-Devel] Re: Common Opensource codec API > > What I'd love to see is the codec API not being an > actual lib, but just > a protocol, like X. Each application can then > write it's own > implementation code for this, and the codec API > can, if wanted, provide > a header file describing all structs (if any) etc. > used in the protocol. > Tying ourselves to one and the same lib likely > won't work, even now > we're already reproducing so much of the same > code... Do people agree > with this? I was working with this kind of design before, but nobody seemed interested in doing it. Basicly the language of the API layer is immaterial, what matters is the messages and data getting passed through it (my system used a message/struct 2 parameter function for everything). If you set up all the data as XML-like structs with messages that tell you what you're expecting to see I think it can be done language and platform independant at the same time. Yes there will be some bloat from the ID overhead, but as long as you're passing frames and not say, individual pixels, it should be ok. There's no reason you can't pass video frames, config info, etc basicly as XML documents through an API designed to handle them. __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com http://www.matroska.org From in7y118 at public.uni-hamburg.de Sun Jun 29 22:08:32 2003 From: in7y118 at public.uni-hamburg.de (Benjamin Otte) Date: Sun, 29 Jun 2003 22:08:32 +0200 (DFT) Subject: [matroska-devel] Re: [gst-devel] Fwd: Re: [UCI-Devel] Re: Common Opensource codec API In-Reply-To: <20030629003605.46801.qmail@web12906.mail.yahoo.com> Message-ID: On Sat, 28 Jun 2003, Cyrius wrote: > I was working with this kind of design before, but > nobody seemed interested in doing it. Basicly the > language of the API layer is immaterial, what > matters is the messages and data getting passed > through it (my system used a message/struct 2 > parameter function for everything). If you set up > all the data as XML-like structs with messages that > tell you what you're expecting to see I think it can > be done language and platform independant at the > same time. Yes there will be some bloat from the ID > overhead, but as long as you're passing frames and > not say, individual pixels, it should be ok. There's > no reason you can't pass video frames, config info, > etc basicly as XML documents through an API designed > to handle them. > So we basically wrap this in CORBA then? ;) Seriously: We need a simple little set of functions that a plugin needs to implement. If it is not dead simple, nobody will implement it. That was the important part: If it is not dead simple, nobody will implement it. And that goes for apps _and_ plugins. Benjamin http://www.matroska.org From bartscgr at t-online.de Sun Jun 29 23:36:52 2003 From: bartscgr at t-online.de (Guenter Bartsch) Date: Sun, 29 Jun 2003 23:36:52 +0200 Subject: [matroska-devel] Re: [xine-devel] Re: [gst-devel] Fwd: Re: [UCI-Devel] Re: Common Opensource codec API In-Reply-To: References: <20030629003605.46801.qmail@web12906.mail.yahoo.com> Message-ID: <20030629213651.GA17101@goofy.disney.gb> hallo benjamin, > > I was working with this kind of design before, but > > nobody seemed interested in doing it. Basicly the > > language of the API layer is immaterial, what > > matters is the messages and data getting passed > > through it (my system used a message/struct 2 > > parameter function for everything). If you set up > > all the data as XML-like structs with messages that > > tell you what you're expecting to see I think it can > > be done language and platform independant at the > > same time. Yes there will be some bloat from the ID > > overhead, but as long as you're passing frames and > > not say, individual pixels, it should be ok. There's > > no reason you can't pass video frames, config info, > > etc basicly as XML documents through an API designed > > to handle them. > > > So we basically wrap this in CORBA then? ;) *lol* ... yeah, overengineering seems to be quite common in those "do-the-right-thing-fixed-forever-joined-effort" style aproaches :> > Seriously: We need a simple little set of functions that a plugin needs to > implement. If it is not dead simple, nobody will implement it. > That was the important part: If it is not dead simple, nobody will > implement it. And that goes for apps _and_ plugins. my point exactly. this is just about defining simple, easy-to-use apis for various multimedia plugins/modules. i too think we should just define a basic set of functions which each plugin type should support, not more. the api should be extensible, though - both, individual implementations should be able to add fields and functions as well as there should be a possibility to add (probably optional) functions to the api in the future over the weekend i have looked through mplayer g2's and xine's stream/input and demux module apis and found them to be quite similar - it should definitely be possible to define a common interface here. i'm planning to set up a little website documenting the two aproaches, maybe i'll also look at other media players (not sure how many aproaches i'll be able to keep in my mind simultaneously ;) ). hope this will be a good starting point for a common api guenter -- "Voraussagen sind ausserordentlich schwierig, vor allem solche ueber die Zukunft." (N. Bohr) http://www.matroska.org From leif at ambient.2y.net Mon Jun 30 18:53:36 2003 From: leif at ambient.2y.net (Leif Johnson) Date: Mon, 30 Jun 2003 12:53:36 -0400 Subject: [matroska-devel] Re: [xine-devel] Re: [gst-devel] Re: [UCI-Devel] Re: Common Opensource codec API In-Reply-To: <20030629213651.GA17101@goofy.disney.gb> References: <20030629003605.46801.qmail@web12906.mail.yahoo.com> <20030629213651.GA17101@goofy.disney.gb> Message-ID: <20030630165336.GA21037@microfridge> You all might find some inspiration in LADSPA, a pretty nice audio plugin API hammered out on the linux-audio-dev mailing list : http://ladspa.org/. It's written for audio plugins only, but I thought some of the concepts might be helpful for more generic types of plugins. leif On Sun, 29 Jun 2003, Guenter Bartsch wrote: > hallo benjamin, > > > > I was working with this kind of design before, but > > > nobody seemed interested in doing it. Basicly the > > > language of the API layer is immaterial, what > > > matters is the messages and data getting passed > > > through it (my system used a message/struct 2 > > > parameter function for everything). If you set up > > > all the data as XML-like structs with messages that > > > tell you what you're expecting to see I think it can > > > be done language and platform independant at the > > > same time. Yes there will be some bloat from the ID > > > overhead, but as long as you're passing frames and > > > not say, individual pixels, it should be ok. There's > > > no reason you can't pass video frames, config info, > > > etc basicly as XML documents through an API designed > > > to handle them. > > > > > So we basically wrap this in CORBA then? ;) > > *lol* ... yeah, overengineering seems to be quite common in those > "do-the-right-thing-fixed-forever-joined-effort" style aproaches :> > > > Seriously: We need a simple little set of functions that a plugin needs to > > implement. If it is not dead simple, nobody will implement it. > > That was the important part: If it is not dead simple, nobody will > > implement it. And that goes for apps _and_ plugins. > > my point exactly. this is just about defining simple, easy-to-use apis > for various multimedia plugins/modules. i too think we should just > define a basic set of functions which each plugin type should support, > not more. the api should be extensible, though - both, individual > implementations should be able to add fields and functions as well as > there should be a possibility to add (probably optional) functions > to the api in the future > > over the weekend i have looked through mplayer g2's and xine's stream/input > and demux module apis and found them to be quite similar - it should > definitely be possible to define a common interface here. i'm planning > to set up a little website documenting the two aproaches, maybe i'll > also look at other media players (not sure how many aproaches i'll be > able to keep in my mind simultaneously ;) ). hope this will be a good > starting point for a common api > > guenter -- Leif Morgan Johnson : http://ambient.2y.net/leif/ http://www.matroska.org From suiryc at yahoo.com Sun Jun 29 02:38:03 2003 From: suiryc at yahoo.com (Cyrius) Date: Sat, 28 Jun 2003 17:38:03 -0700 (PDT) Subject: [matroska-devel] Fwd: Re: [UCI-Devel] Re: Re: Common Opensource codec API Message-ID: <20030629003803.47011.qmail@web12906.mail.yahoo.com> --- Toby Hudon wrote: > From: "Toby Hudon" > To: uci-devel at lists.sourceforge.net > Subject: Re: [UCI-Devel] Re: [matroska-devel] Re: > Common Opensource codec API > Date: Sat, 28 Jun 2003 13:56:33 -0500 > ----- Original Message ----- > From: ChristianHJW > Date: Sat, 28 Jun 2003 16:35:45 +0200 > To: matroska-devel at freelists.org > Subject: [UCI-Devel] Re: [matroska-devel] Re: Common > Opensource codec API > > BBB, can you invest a couple of hours and come up > with a small doc > describing such a protocol, so it could be > discussed on the lists that > have been involved and were expressing interest in > such a solution ? > I can do this if you wanna hear about my design. I still have most of it around. > > >And just to state clearly: our final goal is to > propose a standardized > > >API or interface of how codecs, muxer/demuxer > libraries etc. should look > > >to be usable by our applications. It is not to > define how a bytestream > > >should look. ;). Just so I (and you) know what > we're actually talking > > >about. > > > > > Alex had the following plans for UCI : > > > > UCI : codec API > > UFI : filter API > > UMI : muxing API, so that various containers could > be used from > > supporting apps > > See I think the different operations like filters and muxing should just be subsets of the message space. Because a filter is going to have some redundant use with a codec, such as getting/recieving frames, colorspace conversion, etc. It makes sense to just have them all share the same functions, and just restrict which messages/structs are valid to send to a given object based on if it's a filter or a codec or whatever. General type objects could accept any message, etc. One of the reasons I was advocating a system with 2-way communication at each level was to do things like have an app request an operation that a filter does not support, and have the filter propose an alternate operation by calling back other parts of the system for more info. Thus programmers would be free to do what they think is best for their code to serve each message request. __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com http://www.matroska.org From rbultje at ronald.bitfreak.net Mon Jun 30 09:23:19 2003 From: rbultje at ronald.bitfreak.net (Ronald Bultje) Date: 30 Jun 2003 09:23:19 +0200 Subject: [matroska-devel] Re: [gst-devel] Fwd: Re: [UCI-Devel] Re: Re: Common Opensource codec API In-Reply-To: <20030629003803.47011.qmail@web12906.mail.yahoo.com> References: <20030629003803.47011.qmail@web12906.mail.yahoo.com> Message-ID: <1056913500.2531.351.camel@shrek.bitfreak.net> Hey, On Sun, 2003-06-29 at 02:38, Cyrius wrote: > See I think the different operations like filters > and muxing should just be subsets of the message > space. This was my idea exactly. The muxing/codec operation subsets themselves should be described in the protocol, too, but shouldn't introduce any new features or methods, they should just implement a specific way of using the generalized methods for their specific task. > One of the reasons I was advocating a system with > 2-way communication at each level was to do things > like have an app request an operation that a filter > does not support, and have the filter propose an > alternate operation by calling back other parts of > the system for more info. Thus programmers would be > free to do what they think is best for their code to > serve each message request. Let's first keep it simple. ;). Ronald -- Ronald Bultje http://www.matroska.org From gldm at mail.com Mon Jun 30 20:48:01 2003 From: gldm at mail.com (Toby Hudon) Date: Mon, 30 Jun 2003 13:48:01 -0500 Subject: [matroska-devel] Re: [gst-devel] Fwd: Re: [UCI-Devel] Re: Common Opensource codec API Message-ID: <20030630184802.44092.qmail@mail.com> ----- Original Message ----- From: Benjamin Otte Date: Sun, 29 Jun 2003 22:08:32 +0200 (DFT) To: Cyrius Subject: Re: [gst-devel] Fwd: Re: [UCI-Devel] Re: Common Opensource codec API > On Sat, 28 Jun 2003, Cyrius wrote: > > I was working with this kind of design before, but > > nobody seemed interested in doing it. Basicly the > > language of the API layer is immaterial, what > > matters is the messages and data getting passed > > through it (my system used a message/struct 2 > > parameter function for everything). If you set up > > all the data as XML-like structs with messages that > > tell you what you're expecting to see I think it can > > be done language and platform independant at the > > same time. Yes there will be some bloat from the ID > > overhead, but as long as you're passing frames and > > not say, individual pixels, it should be ok. There's > > no reason you can't pass video frames, config info, > > etc basicly as XML documents through an API designed > > to handle them. > > > So we basically wrap this in CORBA then? ;) > > Seriously: We need a simple little set of functions that a plugin needs to > implement. If it is not dead simple, nobody will implement it. > That was the important part: If it is not dead simple, nobody will > implement it. And that goes for apps _and_ plugins. > > Benjamin > Is one function simple enough? ;) Seriously, do(UINT msg, pDOC data); That's it. Internal switch on the message to handle the data if needed. If you don't support a given message in the API, you go to the default case which is return(0). Whoever called you has the job of handling an unexpected return(0), such as trying an alternate method, and if they can't they also return(0) and pass it up the call stack until it gets to the application, which either decides to try something else or returns a message saying not supported or error or whatever is appropriate. All components (by component I mean a generic object for the API that can be a container, filter, codec, muxer, etc) support this one function. The only other function in the entire API so far is the function to create a component based on information. I.e. the application sees it needs a codec to handle "XVID" output from the container component it just made. It performs a lookup (I'm still working on the exact details of how best to do it) and finds that it points to a DLL that handles this. It then calls an API function that creates the component associated with that dll, i.e. Component my_decoder = CreateComponent("xvid_x86.dll"); That's it, two functions. The complicated part is in defining the messages and their data, but as long as each component is only required to support the messages it can do something with, and not handle exceptions, it should be easy for component developers. If you have a simpler idea please let me know, and BTW what is CORBA? -- __________________________________________________________ Sign-up for your own FREE Personalized E-mail at Mail.com http://www.mail.com/?sr=signup http://www.matroska.org From rbultje at ronald.bitfreak.net Mon Jun 30 23:17:44 2003 From: rbultje at ronald.bitfreak.net (Ronald Bultje) Date: 30 Jun 2003 23:17:44 +0200 Subject: [matroska-devel] Re: [gst-devel] Fwd: Re: [UCI-Devel] Re: Common Opensource codec API In-Reply-To: <20030630184802.44092.qmail@mail.com> References: <20030630184802.44092.qmail@mail.com> Message-ID: <1057007863.1270.76.camel@localhost.localdomain> Hey Toby, On Mon, 2003-06-30 at 20:48, Toby Hudon wrote: > Is one function simple enough? ;) > > Seriously, do(UINT msg, pDOC data); That's it. Internal switch > on the message to handle the data if needed. If you don't support a > given message in the API, you go to the default case which is > return(0). Whoever called you has the job of handling an unexpected > return(0), such as trying an alternate method, and if they can't > they also return(0) and pass it up the call stack until it gets to > the application, which either decides to try something else or > returns a message saying not supported or error or whatever is > appropriate. The only thing that this solves is the API linking issue. And that's not an issue anyway if we're going to define a standard API. > That's it, two functions. The complicated part is in defining > the messages and their data, but as long as each component is only > required to support the messages it can do something with, and not > handle exceptions, it should be easy for component developers. But that's the whole issue, the messages. You're just moving the problem over from linkage space to message space. The problem here is actually to define how all this works. ;). Funnily, you're taking XVID as an example, but xvid is horrible. Look at the API. There's one struct per message. No extendibility. No configurability. Perfect for a one-task API, but not at all usable for a generic API. GStreamer (GObject)'s way of defining all this is easier. Make name/value pairs, make a standard doc that describes which types support what base properties. Since there's no limit on name/value pairs, there's no limit in extendibility. Making this two-way allows the application to view these properties, too. And, even better, this method doesn't depend on GStreamer or GObject at all. GStreamer just implements it in that specific way. The good thing of your approach is actually its simplicity, and I like that. However, I wouldn't vote for sticking to one function, since that only moves the definition problem over from linkage space to message space, and that has no advantage, imho. However, the idea of using as little functions as possible up to a certain amount sounds good, I'll try sticking to that. :). > If you have a simpler idea please let me know, and BTW what is > CORBA? Something like COM, but for Unix/Linux. Ronald PS Christian, you've asked me to come up with a document, I'll try to do that in the course of this week. Give me a few days, I have a job, too. ;). I'll take some ideas from the list and mix them together with some of my own. -- Ronald Bultje http://www.matroska.org From gldm at mail.com Mon Jun 30 20:51:50 2003 From: gldm at mail.com (Toby Hudon) Date: Mon, 30 Jun 2003 13:51:50 -0500 Subject: [matroska-devel] Re: [gst-devel] Fwd: Re: [UCI-Devel] Re: Re: Common Opensource codec API Message-ID: <20030630185151.47171.qmail@mail.com> ----- Original Message ----- From: Ronald Bultje Date: 30 Jun 2003 09:23:19 +0200 To: Cyrius Subject: Re: [gst-devel] Fwd: Re: [UCI-Devel] Re: [matroska-devel] Re: Common Opensource codec API > Hey, > > On Sun, 2003-06-29 at 02:38, Cyrius wrote: > > See I think the different operations like filters > > and muxing should just be subsets of the message > > space. > > This was my idea exactly. The muxing/codec operation subsets themselves > should be described in the protocol, too, but shouldn't introduce any > new features or methods, they should just implement a specific way of > using the generalized methods for their specific task. > > > One of the reasons I was advocating a system with > > 2-way communication at each level was to do things > > like have an app request an operation that a filter > > does not support, and have the filter propose an > > alternate operation by calling back other parts of > > the system for more info. Thus programmers would be > > free to do what they think is best for their code to > > serve each message request. > > Let's first keep it simple. ;). > > Ronald > > -- > Ronald Bultje > The main idea was to keep it simple. The problem is when you make everything one-way like VFW it becomes not simple to do certain things. I had simplicity as the main goal in mind when thinking this through. -- __________________________________________________________ Sign-up for your own FREE Personalized E-mail at Mail.com http://www.mail.com/?sr=signup http://www.matroska.org From gldm at mail.com Mon Jun 30 20:53:31 2003 From: gldm at mail.com (Toby Hudon) Date: Mon, 30 Jun 2003 13:53:31 -0500 Subject: [matroska-devel] Re: [xine-devel] Re: [gst-devel] Re: [UCI-Devel] Re: Common Opensource codec API Message-ID: <20030630185332.49209.qmail@mail.com> ----- Original Message ----- From: Leif Johnson Date: Mon, 30 Jun 2003 12:53:36 -0400 To: bartscgr at ra.informatik.uni-stuttgart.de Subject: Re: [xine-devel] Re: [gst-devel] Re: [UCI-Devel] Re: Common Opensource codec API > You all might find some inspiration in LADSPA, a pretty nice audio plugin > API hammered out on the linux-audio-dev mailing list : http://ladspa.org/. > It's written for audio plugins only, but I thought some of the concepts > might be helpful for more generic types of plugins. > > leif > Sorry I'm not a linux user so I probably wouldn't be able to do much with it. Can you give me a quick overview? -- __________________________________________________________ Sign-up for your own FREE Personalized E-mail at Mail.com http://www.mail.com/?sr=signup http://www.matroska.org