From christian at matroska.org Fri Apr 2 06:38:45 2004 From: christian at matroska.org (ChristianHJW) Date: Fri, 02 Apr 2004 06:38:45 +0200 Subject: [Matroska-devel] Re: NUT preview In-Reply-To: <20040401220101.GX9096@brightrain.aerifal.cx> References: <200404012012.45541.michaelni@gmx.at> <20040401220101.GX9096@brightrain.aerifal.cx> Message-ID: <406CEE55.5050204@matroska.org> D Richard Felker III wrote: > On Thu, Apr 01, 2004 at 08:12:45PM +0200, Michael Niedermayer wrote: >>-rw-r--r-- 1 michael michael 4614655 2004-04-01 19:57 test3.mkv >>-rw-r--r-- 1 michael michael 4592134 2004-04-01 19:57 test3.nut > > BTW, another thing we should do soon is outline some specs for how > subtitles and menus and stuff are stored in NUT. If we want Windows > users (and the "scene"...) to adopt NUT instead of MKV, we need to > make sure they have access to all the features they want. Personally I > think menus are stupid but if we don't make a spec for how they're > stored, then lusers will either use MKV (bad) or hack their own design > into NUT (much worse! like ogm...). > Rich OMG, all this effort to be able to save 0.5% overhead for a single MP3 audio stream in a video container, being definitely the worst case for matroska ( MKV structure likes big frame sizes much better ). Interesting how well the 'bloated crap container' made by 'stupid DirectShow kiddies' performs, even in comparison to the generally highly respected MOV, isnt it : > -rw-r--r-- 1 michael michael 4653651 2004-04-01 22:29 test3.mov > -rw-r--r-- 1 michael michael 4614655 2004-04-01 19:57 test3.mkv I still dont get the point of making NUT, but of course i may be biased ;) .... never mind and good luck with it .... Christian matroska project admin From jcsston at wiesneronline.net Fri Apr 2 07:39:15 2004 From: jcsston at wiesneronline.net (Jory) Date: Thu, 1 Apr 2004 23:39:15 -0600 Subject: [Matroska-devel] New Track Duration Element? Message-ID: <002101c41874$e6f73490$0200a8c0@jcsston> I have an idea of adding a unsigned integer TrackDuration child element to the TrackEntry master, the element should be the length of the stream including the duration of the last frame, it should be scaled like the cluster timecode. The floating-point duration stored in the Segment is not that accurate and doesn't provide a way to know the exact duration of a track. Also, (this may be insane) what if we add adjustment Float elements to the cluster and block timecodes? They could have the offset the integer timecodes are off by. Would floats in seconds or milliseconds be more accurate? I imagine this would cause the overhead to go through the roof though. Jory From steve.lhomme at free.fr Fri Apr 2 09:51:12 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Fri, 02 Apr 2004 09:51:12 +0200 Subject: [Matroska-devel] Re: NUT preview In-Reply-To: <406CEE55.5050204@matroska.org> References: <200404012012.45541.michaelni@gmx.at> <20040401220101.GX9096@brightrain.aerifal.cx> <406CEE55.5050204@matroska.org> Message-ID: <406D1B70.6070009@free.fr> ChristianHJW wrote: > D Richard Felker III wrote: > >> On Thu, Apr 01, 2004 at 08:12:45PM +0200, Michael Niedermayer wrote: >> >>> -rw-r--r-- 1 michael michael 4614655 2004-04-01 19:57 test3.mkv >>> -rw-r--r-- 1 michael michael 4592134 2004-04-01 19:57 test3.nut > >> BTW, another thing we should do soon is outline some specs for how >> subtitles and menus and stuff are stored in NUT. If we want Windows >> users (and the "scene"...) to adopt NUT instead of MKV, we need to >> make sure they have access to all the features they want. Personally I >> think menus are stupid but if we don't make a spec for how they're >> stored, then lusers will either use MKV (bad) or hack their own design >> into NUT (much worse! like ogm...). >> Rich > > I still dont get the point of making NUT, but of course i may be biased > ;) .... never mind and good luck with it .... Because : - matroska is bad - menus are stupid - windows users are lusers - it's good to design first and think again when you have to add new features From alexander.noe at s2001.tu-chemnitz.de Fri Apr 2 10:03:20 2004 From: alexander.noe at s2001.tu-chemnitz.de (alexander.noe at s2001.tu-chemnitz.de) Date: Fri, 2 Apr 2004 10:03:20 +0200 Subject: [Matroska-devel] New Track Duration Element? In-Reply-To: <002101c41874$e6f73490$0200a8c0@jcsston> References: <002101c41874$e6f73490$0200a8c0@jcsston> Message-ID: <1080893000.406d1e484f2c4@mail.tu-chemnitz.de> Zitat von Jory : > The floating-point duration stored in the Segment is not that > accurate and doesn't provide a way to know the exact duration > of a track. That is only a problem if you make MKA files with 1 stream per song of a CD, for example. And if i'm not mistaken, i'm the only one doing that ;) > Also, (this may be insane) what if we add adjustment Float elements to the > cluster and block timecodes? It is insane. > They could have the offset the integer timecodes are off by. That is insane. However, you could add an element, containing the unscaled offset the integer timecode is off by, i.e. you would have Cluster::TimecodeHigh := Cluster::Timecode and Cluster::TimecodeLow Where total_timecode = TimecodeHigh * TimecodeScale + TimecodeLow. > Would floats in seconds or milliseconds be more accurate? Depends on your file. The duration of my Buffy - Season 7 test file is about 15 hours, which is 2^15,7 seconds. The mantissa of a float is 23 bits, i.e. the accuracy of float timecodes at the end of the file would be 2^(-7,3) seconds, which is 6 ms. > I imagine this would cause the overhead to go through the roof though. Actually, assuming timecodes in milliseconds, every cluster timecode larger than 2^21 ms = 45min also needs 4 bytes, so using floats for the cluster timecode would not make the overhead going throw the roof. But it is nethertheless a crappy idea...as to float block timecodes, add 6 bytes of overhead per block and see on your own... Alex From steve.lhomme at free.fr Fri Apr 2 10:07:39 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Fri, 02 Apr 2004 10:07:39 +0200 Subject: [Matroska-devel] New Track Duration Element? In-Reply-To: <002101c41874$e6f73490$0200a8c0@jcsston> References: <002101c41874$e6f73490$0200a8c0@jcsston> Message-ID: <406D1F4B.30708@free.fr> Jory wrote: > I have an idea of adding a unsigned integer TrackDuration child element to > the TrackEntry master, the element should be the length of the stream > including the duration of the last frame, it should be scaled like the > cluster timecode. > The floating-point duration stored in the Segment is not that accurate and > doesn't provide a way to know the exact duration of a track. Well, there's no real point in having such a precision. Otherwise I suggest we add a sample counter... AFAIK there aren't any recording in which the sampling rate changes during the track, so it would be even more accurate. > Also, (this may be insane) what if we add adjustment Float elements to the > cluster and block timecodes? What do you call "adjustment float" ? > They could have the offset the integer timecodes are off by. > Would floats in seconds or milliseconds be more accurate? > I imagine this would cause the overhead to go through the roof though. From steve.lhomme at free.fr Fri Apr 2 10:11:55 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Fri, 02 Apr 2004 10:11:55 +0200 Subject: [Matroska-devel] Usability Message-ID: <406D204B.8060902@free.fr> Interresting articles about usability of OSS : http://www.osnews.com/story.php?news_id=6574 At least we got that already and did our best to meet the user's needs. But maybe we can do even better ? From steve.lhomme at free.fr Fri Apr 2 10:22:39 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Fri, 02 Apr 2004 10:22:39 +0200 Subject: [Matroska-devel] Usability In-Reply-To: <406D204B.8060902@free.fr> References: <406D204B.8060902@free.fr> Message-ID: <406D22CF.2050206@free.fr> I didn't see that one yet : "If there?s a glib, nutshell synopsis for why Linux desktop software tends to suck, it?s this: Raymond and his ilk have no respect for anyone but themselves." anyone care to forward this to Rich ? :p From paul at msn.com Fri Apr 2 11:20:59 2004 From: paul at msn.com (Paul Bryson) Date: Fri, 2 Apr 2004 03:20:59 -0600 Subject: [Matroska-devel] Re: Ogg and Vorbis/Speex/FLAC directshow filters References: Message-ID: Okay.... I thought I sent this off before....Second try. I'll see if the CoreCodec folks have anything to comment about this. Paul Bryson wrote... > I was also talking with the CoreVorbis fellows just a few days ago about using a > standard set of GUIDs. Except that it was more to do with a standard way to > generate GUIDs. This was for consideration from the Matroska project as The only problem of having a standard way of generating a GUID is that you increase the possiblility of clashes. albeit slightly considering 128 bits is a lot ! But by basing 15 bytes on a hash of a very small domain, is kind of not the way GUIDs were intended to be used. I'm going to have to think more about that. > Matroska uses a human readable codec ID. A list of the current IDs is available > here: > http://matroska.org/technical/specs/codecid/index.html > > Here is what has been more or less decided. GUIDs are 128bit (16byte). So, it > was decided to use the first byte as an ASCII character indicating the pin type Directshow already has 3 GUID's to id a connection a major type (MEDIATYPE_Video, MEDIATYPE_Audio etc)... these are already standardised by directshow... it seems redundant to squash a 128 bit domain that already has unique codes for all the major type into an 8 bit domain. The other bigger problem than media type is the format GUID. Standardising the MEDIASUBTYPES (ie MEDIASUBTYPE_Vorbis etc) is not really the major problem. The problem is standardising the format block and either having everyone agree how much or how little information goes into it, or having filters do format type translation. (which is probably only possible in a translation from more info to less info). I'm not so sure that is a good idea... but again... i'll have a think about it some more. Cheers ! From christian at matroska.org Fri Apr 2 15:07:45 2004 From: christian at matroska.org (ChristianHJW) Date: Fri, 02 Apr 2004 15:07:45 +0200 Subject: [Matroska-devel] Re: NUT preview In-Reply-To: <20040402064401.GG9096@brightrain.aerifal.cx> References: <200404012012.45541.michaelni@gmx.at> <20040401220101.GX9096@brightrain.aerifal.cx> <406CEE55.5050204@matroska.org> <20040402064401.GG9096@brightrain.aerifal.cx> Message-ID: <406D65A1.9000300@matroska.org> D Richard Felker III wrote: > On Fri, Apr 02, 2004 at 06:38:45AM +0200, ChristianHJW wrote: >> >>OMG, all this effort to be able to save 0.5% overhead for a single MP3 >>audio stream in a video container, being definitely the worst case for >>matroska ( MKV structure likes big frame sizes much better ). > > It's the worst case for everything, and 0.5% is quite large. Also the > overhead is much higher at very low bitrates. If i'm trying to stream > video over 28.8 modem, I don't want to be wasting 5% of the bandwidth > on a bad container. For this type of purpose, streaming low bitrate audio over modems, i agree there are actually better containers than matroska, but that was never what it was designed for anyhow, as it is a very specific use for a limited usergroup. >>Interesting how well the 'bloated crap container' made by 'stupid >>DirectShow kiddies' performs, even in comparison to the generally highly >>respected MOV, isnt it : > "Generally highly respected"??? WTF? Everyone here knows MOV is one of > the worst container formats of all. If you knew how much we got attacked, especially from the Mac world, for 'reinventing the wheel' because there is the marvellous MOV container existing ;) .... >>I still dont get the point of making NUT, but of course i may be biased >>;) .... never mind and good luck with it .... > > Because nut is simply the right solution, and matroska _isn't_. > Matroska still has one critical flaw that needs to be fixed, the fact > that all streams are forced to use a common time base. This means > you're either forced to use incorrect timestamps or waste lots of bits > by using a very fine-grained time unit. (The proper time unit for > video is almost always something like 1/25 or 1001/24000, and the > proper unit for audio is almost always 1152/44100, 1/44100, or > similar. So you end up with a time base of 1/352800. Not very cool.) This argument does hold as long as you actually HAVE a known timebase, but what are you doing if you are recording from a soundcard with 44073 Hz sampling rate ? Dont tell me to buy a new soundcard, the average user wont even know that his soundcard has that error, but they actually do a lot. This is a major argument for using real timestamps instead of using timeticks like most other containers do, and again we made it that way because matroska is not intended to be used for any specific purpose only, but designed to be a general use container. BTW, this made us one of the favourite containers for capturing Pro's already, and almost any free capturing tool for the Windows world will support matroska as possible container already, for this reason. When discussing with the devs from Foobar2000, we explained that - matroska files can easily be written with sample precise timestamps, for files with only one audio stream, or several streams using the same timebase - the 1 ms precision is not fixed, but fully scaleable over a wide range and can easily be extended to be 1 ?s, and without any noticable overhead increase ( max. cluster length wouldnt be much shorter then we make clusters currently ). Its just that all current tool developers dont care and consider 1 ms being precise enough, but thats not a flaw in the matroska design, these lazybones are just not interested to write files of higher precision ;) ..... > As I've said to other people involved with the matroska project > recently, I don't hate matroska nearly as much now that there are > viable non-libmatroska(c++) implementations. Further, I'll even give > you that ogm is much worse than matroska, and of course all the other > containers (avi, asf, mov, rm, etc.) totally suck. But being better > than stuff that sucks doesn't make you good. It just makes you suck > less. Hmmm ... is this still the same Rich Felker, or did somebody from the NUT team actually have a closer look at the matroska specs meanwhile ? BTW, we have an experimental NUT muxer almost ready, so for sure we DID look closely at your specs :) .... > Nut is designed _not_ to suck. It's very near-optimal given the > constraints we want: > - simple to implement > - minimal overhead > - perfect seeking to any frame > - exact timestamps for all frames > - rational pts, not arbitrary rounding > - support for any codec without modification > - ability to play corrupt/damaged files > - no arbitrary limits > Matroska also accomplishes most of these goals, with the very notable > exception of #1 and also some of the timestamp issues. But it's not > nearly optimal. Rich I am glad to see the change in your tone Richard. If you keep it like that, i guess we can find a good level for communication between the two projects, and learn from each other ( thats what we did already, to be honest ;) ). IMO the main design differences between the two containers are a result of the differing design goals we have. For the user this is pretty nice, because in the end he will have the choice, and can go for what suits him best. BTW, speaking about learning from each other : What would you people think about a common menue system for both projects ? Possible ? Would probably make life of the implementers much easier ? Have a look at the quick draft we made so far ( not very defined yet, sorry ) : http://matroska.org/technical/menu/index.html . Comments welcome, preferably to matroska-devel AT lists.matroska.org Regards Christian matroska project admin From steve.lhomme at free.fr Fri Apr 2 15:28:58 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Fri, 02 Apr 2004 15:28:58 +0200 Subject: [Matroska-devel] Re: NUT preview In-Reply-To: <406D65A1.9000300@matroska.org> References: <200404012012.45541.michaelni@gmx.at> <20040401220101.GX9096@brightrain.aerifal.cx> <406CEE55.5050204@matroska.org> <20040402064401.GG9096@brightrain.aerifal.cx> <406D65A1.9000300@matroska.org> Message-ID: <406D6A9A.1020805@free.fr> >> Nut is designed _not_ to suck. It's very near-optimal given the >> constraints we want: >> - simple to implement >> - minimal overhead >> - perfect seeking to any frame >> - exact timestamps for all frames >> - rational pts, not arbitrary rounding >> - support for any codec without modification >> - ability to play corrupt/damaged files >> - no arbitrary limits >> Matroska also accomplishes most of these goals, with the very notable >> exception of #1 and also some of the timestamp issues. But it's not >> nearly optimal. Rich If you look at Gabest implementation, you'll see that it's very easy to implement as most fields are opt-in. We designed the format to be simple *also*. So that a minimal parser and a minimum of supported fields will get you full playability. It's not because there are lot of extra features that it's complicated. Actually one of our strength is that we can add anything to the format whenever we want without breaking forward and backward compatibility. That's what we had in mind. Maybe the C implementations are even more simple, I just didn't have a look. But I agree that NUT is probably easier than Matroska. Which doesn't mean it's far better or even simply better. It's just not our primary goal. From chris at matroska.org Fri Apr 2 15:50:07 2004 From: chris at matroska.org (Christian HJ Wiesner) Date: Fri, 02 Apr 2004 15:50:07 +0200 Subject: [Matroska-devel] matroska dev needs help Message-ID: <406D6F8F.7020602@matroska.org> http://corecodec.com/modules.php?op=modload&name=PNphpBB2&file=viewtopic&t=634 From paul at msn.com Fri Apr 2 21:54:36 2004 From: paul at msn.com (Paul Bryson) Date: Fri, 2 Apr 2004 13:54:36 -0600 Subject: [Matroska-devel] Re: NUT preview References: <200404012012.45541.michaelni@gmx.at><20040401220101.GX9096@brightrain.aerifal.cx><406CEE55.5050204@matroska.org><20040402064401.GG9096@brightrain.aerifal.cx> <406D65A1.9000300@matroska.org> Message-ID: "ChristianHJW" wrote... > For this type of purpose, streaming low bitrate audio over modems, i > agree there are actually better containers than matroska, but that was > never what it was designed for anyhow, as it is a very specific use for > a limited usergroup. It has always been conceded that even Ogg has better overhead than Matroska for low bitrate streaming. Although, if you really wanted to, you could put up to 255 audio blocks in a lace. The overhead would drop dramatically. The main issue would be seeking, which isn't really an issue for streaming.... This, however, has been relatively low priority to the matroska team. You can make files like this with existing tools, but there is not a reason to yet. > > Matroska still has one critical flaw that needs to be fixed, the fact > > that all streams are forced to use a common time base. This means > > you're either forced to use incorrect timestamps or waste lots of bits > > by using a very fine-grained time unit. ........ > This is a major argument for using real timestamps instead of using > timeticks like most other containers do, and again we made it that way > because matroska is not intended to be used for any specific purpose > only, but designed to be a general use container. I ran some numbers and getting sample accurate timecodes did raise the overhead of a file significantly when the samplerate was high, as in 192kHz. 1 hour of 44.1kHz MP3 audio should have an overhead of around 1.4MB without lacing and 0.24MB with 8 blocks/lace. 1 hour of 192kHz MP3 audio should have an overhead of around 6.1MB without lacing and 1MB with 8blocks/lace. Note that lacing is on by default so the numbers would be 0.24MB vs 1MB for practicaly purposes. As it turned out, sample accurate timecodes weren't needed. Every A/V playback system synchronises by the audio sample, so there is never a problem with playback, and hence no need in video to have sample accurate seeking. Nobody can detect a +/-0.5ms audio synch problem with their video. The only place where it turned out to be an issue was with audiophiles wanting to store a whole CD as a single audio track broken up by chapters. When seeking to a chapter, it was possible to get a small *click* as it would start playing a couple of samples off from the correct sample. However, at the higher bitrates that these people use, the increase in overhead is very marginal. > BTW, we have an experimental NUT muxer almost ready, so for sure we DID > look closely at your specs :) .... It was basically done and about to be released, then the NUT specs just changed again. Ugh. > > Nut is designed _not_ to suck. It's very near-optimal given the > > constraints we want: > > - simple to implement I think there are 6 different matroska libs now written in C, C++, and Java. :) The main issue is getting an EBML parser written, after that its all about having a list of defined elements. Relatively simple to implement. And if you want to add something, you can just add it to the list. Simple. > > - minimal overhead Overhead is low in Matroska, and could be lower than NUT if written with less optimal settings. It was A goal of Matroska, but not THE goal. > > - perfect seeking to any frame Fortunately seeking to any frame works fine in Matroska. Would be silly otherwise, no? > > - exact timestamps for all frames > > - rational pts, not arbitrary rounding Worth noting that the rounding in Matroska is not arbitrary. It is specifically defined within the specs. This allows you to know the exact timestamp of a given audio sample. > > - support for any codec without modification That would be kinda silly if it didn't, wouldn't it? ;) The bigger question would be, what about future codecs? Fortunately none of us know the future. > > - ability to play corrupt/damaged files Perhaps we all beat MP4 in this respect? > > - no arbitrary limits Are there specific limits? > > Matroska also accomplishes most of these goals, with the very notable > > exception of #1 and also some of the timestamp issues. But it's not > > nearly optimal. Rich I would say that is a matter of opinion, and one of a person that has not written a lib for it. Perhaps one that has written a lib for both could comment? Pamel From rbultje at ronald.bitfreak.net Sat Apr 3 01:18:14 2004 From: rbultje at ronald.bitfreak.net (Ronald Bultje) Date: Sat, 3 Apr 2004 01:18:14 +0200 (CEST) Subject: [Matroska-devel] Usability In-Reply-To: <406D204B.8060902@free.fr> Message-ID: Hi, On Fri, 2 Apr 2004, Steve Lhomme wrote: [.] Usability is for end user desktop applications, not for movie formats, libraries or anything. Ronald GNOME desktop guy ;) From jcsston at wiesneronline.net Sun Apr 4 19:44:43 2004 From: jcsston at wiesneronline.net (Jory) Date: Sun, 4 Apr 2004 12:44:43 -0500 Subject: [Matroska-devel] New Track Duration Element? References: <002101c41874$e6f73490$0200a8c0@jcsston> <1080893000.406d1e484f2c4@mail.tu-chemnitz.de> Message-ID: <001901c41a6c$b4731e90$0200a8c0@jcsston> ----- Original Message ----- From: To: Sent: Friday, April 02, 2004 3:03 AM Subject: Re: [Matroska-devel] New Track Duration Element? >> The floating-point duration stored in the Segment is not that >> accurate and doesn't provide a way to know the exact duration >> of a track. > >That is only a problem if you make MKA files with 1 stream per song >of a CD, for example. And if i'm not mistaken, i'm the only one doing >that ;) With regular video+audio files the stream lengths are often slightly different. And if you have subtitles then the stream lengths will differ for sure. BTW AVI stores the length of each stream, OGM does too IIRC. >> Also, (this may be insane) what if we add adjustment Float elements to the >> cluster and block timecodes? > >It is insane. A few minutes after sending it I knew I shouldn't have even thought of it. :> From moritz at bunkus.org Sun Apr 4 21:36:47 2004 From: moritz at bunkus.org (Moritz Bunkus) Date: Sun, 4 Apr 2004 21:36:47 +0200 Subject: [Matroska-devel] New Track Duration Element? In-Reply-To: <001901c41a6c$b4731e90$0200a8c0@jcsston> References: <002101c41874$e6f73490$0200a8c0@jcsston> <1080893000.406d1e484f2c4@mail.tu-chemnitz.de> <001901c41a6c$b4731e90$0200a8c0@jcsston> Message-ID: <20040404193647.GR12604@bunkus.org> Hi, > BTW AVI stores the length of each stream, OGM does too IIRC. Nope, neither OGM nor Ogg do. 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 alexander.noe at s2001.tu-chemnitz.de Mon Apr 5 10:33:05 2004 From: alexander.noe at s2001.tu-chemnitz.de (alexander.noe at s2001.tu-chemnitz.de) Date: Mon, 5 Apr 2004 10:33:05 +0200 Subject: [Matroska-devel] New Track Duration Element? In-Reply-To: <20040404193647.GR12604@bunkus.org> References: <002101c41874$e6f73490$0200a8c0@jcsston> <1080893000.406d1e484f2c4@mail.tu-chemnitz.de> <001901c41a6c$b4731e90$0200a8c0@jcsston> <20040404193647.GR12604@bunkus.org> Message-ID: <1081153985.407119c1eda4f@mail.tu-chemnitz.de> Zitat von Moritz Bunkus : > Hi, > > > BTW AVI stores the length of each stream, OGM does too IIRC. > > Nope, neither OGM nor Ogg do. OGM actually doesn't store the length of anything, and the stream duration in AVI files should not be considered a reliable piece of information.... Alex From agebosma at home.nl Mon Apr 5 20:29:20 2004 From: agebosma at home.nl (Age Bosma) Date: Mon, 05 Apr 2004 20:29:20 +0200 Subject: [Matroska-devel] Re: Tag names In-Reply-To: References: <40532BBD.8060909@home.nl> <4054B190.7050008@home.nl> <4055D0F2.7020907@home.nl> <4056F5BF.3030605@home.nl> <4058CDBF.7020905@home.nl> Message-ID: <4071A580.3060207@home.nl> Sorry for my way to late reply, I've been quite buzzy the past couple of weeks. Paul Bryson wrote: >>INVOLVED_PERSON would be a good place to store it but that name isn't >>very descriptive in this case. We could just change that on to FEATURING >>but I don't know if it would couse problems in other cases. > > I think the key here would be to find out what everyone is using. >>It's not the same as the Vorbis PERFORMER tag as you look at the >>descriptions closely, this field should be placed with CONDUCTOR like in >>my reference. Also for ID3 and APE ARTIST are the only fields that come >>close enough to the LEAD_PERFORMER Matroska field. >> From a e.g. a jazz point of view you may speak about LEAD_PERFORMER >>together with BAND but everyone will know what you mean if you use >>ARTIST and BAND in this case as well. This makes it possible to use the >>ARTIST field for e.g. just "Dire Straits" or "Slipknot" as well and >>therefor being fully compatible with the other tag types. Using >>LEAD_PERFORMER in a "Dire Straits" or "Slipknot" context makes much less >>sense. > > I want to know what is used in fb2k before deciding this one. The use of > different terms that overlap a lot has made this a confusing point. Because no one on the Hydrogenaudio forum responded to that request I'm gonna start a new thread in the foobar forum about this. Hopefully this will attract peter's en kode54's attention. I suspect those two will know about it the most. >>If it comes to songs I think VERSION would be more suitable. Like "Fear >>Factory - New Breed (Spoetnik Mix)" or "Linkin Park - Dedicated (Demo >>1999)". They talk about different versions of the song. If you look >>strictly at the definition of both words VERSION would be more suitable >>in both cases, dvd and audio. >>Maybe we should think about a more general name for this instead. > > I am open to ideas. I though it over and tried to find alternatives but I think VERSION would be the best name for both cases. Although EDITION might be mainstream for DVD's I think changing EDITION to VERSION wouldn't cause any confusion, it's basicly the same. When changing it to VERSION it would leave us with one general field which is good in both situations. >>> One other thing, where should we store if a source was widescreen or >>> fullscreen? >>> And I mean in a generic sense. The dimensional proportions could >>> always go in >>> ORIGINAL_DIMENSIONS. Should there be a different place where >>> someone could just >>> write "Widescreen" or "Fullscreen"? Maybe "Anamorphic Widescreen" >>> (1.66:1 to 2.35:1) and "Full Frame" (1.33:1)? >>> >>That would be a duplicate entry. I think only the ratio will be fine >>because most people using terms like "widescreen" or "fullscreen" will >>probably know what they are talking about and therefor know the ratio as >>well. If we give people an extra option they will most likely leave out >>the actual ratio which imo will describe it more accurately and will >>rule out any mistakes. > > I'm not sure I follow you, what fields do you want? Maybe I'm misunderstanding something. Isn't ORIGINAL_DIMENSIONS used to store the ratio? If not A RATIO field should be introduced to store the numerical ratio, as far as I know stuff like widescreen can be know by looking at the ratio, isn't it? If so, introducing a field to store those names should be avoided to rule out confusion (what's in a name?) and to make sure people do not become to lazy to fill in the numerical ratio, which imo is more important. > I look forward to seeing your sample. I'm realy sorry I haven't been able to create some as I promised. I hope to have a lot of work finished by the end of the week. That will leave me with some spare time again to realy start creating examples. Cheers, Age P.s. did you made any other changes to the list in the mean time? I updated mine to your last reply. From paul at msn.com Tue Apr 6 09:33:57 2004 From: paul at msn.com (Paul Bryson) Date: Tue, 6 Apr 2004 02:33:57 -0500 Subject: [Matroska-devel] Re: Re: Tag names References: <40532BBD.8060909@home.nl> <4054B190.7050008@home.nl> <4055D0F2.7020907@home.nl> <4056F5BF.3030605@home.nl> <4058CDBF.7020905@home.nl> <4071A580.3060207@home.nl> Message-ID: "Age Bosma" wrote... > Maybe I'm misunderstanding something. Isn't ORIGINAL_DIMENSIONS used to > store the ratio? I believe the original intention is to store physical dimensions of the thing being recorded. This would be most applicable for things like if you take a picture of the Mona Lisa, then in this field you would store that the item that was recorded was "8.5 in h, 11 in w." Honestly, I'm not even sure how useful this is. It comes for the RIFF specs. > P.s. did you made any other changes to the list in the mean time? I > updated mine to your last reply. There shouldn't be any changes. You can always look at the diffs between versions here: http://cvs.corecodec.org/cgi-bin/viewcvs.cgi/matroska/doc/website/technical/specs/tagging/index.html Pamel From suiryc at yahoo.com Tue Apr 6 13:52:30 2004 From: suiryc at yahoo.com (Cyrius) Date: Tue, 6 Apr 2004 04:52:30 -0700 (PDT) Subject: [Matroska-devel] New Track Duration Element? In-Reply-To: <001901c41a6c$b4731e90$0200a8c0@jcsston> Message-ID: <20040406115230.50619.qmail@web12906.mail.yahoo.com> --- Jory wrote: > > With regular video+audio files the stream lengths are often slightly > different. And if you have subtitles then the stream lengths will > differ for > sure. > BTW AVI stores the length of each stream, OGM does too IIRC. yes OGM could/should *cough* store the length ... but none of my tools does :p (due to various reasons, specifically the fact there were no OGM specs to tell the exact meaning of the field that could/should contain this value). /me whistles ... Best regards Cyrius __________________________________ Do you Yahoo!? Yahoo! Small Business $15K Web Design Giveaway http://promotions.yahoo.com/design_giveaway/ From suiryc at yahoo.com Tue Apr 6 13:53:48 2004 From: suiryc at yahoo.com (Cyrius) Date: Tue, 6 Apr 2004 04:53:48 -0700 (PDT) Subject: [Matroska-devel] New Track Duration Element? In-Reply-To: <20040404193647.GR12604@bunkus.org> Message-ID: <20040406115348.79029.qmail@web12901.mail.yahoo.com> --- Moritz Bunkus wrote: > Hi, > > > BTW AVI stores the length of each stream, OGM does too IIRC. > > Nope, neither OGM nor Ogg do. OK, so Mosu's tools doesn't store this value either :p __________________________________ Do you Yahoo!? Yahoo! Small Business $15K Web Design Giveaway http://promotions.yahoo.com/design_giveaway/ From suiryc at yahoo.com Tue Apr 6 14:04:04 2004 From: suiryc at yahoo.com (Cyrius) Date: Tue, 6 Apr 2004 05:04:04 -0700 (PDT) Subject: [Matroska-devel] New Track Duration Element? In-Reply-To: <20040406115348.79029.qmail@web12901.mail.yahoo.com> Message-ID: <20040406120404.23833.qmail@web12908.mail.yahoo.com> --- Cyrius wrote: > --- Moritz Bunkus wrote: > > Hi, > > > > > BTW AVI stores the length of each stream, OGM does too IIRC. > > > > Nope, neither OGM nor Ogg do. > > OK, so Mosu's tools doesn't store this value either :p btw the Ogg multiplexer (in OggDS) doesn't either :p __________________________________ Do you Yahoo!? Yahoo! Small Business $15K Web Design Giveaway http://promotions.yahoo.com/design_giveaway/ From suiryc at yahoo.com Tue Apr 6 14:38:51 2004 From: suiryc at yahoo.com (Cyrius) Date: Tue, 6 Apr 2004 05:38:51 -0700 (PDT) Subject: [Matroska-devel] New Track Duration Element? In-Reply-To: <20040404193647.GR12604@bunkus.org> Message-ID: <20040406123851.88400.qmail@web12901.mail.yahoo.com> My error OGM actually doesn't have a field to store the length of the stream :p /me stops flooding the ML ... __________________________________ Do you Yahoo!? Yahoo! Small Business $15K Web Design Giveaway http://promotions.yahoo.com/design_giveaway/ From chris at matroska.org Wed Apr 7 12:24:57 2004 From: chris at matroska.org (Christian HJ Wiesner) Date: Wed, 07 Apr 2004 12:24:57 +0200 Subject: [Matroska-devel] DV in MKV Message-ID: <4073D6F9.9050305@matroska.org> Hi, when reading a 'special video' issue of CHIP, a well known German computer magazine, on my way home from China and studying articles about different tested video editors, it became obvious to me that most of them still have to offer AVI support, especially because most capture tools will export camcorder footage ( or even VHS analog captures ) as DV type 1 or type 2 AVI files, and they have to read this if people want to create DVDs from their self made camcorder home movies. As matroska is aiming to replace AVI, shouldnt we offer a way to write DV in MKV ? It wont help to add this in mkvmerge, but i was thinking of allowing direct capturing from IEE 1394 firewire in MKV, by patching *DVIO*, the most used opensource tool for DV AVI creation. Anybody interested to look into this ? Christian From chris at matroska.org Wed Apr 7 16:52:52 2004 From: chris at matroska.org (Christian HJ Wiesner) Date: Wed, 07 Apr 2004 16:52:52 +0200 Subject: [Matroska-devel] matroska container output for DVIO, replacing crappy AVI ? Message-ID: <407415C4.6090404@matroska.org> Hi Michael, i am project administrator for an opensource project called matroska ( http://www.matroska.org ), we are aiming to replace the old, outdated AVI container. There is a free *matroska muxer Direct Show Filter* available here : http://sf.net/projects/guliverkli and as it seems DVIO is based on DirectShow, could you consider adding matroska support to your program ? matroska container can - write files of arbitrary size ( we tested 1 TB already ) - hold any number of video, audio and subtitles streams - tag files with the matroska tagging system ( not via Dshow Muxer Filter ) - keep perfect sync even for very long captures, thanks to timestamps on the cluster level ( 1 ns precision ) - significantly reduce overhead compared to AVI ( typically 1 - 3 % smaller files, especially for big frame sizes ) We have support for matroska files in a video editor based on Virtualdub already, its called VirtualdubMod ( http://sf.net/projects/virtualdubmod ), and this editor could be adapted to allow MKV editing with DV content, if a DV VCM codec like the Panasonic codec is installed. We also have plans to make DV a 'native' MKV format, so we had to define matroska codec IDs for it like V_DV/TYPE1 V_DV/TYPE2 A_DV/TYPE1 ( or we use the existing A_PCM/INT/xxx , whatever kind of PCM is normally used in DV ) and we could easily update the matroska muxer filter for that, connecting to your app/source filter using a special MEDIATYPE / MEDIASUBTYPE ( you specify that and just tell us ) Thanks for a short answer Best regards Christian matroska project admin -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcsston at wiesneronline.net Wed Apr 7 17:32:26 2004 From: jcsston at wiesneronline.net (Jory) Date: Wed, 7 Apr 2004 10:32:26 -0500 Subject: [Matroska-devel] matroska container output for DVIO, replacing crappy AVI ? References: <407415C4.6090404@matroska.org> Message-ID: <001f01c41cb5$956c7d70$0200a8c0@jcsston> There should not be different codec id's for the video stream. The DV Video stream always has an embedded audio steam and date/time stamps. Jory ----- Original Message ----- From: "Christian HJ Wiesner" To: ; "Discussion about the current and future development of Matroska" Sent: Wednesday, April 07, 2004 9:52 AM Subject: [Matroska-devel] matroska container output for DVIO,replacing crappy AVI ? > > Hi Michael, > > i am project administrator for an opensource project called matroska ( > http://www.matroska.org ), we are aiming to replace the old, outdated > AVI container. > > There is a free > > *matroska muxer Direct Show Filter* > > available here : http://sf.net/projects/guliverkli > > and as it seems DVIO is based on DirectShow, could you consider adding > matroska support to your program ? matroska container can > > - write files of arbitrary size ( we tested 1 TB already ) > - hold any number of video, audio and subtitles streams > - tag files with the matroska tagging system ( not via Dshow Muxer Filter ) > - keep perfect sync even for very long captures, thanks to timestamps on > the cluster level ( 1 ns precision ) > - significantly reduce overhead compared to AVI ( typically 1 - 3 % > smaller files, especially for big frame sizes ) > > We have support for matroska files in a video editor based on Virtualdub > already, its called VirtualdubMod ( http://sf.net/projects/virtualdubmod > ), and this editor could be adapted to allow MKV editing with DV > content, if a DV VCM codec like the Panasonic codec is installed. > > We also have plans to make DV a 'native' MKV format, so we had to define > matroska codec IDs for it like > > V_DV/TYPE1 > V_DV/TYPE2 > A_DV/TYPE1 ( or we use the existing A_PCM/INT/xxx , whatever kind of PCM > is normally used in DV ) > > and we could easily update the matroska muxer filter for that, > connecting to your app/source filter using a special > > MEDIATYPE / MEDIASUBTYPE ( you specify that and just tell us ) > > Thanks for a short answer > > Best regards > > Christian > matroska project admin > ---------------------------------------------------------------------------- ---- > _______________________________________________ > Matroska-devel mailing list > Matroska-devel at lists.matroska.org > http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel > From jcsston at wiesneronline.net Wed Apr 7 17:44:40 2004 From: jcsston at wiesneronline.net (Jory) Date: Wed, 7 Apr 2004 10:44:40 -0500 Subject: [Matroska-devel] DV in MKV References: <4073D6F9.9050305@matroska.org> Message-ID: <002601c41cb7$46a221c0$0200a8c0@jcsston> Though this my get me shoot around here, I don't see any reason to have DV in MKV. Just about any AVI app can handle AVI DV Type-2 fine, the file size is a moot point since any recent app can handle 36GB AVI's. Jory ----- Original Message ----- From: "Christian HJ Wiesner" To: "Discussion about the current and future development of Matroska" Sent: Wednesday, April 07, 2004 5:24 AM Subject: [Matroska-devel] DV in MKV > > Hi, > > when reading a 'special video' issue of CHIP, a well known German > computer magazine, on my way home from China and studying articles about > different tested video editors, it became obvious to me that most of > them still have to offer AVI support, especially because most capture > tools will export camcorder footage ( or even VHS analog captures ) as > DV type 1 or type 2 AVI files, and they have to read this if people > want to create DVDs from their self made camcorder home movies. > > As matroska is aiming to replace AVI, shouldnt we offer a way to write > DV in MKV ? It wont help to add this in mkvmerge, but i was thinking of > allowing direct capturing from IEE 1394 firewire in MKV, by patching > *DVIO*, the most used opensource tool for DV AVI creation. > > Anybody interested to look into this ? > > Christian > > _______________________________________________ > 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 Wed Apr 7 17:53:53 2004 From: chris at matroska.org (Christian HJ Wiesner) Date: Wed, 07 Apr 2004 17:53:53 +0200 Subject: [Matroska-devel] Re: matroska container output for DVIO, replacing crappy AVI ? In-Reply-To: References: Message-ID: <40742411.90303@matroska.org> Hi Michael, thanks for the quick reply. Michael Carr wrote: > Sounds like a good idea. At the moment my time is severely limited > because of several other projects, but I will definitely add it to > DVIO as soon as possible. If we can help, let us know. Have you ever considered making DVIO opensource BTW ? You dont have to answer if you consider this question impolite ;-) .... > One question -- The DV specification defines an interleaved stream, > meaning that one frame of video is mixed together with its > corresponding audio. In my experience, it is much better to store the > DV stream in its native interleaved format (i.e. Type 1) rather than > storing the audio redundantly in its own stream (i.e. Type 2). This > leads to all sorts of confusion, plus extra file storage, plus extra > CPU overhead on record/playback, on the part of a reader/writer that > is formatting DV data. I have been advocating for a while to get rid > of Type 2 for these reasons, so this would be a great opportunity to > do so... what are your thoughts about this? As Admin on the biggest existing Virtualdub user forums ( http://virtualdub.everwicked.com ) i know that DV type-1 AVIs are causing problems mainly because Virtualdub cant handle the embedded audio in the video stream correctly, as a result of the limitations of the VCM API. So, if people like to extract the audio for further processing, they are stuck and cant do that with type 1, thats where type 2 comes in handy. As DV AVI, in most cases, is anyhow only used as an interims format and the footage is processed in DivX/MP3 AVIs or DVDs, the extra file size for the additional audio stream is not a big problem. Using matroska, we can do the following to keep overhead comparably small, or to avoid it completely : 1. We can program the matroska DirectShow splitter filter to *NOT* create an audio pin from the additional audio track if he finds a 'V_DV' video track, to avoid using unnecessary decoding/parsing power. I assume the existing DV DirectShow decoder filters will create this audio pin automatically ? What if an existing VCM codec is used from the M$ avi demuxer filter, it for sure couldnt handle that correctly ? Is there a good DV decoder filter for DirectShow, capable of handling audio pin rendering from a type 1 DV stream ? 2. We can use Jory's FLAC compression filter to losslessly compress the PCM audio for the separate audio, thus reducing the extra required file size by about 40- 50%, depending on audio content ( for most homemade DV cam footage, compression ratios should be even well over 50% i assume ). Note that AVI cant be used for that, because FLAC is VBR by default and AVI cant cope with that correctly ( one of the main reasons its really about time to replace it ). 3. We are in the process of porting Gstreamer ( http://www.gstreamer.org ) to win32, and to create a new, variable frame rate ( VFR ) capable video editor based on that, of course as an opensource project. We are well aware it will take a lot fo time until this new app, called TCME, will be able to replace Virtualdub even partially, but as we can influence the API for it, its well possible we add the capability to handle embedded audio in video streams, thus allowing easy DV type 1 editing from it. For the time being, i guess there is no other way than adding type 2 output also, as people are used to Virtualdub ( or for matroska, VirtualdubMod ) and will complain if they cant handle the audio from it. Comments welcome Christian matroska project admin > Regards, > Michael Carr > > ------------------------------------------------------------------------ > *From:* Christian HJ Wiesner [mailto:chris at matroska.org] > *Sent:* Wednesday, April 07, 2004 10:53 AM > *To:* mcarr at carr-engineering.com; Discussion about the current and > future development of Matroska > *Subject:* matroska container output for DVIO, replacing crappy AVI ? > > > Hi Michael, > > i am project administrator for an opensource project called matroska ( > http://www.matroska.org ), we are aiming to replace the old, outdated > AVI container. > > There is a free > > *matroska muxer Direct Show Filter* > > available here : http://sf.net/projects/guliverkli > > and as it seems DVIO is based on DirectShow, could you consider adding > matroska support to your program ? matroska container can > > - write files of arbitrary size ( we tested 1 TB already ) > - hold any number of video, audio and subtitles streams > - tag files with the matroska tagging system ( not via Dshow Muxer > Filter ) > - keep perfect sync even for very long captures, thanks to timestamps > on the cluster level ( 1 ns precision ) > - significantly reduce overhead compared to AVI ( typically 1 - 3 % > smaller files, especially for big frame sizes ) > > We have support for matroska files in a video editor based on > Virtualdub already, its called VirtualdubMod ( > http://sf.net/projects/virtualdubmod ), and this editor could be > adapted to allow MKV editing with DV content, if a DV VCM codec like > the Panasonic codec is installed. > > We also have plans to make DV a 'native' MKV format, so we had to > define matroska codec IDs for it like > > V_DV/TYPE1 > V_DV/TYPE2 > A_DV/TYPE1 ( or we use the existing A_PCM/INT/xxx , whatever kind of > PCM is normally used in DV ) > > and we could easily update the matroska muxer filter for that, > connecting to your app/source filter using a special > > MEDIATYPE / MEDIASUBTYPE ( you specify that and just tell us ) > > Thanks for a short answer > > Best regards > > Christian > matroska project admin From chris at matroska.org Thu Apr 8 14:36:21 2004 From: chris at matroska.org (Christian HJ Wiesner) Date: Thu, 08 Apr 2004 14:36:21 +0200 Subject: [Matroska-devel] Re: matroska container output for DVIO, replacing crappy AVI ? In-Reply-To: References: Message-ID: <40754745.1080600@matroska.org> Hi Michael, thanks for the very detailled reply ! Michael Carr wrote: >Christian, > >Regarding open source: DVIO is simply a GUI front-end to DirectShow. All it >does is build the filter graph and provide a simple UI. It does no >processing whatsoever. So in that sense, DVIO is already open source because >it represents just a few lines of GUI code on top of the existing DirectShow >SDK. > > Anyhow, you could release the sourcecode on our multimedia focussed opensource community http://www.corecodec.org and found a project for it. Just consider you get rich tomorrow and spend the rest of your life on the Bahamas, and we cant improve DVIO any further ;-) .... gimme a shout if you need assistance .... >Regarding the Matroska DirectShow splitter filter: I would suggest the >following. Write your filter to take data from the file reader on its input >pin and output standard interleaved DV on its output pin. (i.e. a nice, >clean, one-to-one relationship between the output pins on your filter and >the streams in the file). Then, the programmer simply connects the DV Demux >to your output pin to convert the interleaved DV stream into separate audio >and video streams as necessary. In fact, when rendering the pin for >playback, GraphEdt.exe will automatically insert the DV Demux when it >detects interleaved DV data. On your Mux, don't accept DV data unless it is >interleaved (i.e. the programmer has inserted the DV Mux prior to your mux >filter). Yes, using the DV Demux takes a little more processing (<1% CPU on >my AMD 3200+) but all you're really doing is copying bytes straight from the >DV stream into an audio buffer. > > Do i understand this correctly : no DV decoder will accept the video alone, without the interleaved audio ? Can people use 5.1 surround audio, interleaved with DV video that way ? I dont understand why we should stick to the 'audio/video interleaved' solution by all means, when we can easily have any number of separate audio formats coming with the DV video, and using any allowed audio compression format ? Another question : in the DV device, the data are certainly not saved in the AVI container, right ? so, the AVI is just used as an interims container if the interleaved DV packets are read from the DV tape, correct ? >Regarding Type 1 vs. Type 2: I don't think that the answer to providing Type >2-like functionality is to mold your nice new clean file format around an >old, defunct VFW AVI backward-compatibility requirement. In my opinion, >there is absolutely no excuse for VirtualDub "requiring" its users to use >Type 2 DV for any reason. Extracting audio data from Type 1 DV is a VERY >simple operation. I have a tiny 16-line subroutine that pulls the audio >bytes out of the interleaved DV data and sticks them into a PCM audio >buffer. The samples are already PCM in the DV stream, so it's simply a >matter of pulling them out in the correct sequence and sticking them into an >array of bytes. That's it. Why this very simple operation can't be performed >internally by VirtualDub is really a mystery to me, especially when one >considers how incredibly simple the extraction process is compared to the >ramifications of the alternative (i.e. "Type 2 AVI"). Imagine Microsoft >creating a Word 2005 file format that says, "We are going to store all the >images in your document twice in order to be backward compatible with Word >1.0." Such a thing is bad design, plain and simple. > > I agree partially. Of course, our main motivation to demux audio from video should not be limitations of an old, outdated API like VfW. But, i also currently dont see any disadvantages to separating audio and video, and storing only the DV video packets in the video track, and allow any other supported audio compression format being used with it. If you want, we could see DV itself as a ( very limited ) container of its own, and if we put this into AVI or MKV 'as-is', we simply have a 'container-in-a-container' scenario, which we normally try to avoid best we can, for overhead and usability reasons. So, are there any specific reasons why the audio should stay interleaved with the video by all means ? If we export to DV ( e.g. to save the edited video back into the camcorder ), it shouldnt be any problem to connect the matroska audio output pin to the DV muxer audio input, or put the right decoder inbetween the two to produce PCM 16 bit int ? >(Sorry for the ranting here... I spent half of 2001 writing an AVI decoder >that could process DV data. It took me about a week to write the Type 1 >part, then it took me 6 solid months to write the Type 2 part (and it never >did work for every single weird variety of Type 2 file that exists out >there). So I feel very passionate about this issue because I've wasted an >enormous amount of time on it in the past...) > > Well, we have all of this working already in the matroska parsers/demuxers, we can basically handle any number of audio ( and even video streams ) from one file, and in perfect sync, including the switching between the streams from the players. We have to make a basic decision about how to handle DV, and as the audio is clean PCM, i currently dont see any advantage in keeping the two interleaved when muxing DV into MKV. >Regarding DV being a go-between or temporary file format to get to DivX: I >work with many TV broadcasters to author DV processing software for >streaming DV data to TV transmitters in real time. Very few of them have >ever heard of DivX, and I've never met a single one that uses it on a large >scale. This is because: 1. It takes a relatively large amount of time (and a >fair amount of human expertise) to convert DV to DivX, 2. Big hard-drives >are extremely cheap these days, 3. They want the maximum quality possible >(i.e. absolutely zero loss). Many of the broadcasters I work with have >thousands (and maybe tens of thousands) of hours of DV stored on vast arrays >of hard drives. Now, consider the amount of that HD space that is wasted to >unnecessarily store TWO COPIES of tens of thousands of hours of PCM audio. >Yet, they are forced to use it because we still have this strange Type 2 AVI >format floating around and Adobe Premiere insists on using it for everything >that it renders. Personally, I like DivX. I know that the open source >community (of which I am a member) likes DivX. But I don't believe the >statement that DV is mosty a go-between for DivX is quite accurate. > > I was, of course, talking about private users, who are our main usergroup. I absolutely agree that DivX or XviD dont have any meaning for professional customers, but 'normal' people do compressing of their edited footage, to make them fit on a single CD ( or DVD, in full resolution ). All our tools support XviD and DivX, and the goal is to be able to edit the DV MKV in VirtualdubMod, and export it from there into a XviD/DivX MKV with MP3 or Ogg Vorbis audio with a few simple steps. >I'm not familiar with the existing VCM codec, but if you are using the MS >AVI Demux to read a Type 1 file then all you need to do is insert the MS DV >Demux right after it to split Type 1 interleaved data into separate audio >and video streams. (See >http://msdn.microsoft.com/library/default.asp?url=/library/en-us/directx9_c/ >directx/htm/type1vstype2dvfiles.asp) As I said, GraphEdt automatically >inserts this filter as necessary. > > Thats DirectShow, and i thought this would be perfectly possible with it. However, as stated in my previous email, Virtualdub is based on VfW, and not on DShow, and there is no way to handle audio and video in a single stream by using a VCM codec. So, if we like it or not, if we have the average user in the focus of our tools, and he is using Virtualdub or VirtualdubMod, we have to find another solution here. >Using Jory's FLAC compression filter would be a nice FEATURE, but I don't >think it should be a REQUIREMENT of your file format. I think it's better to >leave your file format specification as clean and simple as possible and let >the programmer decide what to stick in the actual file. Again, the DV stream >already contains the audio, so any way you look at it you're still adding >unnecessary bytes to what is already there. If you do want to support FLAC, >then I suggest one video-only stream (i.e. DivX or WMV or M-JPEG or >whatever) and one or more audio-only streams (i.e. FLAC), with neither one >being DV. > > matroska basically allows you to use any supported audio format with any supported video format, so the user has all kinds of freedom here. Jory even made a FLAC.acm codec, to allow transcoding of MKV files with FLAC audio into any other audio format supported from VirtualdubMod, like Ogg Vorbis or any other ACM codec ( MP3, AC3, whatever ). >If you build Type 2 support into Matroska, then you are basically >propagating the same clunky limitations imposed by the original VFW AVI >specification. Isn't the whole idea of Matroska to clean up the AVI >specification and provide a nice, streamlined file format for the future? > As stated above, our decision should be completely independant from the limitations of the AVI container, or the VfW codec API, i fully agree with you here. But they should also not be centered around the DV solution IMO, especially if there are no real advantages in practice. After all, for matroska DV is just one of many possible video codecs .... > Best Regards, > Michael Carr > > Cheers @ devs : Opinions please !!!! And dont forget to copy Micheal in your replies .... Christian matroska project admin From paul at msn.com Thu Apr 8 21:25:50 2004 From: paul at msn.com (Paul Bryson) Date: Thu, 8 Apr 2004 14:25:50 -0500 Subject: [Matroska-devel] Re: matroska container output for DVIO, replacing crappy AVI ? References: <40742411.90303@matroska.org> Message-ID: > Michael Carr wrote: > > One question -- The DV specification defines an interleaved stream, > > meaning that one frame of video is mixed together with its > > corresponding audio. In my experience, it is much better to store the > > DV stream in its native interleaved format (i.e. Type 1) rather than > > storing the audio redundantly in its own stream (i.e. Type 2). You will have to excuse my ignorance as I have never dealt with DV directly before, so I am ignorant to many sides of it. Are you saying that the Type 2 DV in AVI is actually the entire Type 1 stream, in addition to an audio stream that contains the same audio data that is in the video stream? Obviously storing the audio data twice is pretty useless and is not the type of thing that the Matroska team strives for. While it is certainly possible to store a complete Type 1 DV stream in a Matroska stream, we generally try to avoid this. The reason is it offers more flexibility to always allow the user to deal with audio and video completely separately. An example of this is the Matroska Stream Editor that allows a user to add, remove, truncate, append, and shift different types of streams completely independent of the stream type. For instance, you could edit a file on a system without a single codec installed. However, if the video and audio data are stored together in one stream, it is not possible to deal with them separately. In windows, this is about what a DV playback graph should look like, correct? http://www.commo.de/DV-demux.png (note that I don't have an AVI-DV file to decode) If so, what is the problem with doing this? http://www.commo.de/DV-to-Matroska.png As far as I can tell, this should work fine if the Matroska splitter/muxer were updated. What issues do you see with this? A little off topic, but what type of compression scheme is used for DV video? Does it encode each frame as a keyframe? Is the audio really just 16 bit stereo PCM? Is any data lost from the DV when it passes through the DV Splitter? Pamel From jcsston at wiesneronline.net Fri Apr 9 02:03:04 2004 From: jcsston at wiesneronline.net (Jory) Date: Thu, 8 Apr 2004 19:03:04 -0500 Subject: [Matroska-devel] Current status of using libmatroska/libebml in closed-source apps? Message-ID: <000f01c41dc6$127e6560$0200a8c0@jcsston> What is the current status of using libmatroska/libebml in closed-source apps? Was the license changed to LGPL as talked about? Jory From paul at msn.com Fri Apr 9 02:40:49 2004 From: paul at msn.com (Paul Bryson) Date: Thu, 8 Apr 2004 19:40:49 -0500 Subject: [Matroska-devel] Re: matroska container output for DVIO, replacing crappy AVI ? References: <40742411.90303@matroska.org> Message-ID: >From Michael Carr: > Are you saying that the Type 2 DV in AVI is actually the entire Type 1 stream, > in addition to an audio stream that contains the same audio data that is in the > video stream? Obviously storing the audio data twice is pretty useless and is > not the type of thing that the Matroska team strives for. Yes you are absolutely correct. DV exists ONLY as a single interleaved video + audio stream. There is no such thing as "DV video" or "DV audio". Video in the DV stream is actually a type of M-JPEG (motion JPEG) which is simply a JPEG of each individual frame/field of video (there is no temporal compression). Audio in the DV stream is straight 48 kHz 16-bit PCM. The official DV specification simply defines how the M-JPEG and PCM bytes are interleaved together to produce the "DV stream." In other words, DV, by definition, is an interleaved stream of video + audio. Unfortunately I can't send you the official DV spec because it is a copyrighted document costing about $450. So much for open source, eh? However, a TON of info about the DV format is here: http://www.adamwilt.com/DV.html. So where does Type 1 and Type 2 AVI come in? Type 1 is a simple AVI wrapper around the DV stream. However, Microsoft developers quickly discovered that the old VFW-based software expects to see TWO streams in an AVI, one dedicated to video, one dedicated to audio. So, they created Type 2 AVI which contains two streams: the first stream contains the EXACT SAME DV stream as Type 1 (interleaved video + audio) and the second stream contains an EXTRA COPY (in plain PCM format) of the audio portion of the DV stream. So, in effect Type 2 stores the audio data TWICE, once in the original DV interleaved video + audio stream, and once as PCM-only. This makes the old VFW software happy because it sees two streams, one it interprets as video (ignoring the audio portion), and one it interprets as audio. For discussion about Type 1 and Type 2, go here: http://www.microsoft.com/whdc/hwdev/tech/stream/vidcap/dvavi.mspx What problems does this cause? From my perspective, a bunch: 1. A lot of HD space wasted on redundantly storing the audio twice. 2. When exporting a Type 2 AVI to a 1394-enabled device, the CPU must blend the individual video & audio streams together in real-time. Unfortunately, since the Type 2 AVI spec is poorly defined (actually, it is undefined altogether), the data for these streams don't necessarily need to be physically very close to each other in the AVI file. So, you may have a 3.4 GB block of video data followed by a 500 MB block of audio data. Recombining these two streams means that the HD must skip back and forth and back and forth to read the two streams, in real time, GREATLY reducing the efficiency of the HD. I am currently writing an application to stream multiple synchronized DV files to multiple 1394 devices, and Type 2 severely restricts the total number of streams I can handle simultaneously for this very reason. Not to mention the increased CPU (small but not negligible) required to interleave the two streams together. 3. The basic fact that programmers have to worry about two standards instead of one. > While it is certainly possible to store a complete Type 1 DV stream in a > Matroska stream, we generally try to avoid this. The reason is it offers > more flexibility to always allow the user to deal with audio and video > completely separately. An example of this is the Matroska Stream Editor > that allows a user to add, remove, truncate, append, and shift different > types of streams completely independent of the stream type. For instance, > you could edit a file on a system without a single codec installed. > However, if the video and audio data are stored together in one stream, > it is not possible to deal with them separately. I guess we should consider two different questions here: 1. What do we want to physically store on the disk? 2. What functionality do we want to provide to client applications? My personal answers would be: 1. Only physically store the single DV stream. 2. Write your front-end (whether it be a DirectShow front-end or a VfW front-end) to transparently mux/demux DV data (if requested by the client application) in real time, or use Microsoft's already existing DV mux/demux filters. In other words, make it "appear" that you are providing two separate streams even though you are only physically storing one on disk. If you wish, I can provide you with a very simple routine for muxing or demuxing in real-time. Under this scenario, the user can still edit the file w/o having codecs installed since your front-end is doing the work of separating out and combining together the interleaved DV streams. for examples of DV playback graphs, please check out the link I pasted above regarding Type 1 vs. Type 2. > A little off topic, but what type of compression scheme is used for DV video? A type of M-JPEG. > Does it encode each frame as a keyframe? Since there is no temporal compression, then yes every frame is a keyframe. > Is the audio really just 16 bit stereo PCM? Yes. > Is any data lost from the DV when it passes through the DV Splitter? No. The DV Splitter simply copies the audio bytes contained inside the DV stream into a separate PCM buffer. The "video" output pin of the DV Splitter is actually an exact copy of the DV data coming in the input pin. The DV Video Decoder simply ignores the audio portion of this stream. Something else to consider: you mentioned that you want to be able to allow users to add, subtract, shift, etc multiple audio streams in conjunction with a DV "video" stream. What happens when one wants to output such a file to a 1394 device? The 1394 device expects to see a single interleaved DV stream, so your application will need to, in real time: 1. Mix together all the audio channels 2. Interleave the audio channels with the DV stream I'm a bit worried about the mixing process. Not only could it be potentially CPU intensive, but it also leaves the door open for implementation variations. Also, it would significantly increase the complexity of a simple app such as DVIO, for example, because one would need to write a whole new filter (and container logic for adding the filter to the graph) for mixing multiple audio channels, etc. Since my original objective was to make DVIO as reliable as possible by keeping it as simple as possible, it is unlikely I would adopt Matroska in DVIO if it required so much additional work on my part... Michael Carr From paul at msn.com Fri Apr 9 06:12:52 2004 From: paul at msn.com (Paul Bryson) Date: Thu, 8 Apr 2004 23:12:52 -0500 Subject: [Matroska-devel] Re: matroska container output for DVIO, replacing crappy AVI ? References: <40742411.90303@matroska.org> Message-ID: > Yes you are absolutely correct. DV exists ONLY as a single interleaved video > + audio stream. There is no such thing as "DV video" or "DV audio" ........ > In other words, DV, by > definition, is an interleaved stream of video + audio. Ugh. The audio is not a problem as it is regular PCM and can be stored as such. There is no definition of the video alone? That is a little painful. > Unfortunately I can't send you the official DV spec because it is a > copyrighted document costing about $450. So much for open source, eh? Thats okay, I'm sure I would never read it anyway. Much more information than I need. > However, a TON of info about the DV format is here: > http://www.adamwilt.com/DV.html. Thanks, very useful. > So where does Type 1 and Type 2 AVI come in? Type 1 is a simple AVI wrapper > around the DV stream. However, Microsoft developers quickly discovered that > the old VFW-based software expects to see TWO streams in an AVI, one > dedicated to video, one dedicated to audio. So, they created Type 2 AVI > which contains two streams: the first stream contains the EXACT SAME DV > stream as Type 1 (interleaved video + audio) and the second stream contains > an EXTRA COPY (in plain PCM format) of the audio portion of the DV stream. It is pointless in Matroska to store that data twice. Obviously this is something that won't be useful for VFW applications. > So, in effect Type 2 stores the audio data TWICE, once in the original DV > interleaved video + audio stream, and once as PCM-only. This makes the old > VFW software happy because it sees two streams, one it interprets as video > (ignoring the audio portion), and one it interprets as audio. That is idiotic. > What problems does this cause? From my perspective, a bunch: > > 1. A lot of HD space wasted on redundantly storing the audio twice. Obviously. > 2. When exporting a Type 2 AVI to a 1394-enabled device, the CPU must blend > the individual video & audio streams together in real-time. Unfortunately, > since the Type 2 AVI spec is poorly defined (actually, it is undefined > altogether), the data for these streams don't necessarily need to be > physically very close to each other in the AVI file. So, you may have a 3.4 > GB block of video data followed by a 500 MB block of audio data. This would not happen in Matroska as all of the data is timestamped and interleaved by the timestamp. > these two streams means that the HD must skip back and forth and back and > forth to read the two streams, in real time, GREATLY reducing the efficiency > of the HD. I am currently writing an application to stream multiple > synchronized DV files to multiple 1394 devices, and Type 2 severely > restricts the total number of streams I can handle simultaneously for this > very reason. Not to mention the increased CPU (small but not negligible) > required to interleave the two streams together. The thing that I find odd is if the entire Type1 stream is stored in the video stream of an AVI when you store a Type2 file, why not just ignore the audio stream and copy the video stream only as it contains everything? > 3. The basic fact that programmers have to worry about two standards instead > of one. Notable. > I guess we should consider two different questions here: > 1. What do we want to physically store on the disk? > 2. What functionality do we want to provide to client applications? > > My personal answers would be: > 1. Only physically store the single DV stream. > 2. Write your front-end (whether it be a DirectShow front-end or a VfW > front-end) to transparently mux/demux DV data (if requested by the client > application) in real time, or use Microsoft's already existing DV mux/demux > filters. In other words, make it "appear" that you are providing two > separate streams even though you are only physically storing one on disk. If > you wish, I can provide you with a very simple routine for muxing or > demuxing in real-time. We don't like making exceptions. Generally speaking, if it doesn't work, then there is something wrong with the decoder and that is what needs to be fixed. There have already been some decoders fixed in Matroska's development that weren't handling data properly. > Something else to consider: you mentioned that you want to be able to allow > users to add, subtract, shift, etc multiple audio streams in conjunction > with a DV "video" stream. What happens when one wants to output such a file > to a 1394 device? Well, I am making the assumption that the audio isn't necessarily the original PCM audio. This can be part of an interim step in editing, so the audio might be FLAC, Vorbis, AC3, or any number of other audio types. On the other hand, maybe the audio is the original, and the video has since been encoded to something else. In either case, at least part of the file would need to be reencoded. If it were only the audio, then you are talking about simply decoding the audio and possible converting to the correct samplrate/bitdepth plus recombining with the video. Audio decoding is simply not that complex for most formats on any modern computer. Other than that, I guess it depends largely on how hard it is to create a DV stream using DV video and DV audio. Regardless, I'm not really sure if a DV muxer would handle it as, according to you, it would have to overwrite the existing audio in the Type1 track. > I'm a bit worried about the mixing process. Not only could it be potentially > CPU intensive, but it also leaves the door open for implementation > variations. How could there be implementation variations if you have to produce a DV compatible stream? Pamel From paul at msn.com Fri Apr 9 07:39:55 2004 From: paul at msn.com (Paul Bryson) Date: Fri, 9 Apr 2004 00:39:55 -0500 Subject: [Matroska-devel] Re: matroska container output for DVIO, replacing crappy AVI ? References: <40742411.90303@matroska.org> Message-ID: > From Michael Carr: > So, in effect Type 2 stores the audio data TWICE, once in the original DV > interleaved video + audio stream, and once as PCM-only. This makes the old > VFW software happy because it sees two streams, one it interprets as video > (ignoring the audio portion), and one it interprets as audio. I just played with this using the DirectShow DV Muxer and Splitter. The funny thing is that it sets a flag somewhere in the DV stream so that the DV audio isn't rendered. I could mux the audio back in with the video using the muxer and it would play fine. But if I ran that same file back through the splitter and muxer, but not connecting the audio pin from the splitter to the muxer, the resulting file would take the same amount of space, but not play any audio. This is indeed a pain. I suppose someone could write a parser that would strip the DV stream down to just the video stream, but I think that would be going overboard. That would mean you would also likely need to write a whole new DV video decoder, and I don't know of anyone that would want to do that. (although, that is probably the right thing to do.) As far as Matroska is concerned, we should probably make two Codec IDs. One that indicates both the video and audio are contained in the track. And then another that indicates a DV track where the audio is flagged inside of the DV stream not to play. We could also just leave it as is. Either way, support for the DV stream that contains audio also needs to be added to the Matroska Muxer/Splitter. Also, running things through the DV Muxer didn't seem to have a significant impact on required processing to make it work. If stored separately, the audio will bear the standard PCM CodecID as that is exactly what it is. If audio is stored in a different format and you want to stream to a firewire device, then you just decode and resample to the required samplerate and run through the muxer. (Assuming you are doing this through DirectShow) Capturing to Matroska should work fine and it should be recommended to use the Type1 stream as the only stream. If the user wants to edit the file in a VFW application, then it should be a simple matter to run it through a DirectShow graph to separate the audio to a separate stream. Pamel From agebosma at home.nl Fri Apr 9 15:12:40 2004 From: agebosma at home.nl (Age Bosma) Date: Fri, 09 Apr 2004 15:12:40 +0200 Subject: [Matroska-devel] Re: Re: Re: Tag names In-Reply-To: References: <40532BBD.8060909@home.nl> <4054B190.7050008@home.nl> <4055D0F2.7020907@home.nl> Message-ID: <4076A148.2060202@home.nl> To not get too off topic on the foobar forum: If MEDIA_PART can be used to stor disc info, I suggest we add this example to the description of this tag. Because there can be other situations besides the number of discs, e.g. a video tape box set, etc., we can't change this filed name to just disc imo. Should we add CUESHEET and LOGFILE? Although I don't like the idea of storing a complete file into a tag field, it has it's advantages. Personally I prefer a URI to the file in those fields but it's not being used this way. (we could allow both? :-S) SUBALBUM should be added. There's already a RATING field but with it's current description, does it fit in the context of the descussion? Somethig in the line of ALBUM_ARTIST should be added but if we add it like this I think we should change LEAD_PERFORMER to ARTIST like I suggested before as well. For a consistentcy point of view it would cause confusing when we add ALBUM_ARTIST if there isn't a normal ARTIST field in the first place. We could also change it to ALBUM_LEAD_PERFORMER but imo LEAD_PERFORMER doesn't make much sence in the first place (check my reference to see what I mean). We should make clear in the desciption if we recommend SET_PART, TOTAL_SET_PART, MEDIA_PART and TOTAL_MEDIA_PART to be padded with zero's. In the descission I came to the conclusion we shouldn't use padding but I don't know what you think of that. Did I include everything now? :-) Cheers, Age From paul at msn.com Fri Apr 9 17:48:09 2004 From: paul at msn.com (Paul Bryson) Date: Fri, 9 Apr 2004 10:48:09 -0500 Subject: [Matroska-devel] Re: matroska container output for DVIO, replacing crappy AVI ? References: <40742411.90303@matroska.org> Message-ID: >From Michael Carr: Pamel wrote... > The thing that I find odd is if the entire Type1 stream is stored in the video stream of an AVI when you store a Type2 file, why not just ignore the audio stream and copy the video stream only as it contains everything? Excellent idea! In fact, it's exactly what the initial versions of my Type 2 AVI decoder did. Then I started getting calls from clients indicating that their EDITED footage still contained the audio from the original clips, and their new audio was completely missing. After some investigating I discovered that Adobe Premiere (and probably other packages) doesn't bother interleaving the new audio back into the DV stream--they simply copy the original DV data and save the new audio only in the Type 2 audio stream (there is no option in Premiere to save a Type 1 AVI), therefore forcing any export application to MUX the audio stream into the DV stream. Premiere's crappy implementation of DV goes even further -- perhaps you are aware of OpenDML which allows AVI files to contain more than 2 GB of data? Well, it turns out that Premiere-rendered DV is non-OpenDML if the file is less than 2 GB and OpenDML if the file is more than 2 GB (there is no reason whatsoever not to output everything in OpenDML), which further increases decoder complexity. THEN there is another issue -- every AVI file contains an index section which tells the parser the byte offset where each frame of video / audio begins. Well, it turns out that Microsoft-generated DV (via the DV Mux + File Writer) uses the beginning of the file as byte 0. Premiere considers the beginning of the actual video/audio data to be byte 0 (it neglects the file header and video block header). Other codecs consider the beginning of the first video block header to the byte 0. These issues have nothing to do with Type 2 AVI, but I just wanted to give you the same headache I got when I tried to implement the Type 2 parser. :) > I just played with this using the DirectShow DV Muxer and Splitter. The funny thing is that it sets a flag somewhere in the DV stream so that the DV audio isn't rendered. I could mux the audio back in with the video using the muxer and it would play fine. But if I ran that same file back through the splitter and muxer, but not connecting the audio pin from the splitter to the muxer, the resulting file would take the same amount of space, but not play any audio. Yes, there are a variety of flags within the DV stream that notify decoders whether the audio portion should be considered valid or not. Even if the audio portion is considered invalid, the DV packet (which is defined to be a constant size) still contains audio data (or perhaps just zeros where the audio data would normally be). > This is indeed a pain. I suppose someone could write a parser that would strip the DV stream down to just the video stream, but I think that would be going overboard. That would mean you would also likely need to write a whole new DV video decoder, and I don't know of anyone that would want to do that. (although, that is probably the right thing to do.) Yes, that is a good idea but as you say it would require a whole new DV decoder and therefore lots of work... > As far as Matroska is concerned, we should probably make two Codec IDs. One that indicates both the video and audio are contained in the track. And then another that indicates a DV track where the audio is flagged inside of the DV stream not to play. We could also just leave it as is. Either way, support for the DV stream that contains audio also needs to be added to the Matroska Muxer/Splitter. There are already flags within the DV stream that indicate whether the audio should be considered valid or not. You could just use these. > Also, running things through the DV Muxer didn't seem to have a significant impact on required processing to make it work. If stored separately, the audio will bear the standard PCM CodecID as that is exactly what it is. If audio is stored in a different format and you want to stream to a firewire device, then you just decode and resample to the required samplerate and run through the muxer. (Assuming you are doing this through DirectShow) Sounds simple enough, but I still think it would substantially increase the complexity of applications like DVIO. DVIO would need to be prepared to accept a Matroska file that could potentially contain a variety of audio streams in various formats, all of which need to be [potentially] decompressed, [potentially] resampled, [potentially] mixed, and [potentially] interleaved into the DV stream before being transmit to the camera. This is a lot more involved (I don't even want to think about the logic required to build such a graph) than simply reading a file and pushing bytes to the 1394 device as DVIO does now. If one were to create an easy-to-use filter (or collection of filters) that takes an arbitrary Matroska file as an input and spits out a single, ready-to-transmit DV stream, that would go far to belay my concerns and would greatly increase the overall rate of adoption in my opinion. > Capturing to Matroska should work fine and it should be recommended to use the Type1 stream as the only stream. If the user wants to edit the file in a VFW application, then it should be a simple matter to run it through a DirectShow graph to separate the audio to a separate stream. Yes that is what I am suggesting, although it doesn't even need to be that complicated... extracting the audio from the DV stream can be performed with a very simple, short algorithm. No need to go through all the trouble of building and managing an entire DirectShow graph. Regards, Michael Carr From spyder at matroska.org Sat Apr 10 22:09:27 2004 From: spyder at matroska.org (John Cannon) Date: Sat, 10 Apr 2004 15:09:27 -0500 Subject: [Matroska-devel] New Perspective Message-ID: <40785477.5070100@matroska.org> Hi, I'm not sure if this is the best thing to do now but I feel it is. I am stopping all my work on anything related to Nut. At first I worked on it for the experience in C coding. Then it became more about seeing the differences between it and Matroska. Now I have realized that there is no real use in continuing this as it wastes my time I could be using to contribute to Matroska. The Nut muxer source is now tucked away on a backup and that's where it will stay. I will continue to monitor Nut's progress but only for the benefit of Matroska. This has been a very odd week for me in this part of my life. I even considered stopping everything, including my work with Matroska. I don't want to do that. After talking to a few of you I have calmed down. My life is VERY busy right now and I don't have the time really to learn DirectShow or anything that would be of use to us. So, in light of my recent toying with experimental codecs, I have decided the next step for me. I will continue Milk. I am going to finish the codec API and wrap x264 and Skal's MPEG-4 codecs into it. Jory agreed to help me with reading AVISynth and possibly a GUI for it. This will be the first step to VFRE. Soon I will be out of school so this should provide enough foundation and interest for me to develop this further into a Matroska MPEG-4/H.264 encoder app with filtering etc. this summer. I apologize to the team for anything I may have said or done in the past few weeks which hurt the general pride of the group. I have during my time studying other formats realized the one thing that might keep Matroska from being "the perfect container". Don't take this as a bad comment. I know what this means for the format's current design. I don't like what this change would require. I personally like Matroska in it's current form as the problem of sample precision in timecodes doesn't matter much to me. This is only a comment on this flaw, don't take it as a demand for change. This change would be drastic at the moment. But I feel that it's my duty as a team member to voice this here. In my opinion, the only remaining flaw in Matroska's design is that we use a single common timebase for all tracks. This is not a problem of course if you use a really precise timebase. This however does cause an increase in overhead. It works, but in my opinion isn't as elegenat as it could have been. In order to remove this flaw we would have to remove clusters also. I realize that changing this now will break the format's backward compatibility. However, we should consider this. So, I ask you all what your opinion is of this. I know this has been discussed about a bazillion times though. I just think we should discuss this one last time. Other containers are developing rapidly and I am worried they will have more appeal than us before long. I don't want to see that happen. As I always have, I want what's best for Matroska. So, please reply to me and tell me I am not going crazy and that everything will be OK :) I hope this doesn't demotivate any of you. The intention is the exact opposite. We need to get back to work. I think everything has slowed down too much. I know real life gets in the way very often and there's nothing wrong with that. This is just part of my life as I am sure it is the same for you all. I have some great friends here though. Now I will quit talking as I have said enough for now. Let me know what you all think. John From moritz at bunkus.org Sat Apr 10 22:09:51 2004 From: moritz at bunkus.org (Moritz Bunkus) Date: Sat, 10 Apr 2004 22:09:51 +0200 Subject: [Matroska-devel] Re: New Perspective In-Reply-To: <316131546.3201.1081633505@wiesneronline.net> References: <316131546.3201.1081633505@wiesneronline.net> Message-ID: <20040410200951.GM12604@bunkus.org> Hey John, well... Let me tell you I've thought about supporting nut in mkvmerge as well. I consider myself to be primarily an engineer interested in coding & technology, not so much in the more 'political' aspects. But this would severly hurt Matroska, and I would disappoint a lot of folks, so I won't do it. Now your coding for nut has left me wondering once or twice, but I don't think less of you because you wanted to do that. And you've never hurt me, please don't worry about that. It was your decision, plain and simple. So if you decide now that you don't want to do it anymore then I'm more than happy because it does hurt Matroska. We're only few persons to begin with, so we shouldn't work on nut or e.g. MP4 too much. As to your 'weird week' - believe me, I totally get what you mean. I've had my share of that as well. I've had such a week myself: frustration mixed with lack of motivation; then there were talks about 'discontinuing Matroska' somehow after I had spent nearly all of my free time working on it for the previous couple of months. Leaves you wondering if you had done the right thing and what would happen next and how drastic the changes would be... A couple of days later everything was alright again. But pulling through is important. Don't give up. If you need a timeout then take it. But you seem to have made up your mind already, and if you're motivated to work on Milk then by all means do that! Now to the Matroska deficiencies. I agree with you. I've always wanted to simplify the block layout and get rid of the explicit references or at least provide a flag that says 'this block contains only frame type flags' or 'this block contains proper references'. This would really decrease file size. Another thing that would have been VERY helpful would have been to store all clusters one level lower under a 'KaxClusters' element so that skipping over all clusters would have been a lot easier. But this would MASSIVELY increase complexity for demuxers because they'd have to support both versions. Demuxers that don't rely on specific elements being on specific levels are safe(r), but others will be a bitch. Next thing: different time bases. I agree. It'd have been better to have separated them. But if we do that we get problems with the clusters because the cluster timecode is scaled. I see three options: 1) Get rid of clusters. Obvious disadvantage is that it would require changes to the block structure as 16bit relative timecodes are simply not possible then and the overhead would immediately go through the roof. 2) Use a new cluster-track timecode for each track in the file. The obvious disadvantage is that it'll increase overhead a bit. These timecodes would be in track timecode units. 3) Same as 2) but put those cluster-track-timecodes before the first block of that track in a cluster. This would gain us a bit of size compared to 2) for tracks that do not have packets in each cluster (e.g. subtitles, but here the overhead is small anyway). And it would simplify the muxers a lot. I think that 3) would be the best option if we want to implement track independant timecode scaling. But maybe there are even better solutions for this... Anyway, I'm really 'pro change', but if we do it we should change a lot at once and declare that 'Matroska v2' or sth like that. 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 suiryc at yahoo.com Sat Apr 10 22:52:20 2004 From: suiryc at yahoo.com (Cyrius) Date: Sat, 10 Apr 2004 13:52:20 -0700 (PDT) Subject: [Matroska-devel] New Perspective In-Reply-To: <40785477.5070100@matroska.org> Message-ID: <20040410205220.16331.qmail@web12907.mail.yahoo.com> Hi Damn, and I wanted you to add Nut support in VDM ;) --- John Cannon wrote: > My life is VERY busy > right now and I don't have the time really to learn DirectShow or > anything that would be of use to us. So, in light of my recent > toying > with experimental codecs, I have decided the next step for me. I > will > continue Milk. I am going to finish the codec API and wrap x264 and > Skal's MPEG-4 codecs into it. Jory agreed to help me with reading > AVISynth and possibly a GUI for it. This will be the first step to > VFRE. Soon I will be out of school so this should provide enough > foundation and interest for me to develop this further into a > Matroska > MPEG-4/H.264 encoder app with filtering etc. this summer. I > apologize > to the team for anything I may have said or done in the past few > weeks > which hurt the general pride of the group. Eheh, don't worry and just do as I do: work at your own pace :p > I have during my time studying other formats realized the one thing > that > might keep Matroska from being "the perfect container". Don't take > this > as a bad comment. I know what this means for the format's current > design. I don't like what this change would require. I personally > like > Matroska in it's current form as the problem of sample precision in > timecodes doesn't matter much to me. This is only a comment on this > flaw, don't take it as a demand for change. This change would be > drastic at the moment. But I feel that it's my duty as a team member > to > voice this here. In my opinion, the only remaining flaw in > Matroska's > design is that we use a single common timebase for all tracks. This > is > not a problem of course if you use a really precise timebase. This > however does cause an increase in overhead. It works, but in my > opinion > isn't as elegenat as it could have been. In order to remove this > flaw > we would have to remove clusters also. I realize that changing this > now > will break the format's backward compatibility. However, we should > consider this. So, I ask you all what your opinion is of this. I > know this has been discussed about a bazillion times though. I just > think we should discuss this one last time. Other containers are > developing rapidly and I am worried they will have more appeal than > us > before long. I don't want to see that happen. As I always have, I > want > what's best for Matroska. Yeah it's true that it's a big difference between Matroska and some other containers. Containers like AVI or OGM (and Nut too I think) use sample precision information. But I think it was an aim at the beginning for Matroska, i.e. rely on timestamps and not sample count ... This for example allows VFR streams without effort (with sample precisioon you can do it too, but the trick is the same as using timestamps). So one of the aims of Matroska is fulfilled with the timestamps. Now of course the precision isn't enough for very precise editing so maybe we indeed should try to think about a better system here. > So, please reply to me and tell me I am > not > going crazy and that everything will be OK :) What are you saying? We all know you are crazy :p > I hope this doesn't > demotivate any of you. The intention is the exact opposite. We need > to > get back to work. I think everything has slowed down too much. I > know > real life gets in the way very often and there's nothing wrong with > that. This is just part of my life as I am sure it is the same for > you > all. I have some great friends here though. Now I will quit talking > as > I have said enough for now. Let me know what you all think. nah I don't feel demotivated (yet :p). I also have some real life matters to take care of. So just keep in mind the piece of advice from earlier :p Best regards Cyrius __________________________________ Do you Yahoo!? Yahoo! Tax Center - File online by April 15th http://taxes.yahoo.com/filing.html From paul at msn.com Sun Apr 11 10:04:18 2004 From: paul at msn.com (Paul Bryson) Date: Sun, 11 Apr 2004 03:04:18 -0500 Subject: [Matroska-devel] Re: New Perspective References: <40785477.5070100@matroska.org> Message-ID: Wow, I had no idea anything was happenning because I hadn't been reading the logs from IRC. To lazy lately even though I have done nothing for about 2 weeks. Honestly it hasn't bothered me that you have worked on NUT lately. I don't think its very productive, but a lot of people do isn't and its not a big concern to me. NUT will never become a common format because the people in charge of it will never push it enough. I'm sure that BBB would love to make some comments about this type of thing, but it doesn't matter. Well, I guess Dick is pushing it a little. At least it has given you perspective for Matroska. What I like shouldn't matter much, but I do like you working on Matroska. The important thing is for you to do what you are interested in. Honestly, independant fractional timecodes for the Blocks would have been nice. Also, having all of the Clusters one level lower would have been really nice too. Maybe the lower clusters can come with version 2, but that can be talked about later. About the timecodes, as it turns out it doesn't matter. I thought the same thing when I started writing up how to do sample precise seeking and it really bothered me. I kicked around a lot of ideas trying to see if there was an easy way to implement it, or if a more drastic structure change would be best. Mosu mentions some of the same ideas that I had, and in fact I also considered the clusterless type streams that you were talking about. I put a lot of thought into how to do this until I realized something surprising. It doesn't matter. It actually came from something that I noticed in DirectShow and thought was a rather annoying bug. When playing with the Matroska Stream Editor, I made many different types of expiremental files with all sorts of weird cases. One of these was a file with a video track, and an audio track that had about a 5 second period in the middle where there were no audio packets. I assumed that on playback the file would just be silent for 5 seconds and then start playing audio again. It didn't. It played the audio without a break and skipped all of the video where the audio should have been skipped. at first I thought the file had been written wrong, but I looked at it and it was written correctly with data interleaved in the correct places and timestamps correct for the Blocks showing a 5 second gap for the audio. It took a while to figure out why DirectShow was skipping that whole section of video. I suddenly realized that DirectShow (like every other playback application) times everything based on the audio renderer. So when the audio decoder passes on a block with audio in it, the renderer plays the audio and tells everything else to play whatever is at the timecode attached to the audio. If it weren't this way, Matroska never would have played correctly because of the rounding with the timestamps. One important thing to remember about those precise timestamps used by fractional systems (such as 1/44100) is that you can't insert a precise delay or gap in the audio because you always have to use whatever resolution is being provided to you by the samples. You just end up rounding again, although at an again imperceptible amount, its just important to realize. This means that you can have audio drift from an imprecise audio clock for capture. Not a good reason not to use fractional systems, but important to remember for perspective. Pamel From alexander.noe at s2001.tu-chemnitz.de Sun Apr 11 10:57:42 2004 From: alexander.noe at s2001.tu-chemnitz.de (alexander.noe at s2001.tu-chemnitz.de) Date: Sun, 11 Apr 2004 10:57:42 +0200 Subject: [Matroska-devel] Re: New Perspective In-Reply-To: References: <40785477.5070100@matroska.org> Message-ID: <1081673862.40790886a2b37@mail.tu-chemnitz.de> Zitat von Paul Bryson : > the audio. It took a while to figure out why DirectShow was skipping that > whole > section of video. I suddenly realized that DirectShow (like every other > playback application) times everything based on the audio renderer. LOL. I once had a soundcard (SB AWE64 Value) which had a frequency that was off by 0.2%. If DS didn't use the audio as 'master stream', playback would have been off by 1s per 8minutes... Alex From jcsston at wiesneronline.net Sun Apr 11 22:58:33 2004 From: jcsston at wiesneronline.net (Jory) Date: Sun, 11 Apr 2004 15:58:33 -0500 Subject: [Matroska-devel] Status of WinStreamer (GStreamer Win32 port) Message-ID: <000801c42007$d807db70$0200a8c0@jcsston> I've decided to write up an email about the current/past status of GStreamer for Windows. First topic the VarArg Marcos, this has been the main (if only) thing holding the Windows port. MSVC doesn't support them. The Intel compilers supports VarArg macros with a slightly different syntax than POSIX and C99. GCC (MinGW) supports them. Steve started the port to compile in MSVC by replacing a number of the VarArg macros with inline VarArg functions, but a number of the macros are used in plugins to declare new required functions and/or structs, which cannot work with inline functions. I furthered Steve's work by adding replacement macros for the VarArg macros with macros postfixed with the argument count. Ex. MACRO1(x1) MACRO2(x1, x2), ... However the VarArg macro changes is too much of a change to be accepted into the official GStreamer branch. They have received patches for VarArg macros for other platforms (Axis IIRC) and didn't accept those either. The problem is about how difficult it would be to stay in synch with GStreamer main dev branch So the GCC compiler looks to be a good choice. However, the point with falling back to GCC is we leave in the VarArg macros, and GStreamer is pumped full of them. So, all and any programs wanting to use GStreamer have to use GCC. And Why do we care if MSVC cannot be used? Because most Windows developers use it and it also has some extra stuff like GCC that is non-standard. For example both GCC and MSVC have different syntax for assembly and inline assembly, which in multimedia plugins is often needed. Now to why I have not worked on it. I dislike GDB (please no MSVC vs. GCC here). I have also been busy with JEBML and RL ;) Jory From steve.lhomme at free.fr Mon Apr 12 23:15:00 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Mon, 12 Apr 2004 23:15:00 +0200 Subject: [Matroska-devel] DV in MKV In-Reply-To: <002601c41cb7$46a221c0$0200a8c0@jcsston> References: <4073D6F9.9050305@matroska.org> <002601c41cb7$46a221c0$0200a8c0@jcsston> Message-ID: <407B06D4.1090306@free.fr> Jory wrote: > Though this my get me shoot around here, I don't see any reason to have DV > in MKV. > Just about any AVI app can handle AVI DV Type-2 fine, the file size is a > moot point since any recent app can handle 36GB AVI's. The problem is that Type2 AVI contain twice the audio track which is stupid. In Matroska we can have "complex" streams like DV in which there is both audio and video and that's what should be used for DV... It would be nice to have DV in Matroska. But it will means current filters/parsers will have to be updated to be able to handle complex streams... It would be usefull to be able to encode then this DV-in-MKV file to whatever you want. From steve.lhomme at free.fr Mon Apr 12 23:23:24 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Mon, 12 Apr 2004 23:23:24 +0200 Subject: [Matroska-devel] Re: matroska container output for DVIO, replacing crappy AVI ? In-Reply-To: <40742411.90303@matroska.org> References: <40742411.90303@matroska.org> Message-ID: <407B08CC.7050404@free.fr> Christian HJ Wiesner wrote: > Hi Michael, > > thanks for the quick reply. > > Michael Carr wrote: > >> Sounds like a good idea. At the moment my time is severely limited >> because of several other projects, but I will definitely add it to >> DVIO as soon as possible. > > > If we can help, let us know. Have you ever considered making DVIO > opensource BTW ? You dont have to answer if you consider this question > impolite ;-) .... > >> One question -- The DV specification defines an interleaved stream, >> meaning that one frame of video is mixed together with its >> corresponding audio. In my experience, it is much better to store the >> DV stream in its native interleaved format (i.e. Type 1) rather than >> storing the audio redundantly in its own stream (i.e. Type 2). This >> leads to all sorts of confusion, plus extra file storage, plus extra >> CPU overhead on record/playback, on the part of a reader/writer that >> is formatting DV data. I have been advocating for a while to get rid >> of Type 2 for these reasons, so this would be a great opportunity to >> do so... what are your thoughts about this? > > > As Admin on the biggest existing Virtualdub user forums ( > http://virtualdub.everwicked.com ) i know that DV type-1 AVIs are > causing problems mainly because Virtualdub cant handle the embedded > audio in the video stream correctly, as a result of the limitations of > the VCM API. So, if people like to extract the audio for further > processing, they are stuck and cant do that with type 1, thats where > type 2 comes in handy. As DV AVI, in most cases, is anyhow only used as > an interims format and the footage is processed in DivX/MP3 AVIs or > DVDs, the extra file size for the additional audio stream is not a big > problem. I don't agree. We should not make crappy choices because of coders lazyness. Of course the path to have native DV is harder, but IMO that's the only one that makes sense... Don't make Matroska dirty because VDub has limitations. If there is a pb in VD that's where it should be fixed. > 3. We are in the process of porting Gstreamer ( http://www.gstreamer.org > ) to win32, and to create a new, variable frame rate ( VFR ) capable > video editor based on that, of course as an opensource project. We are > well aware it will take a lot fo time until this new app, called TCME, > will be able to replace Virtualdub even partially, but as we can > influence the API for it, its well possible we add the capability to > handle embedded audio in video streams, thus allowing easy DV type 1 > editing from it. If a basic command-line application can convert DV-in-mkv to any other thing (DivX-in-AVI, RV9-in-mkv, MPEG2-for-DVD) then it's already a huge step and no need to wait for a complicated app to appear to be able to do things. From steve.lhomme at free.fr Mon Apr 12 23:46:06 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Mon, 12 Apr 2004 23:46:06 +0200 Subject: [Matroska-devel] Re: matroska container output for DVIO, replacing crappy AVI ? In-Reply-To: References: <40742411.90303@matroska.org> Message-ID: <407B0E1E.2090103@free.fr> Paul Bryson wrote: >>these two streams means that the HD must skip back and forth and back and >>forth to read the two streams, in real time, GREATLY reducing the efficiency >>of the HD. I am currently writing an application to stream multiple >>synchronized DV files to multiple 1394 devices, and Type 2 severely >>restricts the total number of streams I can handle simultaneously for this >>very reason. Not to mention the increased CPU (small but not negligible) >>required to interleave the two streams together. > > > The thing that I find odd is if the entire Type1 stream is stored in the video > stream of an AVI when you store a Type2 file, why not just ignore the audio > stream and copy the video stream only as it contains everything? OK, a solution I see for Matroska is the following : - demux the audio and video parts of the DV stream - store the M-JPEG video in a stream as V_DV/M-JPEG - store the PCM audio in a stream as A_DV/PCM (or something like this, to recognize that it is supposed be mixed with DV video, in case you want to put more streams in that file) On playback you could either remux the audio in the stream needed by the DV decoder or just put silent audio (0) in this stream if you know the video decoder will ignore it. This way the video decoder will have something that looks like a real DV stream and even VDM could use it. BTW Michael, it would be nice then to convince your contacts to switch to Matroska ;) >>Something else to consider: you mentioned that you want to be able to allow >>users to add, subtract, shift, etc multiple audio streams in conjunction >>with a DV "video" stream. What happens when one wants to output such a file >>to a 1394 device? See my previous statement on playback. Based on *all* that is stored in the Matroska file, it should be possible to extract the same exact DV stream that it was originally sourced from. The rest is only a matter of coding (muxing 2 streams which is nothing). And as Paul mentions, it should also be possible to use the DV video and extract the audio from a compressed streamed... very possible with DirectShow! BTW, DV audio can also be ADPCM coded, right ? From steve.lhomme at free.fr Mon Apr 12 23:54:28 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Mon, 12 Apr 2004 23:54:28 +0200 Subject: [Matroska-devel] Re: matroska container output for DVIO, replacing crappy AVI ? In-Reply-To: References: <40742411.90303@matroska.org> Message-ID: <407B1014.7030608@free.fr> Paul Bryson wrote: > >>Also, running things through the DV Muxer didn't seem to have a significant > > impact on required processing to make it work. If stored separately, the audio > will bear the standard PCM CodecID as that is exactly what it is. If audio is > stored in a different format and you want to stream to a firewire device, then > you just decode and resample to the required samplerate and run through the > muxer. (Assuming you are doing this through DirectShow) > > Sounds simple enough, but I still think it would substantially increase the > complexity of applications like DVIO. DVIO would need to be prepared to accept a > Matroska file that could potentially contain a variety of audio streams in > various formats, all of which need to be [potentially] decompressed, > [potentially] resampled, [potentially] mixed, and [potentially] interleaved into > the DV stream before being transmit to the camera. This is a lot more involved > (I don't even want to think about the logic required to build such a graph) than > simply reading a file and pushing bytes to the 1394 device as DVIO does now. If > one were to create an easy-to-use filter (or collection of filters) that takes > an arbitrary Matroska file as an input and spits out a single, ready-to-transmit > DV stream, that would go far to belay my concerns and would greatly increase the > overall rate of adoption in my opinion. This is what I have in mind and we have all the hands and skills to do that. >>Capturing to Matroska should work fine and it should be recommended to use the > > Type1 stream as the only stream. If the user wants to edit the file in a VFW > application, then it should be a simple matter to run it through a DirectShow > graph to separate the audio to a separate stream. As I said, VDM would have any problem with a demuxed DV stream stored in Matroska. From steve.lhomme at free.fr Mon Apr 12 23:56:06 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Mon, 12 Apr 2004 23:56:06 +0200 Subject: [Matroska-devel] Current status of using libmatroska/libebml in closed-source apps? In-Reply-To: <000f01c41dc6$127e6560$0200a8c0@jcsston> References: <000f01c41dc6$127e6560$0200a8c0@jcsston> Message-ID: <407B1076.9030108@free.fr> Jory wrote: > What is the current status of using libmatroska/libebml in closed-source > apps? > Was the license changed to LGPL as talked about? Not yet. Maybe we should ask Ingo for his approval to make the switch. Then I think everyone will agree on the move to this single license. (but I don't have his email here) From steve.lhomme at free.fr Tue Apr 13 00:01:47 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Tue, 13 Apr 2004 00:01:47 +0200 Subject: [Matroska-devel] Re: New Perspective In-Reply-To: <316131546.3201.1081633505@wiesneronline.net> References: <316131546.3201.1081633505@wiesneronline.net> Message-ID: <407B11CB.60706@free.fr> John Cannon wrote: > design. I don't like what this change would require. I personally like > Matroska in it's current form as the problem of sample precision in > timecodes doesn't matter much to me. This is only a comment on this > flaw, don't take it as a demand for change. This change would be > drastic at the moment. But I feel that it's my duty as a team member to > voice this here. In my opinion, the only remaining flaw in Matroska's > design is that we use a single common timebase for all tracks. This is The idea in a muxed format is that all streams that shared the same timeframe are related. It doesn't make sense to have one that has 1s precision and another 1ns. But it's still possible, like what we do with subs. The timecode precision can be done with additions, not radical changes to the format. From steve.lhomme at free.fr Tue Apr 13 00:05:51 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Tue, 13 Apr 2004 00:05:51 +0200 Subject: [Matroska-devel] Re: New Perspective In-Reply-To: <20040410200951.GM12604@bunkus.org> References: <316131546.3201.1081633505@wiesneronline.net> <20040410200951.GM12604@bunkus.org> Message-ID: <407B12BF.1050705@free.fr> Moritz Bunkus wrote: > Next thing: different time bases. I agree. It'd have been better to have > separated them. But if we do that we get problems with the clusters > because the cluster timecode is scaled. I see three options: > > 1) Get rid of clusters. Obvious disadvantage is that it would require > changes to the block structure as 16bit relative timecodes are simply > not possible then and the overhead would immediately go through the > roof. > 2) Use a new cluster-track timecode for each track in the file. The > obvious disadvantage is that it'll increase overhead a bit. These > timecodes would be in track timecode units. > 3) Same as 2) but put those cluster-track-timecodes before the first > block of that track in a cluster. This would gain us a bit of size > compared to 2) for tracks that do not have packets in each cluster > (e.g. subtitles, but here the overhead is small anyway). And it would > simplify the muxers a lot. > > I think that 3) would be the best option if we want to implement track > independant timecode scaling. But maybe there are even better solutions > for this... Anyway, I'm really 'pro change', but if we do it we should > change a lot at once and declare that 'Matroska v2' or sth like that. I agree that this would be the one if we want streams with independant timecodes. But can anybody explain me the point in that ? From steve.lhomme at free.fr Tue Apr 13 00:07:26 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Tue, 13 Apr 2004 00:07:26 +0200 Subject: [Matroska-devel] New Perspective In-Reply-To: <20040410205220.16331.qmail@web12907.mail.yahoo.com> References: <20040410205220.16331.qmail@web12907.mail.yahoo.com> Message-ID: <407B131E.60401@free.fr> Cyrius wrote: > > Yeah it's true that it's a big difference between Matroska and some > other containers. > Containers like AVI or OGM (and Nut too I think) use sample precision > information. > But I think it was an aim at the beginning for Matroska, i.e. rely on > timestamps and not sample count ... This for example allows VFR streams > without effort (with sample precisioon you can do it too, but the trick > is the same as using timestamps). > So one of the aims of Matroska is fulfilled with the timestamps. Now of > course the precision isn't enough for very precise editing so maybe we > indeed should try to think about a better system here. As they say, it's not a bug it's a feature ! From steve.lhomme at free.fr Tue Apr 13 00:15:55 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Tue, 13 Apr 2004 00:15:55 +0200 Subject: [Matroska-devel] Re: New Perspective In-Reply-To: References: <40785477.5070100@matroska.org> Message-ID: <407B151B.3070604@free.fr> Paul Bryson wrote: > Honestly, independant fractional timecodes for the Blocks would have been nice. > Also, having all of the Clusters one level lower would have been really nice > too. Maybe the lower clusters can come with version 2, but that can be talked Actually when you have a nice SeekHead you don't need this upper element. And the Clusters at level 0 (or 1?) doesn't come from nowhere. It's for streaming reasons, where you should be able to put any level 1 (or 0) element at anytime to restate things. Ultimately for broadcasting it could be between each Cluster. From steve.lhomme at free.fr Tue Apr 13 00:20:26 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Tue, 13 Apr 2004 00:20:26 +0200 Subject: [Matroska-devel] Status of WinStreamer (GStreamer Win32 port) In-Reply-To: <000801c42007$d807db70$0200a8c0@jcsston> References: <000801c42007$d807db70$0200a8c0@jcsston> Message-ID: <407B162A.701@free.fr> Jory wrote: > I've decided to write up an email about the current/past status of GStreamer > for Windows. > > First topic the VarArg Marcos, this has been the main (if only) thing > holding the Windows port. > MSVC doesn't support them. > The Intel compilers supports VarArg macros with a slightly different syntax > than POSIX and C99. > GCC (MinGW) supports them. > > Steve started the port to compile in MSVC by replacing a number of the > VarArg macros with inline VarArg functions, but a number of the macros are > used in plugins to declare new required functions and/or structs, which > cannot work with inline functions. > > I furthered Steve's work by adding replacement macros for the VarArg macros > with macros postfixed with the argument count. Ex. MACRO1(x1) MACRO2(x1, > x2), ... > > However the VarArg macro changes is too much of a change to be accepted into > the official GStreamer branch. They have received patches for VarArg macros > for other platforms (Axis IIRC) and didn't accept those either. > The problem is about how difficult it would be to stay in synch with > GStreamer main dev branch It was quickly clear to me that they would not care about making GStreamer usable for Windows users/developpers. That's a real pity that they want to keep these macros just for political or fancy reasons. And I agree, using GCC under Windows suck. I wish XCode would be ported to Windows ;) From jcsston at wiesneronline.net Tue Apr 13 01:30:24 2004 From: jcsston at wiesneronline.net (Jory) Date: Mon, 12 Apr 2004 18:30:24 -0500 Subject: [Matroska-devel] Re: matroska container output for DVIO, replacingcrappy AVI ? References: <40742411.90303@matroska.org> <407B0E1E.2090103@free.fr> Message-ID: <001c01c420e6$34cec6f0$0200a8c0@jcsston> ----- Original Message ----- From: "Steve Lhomme" To: Cc: Sent: Monday, April 12, 2004 4:46 PM Subject: Re: [Matroska-devel] Re: matroska container output for DVIO, replacingcrappy AVI ? > OK, a solution I see for Matroska is the following : > - demux the audio and video parts of the DV stream > - store the M-JPEG video in a stream as V_DV/M-JPEG > - store the PCM audio in a stream as A_DV/PCM (or something like this, > to recognize that it is supposed be mixed with DV video, in case you > want to put more streams in that file) What do we do with the date/time stream? BTW DV != MJPEG, yes it uses DCT and similar compression methods, but it's close to I-frame MPEG-2 IIRC. > See my previous statement on playback. Based on *all* that is stored in > the Matroska file, it should be possible to extract the same exact DV > stream that it was originally sourced from. The rest is only a matter of > coding (muxing 2 streams which is nothing). And as Paul mentions, it > should also be possible to use the DV video and extract the audio from a > compressed streamed... very possible with DirectShow! > > BTW, DV audio can also be ADPCM coded, right ? For DV you have 2 channel 16-bit 48KHz or 4 channel 12-bit 32KHz PCM. \ Jory Stone From steve.lhomme at free.fr Tue Apr 13 01:34:23 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Tue, 13 Apr 2004 01:34:23 +0200 Subject: [Matroska-devel] Re: matroska container output for DVIO, replacingcrappy AVI ? In-Reply-To: <001c01c420e6$34cec6f0$0200a8c0@jcsston> References: <40742411.90303@matroska.org> <407B0E1E.2090103@free.fr> <001c01c420e6$34cec6f0$0200a8c0@jcsston> Message-ID: <407B277F.6000108@free.fr> Jory wrote: >>OK, a solution I see for Matroska is the following : >>- demux the audio and video parts of the DV stream >>- store the M-JPEG video in a stream as V_DV/M-JPEG >>- store the PCM audio in a stream as A_DV/PCM (or something like this, >>to recognize that it is supposed be mixed with DV video, in case you >>want to put more streams in that file) > > > What do we do with the date/time stream? We save it next to the video stream in the Matroska frame. So that it can be reused later to recover the original data. From rbultje at ronald.bitfreak.net Tue Apr 13 16:52:36 2004 From: rbultje at ronald.bitfreak.net (Ronald Bultje) Date: Tue, 13 Apr 2004 16:52:36 +0200 (CEST) Subject: [Matroska-devel] Status of WinStreamer (GStreamer Win32 port) In-Reply-To: <407B162A.701@free.fr> Message-ID: Hi, On Tue, 13 Apr 2004, Steve Lhomme wrote: > It was quickly clear to me that they would not care about making > GStreamer usable for Windows users/developpers. That's a real pity that > they want to keep these macros just for political or fancy reasons. We do care. We just decided - long time ago - to use C99 as basis for GStreamer coding. Why would we suddenly revert? We had and still have good reasons to conform to this global standard. If you care, make an #ifdef somewhere in a win32-specific header (gst/gstwin32.h or so) and make them vararg functions in the win32 case. However, the "vararg macro" patches were really unacceptable: I don't want GST_DEBUG_1(), GST_DEBUG_2() etc. That destroys the whole use of the vararg macros. You simply cannot disagree here. And on the long run, MSVC has to support C99 and it's vararg macros. It's really just that simple. We're not going to change our plugin coding style because of a port to an inferior, standard-incompliant compiler. Even if it's Microsoft's. We are *not* part of their embrace, extend and exterminate way-of-life. Ronald From jcsston at wiesneronline.net Tue Apr 13 18:39:37 2004 From: jcsston at wiesneronline.net (Jory) Date: Tue, 13 Apr 2004 11:39:37 -0500 Subject: [Matroska-devel] Status of WinStreamer (GStreamer Win32 port) References: Message-ID: <000c01c42175$f7c130a0$0200a8c0@jcsston> It sure seems strange them you send an email supporting both reasons mentioned. ----- Original Message ----- From: "Ronald Bultje" To: "Steve Lhomme" Cc: "Discussion about the current and future development of Matroska" Sent: Tuesday, April 13, 2004 9:52 AM Subject: Re: [Matroska-devel] Status of WinStreamer (GStreamer Win32 port) > Hi, > > On Tue, 13 Apr 2004, Steve Lhomme wrote: > > It was quickly clear to me that they would not care about making > > GStreamer usable for Windows users/developpers. That's a real pity that > > they want to keep these macros just for political or fancy reasons. > > We do care. We just decided - long time ago - to use C99 as basis for > GStreamer coding. Why would we suddenly revert? We had and still have good > reasons to conform to this global standard. > > If you care, make an #ifdef somewhere in a win32-specific header > (gst/gstwin32.h or so) and make them vararg functions in the win32 case. > However, the "vararg macro" patches were really unacceptable: I don't want > GST_DEBUG_1(), GST_DEBUG_2() etc. That destroys the whole use of the > vararg macros. You simply cannot disagree here. fancy > And on the long run, MSVC has to support C99 and it's vararg macros. It's > really just that simple. We're not going to change our plugin coding style > because of a port to an inferior, standard-incompliant compiler. Even if > it's Microsoft's. We are *not* part of their embrace, extend and > exterminate way-of-life. political BTW The last time I checked the AIX platform didn't use a MS compiler... Jory From rbultje at ronald.bitfreak.net Tue Apr 13 18:47:47 2004 From: rbultje at ronald.bitfreak.net (Ronald Bultje) Date: Tue, 13 Apr 2004 18:47:47 +0200 (CEST) Subject: [Matroska-devel] Status of WinStreamer (GStreamer Win32 port) In-Reply-To: <000c01c42175$f7c130a0$0200a8c0@jcsston> Message-ID: Hi, On Tue, 13 Apr 2004, Jory wrote: > BTW The last time I checked the AIX platform didn't use a MS compiler... The latest version of the AIX compiler supports C99. You didn't read the bugzilla report correctly. ;). Ronald From steve.lhomme at free.fr Tue Apr 13 18:55:50 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Tue, 13 Apr 2004 18:55:50 +0200 Subject: [Matroska-devel] Status of WinStreamer (GStreamer Win32 port) In-Reply-To: References: Message-ID: <1081875350.407c1b9638a17@imp4-q.free.fr> Selon Ronald Bultje : > Hi, > > On Tue, 13 Apr 2004, Steve Lhomme wrote: > > It was quickly clear to me that they would not care about making > > GStreamer usable for Windows users/developpers. That's a real pity that > > they want to keep these macros just for political or fancy reasons. > > We do care. We just decided - long time ago - to use C99 as basis for > GStreamer coding. Why would we suddenly revert? We had and still have good > reasons to conform to this global standard. > > If you care, make an #ifdef somewhere in a win32-specific header > (gst/gstwin32.h or so) and make them vararg functions in the win32 case. > However, the "vararg macro" patches were really unacceptable: I don't want > GST_DEBUG_1(), GST_DEBUG_2() etc. That destroys the whole use of the > vararg macros. You simply cannot disagree here. > > And on the long run, MSVC has to support C99 and it's vararg macros. It's I know the world should revolve around GStreamer and not the opposite ;) That's about what you're trying to say here. And that's this kind of mind closed philosophy that I said : > > It was quickly clear to me that they would not care about making > > GStreamer usable for Windows users/developpers. That's a real pity that > > they want to keep these macros just for political or fancy reasons. From R.S.Bultje at students.uu.nl Tue Apr 13 22:18:50 2004 From: R.S.Bultje at students.uu.nl (Ronald S. Bultje) Date: Tue, 13 Apr 2004 22:18:50 +0200 Subject: [Matroska-devel] Status of WinStreamer (GStreamer Win32 port) In-Reply-To: <000c01c42175$f7c130a0$0200a8c0@jcsston> References: <000c01c42175$f7c130a0$0200a8c0@jcsston> Message-ID: <1081887528.24783.38.camel@shrek.bitfreak.net> Hi Jory, (just got home, so time for serious replies now ;) ) On Tue, 2004-04-13 at 18:39, Jory wrote: > It sure seems strange them you send an email supporting both reasons > mentioned. I'm sorry, but I disagree here... > > On Tue, 13 Apr 2004, Steve Lhomme wrote: > > > It was quickly clear to me that they would not care about making > > > GStreamer usable for Windows users/developpers. That's a real pity that > > > they want to keep these macros just for political or fancy reasons. > > > > We do care. We just decided - long time ago - to use C99 as basis for > > GStreamer coding. Why would we suddenly revert? We had and still have good > > reasons to conform to this global standard. > > > > If you care, make an #ifdef somewhere in a win32-specific header > > (gst/gstwin32.h or so) and make them vararg functions in the win32 case. > > However, the "vararg macro" patches were really unacceptable: I don't want > > GST_DEBUG_1(), GST_DEBUG_2() etc. That destroys the whole use of the > > vararg macros. You simply cannot disagree here. > > fancy This is not fancy, it's (consistency of using) a standard. It'd be fancy if we'd be using some extremely weird, non-standard way of coding that'd make things more difficult. C99 is not non-standard. GST_DEBUG_1(), GST_DEBUG_2() etc., *that* is fancy. > > And on the long run, MSVC has to support C99 and it's vararg macros. It's > > really just that simple. We're not going to change our plugin coding style > > because of a port to an inferior, standard-incompliant compiler. Even if > > it's Microsoft's. We are *not* part of their embrace, extend and > > exterminate way-of-life. > > political It'd be political if we did it because it's Microsoft. We do this because it's a standard, and we use standards to the extremes because the nature of our product requires that. Not using standards because that way we can solely support the Microsoft compiler and thereby serve a larger part of the world, *that* is political. Sorry, but fancy & political is a slight misunderstanding of our reasoning, imo. Again, we simply follow globally accepted and well-known standards, known as C99 and provided to you by the ISO. Microsoft (by nature, it seems) unfortunately doesn't. Ronald From steve.lhomme at free.fr Wed Apr 14 04:25:46 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Wed, 14 Apr 2004 04:25:46 +0200 Subject: [Matroska-devel] Status of WinStreamer (GStreamer Win32 port) In-Reply-To: <1081887528.24783.38.camel@shrek.bitfreak.net> References: <000c01c42175$f7c130a0$0200a8c0@jcsston> <1081887528.24783.38.camel@shrek.bitfreak.net> Message-ID: <407CA12A.3070606@free.fr> >>>And on the long run, MSVC has to support C99 and it's vararg macros. It's >>>really just that simple. We're not going to change our plugin coding style >>>because of a port to an inferior, standard-incompliant compiler. Even if >>>it's Microsoft's. We are *not* part of their embrace, extend and >>>exterminate way-of-life. >> >>political > > > It'd be political if we did it because it's Microsoft. We do this > because it's a standard, and we use standards to the extremes because > the nature of our product requires that. Not using standards because > that way we can solely support the Microsoft compiler and thereby serve > a larger part of the world, *that* is political. > > Sorry, but fancy & political is a slight misunderstanding of our > reasoning, imo. Again, we simply follow globally accepted and well-known > standards, known as C99 and provided to you by the ISO. Microsoft (by > nature, it seems) unfortunately doesn't. Supporting new standards will limit GStreamer to only a few platform, because lots of platform don't have C99 compilers available. And I don't see it changing soon. You made the choice of C99 knowing that some widely used compiler don't support it. If that's not a political choice, I don't know what it is... It would be so much easier to replace macros by functions, but you don't want to for this reason. And noone is willing to work with GCC/GDB under Windows, so... From R.S.Bultje at students.uu.nl Tue Apr 13 23:01:39 2004 From: R.S.Bultje at students.uu.nl (Ronald S. Bultje) Date: Tue, 13 Apr 2004 23:01:39 +0200 Subject: [Matroska-devel] Status of WinStreamer (GStreamer Win32 port) In-Reply-To: <407CA12A.3070606@free.fr> References: <000c01c42175$f7c130a0$0200a8c0@jcsston> <1081887528.24783.38.camel@shrek.bitfreak.net> <407CA12A.3070606@free.fr> Message-ID: <1081890098.24790.51.camel@shrek.bitfreak.net> On Wed, 2004-04-14 at 04:25, Steve Lhomme wrote: > Supporting new standards will limit GStreamer to only a few platform, > because lots of platform don't have C99 compilers available. And I don't > see it changing soon. You made the choice of C99 knowing that some > widely used compiler don't support it. If that's not a political choice, > I don't know what it is... We've made this decision knowing that our target platforms where the GNOME platforms (Linux and BSD). Interestingly, also other GNOME users (HP-UX, AIX) have C99 compliant compilers in their newest versions. Also, all KDE platforms seem to have C99-compliant compilers, since they're generally the same as the GNOME target platforms. So far, any platform that we've been tried to port to so far supports C99... ...just MSVC doesn't (and Windows is not yet a target platform). If that's what you call 'lots of platforms', then yes, we fail to support many of them. Win9x, Win98, Win98SE, WinME, Win95SE, Win95SE2.5, WinNT4, Win2k, WinXP, Win.NET, perhaps even WinLonghorn, we fail to support each of those... Not to mention Win3.11, Win3.1, Win3, Win2.any, Win1.any, all DOS versions and I'm sure there's loads of other MS OSes that we fail to support as well. ... just because of MSVC. But seriously, C99 isn't new at all by now. It was new when GStreamer was starting up, but that's back in the previous century. We're 5 years further now, everything supports C99 nowadays... ... except MSVC. > It would be so much easier to replace macros by functions, but you don't > want to for this reason. I've said (in a previous post) that an #ifdef around the vararg macros with vararg compatibility functions for windows *only* (as a temporary solution) is fine. It'll just be slower. Ronald From steve.lhomme at free.fr Wed Apr 14 05:35:31 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Wed, 14 Apr 2004 05:35:31 +0200 Subject: [Matroska-devel] Status of WinStreamer (GStreamer Win32 port) In-Reply-To: <1081890098.24790.51.camel@shrek.bitfreak.net> References: <000c01c42175$f7c130a0$0200a8c0@jcsston> <1081887528.24783.38.camel@shrek.bitfreak.net> <407CA12A.3070606@free.fr> <1081890098.24790.51.camel@shrek.bitfreak.net> Message-ID: <407CB183.1080502@free.fr> Ronald S. Bultje wrote: > But seriously, C99 isn't new at all by now. It was new when GStreamer > was starting up, but that's back in the previous century. We're 5 years > further now, everything supports C99 nowadays... > > ... except MSVC. And probably 90% of the embedded world that is a huge part of computing (and still growing faster). >>It would be so much easier to replace macros by functions, but you don't >>want to for this reason. > > > I've said (in a previous post) that an #ifdef around the vararg macros > with vararg compatibility functions for windows *only* (as a temporary > solution) is fine. It'll just be slower. inline functions + compiler optimisation should lead to the exact same result as using a macro. There's really no use for macro varargs. Especially nowadays that most coder consider macros ugly (and varargs too) because it is a major source of misuse. From R.S.Bultje at students.uu.nl Tue Apr 13 23:47:10 2004 From: R.S.Bultje at students.uu.nl (Ronald S. Bultje) Date: Tue, 13 Apr 2004 23:47:10 +0200 Subject: [Matroska-devel] Status of WinStreamer (GStreamer Win32 port) In-Reply-To: <407CB183.1080502@free.fr> References: <000c01c42175$f7c130a0$0200a8c0@jcsston> <1081887528.24783.38.camel@shrek.bitfreak.net> <407CA12A.3070606@free.fr> <1081890098.24790.51.camel@shrek.bitfreak.net> <407CB183.1080502@free.fr> Message-ID: <1081892829.24780.69.camel@shrek.bitfreak.net> On Wed, 2004-04-14 at 05:35, Steve Lhomme wrote: > inline functions + compiler optimisation should lead to the exact same > result as using a macro. There's really no use for macro varargs. > Especially nowadays that most coder consider macros ugly (and varargs > too) because it is a major source of misuse. Similar to the decision to use C99, there was a decision to not use inline functions. I don't know why - read the archives. If you wish, feel free to use inline functions in the win32 specific headers. And please define "major source of misuse" if you're making such a claim. Even /usr/src/linux/Documentation/SubmittingPatches doesn't use such strong terms, and even that is greatly exagerated. Ronald From steve.lhomme at free.fr Wed Apr 14 05:57:00 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Wed, 14 Apr 2004 05:57:00 +0200 Subject: [Matroska-devel] Status of WinStreamer (GStreamer Win32 port) In-Reply-To: <1081892829.24780.69.camel@shrek.bitfreak.net> References: <000c01c42175$f7c130a0$0200a8c0@jcsston> <1081887528.24783.38.camel@shrek.bitfreak.net> <407CA12A.3070606@free.fr> <1081890098.24790.51.camel@shrek.bitfreak.net> <407CB183.1080502@free.fr> <1081892829.24780.69.camel@shrek.bitfreak.net> Message-ID: <407CB68C.1010304@free.fr> Ronald S. Bultje wrote: > On Wed, 2004-04-14 at 05:35, Steve Lhomme wrote: > >>inline functions + compiler optimisation should lead to the exact same >>result as using a macro. There's really no use for macro varargs. >>Especially nowadays that most coder consider macros ugly (and varargs >>too) because it is a major source of misuse. > > > Similar to the decision to use C99, there was a decision to not use > inline functions. I don't know why - read the archives. If you wish, > feel free to use inline functions in the win32 specific headers. > > And please define "major source of misuse" if you're making such a > claim. Even /usr/src/linux/Documentation/SubmittingPatches doesn't use > such strong terms, and even that is greatly exagerated. int func(int val, void* pointer,...); #define MACRO(x,y,...) func(x,y,...) int a; float b; char c[10]; MACRO(a,&b,c); MACRO(a,&a,a,a,&a); MACRO(a,&c,a,b,c); How is the called function supposed to make the difference ? They are all legal calls but don't make any sense. It would be impossible with functions with fixed parameters... And if you really need this kind of MACRO there must be something wrong in your design. From jcsston at wiesneronline.net Wed Apr 14 07:38:05 2004 From: jcsston at wiesneronline.net (Jory) Date: Wed, 14 Apr 2004 00:38:05 -0500 Subject: [Matroska-devel] Status of WinStreamer (GStreamer Win32 port) References: <000c01c42175$f7c130a0$0200a8c0@jcsston><1081887528.24783.38.camel@shrek.bitfreak.net><407CA12A.3070606@free.fr><1081890098.24790.51.camel@shrek.bitfreak.net><407CB183.1080502@free.fr> <1081892829.24780.69.camel@shrek.bitfreak.net> Message-ID: <001501c421e2$b3b251b0$0200a8c0@jcsston> ----- Original Message ----- From: "Ronald S. Bultje" To: "Steve Lhomme" Cc: "Discussion about the current and future development of Matroska" Sent: Tuesday, April 13, 2004 4:47 PM Subject: Re: [Matroska-devel] Status of WinStreamer (GStreamer Win32 port) > On Wed, 2004-04-14 at 05:35, Steve Lhomme wrote: > > inline functions + compiler optimisation should lead to the exact same > > result as using a macro. There's really no use for macro varargs. > > Especially nowadays that most coder consider macros ugly (and varargs > > too) because it is a major source of misuse. > > Similar to the decision to use C99, there was a decision to not use > inline functions. I don't know why - read the archives. If you wish, > feel free to use inline functions in the win32 specific headers. > > And please define "major source of misuse" if you're making such a > claim. Even /usr/src/linux/Documentation/SubmittingPatches doesn't use > such strong terms, and even that is greatly exagerated. A major source of misuse (and the reason inline functions cannot be used for all vararg marcos) is the usage of vararg marcos to create new functions and structures for plugins. The other uses can be worked around, but this cannot. Jory From chris at matroska.org Wed Apr 14 14:22:05 2004 From: chris at matroska.org (Christian HJ Wiesner) Date: Wed, 14 Apr 2004 14:22:05 +0200 Subject: [Matroska-devel] Status of WinStreamer (GStreamer Win32 port) In-Reply-To: <1081892829.24780.69.camel@shrek.bitfreak.net> References: <000c01c42175$f7c130a0$0200a8c0@jcsston> <1081887528.24783.38.camel@shrek.bitfreak.net> <407CA12A.3070606@free.fr> <1081890098.24790.51.camel@shrek.bitfreak.net> <407CB183.1080502@free.fr> <1081892829.24780.69.camel@shrek.bitfreak.net> Message-ID: <407D2CED.2050108@matroska.org> Ronald S. Bultje wrote: >On Wed, 2004-04-14 at 05:35, Steve Lhomme wrote: > > >>inline functions + compiler optimisation should lead to the exact same >>result as using a macro. There's really no use for macro varargs. >>Especially nowadays that most coder consider macros ugly (and varargs >>too) because it is a major source of misuse. >> >> >And please define "major source of misuse" if you're making such a >claim. Even /usr/src/linux/Documentation/SubmittingPatches doesn't use >such strong terms, and even that is greatly exagerated. >Ronald > Guys, i hope you will keep the peace here, will you :-) ? I understand both sides in this matter. Sure, its a pitty that the Gstreamer team decided to use the C99 standard because MSVC doesnt support these ominous macro's coming with it, on the other hand, matroska is a new standard also, and if nobody uses new standards, how can they become established ? Its a bit like 7zip and ZIP, in principal we guys should offer all our software in 7zip packages, supporting this new, much improved compressor. But we dont, because using ZIP is so much easier for us :-( ...... Seen from the perspective of the Gstreamer team, what i would really worry about is the missing compilability on embedded devices, because there is certainly great use for an upcoming, opensource multimedia platform like gstreamer for this. Just think of a ?C Linux based DVD/MPEG4 player operating on Gstreamer :-) !! PANASONIC and SONY have already announced such devices, and they certainly do have the programming power to make those, and with a good firmware, but what about all the small players in the market, say KENWOOD or DENON ? For these companies, using an open platform like Gstreamer on their devices could be the perfect solution, their programmers could even help developing it further, without becoming dependant from the big players, but still without giving their 'competitive advantages' ( if they have any ) to the direct competitors. Call me crazy, but if you guys dont care about Windows, thats fine with me, but for the missing support in embedded devices, if i were you, i definitely *WOULD* care a lot and put the unsupported vararg macro's in the trash can ..... Christian From chris at matroska.org Wed Apr 14 14:58:13 2004 From: chris at matroska.org (Christian HJ Wiesner) Date: Wed, 14 Apr 2004 14:58:13 +0200 Subject: [Matroska-devel] Why porting Gstreamer to Windows would hurt Redmond ..... Message-ID: <407D3565.5060500@matroska.org> Hi, i am turning to the Gstreamer list again on this matter, sorry for that, but it seems we havent made any progress here since a couple of weeks now, so pls. be nice with me if you are not really interested in this, my apologies out front. There has been a lot of discussion between robux4, jcsston and BBB on the matroska-devel list ( http://news.gmane.org/gmane.comp.multimedia.matroska.devel ) recently about the sense in making Gstreamer dependant from C99 compliant compilers, or not. I am not a coder, but i understand from what they say that there are good ways to get rid of the ominous vararg macro's completely, making a native Windows port of it possible. From BBBs reaction i see that he doesnt feel like moving one jota off his position that its M$ who have to make MSVC C99 compliant to make this porting happen ( without forking that is ;-) ), but by no means he is inclined to give up the using of these vararg macro's for the Gstreamer project. Now, please allow me to list a couple of reasons why IMO you should consider doing that : - As stated on the matroska-devel list already, you guys should definitely have an eye on the compilability of Gstreamer for embedded devices based on ?C Linux, and i understand from robux4 that their compilers also have a hard time supporting vararg macro's, dont know if its true. Just think of a ?C Linux based DVD/MPEG4 player operating on Gstreamer !! PANASONIC and SONY have already announced such devices, and they certainly do have the programming power to make those, and with a good firmware, but what about all the small players in the market, say KENWOOD or DENON ? For these companies, using an open platform like Gstreamer on their devices could be the perfect solution, their programmers could even help developing it further, without becoming dependant from the big players, but still without giving their 'competitive advantages' ( if they have any ) to their direct competitors. - One of the main reasons for Redmond to *NOT* make MSVC C99 compliant, is maybe that they are hoping to bind developers to the Windows platform with that, and to make porting of software for various platforms other than Windows more difficult. After all, they know very well that most commercial software has to be released for Windows *also*, to ensure the software company sells enough copies to be able to survive. As a result of this, by supporting a compiler standard which is not supported by the main compiler for Windows, you in the end *HELP* Redmond to keep their monopoly status, because commercial software developers wanting to use Gstreamer as the framework for their apps, cant release it for Windows that way, so in the end they are *FORCED* to make it based on DirectShow for commercial reasons ( they need to eat, and buy food for that, thats for sure, and the average Linux user doesnt buy a lot of software i bet ;-) ), with the Linux world being left out ( again ) .... - With Quicktime never being well supported on Windows ( QT 6 Pro is payware even ) and with no Linux support, as a matter of fact, DirectShow is the deFacto standard for multimedia platforms these days, and most commercial video applications ( players, editors, capturing software, etc. ) are based on it. This is giving M$ the perfect basis to push WMV into the market, because they are the *ONLY* ones who know all the undocumented stuff in DShow allowing them to implement a real working DRM and other stuff. Again, if a working alternative multimedia platform for Windows would exist, and app developers had a choice other than using Directshow, and even with a chance to be able to easily launch their software for the Linux world also, dont you agree you would hurt their monopolistic activism a lot ? *Again : a working Windows port of Gstreamer could hurt Redmond's monopolistic multimedia status !!! No kidding, think about that when making your decision !* So, if anybody here has problems with a Windows port because he wants Gstreamer to be exclusively usable on Linux desktop's and hates Windows, well, IMO you should rethink your point of view here. What i understand from the matroska team is that using GCC is no option for porting gstreamer, for reasons i dont know and won't comment on. So please, have an internal meeting and make a decision on how we could come together. After all, we are still interested a lot in making this happen, but we wont maintain a parallel MSVC version of Gstreamer, with the need to rewrite every single plugin to make it compile. I very much hope you guys could move into our direction in this matter. Thanks for your interest Christian matroska project admin -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smile_n.gif Type: image/gif Size: 144 bytes Desc: not available URL: From rbultje at ronald.bitfreak.net Wed Apr 14 17:23:17 2004 From: rbultje at ronald.bitfreak.net (Ronald Bultje) Date: Wed, 14 Apr 2004 17:23:17 +0200 (CEST) Subject: [Matroska-devel] Status of WinStreamer (GStreamer Win32 port) In-Reply-To: <407CB68C.1010304@free.fr> Message-ID: Hi, On Wed, 14 Apr 2004, Steve Lhomme wrote: > Ronald S. Bultje wrote: > > On Wed, 2004-04-14 at 05:35, Steve Lhomme wrote: > >>inline functions + compiler optimisation should lead to the exact same > >>result as using a macro. There's really no use for macro varargs. > >>Especially nowadays that most coder consider macros ugly (and varargs > >>too) because it is a major source of misuse. > > > > Similar to the decision to use C99, there was a decision to not use > > inline functions. I don't know why - read the archives. If you wish, > > feel free to use inline functions in the win32 specific headers. > > > > And please define "major source of misuse" if you're making such a > > claim. Even /usr/src/linux/Documentation/SubmittingPatches doesn't use > > such strong terms, and even that is greatly exagerated. > > int func(int val, void* pointer,...); > > #define MACRO(x,y,...) func(x,y,...) > > int a; > float b; > char c[10]; > > MACRO(a,&b,c); > MACRO(a,&a,a,a,&a); > MACRO(a,&c,a,b,c); > > How is the called function supposed to make the difference ? They are > all legal calls but don't make any sense. It would be impossible with > functions with fixed parameters... And if you really need this kind of > MACRO there must be something wrong in your design. Your func() is wrong. Every vararg macro that we use (inside GStreamer) eventually refers to a G_GNUC_PRINTF(x,y) terminated vararg function, so the function actually typechecks the varargs. Therefore, indirectly, the macro is being typechecked as well and thus the above wouldn't be possible. Ronald From rbultje at ronald.bitfreak.net Wed Apr 14 17:26:49 2004 From: rbultje at ronald.bitfreak.net (Ronald Bultje) Date: Wed, 14 Apr 2004 17:26:49 +0200 (CEST) Subject: [Matroska-devel] Status of WinStreamer (GStreamer Win32 port) In-Reply-To: <407D2CED.2050108@matroska.org> Message-ID: Hi, On Wed, 14 Apr 2004, Christian HJ Wiesner wrote: > Seen from the perspective of the Gstreamer team, what i would really > worry about is the missing compilability on embedded devices, because > there is certainly great use for an upcoming, opensource multimedia > platform like gstreamer for this. Just think of a ?C Linux based > DVD/MPEG4 player operating on Gstreamer :-) !! I'm affraid all microLinux embedded stuff uses gcc. Alternative (non-C99) compilers are really only used inside exotic devices. Those are usually so incompatible that it's hard to believe that they *could* use GStreamer... And again, with vararg functions, you could make a first port: #ifdef __MSVC__ #define GST_DEBUG __gst_debug static inline void __gst_debug (gchar fmt, ...) { .. } #endif /* __MSVC__ */ And now just go for it! Moaning about decisions made in the past isn't particularly useful. Ronald From rbultje at ronald.bitfreak.net Wed Apr 14 17:35:09 2004 From: rbultje at ronald.bitfreak.net (Ronald Bultje) Date: Wed, 14 Apr 2004 17:35:09 +0200 (CEST) Subject: [Matroska-devel] Status of WinStreamer (GStreamer Win32 port) In-Reply-To: <001501c421e2$b3b251b0$0200a8c0@jcsston> Message-ID: Hi, On Wed, 14 Apr 2004, Jory wrote: > A major source of misuse (and the reason inline functions cannot be used for > all vararg marcos) is the usage of vararg marcos to create new functions and > structures for plugins. The other uses can be worked around, but this > cannot. That's not a bug, that's a feature. ;). Anyway, for the particular case, I think Dave also removed several of those, so feel free to supply us with patches to remove those macros alltogether. We will not remove the API from the headers (sorry, 0.8.x freeze), but we can remove all instances. Ronald From steve.lhomme at free.fr Wed Apr 14 22:49:40 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Wed, 14 Apr 2004 22:49:40 +0200 Subject: [Matroska-devel] Status of WinStreamer (GStreamer Win32 port) In-Reply-To: References: Message-ID: <407DA3E4.3050209@free.fr> Ronald Bultje wrote: > Your func() is wrong. Every vararg macro that we use (inside GStreamer) > eventually refers to a G_GNUC_PRINTF(x,y) terminated vararg function, so > the function actually typechecks the varargs. Therefore, indirectly, the > macro is being typechecked as well and thus the above wouldn't be > possible. Which doesn't prove varargs and macros are evil and should be avoided as much as possible. Any coder knows that (how do you debug a macro ?). And I *really* don't understand how the intelligent programmers of GStreamer came to this silly decision. But yes, that's discussing about errors of the past. Apparently it's too late to change... From steve.lhomme at free.fr Wed Apr 14 23:35:55 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Wed, 14 Apr 2004 23:35:55 +0200 Subject: [Matroska-devel] Why porting Gstreamer to Windows would hurt Redmond ..... In-Reply-To: <407D3565.5060500@matroska.org> References: <407D3565.5060500@matroska.org> Message-ID: <407DAEBB.7060104@free.fr> Christian HJ Wiesner wrote: > So, if anybody here has problems with a Windows port because he wants > Gstreamer to be exclusively usable on Linux desktop's and hates Windows, > well, IMO you should rethink your point of view here. > > What i understand from the matroska team is that using GCC is no option > for porting gstreamer, for reasons i dont know and won't comment on. So > please, have an internal meeting and make a decision on how we could > come together. After all, we are still interested a lot in making this > happen, but we wont maintain a parallel MSVC version of Gstreamer, with > the need to rewrite every single plugin to make it compile. I very much > hope you guys could move into our direction in this matter. Ronald proposed a solution that would work nicely with MSVC... Why not use for all systems ? Because some plugins should be rewritten. But wouldn't these plugins would need to be rewritten for Windows ? Yes. So in the end these plugins would run under Windows and Linux. But you don't want this solution, don't you ? It seems apparent that for GStreamer to be usable under Windows (in a way that all Windows programmers use) we need some changes. But you don't want them. So it might be very possible that we make a fork of GStreamer that would be nice with Windows coders. And that version (CoreStreamer) would *also* run under Linux and all other platforms you support. So any coder willing to work on GStreamer will have the choice between the original GStreamer and CoreStreamer. But one does the same, and more. What do you think will happen ? From rbultje at ronald.bitfreak.net Wed Apr 14 23:50:35 2004 From: rbultje at ronald.bitfreak.net (Ronald Bultje) Date: Wed, 14 Apr 2004 23:50:35 +0200 (CEST) Subject: [Matroska-devel] Why porting Gstreamer to Windows would hurt Redmond ..... In-Reply-To: <407DAEBB.7060104@free.fr> Message-ID: Hi, On Wed, 14 Apr 2004, Steve Lhomme wrote: > Ronald proposed a solution that would work nicely with MSVC... Why not > use for all systems ? Because some plugins should be rewritten. They don't have to, we'll accept patches for those. We're not *that* bad. ;). Ronald From rbultje at ronald.bitfreak.net Wed Apr 14 23:51:39 2004 From: rbultje at ronald.bitfreak.net (Ronald Bultje) Date: Wed, 14 Apr 2004 23:51:39 +0200 (CEST) Subject: [Matroska-devel] Status of WinStreamer (GStreamer Win32 port) In-Reply-To: <407DA3E4.3050209@free.fr> Message-ID: Hi, On Wed, 14 Apr 2004, Steve Lhomme wrote: > Apparently it's too late to change... You could roll a dice on gstreamer-devel if you really want to. Maybe you get enough support to actually make us drop the debugging macros after 0.8.x. Ronald From steve.lhomme at free.fr Thu Apr 15 01:30:00 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Thu, 15 Apr 2004 01:30:00 +0200 Subject: [Matroska-devel] Matroska library now LGPL Message-ID: <407DC978.8070008@free.fr> As the titles says, I've now switched all the code of libebml and libmatroska to the LGPL license only. That means no more GPL and QPL dual license. That means everyone is now free to use them in open and closed projects as long as they make available their modifications to the person who receives a compiled version. From jcsston at wiesneronline.net Thu Apr 15 01:35:29 2004 From: jcsston at wiesneronline.net (Jory) Date: Wed, 14 Apr 2004 18:35:29 -0500 Subject: [Matroska-devel] Status of WinStreamer (GStreamer Win32 port) References: Message-ID: <000e01c42279$3bb102a0$0200a8c0@jcsston> ----- Original Message ----- From: "Ronald Bultje" To: "Steve Lhomme" Cc: "Discussion about the current and future development of Matroska" Sent: Wednesday, April 14, 2004 4:51 PM Subject: Re: [Matroska-devel] Status of WinStreamer (GStreamer Win32 port) > Hi, > > On Wed, 14 Apr 2004, Steve Lhomme wrote: > > Apparently it's too late to change... > > You could roll a dice on gstreamer-devel if you really want to. Maybe you > get enough support to actually make us drop the debugging macros after > 0.8.x. ... Debugging marcos are no problem. Jory From chris at matroska.org Thu Apr 15 14:11:55 2004 From: chris at matroska.org (Christian HJ Wiesner) Date: Thu, 15 Apr 2004 14:11:55 +0200 Subject: [Matroska-devel] h.264 / AVC in matroska Message-ID: <407E7C0B.7060805@matroska.org> http://www.hydrogenaudio.org/index.php?showtopic=20746& There is an encoder up now which will export the raw h.264 packets ...... something to look at for Mosu :) ? I guess if we are digging deep enough, we should be able to find all the discussion we had about how to best put h.264 into MKV, with NALUs for low bandwidth streaming ( drop packets with lower NALU priority ) and the like ? I guess this was on the corecodec.com forums even, no ? Christian From spyder at matroska.org Thu Apr 15 18:02:18 2004 From: spyder at matroska.org (John Cannon) Date: Thu, 15 Apr 2004 11:02:18 -0500 Subject: [Matroska-devel] h.264 / AVC in matroska In-Reply-To: <407E7C0B.7060805@matroska.org> References: <407E7C0B.7060805@matroska.org> Message-ID: <407EB20A.8050409@matroska.org> Christian HJ Wiesner wrote: > http://www.hydrogenaudio.org/index.php?showtopic=20746& > > There is an encoder up now which will export the raw h.264 packets > ...... something to look at for Mosu :) ? I guess if we are digging > deep enough, we should be able to find all the discussion we had about > how to best put h.264 into MKV, with NALUs for low bandwidth streaming > ( drop packets with lower NALU priority ) and the like ? I guess this > was on the corecodec.com forums even, no ? > > Christian > > _______________________________________________ > Matroska-devel mailing list > Matroska-devel at lists.matroska.org > http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel > Well, there were already encoders that made raw streams. x264 can even be used to encode and hand out single frames. I'm not sure that there's a whole lot to storing h264 in mkv. But I don't remember the stuff we discussed either. Just don't get too excited, h264 still isn't very useful at the moment. Most decoders or encoders crash or don't work right. Soon though :) John PS: I'm taking the next 1-2 weeks off...I'll pop in now and then but I will be really busy. Thank god there are only 3 weeks of school left :) From thomas at apestaart.org Fri Apr 16 11:58:49 2004 From: thomas at apestaart.org (Thomas Vander Stichele) Date: Fri, 16 Apr 2004 11:58:49 +0200 Subject: [gst-devel] Re: [Matroska-devel] Why porting Gstreamer to Windows would hurt Redmond ..... In-Reply-To: <407DAEBB.7060104@free.fr> References: <407D3565.5060500@matroska.org> <407DAEBB.7060104@free.fr> Message-ID: <1082109528.4971.30.camel@otto.amantes> Hi, I think there isn't a real problem at all and it has just been blown out of proportion a little due to a lack of good communication. I'll summarize in a nutshell what, IMO, went wrong, and then I'll try to explain by replying to parts... a) The actual implementation discussion was held on the matroska mailing list when it should have been held on the GStreamer mailing list. If the technical problem is about GStreamer code that needs changing to run on Windows, it should be discussed on the GStreamer mailing list. To me that seems clear. b) When discussing the actual implementation, "the Matroska team" should regard Ronald's opinions as his own, and not as the GStreamer team's. To me that seems fairly clear as well - if Ronald says he doesn't care about Windows, that doesn't mean GStreamer doesn't care about it. Likewise, if Ronald says "a patch will be refused" it doesn't necessarily mean the GStreamer team will refuse it. Again, it should have been discussed on the GStreamer mailing list. c) There is a huge difference between "not accepting a patch" (for whatever reason), "refusing the patch", and "refusing the possibility of patching a certain piece of code". What Ronald did was say "the patch done like this cannot go in". That means you can rework the patch to address his concerns. d) Announcing a fork is not a good way to address communication breakdowns. It makes both teams look very silly and immature :) > > So, if anybody here has problems with a Windows port because he wants > > Gstreamer to be exclusively usable on Linux desktop's and hates Windows, > > well, IMO you should rethink your point of view here. I am pretty sure there aren't many on our team that feel that way. What is true is that some of our developers just don't care about Window, period. That is, mind you, quite a different point of view than hating Windows and wanting GStreamer to be exclusively usable on Linux. AFAICT, Ronald is one of these people, as he's stated repeatedly on IRC, and it is his right to do so, and from his POV I can understand. But that doesn't mean everyone on our team feels the same way. To be clear, personally I think it would be incredible if GStreamer worked on Windows; I'm just not in a good position to help a lot beyond what we can do on our side to integrate code, since I haven't really used Windows for 4 years. > > What i understand from the matroska team is that using GCC is no option > > for porting gstreamer, for reasons i dont know and won't comment on. So > > please, have an internal meeting and make a decision on how we could > > come together. After all, we are still interested a lot in making this > > happen, but we wont maintain a parallel MSVC version of Gstreamer, with > > the need to rewrite every single plugin to make it compile. I very much > > hope you guys could move into our direction in this matter. As far as I know, the ONLY problem there was was the use of variadic macros for the debugging system. If there is something else then please speak up now. Now, on that matter, the patch that got proposed by you was one where you would create, for each GST_DEBUG type macro, a bunch of GST_DEBUG_x macros where x is the number of arguments. I think you can see why this is an ugly hack, and I think you can also see why this would mean we need to rewrite EVERY piece of code that uses the debug system. Ronald proposed to use inline functions as a solution and asked to rewrite the patch that way, but he says you didn't do so. Getting a problem addressed is a matter of communicating and discussing possible implementations between two people. It's up to the person trying to get a patch in to address concerns of the person who is looking at the patches. In this case, it wasn't too hard I think to submit a patch doing just this. In fact, David (from our team) did just that last evening, from the looks of CVS. > Ronald proposed a solution that would work nicely with MSVC... Why not > use for all systems ? Because it's not necessary. We are trying to get GStreamer building on Windows as well, with your help. We now did so by using inline functions on systems that do not implement variadic macros. So now it shouldn't pose a problem anymore on Windows. > Because some plugins should be rewritten. But > wouldn't these plugins would need to be rewritten for Windows ? I'm not sure what you mean. AFAIK none of the plugins need to be rewritten now, and the solution is implemented at the right level: systems not supporting variadic macros now use inline functions with the exact same name and format. (Note to Microsoft: how about implementing variadic macros as inline functions at the compiler level ?) > Yes. So > in the end these plugins would run under Windows and Linux. But you > don't want this solution, don't you ? Maybe I didn't understand what you are saying correctly. So I'll just say what I think: I very much want a solution where most of the plugins are completely the same under Linux and Windows. The only plugins that should be different are plugins that interface directly with the system; which would be input and output plugins. > It seems apparent that for GStreamer to be usable under Windows (in a > way that all Windows programmers use) we need some changes. But you > don't want them. Of course it needs changes, and nobody is against having changes. All we want is for the changes to be correct. Also, again realize that you said "you don't want them" when the correct sentence is "Ronald didn't accept our GST_DEBUG_x patches the first time we submitted them." You really shouldn't generalize on three levels at once (Ronald != gstreamer team, accept != refuse, ugly solution != correct solution). It's an antagonistic statement that doesn't help us getting closer together :) > So it might be very possible that we make a fork of > GStreamer that would be nice with Windows coders. And that version > (CoreStreamer) would *also* run under Linux and all other platforms you > support. So any coder willing to work on GStreamer will have the choice > between the original GStreamer and CoreStreamer. But one does the same, > and more. What do you think will happen ? I think people will laugh at both of us for making such a huge issue out of a simple technical problem which is "finding a way to work around variadic macros not being present on MSVC". I mean, really. A fork for some basic issue that could have been solved by the two teams talking to each other ? Let's just promise to talk some more to each other, and please have these discussions on the GStreamer mailing list instead of somehwere else. At least that way everyone besides Ronald knows what's going on, and you guys also know what we think. It's a lot better than assuming things we haven't said are true. Let's work together to make GStreamer better on both Linux and Windows. I have no doubt in my mind that you guys are capable coders and that the work we can do together will benefit us both. So let's make a bit more effort to talk to each other, as teams, and not only as individuals. And on that note - could you please let us know what else is causing problems on Windows now that the debugging problem has been resolved correctly (to the best of my knowledge, since I cannot test on Windows) ? Thomas Dave/Dina : future TV today ! - http://www.davedina.org/ <-*- thomas (dot) apestaart (dot) org -*-> The girl that I could never hurt had to go and lose all that power over me and I claimed victory <-*- thomas (at) apestaart (dot) org -*-> URGent, best radio on the net - 24/7 ! - http://urgent.fm/ From chris at matroska.org Fri Apr 16 12:01:20 2004 From: chris at matroska.org (Christian HJ Wiesner) Date: Fri, 16 Apr 2004 12:01:20 +0200 Subject: [Matroska-devel] Stripped down frame referencing system for native MPEG 1/2/4 in MKV ? Message-ID: <407FAEF0.1030907@matroska.org> Hi, the question was arised today on IRC, and it seems there had been discussion before about this subject. Using our current frame referencing system, which is admittedly very powerful and especially directed to future codecs that will allow more frame operations, we will add significant overhead when muxing MPEG4 natively into MKV ( i guess same is valid for MPEG1/2 ). Should we seriously consider alexnoe's idea to add a simple flag based system to mark/reference frames, maybe even inspired by the system that NUT uses ? I dont think our native files will get very much accepted by people if it adds significant overhead compared to the 'hackish' AVI solutions, especially 'packed bitstream' as introduced by DivX5. For the time being, every b-frame will need 2 bytes more than an I/P frame with our current system, and stripping a 'dummy frame' will save 6 bytes. So, as Mosu was pointing out on IRC today, we could save overhead for DivX5 files as they support only packed bitstream with dummy frames, and also only one consecutive b-frame in a row, actually we will save 4 bytes per b-frame. But for Xvid, it can have any number of b-frames, although in reality i found out it hardly ever uses more than 3, even if you allow it to use 10 as maximum. However, as it doesnt use packed bitstream by default, there are no dummy frames to strip, so we will add significant overhead with our current system, which i find quite unacceptable because most of our fans are certainly using XviD, and not DivX5. Would it be difficult to add a frame flagging system like proposed by alexnoe and Mosu ? Christian From chris at matroska.org Fri Apr 16 12:56:34 2004 From: chris at matroska.org (Christian HJ Wiesner) Date: Fri, 16 Apr 2004 12:56:34 +0200 Subject: [gst-devel] Re: [Matroska-devel] Why porting Gstreamer to Windows would hurt Redmond ..... In-Reply-To: <1082109528.4971.30.camel@otto.amantes> References: <407D3565.5060500@matroska.org> <407DAEBB.7060104@free.fr> <1082109528.4971.30.camel@otto.amantes> Message-ID: <407FBBE2.6060107@matroska.org> Hi Thomas ! Its an honour to have you posting to our list, hope this wont be the last time. Thomas Vander Stichele wrote: >Hi, >I think there isn't a real problem at all and it has just been blown out >of proportion a little due to a lack of good communication. I'll >summarize in a nutshell what, IMO, went wrong, and then I'll try to >explain by replying to parts... > >a) The actual implementation discussion was held on the matroska mailing >list when it should have been held on the GStreamer mailing list. If >the technical problem is about GStreamer code that needs changing to run >on Windows, it should be discussed on the GStreamer mailing list. To me >that seems clear. > > Yes, i agree with that. But as always, people are subscribed to too many lists already and therefore our devs were lazy and using the matroska-devel list for discussion, although i agree its actually not the right place. But it was convenient as BBB is subscribed there, and also you have to understand that currently not all team members of the matroska team are 100% enthusiastic about trying to create the next generation matroska tools ( incl. video editors ) based on Gstreamer. As a result, if we had been doing the discussion on your list, some matroska team members would have missed it all completely. I am pretty sure we will find a way here, maybe by having a new, low traffic list together with you ( on your host or ours, that doesnt matter ) to care specifically about the Gstreamer porting to Windows and the matroska tools based on it, we'll see. For the time being i highly appreciate if you could copy matroska-devel, like you did in this email. >b) When discussing the actual implementation, "the Matroska team" should >regard Ronald's opinions as his own, and not as the GStreamer team's. >To me that seems fairly clear as well - if Ronald says he doesn't care >about Windows, that doesn't mean GStreamer doesn't care about it. >Likewise, if Ronald says "a patch will be refused" it doesn't >necessarily mean the GStreamer team will refuse it. Again, it should >have been discussed on the GStreamer mailing list. > > BBB is our friend, and we fully trust him on this, as we do now. Of course, we should have known he is a real Linux hardliner and take his comments with some grains of salt maybe ;-) ..... >c) There is a huge difference between "not accepting a patch" (for >whatever reason), "refusing the patch", and "refusing the possibility of >patching a certain piece of code". What Ronald did was say "the patch >done like this cannot go in". That means you can rework the patch to >address his concerns. > > ACK >d) Announcing a fork is not a good way to address communication >breakdowns. It makes both teams look very silly and immature :) > > I apologize for that, but you have to admit, with announcing the fork i finally achieved what i wanted ..... a clear statement from one of the Gstreamer lead developers about this subject ;-) . Believe me, if i had favoured to fork from gstreamer, i wouldnt have told you about it on IRC first ..... look at my announcement as a kind of wake up call on #gstreamer :-D ! >>>So, if anybody here has problems with a Windows port because he wants >>>Gstreamer to be exclusively usable on Linux desktop's and hates Windows, >>>well, IMO you should rethink your point of view here. >>> >>> >I am pretty sure there aren't many on our team that feel that way. What >is true is that some of our developers just don't care about Window, >period. That is, mind you, quite a different point of view than hating >Windows and wanting GStreamer to be exclusively usable on Linux. >AFAICT, Ronald is one of these people, as he's stated repeatedly on IRC, >and it is his right to do so, and from his POV I can understand. But >that doesn't mean everyone on our team feels the same way. >To be clear, personally I think it would be incredible if GStreamer >worked on Windows; I'm just not in a good position to help a lot beyond >what we can do on our side to integrate code, since I haven't really >used Windows for 4 years. > > Dont worry, the matroska team currently consists of more Windows coders than Linux coders ( only Haali and Mosu ), and i guess we have proved already that we are capable to make nice and stable Windows implementations of our stuff. As long as we get the support from your side to be able to do what is necessary to make this a succesful port, we wont run into problems IMO. >>>What i understand from the matroska team is that using GCC is no option >>>for porting gstreamer, for reasons i dont know and won't comment on. So >>>please, have an internal meeting and make a decision on how we could >>>come together. After all, we are still interested a lot in making this >>>happen, but we wont maintain a parallel MSVC version of Gstreamer, with >>>the need to rewrite every single plugin to make it compile. I very much >>>hope you guys could move into our direction in this matter. >>> >>> >As far as I know, the ONLY problem there was was the use of variadic >macros for the debugging system. If there is something else then please >speak up now. >Now, on that matter, the patch that got proposed by you was one where >you would create, for each GST_DEBUG type macro, a bunch of GST_DEBUG_x >macros where x is the number of arguments. I think you can see why this >is an ugly hack, and I think you can also see why this would mean we >need to rewrite EVERY piece of code that uses the debug system. Ronald >proposed to use inline functions as a solution and asked to rewrite the >patch that way, but he says you didn't do so. Getting a problem >addressed is a matter of communicating and discussing possible >implementations between two people. It's up to the person trying to get >a patch in to address concerns of the person who is looking at the >patches. In this case, it wasn't too hard I think to submit a patch >doing just this. In fact, David (from our team) did just that last >evening, from the looks of CVS. > Jory got the latest 0.8.1 sources from your server yesterday, and was very delighted to see that most of the vararg macros seem to have disappeared :-) ! >>in the end these plugins would run under Windows and Linux. But you >>don't want this solution, don't you ? >> >> > >Maybe I didn't understand what you are saying correctly. So I'll just >say what I think: I very much want a solution where most of the plugins >are completely the same under Linux and Windows. The only plugins that >should be different are plugins that interface directly with the system; >which would be input and output plugins. > > ACK. DirectX should be used for the output sinks IMO. As for the inputs, the matroska devs should comment on that. >I mean, really. A fork for some basic issue that could have been solved by the two teams talking to >each other ? >Let's just promise to talk some more to each other, and please have >these discussions on the GStreamer mailing list instead of somehwere >else. At least that way everyone besides Ronald knows what's going on, >and you guys also know what we think. It's a lot better than assuming >things we haven't said are true. Let's work together to make GStreamer >better on both Linux and Windows. >I have no doubt in my mind that you guys are capable coders and that the >work we can do together will benefit us both. So let's make a bit more >effort to talk to each other, as teams, and not only as individuals. >And on that note - could you please let us know what else is causing >problems on Windows now that the debugging problem has been resolved >correctly (to the best of my knowledge, since I cannot test on Windows) >Thomas > > Thomas, looking forward to get this moving with you guys !! I am just an organizer, and with limited time because of job and family, but rest assured i will try to help best i can ! Christian matroska project admin From moritz at bunkus.org Fri Apr 16 13:44:58 2004 From: moritz at bunkus.org (Moritz Bunkus) Date: Fri, 16 Apr 2004 13:44:58 +0200 Subject: [Matroska-devel] Stripped down frame referencing system for native MPEG 1/2/4 in MKV ? In-Reply-To: <407FAEF0.1030907@matroska.org> References: <407FAEF0.1030907@matroska.org> Message-ID: <20040416114457.GE8131@bunkus.org> Hi, While the current system is definitely a powerful one it is also one with a lot of overhead which we simply don't need for current codecs. Using flags will immediately save space. Example: The Finding Nemo.mkv has 239099 P frames resulting in 478198 bytes 'wasted'. For B frames: the files I have so far with packed bitstream have 8 bytes (DivX) and 6 bytes (XviD) dummy frames. If we change this we might also change the block timecode to be an ebml sint (like we've talked about before). This might increase the overhead a tiny bit, but I strongly doubt it, and it'd add a lot more flexibility for clusters and their timecodes. These changes are just like the changes in the lacing scheme - very disruptive and not backwards compatible (so older parsers will have problems with newer files). So if we do that we should first make the most prominent parsers aware of these changes, release these parsers/commit code to mplayer/gstreamer/whatever, wait a month, and then release the tools that can write such files. 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 suiryc at yahoo.com Fri Apr 16 14:46:14 2004 From: suiryc at yahoo.com (Cyrius) Date: Fri, 16 Apr 2004 05:46:14 -0700 (PDT) Subject: [Matroska-devel] Stripped down frame referencing system for native MPEG 1/2/4 in MKV ? In-Reply-To: <20040416114457.GE8131@bunkus.org> Message-ID: <20040416124614.46767.qmail@web12906.mail.yahoo.com> Hi, --- Moritz Bunkus wrote: > Hi, > > While the current system is definitely a powerful one it is also one > with a lot of overhead which we simply don't need for current > codecs. Using flags will immediately save space. Example: The Finding > Nemo.mkv has 239099 P frames resulting in 478198 bytes 'wasted'. For > B > frames: the files I have so far with packed bitstream have 8 bytes > (DivX) and 6 bytes (XviD) dummy frames. > > If we change this we might also change the block timecode to be an > ebml > sint (like we've talked about before). This might increase the > overhead > a tiny bit, but I strongly doubt it, and it'd add a lot more > flexibility > for clusters and their timecodes. Yup, if we make such changes, better make all of them at once :) For most of the tools using ebml sint timecodes won't increase the overhead (not right now at least). With the current design we can store data which relative timecode is up to ~+/-36s. With 2 bytes the ebml sint value could store values up to ~+/-8s. But most of the tools only store a few seconds of data in clusters and don't reach this 8s limit. Now the question is what would this flag system look like ? Would some reserved flags in the Block header be used ? Would something be hardcoded in the block header (just like the current sint16 relative timecode is stored) ? Or would there be a new child element ? (considering the smallest element possible, it would consume 3 bytes per frame) > These changes are just like the changes in the lacing scheme - very > disruptive and not backwards compatible (so older parsers will have > problems with newer files). So if we do that we should first make the > most prominent parsers aware of these changes, release these > parsers/commit code to mplayer/gstreamer/whatever, wait a month, and > then release the tools that can write such files. > > Mosu Good idea too. Saves the time of adding a new kind of Block :p __________________________________ Do you Yahoo!? Yahoo! Tax Center - File online by April 15th http://taxes.yahoo.com/filing.html From in7y118 at public.uni-hamburg.de Fri Apr 16 16:16:24 2004 From: in7y118 at public.uni-hamburg.de (Benjamin Otte) Date: Fri, 16 Apr 2004 16:16:24 +0200 Subject: [gst-devel] Re: [Matroska-devel] Why porting Gstreamer to Windows would hurt Redmond ..... In-Reply-To: <1082109528.4971.30.camel@otto.amantes> References: <407D3565.5060500@matroska.org> <407DAEBB.7060104@free.fr> <1082109528.4971.30.camel@otto.amantes> Message-ID: <1082124984.407feab86aa16@rzaixsrv6.rrz.uni-hamburg.de> Quoting Thomas Vander Stichele : > And on that note - could you please let us know what else is causing > problems on Windows now that the debugging problem has been resolved > correctly (to the best of my knowledge, since I cannot test on Windows) > ? > According to David, Windows doesn't allow DLLs with undefined symbols. This means that our current linking mechanism (not linking to the core lib and loading dependencies via gst_plugin_load) just doesn't work in Windows. AFAICS, the only way to solve that would be a redesign of the plugin linking, loading and initialization mechanism that would most likely not be implementable with API compat without major headaches. Benjamin From alex at fsn.hu Thu Apr 15 18:14:36 2004 From: alex at fsn.hu (Alex Beregszaszi) Date: Thu, 15 Apr 2004 18:14:36 +0200 Subject: [Matroska-devel] LinuxTAG 2004: Linux Video Booth Message-ID: <20040415181436.33aad350@caprice.artificis.hu> Hi, Diego Biurrun and myself from MPlayer are thinking about organizing this year a big common booth among video related open source projects. The biggest projects should come and cooperate: FFmpeg, MPlayer, xine, VideoLAN, Matroska and maybe others I forgot.. I've just asked the Linuxtag organizers about having such a booth, but at least the xine team knows the way to do it as they had a booth last year. What do you think about the idea? -- Alex Beregszaszi e-mail: alex at fsn.hu Free Software Network cell: +36 70 3144424 From paul at msn.com Fri Apr 16 18:31:53 2004 From: paul at msn.com (Paul Bryson) Date: Fri, 16 Apr 2004 11:31:53 -0500 Subject: [Matroska-devel] Re: Stripped down frame referencing system for native MPEG 1/2/4 in MKV ? References: <407FAEF0.1030907@matroska.org> Message-ID: "Christian HJ Wiesner" wrote... > Should we seriously consider alexnoe's idea to add a simple flag based > system to mark/reference frames, maybe even inspired by the system that > NUT uses ? The system that NUT now uses is exactly what I suggested a few months ago. In fact, the Block2 design is very similar to one of their new packet designs in that is uses a VLC flag area for the Block2 header. Pamel From paul at msn.com Fri Apr 16 18:50:37 2004 From: paul at msn.com (Paul Bryson) Date: Fri, 16 Apr 2004 11:50:37 -0500 Subject: [Matroska-devel] Re: Stripped down frame referencing system fornative MPEG 1/2/4 in MKV ? References: <20040416114457.GE8131@bunkus.org> <20040416124614.46767.qmail@web12906.mail.yahoo.com> Message-ID: "Cyrius" wrote... > --- Moritz Bunkus wrote: > > While the current system is definitely a powerful one it is also one > > with a lot of overhead which we simply don't need for current > > codecs. Using flags will immediately save space. Example: The Finding > > Nemo.mkv has 239099 P frames resulting in 478198 bytes 'wasted'. For > > B > > frames: the files I have so far with packed bitstream have 8 bytes > > (DivX) and 6 bytes (XviD) dummy frames. Yes. That is a "not insignificant" amount of space to many people. I know Steve has some resistance to this because you don't want people to get used to using a simple referencing system and ignore the good one when it is needed. But by now, it shouldn't be a problem. Anyone that makes a new parser would need to be able to read the old references or nobody would be able to play any of the files out there. New muxers might be an issue though. > > If we change this we might also change the block timecode to be an > > ebml > > sint (like we've talked about before). This might increase the > > overhead > > a tiny bit, but I strongly doubt it, and it'd add a lot more > > flexibility > > for clusters and their timecodes. > > Yup, if we make such changes, better make all of them at once :) > For most of the tools using ebml sint timecodes won't increase the > overhead (not right now at least). With the current design we can store > data which relative timecode is up to ~+/-36s. With 2 bytes the ebml > sint value could store values up to ~+/-8s. But most of the tools only > store a few seconds of data in clusters and don't reach this 8s limit. I ran some numbers on this a few months ago and it does significantly increase the overhead of the file if you are making sample accurate seeking for audio. Maximum cluster range for sample accurate seeking in 44.1kHz CD audio, 1.49 seconds. Maximum cluster range for sample accurate seeking in 192kHz DVD audio, 0.34 seconds. If you used a SINT EBML timecode for these, then you would have only about 3 Blocks with a 2 byte timecode per Cluster in 192kHz, any more would be 3 bytes for a timecode. > Now the question is what would this flag system look like ? > Would some reserved flags in the Block header be used ? > Would something be hardcoded in the block header (just like the current > sint16 relative timecode is stored) ? > Or would there be a new child element ? (considering the smallest > element possible, it would consume 3 bytes per frame) Please look at the suggestion that I made for a Block2. http://thread.gmane.org/gmane.comp.multimedia.matroska.devel/1578 For some reason I don't actually say it, but the flags part of the header is supposed to be an EBML structure so that you can make it any length you want. All flags default to zero so that you don't need to actually make the flags area more than a byte long if they are using the flags default value. > > These changes are just like the changes in the lacing scheme - very > > disruptive and not backwards compatible (so older parsers will have > > problems with newer files). So if we do that we should first make the > > most prominent parsers aware of these changes, release these > > parsers/commit code to mplayer/gstreamer/whatever, wait a month, and > > then release the tools that can write such files. > > > > Mosu > > Good idea too. Saves the time of adding a new kind of Block :p What possible reason could you have for not making a new Block EBML ID? Its the whole point of EBML. If the Block design is incompatible with the old one, then you make a new EBML ID. Old parsers will simply skip over them then and you won't have the playback issues that were there with the lacing. Either it will play, or it won't. At least it won't crash/stutter. Pamel From suiryc at yahoo.com Fri Apr 16 19:06:07 2004 From: suiryc at yahoo.com (Cyrius) Date: Fri, 16 Apr 2004 10:06:07 -0700 (PDT) Subject: [Matroska-devel] Re: Stripped down frame referencing system fornative MPEG 1/2/4 in MKV ? In-Reply-To: Message-ID: <20040416170607.35622.qmail@web12905.mail.yahoo.com> --- Paul Bryson wrote: > > Now the question is what would this flag system look like ? > > Would some reserved flags in the Block header be used ? > > Would something be hardcoded in the block header (just like the > current > > sint16 relative timecode is stored) ? > > Or would there be a new child element ? (considering the smallest > > element possible, it would consume 3 bytes per frame) > > Please look at the suggestion that I made for a Block2. > http://thread.gmane.org/gmane.comp.multimedia.matroska.devel/1578 > For some reason I don't actually say it, but the flags part of the > header is > supposed to be an EBML structure so that you can make it any length > you want. > All flags default to zero so that you don't need to actually make the > flags area > more than a byte long if they are using the flags default value. Yeah you actually mix the idea of 'hardcoded' fields and ebml (extensible) fields. It's another solution, which at least saves the ebml ID bytes. > > > These changes are just like the changes in the lacing scheme - > very > > > disruptive and not backwards compatible (so older parsers will > have > > > problems with newer files). So if we do that we should first make > the > > > most prominent parsers aware of these changes, release these > > > parsers/commit code to mplayer/gstreamer/whatever, wait a month, > and > > > then release the tools that can write such files. > > > > > > Mosu > > > > Good idea too. Saves the time of adding a new kind of Block :p > > What possible reason could you have for not making a new Block EBML > ID? Its the > whole point of EBML. If the Block design is incompatible with the > old one, then > you make a new EBML ID. Old parsers will simply skip over them then > and you > won't have the playback issues that were there with the lacing. > Either it will > play, or it won't. At least it won't crash/stutter. Sure using a new ID is the clean way for such changes. But tools need to be backward compatible, so we also need to support the previous/old elements. This would mainly mean duplicated coded to do almost the same thing (new ID == new C++ object to handle in libmatroska). Of course people using their own 'library' (such as alexnoe) may not have this issue. Of course reusing the ID means you break forward compatibility (for tools built with the old lib), but if you know all the tools using matroska it's not too hard to make them update for the new design. __________________________________ Do you Yahoo!? Yahoo! Tax Center - File online by April 15th http://taxes.yahoo.com/filing.html From paul at msn.com Fri Apr 16 19:34:13 2004 From: paul at msn.com (Paul Bryson) Date: Fri, 16 Apr 2004 12:34:13 -0500 Subject: [Matroska-devel] Re: Re: Stripped down frame referencing systemfornative MPEG 1/2/4 in MKV ? References: <20040416170607.35622.qmail@web12905.mail.yahoo.com> Message-ID: "Cyrius" wrote... > Sure using a new ID is the clean way for such changes. > But tools need to be backward compatible, so we also need to support > the previous/old elements. This would mainly mean duplicated coded to > do almost the same thing (new ID == new C++ object to handle in > libmatroska). Of course people using their own 'library' (such as > alexnoe) may not have this issue. > Of course reusing the ID means you break forward compatibility (for > tools built with the old lib), but if you know all the tools using > matroska it's not too hard to make them update for the new design. Using a new ID would allow you to use either Block design, depending on which was more efficient. I assume that you would just use all of the same elements (Cluster, BlockGroup, etc) leaving a much smaller amount of duplicated code. Actually, the only thing that would change would be the Block headers, so maybe you could use the same object? Pamel From suiryc at yahoo.com Fri Apr 16 19:49:19 2004 From: suiryc at yahoo.com (Cyrius) Date: Fri, 16 Apr 2004 10:49:19 -0700 (PDT) Subject: [Matroska-devel] Re: Re: Stripped down frame referencing systemfornative MPEG 1/2/4 in MKV ? In-Reply-To: Message-ID: <20040416174919.44666.qmail@web12905.mail.yahoo.com> --- Paul Bryson wrote: > "Cyrius" wrote... > > Sure using a new ID is the clean way for such changes. > > But tools need to be backward compatible, so we also need to > support > > the previous/old elements. This would mainly mean duplicated coded > to > > do almost the same thing (new ID == new C++ object to handle in > > libmatroska). Of course people using their own 'library' (such as > > alexnoe) may not have this issue. > > Of course reusing the ID means you break forward compatibility (for > > tools built with the old lib), but if you know all the tools using > > matroska it's not too hard to make them update for the new design. > > Using a new ID would allow you to use either Block design, depending > on which > was more efficient. I assume that you would just use all of the same > elements > (Cluster, BlockGroup, etc) leaving a much smaller amount of > duplicated code. > Actually, the only thing that would change would be the Block > headers, so maybe > you could use the same object? Not sure the current libmatroska could do that easily. One object == one element == one ID. I have nothing against adding a new element (which is as I said the clean way). The question is more like "Do we really need/want to use a new ID for those changes, or can we manage to upgrade everything - specs, libs & tools - for a new design ?". __________________________________ Do you Yahoo!? Yahoo! Tax Center - File online by April 15th http://taxes.yahoo.com/filing.html From ds at schleef.org Sat Apr 17 01:22:20 2004 From: ds at schleef.org (David Schleef) Date: Fri, 16 Apr 2004 16:22:20 -0700 Subject: [gst-devel] Re: [Matroska-devel] Why porting Gstreamer to Windows would hurt Redmond ..... In-Reply-To: <1082124984.407feab86aa16@rzaixsrv6.rrz.uni-hamburg.de> References: <407D3565.5060500@matroska.org> <407DAEBB.7060104@free.fr> <1082109528.4971.30.camel@otto.amantes> <1082124984.407feab86aa16@rzaixsrv6.rrz.uni-hamburg.de> Message-ID: <20040416232219.GA8488@comedi.org> On Fri, Apr 16, 2004 at 04:16:24PM +0200, Benjamin Otte wrote: > Quoting Thomas Vander Stichele : > > > And on that note - could you please let us know what else is causing > > problems on Windows now that the debugging problem has been resolved > > correctly (to the best of my knowledge, since I cannot test on Windows) > > ? > > > According to David, Windows doesn't allow DLLs with undefined symbols. This > means that our current linking mechanism (not linking to the core lib and > loading dependencies via gst_plugin_load) just doesn't work in Windows. > > AFAICS, the only way to solve that would be a redesign of the plugin linking, > loading and initialization mechanism that would most likely not be > implementable with API compat without major headaches. I already have the core mostly fixed for RTLD_LOCAL/-no-undefined plugins on my local machine. Basically, we'll need to have the entire plugin style #ifdef'd in the core code and ifdef'd in the plugin Makefile.am's, since the plugin linking is slightly different. I'm hoping it won't really be that gross. On Windows, you'll have to use the new style, and on Linux, you'll have the option of using either style (with the obvious caveat that you won't be compatibile with everyone else if you use the new style.) dave... From ds at schleef.org Sat Apr 17 02:00:47 2004 From: ds at schleef.org (David Schleef) Date: Fri, 16 Apr 2004 17:00:47 -0700 Subject: [gst-devel] Re: [Matroska-devel] Why porting Gstreamer to Windows would hurt Redmond ..... In-Reply-To: <20040416232219.GA8488@comedi.org> References: <407D3565.5060500@matroska.org> <407DAEBB.7060104@free.fr> <1082109528.4971.30.camel@otto.amantes> <1082124984.407feab86aa16@rzaixsrv6.rrz.uni-hamburg.de> <20040416232219.GA8488@comedi.org> Message-ID: <20040417000047.GA10457@comedi.org> On Fri, Apr 16, 2004 at 04:22:20PM -0700, David Schleef wrote: > I already have the core mostly fixed for RTLD_LOCAL/-no-undefined > plugins on my local machine. Basically, we'll need to have the > entire plugin style #ifdef'd in the core code and ifdef'd in the > plugin Makefile.am's, since the plugin linking is slightly different. > I'm hoping it won't really be that gross. On Windows, you'll > have to use the new style, and on Linux, you'll have the option > of using either style (with the obvious caveat that you won't > be compatibile with everyone else if you use the new style.) Oh yeah, and this requires glib-2.4. dave... From spyder at matroska.org Sun Apr 18 06:18:29 2004 From: spyder at matroska.org (John Cannon) Date: Sat, 17 Apr 2004 23:18:29 -0500 Subject: [Matroska-devel] Gstreamer Matroska Muxer Message-ID: <40820195.5010105@matroska.org> Hi, Tonight I was playing with gst-launch and figured out how to mux files finally with the help of alley_cat and Ronald. I was writing an app to do this but as everyone in the channel at the time would know I lost the app after an hour of work. After I got over the frustration (2 CSI episodes later), I started back with gst-launch. This time I successfully muxed a matroska file. :) Interesting things happen with this file however. First, for some reason the file crashes mkvverify. It reads fine in mkvinfo however. Alex, I can get you a small sample file perhaps later so you can debug this. Second, the file it self has a few problems but still nothing to crash Alex's code I think: @Ronald 1) the duration in the segment info is 0 - Not so much a bug as a missing feature. You should write this if at all possible. 2) The codec ID for XviD is wrong. Currently the code uses the native MPEG-4 ID which is OK as long as the video isn't packed bitstream and you add references. But, (see 3) you don't and therefore I think you should use the VFW compat. ID. 3) There are no refernces written. This of course requires knowledge of the video frames, at least where keyframes are. I assume this is why mkvinfo reports every frame as an I frame. This should be fixed :) 4) You have very small clusters. I'm not sure why yet. But some clusters only have one video frame in them. Very odd. 5) Samplerate for my tested file's audio stream is 0. Looking at the code for the muxer, I see that the sample rate is obtained and written, yet it still is written as 0. Weird...maybe due to the audio coming stright out of an AVI. So ... There is some work to be done on the muxer. I haven't tried the demuxer yet. I would like to learn gstreamer's plugin API and then maybe I could at least assist in maintaining this plugin. @ Alex, remind me on IRC and I'll conjure up a clip for you to crash your app with :) @Mosu, the file doesn't play in mplayer because the video codec ID is unknown it says. I thought you change that? PS: I have a full analysis of this file here, it's 1.7MB, if you want it let me know and I'll tell you where to get it. John From R.S.Bultje at students.uu.nl Sun Apr 18 15:10:19 2004 From: R.S.Bultje at students.uu.nl (Ronald S. Bultje) Date: Sun, 18 Apr 2004 15:10:19 +0200 Subject: [Matroska-devel] Gstreamer Matroska Muxer In-Reply-To: <40820195.5010105@matroska.org> References: <40820195.5010105@matroska.org> Message-ID: <1082293818.4047.45.camel@shrek.bitfreak.net> Hi John, On Sun, 2004-04-18 at 06:18, John Cannon wrote: > 1) the duration in the segment info is 0 - Not so much a bug as a > missing feature. You should write this if at all possible. Hm, I do write that after EOS. I might have broken that at some point. Can you debug gst_matroska_mux_finish()? > 2) The codec ID for XviD is wrong. Currently the code uses the native > MPEG-4 ID which is OK as long as the video isn't packed bitstream and > you add references. But, (see 3) you don't and therefore I think you > should use the VFW compat. ID. Yeah, Chris already told me. > 3) There are no refernces written. This of course requires knowledge of > the video frames, at least where keyframes are. I assume this is why > mkvinfo reports every frame as an I frame. This should be fixed :) I know that (GST_BUFFER_HAS_FLAG (buf, GST_BUFFER_KEY_UNIT)), but I don't know how referencing works. You guys should explain that somewhere sometime. ;). > 4) You have very small clusters. I'm not sure why yet. But some > clusters only have one video frame in them. Very odd. I know, one frame per cluster. I've never understood how this is supposed to work. > 5) Samplerate for my tested file's audio stream is 0. Looking at the > code for the muxer, I see that the sample rate is obtained and written, > yet it still is written as 0. Weird...maybe due to the audio coming > stright out of an AVI. Could you debug this further please? I do write it, code looks good. I've had this working for me locally. > So ... There is some work to be done on the muxer. I haven't tried the > demuxer yet. I would like to learn gstreamer's plugin API and then > maybe I could at least assist in maintaining this plugin. Please do. As for the bugs, feel free to put each of them into bugzilla, that way I don't forget (that's why we use bugzilla ;) ). Ronald From paul at msn.com Mon Apr 19 05:40:40 2004 From: paul at msn.com (Paul Bryson) Date: Sun, 18 Apr 2004 22:40:40 -0500 Subject: [Matroska-devel] Re: Gstreamer Matroska Muxer References: <40820195.5010105@matroska.org> <1082293818.4047.45.camel@shrek.bitfreak.net> Message-ID: I'll try an answer what I can. "Ronald S. Bultje" wrote... > > 3) There are no refernces written. This of course requires knowledge of > > the video frames, at least where keyframes are. I assume this is why > > mkvinfo reports every frame as an I frame. This should be fixed :) > I know that (GST_BUFFER_HAS_FLAG (buf, GST_BUFFER_KEY_UNIT)), but I > don't know how referencing works. You guys should explain that somewhere > sometime. ;). Use this element to indicate a P/B frame. http://matroska.org/technical/specs/index.html#ReferenceBlock Instead of having specific definitions of P or B frames, Matroska opted to simply let the codec define what frames are needed for decode. In this way, a frame could define 1, 2, or how ever many frames were required to decode it. In the case of a P frame, you would put the I or P frame just prior to it. For a B frame, you would put the frame just before and just after it in two ReferenceBlocks. > 4) You have very small clusters. I'm not sure why yet. But some > > clusters only have one video frame in them. Very odd. > I know, one frame per cluster. I've never understood how this is > supposed to work. It might help to look at the diagram of the Clusters. http://matroska.org/technical/diagram/index.html A single cluster would typically contain several Blocks from all of the tracks. The number of Blocks is limited by size or time or both. For instance, you might set the limit to 500KB and 5 seconds. So, you make a Cluster and write a timecode element at the beginning of it. Then you start writing Blocks from all of the tracks to it in order of their timecode. Once you hit a limit of either 500KB in the cluster, or 5 seconds worth of data, then you end the cluster and start another one. It is perfectly legal to write a file containing 1 Block per Cluster, but it is incredibly wasteful as you waste bytes writing new Clusters and Timecode elements. With 1ms accuracy, you could write up to about 64 seconds of data in one Cluster of an almost unlimited size. However, this makes it more difficult to recover from an error. A few seconds and a few hundred kilobytes is probably fine. Alex Noe made some tests to see where the overhead stopped being noticable, but security was fine. Pamel From miguel at cetuc.puc-rio.br Mon Apr 19 15:18:49 2004 From: miguel at cetuc.puc-rio.br (Miguel Freitas) Date: Mon, 19 Apr 2004 10:18:49 -0300 Subject: [Matroska-devel] Re: [xine-devel] LinuxTAG 2004: Linux Video Booth In-Reply-To: <20040415181436.33aad350@caprice.artificis.hu> References: <20040415181436.33aad350@caprice.artificis.hu> Message-ID: <1082380729.23970.9.camel@pitanga.ldhs.cetuc.puc-rio.br> Hi Alex, On Thu, 2004-04-15 at 13:14, Alex Beregszaszi wrote: > Diego Biurrun and myself from MPlayer are thinking about organizing this > year a big common booth among video related open source projects. > > The biggest projects should come and cooperate: FFmpeg, MPlayer, xine, > VideoLAN, Matroska and maybe others I forgot.. I don't think my opinion will matter (given that i'm thousands km away from europe), but still this sounds like a nice idea. > I've just asked the Linuxtag organizers about having such a booth, but > at least the xine team knows the way to do it as they had a booth last > year. afair the booth was shared with gentoo folks. i guess they have taken care of contacting the organizers. regards, Miguel From steve.lhomme at free.fr Tue Apr 20 17:15:59 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Tue, 20 Apr 2004 17:15:59 +0200 Subject: [Matroska-devel] Free C++ compiler from Microsoft Message-ID: <40853EAF.9070901@free.fr> http://msdn.microsoft.com/visualc/vctoolkit2003/ From alexander.noe at s2001.tu-chemnitz.de Tue Apr 20 23:24:53 2004 From: alexander.noe at s2001.tu-chemnitz.de (=?ISO-8859-1?Q?Alexander_No=E9?=) Date: Tue, 20 Apr 2004 23:24:53 +0200 Subject: [Matroska-devel] Gstreamer Matroska Muxer In-Reply-To: <40820195.5010105@matroska.org> References: <40820195.5010105@matroska.org> Message-ID: <40859525.9010507@hrz.tu-chemnitz.de> John Cannon wrote: > Hi, > First, for some reason the file crashes mkvverify. The TrackUID is missing. I made a fix now to abord with a fatal error message instead of a crash. Alex From alexander.noe at s2001.tu-chemnitz.de Wed Apr 21 00:39:39 2004 From: alexander.noe at s2001.tu-chemnitz.de (=?ISO-8859-1?Q?Alexander_No=E9?=) Date: Wed, 21 Apr 2004 00:39:39 +0200 Subject: [Matroska-devel] Cluster::Position kills mkvinfo Message-ID: <4085A6AB.2020307@hrz.tu-chemnitz.de> MKVInfo dies on files containing Position elements in their clusters. That shouldn't happen. Alex From paul at msn.com Wed Apr 21 00:50:44 2004 From: paul at msn.com (Paul Bryson) Date: Tue, 20 Apr 2004 17:50:44 -0500 Subject: [Matroska-devel] Vorbis skipping bug Message-ID: There appears to be a bug in either Matroska Splitter or CoreVorbis. Here is a file that will skip at about 1 minute and 45 seconds. http://commo.de/skip.mka It will not skip again once it has skipped and you seek back to it. This file was muxed with MKVMerge, but it will also happen if muxed with AVIMux GUI or the Matroska Stream Editor. The Clusters appear normal from MKVInfo. When I cut the first part of the audio, I was not able to find another skip in the clip. The problem does not show in fb2k. The original file had video, but its presence doesn't seem to make a difference. Also from the user: this is q5.. when I made it q6, it happened about 15 secs earlier Thanks to Moitah for finding this bug. Pamel From moritz at bunkus.org Wed Apr 21 09:58:28 2004 From: moritz at bunkus.org (Moritz Bunkus) Date: Wed, 21 Apr 2004 09:58:28 +0200 Subject: [Matroska-devel] Cluster::Position kills mkvinfo In-Reply-To: <4085A6AB.2020307@hrz.tu-chemnitz.de> References: <4085A6AB.2020307@hrz.tu-chemnitz.de> Message-ID: <20040421075828.GE1898@bunkus.org> Hi, > MKVInfo dies on files containing Position elements in their clusters. > That shouldn't happen. Probably a bug in libmatroska - it doesn't handle unknown elements (too well). mkvinfo will just print 'Unknown element' on unknown elements. 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 weigelt at metux.de Wed Apr 21 10:07:33 2004 From: weigelt at metux.de (Enrico Weigelt) Date: Wed, 21 Apr 2004 10:07:33 +0200 Subject: [Matroska-devel] mobbing @mplayer-lists ! Message-ID: <200404210807.i3L87Xee032066@metux.de> Hi, I just wanted you to know, that Attila Kinali has mobbed me out of the mplayer lists, because I wanted to discuss with him about why he threatened to kick me off the list. The background was, that he disliked my signature - which was too long for him - and so he wrote me a mail where he threatened to kick me off the mplayer-lists immediately if I post any single mail with this signature. He defamed my signature - which just contained my contact information - as "spam" and demanded me to cut it down. I asked him, if it is just for principle or if there is any good reason and if a signature filter wouldn't help. I also stated that in all the about 100 maillists where I'm active, nobody had a problem w/ my signature yet. As he also uses the mutt mta, I asked him, if he would have any tip how to configure it in order to skip off the signature for the mplayer lists. But with his answer he made absolutely clear, that's he's the boss of the lists and he doesn't need any good reason to hate my signature. As I then asked him, if he really wants such a childish niveau, he just kicked me off the lists @mplayerhq.hu. Well, nevertheless some people disliked me from the moment when I wanted to improve the buildsystem to make it more consistent and reliable for fully automated builds and at least when I "collaborated" with the "stupid" matroska people and voted for a common codec api. (rich felker at most - he seemed to be quite paranoid at all ...) Isn't it funny ? Probly its not good publicity for mplayer ... greetz From paul at msn.com Wed Apr 21 16:07:47 2004 From: paul at msn.com (Paul Bryson) Date: Wed, 21 Apr 2004 09:07:47 -0500 Subject: [Matroska-devel] Re: Vorbis skipping bug References: Message-ID: Here is a much smaller/shorter version where the skip occurs after about 1 second. Exact same situation. http://commo.de/skip2.mka Pamel "Paul Bryson" wrote... > There appears to be a bug in either Matroska Splitter or CoreVorbis. Here is a > file that will skip at about 1 minute and 45 seconds. > http://commo.de/skip.mka > > It will not skip again once it has skipped and you seek back to it. > This file was muxed with MKVMerge, but it will also happen if muxed with AVIMux > GUI or the Matroska Stream Editor. The Clusters appear normal from MKVInfo. > When I cut the first part of the audio, I was not able to find another skip in > the clip. > The problem does not show in fb2k. > The original file had video, but its presence doesn't seem to make a difference. > > Also from the user: > this is q5.. when I made it q6, it happened about 15 secs earlier > > Thanks to Moitah for finding this bug. > > > Pamel From chris at matroska.org Wed Apr 21 17:49:48 2004 From: chris at matroska.org (Christian HJ Wiesner) Date: Wed, 21 Apr 2004 17:49:48 +0200 Subject: [Matroska-devel] Re: [gst-devel] Re: audio/mpeg4 muxer In-Reply-To: References: Message-ID: <4086981C.70702@matroska.org> Benjamin Otte wrote: >On Mon, 19 Apr 2004, ChristianHJW wrote: > >>BBB's matroska muxer plugin should work for the creation of MKV's >>already, but we recently found a couple of bugs in it. Before using it >>for a final backup file, i recommend to wait until then. >> >here's bug reports about that? > > > Nope, i guess spyder482 decided to fix them rather than filing a bug report ;-) ..... let see how he is coming along, diving through BBB's code, and making his way through the Linux dungeon ... >>>Is there a MOV muxer existing ? >>> >>> >No there's not. I don't even like the state of the MOV demuxer... >Benjaminwe > > Hmmm ..... as much as i love the fact that Gstreamer has a matroska muxer while it doesnt have a MOV/MP4 muxer yet at a first glance, the more i feel we urgently need those if we want Gstreamer to be established as THE opensource multimedia framework. I promise to talk to Jory again on IRC, today or tomorrow if i get hold of him, about a prerelease of what we have, as a first working version of a win32 version. I am convinced that we could attract a lot of other developers to contribute to the project, even from the Windows world, if we are successful to transport the message we have for it, and to give people an idea how beneficious a working platform like Gstreamer could be compared to DirectShow, as a rather closed, limited blackbox solution. Lets see if i can motivate him to put some working binaries together, with some first ported plugins, so that we can launch them to a very small circle of devs on Doom9 and Hydrogenaudio ..... Christian From rbultje at ronald.bitfreak.net Wed Apr 21 19:37:40 2004 From: rbultje at ronald.bitfreak.net (Ronald Bultje) Date: Wed, 21 Apr 2004 19:37:40 +0200 (CEST) Subject: [Matroska-devel] Re: [gst-devel] Re: audio/mpeg4 muxer In-Reply-To: <4086981C.70702@matroska.org> Message-ID: Hi, On Wed, 21 Apr 2004, Christian HJ Wiesner wrote: > Benjamin Otte wrote: > > On Mon, 19 Apr 2004, ChristianHJW wrote: > > > BBB's matroska muxer plugin should work for the creation of MKV's > > > already, but we recently found a couple of bugs in it. Before using > > > it for a final backup file, i recommend to wait until then. > > > > here's bug reports about that? > > Nope, i guess spyder482 decided to fix them rather than filing a bug > report ;-) ..... let see how he is coming along, diving through BBB's > code, and making his way through the Linux dungeon ... I'd rather see bug reports either way. I told this to John as well when I Replied to his email. Bug reports are the primary way of communicating code in the GNOME world. > > > > Is there a MOV muxer existing ? [..] > Hmmm ..... as much as i love the fact that Gstreamer has a matroska > muxer while it doesnt have a MOV/MP4 muxer yet at a first glance, the > more i feel we urgently need those if we want Gstreamer to be > established as THE opensource multimedia framework. There's loads of things needed, and a .mov/.mp4 muxer is just one of them. (a.k.a. feel free to write one. ;) ) I myself am more interested in DVD encoding (and have all necessary tools for that integrated in GStreamer already). Note that there's ffmpeg muxer, but disabled. The code has been used to mux MPEG files, and worked fine. The problem is that for each format, there's some specific code and such needed, and I didn't bother to add that because of the low amount of interest vs. high amount of work + testing. It will require little work, however, to make it work specifically for .mvo/.mp4. The module is called gst-ffmpeg and you can enable those muxers by editing ext/ffmpeg/gstffmpeg.c and uncomment the line that registers the muxers. Recompile, re-register and you're done. Note that I don't provide support for those, they're disabled for a reason. ;). Ronald From paul at msn.com Thu Apr 22 07:16:49 2004 From: paul at msn.com (Paul Bryson) Date: Thu, 22 Apr 2004 00:16:49 -0500 Subject: [Matroska-devel] Re: RFC 1134 - New EBML Block design (Block2) References: Message-ID: "Paul Bryson" wrote... > The Bitflags are a set of bits used as flags to indicate Block2 structure. > Default value of all Flags are 0. If an unknown flag is set to 1, the Block2 > should be discarded by the parsers. > > Bitflags are as follows. > Bit > 0-1 Lacing flags > 2 Time flag > 3-6 Unused > 7 Gap flag I may not have been clear about this, but the bitflags field was an EBML field also. Bits 0-1 would be bits 0-1 AFTER the EBML size field. > The Time flag indicates what method is used for calculating the timecode. > 0 Timecode calculation is identical to the original Block design. It is > calculated by adding the Time to the Cluster's Timecode and then multiplying the > result by the TimecodeScale. > 1 Timecode calculation is based on a new element in the Cluster. The Cluster > Sample*. The Time is added to the Cluster's Sample to obtain the first sample > number in the Block2. That number is then multiplied by the samplerate to > obtain a timecode. I just realized that the addition of a new element is completely unnecessary. A simpler, and existing method would be to use the current Cluster's Timecode element. We know what sample that would equal by using the equation: ((Timecode * TimecodeScale) / 1000000000) * samplerate = x Knock off everything after the decimal, and you have your sample number. Then you used the signed integer from the Block's timecode to represent the number of samples from the Cluster's Timecode. Then you have precise sample seeking, even if the entire file is using 1ms accuracy for timecodes. I don't really believe that this extra sample-accuracy is any more useful than what can be obtained using the current at a lower TimecodeScale. But, I thought I would mention it in case there was ever a need, as it has already been thought through. Pamel From steve.lhomme at free.fr Thu Apr 22 17:15:09 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Thu, 22 Apr 2004 17:15:09 +0200 Subject: [Matroska-devel] IBM Toolkit for MPEG4 Message-ID: <4087E17D.9020304@free.fr> in Java, for free (I think) : http://www.alphaworks.ibm.com/tech/tk4mpeg4?Open&ca=daw-flHut-042204 From steve.lhomme at free.fr Thu Apr 22 22:28:08 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Thu, 22 Apr 2004 22:28:08 +0200 Subject: [Matroska-devel] Re: Re: Tag names In-Reply-To: References: <40532BBD.8060909@home.nl> <4054B190.7050008@home.nl> <4055D0F2.7020907@home.nl> <4056F5BF.3030605@home.nl> <4058CDBF.7020905@home.nl> <4071A580.3060207@home.nl> Message-ID: <40882AD8.2070402@free.fr> Paul Bryson wrote: > "Age Bosma" wrote... > >>Maybe I'm misunderstanding something. Isn't ORIGINAL_DIMENSIONS used to >>store the ratio? > > > I believe the original intention is to store physical dimensions of the thing > being recorded. This would be most applicable for things like if you take a > picture of the Mona Lisa, then in this field you would store that the item that > was recorded was "8.5 in h, 11 in w." Honestly, I'm not even sure how useful > this is. It comes for the RIFF specs. Maybe if you want to project an image on a wall it's better to have it the original size ? That's also why I want this values "deep" in Matroska. From steve.lhomme at free.fr Thu Apr 22 22:50:35 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Thu, 22 Apr 2004 22:50:35 +0200 Subject: [Matroska-devel] LinuxTAG 2004: Linux Video Booth In-Reply-To: <20040415181436.33aad350@caprice.artificis.hu> References: <20040415181436.33aad350@caprice.artificis.hu> Message-ID: <4088301B.40203@free.fr> Alex Beregszaszi wrote: > Hi, > > Diego Biurrun and myself from MPlayer are thinking about organizing this > year a big common booth among video related open source projects. > > The biggest projects should come and cooperate: FFmpeg, MPlayer, xine, > VideoLAN, Matroska and maybe others I forgot.. > > I've just asked the Linuxtag organizers about having such a booth, but > at least the xine team knows the way to do it as they had a booth last > year. > > What do you think about the idea? I would be nice to have people from all these teams meet and get drunk together (that might be a way to be friends even though we don't always agree)... Where does it take place and when ? From steve.lhomme at free.fr Thu Apr 22 23:22:00 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Thu, 22 Apr 2004 23:22:00 +0200 Subject: [Matroska-devel] Re: Stripped down frame referencing system fornative MPEG 1/2/4 in MKV ? In-Reply-To: References: <20040416114457.GE8131@bunkus.org> <20040416124614.46767.qmail@web12906.mail.yahoo.com> Message-ID: <40883778.6000909@free.fr> Paul Bryson wrote: > "Cyrius" wrote... > >>--- Moritz Bunkus wrote: >> >>>While the current system is definitely a powerful one it is also one >>>with a lot of overhead which we simply don't need for current >>>codecs. Using flags will immediately save space. Example: The Finding >>>Nemo.mkv has 239099 P frames resulting in 478198 bytes 'wasted'. For >>>B >>>frames: the files I have so far with packed bitstream have 8 bytes >>>(DivX) and 6 bytes (XviD) dummy frames. > > > Yes. That is a "not insignificant" amount of space to many people. I know > Steve has some resistance to this because you don't want people to get used to > using a simple referencing system and ignore the good one when it is needed. > But by now, it shouldn't be a problem. Anyone that makes a new parser would > need to be able to read the old references or nobody would be able to play any > of the files out there. New muxers might be an issue though. I just don't like the idea to have 2 things doing exactly the same thing in a format. The idea was to allow minimal playback systems even if they don't support the whole thing... If you go for a simpler systems, a minimal system will favor this one and not the other. And all "old" files will not play in these players... If it doesn't happen now, it may happen in the future. From moritz at bunkus.org Fri Apr 23 10:10:52 2004 From: moritz at bunkus.org (Moritz Bunkus) Date: Fri, 23 Apr 2004 10:10:52 +0200 Subject: [Matroska-devel] Cluster::Position kills mkvinfo In-Reply-To: <20040421075828.GE1898@bunkus.org> References: <4085A6AB.2020307@hrz.tu-chemnitz.de> <20040421075828.GE1898@bunkus.org> Message-ID: <20040423081052.GC17155@bunkus.org> Heya, > Probably a bug in libmatroska - it doesn't handle unknown elements (too > well). mkvinfo will just print 'Unknown element' on unknown elements. Hmm, more likely a bug in both. mkvinfo does not allow libmatroska to use EbmlDummy elements, which is the first bug. The second is that in this situation libmatroska returns pointers to non-objects (even the typeid operator segfaults on those...). I've fixed that in mkvinfo. In libmatroska I've re-enabled the ClusterPosition element 'cause it's a MatroskaV1 element according to the specs. I'll release new versions of libebml & libmatroska today. They'll both be 0.7.0, mostly because they're LGPL now. A new mkvtoolnix release might follow tonight as well. 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 alex at fsn.hu Sun Apr 25 13:40:41 2004 From: alex at fsn.hu (Alex Beregszaszi) Date: Sun, 25 Apr 2004 13:40:41 +0200 Subject: [Matroska-devel] LinuxTAG 2004: Linux Video Booth In-Reply-To: <4088301B.40203@free.fr> References: <20040415181436.33aad350@caprice.artificis.hu> <4088301B.40203@free.fr> Message-ID: <20040425134041.406e822a@caprice.artificis.hu> tHi, > > What do you think about the idea? > > I would be nice to have people from all these teams meet and get drunk > together (that might be a way to be friends even though we don't > always agree)... > > Where does it take place and when ? Visit www.linuxtag.org: 23-26 juni 2004 / karlsruhe / germany We're (the "organizers") planning to stay the whole event so if some of you can only join us one day, just do it -- Alex Beregszaszi e-mail: alex at fsn.hu Free Software Network cell: +36 70 3144424 From mru at kth.se Sun Apr 25 16:10:01 2004 From: mru at kth.se (=?iso-8859-1?q?M=E5ns_Rullg=E5rd?=) Date: Sun, 25 Apr 2004 16:10:01 +0200 Subject: [Ffmpeg-devel] Re: [Matroska-devel] LinuxTAG 2004: Linux Video Booth In-Reply-To: <20040425134041.406e822a@caprice.artificis.hu> (Alex Beregszaszi's message of "Sun, 25 Apr 2004 13:40:41 +0200") References: <20040415181436.33aad350@caprice.artificis.hu> <4088301B.40203@free.fr> <20040425134041.406e822a@caprice.artificis.hu> Message-ID: Alex Beregszaszi writes: > tHi, > >> > What do you think about the idea? >> >> I would be nice to have people from all these teams meet and get drunk >> together (that might be a way to be friends even though we don't >> always agree)... >> >> Where does it take place and when ? > Visit www.linuxtag.org: > 23-26 juni 2004 / karlsruhe / germany > > We're (the "organizers") planning to stay the whole event so if some of > you can only join us one day, just do it Is TCVP too small to be welcome? -- M?ns Rullg?rd mru at kth.se From steve.lhomme at free.fr Tue Apr 27 23:04:24 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Tue, 27 Apr 2004 23:04:24 +0200 Subject: [Matroska-devel] Native Win32 build of GStreamer 0.8.1 Message-ID: <408ECAD8.4030502@free.fr> Hi everyone, I finally managed to compile GStreamer 0.8.1 (modified) under Windows using MS VS.Net 2003. The project currently requires the IDE but I will make a makefile to compile it with the Free command-line version. I will also make the gst-plugins package work ASAP. I can already submit my modified files somewhere for approval/integration. How do we proceed ? (I can send only the modified files and added files somewhere/to someone) From rbultje at ronald.bitfreak.net Wed Apr 28 00:06:03 2004 From: rbultje at ronald.bitfreak.net (Ronald Bultje) Date: Wed, 28 Apr 2004 00:06:03 +0200 (CEST) Subject: [Matroska-devel] Re: [gst-devel] Native Win32 build of GStreamer 0.8.1 In-Reply-To: <408ECAD8.4030502@free.fr> Message-ID: Hi Steve, On Tue, 27 Apr 2004, Steve Lhomme wrote: > I can already submit my modified files somewhere for > approval/integration. How do we proceed ? (I can send only the modified > files and added files somewhere/to someone) Send unified diff patches (not sure how to make those in VC++, but I'm sure it's possible) to bugzilla. We can also get you a CVS account after a while if things appear to work okay. Ronald From ds at schleef.org Wed Apr 28 00:02:06 2004 From: ds at schleef.org (David Schleef) Date: Tue, 27 Apr 2004 15:02:06 -0700 Subject: [Matroska-devel] Re: [gst-devel] Native Win32 build of GStreamer 0.8.1 In-Reply-To: <408ECAD8.4030502@free.fr> References: <408ECAD8.4030502@free.fr> Message-ID: <20040427220206.GA21349@comedi.org> On Tue, Apr 27, 2004 at 11:04:24PM +0200, Steve Lhomme wrote: > Hi everyone, > > I finally managed to compile GStreamer 0.8.1 (modified) under Windows > using MS VS.Net 2003. The project currently requires the IDE but I will > make a makefile to compile it with the Free command-line version. > > I will also make the gst-plugins package work ASAP. > > I can already submit my modified files somewhere for > approval/integration. How do we proceed ? (I can send only the modified > files and added files somewhere/to someone) Please create a bug in bugzilla.gnome.org and attach the patch to that. Also note that a lot of things wrt building on Windows has changed since 0.8.1 -- specifically, a tree disted from the current CVS builds[1] with gcc on Windows. So it might be a good idea to port the patch to current CVS before attaching to the bug. dave... [1] builds == builds, but requires copying some generated files since they don't autogenerate correctly on Windows. From rbultje at ronald.bitfreak.net Wed Apr 28 18:33:32 2004 From: rbultje at ronald.bitfreak.net (Ronald Bultje) Date: Wed, 28 Apr 2004 18:33:32 +0200 (CEST) Subject: [Matroska-devel] eek! Message-ID: Hi, Go to http://www.matroska.org/ -> Guides -> Playback -> Linux -> GStreamer and check the contents. "Use mplayer"? Dudes, fix that! Our matroska support is far better than theirs, and theirs is ripped from ours anyway. Thanks ;-), Ronald From moritz at bunkus.org Fri Apr 30 10:42:55 2004 From: moritz at bunkus.org (Moritz Bunkus) Date: Fri, 30 Apr 2004 10:42:55 +0200 Subject: [Matroska-devel] eek! In-Reply-To: References: Message-ID: <20040430084255.GF20192@bunkus.org> Hi, > Go to http://www.matroska.org/ -> Guides -> Playback -> Linux -> GStreamer > and check the contents. "Use mplayer"? Dudes, fix that! Our matroska > support is far better than theirs, and theirs is ripped from ours > anyway. Done. Btw, the mplayer support was there way before the gstreamer support was written. Yes, the current implementation is based on yours, and yours was great work, but I somehow doubt the 'far better' part. 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 R.S.Bultje at students.uu.nl Fri Apr 30 07:54:31 2004 From: R.S.Bultje at students.uu.nl (Ronald S. Bultje) Date: Fri, 30 Apr 2004 07:54:31 +0200 Subject: [Matroska-devel] eek! In-Reply-To: <20040430084255.GF20192@bunkus.org> References: <20040430084255.GF20192@bunkus.org> Message-ID: <1083304471.9771.31.camel@shrek.bitfreak.net> Hi, On Fri, 2004-04-30 at 10:42, Moritz Bunkus wrote: > Done. Btw, the mplayer support was there way before the gstreamer > support was written. Yes, the current implementation is based on yours, > and yours was great work, but I somehow doubt the 'far better' part. It sounded so good. ;). Thanks, Ronald