From jcsston at wiesneronline.net Sun Feb 1 17:20:54 2004 From: jcsston at wiesneronline.net (Jory) Date: Sun, 1 Feb 2004 10:20:54 -0600 Subject: [Matroska-devel] Using GStreamer with TCME Message-ID: <001901c3e8df$6f131b20$0200a8c0@jcsston> Hi all, In GStreamer there is a feature to save the pipeline (graph in DShow) to XML. As I read the source code, the XML file also has all the settings set on the elements (filters in DShow) saved too. With this I think we could build a script parser that would convert an AviSynth-like script into a XML file that GStreamer could load. (Anyone want to rip out the script parser from AviSynth?) Here is how I see GStreamer working as an encoder. (video only, audio would make the graph/pipeline more complex than ASCII allows) AVIDemux -> Trimmer* -> Raw Splitter* -> IVTC* -> ... \->Video1 Render* ... Noise Reduction* -> Crop* -> Resize* ... -> XviD Encoder* -> Raw Splitter* -> Matroska Muxer (I:\voyager.mkv) \-> XviD Decoder* -> Video2 Render* In this the Video1 Render is the input preview, and Video2 is the decompressed output preview. The *'s filters will need to be written Filters we may need: Color Conversion (ASM code from AviSynth/XviD could be used) Deinterlacing/IVTC (port Decomb?) Noise Filters Cropping Resizing (Bilinear, Bicubic, Lanzcos) XviD En/Decoder VFW Wrapper En/Decoder (Win32 only) AviSynth Filter Wrapper (Win32 only, may be too complex to be really useful) Raw Splitter (sends copies of the input to each output pad) Video Render (Win32 only, DirectDraw) Audio Render (Win32 only, DirectSound) So far, GStreamer looks the way to go. The only area I don't know about GStreamer yet is how it handles seeking and what type of timestamps it uses. But, I'm sure it can be adopted/expanded if those areas are not good enough for us. I have been thinking way too much recently ;) Somebody stop me, Jory From chris at matroska.org Mon Feb 2 09:01:48 2004 From: chris at matroska.org (Christian HJ Wiesner) Date: Mon, 02 Feb 2004 09:01:48 +0100 Subject: [Matroska-devel] Using GStreamer with TCME In-Reply-To: <001901c3e8df$6f131b20$0200a8c0@jcsston> References: <001901c3e8df$6f131b20$0200a8c0@jcsston> Message-ID: <401E03EC.6020904@matroska.org> Jory wrote: >Hi all, > >In GStreamer there is a feature to save the pipeline (graph in DShow) to >XML. As I read the source code, the XML file also has all the settings set >on the elements (filters in DShow) saved too. With this I think we could >build a script parser that would convert an AviSynth-like script into a XML >file that GStreamer could load. (Anyone want to rip out the script parser >from AviSynth?) >I have been thinking way too much recently ;) >Somebody stop me, Jory > I wont :-) ..... great work Jory ! As i understand it, Cyrius and Toff are not opposed to the idea to use gstreamer for the editor, and it seems to be possible also. Are there any other opinions on that ? Mosu ? spyder ? Pamel ? Make yourself heard guys :-D ... Christian From paul at msn.com Mon Feb 2 11:38:09 2004 From: paul at msn.com (Paul Bryson) Date: Mon, 2 Feb 2004 04:38:09 -0600 Subject: [Matroska-devel] Re: Using GStreamer with TCME References: <001901c3e8df$6f131b20$0200a8c0@jcsston> <401E03EC.6020904@matroska.org> Message-ID: "Christian HJ Wiesner" wrote... > As i understand it, Cyrius and Toff are not opposed to the idea to use > gstreamer for the editor, and it seems to be possible also. Are there > any other opinions on that ? Mosu ? spyder ? Pamel ? Make yourself heard > guys :-D ... I think that it is clear that everyone is simply looking for the easiest way to accomplish the goals. To use GStreamer, it must first be ported to Win32. If that can be done, then it is possible. There are also some other already-free non-linear editors that have been mentioned. These need to be looked at to see if they could be ported to Win32. Whatever is easiest. Pamel From spyder at matroska.org Mon Feb 2 03:00:04 2004 From: spyder at matroska.org (John Cannon) Date: Sun, 01 Feb 2004 20:00:04 -0600 Subject: [Matroska-devel] Re: Using GStreamer with TCME In-Reply-To: References: <001901c3e8df$6f131b20$0200a8c0@jcsston> <401E03EC.6020904@matroska.org> Message-ID: <401DAF24.9060207@matroska.org> Paul Bryson wrote: >"Christian HJ Wiesner" wrote... > > > >>As i understand it, Cyrius and Toff are not opposed to the idea to use >>gstreamer for the editor, and it seems to be possible also. Are there >>any other opinions on that ? Mosu ? spyder ? Pamel ? Make yourself heard >>guys :-D ... >> >> > >I think that it is clear that everyone is simply looking for the easiest way to >accomplish the goals. To use GStreamer, it must first be ported to Win32. If >that can be done, then it is possible. There are also some other already-free >non-linear editors that have been mentioned. These need to be looked at to see >if they could be ported to Win32. Whatever is easiest. > > >Pamel > > > >_______________________________________________ >Matroska-devel mailing list >Matroska-devel at lists.matroska.org >http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel > > > Gstreamer sounds good :) I will try to port decomb once we are to that stage. I have worked a good bit with the code before... though it was4.x not the 5.x series :) John From rbultje at ronald.bitfreak.net Mon Feb 2 21:40:17 2004 From: rbultje at ronald.bitfreak.net (Ronald S. Bultje) Date: Mon, 02 Feb 2004 21:40:17 +0100 Subject: [Matroska-devel] Using GStreamer with TCME In-Reply-To: <001901c3e8df$6f131b20$0200a8c0@jcsston> References: <001901c3e8df$6f131b20$0200a8c0@jcsston> Message-ID: <1075754417.14656.5.camel@shrek.bitfreak.net> Hi, I'll be gone for a few months (study), but will try to answer emails once in a while... Here goes. On Sun, 2004-02-01 at 17:20, Jory wrote: > Here is how I see GStreamer working as an encoder. (video only, audio would > make the graph/pipeline more complex than ASCII allows) > AVIDemux -> Trimmer* -> Raw Splitter* -> IVTC* -> ... > \->Video1 > Render* > > ... Noise Reduction* -> Crop* -> Resize* > ... -> XviD Encoder* -> Raw Splitter* -> Matroska Muxer (I:\voyager.mkv) > \-> XviD > Decoder* -> Video2 Render* > > In this the Video1 Render is the input preview, and Video2 is the > decompressed output preview. > > The *'s filters will need to be written Ehm, we really have most of these. We have matroska muxers, xvid encoders, video scalers, etc. I don't know what a splitter is, but we probably have that too. > Color Conversion (ASM code from AviSynth/XviD could be used) We have that, from ffmpeg. It's well optimized. > Deinterlacing/IVTC (port Decomb?) I have that in mjpegtools, GStreamer port is pending. > Noise Filters Same. > Cropping > Resizing (Bilinear, Bicubic, Lanzcos) > XviD En/Decoder We have those. > VFW Wrapper En/Decoder (Win32 only) > AviSynth Filter Wrapper (Win32 only, may be too complex to be really useful) [..] > Raw Splitter (sends copies of the input to each output pad) Tee, we have that. > Video Render (Win32 only, DirectDraw) > Audio Render (Win32 only, DirectSound) Those need to be written, yes. That's the work for the win32 port. :). Ronald -- Ronald Bultje Linux Video/Multimedia developer From moritz at bunkus.org Mon Feb 2 23:36:05 2004 From: moritz at bunkus.org (Moritz Bunkus) Date: Mon, 2 Feb 2004 23:36:05 +0100 Subject: [Matroska-devel] tcme and stuff Message-ID: <20040202223605.GA3530@bunkus.org> Heya, maybe you're wondering why I'm so silent at the moment - well, the hot phase of my diploma thesis has begun, and it'll take until at least middle of March. I won't be any help during that period, I'm afraid. I don't have much time for other things besides diploma thesis and doing stuff for my company. For what it's worth: gstreamer is a good choice, of course. We could then write our own file reader/writer plugins with our own API (we cannot use gstream for that, of course, as it gives far too few details - just think about track languages, chapters, stuff...). Place a GUI on top of that and we have at least a prototype. Of course there's still the question of the 'scripting language'... What I probably can do is draft some API for the readers. But all the work I WILL be able to do will be on weekends. Mosu -- If Darl McBride was in charge, he'd probably make marriage unconstitutional too, since clearly it de-emphasizes the commercial nature of normal human interaction, and probably is a major impediment to the commercial growth of prostitution. - Linus Torvalds From steve.lhomme at free.fr Mon Feb 2 23:43:59 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Mon, 02 Feb 2004 23:43:59 +0100 Subject: [Matroska-devel] GStreamer/GLib Win32 build Message-ID: <401ED2AF.5040505@free.fr> Hello everyone, I finally managed to compile GStreamer and GLib as DLLs under Windows using the Microsoft Visual Studio 2003 compiler (MSVC 7.1). I have published my modified source code on : http://mukoli.free.fr/gstreamer/gstreamer-0.7.3-win32.zip and http://mukoli.free.fr/gstreamer/glib-2.3.2-win32.zip They only contains files I had to modify in order to compile them. The rest of the files can be found in official source releases of both packages (0.7.3 and 2.3.2 respectively). In order to run gst-launch.exe (the only sample I've compiled yet) you need to build GStreamer.dll, GLib.dll, GObject.dll, GThread.dll and GModule.dll. And you also need : - libiconv-2.dll - libintl-2.dll - libxml2.dll - popt1.dll They can be found in http://gnuwin32.sourceforge.net/ You will need the binary package and developper package (include files). Last but not least, some paths in the MSVC project are only worth on my system. You may have to modify them to work on your system. In the GStreamer sources I had to disable some code. Mostly the SIG_XXX stuff. And also the _gst_parse_launch() function that I didn't generate. Right now I only tried to build all the DLLs in Debug build. From rbultje at ronald.bitfreak.net Wed Feb 4 09:36:41 2004 From: rbultje at ronald.bitfreak.net (Ronald Bultje) Date: Wed, 04 Feb 2004 09:36:41 +0100 Subject: [Matroska-devel] GStreamer/GLib Win32 build In-Reply-To: <401ED2AF.5040505@free.fr> References: <401ED2AF.5040505@free.fr> Message-ID: <1075883801.1426.0.camel@bultje.demon.nl> Op ma 02-02-2004, om 23:43 schreef Steve Lhomme: > I finally managed to compile GStreamer and GLib as DLLs under Windows > using the Microsoft Visual Studio 2003 compiler (MSVC 7.1). > > I have published my modified source code on : > http://mukoli.free.fr/gstreamer/gstreamer-0.7.3-win32.zip > and > http://mukoli.free.fr/gstreamer/glib-2.3.2-win32.zip > > They only contains files I had to modify in order to compile them. The > rest of the files can be found in official source releases of both > packages (0.7.3 and 2.3.2 respectively). > In order to run gst-launch.exe (the only sample I've compil Could you please post diff -u patches? Those can be applied to our CVS. Ronald -- Ronald Bultje From steve.lhomme at free.fr Wed Feb 4 09:38:52 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Wed, 04 Feb 2004 09:38:52 +0100 Subject: [Matroska-devel] Re: GStreamer/GLib Win32 build In-Reply-To: <1075883801.1426.0.camel@bultje.demon.nl> References: <401ED2AF.5040505@free.fr> <1075883801.1426.0.camel@bultje.demon.nl> Message-ID: <4020AF9C.8090802@free.fr> Ronald Bultje wrote: > Op ma 02-02-2004, om 23:43 schreef Steve Lhomme: > >>I finally managed to compile GStreamer and GLib as DLLs under Windows >>using the Microsoft Visual Studio 2003 compiler (MSVC 7.1). >> >>I have published my modified source code on : >>http://mukoli.free.fr/gstreamer/gstreamer-0.7.3-win32.zip >>and >>http://mukoli.free.fr/gstreamer/glib-2.3.2-win32.zip >> >>They only contains files I had to modify in order to compile them. The >>rest of the files can be found in official source releases of both >>packages (0.7.3 and 2.3.2 respectively). > > >>In order to run gst-launch.exe (the only sample I've compil > > > Could you please post diff -u patches? Those can be applied to our CVS. It is technically possible of course. But what is the point now ? It currently doesn't work. And any of you could do it too (otherwise I can put that in CVS myself and don't see the point of using a diff). Jory has taken the sources, added a few things here and there and was trying to have something not crashing. So right now I consider it as not ready... But I think it would be worth if anybody could have a look at modifications to check if I did anything wrong, like swapping some stuff, adding more compiler checks, etc. From moritz at bunkus.org Wed Feb 4 09:46:52 2004 From: moritz at bunkus.org (Moritz Bunkus) Date: Wed, 4 Feb 2004 09:46:52 +0100 Subject: [Matroska-devel] Re: GStreamer/GLib Win32 build In-Reply-To: <4020AF9C.8090802@free.fr> References: <401ED2AF.5040505@free.fr> <1075883801.1426.0.camel@bultje.demon.nl> <4020AF9C.8090802@free.fr> Message-ID: <20040204084652.GD3530@bunkus.org> Heya, > It is technically possible of course. But what is the point now ? The point of you posting diffs is that the gstreamer devels can check your changes very quickly without the hassle of building diffs themselves. It's usually considered polite to cause them the smallest possible amount of work checking your changes :) Mosu -- If Darl McBride was in charge, he'd probably make marriage unconstitutional too, since clearly it de-emphasizes the commercial nature of normal human interaction, and probably is a major impediment to the commercial growth of prostitution. - Linus Torvalds From steve.lhomme at free.fr Wed Feb 4 09:55:25 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Wed, 04 Feb 2004 09:55:25 +0100 Subject: [Matroska-devel] Re: GStreamer/GLib Win32 build In-Reply-To: <20040204084652.GD3530@bunkus.org> References: <401ED2AF.5040505@free.fr> <1075883801.1426.0.camel@bultje.demon.nl> <4020AF9C.8090802@free.fr> <20040204084652.GD3530@bunkus.org> Message-ID: <4020B37D.6090604@free.fr> Moritz Bunkus wrote: > Heya, > > >>It is technically possible of course. But what is the point now ? > > > The point of you posting diffs is that the gstreamer devels can check > your changes very quickly without the hassle of building diffs > themselves. It's usually considered polite to cause them the smallest > possible amount of work checking your changes :) Would a diff look like this : + #if defined(_MSC_VER) ... - if (...) I think that's highly unreadable at most ! I don't understand why it's better than comparing source files side by side... (or maybe such tools like Beyond Compare or Araxis Merge don't exist on Linux ?) From moritz at bunkus.org Thu Feb 5 15:58:18 2004 From: moritz at bunkus.org (Moritz Bunkus) Date: Thu, 5 Feb 2004 15:58:18 +0100 Subject: [Matroska-devel] TCME low level file/file format input/output APIs Message-ID: <20040205145817.GG3530@bunkus.org> Heya, like I said I'll be really busy from tomorrow on, so this is probably my last big work for the coming five weeks. I've wanted to start working on some low level APIs that are independent of the decisions we still have to make on the upper levels including the scripting language. The APIs I talk about are: file I/O abstraction API and demuxer/muxer API (I call that "file format input/output API"). My work can be found at https://svn.bunkus.org/mosu/trunk/prog/video/tcme-file-api/ Before you start shouting "Noooo! Don't code, think first!" let me assure you that I do NOT want to code a complete API and think about it later. I HAVE thought about it a bit. It's just that I can think better when I'm coding, I especially tend to forget to include things that are neccessary. Here I go. 1) File reading/writing abstraction API https://svn.bunkus.org/mosu/trunk/prog/video/tcme-file-api/fileio.h Basic stuff. Open files, read from them, write to them, seek in them. As a bonus they can handle text files in a special way (read the .h file, plesae): files with BOMs are supported and lines converted to UTF-8 automatically. Both DOS style and Unix style new lines will be handled correctly. 2) Demuxer/muxer API, called file format API https://svn.bunkus.org/mosu/trunk/prog/video/tcme-file-api/fileformat.h This is based heavily on ffmpeg's libavformat. I've left out some stuff and added other stuff, but my experience with demuxer APIs is very limited. I'd like the input of the guys who're familiar with the other demuxer/muxer APIs around (VDubMod's, gstreamer, milk). Unfortunately Ronald will go to New York on Sunday, so we probably have to dig into gstreamer ourselves. (Good luck and a lot of fun in NY, Ronald.) My aim was to keep it simple. No fancy XML stuff (so far). Pure C function calls. One note about the "file/track extensions". I chose against including a LOT of fields in the track and file structures as they're quite numerous: title, language, chapters, attachments, tags, default track, disabled, whatever. The "advantage" of doing it this way is that a demuxer/muxer pair can easily add their own extensions that others don't know about - this wouldn't be possible if we chose to have everything as members. 3) Test app, common.h, whatever I've implemented a SRT subtitle reader and a small test application. Nothing fancy, I just wanted to get the basics straight. Now it's your turn to say something :) -- If Darl McBride was in charge, he'd probably make marriage unconstitutional too, since clearly it de-emphasizes the commercial nature of normal human interaction, and probably is a major impediment to the commercial growth of prostitution. - Linus Torvalds From suiryc at yahoo.com Thu Feb 5 22:33:05 2004 From: suiryc at yahoo.com (Cyrius) Date: Thu, 5 Feb 2004 13:33:05 -0800 (PST) Subject: [Matroska-devel] TCME low level file/file format input/output APIs In-Reply-To: <20040205145817.GG3530@bunkus.org> Message-ID: <20040205213305.79254.qmail@web12908.mail.yahoo.com> Hi --- Moritz Bunkus wrote: > Heya, > > like I said I'll be really busy from tomorrow on, so this is probably > my > last big work for the coming five weeks. > > I've wanted to start working on some low level APIs that are > independent > of the decisions we still have to make on the upper levels including > the > scripting language. The APIs I talk about are: file I/O abstraction > API > and demuxer/muxer API (I call that "file format input/output API"). > My > work can be found at > https://svn.bunkus.org/mosu/trunk/prog/video/tcme-file-api/ > > Before you start shouting "Noooo! Don't code, think first!" let me > assure you that I do NOT want to code a complete API and think about > it > later. I HAVE thought about it a bit. It's just that I can think > better > when I'm coding, I especially tend to forget to include things that > are > neccessary. > > Here I go. > > 1) File reading/writing abstraction API > https://svn.bunkus.org/mosu/trunk/prog/video/tcme-file-api/fileio.h > > Basic stuff. Open files, read from them, write to them, seek in them. > As > a bonus they can handle text files in a special way (read the .h > file, > plesae): files with BOMs are supported and lines converted to UTF-8 > automatically. Both DOS style and Unix style new lines will be > handled > correctly. > > 2) Demuxer/muxer API, called file format API > https://svn.bunkus.org/mosu/trunk/prog/video/tcme-file-api/fileformat.h > > This is based heavily on ffmpeg's libavformat. I've left out some > stuff > and added other stuff, but my experience with demuxer APIs is very > limited. I'd like the input of the guys who're familiar with the > other > demuxer/muxer APIs around (VDubMod's, gstreamer, milk). Unfortunately > Ronald will go to New York on Sunday, so we probably have to dig into > gstreamer ourselves. (Good luck and a lot of fun in NY, Ronald.) I noticed that you use timecodes (ns precision) in your API. When working on my previous dream :p I was unsure whether fixed timescales (here 1ns precision) or a rational system was better. For exemple in VDub Avery Lee now uses a rational value to express the rate of data, thus keeping perfect precision till the end. For Constant FrameRate streams it would be the framerate/samplerate, and for variable framerates it would be a 1ns timescale too. For CBR audio it could even be the byterate. Of course with such a system you need to multiply the 'index' given to you by the 'rate' to get time information ... but many formats chose to use this as basis (numerator/denominator to express a rate; it's used in AVI, OGM and Nut, dunno about the other formats). Maybe other people could express their feelings about both systems ... > My aim was to keep it simple. No fancy XML stuff (so far). Pure C > function calls. =) > One note about the "file/track extensions". I chose against including > a > LOT of fields in the track and file structures as they're quite > numerous: title, language, chapters, attachments, tags, default > track, > disabled, whatever. The "advantage" of doing it this way is that a > demuxer/muxer pair can easily add their own extensions that others > don't > know about - this wouldn't be possible if we chose to have everything > as > members. I also think that's the way to go. I had a similar idea. > 3) Test app, common.h, whatever > I've implemented a SRT subtitle reader and a small test > application. Nothing fancy, I just wanted to get the basics straight. > > Now it's your turn to say something :) Moo. __________________________________ Do you Yahoo!? Yahoo! Finance: Get your refund fast by filing online. http://taxes.yahoo.com/filing.html From moritz at bunkus.org Thu Feb 5 23:17:46 2004 From: moritz at bunkus.org (Moritz Bunkus) Date: Thu, 5 Feb 2004 23:17:46 +0100 Subject: [Matroska-devel] TCME low level file/file format input/output APIs In-Reply-To: <20040205213305.79254.qmail@web12908.mail.yahoo.com> References: <20040205145817.GG3530@bunkus.org> <20040205213305.79254.qmail@web12908.mail.yahoo.com> Message-ID: <20040205221746.GI3530@bunkus.org> Heya, Jory asked: 'I thought we were using gstreamer?' I thought we'd use it for all the audio/video processing stuff. But for the file formats? We'd have to enhance its API, I'd guess, a lot. Remember that we want to be able to take advantage of every feature Matroska has to offer. Maybe I'm wrong and the gstreamer API is already extensible, or maybe it has something similar to the 'track extensions' I was proposing. If so then there's no need for this API. Please could someone take a look at gstreamer? Thanks. Mosu -- If Darl McBride was in charge, he'd probably make marriage unconstitutional too, since clearly it de-emphasizes the commercial nature of normal human interaction, and probably is a major impediment to the commercial growth of prostitution. - Linus Torvalds From spyder at matroska.org Fri Feb 6 22:34:55 2004 From: spyder at matroska.org (John Cannon) Date: Fri, 06 Feb 2004 15:34:55 -0600 Subject: [Matroska-devel] TCME low level file/file format input/output APIs In-Reply-To: <20040205213305.79254.qmail@web12908.mail.yahoo.com> References: <20040205213305.79254.qmail@web12908.mail.yahoo.com> Message-ID: <4024087F.3@matroska.org> Cyrius wrote: >>This is based heavily on ffmpeg's libavformat. I've left out some >>stuff >>and added other stuff, but my experience with demuxer APIs is very >>limited. I'd like the input of the guys who're familiar with the >>other >>demuxer/muxer APIs around (VDubMod's, gstreamer, milk). Unfortunately >>Ronald will go to New York on Sunday, so we probably have to dig into >>gstreamer ourselves. (Good luck and a lot of fun in NY, Ronald.) >> >> > >I noticed that you use timecodes (ns precision) in your API. >When working on my previous dream :p I was unsure whether fixed >timescales (here 1ns precision) or a rational system was better. > > > I agree :) It's best if we can keep this as extremely accurate as possible inside TCME. I am building gstreamer ATM so i can play with it and get a feel for how it works :) John From spyder at matroska.org Fri Feb 6 22:39:46 2004 From: spyder at matroska.org (John Cannon) Date: Fri, 06 Feb 2004 15:39:46 -0600 Subject: [Matroska-devel] TCME low level file/file format input/output APIs In-Reply-To: <4024087F.3@matroska.org> References: <20040205213305.79254.qmail@web12908.mail.yahoo.com> <4024087F.3@matroska.org> Message-ID: <402409A2.9070802@matroska.org> John Cannon wrote: > I agree :) It's best if we can keep this as extremely accurate as > possible inside TCME. I am building gstreamer ATM so i can play with > it and get a feel for how it works :) > Hmm, that was really uninformative ;) I think we should use a rational system. John From jcsston at wiesneronline.net Fri Feb 6 22:43:06 2004 From: jcsston at wiesneronline.net (Jory) Date: Fri, 6 Feb 2004 15:43:06 -0600 Subject: [Matroska-devel] TCME low level file/file format input/output APIs References: <20040205145817.GG3530@bunkus.org><20040205213305.79254.qmail@web12908.mail.yahoo.com> <20040205221746.GI3530@bunkus.org> Message-ID: <002801c3ecfa$43d07560$0200a8c0@jcsston> Each filter in GStreamer has a gchar * name binded to a GValue. Here's an excerpt from a fakesrc ! fakesink pipeline saved to .xml. fakesrc0 fakesrc name fakesrc0 num-sources 1 ... last-message src fakesink0.sink I think the on the matroska de/muxer filter could be enough for setting most the non-track related muxing options. For the track related options, I see adding 's to the pads/pins as a clean way to do it in the GStreamer framework without a lot of work. >I noticed that you use timecodes (ns precision) in your API. >When working on my previous dream :p I was unsure whether fixed >timescales (here 1ns precision) or a rational system was better. GStreamer uses ns precision for timecodes, as does DirectShow. Later, Jory ----- Original Message ----- From: "Moritz Bunkus" To: Sent: Thursday, February 05, 2004 4:17 PM Subject: Re: [Matroska-devel] TCME low level file/file format input/output APIs > Heya, > > Jory asked: > > 'I thought we were using gstreamer?' > > I thought we'd use it for all the audio/video processing stuff. But for > the file formats? We'd have to enhance its API, I'd guess, a > lot. Remember that we want to be able to take advantage of every feature > Matroska has to offer. > > Maybe I'm wrong and the gstreamer API is already extensible, or maybe it > has something similar to the 'track extensions' I was proposing. If so > then there's no need for this API. > > Please could someone take a look at gstreamer? Thanks. > > Mosu > > -- > If Darl McBride was in charge, he'd probably make marriage > unconstitutional too, since clearly it de-emphasizes the commercial > nature of normal human interaction, and probably is a major impediment > to the commercial growth of prostitution. - Linus Torvalds > _______________________________________________ > Matroska-devel mailing list > Matroska-devel at lists.matroska.org > http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel From paul at msn.com Sat Feb 7 09:45:36 2004 From: paul at msn.com (Paul Bryson) Date: Sat, 7 Feb 2004 02:45:36 -0600 Subject: [Matroska-devel] Re: TCME low level file/file format input/output APIs References: <20040205145817.GG3530@bunkus.org><20040205213305.79254.qmail@web12908.mail.yahoo.com><20040205221746.GI3530@bunkus.org> <002801c3ecfa$43d07560$0200a8c0@jcsston> Message-ID: "Jory" wrote... > >I noticed that you use timecodes (ns precision) in your API. > >When working on my previous dream :p I was unsure whether fixed > >timescales (here 1ns precision) or a rational system was better. > > GStreamer uses ns precision for timecodes, as does DirectShow. I thought that DirectShow used 100ns precision? Pamel From rbultje at ronald.bitfreak.net Sat Feb 7 16:15:16 2004 From: rbultje at ronald.bitfreak.net (Ronald Bultje) Date: Sat, 07 Feb 2004 16:15:16 +0100 Subject: [Matroska-devel] TCME low level file/file format input/output APIs In-Reply-To: <20040205221746.GI3530@bunkus.org> References: <20040205145817.GG3530@bunkus.org> <20040205213305.79254.qmail@web12908.mail.yahoo.com> <20040205221746.GI3530@bunkus.org> Message-ID: <1076166913.5294.10.camel@localhost.localdomain> On Thu, 2004-02-05 at 23:17, Moritz Bunkus wrote: > 'I thought we were using gstreamer?' [..] > I thought we'd use it for all the audio/video processing stuff. But for > the file formats? We'd have to enhance its API, I'd guess, a > lot. Remember that we want to be able to take advantage of every feature > Matroska has to offer. > > Maybe I'm wrong and the gstreamer API is already extensible, or maybe it > has something similar to the 'track extensions' I was proposing. If so > then there's no need for this API. I'm not dead, guys, just slow. ;). We dont' have any fixed API for tracks or anything yet. We only have plans for that. Reason is simple: most common file formats don't use it. You can always use gobject parameters as a start. Later on, it could be implemented as a hard-coded, specific track API. I didn't actually look at your code, still a bit busy. I'll try to look at it when I've arrived in New York. Ronald -- Ronald Bultje From dcoder at mindless.com Sat Feb 7 18:29:06 2004 From: dcoder at mindless.com (Dcoder) Date: Sat, 7 Feb 2004 17:29:06 -0000 Subject: [Matroska-devel] Menus and Control tracks Message-ID: Hi everyone. I was just wondering how is the progress of Matroska regarding those two features. I noticed that much effort now is being made about TCME. Will Matroska development slowdown because of it? Or will Matroska evolve with TCME, side by side? Will TCME be the first tool to handle menus, make control tracks, etc? Best regards, Dcoder From chris at matroska.org Mon Feb 9 22:41:08 2004 From: chris at matroska.org (Christian HJ Wiesner) Date: Mon, 09 Feb 2004 22:41:08 +0100 Subject: [Matroska-devel] Menus and Control tracks In-Reply-To: References: Message-ID: <4027FE74.2060208@matroska.org> Dcoder wrote: >Hi everyone. >I was just wondering how is the progress of Matroska regarding those two >features. >I noticed that much effort now is being made about TCME. Will Matroska >development slowdown because of it? Or will Matroska evolve with TCME, side >by side? Will TCME be the first tool to handle menus, make control tracks, >etc? Best regards, Dcoder > Dcoder, i fear you are right. matroska development, IMO, will significantly slow down because of TCME, and i am the one to blame. However, i am convinced that its the right thing to do, and that matroska will only have a chance to 'survive' against MP4 and others with a decent editor support. Naturally, this editor should be capable to handle MP4 and other containers also. But this way we make sure that matroska will always be an option in 'the next generation Virtualdub' ;) .... Christian From moritz at bunkus.org Thu Feb 12 16:33:32 2004 From: moritz at bunkus.org (Moritz Bunkus) Date: Thu, 12 Feb 2004 16:33:32 +0100 Subject: [Matroska-devel] mailing list archives are now searchable Message-ID: <20040212153332.GF8062@bunkus.org> Heya, I've added ht://dig as a search backend for the list archives. On the archives index pages (http://lists.matroska.org/ -> chose your list -> chose the archives likn) you'll find a link to the search pages. Mosu -- If Darl McBride was in charge, he'd probably make marriage unconstitutional too, since clearly it de-emphasizes the commercial nature of normal human interaction, and probably is a major impediment to the commercial growth of prostitution. - Linus Torvalds From matroska at mani.user.lysator.liu.se Thu Feb 12 17:30:34 2004 From: matroska at mani.user.lysator.liu.se (Martin Nilsson) Date: Thu, 12 Feb 2004 17:30:34 +0100 Subject: [Matroska-devel] EBML Message-ID: <402BAA2A.6060008@mani.user.lysator.liu.se> Hello. I don't know if this is the most appropriate place for this, but I didn't find any EBML specific forum. My name is Martin Nilsson and once upon a time I did an overly complex standard called ID3v2. My mission now is to seek out emerging standards that I am likely to be affected by and make sure I can live with them :) So this week I've spent one day writing an EBML library of my own, to figure EBML out as best as I could, and two days on writing an EBML specification draft. I hope this is an welcome effort and does not collide with anything that you are already working on. The draft (and I emphasize draft) is available at http://pike.ida.liu.se/generated/ebml.txt Any feedback is good feedback. /Martin Nilsson From steve.lhomme at free.fr Thu Feb 12 17:45:10 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Thu, 12 Feb 2004 17:45:10 +0100 Subject: [Matroska-devel] EBML In-Reply-To: <402BAA2A.6060008@mani.user.lysator.liu.se> References: <402BAA2A.6060008@mani.user.lysator.liu.se> Message-ID: <402BAD96.8030606@free.fr> Hi Martin, I've seen the email you sent me on robUx4 but could not find the time to check your specs and reply to you so far. I hope I will have the needed time tonight. Thx for your work and interrest in EBML :) Martin Nilsson wrote: > > Hello. > > I don't know if this is the most appropriate place for this, but I > didn't find any EBML specific forum. My name is Martin Nilsson and once > upon a time I did an overly complex standard called ID3v2. My mission > now is to seek out emerging standards that I am likely to be affected by > and make sure I can live with them :) > > So this week I've spent one day writing an EBML library of my own, to > figure EBML out as best as I could, and two days on writing an EBML > specification draft. I hope this is an welcome effort and does not > collide with anything that you are already working on. The draft (and I > emphasize draft) is available at > > http://pike.ida.liu.se/generated/ebml.txt > > Any feedback is good feedback. > > /Martin Nilsson > > > _______________________________________________ > Matroska-devel mailing list > Matroska-devel at lists.matroska.org > http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel From chris at matroska.org Thu Feb 12 19:09:57 2004 From: chris at matroska.org (Christian HJ Wiesner) Date: Thu, 12 Feb 2004 19:09:57 +0100 Subject: [Matroska-devel] EBML In-Reply-To: <402BAA2A.6060008@mani.user.lysator.liu.se> References: <402BAA2A.6060008@mani.user.lysator.liu.se> Message-ID: <402BC175.1040309@matroska.org> Hi Martin, welcome to this list ! Martin Nilsson wrote: > Hello. > I don't know if this is the most appropriate place for this, but I > didn't find any EBML specific forum. My name is Martin Nilsson and > once upon a time I did an overly complex standard called ID3v2. My > mission now is to seek out emerging standards that I am likely to be > affected by and make sure I can live with them :) You are the 'founder' of the id3v2 standard ? What an honour to have you posting to this list ! Welcome again ! But i admit, being not a developer myself, i dont really understand how ebml or matroska could affect id3v2 ? Can you pls. explain this in layman's terms for a non-techie :) ? > So this week I've spent one day writing an EBML library of my own, to > figure EBML out as best as I could, and two days on writing an EBML > specification draft. I hope this is an welcome effort and does not > collide with anything that you are already working on. The draft (and > I emphasize draft) is available at > http://pike.ida.liu.se/generated/ebml.txt Any feedback is good > feedback. /Martin Nilsson Wow. A new EBML lib ? What language is it in ? C or C++ ? What license did you choose for it ? Christian matroska project admin From steve.lhomme at free.fr Thu Feb 12 20:40:07 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Thu, 12 Feb 2004 20:40:07 +0100 Subject: [Matroska-devel] EBML In-Reply-To: <402BB202.3060505@mani.user.lysator.liu.se> References: <402BAA2A.6060008@mani.user.lysator.liu.se> <402BAD96.8030606@free.fr> <402BB202.3060505@mani.user.lysator.liu.se> Message-ID: <402BD697.4090801@free.fr> Martin Nilsson wrote: > Steve, Hi Martin, > Note that the draft I linked to is much more developed than the one I > sent you. The major things left to do is textual descriptions of my DTD > suggestion, the value restriction property and listing the EBML standard > elements. I hope to be able to do that tonight. I also intend to write > an EBML DTD for XHTML to see that the DTD language is expressive enough > to handle XML (and write an XHTML to EBML converter in the process). > Once that is done my EBML specification is ready for publication. > However, the question is if it is anywhere near what you want :) Well, I'll first have to look at your work to see if there is no mistake/misunderstanding. Otherwise it will be very valuable to us ! It looks like a RFC and could be used for other things. A formal description is for sure something that will help people understanding it. > I have a question right away though. Are there any secret rules for EBML > element ID assignment, or is it just taking whatever number you feel like? In the case of Matroska we used 4-octets long IDs for elements that be used as damaged file recovery (syncword). Otherwise it just depends on the occurence and the importance of the ID (more often is a short one to reduce the overall size of the file). From steve.lhomme at free.fr Thu Feb 12 20:48:30 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Thu, 12 Feb 2004 20:48:30 +0100 Subject: [Matroska-devel] [Fwd: Undelivered Mail Returned to Sender] Message-ID: <402BD88E.9030307@free.fr> In case you see this... -------- Original Message -------- Subject: Undelivered Mail Returned to Sender Date: Thu, 12 Feb 2004 20:40:35 +0100 (CET) From: MAILER-DAEMON at huva.hittite.isp.9tel.net (Mail Delivery System) To: steve.lhomme at free.fr This is the Postfix program at host huva.hittite.isp.9tel.net. I'm sorry to have to inform you that the message returned below could not be delivered to one or more destinations. For further assistance, please send mail to If you do so, please include this problem report. You can delete your own text from the message returned below. The Postfix program : host mail.lysator.liu.se[130.236.254.3] said: 554 : Recipient address rejected: Service unavailable, blocked by RBL+; [62.62.156.28] Contact postmaster if any questions occur -------------- next part -------------- An embedded message was scrubbed... From: Steve Lhomme Subject: Re: [Matroska-devel] EBML Date: Thu, 12 Feb 2004 20:40:07 +0100 Size: 2253 URL: From steve.lhomme at free.fr Thu Feb 12 21:27:34 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Thu, 12 Feb 2004 21:27:34 +0100 Subject: [Matroska-devel] EBML In-Reply-To: <402BAA2A.6060008@mani.user.lysator.liu.se> References: <402BAA2A.6060008@mani.user.lysator.liu.se> Message-ID: <402BE1B6.5050105@free.fr> Martin Nilsson wrote: > http://pike.ida.liu.se/generated/ebml.txt [Isn't markup better than meta, since it's really markup we are doing?] Yes. You might add that EBML is octet/byte aligned (in addition of the network byte ordering). That would be a good addition to the VINT definition. "As an example ID 1 from class A, encoded as 0x81, and ID 1 from class B, encoded as 0x4001, are considered different IDs." Interresting point that was never raised before. IMO it should be avoided to use this case. And that's what we did with Matroska. It could impose some constraints on the parser behaviour which is IMO not necessary. I think there is enough IDs to avoid this (and BTW that means the number of IDs for class B, C and D are wrong because they should not contain elements of the other class). The overlapping is allowed for the size coding and is actually needed as you mention (This allows for the element data to shrink without having to shrink the width of the size descriptor). [Why not 0 bytes for 0?] Good question. We never thought about that before. That could be a funny enhancement (although it would be harder to change a value that has no space for it). "A string MAY be zero padded at the end." You might add this to you ABNF notion (but I could no write it myself ;) idem for UTF-8 "DATE = 8BYTE Signed, 64-bit (8 byte) integer describing the distance to the beginning of the millennium" You might add that it's in nanoseconds. FYI, one of the EBML enhancement that is planned is to allow some kind of embedded DTD inside the EBML header, that would describe the hierarchy of the elements, their ID and their type (all in EBML format of course). This way it would be easy to spot known/unknown elements and interpret the value of some elements (maybe even with a human friendly name) even if you don't know the actual meaning. I'm going to check the second chapter next. From steve.lhomme at free.fr Thu Feb 12 21:52:45 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Thu, 12 Feb 2004 21:52:45 +0100 Subject: [Matroska-devel] EBML In-Reply-To: <402BAA2A.6060008@mani.user.lysator.liu.se> References: <402BAA2A.6060008@mani.user.lysator.liu.se> Message-ID: <402BE79D.6040506@free.fr> Martin Nilsson wrote: > http://pike.ida.liu.se/generated/ebml.txt In Chapter 2 "The default value can also be a symbol referring back to a previously seen symbol. If however no such symbol has been seen, i.e. it has not been encoded into the EBML data and has no default value, the element will not be added as a child on the semantic level." This has not been firmly defined yet. Even though in Matroska we already use this. The problem is in what scope the 'other' element should be. Especially since there is no order in EBML (as in XML). Even though we always assume there is one... I really have no idea on how to define this clearly. So for now your formulation is best. "2.7. Child order property" This is not yet supported. But the idea to have some elements that need ordering and some not is good. There are 2 chapter 4 Otherwise the rest is OK. IMPRESSIVE WORK !!! Do you plan to submit this to the IETF ? That would be great to have EBML become a wide standard. Because I'm sure it can be used in many cases : small XML that can store binary data and use default values. From matroska at mani.user.lysator.liu.se Fri Feb 13 02:01:48 2004 From: matroska at mani.user.lysator.liu.se (Martin Nilsson) Date: Fri, 13 Feb 2004 02:01:48 +0100 Subject: [Matroska-devel] EBML In-Reply-To: <402BE1B6.5050105@free.fr> References: <402BAA2A.6060008@mani.user.lysator.liu.se> <402BE1B6.5050105@free.fr> Message-ID: <402C21FC.6070206@mani.user.lysator.liu.se> Steve Lhomme wrote: > > "As an example ID 1 from class A, encoded as 0x81, and ID 1 from class > B, encoded as 0x4001, are considered different IDs." > > Interresting point that was never raised before. IMO it should be > avoided to use this case. And that's what we did with Matroska. It could > impose some constraints on the parser behaviour which is IMO not > necessary. I think there is enough IDs to avoid this (and BTW that means > the number of IDs for class B, C and D are wrong because they should not > contain elements of the other class). I disagree. Even if you represented the ID in its parsed numerical state you would still have to save the size as well to prevent 0x4001 from being compressed into 0x81. So disallowing two IDs from having the same decoded value only imposes extra constraints on ID generation, unless one uses the decoded ID as the actual ID (i.e. having 0x81 and 0x4001 meaning the same element). And imposing extra ID generation constraints is very bad since (hopefully) more people will be writing EBML DTDs than EBML parsers. Making correct IDs are already the most complicated step in formulating an EBML language. > FYI, one of the EBML enhancement that is planned is to allow some kind > of embedded DTD inside the EBML header, that would describe the > hierarchy of the elements, their ID and their type (all in EBML format > of course). This way it would be easy to spot known/unknown elements and > interpret the value of some elements (maybe even with a human friendly > name) even if you don't know the actual meaning. Good idea. There should probably be some sort of ID range reserved for EBML elements. Actually the possible ID clashes between different DTDs upon compositioning is probably the biggest weakness of EBML right now as far as I can see. And it is a difficult problem to solve. W3C never actually solved the problem for XML. They sidestepped the issue with namespaces as "solution". Moving on to reply 2: [default by symbol value] > This has not been firmly defined yet. Even though in Matroska we > already use this. Well, I used the Matroska definition as test case for the expressiveness of my DTD format > The problem is in what scope the 'other' element should be. My first thought was to only refer back to parents, but in practice you would probably more often want to refer to siblings. The real issue here of course is to cap the memory consumption for the "semantic EBML parser". Do we need to save the latest value of every parsed element? No, fortunately not. When we read the EBML DTD we compile a list of all referred elements and only save the latest one of those in a history. Further we could state that once we leave the top level element the history must be cleared. That in itself is a good idea, but the fewer rules the better. Even further we could state that once we leave the current parent element, the history for that level should be cleared. That is probably a bad idea. Lastly we could introduce another DTD property specifying that an element has a private scope that should be cleared when the element is exited. That is a flexible solution that allows the DTD author to control how values are stored. I think it adds unnecessary complexity for too little gain. > IMPRESSIVE WORK !!! Thank you. > Do you plan to submit this to the IETF ? That would be great to have > EBML become a wide standard. Because I'm sure it can be used in many > cases : small XML that can store binary data and use default values. I'm a bit reluctant to take things to IETF after my experience with getting RFC 3003 through. I guess the only good way to get things done is to be there in person, and that would require someone to financially back the standard or that someone already involved in IETF sponsors it. Right now my focus is on going through all the layers of Matroska and at least try to change everything that I don't like... I hope you guys are open for debate when I reach the difficult parts. /Martin Nilsson From matroska at mani.user.lysator.liu.se Fri Feb 13 02:59:30 2004 From: matroska at mani.user.lysator.liu.se (Martin Nilsson) Date: Fri, 13 Feb 2004 02:59:30 +0100 Subject: [Fwd: Re: [Matroska-devel] EBML] Message-ID: <402C2F82.2090707@mani.user.lysator.liu.se> Looks like I didn't reply to the right address. -------------- next part -------------- An embedded message was scrubbed... From: Martin Nilsson Subject: Re: [Matroska-devel] EBML Date: Thu, 12 Feb 2004 20:52:28 +0100 Size: 2096 URL: From paul at msn.com Fri Feb 13 08:13:42 2004 From: paul at msn.com (Paul Bryson) Date: Fri, 13 Feb 2004 01:13:42 -0600 Subject: [Matroska-devel] Re: EBML References: <402BAA2A.6060008@mani.user.lysator.liu.se> Message-ID: "Martin Nilsson" wrote... > I don't know if this is the most appropriate place for this, but I > didn't find any EBML specific forum. The "right" place might possibly be the sf.net mailing list, but this place is certainly more useful. :) > My name is Martin Nilsson and once > upon a time I did an overly complex standard called ID3v2. I have spent many hours pouring over the ID3v2.4.0 docs. My greatest regret is that they didn't have an HTML version that I could just like directly to tag descriptions. Sometimes it was difficult to understand exactly what a given field was for, and in working with the Matroska Tags, I would simply link to those specs hoping that others would understand the purpose. Overall though, it was a very good spec, and it is an honor to respond to correspondance from the person that developed it. The first revision of the Matroska Tags turned out to be even more complex than ID3v2, and was eventually revised into a simpler, and ultimately more flexible system. Any direction you could offer with them would be more than appreciated. I can see that you are busy with several projects, so it would certainly be understandable if you do not have the time, or are simply sick of tags. http://matroska.org/technical/specs/tagging/index.html > My mission > now is to seek out emerging standards that I am likely to be affected by > and make sure I can live with them :) A noble cause to say the least. > So this week I've spent one day writing an EBML library of my own, to > figure EBML out as best as I could, and two days on writing an EBML > specification draft. I hope this is an welcome effort and does not > collide with anything that you are already working on. The draft (and I > emphasize draft) is available at > > http://pike.ida.liu.se/generated/ebml.txt > > Any feedback is good feedback. The most feedback I could give is to say, "excellent job, keep up the good work". While I wouldn't say that the current group is very lacking in its ability to define the standard on its website, you certainly have great skill at producing documents that would be needed for official processes. Very well written. Pamel From paul at msn.com Fri Feb 13 08:30:32 2004 From: paul at msn.com (Paul Bryson) Date: Fri, 13 Feb 2004 01:30:32 -0600 Subject: [Matroska-devel] Re: EBML References: <402BAA2A.6060008@mani.user.lysator.liu.se><402BE1B6.5050105@free.fr> <402C21FC.6070206@mani.user.lysator.liu.se> Message-ID: "Martin Nilsson" wrote... > Right now my focus is on going through all the layers of Matroska and at > least try to change everything that I don't like... I hope you guys are > open for debate when I reach the difficult parts. The format is certainly not perfect, but it is to late to make major changes to the basic design as there is already to large of a user base. Additions are the most likely thing to work. There is actually a push to formalize a version 1.0 specification so that changes can be made for version 2 or 3 featuring improvements, without breaking current tools. For instance, I would prefer all Clusters to be children of a parent element named "Clusters" to make it easy to find non-Cluster elements in the file without a seekhead. You probably wouldn't have more than a single Clusters element in a Matroska file, unless you were repeating the Tracks element. But, this would make finding other level 1 elements at the end of the file extremely fast. However, changing the level of a major element would break every existing tool, and would probably be to difficult to do for version 2 or 3 of Matroska. Version 2 of Matroska is when certain more advanced features such as menus are planned. So, just because you do not see them yet does not mean they have not already been considered, and possibly planned for the future. It might be good to quickly browse through the mailing lists to see the ideas that have already been discussed as it may spark some of your own. Pamel From steve.lhomme at free.fr Fri Feb 13 13:49:05 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Fri, 13 Feb 2004 13:49:05 +0100 Subject: [Matroska-devel] EBML In-Reply-To: <402C1745.5050206@mani.user.lysator.liu.se> References: <402BAA2A.6060008@mani.user.lysator.liu.se> <402BE1B6.5050105@free.fr> <402C1745.5050206@mani.user.lysator.liu.se> Message-ID: <402CC7C1.3000307@free.fr> Martin Nilsson wrote: > Steve Lhomme wrote: > >> >> "As an example ID 1 from class A, encoded as 0x81, and ID 1 from class >> B, encoded as 0x4001, are considered different IDs." >> >> Interresting point that was never raised before. IMO it should be >> avoided to use this case. And that's what we did with Matroska. It >> could impose some constraints on the parser behaviour which is IMO not >> necessary. I think there is enough IDs to avoid this (and BTW that >> means the number of IDs for class B, C and D are wrong because they >> should not contain elements of the other class). > > > I disagree. Even if you represented the ID in its parsed numerical state > you would still have to save the size as well to prevent 0x4001 from > being compressed into 0x81. So disallowing two IDs from having the same > decoded value only imposes extra constraints on ID generation, unless > one uses the decoded ID as the actual ID (i.e. having 0x81 and 0x4001 > meaning the same element). From a coding perspective, as we decided that IDs are max 4 octets long, one could decide to store the decoded ID value in a 32 bits variable (int on most computers). And if this ID don't keep the way it's coded, some IDs may have the same value even if they are not coded the same way (length). > And imposing extra ID generation constraints is very bad since > (hopefully) more people will be writing EBML DTDs than EBML parsers. > Making correct IDs are already the most complicated step in formulating > an EBML language. That's true from this point of view. But I think it's better to avoid this case. Any writer of a format based on EBML should be able (but not be obliged) to take that in account. >> FYI, one of the EBML enhancement that is planned is to allow some kind >> of embedded DTD inside the EBML header, that would describe the >> hierarchy of the elements, their ID and their type (all in EBML format >> of course). This way it would be easy to spot known/unknown elements >> and interpret the value of some elements (maybe even with a human >> friendly name) even if you don't know the actual meaning. > > > Good idea. There should probably be some sort of ID range reserved for > EBML elements. Actually the possible ID clashes between different DTDs > upon compositioning is probably the biggest weakness of EBML right now > as far as I can see. And it is a difficult problem to solve. W3C never > actually solved the problem for XML. They sidestepped the issue with > namespaces as "solution". That's why we have a DocType. It is not possible to merge 2 DocTypes in one. And XML has more "space" to use namespaces. Because of the way we try to store values, it would cost a lot of space to make all EBML formats compatible with each others. > > The problem is in what scope the 'other' element should be. > > My first thought was to only refer back to parents, but in practice you > would probably more often want to refer to siblings. The real issue here > of course is to cap the memory consumption for the "semantic EBML > parser". Do we need to save the latest value of every parsed element? > No, fortunately not. When we read the EBML DTD we compile a list of all > referred elements and only save the latest one of those in a history. Yeah, that makes sense this way. > Further we could state that once we leave the top level element the > history must be cleared. That in itself is a good idea, but the fewer > rules the better. Even further we could state that once we leave the > current parent element, the history for that level should be cleared. > That is probably a bad idea. Lastly we could introduce another DTD > property specifying that an element has a private scope that should be > cleared when the element is exited. That is a flexible solution that > allows the DTD author to control how values are stored. I think it adds > unnecessary complexity for too little gain. Yep. Well in the case of Matroska, all refered data make sense in the scope of a Segment. (well, there *is* a way to link segments with IDs so the scope is even wider). And in the DTD you know at which level Element A referenced by Element B mix (the first level they have in common which in Matroska is probably always the Segment). So even with the DTD you should have enough knowledge of the scope you need to keep the references. Then what about references that could match many elements in the same scope ? > Right now my focus is on going through all the layers of Matroska and at > least try to change everything that I don't like... I hope you guys are > open for debate when I reach the difficult parts. Of course we are always opened to improvements. But right now we have lots of files based on the current specs in the wild. And we do not want to break any backward compatibility with those files. So changes would only be done if they meet this requirement. Otherwise they would be an option for Matroska 2 that will have more features and some doubled for better efficiency (maybe a new Block element). That would still not break forward compatibility (Matroska 1 files should play in Matroska 2 files). BTW, some SMTP servers don't like your matroska at mani.user.lysator.liu.se address. From matroska at mani.user.lysator.liu.se Tue Feb 17 04:28:56 2004 From: matroska at mani.user.lysator.liu.se (Martin Nilsson) Date: Tue, 17 Feb 2004 04:28:56 +0100 Subject: [Matroska-devel] Re: EBML In-Reply-To: References: <402BAA2A.6060008@mani.user.lysator.liu.se> Message-ID: <40318A78.4050507@mani.user.lysator.liu.se> Paul Bryson wrote: > I have spent many hours pouring over the ID3v2.4.0 docs. My greatest regret is > that they didn't have an HTML version that I could just like directly to tag > descriptions. I did an HTML version of the revesion before 2.4.0, but it was so incredibly time consuming that I really didn't want to go through it again. I did however look into building an XML format for RFC-like texts, envisioning one XSLT to make the text version and one to make the HTML version. As with many projects I didn't come too far, mostly because no one else was interested. > Sometimes it was difficult to understand exactly what a given > field was for, and in working with the Matroska Tags, I would simply link to > those specs hoping that others would understand the purpose. Understandable, but in my opinion wrong. Just include what you really have a need for. The way specifications and libraries tend to grow is probably one of the more difficult problems to overcome/avoid. You need to have an objective look at your specification and question what is good and what shouldn't be there, and that is _really_ hard. WRT tagging I would suggest you to drop support for AENC, since no one uses it, and EQU2, since it is underspecified. Instead there should have been a frame with spectral average which could be used as input to a function that generated equalization curves. Generally speaking though it would all be a waste of time since people really only want to have volume equalization between files (We did some feature research together with mp3.com a while back). Now back to the EBML spec. I've had another go at it and is now probably in the last 10% (where 90% of the time is spent...). I've posted the latest version at http://www.lysator.liu.se/~mani/ebml/ together with a copy of matroska.edtd and an EBML DTD validator. Unfortunately it does find some problems with Matroska. [nilsson at mahoro ebml]$ ./vdtd matroska.edtd Pass 1. (parser) matroska.edtd:176: ID "80" is reserved. Pass 2. (analysis) matroska.edtd:169: Element name "chapteruid" already used at line 191. matroska.edtd:68: Element name "trackuid" already used at line 190. matroska.edtd:26: Element name "duration" already used at line 58. matroska.edtd:58: Default reference "TrackDuration" does not exist. matroska.edtd:47: Default reference "TrackDuration" does not exist. ID 80 (ChapterDisplay) is reserved (all "x" are 0). This is the serious one, since it would mean to change the binary format, unless the reserved rule is dropped. ChapterUID exists both in Chapters and Tagging. TrackUID exists both in Track and Tagging. Duration exists both in Info and Cluster. These three are just naming problems, since I decided that element names should be unique in a DTD. Finally the element referenced as default value to BlockDuration and Duration (in TimeSlice) doesn't exist. Did you rename it? About the document: I've changed the ID semantics as Steve suggested and adjusted the total number of IDs per class (hopefully to correct values). I'm almost done with the DTD section and am about to begin the standard elements section. Some questions here. Should really SignatureSlot be part of the EBML core standard? Isn't CRC-32 better implemented as a container element? Then the decoder will know when it must calculate CRC-32 and the start and end is very obvious. I also think the requirement for a CRC-32 element in every level 1 elements should be dropped. It isn't even met in all files I've found to experiment with. Should we drop the string type? It is a complete subset of the utf8 type and since I've defined ranges on utf8 strings to limit the range of every byte, you can still define an element to have the same practical meaning. /Martin Nilsson From matroska at mani.user.lysator.liu.se Tue Feb 17 07:26:51 2004 From: matroska at mani.user.lysator.liu.se (Martin Nilsson) Date: Tue, 17 Feb 2004 07:26:51 +0100 Subject: [Matroska-devel] Re: EBML In-Reply-To: References: <402BAA2A.6060008@mani.user.lysator.liu.se> <402BE1B6.5050105@free.fr> <402C21FC.6070206@mani.user.lysator.liu.se> Message-ID: <4031B42B.2070509@mani.user.lysator.liu.se> Paul Bryson wrote: > The format is certainly not perfect, but it is to late to make major changes to > the basic design as there is already to large of a user base. Additions are the > most likely thing to work. There is actually a push to formalize a version 1.0 > specification so that changes can be made for version 2 or 3 featuring > improvements, without breaking current tools. I have not had the time to read through and evaluate everything carefully yet, but I'm really happy with most of what I've seen. One of the good lessons from ID3v2 was to put a lot of effort in making a well documented, easy to use, feature complete, cross platform library. If you do that, and keep the library able to handle all versions of your format, you are free to do pretty much anything with the format. To instead invest a lot of time and effort into a lot of really clever compatibility things in the standard, as we did in ID3v2, is not a good way. It makes the standard really cluttered, hard to interpret and implement and in the end it turned out that every new version had to be incompatible anyway. So it's better to come clean up front and tell everyone that the next version will be incompatible. If you don't want to deal with it, use our lib. What I do like to see is a reduced library dependency. To completely support matroska I would have to support RSA and ECDSA. SHA1 and MD5. z-compression, bz-compression and lzo-compression. DES, 3DES, Twofish, Blowfish and AES. To name a few standards. I don't think there is something wrong with deciding for the user in some of these issues. AES is proven better than the other cipher algorithms. SHA1 is proven better than MD5. The NIST reports are there for everyone to read, so there is really no technical reason to allow all of these algorithms. Similarly when something can be normalized into one unit or format I think it should. Why allow for DisplayUnit to be both centimeters and inches? Inch is _defined_ in centimeters. Or why have support for five different subtitle formats when two would be enough; One format which the textual formats could be normalized into (EBML based?) and one bitmap format (perhaps based on PNG with alpha channels?). I realize that this is something that must have been up for discussion (sorry, I have not had the time to read up in the list archive either), but I'll just use these specific examples to back my general suggestion: reduce dependencies, e.g. by disallowing things and normalizing data. These are of course things that can be done at any time ("From version 7 of matroska X is no longer allowed"). I can easily see why no one would like to have a generic subtitle binary format as blocker for matroska 1.0, but the more dependencies we get rid of before 1.0 the better. The smaller libmatroska gets the less you'll have to pay for your matroska-aware DVD-player. /Martin Nilsson From matroska at mani.user.lysator.liu.se Tue Feb 17 07:48:20 2004 From: matroska at mani.user.lysator.liu.se (Martin Nilsson) Date: Tue, 17 Feb 2004 07:48:20 +0100 Subject: [Matroska-devel] EBML In-Reply-To: <402CC7C1.3000307@free.fr> References: <402BAA2A.6060008@mani.user.lysator.liu.se> <402BE1B6.5050105@free.fr> <402C1745.5050206@mani.user.lysator.liu.se> <402CC7C1.3000307@free.fr> Message-ID: <4031B934.2070008@mani.user.lysator.liu.se> Steve Lhomme wrote: > That's why we have a DocType. It is not possible to merge 2 DocTypes in > one. And XML has more "space" to use namespaces. Because of the way we > try to store values, it would cost a lot of space to make all EBML > formats compatible with each others. No, there are several space efficient ways to combine several DocTypes. The most general is probably to define some sort of EBMLChangeDocType element. You could end up with elements that means different things in different contexts, but that is really not much of a problem. Normally when you combine XML languages you don't want to really mix them, just use one within the other. I am confident that both EBML and the DTD format can be extended in the future to allow for this. > Then what about references that could match many elements in > the same scope ? I think that the last instance of an element is what is referenced. > BTW, some SMTP servers don't like your matroska at mani.user.lysator.liu.se > address. You mean this: mail.lysator.liu.se[130.236.254.3] said: 554 : Recipient address rejected: Service unavailable, blocked by RBL+; [62.62.156.28] Contact postmaster if any questions occur Looks to me like your mail server (62.62.156.28) is blocked by RBL (http://mail-abuse.org/rbl+/) /Martin Nilsson From steve.lhomme at free.fr Tue Feb 17 09:44:18 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Tue, 17 Feb 2004 09:44:18 +0100 Subject: [Matroska-devel] Re: EBML In-Reply-To: <40318A78.4050507@mani.user.lysator.liu.se> References: <402BAA2A.6060008@mani.user.lysator.liu.se> <40318A78.4050507@mani.user.lysator.liu.se> Message-ID: <4031D462.8050105@free.fr> Martin Nilsson wrote: > I did an HTML version of the revesion before 2.4.0, but it was so > incredibly time consuming that I really didn't want to go through it > again. I did however look into building an XML format for RFC-like > texts, envisioning one XSLT to make the text version and one to make the > HTML version. As with many projects I didn't come too far, mostly > because no one else was interested. You might like to have a look at the DocBook file format. You can generate your doc in many formats then (HTML, PDF, text, etc). We started the Matroska specs in this format a while back, but we stopped to spend more time actually writing things (there is a learning curve but it's worth it). For the rest, I'll check the problems tonight. > Should really SignatureSlot be part of the EBML core standard? Probably not. Lots of basic formats that could use EBML would probably not need a complicated/versatile signature system support. It can be optional at the "EBML-children" level (like Matroska). > Isn't CRC-32 better implemented as a container element? Then the decoder > will know when it must calculate CRC-32 and the start and end is very > obvious. I also think the requirement for a CRC-32 element in every > level 1 elements should be dropped. It isn't even met in all files I've > found to experiment with. I think the CRC-32 is OK because it gives a simple way to every EBML user to have error detection at almost no cost. The level 1 requirement is for Matroska (and a guideline, not a formal rule) not for EBML. > Should we drop the string type? It is a complete subset of the utf8 type > and since I've defined ranges on utf8 strings to limit the range of > every byte, you can still define an element to have the same practical > meaning. It's a subset with more restrictions. These restrictions *are* sometimes needed, like when you have a URL for example. So I think it should be kept. Plus it is very common in the computer world... From steve.lhomme at free.fr Tue Feb 17 09:54:56 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Tue, 17 Feb 2004 09:54:56 +0100 Subject: [Matroska-devel] Re: EBML In-Reply-To: <4031B42B.2070509@mani.user.lysator.liu.se> References: <402BAA2A.6060008@mani.user.lysator.liu.se> <402BE1B6.5050105@free.fr> <402C21FC.6070206@mani.user.lysator.liu.se> <4031B42B.2070509@mani.user.lysator.liu.se> Message-ID: <4031D6E0.20000@free.fr> Martin Nilsson wrote: > To instead invest a lot of time and effort into a lot of really clever > compatibility things in the standard, as we did in ID3v2, is not a good > way. It makes the standard really cluttered, hard to interpret and > implement and in the end it turned out that every new version had to be > incompatible anyway. So it's better to come clean up front and tell > everyone that the next version will be incompatible. If you don't want > to deal with it, use our lib. The problem is that (almost) noone wants to use our lib (because it's C++) ;) > What I do like to see is a reduced library dependency. To completely > support matroska I would have to support RSA and ECDSA. SHA1 and MD5. > z-compression, bz-compression and lzo-compression. DES, 3DES, Twofish, > Blowfish and AES. To name a few standards. Nop, because nothing is defined in this territory so far. And actually libebml+libmatroska just need a good C++ compiler, no other libraries. > Similarly when something can be normalized into one unit or format I > think it should. Why allow for DisplayUnit to be both centimeters and > inches? Inch is _defined_ in centimeters. Or why have support for five I agree on that one. The authoring program can make the conversion anyway. > different subtitle formats when two would be enough; One format which I don't agree on that one. We want to support as many codec as possible (audio, video, subtitles). We'll let the authors/users decide what they prefer. And that's why Matroska is getting successful you can use combinations that are otherwise impossible in other containers due to marketing/license pressures. The problem you mention might be a problem for "standard" Matroska (hardware) players. Because they can't have an unlimited codec list. That's why we'll need to have some profiles for such players (and most of the time only a few format of audio/video/subs is actually in use). > the textual formats could be normalized into (EBML based?) and one This already exists (theoretically) and is called USF. > bitmap format (perhaps based on PNG with alpha channels?). I realize > that this is something that must have been up for discussion (sorry, I > have not had the time to read up in the list archive either), but I'll > just use these specific examples to back my general suggestion: reduce > dependencies, e.g. by disallowing things and normalizing data. We have made the container codec independent (unlike OGG). So these dependencies are dealt elsewhere. Which doesn't mean we're not responsible for it... From matroska at mani.user.lysator.liu.se Tue Feb 17 11:01:53 2004 From: matroska at mani.user.lysator.liu.se (Martin Nilsson) Date: Tue, 17 Feb 2004 11:01:53 +0100 Subject: [Matroska-devel] Re: EBML In-Reply-To: <4031D462.8050105@free.fr> References: <402BAA2A.6060008@mani.user.lysator.liu.se> <40318A78.4050507@mani.user.lysator.liu.se> <4031D462.8050105@free.fr> Message-ID: <4031E691.4090609@mani.user.lysator.liu.se> Steve Lhomme wrote: > I think the CRC-32 is OK because it gives a simple way to every EBML > user to have error detection at almost no cost. I have no problem with CRC-32 in the set of core elements, but with the way it is implemented. Since EBML implements a way of grouping elements together, why not use it (and get the other benefits I listed). Example: CRC32 := fe container { %children; CRC32Value := 1a19df41 binary [ size:4; ] } > It's a subset with more restrictions. These restrictions *are* sometimes > needed, like when you have a URL for example. So I think it should be > kept. Plus it is very common in the computer world... Yes but URL := 81 string; and URL := 81 utf8 [ range:32..126; ] mean exactly the same thing. The only reason would be to reduce typing, but there is a point in forcing americans to really consider if they need to disallow strings with funny characters. If we create type definitions, then one could just start the document with define types { string := utf8 [ range:32..126; ] } But then only 5% of the Matroska elements are string elements, so it wouldn't save much. URL is by the way a bad example since it is even more restricted than the character range 32-126. Interstingly enough 8-bit characters are allowed in URLs according to the first URL specification. They did however forget to specify which character set to use... /Martin Nilsson From matroska at mani.user.lysator.liu.se Tue Feb 17 11:30:15 2004 From: matroska at mani.user.lysator.liu.se (Martin Nilsson) Date: Tue, 17 Feb 2004 11:30:15 +0100 Subject: [Matroska-devel] Re: EBML In-Reply-To: <4031D6E0.20000@free.fr> References: <402BAA2A.6060008@mani.user.lysator.liu.se> <402BE1B6.5050105@free.fr> <402C21FC.6070206@mani.user.lysator.liu.se> <4031B42B.2070509@mani.user.lysator.liu.se> <4031D6E0.20000@free.fr> Message-ID: <4031ED37.20706@mani.user.lysator.liu.se> Steve Lhomme wrote: > The problem is that (almost) noone wants to use our lib (because it's > C++) ;) That should be OK for most people if the interface is easy to use from C. I took a quick look at libebml, but couldn't find a C header file to use. But it is true that some of the embedded systems lack C++ compilers (though it is usually possible to compile one). > >> What I do like to see is a reduced library dependency. To completely >> support matroska I would have to support RSA and ECDSA. SHA1 and MD5. >> z-compression, bz-compression and lzo-compression. DES, 3DES, Twofish, >> Blowfish and AES. To name a few standards. > > Nop, because nothing is defined in this territory so far. I don't understand what you mean by that. These standards are listed in the Matroska specification. To, as I said, completely support Matroska I would need to support these standards. Perhpas libmatroska doesn't support these standards, but then the application will. > And actually > libebml+libmatroska just need a good C++ compiler, no other libraries. Not even libc? :) > I don't agree on that one. We want to support as many codec as possible > (audio, video, subtitles). We'll let the authors/users decide what they > prefer. And that's why Matroska is getting successful you can use > combinations that are otherwise impossible in other containers due to > marketing/license pressures. Let's not confuse different kinds of encoding here. You can not convert between different video encodings without distorting the data. You can not convert between different audio encodings without distorting data. You however can convert between different subtitle formats without distorting data. That's why I think the long term strategy should be to get rid of as many subtitle formats as possible on the player side. You can compare this to character encodings. There are about 1200 different character encodings that I am aware of (http://www.iana.org/assignments/character-sets has the major ones). Given the big amount of code and data needed to support all these encodings you would prefer to keep that away from the end user and instead use e.g. UTF-8 for all data going to the user. > > This already exists (theoretically) and is called USF. > It's not good enough. /Martin Nilsson From steve.lhomme at free.fr Tue Feb 17 13:27:23 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Tue, 17 Feb 2004 13:27:23 +0100 Subject: [Matroska-devel] Re: EBML In-Reply-To: <4031ED37.20706@mani.user.lysator.liu.se> References: <402BAA2A.6060008@mani.user.lysator.liu.se> <402BE1B6.5050105@free.fr> <402C21FC.6070206@mani.user.lysator.liu.se> <4031B42B.2070509@mani.user.lysator.liu.se> <4031D6E0.20000@free.fr> <4031ED37.20706@mani.user.lysator.liu.se> Message-ID: <403208AB.3050406@free.fr> Martin Nilsson wrote: > That should be OK for most people if the interface is easy to use from > C. I took a quick look at libebml, but couldn't find a C header file to > use. But it is true that some of the embedded systems lack C++ compilers > (though it is usually possible to compile one). Well, there is no point in making a C wrapper at the moment. If one's platform has a C++ compiler, one can make a minimal wrapper with only the needed part (or even use C++ directly). If not the code won't compile anyway. >> Nop, because nothing is defined in this territory so far. > > I don't understand what you mean by that. These standards are listed in > the Matroska specification. To, as I said, completely support Matroska I > would need to support these standards. Perhpas libmatroska doesn't > support these standards, but then the application will. Well, OK. It *is* written in the specs but I'm not sure it's in use anywhere so far. We'll have to ask Jory who made an encryption/decryption filter in DirectShow. Otherwise we can probably safely drop them from that place and move it to the Matroska specs and not in the 1. freezed version. >> And actually libebml+libmatroska just need a good C++ compiler, no >> other libraries. > > > Not even libc? :) I consider this as part of the compiler. Otherwise no code would ever run... > Let's not confuse different kinds of encoding here. You can not convert > between different video encodings without distorting the data. You can > not convert between different audio encodings without distorting data. > You however can convert between different subtitle formats without > distorting data. That's why I think the long term strategy should be to > get rid of as many subtitle formats as possible on the player side. This is not true, because some subs format are in image formats. For the text based ones it's not even true neither. Because some formats support some features and others don't (outlines, fonts, icons, etc). That would mean *the* one we chose has to support everything and more. Of course USF is the closer. >> This already exists (theoretically) and is called USF. > > It's not good enough. Then propose the missing parts. Because the format is still in alpha stage. I'm sure they will welcome any additions changes. (of course if you have the time to). From paul at msn.com Wed Feb 18 07:43:23 2004 From: paul at msn.com (Paul Bryson) Date: Wed, 18 Feb 2004 00:43:23 -0600 Subject: [Matroska-devel] Re: Re: EBML References: <402BAA2A.6060008@mani.user.lysator.liu.se><402BE1B6.5050105@free.fr><402C21FC.6070206@mani.user.lysator.liu.se> <4031B42B.2070509@mani.user.lysator.liu.se> Message-ID: I was writing this originally and stopped most of the way through to take a shower. When I got back my system was locked and I had to reboot. So if some of the ideas seem short, that is why. "Martin Nilsson" wrote... > What I do like to see is a reduced library dependency. To completely > support matroska I would have to support RSA and ECDSA. SHA1 and MD5. These are all part of the Signature and are there only to verify data integrity. There definately isn't any requirement to have this in a lib as you don't need to use it to decode any of the data. Regardless, it was removed for the version 1.0 specs. It is not used yet, and can definately be reworked. > z-compression, bz-compression and lzo-compression. DES, 3DES, Twofish, > Blowfish and AES. To name a few standards. This is a little bit different and shouldn't be a library dependancy anyway. The way that this should work is through a plugin system that allows chaining. For example, you COULD have an MPEG-4 stream that was compressed with ZLIB, then encrypted with AES, and then compressed with LZO1x. On playback, the data would be decompressed, decrypted, and then decompressed again before being handed to the MPEG-4 decoder. While there are different reasons to use the generic compression methods, one of the only reasons to use encryption is for DRM. And because DRM will likely never be added directly in the lib, a plugin system NEEDS to be developed so that a new plugin could be added, independantly of the lib so that new DRM methods can be used. Because (to my knowledge) this system has never been developed, deciding on how exactly to handle it in the lib has been slow. But it is obvious it needs to be plugin based. > I don't think there is something wrong with deciding for the user in > some of these issues. AES is proven better than the other cipher > algorithms. SHA1 is proven better than MD5. The NIST reports are there > for everyone to read, so there is really no technical reason to allow > all of these algorithms. Its all about options. When deciding which compression method would be best for storing VobSubs, Mosu tested not only the encoding and decoding speed of different libraries, but also how well they handled errors. Even if a method is technically better, existing libraries my make a different method more practical. And as time progresses, the options change. So, instead we leave the options up to developers for what to use. Matroska is a general purpose container. The idea is that if two people store the same type of data in Matroska, they should both be able to decode each others work. We don't define WHAT to store in it, but rather HOW to store it. An excellent example can be seen from looking at current Matroska files in the wild. The majority of them use RV9 video with AC3 and Vorbis audio, as well as UTF-8 subtitles. There is no way that we could have predicted that RV9 would have become one of the most popular choices. If we had limited it, then we would have missed this boost in popularity as well as our goals to be a general container that can store anything. > Similarly when something can be normalized into one unit or format I > think it should. Why allow for DisplayUnit to be both centimeters and > inches? Inch is _defined_ in centimeters. Yes, storing the exact same data in two different formats is pretty redundant. However, since the Height and Width are both u-integer, perhaps a finer unit of measurement should be used? Maybe millimeter? > Or why have support for five > different subtitle formats when two would be enough; One format which > the textual formats could be normalized into (EBML based?) and one > bitmap format (perhaps based on PNG with alpha channels?). I realize > that this is something that must have been up for discussion (sorry, I > have not had the time to read up in the list archive either), but I'll > just use these specific examples to back my general suggestion: reduce > dependencies, e.g. by disallowing things and normalizing data. Limiting the number of subtitle formats definately wouldn't decrease the size of the lib. Subtitles are just another generic form of data in Matroska. The same as Video and Audio. Its all generic. Matroska doesn't care what it is, it depends on whatever system is being used to decode the data in the proper way. On a different note, PNG would be very desireable with its 255 levels of alpha. Current systems are not strong enough to be depended on to decode PNG subtitles without causing a pause in the video. But, in the next couple of years this could become a real possibility. Jory has already designed a PNG video codec that supports RGB, YUV, and YV12, so we know it is possible. > The > smaller libmatroska gets the less you'll have to pay for your > matroska-aware DVD-player. I agree. But remember, that DVD players will never be able to handle most Matroska files that are already out there. I am pretty sure that no DVD player will ever play back RV9 or RV10. Also, it is not likely that any will ever provide full UTF-8 support as the full Arial font is around 20MB. The things that DVD players might possibly support are MPEG-1/2/4 in Matroska with VobSub subtitles, as well as Matroska audio-only files using formats that they already support. Pamel From paul at msn.com Wed Feb 18 08:16:29 2004 From: paul at msn.com (Paul Bryson) Date: Wed, 18 Feb 2004 01:16:29 -0600 Subject: [Matroska-devel] Re: Re: EBML References: <402BAA2A.6060008@mani.user.lysator.liu.se> <40318A78.4050507@mani.user.lysator.liu.se> Message-ID: "Martin Nilsson" wrote... > Paul Bryson wrote: > > Sometimes it was difficult to understand exactly what a given > > field was for, and in working with the Matroska Tags, I would simply link to > > those specs hoping that others would understand the purpose. > > Understandable, but in my opinion wrong. Just include what you really > have a need for. The way specifications and libraries tend to grow is > probably one of the more difficult problems to overcome/avoid. You need > to have an objective look at your specification and question what is > good and what shouldn't be there, and that is _really_ hard. The decision was made to support every tag from every common consumer tagging format. There are of course a few items that are container specific, so they weren't used. > WRT tagging > I would suggest you to drop support for AENC, since no one uses it, and Matroska has its own methods for encryption as discussed earlier. This was only listed for the possibility of importing DRM'd MP3 files. However, if no one uses it, then it is not needed here. > EQU2, since it is underspecified. Instead there should have been a frame > with spectral average which could be used as input to a function that > generated equalization curves. Generally speaking though it would all be > a waste of time since people really only want to have volume > equalization between files (We did some feature research together with > mp3.com a while back). On your advice, I will remove this. The Audio_Gain/Peak fields should be sufficient as they use an already defined standard. Apparently I forgot to commit the version of the tags specs where this was updated. This isn't yet finalized though as there is a little discussion going on about how to define the scopes of these tags specifically. > ChapterUID exists both in Chapters and Tagging. TrackUID exists both in > Track and Tagging. Duration exists both in Info and Cluster. These three > are just naming problems, since I decided that element names should be > unique in a DTD. This is my fault, and I actually wondered if anyone would comment on it when I did it. These should probably be renamed under the tags section to TagChapterUID and TagTrackUID. Does anyone have any opinion about this? Pamel BTW, I really wish I was awake at the same time that you guys have this active discussion. From matroska at mani.user.lysator.liu.se Wed Feb 18 09:19:53 2004 From: matroska at mani.user.lysator.liu.se (Martin Nilsson) Date: Wed, 18 Feb 2004 09:19:53 +0100 Subject: [Matroska-devel] Re: Re: EBML In-Reply-To: References: <402BAA2A.6060008@mani.user.lysator.liu.se> <402BE1B6.5050105@free.fr> <402C21FC.6070206@mani.user.lysator.liu.se> <4031B42B.2070509@mani.user.lysator.liu.se> Message-ID: <40332029.2010806@mani.user.lysator.liu.se> Paul Bryson wrote: > When deciding which compression method would be best for > storing VobSubs, Mosu tested not only the encoding and decoding speed of > different libraries, but also how well they handled errors. Even if a method is > technically better, existing libraries my make a different method more > practical. I know that Opera made a PNG library of their own last year, reducing the size from 160K to 5K. It is fast enough to decode images on mobile phones. So most of these issues can be solved if you are determined to, e.g. by working closer to developers of other technology. But again, I have no problems to see why this hasn't been done. > Limiting the number of subtitle formats definately wouldn't decrease the size of > the lib. Subtitles are just another generic form of data in Matroska. > The same as Video and Audio. Its all generic. Matroska doesn't care > what it is, it depends on whatever system is being used to decode the > data in the proper way. The reason why I mentioned subtitles in the first place is beacuse there is some sort of interpretation of the formats when separating them into Track->CodecPrivate and Cluster->Block. Since there is interpretation, why not also have normalization, or at least "compression" to a binary format? One could note that the segmentation of SSA files didn't help us with our video player, since our SSA decoder worked on complete SSA files. Skip to specific words in the subtitles are also a more costly operation now that you have to seek through more data. But I guess that I am talking for no reason. The "correct" solution from Matroska point of view is for me to present a new format and hope for its adoption. > On a different note, PNG would be very desireable with its 255 levels of alpha. > Current systems are not strong enough to be depended on to decode PNG subtitles > without causing a pause in the video. You can't be referring to systems made this century... > Also, it is not likely that any will ever provide full UTF-8 support as the full > Arial font is around 20MB. As always it's a matter of competence. You can get a Unicode font supporting all languages, optimized for TV-resolution, from Bitstream that is around 3MB. You can cluster that one into codepages and compress them separately. /Martin Nilsson From unmei at matroska.org Wed Feb 18 13:12:40 2004 From: unmei at matroska.org (unmei) Date: Wed, 18 Feb 2004 13:12:40 +0100 Subject: [Matroska-devel] Re: Re: EBML (subitles) In-Reply-To: <40332029.2010806@mani.user.lysator.liu.se> References: <402BAA2A.6060008@mani.user.lysator.liu.se> <402BE1B6.5050105@free.fr> <402C21FC.6070206@mani.user.lysator.liu.se> <4031B42B.2070509@mani.user.lysator.liu.se> <40332029.2010806@mani.user.lysator.liu.se> Message-ID: <403356B8.2060608@matroska.org> Martin Nilsson wrote: > The reason why I mentioned subtitles in the first place is beacuse > there is some sort of interpretation of the formats when separating > them into Track->CodecPrivate and Cluster->Block. Since there is > interpretation, why not also have normalization, or at least > "compression" to a binary format? One could note that the segmentation > of SSA files didn't help us with our video player, since our SSA > decoder worked on complete SSA files. Skip to specific words in the > subtitles are also a more costly operation now that you have to seek > through more data. > > But I guess that I am talking for no reason. The "correct" solution > from Matroska point of view is for me to present a new format and hope > for its adoption. > sorry to jump into this discussion a bit, but i snapped up the subtitles parts :) i'm currently developing a new graphical subtitle format. It's in the early implementation and still change phase but it shows good results so far. I hope it will allow to compress full color subtitles at about the size of (4 color) sub/idx. I think 1 mb per stream (language) is possible and maybe even 400 or less kb could be attained. I designed it to be not CPU demanding by not incoprorating sophisticated compression schemes (_not_ like png, lzw et all) but my current encoder is extremely slow (probably because i re-resize the target array quite often and hopefully more avoidable stupidities). What i actually wanted to stress is the format is very heavy on the header, about 90% of all data is in the header and must be decompressed before playback. So for me its nice to hear players prefer to handle subtitles as one big chunk and do not rely on too much on "streaming" them. From chris at matroska.org Wed Feb 18 13:53:19 2004 From: chris at matroska.org (Christian HJ Wiesner) Date: Wed, 18 Feb 2004 13:53:19 +0100 Subject: [Matroska-devel] Reading AR flag from MKV track header in MPC ? Message-ID: <4033603F.8010800@matroska.org> Hi Gabest, allow me a quick question, copied to the matroska-devel list : With Zoomplayer supporting reading the matroska AR flag from the track header recently there are now alltogether 6 players supporting this important feature : TCMP VLC Xine mplayer Koolplaya Zoomplayer but MPC, probably the most used player for matroska files, still needs a build of ffdshow with overlay enabled. Now very unfortunately all the latest ffdshow builds with support for XviD beta versions have overlay broken :-( ..... . SysKin from the XviD team implemented passing of the VIDEOINFOHEADER2 struct in the latest XviD decoder filters, so this works fine with AR correction now, but then again we cant add this filter to our installer packs because there is the complete xvidcore coming with it, and i am afraid of licensing problems when doing so. Long speech, short message : Is there any chance you could use Toff's MKV track info interface, that he added to the latest matroska splitter, to read AR info from the MKV direcly in MPC ?? Thanks for a short answer Christian From chris at matroska.org Wed Feb 18 16:27:17 2004 From: chris at matroska.org (Christian HJ Wiesner) Date: Wed, 18 Feb 2004 16:27:17 +0100 Subject: [Matroska-devel] Gstreamer and matroska - the opensource answer to VideoforWindows/AVI and Quicktime/MOV ? Message-ID: <40338455.3050905@matroska.org> Hi, this email is more to be seen as a brainstorming rather than an announcement or the like. My excuses go to the Gstreamer guys about copying their list, i dont know if they are interested in this kind of thinking at all. I was recently becoming aware that matroska's only hope to become established as standard, if this is ever going to happen, is versatility and flexibility. In short, to become a 100% replacement for good old AVI, currently the most used container format out there, probably on rivalled by MPEG. The reason this container is/was used so much can be explained when knowing its the standard container for VfW ( Video for Windows ), Redmond's old Media Framework. http://fourcc.org and http://abcavi.com give a pretty good impression how many different audio and video codecs had been developed for this framework in the past, obviously because of M$'s domination in the Multimedia scene and the sheer number of copies out in the wild. Now, as we all are well aware, both VCM ( the video codec API ) and ACM ( the audio codec API ) are completely outdated and can not support most of the modern compression formats anymore, leading to a number of problems and incompatibilities, of which VBR MP3 async and the 'packed bitstream' hack are the two most obvious to name. The successor of VfW, DirectShow, has never played the same role if it comes to video editing and video creation/encoding, due to a number of pretty bad limitations with respect to accessing the chain once its started. In short, DShow is wanting to much automatism here, stealing developers the possibilitites they request if they code a video application based on it. For this reason, DShow is today mainly used for playback and capturing. The big 'competitor' to VfW has always been Quicktime in the past, with MOV as the standard container. It is very well implemented into Mac's, and like DirectShow for Windows it can be seen as a fixed part of the OS. Its coming with a nice, open video and audio codec API also, which is much more powerful then VCM/ACM, and same is valid for the container. However, there is no working implementation of Quicktime ( the framework ) for Linux, at least i am not aware of such, and the Windows implementation of it sucks badly ( not to mention its payware if it should do more than just playback ). I was recently thinking that Gstreamer and matroska together could become the opensource counterpart to both of the framework/container combinations listed above, and am asking for opinions on this ? Once we really succeed in porting Gstreamer to win32 ( maybe even MacOSX in future ? ), and come up with a powerful but not overly complex codec API, sitting on top of the gstreamer plugin API ( via a wrapper ), do you think codec developers could actually consider supporting this API, chosing MKV as their 'preferred' container ? DivX.com have plans to release DivX6 from AVI and VCM, as well as from the MPEG4 standard in general. They have plans for a new, DivX6 specific container format i heard, and want to establish themselves as a new video standard that way, even with hardware support. Good luck, thats all i can say here. They would probably be better off to use their existing market power and support us to become the first true x-platform media framework and media format ? The reason DivX became so big is simply because it could be used from Virtualdub, and in AVI as a well supported container. If they now try to establish their own stuff, supported only by a small number of apps, and everything coded by themselves, they are very likely to fail IMO. Look at Real Networks, they understood this and went all the way back, trying to offer Helix as another universal framework, advertising it in the OSS scene even, and with great x-platform support, but still limited in terms of supported formats in it, and with only one ( for win32 sucky ) player for it. I am well aware gstreamer doesnt need matroska at all. Your way is clear, becoming the best media framework for the Linux world, and you guys wont mind if your project is ported to other OSes also, as this can only help you to achieve your goals, for sure. You could also settle for MOV as standard container, as there are currently no features realized in matroska that MOV cant do also, or have no standard container at all. On the other hand, you could win a couple of contributors and fans with such an 'alliance', if you allow me to name it like that. Opinions please, and use the 'reply all' button if i may ask for that, to copy both lists. Stupid idea ? Useless ? Possible ? Tell me what you think .... Regards Christian From paul at msn.com Wed Feb 18 16:57:52 2004 From: paul at msn.com (Paul Bryson) Date: Wed, 18 Feb 2004 09:57:52 -0600 Subject: [Matroska-devel] Re: Re: Re: EBML References: <402BAA2A.6060008@mani.user.lysator.liu.se><402BE1B6.5050105@free.fr><402C21FC.6070206@mani.user.lysator.liu.se><4031B42B.2070509@mani.user.lysator.liu.se> <40332029.2010806@mani.user.lysator.liu.se> Message-ID: "Martin Nilsson" wrote... > Paul Bryson wrote: > > Limiting the number of subtitle formats definately wouldn't decrease the size of > > the lib. Subtitles are just another generic form of data in Matroska. The > > same as Video and Audio. Its all generic. Matroska doesn't care what > > it is, it depends on whatever system is being used to decode the data > > in the proper way. > > The reason why I mentioned subtitles in the first place is beacuse there > is some sort of interpretation of the formats when separating them into > Track->CodecPrivate and Cluster->Block. Since there is interpretation, > why not also have normalization, or at least "compression" to a binary > format? I am not sure what you are talking about here. Could you rephrase this? > But I guess that I am talking for no reason. The "correct" solution from > Matroska point of view is for me to present a new format and hope for > its adoption. That is correct. Matroska is not about defining what compression formats to use, it is about offering a common platform for all formats to be used on. > > On a different note, PNG would be very desireable with its 255 levels of alpha. > > Current systems are not strong enough to be depended on to decode PNG subtitles > > without causing a pause in the video. > > You can't be referring to systems made this century... Well, tests were made using libpng, so results may vary if using another lib such as the Opera PNG lib. Using a 24fps PNG clip at 512x384, and no audio, resulted in a file that was playable with a slight stutter on my Athlon 2100+. Decoding PNG subtitles at full DVD res or HDTV, AND decoding the video, AND overlaying the PNG image on top of the video with full alpha transparency would indeed result in stuttering. Current video players simply don't buffer well enough. Some people want to prerender complicated SSA scripts into PNG subtitles. That definately isn't doable yet. But when computers are fast enough, it will be done. > > Also, it is not likely that any will ever provide full UTF-8 support as the full > > Arial font is around 20MB. > > As always it's a matter of competence. You can get a Unicode font > supporting all languages, optimized for TV-resolution, from Bitstream > that is around 3MB. You can cluster that one into codepages and compress > them separately. That sounds like an excellent option. Do it and define a new standard. If the decoder filters work well, and creation tools are easy to use, it will be adopted. Pamel From jcsston at wiesneronline.net Fri Feb 20 09:34:00 2004 From: jcsston at wiesneronline.net (Jory) Date: Fri, 20 Feb 2004 02:34:00 -0600 Subject: [Matroska-devel] Incomplete Matroska File, crashes libebml Message-ID: <000801c3f78c$69882cc0$0200a8c0@jcsston> I have an incomplete Matroska file that libebml crashes on when trying to read the ebml header. I uploaded it to http://www.mycgiserver.com/~jcsston/simp.avi.mkv.zip Do not extract this with the Shell Ext installed I did a little debugging and it looks like it is stuck in a loop in EbmlElement.cpp:266 - 270. Jory From paul at msn.com Fri Feb 20 16:12:12 2004 From: paul at msn.com (Paul Bryson) Date: Fri, 20 Feb 2004 09:12:12 -0600 Subject: [Matroska-devel] Re: Incomplete Matroska File, crashes libebml References: <000801c3f78c$69882cc0$0200a8c0@jcsston> Message-ID: "Jory" wrote... > Do not extract this with the Shell Ext installed I really need to learn to read emails before clicking on the links. Pamel From gjc at inescporto.pt Fri Feb 20 15:28:52 2004 From: gjc at inescporto.pt (Gustavo J. A. M. Carneiro) Date: Fri, 20 Feb 2004 14:28:52 +0000 Subject: [Matroska-devel] Re: [gst-devel] Gstreamer and matroska - the opensource answer to VideoforWindows/AVI and Quicktime/MOV ? In-Reply-To: <40338455.3050905@matroska.org> References: <40338455.3050905@matroska.org> Message-ID: <1077287332.27349.14.camel@spectrum.inescn.pt> I wish I could be sufficiently well informed to make insightful comments about this issue. Since I'm not, I can only comment on the name. 'matroska' is a really poor name. It doesn't mean anything to most people. And what would the adopted file extension? That's a rhetorical question, as I'm sure it would sound bad. Why can't open source projects come up with better names? GStreamer, for example, is a good name. It is all about media pipelines. For a multimedia container format, why can't you come up with a better name, like Extensible Media Stream (.ems), or something like that. Another question, how does the matroska container relate to the generic (and also poorly named) OGG container? Is it really technically better? I'm just asking, I have no idea. Best regards. A Qua, 2004-02-18 ?s 15:27, Christian HJ Wiesner escreveu: > Hi, > > this email is more to be seen as a brainstorming rather than an > announcement or the like. My excuses go to the Gstreamer guys about > copying their list, i dont know if they are interested in this kind of > thinking at all. > > I was recently becoming aware that matroska's only hope to become > established as standard, if this is ever going to happen, is versatility > and flexibility. In short, to become a 100% replacement for good old > AVI, currently the most used container format out there, probably on > rivalled by MPEG. The reason this container is/was used so much can be > explained when knowing its the standard container for VfW ( Video for > Windows ), Redmond's old Media Framework. http://fourcc.org and > http://abcavi.com give a pretty good impression how many different audio > and video codecs had been developed for this framework in the past, > obviously because of M$'s domination in the Multimedia scene and the > sheer number of copies out in the wild. Now, as we all are well aware, > both VCM ( the video codec API ) and ACM ( the audio codec API ) are > completely outdated and can not support most of the modern compression > formats anymore, leading to a number of problems and incompatibilities, > of which VBR MP3 async and the 'packed bitstream' hack are the two most > obvious to name. > > The successor of VfW, DirectShow, has never played the same role if it > comes to video editing and video creation/encoding, due to a number of > pretty bad limitations with respect to accessing the chain once its > started. In short, DShow is wanting to much automatism here, stealing > developers the possibilitites they request if they code a video > application based on it. For this reason, DShow is today mainly used for > playback and capturing. > > The big 'competitor' to VfW has always been Quicktime in the past, with > MOV as the standard container. It is very well implemented into Mac's, > and like DirectShow for Windows it can be seen as a fixed part of the > OS. Its coming with a nice, open video and audio codec API also, which > is much more powerful then VCM/ACM, and same is valid for the container. > However, there is no working implementation of Quicktime ( the framework > ) for Linux, at least i am not aware of such, and the Windows > implementation of it sucks badly ( not to mention its payware if it > should do more than just playback ). > > I was recently thinking that Gstreamer and matroska together could > become the opensource counterpart to both of the framework/container > combinations listed above, and am asking for opinions on this ? Once we > really succeed in porting Gstreamer to win32 ( maybe even MacOSX in > future ? ), and come up with a powerful but not overly complex codec > API, sitting on top of the gstreamer plugin API ( via a wrapper ), do > you think codec developers could actually consider supporting this API, > chosing MKV as their 'preferred' container ? > > DivX.com have plans to release DivX6 from AVI and VCM, as well as from > the MPEG4 standard in general. They have plans for a new, DivX6 specific > container format i heard, and want to establish themselves as a new > video standard that way, even with hardware support. Good luck, thats > all i can say here. They would probably be better off to use their > existing market power and support us to become the first true x-platform > media framework and media format ? The reason DivX became so big is > simply because it could be used from Virtualdub, and in AVI as a well > supported container. If they now try to establish their own stuff, > supported only by a small number of apps, and everything coded by > themselves, they are very likely to fail IMO. Look at Real Networks, > they understood this and went all the way back, trying to offer Helix as > another universal framework, advertising it in the OSS scene even, and > with great x-platform support, but still limited in terms of supported > formats in it, and with only one ( for win32 sucky ) player for it. > > I am well aware gstreamer doesnt need matroska at all. Your way is > clear, becoming the best media framework for the Linux world, and you > guys wont mind if your project is ported to other OSes also, as this can > only help you to achieve your goals, for sure. You could also settle for > MOV as standard container, as there are currently no features realized > in matroska that MOV cant do also, or have no standard container at all. > On the other hand, you could win a couple of contributors and fans with > such an 'alliance', if you allow me to name it like that. Opinions > please, and use the 'reply all' button if i may ask for that, to copy > both lists. Stupid idea ? Useless ? Possible ? Tell me what you think .... > > Regards > > Christian > > > > ------------------------------------------------------- > SF.Net is sponsored by: Speed Start Your Linux Apps Now. > Build and deploy apps & Web services for Linux with > a free DVD software kit from IBM. Click Now! > http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click > _______________________________________________ > gstreamer-devel mailing list > gstreamer-devel at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/gstreamer-devel -- Gustavo Jo?o Alves Marques Carneiro The universe is always one step beyond logic. From chris at matroska.org Fri Feb 20 16:39:35 2004 From: chris at matroska.org (Christian HJ Wiesner) Date: Fri, 20 Feb 2004 16:39:35 +0100 Subject: [Matroska-devel] Re: [Matroska-general] Re: [gst-devel] Gstreamer and matroska - the opensource answer to VideoforWindows/AVI and Quicktime/MOV ? In-Reply-To: <1077287332.27349.14.camel@spectrum.inescn.pt> References: <40338455.3050905@matroska.org> <1077287332.27349.14.camel@spectrum.inescn.pt> Message-ID: <40362A37.8090701@matroska.org> Hi Gustavo Gustavo J. A. M. Carneiro wrote: > I wish I could be sufficiently well informed to make insightful >comments about this issue. Since I'm not, I can only comment on the >name. 'matroska' is a really poor name. It doesn't mean anything to >most people. And what would the adopted file extension? That's a >rhetorical question, as I'm sure it would sound bad. > Why can't open source projects come up with better names? GStreamer, >for example, is a good name. It is all about media pipelines. For a >multimedia container format, why can't you come up with a better name, >like Extensible Media Stream (.ems), or something like that. > > Did nobody tell you the times for 3 letter acronyms are definitely over since some years now ;-) ? matroska was derived from a similar project with such a name, called MCF ( Multimedia Container Format ). Now, when we tried to register MCF.org for the project these days, we had to face that the 'Minnesota Cycling Federation' was faster :-D ..... lol ..... same for mcf.com, mcf.net, etc. The name matroska comes from the Russian word 'matrioshka' , and it has a related meaning. A media container can contain many different streams like an envelope, similar to the Russian dolls giving it its name, where one doll is put into the other. Sorry you dont like the name, i am pretty happy about it because its easy to remember and quite unique. Try googling for 'matroska', and you know what i mean. > Another question, how does the matroska container relate to the >generic (and also poorly named) OGG container? Is it really technically >better? I'm just asking, I have no idea. > Best regards. > A container is always a compromise, you wont find the one container being perfect in every respect. Lets say matroska is different than Ogg and will serve you better for certain things like video editing and future extendability. Ogg has other strong sides also, thats about it. Up to now, i cant see anything in the Ogg specs that would make it the preferred choice for a general use container, to put many different formats into it. But this may change one day, you never know. Best regards Christian From gjc at inescporto.pt Fri Feb 20 18:09:56 2004 From: gjc at inescporto.pt (Gustavo J. A. M. Carneiro) Date: Fri, 20 Feb 2004 17:09:56 +0000 Subject: [Matroska-devel] Re: [gst-devel] Gstreamer and matroska - the opensource answer to VideoforWindows/AVI and Quicktime/MOV ? In-Reply-To: <4036313E.4010900@imn.htwk-leipzig.de> References: <40338455.3050905@matroska.org> <1077287332.27349.14.camel@spectrum.inescn.pt> <4036313E.4010900@imn.htwk-leipzig.de> Message-ID: <1077296996.21153.5.camel@spectrum.inescn.pt> A Sex, 2004-02-20 ?s 16:09, Stefan Kost escreveu: > Do you really don't know what a matroska is? Honestly, I didn't know. But it's my fault. Lack of culture :-P I just asked a couple of people here, and they tell me it is doll with another doll inside, and another inside that one, and so on. > Personaly it find that name quite cool for a (recursive) media *container*. Yeah, now that I know what it is, it does sound a bit better. -- Gustavo Jo?o Alves Marques Carneiro The universe is always one step beyond logic. From kost at imn.htwk-leipzig.de Fri Feb 20 17:09:34 2004 From: kost at imn.htwk-leipzig.de (Stefan Kost) Date: Fri, 20 Feb 2004 17:09:34 +0100 Subject: [Matroska-devel] Re: [gst-devel] Gstreamer and matroska - the opensource answer to VideoforWindows/AVI and Quicktime/MOV ? In-Reply-To: <1077287332.27349.14.camel@spectrum.inescn.pt> References: <40338455.3050905@matroska.org> <1077287332.27349.14.camel@spectrum.inescn.pt> Message-ID: <4036313E.4010900@imn.htwk-leipzig.de> Do you really don't know what a matroska is? Personaly it find that name quite cool for a (recursive) media *container*. stefan Gustavo J. A. M. Carneiro wrote: > I wish I could be sufficiently well informed to make insightful > comments about this issue. Since I'm not, I can only comment on the > name. 'matroska' is a really poor name. It doesn't mean anything to > most people. And what would the adopted file extension? That's a > rhetorical question, as I'm sure it would sound bad. > > Why can't open source projects come up with better names? GStreamer, > for example, is a good name. It is all about media pipelines. For a > multimedia container format, why can't you come up with a better name, > like Extensible Media Stream (.ems), or something like that. > > Another question, how does the matroska container relate to the > generic (and also poorly named) OGG container? Is it really technically > better? I'm just asking, I have no idea. > > Best regards. > > A Qua, 2004-02-18 ?s 15:27, Christian HJ Wiesner escreveu: > >>Hi, >> >>this email is more to be seen as a brainstorming rather than an >>announcement or the like. My excuses go to the Gstreamer guys about >>copying their list, i dont know if they are interested in this kind of >>thinking at all. >> >>I was recently becoming aware that matroska's only hope to become >>established as standard, if this is ever going to happen, is versatility >>and flexibility. In short, to become a 100% replacement for good old >>AVI, currently the most used container format out there, probably on >>rivalled by MPEG. The reason this container is/was used so much can be >>explained when knowing its the standard container for VfW ( Video for >>Windows ), Redmond's old Media Framework. http://fourcc.org and >>http://abcavi.com give a pretty good impression how many different audio >>and video codecs had been developed for this framework in the past, >>obviously because of M$'s domination in the Multimedia scene and the >>sheer number of copies out in the wild. Now, as we all are well aware, >>both VCM ( the video codec API ) and ACM ( the audio codec API ) are >>completely outdated and can not support most of the modern compression >>formats anymore, leading to a number of problems and incompatibilities, >>of which VBR MP3 async and the 'packed bitstream' hack are the two most >>obvious to name. >> >>The successor of VfW, DirectShow, has never played the same role if it >>comes to video editing and video creation/encoding, due to a number of >>pretty bad limitations with respect to accessing the chain once its >>started. In short, DShow is wanting to much automatism here, stealing >>developers the possibilitites they request if they code a video >>application based on it. For this reason, DShow is today mainly used for >>playback and capturing. >> >>The big 'competitor' to VfW has always been Quicktime in the past, with >>MOV as the standard container. It is very well implemented into Mac's, >>and like DirectShow for Windows it can be seen as a fixed part of the >>OS. Its coming with a nice, open video and audio codec API also, which >>is much more powerful then VCM/ACM, and same is valid for the container. >>However, there is no working implementation of Quicktime ( the framework >>) for Linux, at least i am not aware of such, and the Windows >>implementation of it sucks badly ( not to mention its payware if it >>should do more than just playback ). >> >>I was recently thinking that Gstreamer and matroska together could >>become the opensource counterpart to both of the framework/container >>combinations listed above, and am asking for opinions on this ? Once we >>really succeed in porting Gstreamer to win32 ( maybe even MacOSX in >>future ? ), and come up with a powerful but not overly complex codec >>API, sitting on top of the gstreamer plugin API ( via a wrapper ), do >>you think codec developers could actually consider supporting this API, >>chosing MKV as their 'preferred' container ? >> >>DivX.com have plans to release DivX6 from AVI and VCM, as well as from >>the MPEG4 standard in general. They have plans for a new, DivX6 specific >>container format i heard, and want to establish themselves as a new >>video standard that way, even with hardware support. Good luck, thats >>all i can say here. They would probably be better off to use their >>existing market power and support us to become the first true x-platform >>media framework and media format ? The reason DivX became so big is >>simply because it could be used from Virtualdub, and in AVI as a well >>supported container. If they now try to establish their own stuff, >>supported only by a small number of apps, and everything coded by >>themselves, they are very likely to fail IMO. Look at Real Networks, >>they understood this and went all the way back, trying to offer Helix as >>another universal framework, advertising it in the OSS scene even, and >>with great x-platform support, but still limited in terms of supported >>formats in it, and with only one ( for win32 sucky ) player for it. >> >>I am well aware gstreamer doesnt need matroska at all. Your way is >>clear, becoming the best media framework for the Linux world, and you >>guys wont mind if your project is ported to other OSes also, as this can >>only help you to achieve your goals, for sure. You could also settle for >>MOV as standard container, as there are currently no features realized >>in matroska that MOV cant do also, or have no standard container at all. >>On the other hand, you could win a couple of contributors and fans with >>such an 'alliance', if you allow me to name it like that. Opinions >>please, and use the 'reply all' button if i may ask for that, to copy >>both lists. Stupid idea ? Useless ? Possible ? Tell me what you think .... >> >>Regards >> >>Christian >> >> >> >>------------------------------------------------------- >>SF.Net is sponsored by: Speed Start Your Linux Apps Now. >>Build and deploy apps & Web services for Linux with >>a free DVD software kit from IBM. Click Now! >>http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click >>_______________________________________________ >>gstreamer-devel mailing list >>gstreamer-devel at lists.sourceforge.net >>https://lists.sourceforge.net/lists/listinfo/gstreamer-devel -- \|/ Stefan Kost <@ @> private business +-oOO-(_)-OOo------------------------------------------------------ - - - - - | __ Address Simildenstr. 5 HTWK Leipzig, Fb IMN, Postfach 301166 | /// 04277 Leipzig 04251 Leipzig | __ /// Germany Germany | \\\/// Phone +49341 2253538 +49341 30766101 | \__/ EMail st_kost_at_gmx.net kost_at_imn.htwk-leipzig.de | WWW www.sonicpulse.de www.imn.htwk-leipzig.de/~kost/about.html ===-=-=--=---=---------------------------------- - - - - - -------------- next part -------------- A non-text attachment was scrubbed... Name: kost.vcf Type: text/x-vcard Size: 345 bytes Desc: not available URL: From steve.lhomme at free.fr Mon Feb 23 12:49:44 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Mon, 23 Feb 2004 12:49:44 +0100 Subject: [Matroska-devel] Subversion goes 1.0 Message-ID: <4039E8D8.5070604@free.fr> http://subversion.tigris.org/servlets/NewsItemView?newsItemID=612 Especially for Mosu... But Cyt0plas mentioned that an update on CoreCodec was planed and that they could support Subversion too. Anyone has more info on this ? From moritz at bunkus.org Mon Feb 23 13:39:33 2004 From: moritz at bunkus.org (Moritz Bunkus) Date: Mon, 23 Feb 2004 13:39:33 +0100 Subject: [Matroska-devel] Subversion goes 1.0 In-Reply-To: <4039E8D8.5070604@free.fr> References: <4039E8D8.5070604@free.fr> Message-ID: <20040223123932.GC9976@bunkus.org> Heya, > http://subversion.tigris.org/servlets/NewsItemView?newsItemID=612 > > Especially for Mosu... Very good news :)) > But Cyt0plas mentioned that an update on CoreCodec was planed and that > they could support Subversion too. Anyone has more info on this ? That'd be great. Mosu -- If Darl McBride was in charge, he'd probably make marriage unconstitutional too, since clearly it de-emphasizes the commercial nature of normal human interaction, and probably is a major impediment to the commercial growth of prostitution. - Linus Torvalds From paul at msn.com Fri Feb 27 17:48:58 2004 From: paul at msn.com (Paul Bryson) Date: Fri, 27 Feb 2004 10:48:58 -0600 Subject: [Matroska-devel] New audio offset element Message-ID: I would like to introduce a new element for use in Matroska after version 1 is finalized. I want to add an element to adjust the timecode of all of the Blocks for a Track. For instance, if you write the file and then realize that the offset is 100ms off, you could simply write a value of -100 to the element, and on playback that value would be added to each Block's timecode, adjusting it automatically for correct playback. Saves on remuxing. A single element located under TrackEntry as a level 3 element. I think a signed integer would work fine. A default value of 0. An ID of [53][7F]. But, I'm not sure if you would want the value to be scaled by TimecodeScale, or simply stored in nanoseconds. The only problem that I can see is that if someone creates an offset of a few seconds, the data would not be interleaved enough to produce smooth playback without some serious buffering. Any application re-muxing the file should just take the offset value and zero it, writing the correct values into the Blocks. I know this has been brought up previously, but does anyone have any concerns about this element? Pamel