From moritz at bunkus.org Thu Jan 1 14:42:26 2004 From: moritz at bunkus.org (Moritz Bunkus) Date: Thu, 1 Jan 2004 14:42:26 +0100 Subject: [Matroska-devel] libebml 0.6.3 & libmatroska 0.6.2 released Message-ID: <20040101134226.GG21226@bunkus.org> Heya, I've released new versions of both libebml (now 0.6.3) and libmatroska (now 0.6.2). Both include a ChangeLog which I'll automatically generate form the CVS commit messages. Therefore you should all use very descriptive commit messages, please! We don't have any other means of documenting changes at the moment. Especially messages like Cyrius 'fixes' are not really helpful ;) Happy new year. Mosu -- If Darl McBride was in charge, he'd probably make marriage unconstitutional too, since clearly it de-emphasizes the commercial nature of normal human interaction, and probably is a major impediment to the commercial growth of prostitution. - Linus Torvalds From steve.lhomme at free.fr Fri Jan 2 12:13:49 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Fri, 02 Jan 2004 12:13:49 +0100 Subject: [Matroska-devel] ContentEncodings element use in DirectShow In-Reply-To: References: Message-ID: <3FF5526D.9000903@free.fr> Paul Bryson wrote: > I bugged Jory about creating a decryption filter that can do this but it would > be nice to know if there are any existing DirectShow standards that would cover > what would be required for this. Also, if anyone has any ideas on a good way to > get this done, that would be great. This is one of the features that should be > working for the Matroska 1.0 specs release so any help to speed it along would > be great. IMo you should create an API independant of DirectShow. This way the same decoding plugin could be used by other apps such as VLC, MPlayer and others with the same API. This API is probably Matroska specific, as after decoding, we have to keep "attached" to the decrypted content a lot of Matroska specific stuff (timecode and other meta data). From spyder at matroska.org Fri Jan 2 18:44:29 2004 From: spyder at matroska.org (John Cannon) Date: Fri, 02 Jan 2004 11:44:29 -0600 Subject: [Matroska-devel] ContentEncodings element use in DirectShow In-Reply-To: <3FF5526D.9000903@free.fr> References: <3FF5526D.9000903@free.fr> Message-ID: <3FF5ADFD.4010505@matroska.org> Steve Lhomme wrote: > Paul Bryson wrote: > >> I bugged Jory about creating a decryption filter that can do this but >> it would >> be nice to know if there are any existing DirectShow standards that >> would cover >> what would be required for this. Also, if anyone has any ideas on a >> good way to >> get this done, that would be great. This is one of the features that >> should be >> working for the Matroska 1.0 specs release so any help to speed it >> along would >> be great. > > > IMo you should create an API independant of DirectShow. This way the > same decoding plugin could be used by other apps such as VLC, MPlayer > and others with the same API. > > This API is probably Matroska specific, as after decoding, we have to > keep "attached" to the decrypted content a lot of Matroska specific > stuff (timecode and other meta data). I said the exact same thing the other day ;) I just couldn't think of a real reason to convince Paul why it would be Matroska specific. John From paul at msn.com Fri Jan 2 23:00:31 2004 From: paul at msn.com (Paul Bryson) Date: Fri, 2 Jan 2004 16:00:31 -0600 Subject: [Matroska-devel] Re: ContentEncodings element use in DirectShow References: <3FF5526D.9000903@free.fr> Message-ID: "Steve Lhomme" wrote... > Paul Bryson wrote: > > I bugged Jory about creating a decryption filter that can do this but it would > > be nice to know if there are any existing DirectShow standards that would cover > > what would be required for this. Also, if anyone has any ideas on a good way to > > get this done, that would be great. This is one of the features that should be > > working for the Matroska 1.0 specs release so any help to speed it along would > > be great. > > IMo you should create an API independant of DirectShow. This way the > same decoding plugin could be used by other apps such as VLC, MPlayer > and others with the same API. Talk to Jory, I have nothing to do with the specifics of the design. > This API is probably Matroska specific, as after decoding, we have to > keep "attached" to the decrypted content a lot of Matroska specific > stuff (timecode and other meta data). Why would a timecode be Matrsoka specific? AFAIK, the only reason that this would be Matroska specific is no other container can support this. For DirectShow, all of the ContentEncoding stuff would only be used to create the graph and initialize the filters. Once that is done it doesn't need anything else and should function just like any other graph out there. I asked BBB about how G-Streamer would do it, but I can't recall what he said as I didn't have a very firm grasp on it. His comments would be very helpful here if you would like some input for a common API to use. I'm not sure where the VLC guys are though. Pamel From steve.lhomme at free.fr Sat Jan 3 15:01:43 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Sat, 03 Jan 2004 15:01:43 +0100 Subject: [Matroska-devel] DVD Menu Message-ID: <3FF6CB47.9040104@free.fr> I'm going to spend some time in the near future to check the DVD menu specs (Pamel sent me a paying site where there could be usefull informations). I found this tool that may be a good indication on what is possible with DVD menus : http://menuedit.dimad.net/home.html BTW, we will probably have to do a tool DVD menus to the Matroska menu format. So we will probably have to code the whole parser for DVD menus at some point. Apparently there is no such thing existing as an open source code. But does anyone have info on this ? Maybe on VLC or MPlayer they have this ? I'm sure we could get more help from the CoreCodec team or Gabest as they probably would benefit from such code too to read DVDs in a better way. From chris at matroska.org Sat Jan 3 15:54:46 2004 From: chris at matroska.org (Christian HJ Wiesner) Date: Sat, 03 Jan 2004 15:54:46 +0100 Subject: [Matroska-devel] DVD Menu In-Reply-To: <3FF6CB47.9040104@free.fr> References: <3FF6CB47.9040104@free.fr> Message-ID: <3FF6D7B6.8060703@matroska.org> Guys, i thought about this recently, and referring to the discussion on IRC lately if we should wait with the 1.0 specs until menues are at least specified ( even if implemented later ). What you think of the following idea : Lets implement a 'simple' menue system and 'basic' control tracks for the 1.0 specs, and lets look at the DVD menues very closely for that. After all, they should meanwhile not be protected anymore as the DVD system is almost 15 years old now ( not real units, but at least the specs ), so i dont think the industry is looking very closely at who is implementing it without paying the licenses. Lets not forget, any Windows OS is coming with by default with a DShow implementation for the DVD menue, maybe we could even use the existing DShow fiter that way ? A more advanced menue system could follow later then, with the 2.0 specs, and i even think it wouldnt hurt if this menue system would not be based on the 1.0 version, but be a complete starting over from scratch. After all, the possibility to mux a complete DVD into a single, huge matroska file, then maybe use the splitting feature in mkvmerge to split a 8 GB file into two 4 GB files to be able to burn them on DVD-R's, without changing anything in the DVD itself. As soon as spyder has the MPEG2 video muxing done, only the menues are missing for that, as all audio formats ( AC3, DTS, MP2, PCM ) are already supported in MKV. The biggest argument for DVD users to look at matroska for editing/intermediate storage was of course if we were able to make VirtualdubMod edit MKV files with MPEG2 video. I am maybe not telling you this often enough, but without VdubMod supporting MKV, matroska would not be as popular as it is . mkvmerge may be the most important tool for MKV creation amongst the Pro's, but the average matroska user is still very focussed on VirtualdubMod, and the fact that matroska files can be edited cant be weighed in gold. Cyrius, would MPEG2 editing in MKV be possible, mayb even with preview ? What does everbody think of the idea to make a 'simple' menue spec based on the DVD specs, for the 1.0 matroska release ? Best regards Christian Steve Lhomme wrote: > I'm going to spend some time in the near future to check the DVD menu > specs (Pamel sent me a paying site where there could be usefull > informations). > I found this tool that may be a good indication on what is possible > with DVD menus : > http://menuedit.dimad.net/home.html > BTW, we will probably have to do a tool DVD menus to the Matroska menu > format. So we will probably have to code the whole parser for DVD > menus at some point. Apparently there is no such thing existing as an > open source code. But does anyone have info on this ? Maybe on VLC or > MPlayer they have this ? I'm sure we could get more help from the > CoreCodec team or Gabest as they probably would benefit from such code > too to read DVDs in a better way. From renekoch at e-divx.at Sat Jan 3 16:12:49 2004 From: renekoch at e-divx.at (=?iso-8859-1?Q?Ren=E9_Koch?=) Date: Sat, 3 Jan 2004 16:12:49 +0100 Subject: [Matroska-devel] DVD Menu References: <3FF6CB47.9040104@free.fr> <3FF6D7B6.8060703@matroska.org> Message-ID: <000901c3d20c$0d794e00$05bb2e3e@karlpc> Hey guys! If you decide to make a simple menu system and later an advanced one it should (or better must) be so that the simple menu must also work when the advaced one is implemented because many user will make a backup with a simple menu and if you change it so that this menu won't work later it makes more sence to implement the complete menu system. Just think about it. greetings, scrat > Guys, > > i thought about this recently, and referring to the discussion on IRC > lately if we should wait with the 1.0 specs until menues are at least > specified ( even if implemented later ). What you think of the following > idea : > > Lets implement a 'simple' menue system and 'basic' control tracks for > the 1.0 specs, and lets look at the DVD menues very closely for that. > After all, they should meanwhile not be protected anymore as the DVD > system is almost 15 years old now ( not real units, but at least the > specs ), so i dont think the industry is looking very closely at who is > implementing it without paying the licenses. Lets not forget, any > Windows OS is coming with by default with a DShow implementation for the > DVD menue, maybe we could even use the existing DShow fiter that way ? > > A more advanced menue system could follow later then, with the 2.0 > specs, and i even think it wouldnt hurt if this menue system would not > be based on the 1.0 version, but be a complete starting over from > scratch. After all, the possibility to mux a complete DVD into a single, > huge matroska file, then maybe use the splitting feature in mkvmerge to > split a 8 GB file into two 4 GB files to be able to burn them on > DVD-R's, without changing anything in the DVD itself. As soon as spyder > has the MPEG2 video muxing done, only the menues are missing for that, > as all audio formats ( AC3, DTS, MP2, PCM ) are already supported in MKV. > > The biggest argument for DVD users to look at matroska for > editing/intermediate storage was of course if we were able to make > VirtualdubMod edit MKV files with MPEG2 video. I am maybe not telling > you this often enough, but without VdubMod supporting MKV, matroska > would not be as popular as it is . mkvmerge may be the most important > tool for MKV creation amongst the Pro's, but the average matroska user > is still very focussed on VirtualdubMod, and the fact that matroska > files can be edited cant be weighed in gold. Cyrius, would MPEG2 editing > in MKV be possible, mayb even with preview ? > > What does everbody think of the idea to make a 'simple' menue spec based > on the DVD specs, for the 1.0 matroska release ? > > Best regards > > Christian > > Steve Lhomme wrote: > > > I'm going to spend some time in the near future to check the DVD menu > > specs (Pamel sent me a paying site where there could be usefull > > informations). > > I found this tool that may be a good indication on what is possible > > with DVD menus : > > http://menuedit.dimad.net/home.html > > BTW, we will probably have to do a tool DVD menus to the Matroska menu > > format. So we will probably have to code the whole parser for DVD > > menus at some point. Apparently there is no such thing existing as an > > open source code. But does anyone have info on this ? Maybe on VLC or > > MPlayer they have this ? I'm sure we could get more help from the > > CoreCodec team or Gabest as they probably would benefit from such code > > too to read DVDs in a better way. > > > > _______________________________________________ > 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 Sat Jan 3 18:30:48 2004 From: chris at matroska.org (Christian HJ Wiesner) Date: Sat, 03 Jan 2004 18:30:48 +0100 Subject: [Matroska-devel] DVD Menu In-Reply-To: <000901c3d20c$0d794e00$05bb2e3e@karlpc> References: <3FF6CB47.9040104@free.fr> <3FF6D7B6.8060703@matroska.org> <000901c3d20c$0d794e00$05bb2e3e@karlpc> Message-ID: <3FF6FC48.5010001@matroska.org> Ren? Koch wrote: >Hey guys! >If you decide to make a simple menu system and later an advanced one it >should (or better must) be so that the simple menu must also work when the >advaced one is implemented because many user will make a backup with a >simple menu and if you change it so that this menu won't work later it makes >more sence to implement the complete menu system. >Just think about it. > > Hi Ren?, sure, misunderstanding. When i talked about to start a new, more powerful menue system later, i didnt mean to drop the old menue system and make old file using spec incompliant ;) .... Christian From paul at msn.com Sat Jan 3 18:44:05 2004 From: paul at msn.com (Paul Bryson) Date: Sat, 3 Jan 2004 11:44:05 -0600 Subject: [Matroska-devel] Re: DVD Menu References: <3FF6CB47.9040104@free.fr> <3FF6D7B6.8060703@matroska.org> Message-ID: "Christian HJ Wiesner" wrote... > What does everbody think of the idea to make a 'simple' menue spec based > on the DVD specs, for the 1.0 matroska release ? Not enough time. The 1.0 specs only have about 6 weeks to get out now, right? It is basically everything that has at least some implementation. If there is nothing working for it, then it needs to be moved back to a later release. Besides, 1.0 as it is right now is an excellent starting point for hardware implementation. It basically only has stuff that could very easily be implemented in a hardware device. Pamel From chris at matroska.org Sat Jan 3 21:37:25 2004 From: chris at matroska.org (Christian HJ Wiesner) Date: Sat, 03 Jan 2004 21:37:25 +0100 Subject: [Matroska-devel] Re: DVD Menu In-Reply-To: References: <3FF6CB47.9040104@free.fr> <3FF6D7B6.8060703@matroska.org> Message-ID: <3FF72805.3060109@matroska.org> Pamel, Paul Bryson wrote: >"Christian HJ Wiesner" wrote... > > >>What does everbody think of the idea to make a 'simple' menue spec based >>on the DVD specs, for the 1.0 matroska release ? >> >> >Not enough time. The 1.0 specs only have about 6 weeks to get out now, right? >It is basically everything that has at least some implementation. If there is >nothing working for it, then it needs to be moved back to a later release. > IMO, we should sometimes lean back a bit and see where we are coming from. This means, not making the same error as DivX Networks, who are obviously forgetting about their roots and becoming arrogant. Why is matroska used at all ? Simple answer : its the most feature rich container. Long answer : 1. Its well supported, with many great apps like DirectShow decoder/muxer, mkvmerge, vdubmod, avi-mux GUI, foobar2000, VLC, mplayer, mencoder, etc. .... 2. Its free to use 3. The users know about it, because they are told about its existence ;-) 4. Its feature rich, means with matroska the users can do things they cant do with other containers ( even if those have nice specs with the same features, but users dont give SHIT about specs, they want apps they can use ). matroska can do - RV9 muxing ( users love it ) - chapters - various subtitles, especially vobsubs and SSA are to list, USF to come later - low overhead etc. But, as i was writing in my email to the list recently, we shouldnt be too naive about the acceptance of MP4 as new standard. There are a lot of different companies and opensource projects working on MP4 implementations, bond even made an app to convert DVD menues into MP4 menues, and many users will convert to it because its 'a real standard' ! IMO, it would be a wrong signal to release the 1.0 matroska specs without a menue spec. We would position matroska under Mp4, and thats no good. >Besides, 1.0 as it is right now is an excellent starting point for hardware >implementation. It basically only has stuff that could very easily be >implemented in a hardware device. >Pamel > > Nice idea, if there weren't the big number of used codecs in matroska, making hardware support currently more or less impossible ;) .... Christian From steve.lhomme at free.fr Sun Jan 4 10:56:08 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Sun, 04 Jan 2004 10:56:08 +0100 Subject: [Matroska-devel] Re: DVD Menu In-Reply-To: <3FF72805.3060109@matroska.org> References: <3FF6CB47.9040104@free.fr> <3FF6D7B6.8060703@matroska.org> <3FF72805.3060109@matroska.org> Message-ID: <3FF7E338.1090501@free.fr> Christian HJ Wiesner wrote: > But, as i was writing in my email to the list recently, we shouldnt be > too naive about the acceptance of MP4 as new standard. There are a lot > of different companies and opensource projects working on MP4 > implementations, bond even made an app to convert DVD menues into MP4 > menues, and many users will convert to it because its 'a real standard' ! Actually bond can't rip DVD menus. He just suggest to look at your DVD and recreate the menu yourself from what you saw... So if we can do it the clean way, we have another key feature (in advance). > IMO, it would be a wrong signal to release the 1.0 matroska specs > without a menue spec. We would position matroska under Mp4, and thats no > good. That was once a wise idea to stop the brainstorming and actually put some time limits. But now we should be more relax with that. When things are decided we can progress faster than all MPEG4 stuff that need a lot of various discussions everywhere on what is what. From suiryc at yahoo.com Sun Jan 4 21:47:44 2004 From: suiryc at yahoo.com (Cyrius) Date: Sun, 4 Jan 2004 12:47:44 -0800 (PST) Subject: [Matroska-devel] DVD Menu In-Reply-To: <3FF6D7B6.8060703@matroska.org> Message-ID: <20040104204744.43841.qmail@web12907.mail.yahoo.com> --- Christian HJ Wiesner wrote: > The biggest argument for DVD users to look at > matroska for > editing/intermediate storage was of course if we > were able to make > VirtualdubMod edit MKV files with MPEG2 video. I am > maybe not telling > you this often enough, but without VdubMod > supporting MKV, matroska > would not be as popular as it is . mkvmerge may be > the most important > tool for MKV creation amongst the Pro's, but the > average matroska user > is still very focussed on VirtualdubMod, and the > fact that matroska > files can be edited cant be weighed in gold. Cyrius, > would MPEG2 editing > in MKV be possible, mayb even with preview ? Editing would only work with CFR content. I fear previewing won't be possible (using fccHandler's mpeg2 code) or at least quite hard. IIRC ffvfw can encode to mpeg2 in VFW (at least mpeg2 was proposed in the version I had some times ago) mayb it can decode it too ... __________________________________ Do you Yahoo!? Find out what made the Top Yahoo! Searches of 2003 http://search.yahoo.com/top2003 From steve.lhomme at free.fr Sun Jan 4 22:46:35 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Sun, 04 Jan 2004 22:46:35 +0100 Subject: [Matroska-devel] Freeze 1. Message-ID: <3FF889BB.9030302@free.fr> Hi, As there is a considerable amount of pressure ;) to push for a freeze of the Matroska specs to version 1. I added 2 elements that should be mandatory for playback. It will allow better Control Track support and hide some content, especially hiding the menus by default to 1. compliant players. The 2 elements have been added to the chapter spec, the main spec and the libmatroska code. ChapterFlagHidden allow to hide some menu items to the user. It should be very helpful fro Control Tracks to jump to positions that the user has no need to know. ChapterFlagEnabled allow to disactivate a part of a movie. It can be for some given tracks or all tracks. When it's all tracks, the content should be skipped and be made inaccessible to the user (until it's activated somewhere, namely by a Control Track). That's a good way to hide the menu content from 1.-compliant-only matroska players. This feature support is *mandatory in all cases* ! From steve.lhomme at free.fr Sun Jan 4 22:58:29 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Sun, 04 Jan 2004 22:58:29 +0100 Subject: [Matroska-devel] CueBlockNumber Message-ID: <3FF88C85.3070200@free.fr> On the request of alexnoe, I've changed the meaning of the CueBlockNumber from : "Number of the Block of Track X in the specified Cluster." to : "Number of the Block in the specified Cluster." I hope noone minds. It makes more sense this way and is more useful. From gabest at freemail.hu Sun Jan 4 23:26:51 2004 From: gabest at freemail.hu (Gabest) Date: Sun, 4 Jan 2004 23:26:51 +0100 Subject: [Matroska-devel] CueBlockNumber References: <3FF88C85.3070200@free.fr> Message-ID: <035a01c3d311$d9cbe930$0100a8c0@i2400p4> > On the request of alexnoe, I've changed the meaning of the > CueBlockNumber from : > > "Number of the Block of Track X in the specified Cluster." > > to : > > "Number of the Block in the specified Cluster." > > I hope noone minds. It makes more sense this way and is more useful. The good news, the splitter already has a commented out code ready to use this element in the new meaning (first I interpreted it that way and than was too lazy to alter it). The bad news, the ds muxer already writes this element according to the old specs. Maybe we should create a new element and depricate this one. From paul at msn.com Mon Jan 5 05:04:10 2004 From: paul at msn.com (Paul Bryson) Date: Sun, 4 Jan 2004 22:04:10 -0600 Subject: [Matroska-devel] Re: CueBlockNumber References: <3FF88C85.3070200@free.fr> <035a01c3d311$d9cbe930$0100a8c0@i2400p4> Message-ID: "Gabest" in... > Maybe we should create a new element and > depricate this one. That would of course be taking advantage of one of the features of EBML. Sounds good to me. Pamel From steve.lhomme at free.fr Mon Jan 5 09:38:24 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Mon, 05 Jan 2004 09:38:24 +0100 Subject: [Matroska-devel] Re: CueBlockNumber In-Reply-To: References: <3FF88C85.3070200@free.fr> <035a01c3d311$d9cbe930$0100a8c0@i2400p4> Message-ID: <3FF92280.2050900@free.fr> Paul Bryson wrote: > "Gabest" in... > >>Maybe we should create a new element and >>depricate this one. > > > That would of course be taking advantage of one of the features of EBML. Sounds > good to me. OK, I'll do that tonight. IMO we should "forget" the old one. So that such elements written in files will never be taken into consideration... We're freezing the specs for this kind of reasons. Everything before the freeze can be considered as beta (and not fully stable). But once it's freezed it will never move (out). From moritz at bunkus.org Mon Jan 5 12:39:47 2004 From: moritz at bunkus.org (Moritz Bunkus) Date: Mon, 5 Jan 2004 12:39:47 +0100 Subject: [Matroska-devel] libmatroska did not compile Message-ID: <20040105113947.GA19603@bunkus.org> Heya, the new changes by robux do not compile. I've committed fixes, but please check them. Affected files: KaxChapters.h, KaxChapters.cpp Mosu -- If Darl McBride was in charge, he'd probably make marriage unconstitutional too, since clearly it de-emphasizes the commercial nature of normal human interaction, and probably is a major impediment to the commercial growth of prostitution. - Linus Torvalds From steve.lhomme at free.fr Mon Jan 5 12:51:00 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Mon, 05 Jan 2004 12:51:00 +0100 Subject: [Matroska-devel] libmatroska did not compile In-Reply-To: <20040105113947.GA19603@bunkus.org> References: <20040105113947.GA19603@bunkus.org> Message-ID: <3FF94FA4.9090809@free.fr> Ah, I knew committing without compiling was not a good idea... Moritz Bunkus wrote: > Heya, > > the new changes by robux do not compile. I've committed fixes, but > please check them. Affected files: KaxChapters.h, KaxChapters.cpp > > Mosu > From chris at matroska.org Mon Jan 5 17:35:25 2004 From: chris at matroska.org (Christian HJ Wiesner) Date: Mon, 05 Jan 2004 17:35:25 +0100 Subject: [Matroska-devel] And another time : native replay gain element usage in matroska track headers ? Message-ID: <3FF9924D.7@matroska.org> Hi, i asked this several times already : Are any tools making use of the replaygain element already ? I read this here, and just thought to myself the poor guy needs matroska ;-) : http://www.hydrogenaudio.org/index.php?showtopic=16794&hl= Christian From steve.lhomme at free.fr Mon Jan 5 18:48:37 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Mon, 05 Jan 2004 18:48:37 +0100 Subject: [Matroska-devel] And another time : native replay gain element usage in matroska track headers ? In-Reply-To: <3FF9924D.7@matroska.org> References: <3FF9924D.7@matroska.org> Message-ID: <3FF9A375.6070006@free.fr> Christian HJ Wiesner wrote: > > Hi, > > i asked this several times already : > > Are any tools making use of the replaygain element already ? I read this > here, and just thought to myself the poor guy needs matroska ;-) : > http://www.hydrogenaudio.org/index.php?showtopic=16794&hl= There's no such tool for Matroska yet. And the guy mentioned MPC too, which is not in Matroska yet :'( Anyway for my DJing project I will support MKA and ReplayGain, and probably will have a tool to compute/store it. From steve.lhomme at free.fr Mon Jan 5 20:57:25 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Mon, 05 Jan 2004 20:57:25 +0100 Subject: [Matroska-devel] Re: CueBlockNumber In-Reply-To: <3FF92280.2050900@free.fr> References: <3FF88C85.3070200@free.fr> <035a01c3d311$d9cbe930$0100a8c0@i2400p4> <3FF92280.2050900@free.fr> Message-ID: <3FF9C1A5.1080700@free.fr> Steve Lhomme wrote: > Paul Bryson wrote: > >> "Gabest" in... >> >>> Maybe we should create a new element and >>> depricate this one. >> >> >> >> That would of course be taking advantage of one of the features of >> EBML. Sounds >> good to me. > > > OK, I'll do that tonight. IMO we should "forget" the old one. So that > such elements written in files will never be taken into consideration... > We're freezing the specs for this kind of reasons. Everything before the > freeze can be considered as beta (and not fully stable). But once it's > freezed it will never move (out). The ID is now [53][78] instead of [53][87]. The other is not part of the specs anymore and should not be used in the future. From chris at matroska.org Mon Jan 5 21:41:28 2004 From: chris at matroska.org (Christian HJ Wiesner) Date: Mon, 05 Jan 2004 21:41:28 +0100 Subject: [Matroska-devel] Re: CueBlockNumber In-Reply-To: <3FF9C1A5.1080700@free.fr> References: <3FF88C85.3070200@free.fr> <035a01c3d311$d9cbe930$0100a8c0@i2400p4> <3FF92280.2050900@free.fr> <3FF9C1A5.1080700@free.fr> Message-ID: <3FF9CBF8.6000002@matroska.org> Steve Lhomme wrote: > The ID is now [53][78] instead of [53][87]. The other is not part of > the specs anymore and should not be used in the future. Sorry if i am talking rubbish, but do i understand correctly that this will make some files created with matroskamuxer spec incompliant in future ? if so, i dont like it. Christian From alexander.noe at s2001.tu-chemnitz.de Mon Jan 5 21:55:55 2004 From: alexander.noe at s2001.tu-chemnitz.de (=?ISO-8859-1?Q?Alexander_No=E9?=) Date: Mon, 05 Jan 2004 21:55:55 +0100 Subject: [Matroska-devel] Re: CueBlockNumber In-Reply-To: <3FF9CBF8.6000002@matroska.org> References: <3FF88C85.3070200@free.fr> <035a01c3d311$d9cbe930$0100a8c0@i2400p4> <3FF92280.2050900@free.fr> <3FF9C1A5.1080700@free.fr> <3FF9CBF8.6000002@matroska.org> Message-ID: <3FF9CF5B.1020102@hrz.tu-chemnitz.de> Christian HJ Wiesner wrote: > Steve Lhomme wrote: > >> The ID is now [53][78] instead of [53][87]. The other is not part of >> the specs anymore and should not be used in the future. > > > Sorry if i am talking rubbish, but do i understand correctly that this > will make some files created with matroskamuxer spec incompliant in > future ? if so, i dont like it. Files written with Gabest's "old" muxer will contain elements that readers will ignore. Alex From steve.lhomme at free.fr Mon Jan 5 22:21:55 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Mon, 05 Jan 2004 22:21:55 +0100 Subject: [Matroska-devel] Re: CueBlockNumber In-Reply-To: <3FF9CF5B.1020102@hrz.tu-chemnitz.de> References: <3FF88C85.3070200@free.fr> <035a01c3d311$d9cbe930$0100a8c0@i2400p4> <3FF92280.2050900@free.fr> <3FF9C1A5.1080700@free.fr> <3FF9CBF8.6000002@matroska.org> <3FF9CF5B.1020102@hrz.tu-chemnitz.de> Message-ID: <3FF9D573.9010707@free.fr> Alexander No? wrote: > Christian HJ Wiesner wrote: > >> Steve Lhomme wrote: >> >>> The ID is now [53][78] instead of [53][87]. The other is not part of >>> the specs anymore and should not be used in the future. >> >> >> >> Sorry if i am talking rubbish, but do i understand correctly that this >> will make some files created with matroskamuxer spec incompliant in >> future ? if so, i dont like it. > > > Files written with Gabest's "old" muxer will contain elements that > readers will ignore. Yes, simply ignored and that has never had been used for playback. Just written. You could write a lot of garbage in a Matroska file and it would still be spec compliant, the rest is ignored. From paul at msn.com Tue Jan 6 01:48:03 2004 From: paul at msn.com (Paul Bryson) Date: Mon, 5 Jan 2004 18:48:03 -0600 Subject: [Matroska-devel] Re: And another time : native replay gain elementusage in matroska track headers ? References: <3FF9924D.7@matroska.org> <3FF9A375.6070006@free.fr> Message-ID: "Steve Lhomme" wrote... > Christian HJ Wiesner wrote: > > Are any tools making use of the replaygain element already ? I read this > > here, and just thought to myself the poor guy needs matroska ;-) : > > http://www.hydrogenaudio.org/index.php?showtopic=16794&hl= > > There's no such tool for Matroska yet. And the guy mentioned MPC too, > which is not in Matroska yet :'( > Anyway for my DJing project I will support MKA and ReplayGain, and > probably will have a tool to compute/store it. It should be a simple matter to store the necessary ReplayGain information in the Tags allowing it to be used for any combination of Tracks or Chapters. Really, I am not sure why it is not stored there now in fb2k. Perhaps Jory could inform us? Pamel From chris at matroska.org Tue Jan 6 18:07:45 2004 From: chris at matroska.org (Christian HJ Wiesner) Date: Tue, 06 Jan 2004 18:07:45 +0100 Subject: [Matroska-devel] Timestamp precision in matroska files Message-ID: <3FFAEB61.4060208@matroska.org> Hi, here an interesting log from #foobar2000 : -------------------------------------------------------------------------------------------------------------- DEATH : are you here ? yes DEATH : there is an alpha muxer to write MKA files with factor 10 higher time resolution 100 ?s not enough ^^ would this help ? it would not still inaccurate what resolution would you need ? and i havent tried jcsston's new muxer, blah gonna do it now needs to be greater than samplerate or equal to samplerate samplerate or way higher more like what Case said must be enough to point any sample with time values 1 / 44100 = 22 ?s ? 1 / 48000 = 20 ?s ? Hmm .... so even 10 ?s would help much, right ? you need 1 ?s ? wouldnt or is 10 ?s ok ? is not for high rates 10 looks like it could be enough for 48000hz that is how about just making it equal to samplerate ? Case : 96 KHz is quite unlikely to be lossy compressed ? no it isn't think dvd audio perfect for lossy compression, no one will miss > 22kHz ssamadhi97 : if its PCM 96 Khz, it wont be a problem matroska container can have a resolution of 1 ns BUT the maximum length for a cluster is then limited and this will have huge impact on overhead, especially for low bitrate lossy compression * how is that mp4 doesnt have this issue ? :B* for high bitrate lossless or PCM, the overhead would be acceptable lets see.. because it stores only frame durations and compresses them because they are repetitive ? RLE ist god ^_^ would probably puke on vorbis then again, noone wants vorbis in mp4 then again, noone wants vorbis that too ChrisHJW: that inaccuracy in matroska must cause sync problems with video and audio and make inaccurate video seeking also impossible not with +-1ms inaccuracy i wonder what kind of sound lag console/whatever emulators have Case : you wont notice a lag between video and audio of 1 ms that's still unacceptable Case: emulators probably have 30ms+ sound lag, and people still dont notice that even 100 ms are hard to distinguish until i tried to play vagrant story on ePSXe after playing it to death on real console all my chained attacks were screwed because they relied on sound you see there is something wrong, but you cant say if its too early or too late haha * I remember how matroska was advertised as great for video editing because of accurate seeking and such. if it isn't accurate and time codes people see are pulled from ass it's unusable* -------------------------------------------------------------------------------------------------------------------------------------------------- Any comments on this ? I dont have enough knowledge about why it was designed this way to reply accordingly. Christian -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.noe at s2001.tu-chemnitz.de Tue Jan 6 18:36:05 2004 From: alexander.noe at s2001.tu-chemnitz.de (=?ISO-8859-1?Q?Alexander_No=E9?=) Date: Tue, 06 Jan 2004 18:36:05 +0100 Subject: [Matroska-devel] Timestamp precision in matroska files In-Reply-To: <3FFAEB61.4060208@matroska.org> References: <3FFAEB61.4060208@matroska.org> Message-ID: <3FFAF205.6090504@hrz.tu-chemnitz.de> Christian HJ Wiesner wrote: > > Hi, > > here an interesting log from #foobar2000 : > -------------------------------------------------------------------------------------------------------------- > DEATH : are you here ? > yes > DEATH : there is an alpha muxer to write MKA files with > factor 10 higher time resolution > 100 ?s > not enough The scale can be adjusted by will. > or is 10 ?s ok ? > is not for high rates Then we need a new block type, with more than 16 bits for the timecode. Alex From jcsston at wiesneronline.net Tue Jan 6 20:04:30 2004 From: jcsston at wiesneronline.net (Jory) Date: Tue, 6 Jan 2004 13:04:30 -0600 Subject: [Matroska-devel] Timestamp precision in matroska files References: <3FFAEB61.4060208@matroska.org> Message-ID: <002001c3d488$08f01b60$0200a8c0@jcsston> :sigh: I've said this many times, the muxer I'm working on will FIX sample accuarte seeking by using the sample rate as the timecode scale. It's buggy right now and I'm trying to work on it as fast as I can Later, Jory ----- Original Message ----- From: Christian HJ Wiesner To: Discussion about the current and future development of Matroska Sent: Tuesday, January 06, 2004 11:07 AM Subject: [Matroska-devel] Timestamp precision in matroska files Hi, here an interesting log from #foobar2000 : -------------------------------------------------------------------------------------------------------------- DEATH : are you here ? yes DEATH : there is an alpha muxer to write MKA files with factor 10 higher time resolution 100 ?s not enough ^^ would this help ? it would not still inaccurate what resolution would you need ? and i havent tried jcsston's new muxer, blah gonna do it now needs to be greater than samplerate or equal to samplerate samplerate or way higher more like what Case said must be enough to point any sample with time values 1 / 44100 = 22 ?s ? 1 / 48000 = 20 ?s ? Hmm .... so even 10 ?s would help much, right ? you need 1 ?s ? wouldnt or is 10 ?s ok ? is not for high rates 10 looks like it could be enough for 48000hz that is how about just making it equal to samplerate ? Case : 96 KHz is quite unlikely to be lossy compressed ? no it isn't think dvd audio perfect for lossy compression, no one will miss > 22kHz ssamadhi97 : if its PCM 96 Khz, it wont be a problem matroska container can have a resolution of 1 ns BUT the maximum length for a cluster is then limited and this will have huge impact on overhead, especially for low bitrate lossy compression how is that mp4 doesnt have this issue ? :B for high bitrate lossless or PCM, the overhead would be acceptable lets see.. because it stores only frame durations and compresses them because they are repetitive ? RLE ist god ^_^ would probably puke on vorbis then again, noone wants vorbis in mp4 then again, noone wants vorbis that too ChrisHJW: that inaccuracy in matroska must cause sync problems with video and audio and make inaccurate video seeking also impossible not with +-1ms inaccuracy i wonder what kind of sound lag console/whatever emulators have Case : you wont notice a lag between video and audio of 1 ms that's still unacceptable Case: emulators probably have 30ms+ sound lag, and people still dont notice that even 100 ms are hard to distinguish until i tried to play vagrant story on ePSXe after playing it to death on real console all my chained attacks were screwed because they relied on sound you see there is something wrong, but you cant say if its too early or too late haha I remember how matroska was advertised as great for video editing because of accurate seeking and such. if it isn't accurate and time codes people see are pulled from ass it's unusable -------------------------------------------------------------------------------------------------------------------------------------------------- Any comments on this ? I dont have enough knowledge about why it was designed this way to reply accordingly. Christian ------------------------------------------------------------------------------ _______________________________________________ Matroska-devel mailing list Matroska-devel at lists.matroska.org http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve.lhomme at free.fr Tue Jan 6 20:17:14 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Tue, 06 Jan 2004 20:17:14 +0100 Subject: [Matroska-devel] Timestamp precision in matroska files In-Reply-To: <3FFAF205.6090504@hrz.tu-chemnitz.de> References: <3FFAEB61.4060208@matroska.org> <3FFAF205.6090504@hrz.tu-chemnitz.de> Message-ID: <3FFB09BA.4020408@free.fr> Alexander No? wrote: > Christian HJ Wiesner wrote: > >> >> Hi, >> >> here an interesting log from #foobar2000 : >> -------------------------------------------------------------------------------------------------------------- >> >> DEATH : are you here ? >> yes >> DEATH : there is an alpha muxer to write MKA files with >> factor 10 higher time resolution >> 100 ?s >> not enough > > > The scale can be adjusted by will. > >> or is 10 ?s ok ? >> is not for high rates > > > Then we need a new block type, with more than 16 bits for the timecode. What about the same Block using a new attached (in BlockMore) containing the number of samples since the beggining ? A la Granule Pos. This could apply to video for the number of frames too. That's backward compatible and add a neat feature. From alexander.noe at s2001.tu-chemnitz.de Tue Jan 6 20:21:16 2004 From: alexander.noe at s2001.tu-chemnitz.de (=?ISO-8859-1?Q?Alexander_No=E9?=) Date: Tue, 06 Jan 2004 20:21:16 +0100 Subject: [Matroska-devel] Timestamp precision in matroska files In-Reply-To: <3FFB09BA.4020408@free.fr> References: <3FFAEB61.4060208@matroska.org> <3FFAF205.6090504@hrz.tu-chemnitz.de> <3FFB09BA.4020408@free.fr> Message-ID: <3FFB0AAC.4090809@hrz.tu-chemnitz.de> Steve Lhomme wrote: > Alexander No? wrote: > >> Christian HJ Wiesner wrote: >> >>> >>> Hi, >>> >>> here an interesting log from #foobar2000 : >>> -------------------------------------------------------------------------------------------------------------- >>> DEATH : are you here ? >>> yes >>> DEATH : there is an alpha muxer to write MKA files with >>> factor 10 higher time resolution >>> 100 ?s >>> not enough >> >> >> >> The scale can be adjusted by will. >> >>> or is 10 ?s ok ? >>> is not for high rates >> >> >> >> Then we need a new block type, with more than 16 bits for the timecode. > > > What about the same Block using a new attached (in BlockMore) > containing the number of samples since the beggining ? A la Granule Pos. > This could apply to video for the number of frames too. That does not fix the overhead, caused by one frame per cluster....using 1 ns granularity and 32 bit block timecodes is imho easier. Alex From steve.lhomme at free.fr Tue Jan 6 20:27:31 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Tue, 06 Jan 2004 20:27:31 +0100 Subject: [Matroska-devel] Timestamp precision in matroska files In-Reply-To: <3FFB0AAC.4090809@hrz.tu-chemnitz.de> References: <3FFAEB61.4060208@matroska.org> <3FFAF205.6090504@hrz.tu-chemnitz.de> <3FFB09BA.4020408@free.fr> <3FFB0AAC.4090809@hrz.tu-chemnitz.de> Message-ID: <3FFB0C23.6050206@free.fr> Alexander No? wrote: >> What about the same Block using a new attached (in BlockMore) >> containing the number of samples since the beggining ? A la Granule Pos. >> This could apply to video for the number of frames too. > > > That does not fix the overhead, caused by one frame per cluster....using > 1 ns granularity and 32 bit block timecodes > is imho easier. Mmm. What is the use for such a granularity ? Other than sample accurate seeking ? Which can be solved with the element I propose. And actually that's a feature we're probably missing. From steve.lhomme at free.fr Tue Jan 6 21:41:45 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Tue, 06 Jan 2004 21:41:45 +0100 Subject: [Matroska-devel] New elements Message-ID: <3FFB1D89.7080304@free.fr> Hi, As it was requested, it would be nice to have sample-accurate seeking in Matroska (for audio-only files). Therefore I added 2 elements to support that in the specs (as well as version 1 of the specs). SampleScale is a scale factor for the BlockSamples element BlockSamples is the actual count of samples since the beggining (timecode 0), but this value is scaled : SampleScale * BlockSamples = actual number of samples since timecode 0. I'm going to add support for this in libmatroska right now. From alexander.noe at s2001.tu-chemnitz.de Tue Jan 6 21:46:40 2004 From: alexander.noe at s2001.tu-chemnitz.de (=?ISO-8859-1?Q?Alexander_No=E9?=) Date: Tue, 06 Jan 2004 21:46:40 +0100 Subject: [Matroska-devel] New elements In-Reply-To: <3FFB1D89.7080304@free.fr> References: <3FFB1D89.7080304@free.fr> Message-ID: <3FFB1EB0.5080807@hrz.tu-chemnitz.de> Steve Lhomme wrote: > > SampleScale * BlockSamples = actual number of samples since timecode 0. What if a file does not start at 0, but ealier? Alex From steve.lhomme at free.fr Tue Jan 6 21:54:27 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Tue, 06 Jan 2004 21:54:27 +0100 Subject: [Matroska-devel] New elements In-Reply-To: <3FFB1EB0.5080807@hrz.tu-chemnitz.de> References: <3FFB1D89.7080304@free.fr> <3FFB1EB0.5080807@hrz.tu-chemnitz.de> Message-ID: <3FFB2083.10806@free.fr> Alexander No? wrote: > Steve Lhomme wrote: > >> >> SampleScale * BlockSamples = actual number of samples since timecode 0. > > > What if a file does not start at 0, but ealier? You add enough samples to the first timecode to match the timecode... From pfk at fuchs.offl.uni-jena.de Wed Jan 7 01:57:40 2004 From: pfk at fuchs.offl.uni-jena.de (Frank Klemm) Date: Wed, 7 Jan 2004 01:57:40 +0100 Subject: =[SPAM?]= Re: [Matroska-devel] Timestamp precision in matroska files In-Reply-To: <3FFB09BA.4020408@free.fr>; from steve.lhomme@free.fr on Tue, Jan 06, 2004 at 08:17:14PM +0100 References: <3FFAEB61.4060208@matroska.org> <3FFAF205.6090504@hrz.tu-chemnitz.de> <3FFB09BA.4020408@free.fr> Message-ID: <20040107015740.A4136@fuchs.offl.uni-jena.de> On Tue, Jan 06, 2004 at 08:17:14PM +0100, Steve Lhomme wrote: > > >> > >> DEATH : are you here ? > >> yes > >> DEATH : there is an alpha muxer to write MKA files with > >> factor 10 higher time resolution > >> 100 ?s > >> not enough > > > > > > The scale can be adjusted by will. > > > >> or is 10 ?s ok ? > >> is not for high rates > > > > > > Then we need a new block type, with more than 16 bits for the timecode. > > What about the same Block using a new attached (in BlockMore) containing > the number of samples since the beggining ? A la Granule Pos. > This could apply to video for the number of frames too. > > That's backward compatible and add a neat feature. > What about A/V material with changing frame rates (mixed CCIR, FCC/IAC and cinema material) ??? Current medias are in a format, where the source format is converted to the frame rate of your region (i.e. 50 or 60 frames per seconds). When the diplay convert this rate again, it is done twice, not nice for quality. Also most convertings are really low quality. Better would be when all material can be mixed in a file, the decoder + display render engine translates the signal into the needs of the display. This re-rendering ist done for - horizontal pixels for displays with a horizontal discrete structure (LCDs, LEDs, DLPs) - vertical lines for displays with a vertical discrete structure (all electronic displays) - in the time domain (for all displays with flicker reduction and more complex computation of intermediate images) Also note that the interlacing can be changed inside a stream. You can have a DVD with a non-interlaced movie and the final credits are interlaced. It is even possible that regions of a single frame are interlaced and other not! Audio Time Code: - Low Res (normally exact enough for sample exact cuttering): 48000 ticks/sec - High Res (enough for nearly all): 192000 ticks/sec Video Time Code: - Low Res (normally exact enough for sample exact cuttering): 300 ticks/sec - High Res (enough for nearly all): 1200 ticks/sec Combined Audio/Video Time Code: - Low Res (normally exact enough for sample exact cuttering): 48000 ticks/sec - High Res (enough for nearly all): 192000 ticks/sec Note: - You also must define exact rounding rules for sample precise cuttering (otherwise you have problems even with 192 kHz Time Code when using audio with 44100 Hz). - It should be defined how to handle FCC/IAC "nice" rate of 59.94005232862375719518... Hz a) exact 60 Hz, don't care about the 0.1% error (which was intended to reduce interference between color and audio carrier in radio transmissions) b) 59.94 Hz (ca. 0,9 ppm error) c) 2863636 / 47775 Hz (exact theoretical value) -- Frank Klemm From paul at msn.com Wed Jan 7 03:26:09 2004 From: paul at msn.com (Paul Bryson) Date: Tue, 6 Jan 2004 20:26:09 -0600 Subject: [Matroska-devel] Re: New elements References: <3FFB1D89.7080304@free.fr> Message-ID: "Steve Lhomme" wrote... > As it was requested, it would be nice to have sample-accurate seeking in > Matroska (for audio-only files). Therefore I added 2 elements to support > that in the specs (as well as version 1 of the specs). > > SampleScale is a scale factor for the BlockSamples element > BlockSamples is the actual count of samples since the beggining > (timecode 0), but this value is scaled : That is useless. Didn't anyone notice that Jory already fixed this? Pamel From paul at msn.com Wed Jan 7 04:39:41 2004 From: paul at msn.com (Paul Bryson) Date: Tue, 6 Jan 2004 21:39:41 -0600 Subject: [Matroska-devel] Re: Timestamp precision in matroska files References: <3FFAEB61.4060208@matroska.org> Message-ID: must be enough to point any sample with time values 1 / 44100 = 22 ?s ? 1 / 48000 = 20 ?s ? Hmm .... so even 10 ?s would help much, right ? you need 1 ?s ? wouldnt or is 10 ?s ok ? is not for high rates 10 looks like it could be enough for 48000hz that is how about just making it equal to samplerate ? Case : 96 KHz is quite unlikely to be lossy compressed ? no it isn't think dvd audio For 96KHz audio (96,000 samples/second), a single sample lasts 10,417ns. So, for sample accurate seeking you could set the time TimecodeScale to 10,417ns, giving you an accuracy of within 1ns for a single sample. The default is 1,000,000ns, or 1ms. This would decrease the maximum possible cluster size from 64 seconds to .64 seconds. The overhead would probably balloon quite a bit. If a Block were created that used 32bit timecodes, you could have much larger clusters again, but you would have to deal with an extra byte for every Block2. Even with lacing, this would probably still be to much overhead. If you find it to be such a big concern, then set the TimecodeScale to 104,167ns and you will have 10 sample accuracy on the timecodes. The clusters could still only be a max size of about 6.4 seconds, but that is much better the 0.64. Also, even a Vorbis sample only has a minimum size of 64 samples, meaning that you could never be off by even 1/6th of a packet. Honestly this whole discussion is pretty idiotic since on the absolute highest consumer audio samplerate available (96KHz), and using the default 1ms TimecodeScale, you could only be off a maximum of about 99 samples, WHILE SEEKING. 99 samples! Less than a millisecond! Most likely around half a millisecond. And that is with 96KHz! ChrisHJW: that inaccuracy in matroska must cause sync problems with video and audio and make inaccurate video seeking also impossible not with +-1ms inaccuracy i wonder what kind of sound lag console/whatever emulators have Case : you wont notice a lag between video and audio of 1 ms that's still unacceptable Case: emulators probably have 30ms+ sound lag, and people still dont notice that even 100 ms are hard to distinguish Exactly. Most people can't tell 100ms off. 30ms is pretty much impossible.1ms IS impossible. But even if it weren't impossible to tell 1ms, the format is designed allow greater accurracy. Please stop the insanity that is shown in the rest of this thread. There is no need to add such awful hacks to Matroska. Just use what you already have. Pamel From paul at msn.com Wed Jan 7 04:58:51 2004 From: paul at msn.com (Paul Bryson) Date: Tue, 6 Jan 2004 21:58:51 -0600 Subject: [Matroska-devel] Re: Timestamp precision in matroska files References: <3FFAEB61.4060208@matroska.org> Message-ID: "Paul Bryson" wrote... > Honestly this whole discussion is pretty idiotic since on the absolute highest > consumer audio samplerate available (96KHz) Excuse me, DVD-A allows 2 channel 24-bit 192kHz audio. I don't know of any other sources, at this rate, that you could obtain that you didn't make yourself. If you made it yourself, then the you are surely using lossless compression and 0.6 seconds per cluster is not going to be significant enough to you to matter. Please double or half the numbers for 192kHz audio. Pamel From paul at msn.com Wed Jan 7 08:07:32 2004 From: paul at msn.com (Paul Bryson) Date: Wed, 7 Jan 2004 01:07:32 -0600 Subject: [Matroska-devel] Re: Timestamp precision in matroska files References: <3FFAEB61.4060208@matroska.org> Message-ID: I just realized that this is really easy for any audio format that doesn't have a variable number of samples/packet. (Anything other than Vorbis) (1/(number of samples per packet))*1000000000 For MP3 this would be: (1/1152)*1000000000 or 868055.5555 So, round the number and set TimecodeScale to 868055 This should allow for sample accurate seeking and shouldn't be much less efficient than using 1ms. Pamel From steve.lhomme at free.fr Wed Jan 7 09:42:20 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Wed, 07 Jan 2004 09:42:20 +0100 Subject: [Matroska-devel] Re: Timestamp precision in matroska files In-Reply-To: References: <3FFAEB61.4060208@matroska.org> Message-ID: <3FFBC66C.2090908@free.fr> Paul Bryson wrote: > I just realized that this is really easy for any audio format that doesn't have > a variable number of samples/packet. (Anything other than Vorbis) > > (1/(number of samples per packet))*1000000000 > > For MP3 this would be: > > (1/1152)*1000000000 > > or > > 868055.5555 > > So, round the number and set TimecodeScale to > > 868055 > > This should allow for sample accurate seeking and shouldn't be much less > efficient than using 1ms. I don't know what this calculus is about. But look at yesterday's channel log. I explained why it's impossible to have such accuracy the way it is done now. BTW, rounding is just what proves that it's impossible. That's just an approximation, as everything else. You also forget to mention that sample accurate seeking means that you know which sample you're looking for in the frame. Not just the first decoded one. And this is written nowhere. Well that was the case until I introduced new elements ;) I'll see if the Chapters need to be updated too to allow sample accurate seeking. From steve.lhomme at free.fr Wed Jan 7 09:50:04 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Wed, 07 Jan 2004 09:50:04 +0100 Subject: =[SPAM?]= Re: [Matroska-devel] Timestamp precision in matroska files In-Reply-To: <20040107015740.A4136@fuchs.offl.uni-jena.de> References: <3FFAEB61.4060208@matroska.org> <3FFAF205.6090504@hrz.tu-chemnitz.de> <3FFB09BA.4020408@free.fr> <20040107015740.A4136@fuchs.offl.uni-jena.de> Message-ID: <3FFBC83C.1050201@free.fr> Frank Klemm wrote: >>>Then we need a new block type, with more than 16 bits for the timecode. >> >>What about the same Block using a new attached (in BlockMore) containing >>the number of samples since the beggining ? A la Granule Pos. >>This could apply to video for the number of frames too. >> >>That's backward compatible and add a neat feature. >> > > What about A/V material with changing frame rates (mixed CCIR, FCC/IAC and > cinema material) ??? Is that possible with audio ? Anyway audio will always be in samples (for still a long time). So counting samples is the only really accurate way to know where you are. I didn't introduce the frame count feature for video because of VFR material. And most of the time 1 frame = 1 block. So seeking is frame accurate in this case. > Better would be when all material can be mixed in a file, the decoder + > display render engine translates the signal into the needs of the display. Well, actually you have have a 25fps movie stored with the sound for the 30fps version of the movie. There is a scale factor to adjust the 2 (or more) together (based on the sound). I dunno if that's the problem you mentioned. > Note: > > - You also must define exact rounding rules for sample precise cuttering > (otherwise you have problems even with 192 kHz Time Code when using audio > with 44100 Hz). No rounding. As I said we count samples. (with a scale factor to reduce the size of the counter when possible) For "high precision" matroska files (most probably audio-only files) this counter should be present in the file. > - It should be defined how to handle FCC/IAC "nice" rate of > 59.94005232862375719518... Hz > > a) exact 60 Hz, don't care about the 0.1% error (which was intended to > reduce interference between color and audio carrier in radio transmissions) > b) 59.94 Hz (ca. 0,9 ppm error) > c) 2863636 / 47775 Hz (exact theoretical value) You can adjust the timecode scale of the track to avoid rounding errors as much as possible depending on your source material. Of course, it will never be perfect, but very close. From chris at matroska.org Wed Jan 7 12:09:19 2004 From: chris at matroska.org (Christian HJ Wiesner) Date: Wed, 07 Jan 2004 12:09:19 +0100 Subject: [Matroska-devel] New elements In-Reply-To: <3FFB1D89.7080304@free.fr> References: <3FFB1D89.7080304@free.fr> Message-ID: <3FFBE8DF.7050408@matroska.org> Steve Lhomme wrote: > Hi, > As it was requested, it would be nice to have sample-accurate seeking > in Matroska (for audio-only files). Therefore I added 2 elements to > support that in the specs (as well as version 1 of the specs). > SampleScale is a scale factor for the BlockSamples element > BlockSamples is the actual count of samples since the beggining > (timecode 0), but this value is scaled : > SampleScale * BlockSamples = actual number of samples since timecode 0. > I'm going to add support for this in libmatroska right now. Not so quickly please Steve ! Its ESSENTIAL that we are 100% sure about what we are doing here. Have we thought about : - inaccurate sampling rates, like 44055 Hz, as caused by inferior soundcards doing live recordings ? For the time being, many analog capture fans convert from AVI/MPEG to matroska, because our container will keep sync in any case, while the sample rate based containers fail very often on keeping sync for analog capturing, especially with bad soundcards - if a player, say its foobar2000, wants to do gapless playback of multiple MKA tracks in its playlist, and the file it has to play was made with VirtualdubMod or the matroska muxer on DirectShow for example, we cant have that because your new elements are not supported in the old files. Thats sucks ! In short, there will be some files that play gapless, some wont. And as our specs will *always* allow both ways to make MKA files, the users will never be able to trust that gapless MKA playback works. Have we really investigated *ALL* possibilities to make sample accurate seeking possible with any MKA file, even with a lower timecode accuracy ? What about putting some intelligence into the players here ? - if you are using special timecode scaling for every single track in a matroska file, depending on its sampling rate, and lets say the file has 5 or more tracks, wont it be pretty complicated and CPU intensive to parse these matroska files ? Dont forget, our matroska splitter will expose all audio streams on DirectShow, and its up to the player/switcher to select one of them, but still *ALL* tracks are parsed in the parser filter. - accurate video editing with PCM sound might require to cut *exactly* the right PCM sample at the end of a video frame. If both tracks have the same timescale, thats no problem at all. If you start using different scales for each track, things might get complicated. You might find yourself in a situation where a specific PCM sample is added to both halfs of the splitted movie, and when these parts are concatenated again you are loosing sync ( ok, its only one sample ) because of the repeated sample. Please, lets not hurry this ..... we have to find a good solution, with respect to all existing aspects of the problem Christian From steve.lhomme at free.fr Wed Jan 7 13:25:18 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Wed, 07 Jan 2004 13:25:18 +0100 Subject: [Matroska-devel] New elements In-Reply-To: <3FFBE8DF.7050408@matroska.org> References: <3FFB1D89.7080304@free.fr> <3FFBE8DF.7050408@matroska.org> Message-ID: <3FFBFAAE.3090601@free.fr> Christian HJ Wiesner wrote: > Its ESSENTIAL that we are 100% sure about what we are doing here. Have > we thought about : > > - inaccurate sampling rates, like 44055 Hz, as caused by inferior > soundcards doing live recordings ? For the time being, many analog > capture fans convert from AVI/MPEG to matroska, because our container > will keep sync in any case, while the sample rate based containers fail > very often on keeping sync for analog capturing, especially with bad > soundcards I agree there is a problem if the number of samples doesn't meet the timecode*sampling freq. But there will be a playback problem in this case anyway. And this problem will only exist for "live" recordings where the timestamp is taken from the general clock and the sample count computed on the fly. Maybe this sample count should not be written in the case of "live" recordings ? Because for offline computing, the timecode should be computed from sample count / sampling freq. This is always the case when muxing data from external audio files. > - if a player, say its foobar2000, wants to do gapless playback of > multiple MKA tracks in its playlist, and the file it has to play was > made with VirtualdubMod or the matroska muxer on DirectShow for example, > we cant have that because your new elements are not supported in the old > files. Thats sucks ! In short, there will be some files that play > gapless, some wont. And as our specs will *always* allow both ways to > make MKA files, the users will never be able to trust that gapless MKA > playback works. Well, as Matroska was yesterday, it can't ensure gapless playback. At least the way it's done in foobar2k. Ie jump to a specific location in the file when the previous part is done. So it's not a question wether old tools don't support this. They never did. They need to be updated if they want to support gapless playback. > Have we really investigated *ALL* possibilities to make sample accurate > seeking possible with any MKA file, even with a lower timecode accuracy > ? What about putting some intelligence into the players here ? The sample count *is* the absolute truth for sample accurate handling. As said before all the data we have now in Matroska are not enough. That's why we needed more. And I think we need more in Cues too. > - if you are using special timecode scaling for every single track in a > matroska file, depending on its sampling rate, and lets say the file has > 5 or more tracks, wont it be pretty complicated and CPU intensive to > parse these matroska files ? Dont forget, our matroska splitter will > expose all audio streams on DirectShow, and its up to the > player/switcher to select one of them, but still *ALL* tracks are parsed > in the parser filter. There should be no problem. The muxed files should be muxed as if all data had the same "final" clock. So there won't be a parsing problem when keeping things in sync. And on playback the timecode is recomputed all the time from the scales. That's already handled (or should be). There's no problem here. > - accurate video editing with PCM sound might require to cut *exactly* > the right PCM sample at the end of a video frame. If both tracks have > the same timescale, thats no problem at all. If you start using > different scales for each track, things might get complicated. You might > find yourself in a situation where a specific PCM sample is added to > both halfs of the splitted movie, and when these parts are concatenated > again you are loosing sync ( ok, its only one sample ) because of the > repeated sample. Actually there's not much problems with PCM, if it is treated as such (you know how to cut inside a frame). But IMO that's a bit too much asking for such a precision. Because in the end you don't know it the timecode of the video is precise or not. So asking for the PCM to be more accurate than its reference is stupid. There *is* a problem with audio-only files. If you want to cut this file from sample X to sample Y, you can't. Because the sample X can be inside a frame, as well as sample Y can be the first sample of another frame. (like MP3, AAC or Vorbis frames). If you want to do that losslessly (no reencoding) you need to keep the frame containing sample X, sample Y and all frames in between. And in the resulting file you need to be able to say that the frame with X should start playback at offset XX and that the frame with Y should stop playback at offset YY (in the frame). That means what I added yesterday is just half of it... It's just the sample counter for the first sample of the (first) frame. But there should also be somewhere the start and stop sample counts. Each with a default value to 0 and "max" respectively. IMO that should be combined with the TimeSlice. From chris at matroska.org Wed Jan 7 13:59:57 2004 From: chris at matroska.org (Christian HJ Wiesner) Date: Wed, 07 Jan 2004 13:59:57 +0100 Subject: [Matroska-devel] Wavpack4 integration into MKA Message-ID: <3FFC02CD.2030300@matroska.org> Hi guys, read here : http://www.hydrogenaudio.org/index.php?showtopic=15073&st=50&hl= In the long reply from David Bryant, he says : *ChristianHJW*: After we communicated last I created a document describing (in general terms) how the future API would look, and that file is also now included in the alpha package. I believe that this is a more useful picture of the Matroska integration issues than the source code because /there is no API in the source code/. If your devs look over that document and have questions or suggestions then we can go back and forth and they can influence how the API might look. If they still want to see the source after that I can provide something, but it's still kind of a mess and I really don't think they could find anything useful in there. I do want to make sure that I don't do anything that makes Matroska difficult... It seems there is an API described in the last pack, http://www.wavpack.com/alpha2.zip .... anybody has the time to look at it ? Christian -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve.lhomme at free.fr Wed Jan 7 15:33:10 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Wed, 07 Jan 2004 15:33:10 +0100 Subject: [Matroska-devel] mkvmerge sources Message-ID: <3FFC18A6.7030507@free.fr> Hi (Mosu), I'm currently browsing the sources of mkvmerge to see where I could add the new elements (the Chapter ones for now). I found a function called copy_chapters_recursive(). What is the use of it ? Why not simply use the Clone() method of EBML ? Or maybe you want to remove all unknown IDs ? From moritz at bunkus.org Wed Jan 7 18:26:06 2004 From: moritz at bunkus.org (Moritz Bunkus) Date: Wed, 7 Jan 2004 18:26:06 +0100 Subject: [Matroska-devel] mkvmerge sources In-Reply-To: <3FFC18A6.7030507@free.fr> References: <3FFC18A6.7030507@free.fr> Message-ID: <20040107172606.GC30186@bunkus.org> Heya, > I'm currently browsing the sources of mkvmerge to see where I could add > the new elements (the Chapter ones for now). src/common/chapter_parser_xml.cpp, function start_next_level src/common/chapter_writer.cpp, function write_chapter_atom_xml src/mkvinfo.cpp, the big ugly function Please call the XML elements FlagHidden and FlagEnabled. > I found a function called copy_chapters_recursive(). What is the use of > it ? Why not simply use the Clone() method of EBML ? Or maybe you want > to remove all unknown IDs ? No. That function still exists from when there was no Clone() function, and I never got around to removing it. Mosu -- If Darl McBride was in charge, he'd probably make marriage unconstitutional too, since clearly it de-emphasizes the commercial nature of normal human interaction, and probably is a major impediment to the commercial growth of prostitution. - Linus Torvalds From steve.lhomme at free.fr Wed Jan 7 19:37:13 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Wed, 07 Jan 2004 19:37:13 +0100 Subject: [Matroska-devel] Re: New elements In-Reply-To: References: <3FFB1D89.7080304@free.fr> Message-ID: <3FFC51D9.9030203@free.fr> Paul Bryson wrote: > "Steve Lhomme" wrote... > >>As it was requested, it would be nice to have sample-accurate seeking in >>Matroska (for audio-only files). Therefore I added 2 elements to support >>that in the specs (as well as version 1 of the specs). >> >>SampleScale is a scale factor for the BlockSamples element >>BlockSamples is the actual count of samples since the beggining >>(timecode 0), but this value is scaled : > > > That is useless. Didn't anyone notice that Jory already fixed this? Could you provide some background on how you can acheive sample-precise seeking ? From steve.lhomme at free.fr Thu Jan 8 09:51:01 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Thu, 08 Jan 2004 09:51:01 +0100 Subject: [Matroska-devel] Split files Message-ID: <3FFD19F5.900@free.fr> With the spec freezing nearing, there is a feature that is currently supported nowhere in the players : files that has been split in many parts (possible with mkvmerge). AFAIK there is no player that support this feature yet. And that should be done before the spec freezing. Anyone volunteer for TCMP or MPC support ? I guess the VLC guys are still far from supporting many features of Matroska so it's not an option to ask them now. From steve.lhomme at free.fr Thu Jan 8 10:16:47 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Thu, 08 Jan 2004 10:16:47 +0100 Subject: [Matroska-devel] Split files In-Reply-To: <3FFD19F5.900@free.fr> References: <3FFD19F5.900@free.fr> Message-ID: <3FFD1FFF.70801@free.fr> Steve Lhomme wrote: > With the spec freezing nearing, there is a feature that is currently > supported nowhere in the players : files that has been split in many > parts (possible with mkvmerge). AFAIK there is no player that support > this feature yet. And that should be done before the spec freezing. > > Anyone volunteer for TCMP or MPC support ? I guess the VLC guys are > still far from supporting many features of Matroska so it's not an > option to ask them now. BTW, having this working for the 1. announcement could be a nice "new" feature for users. A good reason for everyone to use the latest "validated" code that we'll release. And I'm sure lots of people are waiting for such a feature (not found anywhere else, not even in MP4 AFAIK). From christian at matroska.org Fri Jan 9 00:19:45 2004 From: christian at matroska.org (ChristianHJW) Date: Fri, 09 Jan 2004 00:19:45 +0100 Subject: [Matroska-devel] [Fwd: Re: multiple audio streams] Message-ID: <3FFDE591.7080903@matroska.org> Forwarded from xine-devel ... anybody to clarify ? -------- Original Message -------- Subject: Re: multiple audio streams Date: Wed, 07 Jan 2004 17:36:53 +0000 From: James Stembridge CC: xine-devel On Wed, 07 Jan 2004 18:19:36 +0100, "Thibaut Mattern" said: > ok. > is it ok to send the fragment offset table in a buffer, after the last > fragment and with the FRAME_END flag ? > or do you have a better idea ? Yes I think this is a fine way of doing things. > my only mkv test stream with a RV40 video track contains some fragments > >8k (matrix trailer available on matroska website) Speaking of RV40 you'll see some code in the libreal decoder for skipping certain fragments which was necessary to get certain streams to playback correctly. I wonder if the matroska tools drop these fragments when reading real files. James. From paul at msn.com Fri Jan 9 08:28:48 2004 From: paul at msn.com (Paul Bryson) Date: Fri, 9 Jan 2004 01:28:48 -0600 Subject: [Matroska-devel] Re: Re: Timestamp precision in matroska files References: <3FFAEB61.4060208@matroska.org> <3FFBC66C.2090908@free.fr> Message-ID: "Steve Lhomme" wrote... > I don't know what this calculus is about. But look at yesterday's > channel log. I explained why it's impossible to have such accuracy the > way it is done now. There is no calculus here, just simple mathematics that I learned when I was maybe 10 years old. > BTW, rounding is just what proves that it's impossible. That's just an > approximation, as everything else. Didn't you see my conclusion? You would have to round off numbers that are smaller than the size of a single sample meaning that you are able to accurately seek to a sample. I proved that it was possible, not impossible. > You also forget to mention that sample accurate seeking means that you > know which sample you're looking for in the frame. Not just the first > decoded one. That is the job of the decoder, not the container. The container has no way to pass off a specific sample. The whole chunk must be decoded first, then the decoder passes out audio starting at the necessary point. Pamel From steve.lhomme at free.fr Fri Jan 9 09:39:17 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Fri, 09 Jan 2004 09:39:17 +0100 Subject: [Matroska-devel] Re: Re: Timestamp precision in matroska files In-Reply-To: References: <3FFAEB61.4060208@matroska.org> <3FFBC66C.2090908@free.fr> Message-ID: <3FFE68B5.9060804@free.fr> Paul Bryson wrote: >>BTW, rounding is just what proves that it's impossible. That's just an >>approximation, as everything else. > > > Didn't you see my conclusion? You would have to round off numbers that are > smaller than the size of a single sample meaning that you are able to accurately > seek to a sample. I proved that it was possible, not impossible. OK, rounding of something smaller than a sample is accurate ? 12353.7 samples 12353.2 samples Do you think it refers to the same sample ? >>You also forget to mention that sample accurate seeking means that you >>know which sample you're looking for in the frame. Not just the first >>decoded one. > > > That is the job of the decoder, not the container. The container has no way to > pass off a specific sample. The whole chunk must be decoded first, then the > decoder passes out audio starting at the necessary point. Of course the container doesn't know where is the sample in the frame. But it has to know which sample is the seek (cue) point in that frame. From moritz at bunkus.org Fri Jan 9 09:49:03 2004 From: moritz at bunkus.org (Moritz Bunkus) Date: Fri, 9 Jan 2004 09:49:03 +0100 Subject: [Matroska-devel] Re: Timestamp precision in matroska files In-Reply-To: References: <3FFAEB61.4060208@matroska.org> Message-ID: <20040109084903.GF30186@bunkus.org> Heya, whatever we do, we probably need a new block layout if we want to improve accuracy because the 16bit sint is not very large. There are two proposals how to do that, imho: - use 32bit sint, - use an EBML sint. The former has the advantage of being easy on the parser. Alex proposed to have a flag that says '16bit or 32bit' which would keep the overhead under control - 32bits would only be used if the relative timecode excessed those 15 bits. The latter has the advantage of not being fixed at all. If - for some obscure reason - someone uses a timecode scale of 1 (ns precision) then a 32bit relative timecode only covers approx. 2 seconds in either direction ;) Anyway, we should use a new EBML ID for such a block although libmatroska should somehow make KaxBlock work with it, too (no, i definitely do NOT want a second class for that!). As to if players REALLY need sample accurate seeking I can't say much, I'm not a player developper. Mosu -- If Darl McBride was in charge, he'd probably make marriage unconstitutional too, since clearly it de-emphasizes the commercial nature of normal human interaction, and probably is a major impediment to the commercial growth of prostitution. - Linus Torvalds From steve.lhomme at free.fr Fri Jan 9 10:13:43 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Fri, 09 Jan 2004 10:13:43 +0100 Subject: [Matroska-devel] Re: Timestamp precision in matroska files In-Reply-To: <20040109084903.GF30186@bunkus.org> References: <3FFAEB61.4060208@matroska.org> <20040109084903.GF30186@bunkus.org> Message-ID: <3FFE70C7.1010608@free.fr> Moritz Bunkus wrote: > Heya, > > whatever we do, we probably need a new block layout if we want to > improve accuracy because the 16bit sint is not very large. There are two Well, before we go on further in the discussion, I'd like some cases where it is true that we need a more accurate Block timecode. > proposals how to do that, imho: > > - use 32bit sint, > - use an EBML sint. > > The former has the advantage of being easy on the parser. Alex proposed > to have a flag that says '16bit or 32bit' which would keep the overhead > under control - 32bits would only be used if the relative timecode > excessed those 15 bits. > > The latter has the advantage of not being fixed at all. If - for some > obscure reason - someone uses a timecode scale of 1 (ns precision) then > a 32bit relative timecode only covers approx. 2 seconds in either > direction ;) > > Anyway, we should use a new EBML ID for such a block although > libmatroska should somehow make KaxBlock work with it, too (no, i > definitely do NOT want a second class for that!). We can use a flag in the Block to specify that the size of the timecode is "not as it used to be". We'll have the same compatibility problems that when we introduced new lacing schemes. No need to use a new Block. > As to if players REALLY need sample accurate seeking I can't say much, > I'm not a player developper. I'm a player user. And I want to develop a player too (for DJing). And I want to have sample accurate start/stop. My other friend is a "real" DJ also want this feature badly. So that's at least 2 persons that want this feature from the container... In the digital world we should be allowed to expect digital precision (and any rounding is a *no* for me). For video & subtitles we already have a sample-accurate system (sample == frame) but now we need it for audio too. From moritz at bunkus.org Fri Jan 9 10:33:05 2004 From: moritz at bunkus.org (Moritz Bunkus) Date: Fri, 9 Jan 2004 10:33:05 +0100 Subject: [Matroska-devel] Re: Timestamp precision in matroska files In-Reply-To: <3FFE70C7.1010608@free.fr> References: <3FFAEB61.4060208@matroska.org> <20040109084903.GF30186@bunkus.org> <3FFE70C7.1010608@free.fr> Message-ID: <20040109093304.GG30186@bunkus.org> Heya, > Well, before we go on further in the discussion, I'd like some cases > where it is true that we need a more accurate Block timecode. Huh? You've said it yourself. If you want sample accurate timecodes you'll have to increase accuracy. With the 16bit sint the clusters will become VERY small then because they can only be approx. 64000 scale units big. This means e.g. a bit over a second for 48000 Hz audio if we use the sample rate as the timecode scale. > We can use a flag in the Block to specify that the size of the timecode > is "not as it used to be". We'll have the same compatibility problems > that when we introduced new lacing schemes. No need to use a new > Block. It sucked back then, it'll suck again ;) Anyway, if we're going to do it we should be doing it right. Mosu -- If Darl McBride was in charge, he'd probably make marriage unconstitutional too, since clearly it de-emphasizes the commercial nature of normal human interaction, and probably is a major impediment to the commercial growth of prostitution. - Linus Torvalds From steve.lhomme at free.fr Fri Jan 9 10:44:51 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Fri, 09 Jan 2004 10:44:51 +0100 Subject: [Matroska-devel] Re: Timestamp precision in matroska files In-Reply-To: <20040109093304.GG30186@bunkus.org> References: <3FFAEB61.4060208@matroska.org> <20040109084903.GF30186@bunkus.org> <3FFE70C7.1010608@free.fr> <20040109093304.GG30186@bunkus.org> Message-ID: <3FFE7813.3010309@free.fr> Moritz Bunkus wrote: > Heya, > > >>Well, before we go on further in the discussion, I'd like some cases >>where it is true that we need a more accurate Block timecode. > > > Huh? You've said it yourself. If you want sample accurate timecodes > you'll have to increase accuracy. With the 16bit sint the clusters No I said if we want sample accuracy, we have to find another solution than timecodes. Because they are simply not compatible for this matter. Not in the integer world. Now it seems I find to put a simple example myself : Imagine sample 998 of an audio stream at 44100 kHz. The timecode for this sample is 998/44100 = 22.63038549 ms or 22,630,385.49 ns Now you'll have to explain me how any timecode precision, even of 1ns could be accurate for this sample ! > will become VERY small then because they can only be approx. 64000 > scale units big. This means e.g. a bit over a second for 48000 Hz audio > if we use the sample rate as the timecode scale. As said above, the solution is *not* in timecodes tweaking. >>We can use a flag in the Block to specify that the size of the timecode >>is "not as it used to be". We'll have the same compatibility problems >>that when we introduced new lacing schemes. No need to use a new >>Block. > > > It sucked back then, it'll suck again ;) Anyway, if we're going to do it > we should be doing it right. IMO that's not needed. Not for sample-accurate seeking, at least. -------------------------------------------------------------------------- TrackTimecodeScale is a float, around 1.0. So any timecode right now is a float anyway (so the precision will never be perfect, as a sample count). And the sampling frequency is a float too. So expecting an integer precision from any of these numbers is simply impossible. From chris at matroska.org Fri Jan 9 13:35:43 2004 From: chris at matroska.org (Christian HJ Wiesner) Date: Fri, 09 Jan 2004 13:35:43 +0100 Subject: [Matroska-devel] Re: Timestamp precision in matroska files In-Reply-To: <3FFE7813.3010309@free.fr> References: <3FFAEB61.4060208@matroska.org> <20040109084903.GF30186@bunkus.org> <3FFE70C7.1010608@free.fr> <20040109093304.GG30186@bunkus.org> <3FFE7813.3010309@free.fr> Message-ID: <3FFEA01F.7050801@matroska.org> Steve Lhomme wrote: > Now it seems I find to put a simple example myself : > Imagine sample 998 of an audio stream at 44100 kHz. The timecode for > this sample is 998/44100 = 22.63038549 ms or 22,630,385.49 ns > Now you'll have to explain me how any timecode precision, even of 1ns > could be accurate for this sample ! There is one flaw in this example : The only purpose of the timestamp accuracy is to allow to determine a specific sample in a block by the timestamp attached to the start of the block. 1 / 44100 = 22,6 ?s , means every single sample is 22,6 ?s long , or Ts ( duration of each sample ) = 22,6 ?s So, the minimal required accuracy to determine a specific sample from a timestamp is 1/2 Ts = 11,3 ?s So, if your timestamp is accurate to 10 ?s or less, you can say with 100% certainty what sample you have to load, by using rounding. Remember, we dont need the starting timestamp of this one sample with a precision of 0,5 ns , all we need to know is, if we have a timestamp xxxx , what sample corresponds to it. Christian From steve.lhomme at free.fr Fri Jan 9 14:14:17 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Fri, 09 Jan 2004 14:14:17 +0100 Subject: [Matroska-devel] Re: Timestamp precision in matroska files In-Reply-To: <3FFEA01F.7050801@matroska.org> References: <3FFAEB61.4060208@matroska.org> <20040109084903.GF30186@bunkus.org> <3FFE70C7.1010608@free.fr> <20040109093304.GG30186@bunkus.org> <3FFE7813.3010309@free.fr> <3FFEA01F.7050801@matroska.org> Message-ID: <3FFEA929.70601@free.fr> Christian HJ Wiesner wrote: > Steve Lhomme wrote: > There is one flaw in this example : > > The only purpose of the timestamp accuracy is to allow to determine a > specific sample in a block by the timestamp attached to the start of the > block. > > 1 / 44100 = 22,6 ?s , means every single sample is 22,6 ?s long , or > Ts ( duration of each sample ) = 22,6 ?s > > So, the minimal required accuracy to determine a specific sample from a > timestamp is 1/2 Ts = 11,3 ?s > > So, if your timestamp is accurate to 10 ?s or less, you can say with > 100% certainty what sample you have to load, by using rounding. > Remember, we dont need the starting timestamp of this one sample with a > precision of 0,5 ns , all we need to know is, if we have a timestamp > xxxx , what sample corresponds to it. Ah !!! Finally someone with a real good explanation. You're totally right. There is still the rounding problem. If your timecode scale is 11,338 ns (10^9/(2*44100) = 11,337.868480725623582766439909297) Here is a table corresponding to the Sample #, tick #, reconstituted timecode , real timecode 1 0 0 0 2 2 22,676 22,676 3 4 45,352 45,351 4 6 68,028 68,028 5 8 90,704 90,703 6 10 113,380 113,379 ... 999 2000 22,676,000 22,675,737 1000 2002 22,698,676 22,698,413 1001 2004 22,721,352 22,721,088 You see that there is a difference of 264ns every 1,000 samples. So after 100,000 samples (2.5s) there is 26,400ns or 2 ticks or 1 sample !! You lose the sample accuracy using timecode after just 2s. But hopefully, reality is a bit better. The timecode for an audio track can be expressed in float : TimecodeScale (integer) * TrackTimecodeScale (float) * Timecode So if you have : TimecodeScale = 1,000,000 TrackTimecodeScale = 0,022675736961 Timecode = X And the approximation of the float will hopefully avoid the rounding problem. I'll make a little C program to verify (with C double float) at what "tick" the reconstitued timecode is too different that the real timecode (different by more than half of the duration of a sample). From moritz at bunkus.org Fri Jan 9 14:24:46 2004 From: moritz at bunkus.org (Moritz Bunkus) Date: Fri, 9 Jan 2004 14:24:46 +0100 Subject: [Matroska-devel] Re: Timestamp precision in matroska files In-Reply-To: <3FFEA929.70601@free.fr> References: <3FFAEB61.4060208@matroska.org> <20040109084903.GF30186@bunkus.org> <3FFE70C7.1010608@free.fr> <20040109093304.GG30186@bunkus.org> <3FFE7813.3010309@free.fr> <3FFEA01F.7050801@matroska.org> <3FFEA929.70601@free.fr> Message-ID: <20040109132445.GK30186@bunkus.org> Heya, FLOAT WARNING! If we ever want Matroska to become a reality on hardware devices then using floats everywhere is a big no! Mosu -- If Darl McBride was in charge, he'd probably make marriage unconstitutional too, since clearly it de-emphasizes the commercial nature of normal human interaction, and probably is a major impediment to the commercial growth of prostitution. - Linus Torvalds From steve.lhomme at free.fr Fri Jan 9 15:06:58 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Fri, 09 Jan 2004 15:06:58 +0100 Subject: [Matroska-devel] Re: Timestamp precision in matroska files In-Reply-To: <3FFEA929.70601@free.fr> References: <3FFAEB61.4060208@matroska.org> <20040109084903.GF30186@bunkus.org> <3FFE70C7.1010608@free.fr> <20040109093304.GG30186@bunkus.org> <3FFE7813.3010309@free.fr> <3FFEA01F.7050801@matroska.org> <3FFEA929.70601@free.fr> Message-ID: <3FFEB582.3020103@free.fr> With this sample program I get up to the limit of 32 bits integer without having a timecode problem. And the real timecode is different than the computed timecode only by 1 ns after 3,797,980,000 samples, ie 24h. So as long as the TrackTimecodeScale corresponds to 1/SamplingFreq there should be any problem. At least on machines with a Floating Point Unit. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: main.c URL: From steve.lhomme at free.fr Fri Jan 9 15:09:25 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Fri, 09 Jan 2004 15:09:25 +0100 Subject: [Matroska-devel] Re: Timestamp precision in matroska files In-Reply-To: <3FFEB582.3020103@free.fr> References: <3FFAEB61.4060208@matroska.org> <20040109084903.GF30186@bunkus.org> <3FFE70C7.1010608@free.fr> <20040109093304.GG30186@bunkus.org> <3FFE7813.3010309@free.fr> <3FFEA01F.7050801@matroska.org> <3FFEA929.70601@free.fr> <3FFEB582.3020103@free.fr> Message-ID: <3FFEB615.8060505@free.fr> Steve Lhomme wrote: Poor me... This program can't be accurate. _RealTimecode and _ReconstitutedTimecode should be uint64 as they are very large values (hours expressed in ns). I'll have a deeper look ... > ------------------------------------------------------------------------ > > #include > #include > > #define SamplingFreq 44100.0 > > int main(int argc, char *argv[]) > { > unsigned long Sample = 0; > unsigned int TimecodeScale = 1000000; > double TrackTimecodeScale = 0.022675736961451247165532879818594; > > // timecodes expressed in ns > double RealTimecode, ReconstitutedTimecode; > unsigned long _RealTimecode, _ReconstitutedTimecode; > > while (1) > { > RealTimecode = Sample * 1000000000.0 / SamplingFreq; > ReconstitutedTimecode = TrackTimecodeScale * TimecodeScale * Sample; > Sample+=10000; > _RealTimecode = (unsigned long) RealTimecode; > _ReconstitutedTimecode = (unsigned long) ReconstitutedTimecode; > if (_ReconstitutedTimecode != _RealTimecode) > break; > /* > if (_ReconstitutedTimecode > _RealTimecode && _ReconstitutedTimecode - _RealTimecode >= 11337) > break; > if (_ReconstitutedTimecode < _RealTimecode && _RealTimecode - _ReconstitutedTimecode >= 11337) > break; > */ > if (Sample % 1000000 == 0) > printf("%lu ", Sample); > } > > printf("\nFirst problem at sample %lu (%lu != %lu)\n", Sample, _ReconstitutedTimecode, _RealTimecode); > > system("PAUSE"); > return 0; > } > > > ------------------------------------------------------------------------ From chris at matroska.org Fri Jan 9 16:05:53 2004 From: chris at matroska.org (Christian HJ Wiesner) Date: Fri, 09 Jan 2004 16:05:53 +0100 Subject: [Matroska-devel] Re: Timestamp precision in matroska files In-Reply-To: <20040109132445.GK30186@bunkus.org> References: <3FFAEB61.4060208@matroska.org> <20040109084903.GF30186@bunkus.org> <3FFE70C7.1010608@free.fr> <20040109093304.GG30186@bunkus.org> <3FFE7813.3010309@free.fr> <3FFEA01F.7050801@matroska.org> <3FFEA929.70601@free.fr> <20040109132445.GK30186@bunkus.org> Message-ID: <3FFEC351.5050303@matroska.org> Moritz Bunkus wrote: >Heya, >FLOAT WARNING! If we ever want Matroska to become a reality on hardware >devices then using floats everywhere is a big no! >Mosu > > ACK ....... From rbultje at ronald.bitfreak.net Fri Jan 9 16:25:43 2004 From: rbultje at ronald.bitfreak.net (Ronald Bultje) Date: Fri, 09 Jan 2004 16:25:43 +0100 Subject: [Matroska-devel] Re: Timestamp precision in matroska files In-Reply-To: <3FFEC351.5050303@matroska.org> References: <3FFAEB61.4060208@matroska.org> <20040109084903.GF30186@bunkus.org> <3FFE70C7.1010608@free.fr> <20040109093304.GG30186@bunkus.org> <3FFE7813.3010309@free.fr> <3FFEA01F.7050801@matroska.org> <3FFEA929.70601@free.fr> <20040109132445.GK30186@bunkus.org> <3FFEC351.5050303@matroska.org> Message-ID: <1073661943.15579.226.camel@shrek.bitfreak.net> On Fri, 2004-01-09 at 16:05, Christian HJ Wiesner wrote: > Moritz Bunkus wrote: > >Heya, > >FLOAT WARNING! If we ever want Matroska to become a reality on hardware > >devices then using floats everywhere is a big no! > ACK ....... Eh, samplerate already is a float, so you might be a little late... I do agree, though. Ronald -- Ronald Bultje Linux Video/Multimedia developer From steve.lhomme at free.fr Fri Jan 9 16:20:28 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Fri, 09 Jan 2004 16:20:28 +0100 Subject: [Matroska-devel] Re: Timestamp precision in matroska files In-Reply-To: <3FFEB615.8060505@free.fr> References: <3FFAEB61.4060208@matroska.org> <20040109084903.GF30186@bunkus.org> <3FFE70C7.1010608@free.fr> <20040109093304.GG30186@bunkus.org> <3FFE7813.3010309@free.fr> <3FFEA01F.7050801@matroska.org> <3FFEA929.70601@free.fr> <3FFEB582.3020103@free.fr> <3FFEB615.8060505@free.fr> Message-ID: <3FFEC6BC.8050106@free.fr> The modified version of the program... The difference of timecode is always below 0.5ns for all first 4GB of samples. So there *is* a way to have a correct sample approximation with a good TrackTimecodeScale. About the float problem... This has always been a problem and we already know about it. And there's no big deal as there are some float libraries for integer-only processors. Dunno if their precision will be enough for sample accurate seeking. But well, that may not needed in such limited machines. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: main.c URL: From steve.lhomme at free.fr Fri Jan 9 16:34:13 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Fri, 09 Jan 2004 16:34:13 +0100 Subject: [Matroska-devel] Re: Timestamp precision in matroska files In-Reply-To: <1073661943.15579.226.camel@shrek.bitfreak.net> References: <3FFAEB61.4060208@matroska.org> <20040109084903.GF30186@bunkus.org> <3FFE70C7.1010608@free.fr> <20040109093304.GG30186@bunkus.org> <3FFE7813.3010309@free.fr> <3FFEA01F.7050801@matroska.org> <3FFEA929.70601@free.fr> <20040109132445.GK30186@bunkus.org> <3FFEC351.5050303@matroska.org> <1073661943.15579.226.camel@shrek.bitfreak.net> Message-ID: <3FFEC9F5.8070304@free.fr> Ronald Bultje wrote: > On Fri, 2004-01-09 at 16:05, Christian HJ Wiesner wrote: > >>Moritz Bunkus wrote: >> >>>Heya, >>>FLOAT WARNING! If we ever want Matroska to become a reality on hardware >>>devices then using floats everywhere is a big no! >> >>ACK ....... > > > Eh, samplerate already is a float, so you might be a little late... > > I do agree, though. The sampling rate is not used anywhere else in the format. So it can be computed once and you're done. With a floating point library it's no big deal. The problem is the precision of TrackTimecodeScale. I made the same (successful) test but with float instead of double. And the approximation fails (to estimate the actual timecode of a sample in ns) at the 372nd sample. So the single precision floating point is not enough for sample accurate seeking. But as this timecode complete accuracy will be needed only for seeking (during playback a delay of a few ns is not a big deal). It is only computed in rare cases. So using a third party library for that won't have much performance impact anyway. From paul at msn.com Fri Jan 9 17:00:38 2004 From: paul at msn.com (Paul Bryson) Date: Fri, 9 Jan 2004 10:00:38 -0600 Subject: [Matroska-devel] Re: Re: Re: Timestamp precision in matroska files References: <3FFAEB61.4060208@matroska.org> <3FFBC66C.2090908@free.fr> <3FFE68B5.9060804@free.fr> Message-ID: "Steve Lhomme" wrote... > OK, rounding of something smaller than a sample is accurate ? > 12353.7 samples > 12353.2 samples > Do you think it refers to the same sample ? I don't follow you. The example that I provided would be more accurate than this. It would be something like: 12353.012 samples 12353.000 samples Are these the same sample? Yes. Pamel From alexander.noe at s2001.tu-chemnitz.de Fri Jan 9 17:03:17 2004 From: alexander.noe at s2001.tu-chemnitz.de (=?ISO-8859-1?Q?Alexander_No=E9?=) Date: Fri, 09 Jan 2004 17:03:17 +0100 Subject: [Matroska-devel] Re: Re: Re: Timestamp precision in matroska files In-Reply-To: References: <3FFAEB61.4060208@matroska.org> <3FFBC66C.2090908@free.fr> <3FFE68B5.9060804@free.fr> Message-ID: <3FFED0C5.3060406@hrz.tu-chemnitz.de> Paul Bryson wrote: >"Steve Lhomme" wrote... > > >>OK, rounding of something smaller than a sample is accurate ? >>12353.7 samples >>12353.2 samples >>Do you think it refers to the same sample ? >> >> > >I don't follow you. The example that I provided would be more accurate than >this. It would be something like: >12353.012 samples >12353.000 samples > Not with float arithemtics. The mantissa of a float value is 23 bits + 1 implicit one. Alex From paul at msn.com Fri Jan 9 17:13:36 2004 From: paul at msn.com (Paul Bryson) Date: Fri, 9 Jan 2004 10:13:36 -0600 Subject: [Matroska-devel] Re: Re: Timestamp precision in matroska files References: <3FFAEB61.4060208@matroska.org> <20040109084903.GF30186@bunkus.org> <3FFE70C7.1010608@free.fr> <20040109093304.GG30186@bunkus.org><3FFE7813.3010309@free.fr> <3FFEA01F.7050801@matroska.org> <3FFEA929.70601@free.fr> Message-ID: "Steve Lhomme" wrote... > Christian HJ Wiesner wrote: > > So, if your timestamp is accurate to 10 ?s or less, you can say with > > 100% certainty what sample you have to load, by using rounding. > > Remember, we dont need the starting timestamp of this one sample with a > > precision of 0,5 ns , all we need to know is, if we have a timestamp > > xxxx , what sample corresponds to it. > > Ah !!! Finally someone with a real good explanation. > > You're totally right. I feel like I'm taking crazy pills. Why is Christian the one getting my posts? @Christian: Thanks mate. I was going bonkers trying to get someone to understand what I was saying. Pamel From steve.lhomme at free.fr Fri Jan 9 17:14:44 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Fri, 09 Jan 2004 17:14:44 +0100 Subject: [Matroska-devel] Re: Re: Timestamp precision in matroska files In-Reply-To: References: <3FFAEB61.4060208@matroska.org> <20040109084903.GF30186@bunkus.org> <3FFE70C7.1010608@free.fr> <20040109093304.GG30186@bunkus.org><3FFE7813.3010309@free.fr> <3FFEA01F.7050801@matroska.org> <3FFEA929.70601@free.fr> Message-ID: <3FFED374.9010209@free.fr> Paul Bryson wrote: > "Steve Lhomme" wrote... > >>Christian HJ Wiesner wrote: >> >>>So, if your timestamp is accurate to 10 ?s or less, you can say with >>>100% certainty what sample you have to load, by using rounding. >>>Remember, we dont need the starting timestamp of this one sample with a >>>precision of 0,5 ns , all we need to know is, if we have a timestamp >>>xxxx , what sample corresponds to it. >> >>Ah !!! Finally someone with a real good explanation. >> >>You're totally right. > > > I feel like I'm taking crazy pills. Why is Christian the one getting my posts? > > @Christian: Thanks mate. I was going bonkers trying to get someone to > understand what I was saying. Just a matter of clear explanations. Not just talking numbers... From paul at msn.com Fri Jan 9 17:22:41 2004 From: paul at msn.com (Paul Bryson) Date: Fri, 9 Jan 2004 10:22:41 -0600 Subject: [Matroska-devel] Re: Re: Timestamp precision in matroska files References: <3FFAEB61.4060208@matroska.org> <20040109084903.GF30186@bunkus.org> <3FFE70C7.1010608@free.fr> <20040109093304.GG30186@bunkus.org><3FFE7813.3010309@free.fr> <3FFEA01F.7050801@matroska.org> <3FFEA929.70601@free.fr> Message-ID: "Steve Lhomme" wrote... > You see that there is a difference of 264ns every 1,000 samples. So > after 100,000 samples (2.5s) there is 26,400ns or 2 ticks or 1 sample !! > You lose the sample accuracy using timecode after just 2s. You should be recomputing the timecode for each Block to avoid rounding errors adding up. This way the rounding error will only be a maximum of what is forced by the timecode scale. Pamel From chris at matroska.org Fri Jan 9 21:29:04 2004 From: chris at matroska.org (Christian HJ Wiesner) Date: Fri, 09 Jan 2004 21:29:04 +0100 Subject: [Matroska-devel] Timestamp precision in matroska files] Message-ID: <3FFF0F10.1020905@matroska.org> FYI, in German, but with code ( should be international ;-) ) ... -------- Original Message -------- Subject: Antwort: Re: [Matroska-devel] Re: Timestamp precision in matroska files Date: Fri, 9 Jan 2004 18:40:21 +0100 From: Frank Klemm To: chris at matroska.org Die mindestens ben?tigte Aufl?sung zur samplegenauen Adressierung eines Signals, das mit fs abgetastet wurde, ist 1/fs. Nicht mehr (schadet aber nicht) und nicht weniger (sonst ist es nicht eindeutig). Es m?ssen aber die Rundungsregeln EXAKT definiert sein. Mathematisch EXAKT. F?r den Fall von nur ganzzahligen Abtastraten z.B. UINT64 WhichSample ( UINT64 timeticks, // 0...2^64-1 UINT32 timetickspersecond, // 1, 300, 1000, 1200, 48000, 192000, 10^6, 10^9 UINT32 samplefreq ) // 8000, 32000, 44100, 48000, 96000, 192000 { if ( timetickspersecond == 0 ) return ERROR ; if ( samplefreq > timeticks ) fprintf ( stderr, "Inprecise\n" ); UINT32 seconds = timeticks / timetickspersecond ; UINT32 remaining = timeticks % timetickspersecond ; UINT64 ret ; ret = (UINT64) remaining * samplefreq / timetickspersecond ; ret += (UINT64) seconds * samplefreq ; return ret ; } > So, the minimal required accuracy to determine a specific sample from a > timestamp is 1/2 Ts = 11,3 ?s Den Faktor 2 ben?tigst Du nicht. Aber den Rundungsmodus mu?t Du exakt festlegen. M?glichkeit 1: - immer abrunden in Richtung -oo M?glichkeit 2: - immer aufrunden in Richtung +oo M?glichkeit 3: - immer zum n?chstenliegenden Int runden, 0.500000000000000000000000000000000000 wird aufgerundet. M?glichkeit 4: - immer zum n?chstenliegenden Int runden, Geradezahlregel 3 und 4 unterscheiden sich nur minimal, aber es gibt F?lle, in denen sie sich unterscheiden. Genauso solche Fehler f?hren zu kleinen Fehlern, die man kaum findet, die selten auffallen und die Jahrzehnte ?rger verursachen. -- Frank Klemm AIM Advanced Imaging Microscopy phone: +49 (36 41) 64-27 21 fax: +49 (36 41) 64-31 44 mailto:f.klemm at zeiss.de Christian HJ Wiesner 2004-01-09 13:35 Bitte antworten an chris An: Discussion about the current and future development of Matroska Kopie: Frank at matroska.org Thema: Re: [Matroska-devel] Re: Timestamp precision in matroska files Steve Lhomme wrote: > Now it seems I find to put a simple example myself : > Imagine sample 998 of an audio stream at 44100 kHz. The timecode for > this sample is 998/44100 = 22.63038549 ms or 22,630,385.49 ns > Now you'll have to explain me how any timecode precision, even of 1ns > could be accurate for this sample ! There is one flaw in this example : The only purpose of the timestamp accuracy is to allow to determine a specific sample in a block by the timestamp attached to the start of the block. 1 / 44100 = 22,6 ?s , means every single sample is 22,6 ?s long , or Ts ( duration of each sample ) = 22,6 ?s So, the minimal required accuracy to determine a specific sample from a timestamp is 1/2 Ts = 11,3 ?s So, if your timestamp is accurate to 10 ?s or less, you can say with 100% certainty what sample you have to load, by using rounding. Remember, we dont need the starting timestamp of this one sample with a precision of 0,5 ns , all we need to know is, if we have a timestamp xxxx , what sample corresponds to it. Christian From pfk at fuchs.offl.uni-jena.de Fri Jan 9 23:28:59 2004 From: pfk at fuchs.offl.uni-jena.de (Frank Klemm) Date: Fri, 9 Jan 2004 23:28:59 +0100 Subject: =[SPAM?]= [Matroska-devel] Timestamp precision in matroska files] In-Reply-To: <3FFF0F10.1020905@matroska.org>; from chris@matroska.org on Fri, Jan 09, 2004 at 09:29:04PM +0100 References: <3FFF0F10.1020905@matroska.org> Message-ID: <20040109232859.B1363@fuchs.offl.uni-jena.de> Hi, translation to English and an additional remark. When you want address sample precise, you need a time base with the preciion of the reciproce of the sample frequency. You don't need a saveguard factor of 2 as Mr. Wiesner suggested, but you need precise rounding rules. Otherwise you need a indefinite precision for the timebase (or a integral multiple). You must also be careful with floating point because of rounding differences depending on the order of the operations. Note that a*b/c != a/c*b. In the case of an intergral sample rate (48000 Hz, not 44055.97376127834 Hz), you can use the following code (to avoid 96 bit int arithmetic). UINT64 WhichSample ( UINT64 timeticks, // 0...2^64-1 UINT32 timetickspersecond, // 1, 300, 1000, 1200, 48000, 192000, 10^6, 10^9 UINT32 samplefreq ) // 8000, 32000, 44100, 48000, 96000, 192000 { if ( timetickspersecond == 0 ) return ERROR ; if ( samplefreq > timetickspersecond ) fprintf ( stderr, "Inprecise\n" ); UINT32 seconds = timeticks / timetickspersecond ; UINT32 remaining = timeticks % timetickspersecond ; UINT64 ret ; ret = (UINT64) remaining * samplefreq / timetickspersecond ; ret += (UINT64) seconds * samplefreq ; return ret ; } This code rounds down. I suggest to use this rounding control. Other possiblities are round up, rounding to nearest integer (rounding up 0.5) or rounding to nearest integer (rounding 0.5 to nearest even integral number). Note that the last two are nearly identical, but they still gave different results for some input. -- Frank Klemm From suiryc at yahoo.com Sat Jan 10 13:02:21 2004 From: suiryc at yahoo.com (Cyrius) Date: Sat, 10 Jan 2004 04:02:21 -0800 (PST) Subject: [Matroska-devel] 2 problems in libebml Message-ID: <20040110120221.39561.qmail@web12902.mail.yahoo.com> Hi People are experiencing problems with the files produced by the latest versions of mkvmerge. And it seems related to a few problems inside libebml that I spotted when debugging. First let's see how those files are written by mkvmerge (using mkvinfo) : + EBML head at 0 + Segment at 24 |+ Seek head at 36 |+ EbmlVoid (size: 4029) at 103 |+ Segment information at 4135 | + Muxing application: libebml v0.6.3 + libmatroska v0.6.2 at 4140 | + Writing application: mkvmerge v0.8.1 at 4178 | + Duration: 2.520s at 4196 | + Date: Sat Jan 10 09:40:56 2004 UTC at 4203 | + Segment UID: 0x16 0x69 0x29 0x3e 0x06 0x0c 0x03 0x28 0xa6 0xb0 0xa0 0x4f 0x47 0x52 0xd4 0x75 at 4214 |+ Segment tracks at 4233 |+ EbmlVoid (size: 1024) at 4398 |+ Cluster at 5425 | + Cluster timecode: 0.000s at 5432 | + Block group at 5435 ... |+ Cues at 569825 |+ Seek head at 569859 The problem comes from the EbmlVoid written just after the KaxTracks element. I guess Mosu added this void element in recent versions since there was no troubles before. So what happens bad due to this element inside VirtualDubMod, and due to libebml (there is a workaround that could be used in VDM code, but I think that libebml is mostly guilty here :p)? Everything is fine up to KaxTracks. Then I ask libebml to give me the next element (in the loop processing KaxTracks). As I can't know beforehand if the next element will be inside KaxTracks, or an upper element, I use the size of the KaxTracks as maximum size for the next element to get (MaxDataSize), and say to don't get dummy elements (AllowDummyElt=false). So the first problem arise: libebml find the EbmlVoid element, but this element size is 1024 bytes, while the size of KaxTracks is around 150 bytes. Since an EbmlVoid can be found at any level, libebml thinks it is inside KaxTracks (while actually it is at the same level than KaxTracks) and of course libebml is unhappy to see that the size of this element (1024) doesn't fit inside the maximum size I gave (~150 bytes, i.e. the size of KaxTracks). So libebml think that this EbmlVoid is not a valid element and decide to not return it to me (VDM) and keep on searching the next element. And here is where arise the second problem (yeah, all would have been fine if there was no other problem :>). libebml search for the next element ... the problem is that en EbmlVoid generally contains only 0x00 bytes ;). When libebml think it found an element (generally when reading the bytes corresponding to the EbmlVoid coded size) it then tries to get the size of the element ... and the 0x00 bytes make it read 8 bytes from the file (note that the current libebml code doesn't somehow 'flush' this buffer afterwards). libebml then keep on trying to get the next ebml element ... Finally the code find the KaxCluster :) The problem is that the code already buffered more than 8 bytes. In other words libebml already read more than the Ebml ID and the coded size of the element, and the code doesn't seek back in the file. So when you ask again libebml to get the next element, it won't start right inside the KaxCluster, but a few bytes off and thus you don't get the first element inside the cluster (the first element generally being the timecode). To sum up, there are 2 problems: 1. with multi-level elements, when specifying a maximum size for the element to find, if the size of the multi-level element (that actually could belong to an upper level) is bigger than the specified size then libebml b0rks 2. when searching the next Ebml element, libebml sometimes buffer too much data ahead, and don't seek back in the file when it find a valid ebml element (making the very first bytes of this element lost). I guess that the size of multi-level elements shouldn't get tested against the maximum size specified since there is no way to know the level of such elements. I don't think that buffering too much data is a real trouble for 2. Indeed this only happens when the code couldn't find a valid element right ahead. But the code should seek back in the file if it buffered too much data ;) Best regards Cyrius __________________________________ Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus From moritz at bunkus.org Sat Jan 10 15:44:11 2004 From: moritz at bunkus.org (Moritz Bunkus) Date: Sat, 10 Jan 2004 15:44:11 +0100 Subject: [Matroska-devel] libebml & libmatroska as DLLs Message-ID: <20040110144410.GM30186@bunkus.org> Heya, I've committed changes to libebml and libmatroska which allow building both as DLLs. This i controlled by defining a couple of magic words. So if they aren't defined static libraries will be built - so nothing changes for devels. Here's how it is: If libebml should be built as a DLL then during the DLL build process 'EBML_DLL_EXPORT' has to be defined. An application using the DLL has to define 'EBML_DLL'. If libmatroska should be build as a DLL then during the DLL build process 'MATROSKA_DLL_EXPORT' has to be defined. An application using the DLL has to define 'MATROSKA_DLL'. As libmatroska depends on libebml you also have to define 'EBML_DLL'. So apps using both libs as DLLs have to define both 'EBML_DLL' and 'MATROSKA_DLL'. If both libs should be built statically nothing has to be defined. For details see libebml/ebml/EbmlConfig.h, libebml/make/mingw32/Makefile, libmatroska/matroska/KaxConfig.h and libmatroska/make/mingw32/Makefile. The reason for all these defines is that it seems to be impossible on Windows to do it otherwise. You can't use '__declspec(dllimport)' on statically build libs... I've checked other libraries (expat and wxWindows) and both also use such a system (for expat you have to define XML_STATIC for a static version..., similar for wxWindows which is more like my system). I honestly despise Windows for such a system because you don't need ANY of this crap on most Unix systems... Please test if the code still compiles with MS VC. Mosu -- If Darl McBride was in charge, he'd probably make marriage unconstitutional too, since clearly it de-emphasizes the commercial nature of normal human interaction, and probably is a major impediment to the commercial growth of prostitution. - Linus Torvalds From steve.lhomme at free.fr Sat Jan 10 16:40:32 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Sat, 10 Jan 2004 16:40:32 +0100 Subject: [Matroska-devel] libebml & libmatroska as DLLs In-Reply-To: <20040110144410.GM30186@bunkus.org> References: <20040110144410.GM30186@bunkus.org> Message-ID: <40001CF0.6090205@free.fr> Moritz Bunkus wrote: > Please test if the code still compiles with MS VC. It does with MSVC 7.1. It should work fine with VC6 too. From steve.lhomme at free.fr Sat Jan 10 23:41:00 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Sat, 10 Jan 2004 23:41:00 +0100 Subject: [Matroska-devel] Matroska in RealPlayer Message-ID: <40007F7C.8010903@free.fr> You all know that one of the thing we're missing now is support from an industry leader. That would help us go on and make Matroska a known and trusted alternative to AVI. Now it seems that it could come from the side of Real Networks. Karl Lillevold from Real said this on Doom9 : "It would be fantastic if someone wrote a Matroska file-writer plugin for Producer. I am pretty sure we would then distribute this file-writer with Milestone builds of Helix Producer 10." http://forum.doom9.org/showthread.php?s=&postid=425891#post425891 So I think we should try to spend some time there !!! "If there is a volunteer, I would be more than happy to assist as much as I can, even though I will have to forward many questions to the Producer team." From moritz at bunkus.org Sun Jan 11 00:27:39 2004 From: moritz at bunkus.org (Moritz Bunkus) Date: Sun, 11 Jan 2004 00:27:39 +0100 Subject: [Matroska-devel] Matroska in RealPlayer In-Reply-To: <40007F7C.8010903@free.fr> References: <40007F7C.8010903@free.fr> Message-ID: <20040110232739.GP30186@bunkus.org> Heya, this sounds pretty cool, but I won't be able to help. As some of you know I will be more than busy in the next six to seven weeks with part of my diploma thesis. Mosu -- If Darl McBride was in charge, he'd probably make marriage unconstitutional too, since clearly it de-emphasizes the commercial nature of normal human interaction, and probably is a major impediment to the commercial growth of prostitution. - Linus Torvalds From steve.lhomme at free.fr Sun Jan 11 00:54:45 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Sun, 11 Jan 2004 00:54:45 +0100 Subject: [Matroska-devel] Matroska in RealPlayer In-Reply-To: <20040110232739.GP30186@bunkus.org> References: <40007F7C.8010903@free.fr> <20040110232739.GP30186@bunkus.org> Message-ID: <400090C5.5060508@free.fr> Moritz Bunkus wrote: > Heya, > > this sounds pretty cool, but I won't be able to help. As some of you > know I will be more than busy in the next six to seven weeks with part > of my diploma thesis. No problem. I may do it myself. From steve.lhomme at free.fr Sun Jan 11 10:14:03 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Sun, 11 Jan 2004 10:14:03 +0100 Subject: [Matroska-devel] Matroska support of Wavpack4 Message-ID: <400113DB.9020200@free.fr> Hi David, Following the discussion on HydrogenAudio, here are my answers : http://www.hydrogenaudio.org/index.php?showtopic=15073&st=50&&#entry171972 > I'm not too sure of the advantage of not just leaving the block alone considering how large they generally are (unless you are planning on really short blocks). Well, yes considering that 32 octets is quite small compared to any frame. It is very unlikely that anyone will want to use wavpack with only a serie of small packets (and probably with less efficient compression). But as Pamel replied, the idea is to let the container do his job and leave the rest to the codec. A good example is the CRC that we already handle at the container level or the track number. But as you might use a different CRC (with correction ?) than ours I think we should keep it in our stripped header. > Each of these packets are completely stand-alone. They can be decoded back to mono or stereo audio without anything else. So I don't see any reason that you could not mix as many mono and stereo streams as you wanted as long as Matroska was keeping track of them. There *is* a good reason why we want to avoid that in Matroska. What happens if, in the same track, you have mono samples and stereo samples ? Where does the mono sound go ? In the left channel, in the right, in both ? Same volume or divided by 2 ? In a 3rd channel ? From steve.lhomme at free.fr Sun Jan 11 10:45:44 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Sun, 11 Jan 2004 10:45:44 +0100 Subject: [Matroska-devel] Matroska in RealPlayer In-Reply-To: <400090C5.5060508@free.fr> References: <40007F7C.8010903@free.fr> <20040110232739.GP30186@bunkus.org> <400090C5.5060508@free.fr> Message-ID: <40011B48.4020802@free.fr> Apparently there are different kinds of licenses for adding code in the Helix platform. https://www.helixcommunity.org/content/licenses I don't understand if you have to choose a license or not. But if so, it seems that the RPSL is a very good choice : "RealNetworks Public Source License (RPSL) - no-cost copyleft open source license which requires your entire application to be open sourced." "This license has been approved by the Open Source Initiative as an open source license. It contains some "copyleft" provisions along the lines of the GPL, but also clears up patent issues and allows contributed changes to be put back into the pool for the entire community. Hence, the RPSL gives you the right to develop and distribute Helix DNA, but modifications to the Helix DNA itself need to be supplied back to the community under the RPSL. Also, applications built using the Helix DNA must be released wholly as open source." So I assume it's *very* compatible with the QPL license in libmatroska/libebml that states that the application has to be open sourced too. Now I hope we don't have to make libmatroska/libebml RSPL too... Well, we could use a triple-license, instead of the current dual-license state... But I think we don't need to change this way : https://www.helixcommunity.org/content/complicense From christophe.paris at free.fr Sun Jan 11 22:40:08 2004 From: christophe.paris at free.fr (christophe.paris at free.fr) Date: Sun, 11 Jan 2004 22:40:08 +0100 Subject: [Matroska-devel] MPEG2 support for MatroskaSplitter Message-ID: <1073857208.4001c2b8a4f34@imp1-a.free.fr> Here is a start for the mpeg2 support in MatroskaSplitter in case someone wants to have a look at it. John's test file seems not perfect yet ;) (the mpeg2 sequence header), and i only got it to work with PowerDVD decoder for now. From christophe.paris at free.fr Sun Jan 11 22:44:27 2004 From: christophe.paris at free.fr (Christophe PARIS) Date: Sun, 11 Jan 2004 22:44:27 +0100 Subject: [Matroska-devel] MPEG2 support for MatroskaSplitter In-Reply-To: <1073857208.4001c2b8a4f34@imp1-a.free.fr> References: <1073857208.4001c2b8a4f34@imp1-a.free.fr> Message-ID: <4001C3BB.9020202@free.fr> lol, I forgot the attachment ;) christophe.paris at free.fr wrote: >Here is a start for the mpeg2 support in MatroskaSplitter in case someone wants >to have a look at it. >John's test file seems not perfect yet ;) (the mpeg2 sequence header), and i >only got it to work with PowerDVD decoder for now. > >_______________________________________________ >Matroska-devel mailing list >Matroska-devel at lists.matroska.org >http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel > > > > -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: mpeg2change.txt URL: From jcsston at toughguy.net Mon Jan 12 08:34:22 2004 From: jcsston at toughguy.net (Jory) Date: Mon, 12 Jan 2004 01:34:22 -0600 Subject: [Matroska-devel] Matroska in RealPlayer References: <40007F7C.8010903@free.fr> Message-ID: <002e01c3d8de$8488c100$0200a8c0@jcsston> I would be very interested in this. I recently created a mka muxer for spyder's API/framework and I designed it to be very reusable, so the hardest part would be finding out how to link to the Helix Producer API :) I have already agreed to most of the needed licenses for Helix from when I was looking for RM file format specs. And still have a checkout of the CVS, (though it's a bit old). Jory ----- Original Message ----- From: "Steve Lhomme" To: "Discussion about the current and future development of Matroska" ; "General talk about Matroska and other products" Sent: Saturday, January 10, 2004 4:41 PM Subject: [Matroska-devel] Matroska in RealPlayer > You all know that one of the thing we're missing now is support from an > industry leader. That would help us go on and make Matroska a known and > trusted alternative to AVI. > > Now it seems that it could come from the side of Real Networks. Karl > Lillevold from Real said this on Doom9 : > > "It would be fantastic if someone wrote a Matroska file-writer plugin > for Producer. I am pretty sure we would then distribute this file-writer > with Milestone builds of Helix Producer 10." > > http://forum.doom9.org/showthread.php?s=&postid=425891#post425891 > > So I think we should try to spend some time there !!! > > "If there is a volunteer, I would be more than happy to assist as much > as I can, even though I will have to forward many questions to the > Producer team." > > _______________________________________________ > Matroska-devel mailing list > Matroska-devel at lists.matroska.org > http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel From steve.lhomme at free.fr Mon Jan 12 09:29:57 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Mon, 12 Jan 2004 09:29:57 +0100 Subject: [Matroska-devel] Matroska in RealPlayer In-Reply-To: <002e01c3d8de$8488c100$0200a8c0@jcsston> References: <40007F7C.8010903@free.fr> <002e01c3d8de$8488c100$0200a8c0@jcsston> Message-ID: <40025B05.1000101@free.fr> Cool, so we should work together then (after I have done the Chapter flags handling in Matroska Splitter). I really want this thing to happen :) Jory wrote: > I would be very interested in this. > I recently created a mka muxer for spyder's API/framework and I designed it > to be very > reusable, so the hardest part would be finding out how to link to the Helix > Producer API :) > > I have already agreed to most of the needed licenses for Helix from when I > was looking for RM file format specs. And still have a checkout of the CVS, > (though it's a bit old). > > Jory > > ----- Original Message ----- > From: "Steve Lhomme" > To: "Discussion about the current and future development of Matroska" > ; "General talk about Matroska and other > products" > Sent: Saturday, January 10, 2004 4:41 PM > Subject: [Matroska-devel] Matroska in RealPlayer > > > >>You all know that one of the thing we're missing now is support from an >>industry leader. That would help us go on and make Matroska a known and >>trusted alternative to AVI. >> >>Now it seems that it could come from the side of Real Networks. Karl >>Lillevold from Real said this on Doom9 : >> >>"It would be fantastic if someone wrote a Matroska file-writer plugin >>for Producer. I am pretty sure we would then distribute this file-writer >>with Milestone builds of Helix Producer 10." >> >>http://forum.doom9.org/showthread.php?s=&postid=425891#post425891 >> >>So I think we should try to spend some time there !!! >> >>"If there is a volunteer, I would be more than happy to assist as much >>as I can, even though I will have to forward many questions to the >>Producer team." >> >>_______________________________________________ >>Matroska-devel mailing list >>Matroska-devel at lists.matroska.org >>http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel > > > > _______________________________________________ > Matroska-devel mailing list > Matroska-devel at lists.matroska.org > http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel From steve.lhomme at free.fr Mon Jan 12 10:28:29 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Mon, 12 Jan 2004 10:28:29 +0100 Subject: [Matroska-devel] Matroska in RealPlayer In-Reply-To: <002e01c3d8de$8488c100$0200a8c0@jcsston> References: <40007F7C.8010903@free.fr> <002e01c3d8de$8488c100$0200a8c0@jcsston> Message-ID: <400268BD.5070909@free.fr> BTW, I've had confirmation from Karl that Real Producer is mostly written in C++ except for the codecs. So we should not have much problems integrating our classes with their code :) (I haven't checked out the CVS yet) From jcsston at toughguy.net Tue Jan 13 09:24:14 2004 From: jcsston at toughguy.net (Jory) Date: Tue, 13 Jan 2004 02:24:14 -0600 Subject: [Matroska-devel] Matroska in RealPlayer References: <40007F7C.8010903@free.fr> Message-ID: <010201c3d9b1$735f2580$0200a8c0@jcsston> I've started a mkv writer plugin. The Helix plugin system looks very COM/DShow based, IBaseFilter, IUnknown, graph managers, etc. I'm basing it on the ogg writer, since it is much simpler than the extremely complex realmedia writer. The CodecID or stream type is created using a mime-type. For the codecprivate the plugin is supplied with a buffer "OpaqueData" that has a layout that looks the same as the headers in .rm files, so extracting those shouldn't be any problem. The sample interfaces have Set/GetTime methods so I think our timesamps will be already taken care of. Sleep time for me, Jory ----- Original Message ----- From: "Steve Lhomme" To: "Discussion about the current and future development of Matroska" ; "General talk about Matroska and other products" Sent: Saturday, January 10, 2004 4:41 PM Subject: [Matroska-devel] Matroska in RealPlayer BTW, I've had confirmation from Karl that Real Producer is mostly written in C++ except for the codecs. So we should not have much problems integrating our classes with their code :) (I haven't checked out the CVS yet) From steve.lhomme at free.fr Tue Jan 13 09:56:31 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Tue, 13 Jan 2004 09:56:31 +0100 Subject: [Matroska-devel] Matroska in RealPlayer In-Reply-To: <010201c3d9b1$735f2580$0200a8c0@jcsston> References: <40007F7C.8010903@free.fr> <010201c3d9b1$735f2580$0200a8c0@jcsston> Message-ID: <4003B2BF.6070604@free.fr> Very good ! Actually yesterday I was out (no work) and for the couple of coming days I want to work on the Matroska Splitter. But then I'll join you :) Jory wrote: > I've started a mkv writer plugin. The Helix plugin system looks very > COM/DShow based, IBaseFilter, IUnknown, graph managers, etc. > > I'm basing it on the ogg writer, since it is much simpler than the extremely > complex realmedia writer. The CodecID or stream type is created using a > mime-type. For the codecprivate the plugin is supplied with a buffer > "OpaqueData" that has a layout that looks the same as the headers in .rm > files, so extracting those shouldn't be any problem. > The sample interfaces have Set/GetTime methods so I think our timesamps will > be already taken care of. > > Sleep time for me, > Jory From christophe.paris at free.fr Wed Jan 14 02:55:57 2004 From: christophe.paris at free.fr (Christophe PARIS) Date: Wed, 14 Jan 2004 02:55:57 +0100 Subject: [Matroska-devel] MPEG2 support for MatroskaSplitter In-Reply-To: <1073857208.4001c2b8a4f34@imp1-a.free.fr> References: <1073857208.4001c2b8a4f34@imp1-a.free.fr> Message-ID: <4004A1AD.2000305@free.fr> Ok, I found what was wrong and it was my fault. :-[ Now it connect well with most MPEG2 decoders, I've tested with success the ones from Gabest, Nero and PowerDVD. It seems just reference or timestamps are not perfect yet :-) Regards, Toff christophe.paris at free.fr wrote: >Here is a start for the mpeg2 support in MatroskaSplitter in case someone wants >to have a look at it. >John's test file seems not perfect yet ;) (the mpeg2 sequence header), and i >only got it to work with PowerDVD decoder for now. > -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: mpeg2change2.txt URL: From chris at matroska.org Wed Jan 14 04:16:21 2004 From: chris at matroska.org (Christian HJ Wiesner) Date: Wed, 14 Jan 2004 04:16:21 +0100 Subject: [Matroska-devel] MPEG2 support for MatroskaSplitter In-Reply-To: <4004A1AD.2000305@free.fr> References: <1073857208.4001c2b8a4f34@imp1-a.free.fr> <4004A1AD.2000305@free.fr> Message-ID: <4004B485.4040509@matroska.org> Christophe PARIS wrote: > Ok, I found what was wrong and it was my fault. :-[ > Now it connect well with most MPEG2 decoders, I've tested with success > the ones from Gabest, Nero and PowerDVD. > It seems just reference or timestamps are not perfect yet :-) > Regards, > Toff Guys, this is just great and i am speachless. All i can say is thank you, thank you, thank you, and once again thank you. Now hopefully spyder will find the small remaining bug with the timestamp and reference handling in his muxer, and we can make an alpha release. Just think of this : if we get a basic menue system working, based on robux4's specs, and make a simple app to convert DVD menues into matroska menues we can easily transmux a *complete DVD* into a single matroska file, while maintaining the complete functionality of the DVD !! All the audio formats possible in a DVD, i.e. AC3, MP2 and DTS, are well supported since some time now in MKV, and tested solutions. With MPEG2 video and a menue system, we can convert the complete DVD into a single MKV file. Now, to even top this, think of the following : Currently the users have to take big hassle to make a DVD-9 ( up to 9.4 GB ) smaller, so it fits onto a DVD-5 R/RW ( 4.7 GB ). They have the choice between : - re-encoding the MPEG2 video to a smaller bitrate, thus loosing quality and having to spend hours for the process ( like with MPEG4 compression ) - undertake a complicated authoring process to create two DVD-5 from one DVD-9, and this means they have to change discs in the middle of the movie even Now, with matroska and the automatic file segmenting, we could easily split a 8 GB MKV file into two smaller segments, so that a 9 GB DVD can be converted into two, linked MKV files, and without any time consuming re-encoding or authoring process. A player supporting file linking could even play the 2 parts automatically, the users wouldn't even notice the 2nd part playing now. In theory, an easy to use tool could be made to automate the process ( shouldnt take longer than 20 -30 minutes, depending on HDD speed ), means - extracting all audio and video streams from the DVD, and mux them into a single MKV file - converting the DVD menue into a suitable MKV menue - splitting the resulting file into 4,7 GB segments, using file linking What a great future !!! I love you all guys :-) .... Christian From steve.lhomme at free.fr Wed Jan 14 09:29:26 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Wed, 14 Jan 2004 09:29:26 +0100 Subject: [Matroska-devel] MPEG2 support for MatroskaSplitter In-Reply-To: <4004B485.4040509@matroska.org> References: <1073857208.4001c2b8a4f34@imp1-a.free.fr> <4004A1AD.2000305@free.fr> <4004B485.4040509@matroska.org> Message-ID: <4004FDE6.8090301@free.fr> Christian HJ Wiesner wrote: > Just think of this : if we get a basic menue system working, based on > robux4's specs, and make a simple app to convert DVD menues into The menu will only come after 1. is ready to roll. > - splitting the resulting file into 4,7 GB segments, using file linking What players / filters do support file linking right now ? None. It would have been possible with mkxds. But I guess it's going to be harder with a splitter of Gabest (no direct control of the source file playing)... BTW that's one of the things that need to be address ASAP too. From steve.lhomme at free.fr Wed Jan 14 13:55:46 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Wed, 14 Jan 2004 13:55:46 +0100 Subject: [Matroska-devel] ChapterTrack Message-ID: <40053C52.2080204@free.fr> Does anyone use these elements right now ? ChapterTrack 4+ [8F] - - - sub-elements ChapterTrackNumber 5+ [89] - >0 - u-integer I'm almost sure it's never used on playback. But maybe it's written sometimes ? I actually think that these elements have no real use... To disable a track for some time the Control Track can do that and could even use a hidden chapter (only seen by the control track). And to be able to seek at different locations depending on the track you're playing is IMO useless. So I suggest we make these elements deprecated or even remove them if no muxer use this for now. From suiryc at yahoo.com Wed Jan 14 15:26:10 2004 From: suiryc at yahoo.com (Cyrius) Date: Wed, 14 Jan 2004 06:26:10 -0800 (PST) Subject: [Matroska-devel] ChapterTrack In-Reply-To: <40053C52.2080204@free.fr> Message-ID: <20040114142610.10105.qmail@web12902.mail.yahoo.com> --- Steve Lhomme wrote: > Does anyone use these elements right now ? > > ChapterTrack 4+ [8F] - - - sub-elements > ChapterTrackNumber 5+ [89] - >0 - u-integer > I don't. __________________________________ Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus From steve.lhomme at free.fr Wed Jan 14 15:25:38 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Wed, 14 Jan 2004 15:25:38 +0100 Subject: [Matroska-devel] Disabled parts Message-ID: <40055162.2040709@free.fr> Hi Gabest, I'm going to add the support for disabled chapters in Matroska Splitter (to hide some content of a movie from the user, like the menu section for example). And I have a question on how you would think would be best to implement it. My idea is that while you're playing the movie, the filter knows in which chapter it is (between the start of the current and the start of the next one). During the playback, you pass from a chapter to the next one (based on timecode). But this chapter is disabled. So you have to "jump" to the end of this chapter and continue playback as if nothing happened... So the problem here is the way to jump. Do you think that the splitter could produce an internal SEEK and jump normally this way ? What will happen to the frames that have already been passed to the next pins ? Will they play or will they be flushed during the seeking ? If so the actual moment to decide to jump should be decided at the rendering stage, but that may make things much more complicated... What do you think ? From alexander.noe at s2001.tu-chemnitz.de Wed Jan 14 15:50:35 2004 From: alexander.noe at s2001.tu-chemnitz.de (=?ISO-8859-1?Q?Alexander_No=E9?=) Date: Wed, 14 Jan 2004 15:50:35 +0100 Subject: [Matroska-devel] ChapterTrack In-Reply-To: <40053C52.2080204@free.fr> References: <40053C52.2080204@free.fr> Message-ID: <4005573B.2090800@hrz.tu-chemnitz.de> Steve Lhomme wrote: > Does anyone use these elements right now ? > > ChapterTrack 4+ [8F] - - - sub-elements > ChapterTrackNumber 5+ [89] - >0 - u-integer I don't Alex From moritz at bunkus.org Wed Jan 14 17:59:11 2004 From: moritz at bunkus.org (Moritz Bunkus) Date: Wed, 14 Jan 2004 17:59:11 +0100 Subject: [Matroska-devel] libmatroska's copy c'tors Message-ID: <20040114165911.GD30186@bunkus.org> Heya, (This goes out to robux mostly.) I'm in the process of implementing a general 'just copy the stream' functionality for track types mkvmerge doesn't know anything about and came about this problem: Due to default values not being written and mandatory elements I can't just Render() an element I've just read. Example: Content encodings: + Content encodings + Content encoding + Content compression This is what content encoding looks like for zlib compression. Now, some of ContentCompression's children are missing because they're set to their default value, BUT they're mandatory as well. What I'm doing then is something like KaxContentEncodings *copy = new KaxContentEncodings(*old_encodings); copy->Render(*out); And sure as hell I get an assertion about the mandatory elements missing. So could you please think about a way to avoid this? I think that you could modify the copy c'tor so that after the copy it'll iterate over all the children and create the mandatory elements if they're missing. This has to be done recursively for EbmlMaster children, of course. Thanks. Mosu -- If Darl McBride was in charge, he'd probably make marriage unconstitutional too, since clearly it de-emphasizes the commercial nature of normal human interaction, and probably is a major impediment to the commercial growth of prostitution. - Linus Torvalds From moritz at bunkus.org Wed Jan 14 18:26:36 2004 From: moritz at bunkus.org (Moritz Bunkus) Date: Wed, 14 Jan 2004 18:26:36 +0100 Subject: [Matroska-devel] libmatroska's copy c'tors In-Reply-To: <20040114165911.GD30186@bunkus.org> References: <20040114165911.GD30186@bunkus.org> Message-ID: <20040114172636.GE30186@bunkus.org> Heya, Well, of course this is partial bullshit - a _copy_ c'tor should _copy_ the source exactly, so that's the wrong place to put such a thing. Instead EbmlMaster should contain a function, e.g. AddMandatoryChildren, that does what I asked for. Mosu -- If Darl McBride was in charge, he'd probably make marriage unconstitutional too, since clearly it de-emphasizes the commercial nature of normal human interaction, and probably is a major impediment to the commercial growth of prostitution. - Linus Torvalds From steve.lhomme at free.fr Wed Jan 14 22:29:06 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Wed, 14 Jan 2004 22:29:06 +0100 Subject: [Matroska-devel] libmatroska's copy c'tors In-Reply-To: <20040114165911.GD30186@bunkus.org> References: <20040114165911.GD30186@bunkus.org> Message-ID: <4005B4A2.9050407@free.fr> Moritz Bunkus wrote: > What I'm doing then is something like > KaxContentEncodings *copy = new KaxContentEncodings(*old_encodings); > copy->Render(*out); > > And sure as hell I get an assertion about the mandatory elements > missing. So could you please think about a way to avoid this? I think > that you could modify the copy c'tor so that after the copy it'll > iterate over all the children and create the mandatory elements if > they're missing. This has to be done recursively for EbmlMaster > children, of course. An additional parameter for the copy constructor ? At least there is the method ProcessMandatory() that will do what you want. Or almost because it doesn't check wether the element is already in the list or not. But that could be an added parameter. Now about the copy constructor, it's best to keep it like that as it's a more consistant way of doing things in C++. Otherwise it wouldn't be a copy constructor. So my suggestion would be to add a parameter to Render to be able to avoid checking for mandatory elements. That would also allow creating invalid files... So I think it's the way to go and I'm going to work on this. From steve.lhomme at free.fr Wed Jan 14 22:32:41 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Wed, 14 Jan 2004 22:32:41 +0100 Subject: [Matroska-devel] libmatroska's copy c'tors In-Reply-To: <4005B4A2.9050407@free.fr> References: <20040114165911.GD30186@bunkus.org> <4005B4A2.9050407@free.fr> Message-ID: <4005B579.7010000@free.fr> Steve Lhomme wrote: > Moritz Bunkus wrote: > >> What I'm doing then is something like >> KaxContentEncodings *copy = new KaxContentEncodings(*old_encodings); >> copy->Render(*out); >> >> And sure as hell I get an assertion about the mandatory elements >> missing. So could you please think about a way to avoid this? I think >> that you could modify the copy c'tor so that after the copy it'll >> iterate over all the children and create the mandatory elements if >> they're missing. This has to be done recursively for EbmlMaster >> children, of course. > > > An additional parameter for the copy constructor ? > > At least there is the method ProcessMandatory() that will do what you > want. Or almost because it doesn't check wether the element is already > in the list or not. But that could be an added parameter. > > Now about the copy constructor, it's best to keep it like that as it's a > more consistant way of doing things in C++. Otherwise it wouldn't be a > copy constructor. > > So my suggestion would be to add a parameter to Render to be able to > avoid checking for mandatory elements. That would also allow creating > invalid files... So I think it's the way to go and I'm going to work on > this. Done. Actually I did nothing but a small check : uint32 EbmlMaster::RenderData(IOCallback & output, bool bForceRender, bool bSaveDefault) .... if (!bForceRender) assert(CheckMandatory()); So set bForceRender to true in Render() and you'll be fine :) From steve.lhomme at free.fr Thu Jan 15 09:41:46 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Thu, 15 Jan 2004 09:41:46 +0100 Subject: [Matroska-devel] Re: Matroska and WavPack In-Reply-To: <000501c3db02$e654a3b0$0100a8c0@Pentium> References: <000501c3db02$e654a3b0$0100a8c0@Pentium> Message-ID: <4006524A.3090005@free.fr> David Bryant wrote: > Steve, > > This is reference to our discussion started on HA. I don't have an e-mail > address for "Pamel"; if they're a Matroska developer also perhaps you could > forward this. I've forwarded the email to him. > There seem to be two issues here. The first is what will the WavPack data > look like when it is contained in Matroska, and the other is how > multichannel support is to be done. I'll offer my thoughts on both these. > > My suggestion for the first question is that the WavPack block, including > the 32-byte header, should be stored as-is without stripping (as though the > header was part of the bitstream). I understand the concept of the container > handling what it does well and having the codec do its job, but there are > really only about 12 bytes of stuff in the header that are not required for > decoding, and I would much rather have to maintain just one function that > unpacks a WavPack block. This function would obviously ignore the "wvpk" > field and the other stuff that doesn't apply to a single block. OK. Well I understand that point of view. Actually we usually strip as much unneeded data from any kind of block we store in Matroska. We are very size greedy :) And therefore we are used to reconstitute data as they should be when passed to the decoder. So from your point of view (codec) you will receive data with the 12 bytes as in the original file. But in Matroska it may be stored differently. Don't worry about it. As soon as we have code from you to play with, we can start muxing/demuxing files and you will not be bothered about that :) Now on the other hand, if the Wavpack header structure evolves it is more complicated to follow the changes while it's the job of the codec. So it could be a wise idea to store the header as is. I'm still undecided. > The "crc" field in the WavPack block header applies to the decoded data, so > there is no quick way to use this to verify a block. Instead, this is used > internally to test both the integrity of the data storage and to test that > the encode/decode process was robust. I assume that Matroska has a crc > mechanism for the stored (encoded) stream and I suggest that this be > independent from the internal WavPack crc. OK, we'll keep the CRC. > Another thought I had is that in future improvements of the encoder I may > want to divide a block into two (or more) smaller blocks based on some > analysis of the samples (because, for example, a block must be true stereo > or joint stereo all the way through). If Matroska was simply storing the > data block that WavPack passed back then this could be accomplished with > complete transparency to Matroska. Alright, another point to store the header as-is :) > On the multichannel issue I had originally assumed that Matroska would > divide the multichannel audio into various stereo and mono streams and have > WavPack enocode them like that. In that case Matroska would keep track of > the timing and what speakers the streams were supposed to go to. Now that I > think about it I realize that ideally the codec should handle the > multichannel data directly because it might want to make bitrate decisions > based on all the channels, or even store the data as some sort of complex > matrix. For using codecs that can only handle stereo and mono streams, it > might still be a reasonable thing for Matroska to be able to do. However, > WavPack will be able to handle multichannel directly by using multiple > stereo and mono blocks in sequence (and obviously storing the information > required to know what goes where during decode, and again transparently to > Matroska). Alright, that's the way to go. For all known codecs that's the job of the codec to handle the multichannels (not the container) to compress data efficiently and, the most important, map the channels to the correct speaker. It is possible to have multiple streams playing at the same time with Matroska. But in this case the channel mapping might be problematic... > I am just starting to work with multichannel, so I hope that this makes some > sense. Perhaps you could point me to an example multichannel codec interface > (I was simply going to implement storage of WAVEFORMATEX and corresponding > audio data). I just know the Microsoft implementation. And I don't think there aren't many others in the wild. At least for the channel mapping (in DirectShow). From chris at matroska.org Thu Jan 15 10:38:12 2004 From: chris at matroska.org (Christian HJ Wiesner) Date: Thu, 15 Jan 2004 10:38:12 +0100 Subject: [Matroska-devel] Porting Gstreamer to win32 .... the better solution ? Message-ID: <40065F84.1080909@matroska.org> Hi guys, did we ever seriously think about this option ? Think of the advantages : - plenty of working plugins, for most formats, and including matroska - a working and well designed codec/plugin API - a project to make a vidoe editor, we just need to help and adapt the GUI for win32 - a nice playback platform for a new, powerful player, for Linux and Windows ( TCMP 6 ? ) Just think of the hours of coding just to make working plugins for the new media-api :o ...... About size : and ... how big would it become once its ported ? I have no clue you cant make people understand why a video editor is 50 MB big ? porting is easy if you use cygwin we've had some people coming over to #gstreamer to say they want to port it but nobody wanted to use cygwin and nobody ever submitted workign code these are related ;) point 1: for porting unix code to win32, use cygwin * ChrisHJW is also not happy about cygwin .. think performance and stuff .... and 50 MB? BBB : wild guess how many memleaks does windows have? lol gst core is 1 or 2 MB ? wow we're profiling a *lot* DirectX 9 is 12 MB we're media world pros ;) :) we know how stuff works :) no doubt (well, I don't know why MPEG pauses for 15 seconds when streaming it, but for the rest...) (only on WMP...) 1 - 2 MB, to distribute with a video editor, sounds reasonable, especially if you count the number of wroking plugins the video editor would need a UI thats not the problem so in total, it'd be like 10-20 MB, UI + backend + everything 10 - 20 MB ..... thats a lot now, but i'd like to see the size of Adobe Premiere 8 once its out ? are 100 MB still enough ? And dont forget, the basic gstreamer win32 platform can be distributed separately, and the video editor or player become much smaller then ? What you think ? Christian From steve.lhomme at free.fr Thu Jan 15 10:56:28 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Thu, 15 Jan 2004 10:56:28 +0100 Subject: [Matroska-devel] Porting Gstreamer to win32 .... the better solution ? In-Reply-To: <40065F84.1080909@matroska.org> References: <40065F84.1080909@matroska.org> Message-ID: <400663CC.7020309@free.fr> Christian HJ Wiesner wrote: > Hi guys, > > did we ever seriously think about this option ? Probably not enough. I may investigate while I'm idle at work :) > Think of the advantages : > > - plenty of working plugins, for most formats, and including matroska > - a working and well designed codec/plugin API > - a project to make a vidoe editor, we just need to help and adapt the > GUI for win32 > - a nice playback platform for a new, powerful player, for Linux and > Windows ( TCMP 6 ? ) TCMP 6 based on GStreamer would indeed be a great thing ! Especially if you use wxWindows for the GUI. > point 1: for porting unix code to win32, use cygwin That's the easy-lazy way. Only good from a coder's perspective and definitely a "no way, you suck" for any normal user. I think that's *not* the way to go. But Mingw could help already achieving this. > 10 - 20 MB ..... thats a lot now, but i'd like to see the size of Adobe > Premiere 8 once its out ? are 100 MB still enough ? And dont forget, the > basic gstreamer win32 platform can be distributed separately, and the > video editor or player become much smaller then ? > > What you think ? Of course that could be great. Keep in mind that the Helix platform probably also offer the same capabilities than GStreamer. And it's already working well on many platforms for dumb end-users. From steve.lhomme at free.fr Thu Jan 15 11:11:04 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Thu, 15 Jan 2004 11:11:04 +0100 Subject: [Matroska-devel] Porting Gstreamer to win32 .... the better solution ? In-Reply-To: <400663CC.7020309@free.fr> References: <40065F84.1080909@matroska.org> <400663CC.7020309@free.fr> Message-ID: <40066738.2010504@free.fr> Check out the status of ports : http://gstreamer.net/status/?category=7 Also even though GStreamer is full of promises, we have to keep in mind that it's still in infancy. So it will get a good amount of time until we get substantial results if we go this way. From rbultje at ronald.bitfreak.net Thu Jan 15 11:21:43 2004 From: rbultje at ronald.bitfreak.net (Ronald Bultje) Date: Thu, 15 Jan 2004 11:21:43 +0100 Subject: [Matroska-devel] Porting Gstreamer to win32 .... the better solution ? In-Reply-To: <40066738.2010504@free.fr> References: <40065F84.1080909@matroska.org> <400663CC.7020309@free.fr> <40066738.2010504@free.fr> Message-ID: <1074162103.3619.78.camel@shrek.bitfreak.net> On Thu, 2004-01-15 at 11:11, Steve Lhomme wrote: > http://gstreamer.net/status/?category=7 that table has been unmaintained for 3 years. Ronald -- Ronald Bultje Linux Video/Multimedia developer From paul at msn.com Thu Jan 15 21:45:35 2004 From: paul at msn.com (Paul Bryson) Date: Thu, 15 Jan 2004 14:45:35 -0600 Subject: [Matroska-devel] Porting Gstreamer to win32 ....the better solution ? References: <40065F84.1080909@matroska.org> <400663CC.7020309@free.fr><40066738.2010504@free.fr> <1074162103.3619.78.camel@shrek.bitfreak.net> Message-ID: "Ronald Bultje"wrote... > On Thu, 2004-01-15 at 11:11, Steve Lhomme wrote: > > http://gstreamer.net/status/?category=7 > > that table has been unmaintained for 3 years. Perhaps it should be updated? Pamel From suiryc at yahoo.com Fri Jan 16 01:48:08 2004 From: suiryc at yahoo.com (Cyrius) Date: Thu, 15 Jan 2004 16:48:08 -0800 (PST) Subject: [Matroska-devel] libmatroska CVS + EbmlMaster::Read == b0rk Message-ID: <20040116004808.75493.qmail@web12904.mail.yahoo.com> Hi Let's go straight to the point :p The current libmatroska CVS has some parts hidden (e.g. some EBML elements that will either be removed, or changed, or whatever) such as KaxTrackFlagEnabled, .... and KaxTrackVideoDisplayUnit (or something like that). This triggers a bug when calling EbmlMaster::Read. An exemple, in the KaxTracks element Here is the content of the element: KaxTracks +->KaxTrackEntry | +->... | +->KaxTrackVideo | +->... | +->KaxTrackVideoDisplayUnit +->KaxTrackEntry | +->... ... currently in the CVS KaxTrackVideoDisplayUnit has been hidden (in other words it isn't recognized as a valid EBML element in the matroska context). Now when I call Read on the first KaxTrackEntry (which thus actually call EbmlMaster::Read), everything goes fine ... until the code reach this last (now hidden) element (display unit). At this point the call stack would be : (KaxTrackEntry)EbmlMaster::Read +->(KaxTrackVideo)EbmlMaster::Read +->EbmlElement::FindNextElement What would happen in the past (when the element was still recognized) : FindNextElement find the KaxTrackVideoDisplayUnit (at the same level than the previous element, i.e. UpperElementLevel==0), and returns it. EbmlMaster::Read (KaxTrackVideo level) then keep on its loop to read elements : (line 417) while (ElementLevelA != NULL && MaxSizeToRead > 0 && UpperEltFound <= 0) then the code call ElementLevelA->Read to fill the element. Since it was the last one, now MaxSizeToRead==0, and the code leave the loop and the Read function returns (with UpperEltFound == 0) EbmlMaster::Read (KaxTrackEntry level) had just called ElementLevelA->Read (ElementLevelA being the KaxTrackVideo), and since MaxSizeToRead==0, it also returns (again with UpperEltFound == 0) Since UpperEltFound==0, the calling code (VirtualDubMod) then ask the library to find the next ebml element and all is fine. What happens now : FindNextElement doesn't recognize KaxTrackVideoDisplayUnit and thus keep on searching. Since it was the last element inside the first KaxTrackEntry, It finally find the next KaxTrackEntry. It thus returns with UpperElementLevel==2 (indeed a KaxTrackEntry is 2 levels upper than the elements inside a KaxTrakVideo element). EbmlMaster::Read (KaxTrackVideo level) then leave at once the loop because UpperEltFound>0 (see the 'while' test). It thus returns, with UpperEltFound==2. EbmlMaster::Read (KaxTrackEntry level) had just called ElementLevelA->Read, and since MaxSizeToRead==0 it also returns (with UpperEltFound==2). So now the calling code get a UpperEltLevel==2 as answer from libmatroska (compared to 0 in the past) and thus think that the next element is 2 levels upper. This was of course true inside libmatroska (the next element, a KaxTrackEntry, is indeed 2 levels upper than the KaxTrackVideo children), but completly wrong for the calling code (which is only inside KaxTracks, i.e. already at the KaxTrackEntry level). This of course make the calling code unable to correctly process the next elements until it reaches an element at a upper level. Best regards Cyrius __________________________________ Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus From chris at matroska.org Fri Jan 16 04:11:45 2004 From: chris at matroska.org (Christian HJ Wiesner) Date: Fri, 16 Jan 2004 04:11:45 +0100 Subject: [Matroska-devel] TCMP, MILK, matroska, mkvmerge, avi-mux ..... what a mess !! Cant we come up with a common Corecodec strategy ? Message-ID: <40075671.20409@matroska.org> Hi folks, when lying awake in my bed tonight, i was thinking again of the way we are working currently, and to be honest, i dont like it a lot. Lets see how many APIs and or platforms we have ( planned or used ) alone inside our small number of projects : - CCAS for TCMP - MILK - UDub plugin API - mkvmerge internal API ( sorry, dont know how to name it better ) - VfW ( VCM / ACM ) - DirectShow My question : is there really no way to set all of this on a common platform ? I know this kind of work is unwanted, as it doesnt give you quick results. It maybe requires long term planning until you have the common platform and API working ( i guess BBB and the Gstreamer guys can sing a song here ), but dont you agree that, once this is done, we could progress much much faster ? A big question in this respect, as raised by robux4 again lately, is how about porting Gstreamer to Windows ? We could call it 'WinStreamer' and make a project on cc.org from it, as Gstreamer itself has recently moved to freebsd.org AFAIK, i guess they wont object if the Windows port is hosted on another server. Just think of the huge number of possibilities : - TCMP6 for Linux/Windows - UDub, with the comfort to be able to use *ALL* existing format plugins and codecs for gstreamer - the ability to use most of the apps designed for the official GNOME media interface on Windows etc. What you think ? Christian From alexander.noe at s2001.tu-chemnitz.de Fri Jan 16 06:10:47 2004 From: alexander.noe at s2001.tu-chemnitz.de (=?ISO-8859-1?Q?Alexander_No=E9?=) Date: Fri, 16 Jan 2004 06:10:47 +0100 Subject: [Matroska-devel] TCMP, MILK, matroska, mkvmerge, avi-mux ..... what a mess !! Cant we come up with a common Corecodec strategy ? In-Reply-To: <40075671.20409@matroska.org> References: <40075671.20409@matroska.org> Message-ID: <40077257.8050602@hrz.tu-chemnitz.de> Christian HJ Wiesner wrote: > > Hi folks, > > when lying awake in my bed tonight, i was thinking again of the way we > are working currently, and to be honest, i dont like it a lot. Lets > see how many APIs and or platforms we have ( planned or used ) alone > inside our small number of projects :... You know that, if your idea came true, *all* matroska tools would instantly break the next time Cyrius sends 'libmatroska b0rked' on the ML? Alex From moritz at bunkus.org Fri Jan 16 09:33:09 2004 From: moritz at bunkus.org (Moritz Bunkus) Date: Fri, 16 Jan 2004 09:33:09 +0100 Subject: [Matroska-devel] Re: [Matroska-general] TCMP, MILK, matroska, mkvmerge, avi-mux ..... what a mess !! Cant we come up with a common Corecodec strategy ? In-Reply-To: <40075671.20409@matroska.org> References: <40075671.20409@matroska.org> Message-ID: <20040116083309.GK30186@bunkus.org> Heya, > - mkvmerge internal API ( sorry, dont know how to name it better ) I strongly doubt my API would be 'convertable'. Basically I have three componentes: 1) readers (demuxers) which handle different container formats, file type recognition and stuff. This is more or less easy. 2) packetizers (framers) which handle different media types - one for Vorbis, one for video etc.pp. 3) The muxer (called cluster_helper) which requests packets from the packetizers which request packets from the readers and then stuffs those into clusters which then are rendered to the output file. Now what makes this complicated? One thing is that all the command line parameters actually have to reach the packetizers (and yes, I do mean all or nearly all), that the cluster_helper needs access to a lot of internal stuff of the packetizers. I can't really describe it, but my stuff is really involved. If you want a common API that API would have to be as extensive as mine is, and I don't think anyone else wants that. My idea has never been to have a modular system for which everyone can write a plugin (be it a reader or packetizer, doesn't matter) but to have a system that can control almost every aspect of Matroska file creation. This does not fit well into a common API. Mosu -- If Darl McBride was in charge, he'd probably make marriage unconstitutional too, since clearly it de-emphasizes the commercial nature of normal human interaction, and probably is a major impediment to the commercial growth of prostitution. - Linus Torvalds From steve.lhomme at free.fr Fri Jan 16 09:45:06 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Fri, 16 Jan 2004 09:45:06 +0100 Subject: [Matroska-devel] libmatroska CVS + EbmlMaster::Read == b0rk In-Reply-To: <20040116004808.75493.qmail@web12904.mail.yahoo.com> References: <20040116004808.75493.qmail@web12904.mail.yahoo.com> Message-ID: <4007A492.7050505@free.fr> Cyrius wrote: > What happens now : > > FindNextElement doesn't recognize KaxTrackVideoDisplayUnit and thus > keep on searching. No. It only happens when you don't use AllowDumy (or something like that), which means that you treat unknown elements in the file as errors. So you expected this behaviour. It's not a bug, it's a feature (at least up to now). > Since it was the last element inside the first > KaxTrackEntry, It finally find the next KaxTrackEntry. It thus returns > with UpperElementLevel==2 (indeed a KaxTrackEntry is 2 levels upper > than the elements inside a KaxTrakVideo element). > > EbmlMaster::Read (KaxTrackVideo level) then leave at once the loop > because UpperEltFound>0 (see the 'while' test). > It thus returns, with UpperEltFound==2. > > EbmlMaster::Read (KaxTrackEntry level) had just called > ElementLevelA->Read, and since MaxSizeToRead==0 it also returns (with > UpperEltFound==2). > > So now the calling code get a UpperEltLevel==2 as answer from > libmatroska (compared to 0 in the past) and thus think that the next > element is 2 levels upper. This was of course true inside libmatroska > (the next element, a KaxTrackEntry, is indeed 2 levels upper than the > KaxTrackVideo children), but completly wrong for the calling code > (which is only inside KaxTracks, i.e. already at the KaxTrackEntry > level). > This of course make the calling code unable to correctly process the > next elements until it reaches an element at a upper level. OK, there might be a bug to update the UpperEltFound value in this case. I'll try to have a look tonight or this week-end. From steve.lhomme at free.fr Fri Jan 16 09:52:14 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Fri, 16 Jan 2004 09:52:14 +0100 Subject: [Matroska-devel] Re: TCMP, MILK, matroska, mkvmerge, avi-mux ..... what a mess !! Cant we come up with a common Corecodec strategy ? In-Reply-To: <40075671.20409@matroska.org> References: <40075671.20409@matroska.org> Message-ID: <4007A63E.5030809@free.fr> Christian HJ Wiesner wrote: > > Hi folks, > > when lying awake in my bed tonight, i was thinking again of the way we > are working currently, and to be honest, i dont like it a lot. Lets see > how many APIs and or platforms we have ( planned or used ) alone inside > our small number of projects : > > - CCAS for TCMP > - MILK > - UDub plugin API > - mkvmerge internal API ( sorry, dont know how to name it better ) > - VfW ( VCM / ACM ) > - DirectShow > > My question : is there really no way to set all of this on a common > platform ? I know this kind of work is unwanted, as it doesnt give you > quick results. It maybe requires long term planning until you have the > common platform and API working ( i guess BBB and the Gstreamer guys can > sing a song here ), but dont you agree that, once this is done, we could > progress much much faster ? Yes, but you can't expect DirectShow or VfW working on other platforms that MS ones. And we want to be cross-platform. Now there could be GStreamer but it's not working on anything other than unices. And they have no intention on endorsing other platforms (if you want it, that's your problem). That's a pity but the situation seems to be locked right now. > A big question in this respect, as raised by robux4 again lately, is how > about porting Gstreamer to Windows ? We could call it 'WinStreamer' That would mean that we become *the* maintainers of this port as they don't give a shit about Windows (unless it's close enough to a UNIX using cygwin). And therefore, as I said already, I can't endorse that responsability because I want to concentrate on Matroska and Ordinateur-DJ. > and make a project on cc.org from it, as Gstreamer itself has recently > moved to freebsd.org AFAIK, i guess they wont object if the Windows port > is hosted on another server. Just think of the huge number of > possibilities : > > - TCMP6 for Linux/Windows And OSX :) > - UDub, with the comfort to be able to use *ALL* existing format plugins > and codecs for gstreamer > - the ability to use most of the apps designed for the official GNOME > media interface on Windows > etc. > > What you think ? This is indeed needed ! It will take a lot of time. Maybe today I'm going to try to make real Mingw makefiles for GStreamer and its dependencies. And hopefully if it works I'll make an HTML doc of how to be able to do it... It would be even better to have MSVC project files after that. But I don't have it here... From steve.lhomme at free.fr Fri Jan 16 09:56:06 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Fri, 16 Jan 2004 09:56:06 +0100 Subject: [Matroska-devel] Re: TCMP, MILK, matroska, mkvmerge, avi-mux ..... what a mess !! Cant we come up with a common Corecodec strategy ? In-Reply-To: <40077257.8050602@hrz.tu-chemnitz.de> References: <40075671.20409@matroska.org> <40077257.8050602@hrz.tu-chemnitz.de> Message-ID: <4007A726.1080104@free.fr> Alexander No? wrote: > Christian HJ Wiesner wrote: > >> >> Hi folks, >> >> when lying awake in my bed tonight, i was thinking again of the way we >> are working currently, and to be honest, i dont like it a lot. Lets >> see how many APIs and or platforms we have ( planned or used ) alone >> inside our small number of projects :... > > > You know that, if your idea came true, *all* matroska tools would > instantly break > the next time Cyrius sends 'libmatroska b0rked' on the ML? I understand your point. But that doesn't mean a unification, merging efforts is not needed. And BTW the GStreamer read/write is done in C and done by Ronald. IMO that's another problem with GStreamer, they won't accept C++ code. But if we do WinStreamer we are free from them :D... As for VDM compared to VirtualDub when they release new code we'll have to merge it with ours. From steve.lhomme at free.fr Fri Jan 16 09:59:06 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Fri, 16 Jan 2004 09:59:06 +0100 Subject: [Matroska-devel] Re: [Matroska-general] TCMP, MILK, matroska, mkvmerge, avi-mux ..... what a mess !! Cant we come up with a common Corecodec strategy ? In-Reply-To: <20040116083309.GK30186@bunkus.org> References: <40075671.20409@matroska.org> <20040116083309.GK30186@bunkus.org> Message-ID: <4007A7DA.908@free.fr> Moritz Bunkus wrote: > Now what makes this complicated? One thing is that all the command line > parameters actually have to reach the packetizers (and yes, I do mean > all or nearly all), that the cluster_helper needs access to a lot of > internal stuff of the packetizers. I can't really describe it, but my > stuff is really involved. If you want a common API that API would have > to be as extensive as mine is, and I don't think anyone else wants > that. My idea has never been to have a modular system for which everyone > can write a plugin (be it a reader or packetizer, doesn't matter) but to > have a system that can control almost every aspect of Matroska file > creation. This does not fit well into a common API. That's what makes your tools so special. They are the only ones that can make real use of Matroska because they don't have the limitations of legacy systems. Now maybe GStreamer doesn't have this limitation (as they claim it's almost perfect ;). Maybe Ronald could tell us about it, like what features are and aren't possible, and if it's possible to (re)write something like mkvmerge entirely with GStreamer. From rbultje at ronald.bitfreak.net Fri Jan 16 10:15:42 2004 From: rbultje at ronald.bitfreak.net (Ronald Bultje) Date: Fri, 16 Jan 2004 10:15:42 +0100 Subject: [Media-api] Re: [Matroska-devel] Porting Gstreamer to win32 ....the better solution ? In-Reply-To: References: <40065F84.1080909@matroska.org> <400663CC.7020309@free.fr> <40066738.2010504@free.fr> <1074162103.3619.78.camel@shrek.bitfreak.net> Message-ID: <1074244542.3619.137.camel@shrek.bitfreak.net> On Thu, 2004-01-15 at 21:45, Paul Bryson wrote: > "Ronald Bultje"wrote... > > On Thu, 2004-01-15 at 11:11, Steve Lhomme wrote: > > > http://gstreamer.net/status/?category=7 > > that table has been unmaintained for 3 years. > Perhaps it should be updated? Probably... But we first want to make it look good (i.e.: fix some of our most important bugs) before we tell the world what bugs we actually have. ;). Ronald -- Ronald Bultje Linux Video/Multimedia developer From steve.lhomme at free.fr Fri Jan 16 13:04:15 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Fri, 16 Jan 2004 13:04:15 +0100 Subject: [Matroska-devel] Gentoo Message-ID: <4007D33F.10901@free.fr> While looking for the libmatroska I found this : http://gentoo-portage.com/browse-program.php?program=2694 Apparently it compiles on AMD64 systems. Dunno if it works. But the use of int64 everywhere could be of good use there. From christian at matroska.org Sat Jan 17 00:05:45 2004 From: christian at matroska.org (ChristianHJW) Date: Sat, 17 Jan 2004 00:05:45 +0100 Subject: [Matroska-devel] Porting Gstreamer to win32 Message-ID: <40086E49.9060200@matroska.org> HI, its probably to early to talk about this, but the main developer of the matroska team, Steve 'robux4' Lhomme, has recently been looking into this, using mingw. We will probably call it 'WinStreamer' and host it on our server, corecodec.org . Any comments from your side ? How would you do it ? Is there anything existing yet we could try to build on ? Any ideas making a native port without cygwin or mingw ? Please use 'reply all' to the matroska lists get copied also, thanks Christian matroska project admin http://www.matroska.org From chris at matroska.org Sat Jan 17 00:13:07 2004 From: chris at matroska.org (Christian HJ Wiesner) Date: Sat, 17 Jan 2004 00:13:07 +0100 Subject: [Matroska-devel] C demuxer for matroska files patch for mplayer Message-ID: <40087003.5070106@matroska.org> http://article.gmane.org/gmane.comp.video.mplayer.devel/14806 I like that :) ... thanks Aurelien !! If you need some tips, you are always welcome on irc.corecodec.com #matroska .... Christian From rbultje at ronald.bitfreak.net Sat Jan 17 00:52:22 2004 From: rbultje at ronald.bitfreak.net (Ronald Bultje) Date: Sat, 17 Jan 2004 00:52:22 +0100 Subject: [Matroska-devel] Porting Gstreamer to win32 In-Reply-To: <40086E49.9060200@matroska.org> References: <40086E49.9060200@matroska.org> Message-ID: <1074297142.5655.17.camel@shrek.bitfreak.net> On Sat, 2004-01-17 at 00:05, ChristianHJW wrote: > its probably to early to talk about this, but the main developer of the > matroska team, Steve 'robux4' Lhomme, has recently been looking into > this, using mingw. We will probably call it 'WinStreamer' and host it on > our server, corecodec.org . It's easier to just commit patches to our CVS. You can get CVS access if required. You'll only need to patch very specific subsets, most parts can be shared. Ronald -- Ronald Bultje Linux Video/Multimedia developer From niemayer at isg.de Sat Jan 17 01:21:26 2004 From: niemayer at isg.de (Peter Niemayer) Date: Sat, 17 Jan 2004 01:21:26 +0100 Subject: [Matroska-devel] Re: Gentoo In-Reply-To: <4007D33F.10901@free.fr> References: <4007D33F.10901@free.fr> Message-ID: <40088006.2040600@isg.de> Steve Lhomme wrote: > While looking for the libmatroska I found this : > http://gentoo-portage.com/browse-program.php?program=2694 > > Apparently it compiles on AMD64 systems. Dunno if it works. It does work, though there are a number of warnings, most of which are not too scary, %d vs. %ld vs. %lld stuff in "prints" and alike. > But the use > of int64 everywhere could be of good use there. It would be certainly nice to clean up the code for 64bit systems. Cheers, Peter Niemayer From cyberdemonii at hotmail.com Sat Jan 17 15:08:21 2004 From: cyberdemonii at hotmail.com (Stef Heyenrath) Date: Sat, 17 Jan 2004 15:08:21 +0100 Subject: [Matroska-devel] CoCreateInstance(CLSID_MKXDEMUX returns error code. Message-ID: Hi all, I want to create a simple muxing application with directshow. The following h-file is included : #ifndef MKXDS_FILTER_H #define MKXDS_FILTER_H DEFINE_GUID(CLSID_MKXDEMUX, 0x34293064, 0x2f2, 0x41d5, 0x9d, 0x75, 0xcc, 0x59, 0x67, 0xac, 0xa1, 0xab); #ifdef __cplusplus extern "C" { #endif DEFINE_GUID(IID_IMkxFilter, 0x36a2372a, 0x8697, 0x45ae, 0x90, 0x3c, 0x6f, 0x1c, 0x80, 0x9, 0xf7, 0x50); DECLARE_INTERFACE_(IMkxFilter, IUnknown) {}; #ifdef __cplusplus } #endif #endif // MKXDS_FILTER_H ------------------ But when my application tries to create a mux filter like : hr = CoCreateInstance(CLSID_MKXDEMUX, NULL, CLSCTX_INPROC_SERVER, ID_IMkxFilter, (void **) ppMux); I get the error code : "REGDB_E_CLASSNOTREG", (But when i try to create a OggMux Filter, there are no problems.) what could be the problem ? Thanx, Stef From chris at matroska.org Sat Jan 17 15:29:06 2004 From: chris at matroska.org (Christian HJ Wiesner) Date: Sat, 17 Jan 2004 15:29:06 +0100 Subject: [Matroska-devel] CoCreateInstance(CLSID_MKXDEMUX returns error code. In-Reply-To: References: Message-ID: <400946B2.1030701@matroska.org> Stef, try again with the better DShow filter from Gabest's guliverkli page : http://sf.net/projects/guliverkli This filter is so good, we stopped developing our own ;), so mkxds.dll is deprecated ... Christian Stef Heyenrath wrote: > Hi all, > > I want to create a simple muxing application with directshow. > > The following h-file is included : > > #ifndef MKXDS_FILTER_H > #define MKXDS_FILTER_H > > > DEFINE_GUID(CLSID_MKXDEMUX, 0x34293064, 0x2f2, 0x41d5, 0x9d, 0x75, > 0xcc, 0x59, 0x67, 0xac, 0xa1, 0xab); > > #ifdef __cplusplus > extern "C" { > #endif > > DEFINE_GUID(IID_IMkxFilter, 0x36a2372a, 0x8697, 0x45ae, 0x90, 0x3c, > 0x6f, 0x1c, 0x80, 0x9, 0xf7, 0x50); > > DECLARE_INTERFACE_(IMkxFilter, IUnknown) > {}; > > #ifdef __cplusplus > } > #endif > > #endif // MKXDS_FILTER_H > > > ------------------ > But when my application tries to create a mux filter like : > > hr = CoCreateInstance(CLSID_MKXDEMUX, NULL, CLSCTX_INPROC_SERVER, > ID_IMkxFilter, (void **) ppMux); > > I get the error code : "REGDB_E_CLASSNOTREG", > > (But when i try to create a OggMux Filter, there are no problems.) > > what could be the problem ? > > Thanx, > Stef From steve.lhomme at free.fr Sat Jan 17 15:33:55 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Sat, 17 Jan 2004 15:33:55 +0100 Subject: [Matroska-devel] CoCreateInstance(CLSID_MKXDEMUX returns error code. In-Reply-To: References: Message-ID: <400947D3.2070500@free.fr> Stef Heyenrath wrote: > Hi all, > > I want to create a simple muxing application with directshow. > > But when my application tries to create a mux filter like : > > hr = CoCreateInstance(CLSID_MKXDEMUX, NULL, CLSCTX_INPROC_SERVER, > ID_IMkxFilter, (void **) ppMux); > > I get the error code : "REGDB_E_CLASSNOTREG", > > (But when i try to create a OggMux Filter, there are no problems.) > > what could be the problem ? > > Thanx, > Stef Hi, I don't know what the problem is, but the mkxds filter is deprecated now. Noone has the time/will to support it anymore. The "official" Matroska filter for DirectShow is MatroskaSplitter.ax from Gabest. You can find it on project Guliverkli on Sourceforge. bye From cyberdemonii at hotmail.com Sat Jan 17 15:48:08 2004 From: cyberdemonii at hotmail.com (Stef Heyenrath) Date: Sat, 17 Jan 2004 15:48:08 +0100 Subject: [Matroska-devel] Re: CoCreateInstance(CLSID_MKXDEMUX returns error code. In-Reply-To: <400947D3.2070500@free.fr> References: <400947D3.2070500@free.fr> Message-ID: could you please tell me which h-file I need ? From cyberdemonii at hotmail.com Sat Jan 17 16:03:14 2004 From: cyberdemonii at hotmail.com (Stef Heyenrath) Date: Sat, 17 Jan 2004 16:03:14 +0100 Subject: [Matroska-devel] Re: CoCreateInstance(CLSID_MKXDEMUX returns error code. In-Reply-To: References: <400947D3.2070500@free.fr> Message-ID: Stef Heyenrath wrote: > could you please tell me which h-file I need ? I have found it : It must be : // Matroska Muxer DEFINE_GUID(CLSID_MatroskaMuxer, 0x1E1299A2, 0x9D42, 0x4F12, 0x87, 0x91, 0xD7, 0x9E, 0x37, 0x6F, 0x41, 0x43); Thanx for the answers !!! bye From christophe.paris at free.fr Sat Jan 17 16:08:31 2004 From: christophe.paris at free.fr (Christophe PARIS) Date: Sat, 17 Jan 2004 16:08:31 +0100 Subject: [Matroska-devel] Re: CoCreateInstance(CLSID_MKXDEMUX returns error code. In-Reply-To: References: <400947D3.2070500@free.fr> Message-ID: <40094FEF.7040802@free.fr> Hi, What you need is the Matroska Muxer filter available here http://sourceforge.net/projects/guliverkli There is not really a .h file that you can include (maybe it would works with VC7) But you can have a look at this file : http://cvs.sourceforge.net/viewcvs.py/*checkout*/guliverkli/guliverkli/src/filters/muxer/matroskamuxer/MatroskaMuxer.h?content-type=text%2Fplain&rev=1.7 The filter CLSID is "{1E1299A2-9D42-4F12-8791-D79E376F4143}" or to use in your source : DEFINE_GUID(CLSID_MatroskaMuxer, 0x1E1299A2, 0x9D42, 0x4F12, 0x87, 0x91, 0xD7, 0x9E, 0x37, 0x6F, 0x41, 0x43); in VC7 you could probably do do __uuidof(CMatroskaMuxerFilter) Maybe you could also have a look at http://cvs.sourceforge.net/viewcvs.py/guliverkli/guliverkli/src/apps/asf2mkv Regards Toff Stef Heyenrath wrote: > could you please tell me which h-file I need ? > _______________________________________________ > Matroska-devel mailing list > Matroska-devel at lists.matroska.org > http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel > > From steve.lhomme at free.fr Sat Jan 17 17:44:58 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Sat, 17 Jan 2004 17:44:58 +0100 Subject: [Matroska-devel] libmatroska CVS + EbmlMaster::Read == b0rk In-Reply-To: <20040116004808.75493.qmail@web12904.mail.yahoo.com> References: <20040116004808.75493.qmail@web12904.mail.yahoo.com> Message-ID: <4009668A.8020502@free.fr> Cyrius wrote: > Hi > > Let's go straight to the point :p > The current libmatroska CVS has some parts hidden (e.g. some EBML > elements that will either be removed, or changed, or whatever) such as > KaxTrackFlagEnabled, .... and KaxTrackVideoDisplayUnit (or something > like that). OK, it is supposed to be fixed in CVS now. But as the context handling is quite complex, I'm not sure if I broke something. So please try to open old files, create new files, open new files with your tools (VDM, mkvmerge or whatever using libmatroska/libebml) and see if there is any problem. From steve.lhomme at free.fr Sat Jan 17 18:03:18 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Sat, 17 Jan 2004 18:03:18 +0100 Subject: [Matroska-devel] Re: Gentoo In-Reply-To: <40088006.2040600@isg.de> References: <4007D33F.10901@free.fr> <40088006.2040600@isg.de> Message-ID: <40096AD6.9070103@free.fr> Peter Niemayer wrote: > Steve Lhomme wrote: > >> While looking for the libmatroska I found this : >> http://gentoo-portage.com/browse-program.php?program=2694 >> >> Apparently it compiles on AMD64 systems. Dunno if it works. > > > It does work, though there are a number of warnings, most of which > are not too scary, %d vs. %ld vs. %lld stuff in "prints" and alike. Any log of the compilation would be appreciated (hopefully with the latest CVS version). > > But the use > >> of int64 everywhere could be of good use there. > > > It would be certainly nice to clean up the code for 64bit systems. What do you mean ? thx From cyberdemonii at hotmail.com Sat Jan 17 19:55:16 2004 From: cyberdemonii at hotmail.com (Stef Heyenrath) Date: Sat, 17 Jan 2004 19:55:16 +0100 Subject: [Matroska-devel] Next question about MUX Message-ID: I did not read the documentation about matroska, so if it is described somewhere please tell me ! I want to mux and avi and and mp3 with the matroska mux filter into a matroska file (.mkv) When i do this the following code cannot work : // QueryInterface for some basic interfaces pigb->QueryInterface(IID_IMediaControl, (void **)&pimc); pigb->QueryInterface(IID_IMediaEventEx, (void **)&pimex); pigb->QueryInterface(IID_IMediaSeeking, (void**)&pSeek); lstart = 0; lend = (LONGLONG) (TIMEFORMAT * l_split_at_milli_sec); hr = pSeek->GetTimeFormat(&timeFormat); hr = pSeek->GetDuration(&duration); hr = pSeek->GetPositions(&Current,&Stop); The "pSeek" functions return "NOT Implemented errors" ? Please help me ! grtz, Stef From suiryc at yahoo.com Sat Jan 17 21:26:27 2004 From: suiryc at yahoo.com (Cyrius) Date: Sat, 17 Jan 2004 12:26:27 -0800 (PST) Subject: [Matroska-devel] libmatroska CVS + EbmlMaster::Read == b0rk In-Reply-To: <4009668A.8020502@free.fr> Message-ID: <20040117202627.57386.qmail@web12905.mail.yahoo.com> --- Steve Lhomme wrote: > Cyrius wrote: > > > Hi > > > > Let's go straight to the point :p > > The current libmatroska CVS has some parts hidden (e.g. some EBML > > elements that will either be removed, or changed, or whatever) such > as > > KaxTrackFlagEnabled, .... and KaxTrackVideoDisplayUnit (or > something > > like that). > > OK, it is supposed to be fixed in CVS now. But as the context > handling > is quite complex, I'm not sure if I broke something. So please try to > > open old files, create new files, open new files with your tools > (VDM, > mkvmerge or whatever using libmatroska/libebml) and see if there is > any > problem. Seems to be OK now. __________________________________ Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus From jcsston at wiesneronline.net Sun Jan 18 01:06:46 2004 From: jcsston at wiesneronline.net (Jory) Date: Sat, 17 Jan 2004 18:06:46 -0600 Subject: [Matroska-devel] Next question about MUX References: Message-ID: <001001c3dd58$82658e20$0200a8c0@jcsston> For some example C++ code of using the Matroska Muxer to mux a mp3, you can look at AudioDShowEncoder. http://cvs.corecodec.org/cgi-bin/viewcvs.cgi/vfre/AudioDShowEncoder/ ----- Original Message ----- From: "Stef Heyenrath" To: Sent: Saturday, January 17, 2004 12:55 PM Subject: [Matroska-devel] Next question about MUX > I did not read the documentation about matroska, so if it is described > somewhere please tell me ! > > I want to mux and avi and and mp3 with the matroska mux filter into a > matroska file (.mkv) > > When i do this the following code cannot work : > > // QueryInterface for some basic interfaces > pigb->QueryInterface(IID_IMediaControl, (void **)&pimc); > pigb->QueryInterface(IID_IMediaEventEx, (void **)&pimex); > pigb->QueryInterface(IID_IMediaSeeking, (void**)&pSeek); > > lstart = 0; > lend = (LONGLONG) (TIMEFORMAT * l_split_at_milli_sec); > > hr = pSeek->GetTimeFormat(&timeFormat); > hr = pSeek->GetDuration(&duration); > hr = pSeek->GetPositions(&Current,&Stop); > > The "pSeek" functions return "NOT Implemented errors" ? > > Please help me ! > > > grtz, > Stef > > > _______________________________________________ > Matroska-devel mailing list > Matroska-devel at lists.matroska.org > http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel From gabest at freemail.hu Wed Jan 14 16:23:05 2004 From: gabest at freemail.hu (Gabest) Date: Wed, 14 Jan 2004 16:23:05 +0100 Subject: [Matroska-devel] ChapterTrack References: <40053C52.2080204@free.fr> Message-ID: <02f201c3dab2$4e924af0$fa0aa8c0@pgcp> > Does anyone use these elements right now ? > > ChapterTrack 4+ [8F] - - - sub-elements > ChapterTrackNumber 5+ [89] - >0 - u-integer I do! Wait, I don't need them either :P From steve.lhomme at free.fr Mon Jan 19 17:50:44 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Mon, 19 Jan 2004 17:50:44 +0100 Subject: [Matroska-devel] ChapterTrack In-Reply-To: <02f201c3dab2$4e924af0$fa0aa8c0@pgcp> References: <40053C52.2080204@free.fr> <02f201c3dab2$4e924af0$fa0aa8c0@pgcp> Message-ID: <400C0AE4.7010609@free.fr> It has been decided that Pamel will take care of these elements :) Gabest wrote: >>Does anyone use these elements right now ? >> >>ChapterTrack 4+ [8F] - - - sub-elements >>ChapterTrackNumber 5+ [89] - >0 - u-integer > > > I do! Wait, I don't need them either :P From gabest at freemail.hu Mon Jan 19 18:43:21 2004 From: gabest at freemail.hu (Gabest) Date: Mon, 19 Jan 2004 18:43:21 +0100 Subject: [Matroska-devel] ChapterTrack References: <40053C52.2080204@free.fr> <02f201c3dab2$4e924af0$fa0aa8c0@pgcp> <400C0AE4.7010609@free.fr> Message-ID: <070a01c3deb3$bb323d50$0100a8c0@i2400p4> "Date: Wed, 14 Jan 2004 16:23:05 +0100" No idea why this email got here so slooooow :) > It has been decided that Pamel will take care of these elements :) > > Gabest wrote: > > >>Does anyone use these elements right now ? > >> > >>ChapterTrack 4+ [8F] - - - sub-elements > >>ChapterTrackNumber 5+ [89] - >0 - u-integer > > > > > > I do! Wait, I don't need them either :P > > > _______________________________________________ > Matroska-devel mailing list > Matroska-devel at lists.matroska.org > http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel > > > From paul at msn.com Mon Jan 19 19:50:21 2004 From: paul at msn.com (Paul Bryson) Date: Mon, 19 Jan 2004 12:50:21 -0600 Subject: [Matroska-devel] Re: ChapterTrack References: <40053C52.2080204@free.fr> <02f201c3dab2$4e924af0$fa0aa8c0@pgcp> <400C0AE4.7010609@free.fr> Message-ID: Jory uses them and needs them for the fb2k plugin. Having multiple songs/track and multiple tracks requires it. (You could do this with a control track, but there isn't one right now.) "Steve Lhomme" wrote... > It has been decided that Pamel will take care of these elements :) > > Gabest wrote: > > >>Does anyone use these elements right now ? > >> > >>ChapterTrack 4+ [8F] - - - sub-elements > >>ChapterTrackNumber 5+ [89] - >0 - u-integer > > > > > > I do! Wait, I don't need them either :P From niemayer at isg.de Tue Jan 20 12:03:02 2004 From: niemayer at isg.de (Peter Niemayer) Date: Tue, 20 Jan 2004 12:03:02 +0100 Subject: [Matroska-devel] Re: Gentoo In-Reply-To: <40096AD6.9070103@free.fr> References: <4007D33F.10901@free.fr> <40088006.2040600@isg.de> <40096AD6.9070103@free.fr> Message-ID: <400D0AE6.6090706@isg.de> Steve Lhomme wrote: >>> Apparently it compiles on AMD64 systems. Dunno if it works. >> >> It does work, though there are a number of warnings, most of which >> are not too scary, %d vs. %ld vs. %lld stuff in "prints" and alike. > > Any log of the compilation would be appreciated (hopefully with the > latest CVS version). In the latest libebml-0.64/libmatroska-0.6.3 sources it seems only one problem is still present: g++ -c -Wall -Wno-unknown-pragmas -ansi -fno-gnu-keywords -Wshadow -I/data/home/niemayer/inst/libebml-0.6.4/make/linux/ ../.. -o /data/home/niemayer/inst/libebml-0.6.4/make/linux/../../src/EbmlContexts.o /data/home/niemayer/inst/libebml-0.6 .4/make/linux/../../src/EbmlContexts.cpp In file included from /data/home/niemayer/inst/libebml-0.6.4/src/EbmlContexts.cpp:39: /data/home/niemayer/inst/libebml-0.6.4/ebml/EbmlCrc32.h: In function `bool libebml::IsAlignedOn(const void*, unsigned int)': /data/home/niemayer/inst/libebml-0.6.4/ebml/EbmlCrc32.h:148: warning: cast from pointer to integer of different size /data/home/niemayer/inst/libebml-0.6.4/ebml/EbmlCrc32.h:148: warning: cast from pointer to integer of different size A sizeof(const void *) is 8 on x86_64, while sizeof(unsigned int) == 4. Cheers, Peter Niemayer From gabest at freemail.hu Tue Jan 20 19:15:46 2004 From: gabest at freemail.hu (Gabest) Date: Tue, 20 Jan 2004 19:15:46 +0100 Subject: [Matroska-devel] mpeg2 in mkv References: <4007D33F.10901@free.fr> <40088006.2040600@isg.de><40096AD6.9070103@free.fr> <400D0AE6.6090706@isg.de> Message-ID: <09d501c3df81$6cfc38b0$0100a8c0@i2400p4> Is there a sample anywhere yet? Please, I need one :) From paul at msn.com Tue Jan 20 19:24:30 2004 From: paul at msn.com (Paul Bryson) Date: Tue, 20 Jan 2004 12:24:30 -0600 Subject: [Matroska-devel] Spec update regarding audio timecodes Message-ID: This has been touched on briefly before, but it needs to be finalized so that we can add it to the specs. When storing timecodes for an audio stream, the TimecodeScale must have an accuracy of at least twice that of audio samplerate, otherwise there are rounding errors that prevent you from knowing the precise location of a sample. As was mentioned once (by Tronic I think), if you specify which direction to round in each case, then you can decrease the TimecodeScale to the same level of accuracy of the audio samplerate, allowing you to double your possible Cluster size. This also becomes useful for cases where you have a TimecodeScale of 1ms, and you have very small audio packet sizes. So, we just need to specify which way to round for all cases. For instance, if the first sample of an audio packet is sample 13,824 in an audio stream with a samplerate of 44100Hz, then your time in nanoseconds will be (13824 / 44100) * 1000000000 = ~313469387ns Twice the accuracy of the samplerate would be (1 / 88200) * 1000000000 = ~11338ns Which only gives us a maximum possible Cluster size of 743047168ns, or 0.7 seconds. By matching the accuracy we could get a full 1.4 seconds in a cluster, significant decreasing overhead. But doing this, we reach rounding errors. Matching the accuracy of the samplerate would be (1 / 88200) * 1000000000 = ~22676ns To store the above audio packet using a TimecodeScale of 22676, you would use: 3213061224 / 2276 = 13768.5856 So, do you store the timecode as 13768 or 13769? Pamel From alexander.noe at s2001.tu-chemnitz.de Tue Jan 20 20:06:53 2004 From: alexander.noe at s2001.tu-chemnitz.de (=?ISO-8859-1?Q?Alexander_No=E9?=) Date: Tue, 20 Jan 2004 20:06:53 +0100 Subject: [Matroska-devel] Spec update regarding audio timecodes In-Reply-To: References: Message-ID: <400D7C4D.4090905@hrz.tu-chemnitz.de> Paul Bryson wrote: >This has been touched on briefly before, but it needs to be finalized so that we >can add it to the specs. > >When storing timecodes for an audio stream, the TimecodeScale must have an >accuracy of at least twice that of audio samplerate... > I guess you know that will screw up the idea/sense of clusters? (unless you refered only to MKA files) Alex From paul at msn.com Tue Jan 20 20:31:38 2004 From: paul at msn.com (Paul Bryson) Date: Tue, 20 Jan 2004 13:31:38 -0600 Subject: [Matroska-devel] Re: Spec update regarding audio timecodes References: <400D7C4D.4090905@hrz.tu-chemnitz.de> Message-ID: "Alexander No?" wrote... > Paul Bryson wrote: > > >This has been touched on briefly before, but it needs to be finalized so that we > >can add it to the specs. > > > >When storing timecodes for an audio stream, the TimecodeScale must have an > >accuracy of at least twice that of audio samplerate... > > > I guess you know that will screw up the idea/sense of clusters? (unless > you refered only to MKA files) Don't forget the rest of that sentence, "otherwise there are rounding errors that prevent you from knowing the precise location of a sample." If you don't want to know the precise location of the sample, then you don't need that accurate of a TimecodeScale. This is only when you want something that precise. IE, for MKAs, or very very precise video editing. Pamel From moritz at bunkus.org Tue Jan 20 20:38:22 2004 From: moritz at bunkus.org (Moritz Bunkus) Date: Tue, 20 Jan 2004 20:38:22 +0100 Subject: [Matroska-devel] Re: Spec update regarding audio timecodes In-Reply-To: References: <400D7C4D.4090905@hrz.tu-chemnitz.de> Message-ID: <20040120193822.GR26064@bunkus.org> Heya, a technality. We are writing specs, and the RFCs have long ago agreed upon the meaning of the words SHOULD, MUST etc. Let's please use those. Alex is right - if you write must (ignoring the case) this implies that programs that don't do that are non-spec compliant. 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 Tue Jan 20 20:43:08 2004 From: alexander.noe at s2001.tu-chemnitz.de (=?ISO-8859-1?Q?Alexander_No=E9?=) Date: Tue, 20 Jan 2004 20:43:08 +0100 Subject: [Matroska-devel] Re: Spec update regarding audio timecodes In-Reply-To: <20040120193822.GR26064@bunkus.org> References: <400D7C4D.4090905@hrz.tu-chemnitz.de> <20040120193822.GR26064@bunkus.org> Message-ID: <400D84CC.1070602@hrz.tu-chemnitz.de> Moritz Bunkus wrote: >Heya, > >a technality. We are writing specs, and the RFCs have long ago agreed >upon the meaning of the words SHOULD, MUST etc. Let's please use >those. Alex is right - if you write must (ignoring the case) this >implies that programs that don't do that are non-spec compliant. > > ... and saying 'otherwise blah would happen' just illustrates bad consequences. For those who don't know, here is the Spec language: - must: mandatory. Violating a 'must' is not acceptable under any circumstances - shall := must (!!) - should = highly recommended to be followed (as in 'a cluster should not be as large as 200 MB') - may = it would be nice if Alex From paul at msn.com Tue Jan 20 20:50:45 2004 From: paul at msn.com (Paul Bryson) Date: Tue, 20 Jan 2004 13:50:45 -0600 Subject: [Matroska-devel] Re: Re: Spec update regarding audio timecodes References: <400D7C4D.4090905@hrz.tu-chemnitz.de> <20040120193822.GR26064@bunkus.org> <400D84CC.1070602@hrz.tu-chemnitz.de> Message-ID: "Alexander No?" wrote... > Moritz Bunkus wrote: > > >Heya, > > > >a technality. We are writing specs, and the RFCs have long ago agreed > >upon the meaning of the words SHOULD, MUST etc. Let's please use > >those. Alex is right - if you write must (ignoring the case) this > >implies that programs that don't do that are non-spec compliant. > > > > > ... and saying 'otherwise blah would happen' just illustrates bad > consequences. > > For those who don't know, here is the Spec language: > - must: mandatory. Violating a 'must' is not acceptable under any > circumstances > - shall := must (!!) > - should = highly recommended to be followed (as in 'a cluster should > not be as large as 200 MB') > - may = it would be nice if About the question..... Pamel From paul at msn.com Tue Jan 20 21:01:07 2004 From: paul at msn.com (Paul Bryson) Date: Tue, 20 Jan 2004 14:01:07 -0600 Subject: [Matroska-devel] RFC 80085 - Required TimecodeScale for sample accurate seeking Message-ID: Status of this Memo This document specifies system whereby a system of rounding is specified so as to maximize the possible TimecodeScale for efficient usage. Abstract This document only applies to cases where a precise audio sample is required, all other situations where the required seeking accuracy of a stream is less than 0.5ms should ignore this document. This has been touched on briefly before, but it needs to be finalized so that we can add it to the specs. When storing timecodes for an audio stream, the TimecodeScale must have an accuracy of at least twice that of audio samplerate, otherwise there are rounding errors that prevent you from knowing the precise location of a sample. As was mentioned once (by Tronic I think), if you specify which direction to round in each case, then you can decrease the TimecodeScale to the same level of accuracy of the audio samplerate, allowing you to double your possible Cluster size. This also becomes useful for cases where you have a TimecodeScale of 1ms, and you have very small audio packet sizes. So, we just need to specify which way to round for all cases. For instance, if the first sample of an audio packet is sample 13,824 in an audio stream with a samplerate of 44100Hz, then your time in nanoseconds will be (13824 / 44100) * 1000000000 = ~313469387ns Twice the accuracy of the samplerate would be (1 / 88200) * 1000000000 = ~11338ns Which only gives us a maximum possible Cluster size of 743047168ns, or 0.7 seconds. By matching the accuracy we could get a full 1.4 seconds in a cluster, significant decreasing overhead. But doing this, we reach rounding errors. Matching the accuracy of the samplerate would be (1 / 88200) * 1000000000 = ~22676ns To store the above audio packet using a TimecodeScale of 22676, you would use: 3213061224 / 2276 = 13768.5856 So, do you store the timecode as 13768 or 13769? Pamel From moritz at bunkus.org Tue Jan 20 21:05:28 2004 From: moritz at bunkus.org (Moritz Bunkus) Date: Tue, 20 Jan 2004 21:05:28 +0100 Subject: [Matroska-devel] Spec update regarding audio timecodes In-Reply-To: References: Message-ID: <20040120200528.GS26064@bunkus.org> Heya, the problem is that I'm not awfully good at this kind of stuff. I make too many errors when doing calculations. What I know, so far, is that if we want sample precision and use scaling that allows such high a precision we'll end up with tiny clusters. Very, very tiny clusters. And a lot of overhead. Shrugging this issue off with 'if they want sample precision than they'll have to deal with it' is a bad way to go, IMHO. So until we figure out a better way to store the relative block timecode there is not much use in having such strict specs. My opinion. Mosu -- If Darl McBride was in charge, he'd probably make marriage unconstitutional too, since clearly it de-emphasizes the commercial nature of normal human interaction, and probably is a major impediment to the commercial growth of prostitution. - Linus Torvalds From paul at msn.com Tue Jan 20 22:35:49 2004 From: paul at msn.com (Paul Bryson) Date: Tue, 20 Jan 2004 15:35:49 -0600 Subject: [Matroska-devel] RFC 1134 - New EBML Block design Message-ID: The idea of this post is to display a new Block design that is more flexible and addresses issues with the current Block design. From this point the new Block design will be labeled Block2. Block2 consists of three header sections. TrackNumber, Time, and Bitflags. Each header section is required and is coded for size using EBML coding methods. The order of the headers are 1. TrackNumber 2. Time 3. Bitflags The TrackNumber is an EBML UINT. This number indicates the Track that the data blocks contained within the Block2 belong to. The Time is an EBML SINT that is used to calculate the timecode of the Block2. Exact method depends on the bitflags used below. 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 Definitions of the Bitflags are as follows: Lacing flags layout is identical to the original Block layout. a.. 00 : no lacing a.. 01 : Xiph lacing a.. 11 : EBML lacing a.. 10 : fixed-size lacing 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. The Gap flag is set when the Track is empty after this Block ends (data should not be rendered from this timecode, cache can be flushed). This is identical in use to the original Block design. The reason that this is at bit 7 is that it should rarely be used, and will only take one extra byte when it is. Four more flags may be added that would be more commonly used, without needing to expand the size of the Bit flags header. Benefits: 1. By introducing a completely new Block structure with a new ID, we can be sure that current parsers won't b0rk on the data. It is better for the parser to simply skip the data than to break while trying to read data. 2. Any size Cluster can be made with the variable length timecodes. So, efficiency can be determined by this. 3. Seeking can be done by samples instead of timecodes. 4. Any number of bit flags can be added, changing the structure of the Block2 to accommodate new features. Other possibilities: 1. Two of the bit flags could be used to indicate forward or backward references(as originally planned). This would remove accuracy in the case of a damaged file, but would decrease overhead by no longer needing to use the ReferenceBlock element in most cases. 3 bytes for P frames and 6 bytes for B frames would be saved if using this. Please correct any poor spec grammar while commenting on this. Other: * The Cluster's Sample element would contain a number of samples to use as an offset for the Block2 with the Time bit flag set. From steve.lhomme at free.fr Tue Jan 20 22:43:13 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Tue, 20 Jan 2004 22:43:13 +0100 Subject: [Matroska-devel] Re: Spec update regarding audio timecodes In-Reply-To: <20040120193822.GR26064@bunkus.org> References: <400D7C4D.4090905@hrz.tu-chemnitz.de> <20040120193822.GR26064@bunkus.org> Message-ID: <400DA0F1.2050703@free.fr> Moritz Bunkus wrote: > Heya, > > a technality. We are writing specs, and the RFCs have long ago agreed > upon the meaning of the words SHOULD, MUST etc. Let's please use > those. Alex is right - if you write must (ignoring the case) this > implies that programs that don't do that are non-spec compliant. I've used a lot of RFCs at work and I definitely agree ! From steve.lhomme at free.fr Tue Jan 20 23:03:41 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Tue, 20 Jan 2004 23:03:41 +0100 Subject: [Matroska-devel] Spec update regarding audio timecodes In-Reply-To: References: Message-ID: <400DA5BD.4090203@free.fr> I think things should be explained in a more specific way... To compute the timecode of a Block we use the following formula : a) Timecode in ns = (Block Timecode Value * Track TimecodeScale + Cluster Timecode) * Global TimecodeScale That means we have : b) float = (int16 * float + uint64) * uint64 Which is usually transformed into an integer : c) uint64 = (int16 * float + uint64) * uint64 In most cases, the Track TimecodeScale is 1.0, so we get : d) uint64 = (int16 + uint64) * uint64 So the sample accurate problem only occurs for audio. For video and subs, we can keep the Track TimecodeScale to 1.0. So how can we mix audio and video and keep sample accuracy seeking ? You just use a sufficient Track TimecodeScale on the audio track. Let's take an example. Audio at 44100 Hz (PCM) Video at 25fps (RGB) A good Cluster size is usually 2s long. That means 88200 = 2*44100 audio samples 50 = 2*25 video frames Let's take the first Cluster (they are all equivalent for the example). The Cluster timecode is 0. And usually the Global TimecodeScale is 1,000,000. So for the video formula d) becomes : VideoTimecode = int16 * uint64 And for the audio formula c) becomes : AudioTimecode = int16 * float * uint64 The range of the resulting uint64 is from 0 to 2,000,000,000. So without the Global TimecodeScale we have : VideoTimecode = int16 and AudioTimecode = int16 * float With the timecodes ranging from 0 to 2,000. For the video, there is no problem as a int16 ranges from 0 to 32767 (in the positive side). But for the audio, we need to have 88200 samples that can only span over 32768 values. This is basically impossible. Conclusion : it is impossible to have large Clusters & Sample accurate precision of the timecode. And the bigger the audio sampling rate, the smaller the Cluster has to be. (in this case we need a Cluster smaller than 0.743s = 32768/44100 to be able to have a distinctive timecode for each sample) From moritz at bunkus.org Tue Jan 20 23:10:50 2004 From: moritz at bunkus.org (Moritz Bunkus) Date: Tue, 20 Jan 2004 23:10:50 +0100 Subject: [Matroska-devel] RFC 1134 - New EBML Block design In-Reply-To: References: Message-ID: <20040120221050.GU26064@bunkus.org> Heya, Yay, a new block design. I strongly feel we should discuss this. > The order of the headers are > > 1. TrackNumber > 2. Time > 3. Bitflags That's good. Having the same order certainly lesses the overhead/amount of new code. > The Time is an EBML SINT that is used to calculate the timecode of the Block2. > Exact method depends on the bitflags used below. Certainly an improvement over a fixed 16bit sint, IMHO. > Bitflags are as follows. > Bit > 0-1 Lacing flags > 2 Time flag > 3-6 Unused > 7 Gap flag If we be radical we can also think about using simple flags for track types. We could use the bits 3 and 4 like this: 00: I frame 01: P frame 10: B frame 11: invalid The ReferenceBlocks would then be _optional_ for such a block. If they're not present the references are implicitely given. However, if some special application needs some special references it may still add them. The number / types of references must then comply to the flags used. This would save us a lot of space. > Lacing flags layout is identical to the original Block layout. Good. > 1. By introducing a completely new Block structure with a new ID, we can be sure > that current parsers won't b0rk on the data. It is better for the parser to > simply skip the data than to break while trying to read data. I agree. > 1. Two of the bit flags could be used to indicate forward or backward > references(as originally planned). This would remove accuracy in the case of a > damaged file, but would decrease overhead by no longer needing to use the > ReferenceBlock element in most cases. 3 bytes for P frames and 6 bytes for B > frames would be saved if using this. Maybe I should just read the mail completely before I start spitting out stuff that you've already said ;) All in all I like this more flexible block layout very much. Mosu -- If Darl McBride was in charge, he'd probably make marriage unconstitutional too, since clearly it de-emphasizes the commercial nature of normal human interaction, and probably is a major impediment to the commercial growth of prostitution. - Linus Torvalds From steve.lhomme at free.fr Tue Jan 20 23:24:49 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Tue, 20 Jan 2004 23:24:49 +0100 Subject: [Matroska-devel] RFC 80085 - Required TimecodeScale for sample accurate seeking In-Reply-To: References: Message-ID: <400DAAB1.5000209@free.fr> Now let's see another example. A file using only audio (MKA file). You only have one audio track at 44100 Hz. My point is that the Global TimecodeScale can remain at 1,000,000. But the Track TimecodeScale should be 1000/44100 = 0,022676... So imagine you have Audio Blocks of 1152 samples. Here is a list Of values in the first Cluster : Block # Timecode 1st Smpl Final Timecode Block Timecode 1 0 0 0 2 1152/44100 s 26,122,449ns 1152 3 2*1152/44100 s 52,244,898ns 2304 4 3*1152/44100 s 78,367,347ns 3456 ...... (using formula AudioTimecode = int16 * float * uint64) So for each Block you know exactly the sample count on which starts the Block. This way, if you want to seek to sample 2353 you compute the timecode : AudioTimecode = 2353/44100 = 53,356,009ns So you know that the Block to use is the Block # 3 in Cluster # 1. And with the sample count, you know what is the exact sample you're looking for (the 50th). I don't know if the computing of the Block Timecode might lead to rounding errors... From steve.lhomme at free.fr Tue Jan 20 23:31:35 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Tue, 20 Jan 2004 23:31:35 +0100 Subject: [Matroska-devel] RFC 1134 - New EBML Block design In-Reply-To: References: Message-ID: <400DAC47.2080109@free.fr> Paul Bryson wrote: > Benefits: > > 1. By introducing a completely new Block structure with a new ID, we can be sure > that current parsers won't b0rk on the data. It is better for the parser to > simply skip the data than to break while trying to read data. > > 2. Any size Cluster can be made with the variable length timecodes. So, > efficiency can be determined by this. > > 3. Seeking can be done by samples instead of timecodes. > > 4. Any number of bit flags can be added, changing the structure of the Block2 to > accommodate new features. Right now we are *very* far from any of those limitations. So introducing a cleaner Block is just cosmetic and useless to me. Or you'll have to prove with number that this Block is more space efficient than the current one (which I'm almost sure it's not). > Other: > > * The Cluster's Sample element would contain a number of samples to use as an > offset for the Block2 with the Time bit flag set. Removed from the specs, because proven stupid already... From steve.lhomme at free.fr Tue Jan 20 23:33:38 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Tue, 20 Jan 2004 23:33:38 +0100 Subject: [Matroska-devel] RFC 1134 - New EBML Block design In-Reply-To: <20040120221050.GU26064@bunkus.org> References: <20040120221050.GU26064@bunkus.org> Message-ID: <400DACC2.7080702@free.fr> Moritz Bunkus wrote: > If we be radical we can also think about using simple flags for track > types. We could use the bits 3 and 4 like this: > > 00: I frame > 01: P frame > 10: B frame > 11: invalid > > The ReferenceBlocks would then be _optional_ for such a block. If > they're not present the references are implicitely given. However, if > some special application needs some special references it may still add > them. The number / types of references must then comply to the flags > used. > > This would save us a lot of space. Each time you introduce such design differences it makes the format 2x more complicated to understand/parse/handle/whatever. I'm against adding these inferior bit system compared to the reference system. > All in all I like this more flexible block layout very much. Why ? From paul at msn.com Wed Jan 21 08:02:43 2004 From: paul at msn.com (Paul Bryson) Date: Wed, 21 Jan 2004 01:02:43 -0600 Subject: [Matroska-devel] Re: RFC 1134 - New EBML Block design References: <400DAC47.2080109@free.fr> Message-ID: "Steve Lhomme" wrote... > introducing a cleaner Block is just cosmetic and useless to me. Or > you'll have to prove with number that this Block is more space efficient > than the current one (which I'm almost sure it's not). Well, either RFC 80085 or 1134 needs to be done. Pamel From steve.lhomme at free.fr Wed Jan 21 09:51:23 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Wed, 21 Jan 2004 09:51:23 +0100 Subject: [Matroska-devel] Re: RFC 1134 - New EBML Block design In-Reply-To: References: <400DAC47.2080109@free.fr> Message-ID: <400E3D8B.4030404@free.fr> Paul Bryson wrote: > "Steve Lhomme" wrote... > >>introducing a cleaner Block is just cosmetic and useless to me. Or >>you'll have to prove with number that this Block is more space efficient >>than the current one (which I'm almost sure it's not). > > > Well, either RFC 80085 or 1134 needs to be done. The problem of adding a "parallel" element is not a technical problem. It's a matter that we have to inform every matroska library developper that the format in the current form sucks and should be updated, that they have to code something new that does almost exactly the same thing as it used to. Hopefully there are still no reports of such problems with our former tagging system... Now I remember why we wanted to finish the specs before coding. Because when things are in the public it's too late to change it ! And it's funny that you, Paul, come up with all these changes that will render all current players useless and at the same time you want to freeze the specs to show that Matroska is a stable/solid format. One day you should make up your mind. From paul at msn.com Wed Jan 21 10:06:04 2004 From: paul at msn.com (Paul Bryson) Date: Wed, 21 Jan 2004 03:06:04 -0600 Subject: [Matroska-devel] Re: Re: RFC 1134 - New EBML Block design References: <400DAC47.2080109@free.fr> <400E3D8B.4030404@free.fr> Message-ID: "Steve Lhomme" wrote... > And it's funny that you, Paul, come up with all these changes that will > render all current players useless and at the same time you want to > freeze the specs to show that Matroska is a stable/solid format. One day > you should make up your mind. If RFC 80085 is picked, then it needs to be added to the specs ASAP. If RFC 1134 is picked, then it can wait until 2.0. Although, there is nothing to prevent them both from being implemented. It should also be noted that I came up with the current frame referencing system, and the tags system that was replaced. I have a big desire to do things that are more aesthetically pleasing, but in practice the benefit often lies elsewhere. For instance the tags, they were just to difficult to implement in their original form. Some things are nice when done right, but just work better with a dirty hack. Pamel From chris at matroska.org Wed Jan 21 11:25:33 2004 From: chris at matroska.org (Christian HJ Wiesner) Date: Wed, 21 Jan 2004 11:25:33 +0100 Subject: [Matroska-devel] mpeg2 in mkv In-Reply-To: <09d501c3df81$6cfc38b0$0100a8c0@i2400p4> References: <4007D33F.10901@free.fr> <40088006.2040600@isg.de><40096AD6.9070103@free.fr> <400D0AE6.6090706@isg.de> <09d501c3df81$6cfc38b0$0100a8c0@i2400p4> Message-ID: <400E539D.4080701@matroska.org> Spyder sent me one, but i cant play it !! Gabest wrote: >Is there a sample anywhere yet? Please, I need one :) >_______________________________________________ >Matroska-devel mailing list >Matroska-devel at lists.matroska.org >http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel > > From steve.lhomme at free.fr Wed Jan 21 16:44:41 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Wed, 21 Jan 2004 16:44:41 +0100 Subject: [Matroska-devel] Re: RFC 1134 - New EBML Block design In-Reply-To: References: <400DAC47.2080109@free.fr> Message-ID: <400E9E69.9040804@free.fr> Paul Bryson wrote: > "Steve Lhomme" wrote... > >>introducing a cleaner Block is just cosmetic and useless to me. Or >>you'll have to prove with number that this Block is more space efficient >>than the current one (which I'm almost sure it's not). > > > Well, either RFC 80085 or 1134 needs to be done. If something needs to be done it must come after the 1. freeze. That's a matter of credibility of the format. Introducing a new Block in 2 is not a problem. But right now we have 1. almost done and it's not time to introduce new vital things to support. (even the new chapter flags are not well supported yet) From moritz at bunkus.org Wed Jan 21 16:57:39 2004 From: moritz at bunkus.org (Moritz Bunkus) Date: Wed, 21 Jan 2004 16:57:39 +0100 Subject: [Matroska-devel] Re: RFC 1134 - New EBML Block design In-Reply-To: <400E9E69.9040804@free.fr> References: <400DAC47.2080109@free.fr> <400E9E69.9040804@free.fr> Message-ID: <20040121155739.GX26064@bunkus.org> Heya, I'm perfectly fine with solving this properly after 1.0. It gives us more time to come up / agree upon the best solution - and you're right, it's a matter of credibility. 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 chris at matroska.org Wed Jan 21 17:42:12 2004 From: chris at matroska.org (Christian HJ Wiesner) Date: Wed, 21 Jan 2004 17:42:12 +0100 Subject: [Matroska-devel] Re: RFC 1134 - New EBML Block design In-Reply-To: <20040121155739.GX26064@bunkus.org> References: <400DAC47.2080109@free.fr> <400E9E69.9040804@free.fr> <20040121155739.GX26064@bunkus.org> Message-ID: <400EABE4.7030500@matroska.org> Moritz Bunkus wrote: >I'm perfectly fine with solving this properly after 1.0. It gives us >more time to come up / agree upon the best solution - and you're right, >it's a matter of credibility. Mosu > > So, now that we know a new block type will come with 2.0, how do we do sample accurate seeking with current block structure ? Pamel is right, we need to define a way to do it, and quick, and adapt the specs accordingly. Christian From alexander.noe at s2001.tu-chemnitz.de Wed Jan 21 18:53:00 2004 From: alexander.noe at s2001.tu-chemnitz.de (=?ISO-8859-1?Q?Alexander_No=E9?=) Date: Wed, 21 Jan 2004 18:53:00 +0100 Subject: [Matroska-devel] Re: RFC 1134 - New EBML Block design In-Reply-To: <400EABE4.7030500@matroska.org> References: <400DAC47.2080109@free.fr> <400E9E69.9040804@free.fr> <20040121155739.GX26064@bunkus.org> <400EABE4.7030500@matroska.org> Message-ID: <400EBC7C.2030209@hrz.tu-chemnitz.de> Christian HJ Wiesner wrote: > So, now that we know a new block type will come with 2.0, how do we do > sample accurate seeking with current block structure ? Pamel is right, > we need to define a way to do it, and quick, and adapt the specs > accordingly. If you quickly define sth, you get ogm. Alex From gabest at freemail.hu Wed Jan 21 19:15:31 2004 From: gabest at freemail.hu (Gabest) Date: Wed, 21 Jan 2004 19:15:31 +0100 Subject: [Matroska-devel] mpeg2 in mkv References: <4007D33F.10901@free.fr> <40088006.2040600@isg.de><40096AD6.9070103@free.fr> <400D0AE6.6090706@isg.de> <09d501c3df81$6cfc38b0$0100a8c0@i2400p4> <400E539D.4080701@matroska.org> Message-ID: <0cd301c3e04a$8e752730$0100a8c0@i2400p4> Thanks for uploading a sample. soraya.mkv plays fine, except the display size was not set correctly (same as the resolution). From steve.lhomme at free.fr Wed Jan 21 19:21:41 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Wed, 21 Jan 2004 19:21:41 +0100 Subject: [Matroska-devel] Re: RFC 1134 - New EBML Block design In-Reply-To: <400EBC7C.2030209@hrz.tu-chemnitz.de> References: <400DAC47.2080109@free.fr> <400E9E69.9040804@free.fr> <20040121155739.GX26064@bunkus.org> <400EABE4.7030500@matroska.org> <400EBC7C.2030209@hrz.tu-chemnitz.de> Message-ID: <400EC335.80209@free.fr> Alexander No? wrote: > Christian HJ Wiesner wrote: > >> So, now that we know a new block type will come with 2.0, how do we do >> sample accurate seeking with current block structure ? Pamel is right, >> we need to define a way to do it, and quick, and adapt the specs >> accordingly. > > > If you quickly define sth, you get ogm. Very good point ! answer for Christian : make Clusters of 0.73s or 1.4s (if you put the Cluster timecode in the middle of the whole Cluster spanning time). From paul at msn.com Wed Jan 21 19:24:57 2004 From: paul at msn.com (Paul Bryson) Date: Wed, 21 Jan 2004 12:24:57 -0600 Subject: [Matroska-devel] Re: Re: RFC 1134 - New EBML Block design References: <400DAC47.2080109@free.fr> <400E9E69.9040804@free.fr> <20040121155739.GX26064@bunkus.org> <400EABE4.7030500@matroska.org> Message-ID: "Christian HJ Wiesner" wrote... > So, now that we know a new block type will come with 2.0 No, it MIGHT come with 2.0. The point was to get some ideas out there and comment on the structure. If we did release a new Block structure, then we don't have any restrictions on it, and what is the absolute best way to make it. Once we design "the perfect Block2", we need to look at the cost/benefit ratio of it. Does it introduce enough of an advantage over the current system to warrant using it. And that will be answered by the programmers. Pamel From spyder at matroska.org Wed Jan 21 23:26:20 2004 From: spyder at matroska.org (John Cannon) Date: Wed, 21 Jan 2004 16:26:20 -0600 Subject: [Matroska-devel] mpeg2 in mkv In-Reply-To: <0cd301c3e04a$8e752730$0100a8c0@i2400p4> References: <4007D33F.10901@free.fr> <40088006.2040600@isg.de><40096AD6.9070103@free.fr> <400D0AE6.6090706@isg.de> <09d501c3df81$6cfc38b0$0100a8c0@i2400p4> <400E539D.4080701@matroska.org> <0cd301c3e04a$8e752730$0100a8c0@i2400p4> Message-ID: <400EFC8C.4040202@matroska.org> Gabest wrote: >Thanks for uploading a sample. soraya.mkv plays fine, except the display >size was not set correctly (same as the resolution). > >_______________________________________________ >Matroska-devel mailing list >Matroska-devel at lists.matroska.org >http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel > > > Yeah yeah...getting to that one ;) John From alexander.noe at s2001.tu-chemnitz.de Thu Jan 22 15:14:56 2004 From: alexander.noe at s2001.tu-chemnitz.de (=?ISO-8859-1?Q?Alexander_No=E9?=) Date: Thu, 22 Jan 2004 15:14:56 +0100 Subject: [Matroska-devel] Re: RFC 1134 - New EBML Block design In-Reply-To: <400EABE4.7030500@matroska.org> References: <400DAC47.2080109@free.fr> <400E9E69.9040804@free.fr> <20040121155739.GX26064@bunkus.org> <400EABE4.7030500@matroska.org> Message-ID: <400FDAE0.3030409@hrz.tu-chemnitz.de> Christian HJ Wiesner wrote: > Moritz Bunkus wrote: > >> I'm perfectly fine with solving this properly after 1.0. It gives us >> more time to come up / agree upon the best solution - and you're right, >> it's a matter of credibility. Mosu >> >> > So, now that we know a new block type will come with 2.0... Journalist!!! Alex From chris at matroska.org Sat Jan 24 08:51:58 2004 From: chris at matroska.org (Christian HJ Wiesner) Date: Sat, 24 Jan 2004 08:51:58 +0100 Subject: [Matroska-devel] muxed usf In-Reply-To: References: Message-ID: <4012241E.6000108@matroska.org> Hi, sorry to bring this up again guys, but i feel we would have to undertake something here, or all the hard work invested into USF is maybe in vain. I heard it through the grapevine that at least some of the guys making nice USF editors are planning to convert them to output SSA instaed, as USF is still not usable in MKV or OGM. Toff invested a lot of time into the USF specs, i feel there is not so much necessary to be done still, and we have them finished and USF working in MKV. As it seems impossible to motivate somebody to make USF muxing with EBML, i vote for muxing it the 'normal' way, means to put all the XMl data into a matroska block, with a timestamp and a duration. unmei, could you think about talking to jcsston about using his new MKV muxer plugin ( or maybe even spyder's modified MILK version ) and add direct USF in MKV muxing to your great editor ? If we have this done, it should be quite easy for Mosu to read those streams in mkvmerge, so we can mux them with video. Please guys, lets get this moving, or we risk to make ourselves look like complete idiots. USF has been around since more than one year now, and there are *5!* editors for it, and some of them should even be portable to Linux i heard ! Christian unmei wrote: > some random thoughts and approaches for muxing usf into matroska. > please keep in mind i have not much experience what is hard to > implement or takes much cpu power. also i am not implementing mkv, so > i dont know the internals -> that's why it's just a buch of thoughts > :) (RFC) > >------------------------------------------------------------------------ > >unmei 2003-12-11 > >usf in matroska (EBML) >-------------------------- >TAGS >*all tags are translated into EBML IDs >**tags that are inevitable get the lowest ID integer >**tags occuring the most often get as low ID integer as possible >**tags that denote tags requiring much processing get high IDs >**as we can assume we have all the most basic and skeleton tags today, new tags fall into the category "seldom used" or "high processing" and it is perfectly OK to assign them a high ID - like its inevitable as we assigned the low IDs already. >**also i think most new elements in USF will not be tags, but attributes >**hardware player support a subset of IDs starting at the lowest and going up to some specific ID . When they encounter a higher ID, they know its a rather special feature and can savely skip the entire entry or ignore the ID and process only its conten >t as if the high ID did not exist. The same applies to playback filters. > >EMBED >**Fonts embedded in XML-USF should be muxed into the MKV file as attachment file (and not stored in a in EBML-USF). >**Pictures (embedded in XML-USF or external to XML-USF) should be inlined base64 encoded. This will eventually cause picture to be stored multiple times, but it avoids the necessity to either have all embeds loaded into RAM during the entire playback or > seek to the embed during playback. >**Eventually the RAM chached method is faster and if the additional RAM used is no concern it were optimal since the embeds can be decoded before even start to playback (avoiding a CPU peak when encountering a picture). But embed without caching (read: >seek to the embed section and decode WHILE playback is in progress) is most likely going to kill the playability. >**with the first picture method, there is no in EBML-USF, with the second picture method we do need a . Consequently the issue which method for pictures should be used must be decided before EBML-USF is implemented since is a root >-level tag we need to know whether we need to assign a ID for it (assigning one now is safer than having to assign a higher ID later). > >OTHER POINTS >*are subtitle streams laced (interleaved with audio and video steams) ? I guess not...anyway EBML-USF should use the same method as used for other subtitle formats. >*a muxer must sort the by ascending start time. USF allows wild order, but this is sure not optimal for playback (u96 does order on save if you tell it to do so, but its not a must). >*XML-USF files containing multiple sections are threaten like multiple subtitle files (each gets a stream, with metadata,styles... doubled). >*If the subtitle streams are laced, a different approach were to interleave the also by ascending start time, howeve this way the playback filter must determine for each whether it belongs to a "stream" that has to be displayed -- >eek. If subtitles are not laced, its preferred to simple order "per-stream". > > >PROPOSED TAG ID ORDER >top=low ID, bottom=high ID, >for shortness, some are on the same line: left is lower than right > >VERSION 1 : grouped > >USFSubtitles and its attributes ->"codec private", not assigning a ID > >subtitles >subtitle >text, br, b, i, u, font >karaoke, k >picture > >styles >style >fontstyle, position > >metadata >title, language, lanuageext, date, comment >author >name, email, url, task > >effects >effect >keyframes >keyframe > >embedded >b64file > >shapes >shape >point, polygon, polyline, csg-union, csg-diff, csg-inter, bspline > >[new tags] > > > >VERSION 2 : by nesting level > >subtitles >styles >metadata >effects >embedded >shapes > >subtitle >style >effect >b64file >shape > >text, karaoke, picture >fontstyle, position >title, language, lanuageext, date, comment, author >keyframes > >br, b, i, u, font, k >name, email, url, task >keyframe > >point, polygon, polyline, csg-union, csg-diff, csg-inter, bspline > >[new tags] > > > >VERSION 3 : root-level, then frequency above everything > >subtitles, styles, metadata, effects, embedded, shapes > >subtitle >text >br, font, b, i, u >karaoke, k >style >fontstyle, position > >picture >b64file >effect, keyframes, keyframe > >title, language, languageext, date, comment, author >name, email, url, task > >shape >point, polygon, polyline, csg-union, csg-diff, csg-inter, bspline > >----------------------------------- >personally i prefer version 3, this is the one i really tried to make a thight order. Version 1 and 2 are rather drafts to start with in case version 3 is widely rejected :) > >i've put the root-level on top in version 3 because i think it would be too confusing to encounter a root level element whose id were 30 or higher. A parser should in any case know what the root level-elements mean in order to decide whether the content > can be throw away as a whole. > >don't be confused by embedded, b64file, point, polygon.... they are not in the specs ;) > > >------------------------------------------------------------------------ > >_______________________________________________ >Matroska-devel mailing list >Matroska-devel at lists.matroska.org >http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel > > From christian at matroska.org Sun Jan 25 15:02:58 2004 From: christian at matroska.org (ChristianHJW) Date: Sun, 25 Jan 2004 15:02:58 +0100 Subject: [Matroska-devel] Re: [PATCH] new C only matroska demuxer In-Reply-To: <20040125112948.6EB0067A3E@mail.mplayerhq.hu> References: <40118A9D.9050402@matroska.org> <20040125112948.6EB0067A3E@mail.mplayerhq.hu> Message-ID: <4013CC92.7070905@matroska.org> Arpi wrote: > Hi, >>Aurelien, we have MPEG2 working in MKV now, if you want a sample file >>pls. come to the #matroska channel, it would be nice if you could add >>MPEG2 playback from MKV in your mplayer patch. VLC people have it >>working since today, Xine people got test files already ... > > What's teh sence of putting mpeg2 to mkv container??? > I can't see any reason why is it worth to do it. > It's like putting mp3 into .ogg, it can be done, but no one on > this earth do that. > A'rpi / Astral & ESP-team For us, MPEG2 is just simply a codec, like every other codec around, so we dont see any reason *NOT* to put it into MKV. We have found several different occasions where it could be useful, and others may turn up we havent thought of yet : - MPEG editing : We are planning on making a general use video editor tool based on MKV.That way any video format that can be transmuxed into MKV could be edited, namely MPEG1/2/4, RealVideo, DV video, etc. could be edited, and in combination with any supported audio format, and then converted to any other formats afterwards. Not a very clean way you might say, but definitely feasible. I dont know about Linux, but on Windows there are no good and free MPEG video editors available, and i dont know of any editor for RealVideo at all. - Analog capturing with MPEG2 and FLAC audio : We only need a real time MPEG2 DirectShow encoder filter ( based on libavcodec of course ), and we could do this already, and with any DirectShow based capturing tool. MPEG2 video gives excellent ration between bitrate and video quality, so its a very good alternative to lossless or MJPEG capturing. And the FLAC encoder consumes very little CPU compared to a MP2 or even AC3 encoder. - Combination of MPEG2 video and any other audio format : After all, a general use container should allow total freedom of the user, like AVI does. We have test files ( musisc videos ) with MPEG2 video and Vorbis audio, and they work great ;) ... Christian matroska project admin http://www.matroska.org From paul at msn.com Sun Jan 25 19:34:49 2004 From: paul at msn.com (Paul Bryson) Date: Sun, 25 Jan 2004 12:34:49 -0600 Subject: [Matroska-devel] Re: RFC 1134 - New EBML Block design References: <20040120221050.GU26064@bunkus.org> Message-ID: "Moritz Bunkus" wrote... > If we be radical we can also think about using simple flags for track > types. We could use the bits 3 and 4 like this: > > 00: I frame > 01: P frame > 10: B frame > 11: invalid I think Steve's original system was a little more intuitive. (Not available for viewing because of a CVS failure.) 00: No frames referenced. (I frame) 10: Frame with previous timecode referenced. (P frame) 01: Frame with following timecode referenced 11: Both previous and following timecodes referenced. (B frame) > The ReferenceBlocks would then be _optional_ for such a block. If > they're not present the references are implicitely given. However, if > some special application needs some special references it may still add > them. The number / types of references must then comply to the flags > used. Why prevent either/or situations? For instance, you could have a block that references the previous and following frames, plus another frame two previous. If using the flags, then you wouldn't have to write two of the timecodes, just the one not covered by the flags. But, some application might want to make special use of these and allowing them to use both the flags and the reference blocks shouldn't be a bad thing. > This would save us a lot of space. As stated, 3 bytes for every P frame and 6 for every B frame (while using 1ms accurate timecodes). For real world savings, we could use some very conservative settings from the XviD Matrix trailer. 3635 frames, of which 299 are Key frames, with at least 30% of the remaining being B frames and rest as P frames.But about 8% as keyframes, and this is for a high action trailer so the numbers will be very conservative compared to real life. But using these numbers, using a 2 hour movie at 24fps would yield 172,800 frames. So: 333,849 bytes for P frame references 286,156 bytes for B frame references 620,005 Total bytes for frame references If you allowed more than 1 consecutive B frame, you would get much higher B frame numbers and could exceed 1MB of overhead. This is of course fixed overhead that has nothing to do with the bitrate of the video. This also offers possibilities for using references with audio frames. MP3 can require the Block before it to decode the current content correctly, and it would be nice to know when that is the case without actually having to decode the Block. But, the current referencing system has to much overhead to do this efficiently. Pamel From chris at matroska.org Mon Jan 26 16:57:07 2004 From: chris at matroska.org (Christian HJ Wiesner) Date: Mon, 26 Jan 2004 16:57:07 +0100 Subject: [Matroska-devel] Variable Framerate, plugin based video editing tool Message-ID: <401538D3.1020609@matroska.org> Hi, i have the pleasure to tell you that there is a good chance that Mosu and Cyrius will work together on a new video editing tool. The new tool should not be based on any existing programs, but be more or less started from scratch. Mosu and Cyrius are currently in the process to agree on basic structure, and the matroska-devel ML will be used for these initial steps. A first draft of the scope of the program could look like that : - Variable Framerate ( VFR ) capable - Extendable via plugins, for both input/output containers - Standard editing Format is MKV ( matroska ) - Can handle at least one video stream, plus several audio and subtitles streams - X-platform, GUI made with wxwindows for improved portability - Possibility to extend to handling of multiple video streams for NLE ( Non-Linear Editing ) A possible road map could look like 1. Define basic structure, including the internal scripting 2. Define API for input/output modules 3. Allow muxing of MKV files, using different source formats 4. Implement simple cutting/editing based on frame number / timestamp ----- note : at this step mkvmerge becomes redundant 5. Add Preview for the most used and free formats ( via libavcodec ? licensing problems ? ) 6. Implement enhanced one step editing, similar to Virtualdub ( mark areas to be deleted / copied ) 7. Define a codec plugin API 8. Realize re-encoding of audio and video streams, using de/encoder plugins ----- note : at this step vdubmod becomes redundant 9. Adding NLE, with fades etc. As you all might be aware, this is a huge task and can not be completed by the two alone. It must be the goal of the complete matroska team to contribute to this project, mainly by adding usable input modules, so that step 4. could be achieved in reasonable time, so that the full scope of mkvmerge is matched by the new editor. After that, the definition of a codec plugin API and the creation of codecs based on this should be the mian goal, so we could finally lift matroska to a level where it can truely overcome AVI and VfW, and will get a general standard status for the future of video and audio encoding. I expect Mosu will have something to say here now, and i suppose he will get a lot more technical than i did, and also will answer with a lot of 'BUT's :-) . So please, before you reply to this email to tell us your opinion about it, wait for his email first. After all, i might have seen things too optimistic, as always ;-) .... Christian From steve.lhomme at free.fr Mon Jan 26 17:08:24 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Mon, 26 Jan 2004 17:08:24 +0100 Subject: [Matroska-devel] Variable Framerate, plugin based video editing tool In-Reply-To: <401538D3.1020609@matroska.org> References: <401538D3.1020609@matroska.org> Message-ID: <40153B78.5010605@free.fr> I think it would be good if you have a capture system directly to Matroska (no problems with dropped frames as in AVI) from either video-in, tuner or DV. Similar to what you can do with VDub but a bit better. Another idea would be to post a thread in a few forums (Doom9, VD) to ask all the features people can think of for a good editor. Then we'll pick the most important ones we want. From suiryc at yahoo.com Mon Jan 26 21:18:38 2004 From: suiryc at yahoo.com (Cyrius) Date: Mon, 26 Jan 2004 12:18:38 -0800 (PST) Subject: [Matroska-devel] Re: Variable Framerate, plugin based video editing tool In-Reply-To: <401538D3.1020609@matroska.org> Message-ID: <20040126201838.16629.qmail@web12902.mail.yahoo.com> Hi --- Christian HJ Wiesner wrote: > > Hi, > > i have the pleasure to tell you that there is a good chance that Mosu > and Cyrius will work together on a new video editing tool. The new > tool > should not be based on any existing programs, but be more or less > started from scratch. Mosu and Cyrius are currently in the process to > agree on basic structure, and the matroska-devel ML will be used for > these initial steps. > > A first draft of the scope of the program could look like that : > > - Variable Framerate ( VFR ) capable > - Extendable via plugins, for both input/output containers > - Standard editing Format is MKV ( matroska ) > - Can handle at least one video stream, plus several audio and > subtitles > streams > - X-platform, GUI made with wxwindows for improved portability > - Possibility to extend to handling of multiple video streams for NLE > ( > Non-Linear Editing ) > > A possible road map could look like > > 1. Define basic structure, including the internal scripting > 2. Define API for input/output modules > 3. Allow muxing of MKV files, using different source formats I agree that Matroska may be one of the first output formats supported. But I think we should try to also support an 'easy' format from the beginning too (thinking of AVI or OGM). >From my point of view when you design the code you need to try and prepare it for its future purpose (i.e. generally more advanced features). When testing the code it may be better to have both 'basic'/'limited', and 'advanced' cases to test. In other words it's good to test it to produce Matroska files which support various things such as Variable FrameRate and exotic codec combinations. But it may also be good to test it on more limited formats such as AVI (I mean Constant FrameRate video, preferably CBR audio, or VBR with a few workarounds in the specs ;); but e.g. no Vorbis allowed :p). Since I may be wrong, I invite people to tell here what they think about it :) > 4. Implement simple cutting/editing based on frame number / timestamp > ----- note : at this step mkvmerge becomes redundant > 5. Add Preview for the most used and free formats ( via libavcodec ? > licensing problems ? ) > 6. Implement enhanced one step editing, similar to Virtualdub ( mark > areas to be deleted / copied ) > 7. Define a codec plugin API > 8. Realize re-encoding of audio and video streams, using de/encoder > plugins > ----- note : at this step vdubmod becomes redundant > 9. Adding NLE, with fades etc. That would indeed be a good roadmap to replace mkvmerge and virtualdubmod step by step ... However I'm not sure you can separate that easily steps 4 and 6. Maybe it's only me, but I think that if you start only doing too simple editing features then it might be quite hard to then implement more advanced ones. For other parts of the program (such as handling codec plugins, etc) you can somewhat add them later (by taking into account what it will need in the code), but upgrading a framework from too basic editing capabilities to complex editing features may need to rewrite the code. > As you all might be aware, this is a huge task and can not be > completed > by the two alone. It must be the goal of the complete matroska team > to > contribute to this project, mainly by adding usable input modules, so > that step 4. could be achieved in reasonable time, so that the full > scope of mkvmerge is matched by the new editor. After that, the > definition of a codec plugin API and the creation of codecs based on > this should be the mian goal, so we could finally lift matroska to a > level where it can truely overcome AVI and VfW, and will get a > general > standard status for the future of video and audio encoding. > > I expect Mosu will have something to say here now, and i suppose he > will > get a lot more technical than i did, and also will answer with a lot > of > 'BUT's :-) . So please, before you reply to this email to tell us > your > opinion about it, wait for his email first. After all, i might have > seen > things too optimistic, as always ;-) .... Sorry for not waiting for his mail ;) And yes you are always too optimistic (I'm still waiting a good x-platform media api ;)) :p Best regards Cyrius __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free web site building tool. Try it! http://webhosting.yahoo.com/ps/sb/ From steve.lhomme at free.fr Mon Jan 26 21:28:57 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Mon, 26 Jan 2004 21:28:57 +0100 Subject: [Matroska-devel] Re: Variable Framerate, plugin based video editing tool In-Reply-To: <20040126201838.16629.qmail@web12902.mail.yahoo.com> References: <20040126201838.16629.qmail@web12902.mail.yahoo.com> Message-ID: <40157889.3060408@free.fr> Cyrius wrote: > And yes you are always too optimistic (I'm still waiting a good > x-platform media api ;)) :p Actually, I think you don't necessarily need a media-api that already exists for it. This API is just a building block. But making an editor require much more than that. IMO it's the most simple part of the job. And you can always design your own plugin API if none suits your needs. As long as it's clean and the project is doing well, you won't have problems getting help from a few hackers. Audacity is meant to be the Gimp for audio but it sucks. I hope this TCVE will be a better the Gimp for video :) From spyder at matroska.org Tue Jan 27 01:41:38 2004 From: spyder at matroska.org (John Cannon) Date: Mon, 26 Jan 2004 18:41:38 -0600 Subject: [Matroska-devel] Re: Variable Framerate, plugin based video editing tool In-Reply-To: <40157889.3060408@free.fr> References: <20040126201838.16629.qmail@web12902.mail.yahoo.com> <40157889.3060408@free.fr> Message-ID: <4015B3C2.4040604@matroska.org> Steve Lhomme wrote: > Cyrius wrote: > >> And yes you are always too optimistic (I'm still waiting a good >> x-platform media api ;)) :p > > > Actually, I think you don't necessarily need a media-api that already > exists for it. This API is just a building block. But making an editor > require much more than that. IMO it's the most simple part of the job. > And you can always design your own plugin API if none suits your > needs. As long as it's clean and the project is doing well, you won't > have problems getting help from a few hackers. > > Audacity is meant to be the Gimp for audio but it sucks. > I hope this TCVE will be a better the Gimp for video :) > > _______________________________________________ > Matroska-devel mailing list > Matroska-devel at lists.matroska.org > http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel > Hmmm, why do we always send messages to BOTH devel and users? I get double mail :) Spyder From spyder at matroska.org Tue Jan 27 05:51:13 2004 From: spyder at matroska.org (John Cannon) Date: Mon, 26 Jan 2004 22:51:13 -0600 Subject: [Matroska-devel] Re: Variable Framerate, plugin based video editing tool In-Reply-To: <4015B3C2.4040604@matroska.org> References: <20040126201838.16629.qmail@web12902.mail.yahoo.com> <40157889.3060408@free.fr> <4015B3C2.4040604@matroska.org> Message-ID: <4015EE41.10309@matroska.org> John Cannon wrote: > Steve Lhomme wrote: > >> Cyrius wrote: >> >>> And yes you are always too optimistic (I'm still waiting a good >>> x-platform media api ;)) :p >> >> >> >> Actually, I think you don't necessarily need a media-api that already >> exists for it. This API is just a building block. But making an >> editor require much more than that. IMO it's the most simple part of >> the job. And you can always design your own plugin API if none suits >> your needs. As long as it's clean and the project is doing well, you >> won't have problems getting help from a few hackers. >> >> Audacity is meant to be the Gimp for audio but it sucks. >> I hope this TCVE will be a better the Gimp for video :) >> >> _______________________________________________ >> Matroska-devel mailing list >> Matroska-devel at lists.matroska.org >> http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel >> > Hmmm, why do we always send messages to BOTH devel and users? I get > double mail :) > > Spyder > _______________________________________________ > Matroska-devel mailing list > Matroska-devel at lists.matroska.org > http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel > Back to what I originally intended to say... I love this idea! In fact I would work on it too if you would let me ;) Of course, I probably wouldn't let myself if I were you :P I promise I won't b0rk anything too badly. I need the coding experience so maybe I will just watch and experiment until you think I am ready :) I am good at finding bugs in code :) John From steve.lhomme at free.fr Tue Jan 27 10:23:50 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Tue, 27 Jan 2004 10:23:50 +0100 Subject: [Matroska-devel] Re: Variable Framerate, plugin based video editing tool In-Reply-To: <4015EE41.10309@matroska.org> References: <20040126201838.16629.qmail@web12902.mail.yahoo.com> <40157889.3060408@free.fr> <4015B3C2.4040604@matroska.org> <4015EE41.10309@matroska.org> Message-ID: <40162E26.4040200@free.fr> Some thoughts about the editor... I was just reading the interresting IP article, and read about editing and how studios can have 2 or 3 different edits of the same movie. That made me think of how you could compare them easily. And as we do with software sources, we just make a diff. But it is impossible with binary data. So I suggests that TCVE could store an edit as an XML file. This way you can compare and create new edits easily from the same "raw" source. From steve.lhomme at free.fr Tue Jan 27 10:27:30 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Tue, 27 Jan 2004 10:27:30 +0100 Subject: [Matroska-devel] Re: Variable Framerate, plugin based video editing tool In-Reply-To: <40162E26.4040200@free.fr> References: <20040126201838.16629.qmail@web12902.mail.yahoo.com> <40157889.3060408@free.fr> <4015B3C2.4040604@matroska.org> <4015EE41.10309@matroska.org> <40162E26.4040200@free.fr> Message-ID: <40162F02.30809@free.fr> Steve Lhomme wrote: > Some thoughts about the editor... > > I was just reading the interresting IP article, and read about editing > and how studios can have 2 or 3 different edits of the same movie. That > made me think of how you could compare them easily. And as we do with > software sources, we just make a diff. But it is impossible with binary > data. So I suggests that TCVE could store an edit as an XML file. This > way you can compare and create new edits easily from the same "raw" source. And now pushing the idea further, we should be able to play a movie from that XML source file. Just like an AVIsynth script but with more features : at least VFR, but probably multi-tracks, chapters, control tracks, menus, etc. From steve.lhomme at free.fr Tue Jan 27 10:37:22 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Tue, 27 Jan 2004 10:37:22 +0100 Subject: [Matroska-devel] Re: Variable Framerate, plugin based video editing tool In-Reply-To: <40162F02.30809@free.fr> References: <20040126201838.16629.qmail@web12902.mail.yahoo.com> <40157889.3060408@free.fr> <4015B3C2.4040604@matroska.org> <4015EE41.10309@matroska.org> <40162E26.4040200@free.fr> <40162F02.30809@free.fr> Message-ID: <40163152.5060203@free.fr> Steve Lhomme wrote: > Steve Lhomme wrote: > >> Some thoughts about the editor... >> >> I was just reading the interresting IP article, and read about editing >> and how studios can have 2 or 3 different edits of the same movie. >> That made me think of how you could compare them easily. And as we do >> with software sources, we just make a diff. But it is impossible with >> binary data. So I suggests that TCVE could store an edit as an XML >> file. This way you can compare and create new edits easily from the >> same "raw" source. > > > And now pushing the idea further, we should be able to play a movie from > that XML source file. Just like an AVIsynth script but with more > features : at least VFR, but probably multi-tracks, chapters, control > tracks, menus, etc. Pushing it even further... I think this file format to save an "editing session" is actually the heart of TCVE. It should be possible to store everything in that file format. And therefore TCVE simply becomes a GUI editor for that file format. So if everyone agree, we should concentrate on this file format a lot. From intel69160 at hotmail.com Tue Jan 27 18:03:42 2004 From: intel69160 at hotmail.com (Info) Date: Tue, 27 Jan 2004 18:03:42 +0100 Subject: [Matroska-devel] Bad Boys II en bobdown Message-ID: <20040127170353.6B441440026@p15097576.pureserver.info> An HTML attachment was scrubbed... URL: From chris at matroska.org Wed Jan 28 10:07:28 2004 From: chris at matroska.org (Christian HJ Wiesner) Date: Wed, 28 Jan 2004 10:07:28 +0100 Subject: [Matroska-devel] Re: Variable Framerate, plugin based video editing tool In-Reply-To: <40163152.5060203@free.fr> References: <20040126201838.16629.qmail@web12902.mail.yahoo.com> <40157889.3060408@free.fr> <4015B3C2.4040604@matroska.org> <4015EE41.10309@matroska.org> <40162E26.4040200@free.fr> <40162F02.30809@free.fr> <40163152.5060203@free.fr> Message-ID: <40177BD0.6040200@matroska.org> Steve Lhomme wrote: > Pushing it even further... I think this file format to save an > "editing session" is actually the heart of TCVE. It should be possible > to store everything in that file format. And therefore TCVE simply > becomes a GUI editor for that file format. Steve, dont you think one step too much into the future here, scaring all developers away ? This editing language is certainly a good idea, but shouldn't we concentrate on the very basic sceleton for now, means to create a framework that will allow - input plugins - muxing of MKV files ?? If you look at my roadmap below ------------------------------------------- 1. Define basic structure, including the internal scripting 2. Define API for input/output modules 3. Allow muxing of MKV files, using different source formats 4. Implement simple cutting/editing based on frame number / timestamp ----- note : at this step mkvmerge becomes redundant 5. Add Preview for the most used and free formats ( via libavcodec ? licensing problems ? ) 6. Implement enhanced one step editing, similar to Virtualdub ( mark areas to be deleted / copied ) 7. Define a codec plugin API 8. Realize re-encoding of audio and video streams, using de/encoder plugins ----- note : at this step vdubmod becomes redundant 9. Adding NLE, with fades etc. -------------------------------------------- you will find that the first goal must be to come to step 4. , means to replace the basic muxing functionality of mkvmerge. Your 'editing command file format' would become interesting from step 6. no ? > So if everyone agree, we should concentrate on this file format a lot. We shouldnt take the same risk as with matroska here, wanting too much at a time, risking everything goes down the drain. Lets make a policy of small steps here, first make a working muxer with a plugin structure, then add file splitting, then editing, then reencoding using codec plugins, then NLE . We need help for this huge task, and we should have learned from experience that you dont get support from people when you are in the planning stage still, nobody will give a dime for our nice plans. Give them something basic and working to play with, and interest and support will come all of a sudden. Just my 2 cents Christian From moritz at bunkus.org Wed Jan 28 10:44:22 2004 From: moritz at bunkus.org (Moritz Bunkus) Date: Wed, 28 Jan 2004 10:44:22 +0100 Subject: [Matroska-devel] Re: Variable Framerate, plugin based video editing tool In-Reply-To: <40177BD0.6040200@matroska.org> References: <20040126201838.16629.qmail@web12902.mail.yahoo.com> <40157889.3060408@free.fr> <4015B3C2.4040604@matroska.org> <4015EE41.10309@matroska.org> <40162E26.4040200@free.fr> <40162F02.30809@free.fr> <40163152.5060203@free.fr> <40177BD0.6040200@matroska.org> Message-ID: <20040128094422.GN14653@bunkus.org> Heya, I agree with Chris here. This project will be big enough as it is, and I fear we won't get anywhere with so few people if we spend our energy now on something that is not the first thing to decide. Actually we can do a LOT of work before we even get to this stage where such an edit format will be required, and I hope we can concentrate on that instead. I like Chris' roadmap so far, especially the first four points. What I really want to have is to have the core and the GUI separated from each other. I also want to have the core being completely scriptable. Ideally the GUI would only translate its actions (open file, seek to time x, get the number of tracks etc) into such script commands. Therefore this script language needs some thinking. I have very little experience with such stuff, so others are probably more knowledgable (avisynth users?). Then we need some kind of API for the demuxers / readers / whateveryouwanttocallit. This API must be powerful enough to get all the information out of a Matroska file. It will not be enough to have something like libavformat (meaning only the basics, open a file, get the next frame, have a rough description of the codecs etc). The same goes for the output layer. And we need a framer layer (functions/modules that split a stream of e.g. MP3 frames into the individual frames). That's only the background. We also need someone who's willing to do GUI programming. I'm not - I don't like it, and more importantly, I'm not good at it. The GUI (like the core) must be cross platform, so the number of GUI toolkits to chose from is very, very small. Qt is out of the loop as it cannot be used royalty-free on Windows anymore (especially not if we ever want to accept money for it if I understand it correctly). Gtk might be a solution as it does run on Windows. I'd prefer wxWindows as it is very comprehensive and takes care of a lot of xplatform issues right away. What else? Hmmm... I'd also prefer to use Subversion as the version control system as it has numerous advantages over plain CVS, but as this will be a Corecodec project I guess that is out of the question, and we're stuck with CVS again. You see, Steve, I definitely do not want to discredit your ideas. It's just that we have more than enough work ahead of us that is totally independant of what you want to achieve. Let's concentrate on this instead, please. Mosu -- If Darl McBride was in charge, he'd probably make marriage unconstitutional too, since clearly it de-emphasizes the commercial nature of normal human interaction, and probably is a major impediment to the commercial growth of prostitution. - Linus Torvalds From steve.lhomme at free.fr Wed Jan 28 11:20:39 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Wed, 28 Jan 2004 11:20:39 +0100 Subject: [Matroska-devel] Re: Variable Framerate, plugin based video editing tool In-Reply-To: <20040128094422.GN14653@bunkus.org> References: <20040126201838.16629.qmail@web12902.mail.yahoo.com> <40157889.3060408@free.fr> <4015B3C2.4040604@matroska.org> <4015EE41.10309@matroska.org> <40162E26.4040200@free.fr> <40162F02.30809@free.fr> <40163152.5060203@free.fr> <40177BD0.6040200@matroska.org> <20040128094422.GN14653@bunkus.org> Message-ID: <40178CF7.3090700@free.fr> Moritz Bunkus wrote: > Heya, > > I agree with Chris here. This project will be big enough as it is, and I > fear we won't get anywhere with so few people if we spend our energy now > on something that is not the first thing to decide. Actually we can do a > LOT of work before we even get to this stage where such an edit format > will be required, and I hope we can concentrate on that instead. Sure. But you will also lose a lot of precious time/energy if you start coding and think afterwards. IMO we should have a far view of what we want to do to keep that in mind when designing, and then coding. That was my basic idea of throwing random thoughts in the basket. > I like Chris' roadmap so far, especially the first four points. What I > really want to have is to have the core and the GUI separated from each > other. I also want to have the core being completely scriptable. Ideally Mmm, that script your talking about for phase 1 is the same one I was talking about... > the GUI would only translate its actions (open file, seek to time x, get > the number of tracks etc) into such script commands. Therefore this > script language needs some thinking. I have very little experience with > such stuff, so others are probably more knowledgable (avisynth users?). Maybe Cyrius has some. Because VDub is also scriptable a bit (at least exectue batch processings). > Then we need some kind of API for the demuxers / readers / > whateveryouwanttocallit. This API must be powerful enough to get all the > information out of a Matroska file. It will not be enough to have > something like libavformat (meaning only the basics, open a file, get > the next frame, have a rough description of the codecs etc). The same > goes for the output layer. And we need a framer layer (functions/modules > that split a stream of e.g. MP3 frames into the individual frames). I suggest investigating some time to search if we will have to reinvent the wheel or not. There are maybe GStreamer, Helix and Quicktime that are possible to use for the main 3 desktop OSes. GStreamer being the most open one, but the less advanced so far. > That's only the background. We also need someone who's willing to do GUI > programming. I'm not - I don't like it, and more importantly, I'm not > good at it. The GUI (like the core) must be cross platform, so the Yes, that's also my problem : the GUI. And we can't give that to a VB coder... Maybe Jory would be interrested ? > number of GUI toolkits to chose from is very, very small. Qt is out of > the loop as it cannot be used royalty-free on Windows anymore Uh ? I didn't know something has changed here ! > (especially not if we ever want to accept money for it if I understand If we want money we need to pay a license of a few 1,000 USD (IIRC). > it correctly). Gtk might be a solution as it does run on Windows. I'd > prefer wxWindows as it is very comprehensive and takes care of a lot of > xplatform issues right away. Yes, and it looks native ! Which is the best way to have a user feel comfortable. (and is probably the most efficient CPU wise). > What else? Hmmm... I'd also prefer to use Subversion as the version > control system as it has numerous advantages over plain CVS, but as this > will be a Corecodec project I guess that is out of the question, and > we're stuck with CVS again. We might talk to Cyt0plas about it. But we could also use your subversion system. And only feed CVS for the tagged versions. (extra work for no gain...) > You see, Steve, I definitely do not want to discredit your ideas. It's > just that we have more than enough work ahead of us that is totally > independant of what you want to achieve. Let's concentrate on this > instead, please. Well, you're not that far from my ideas :) From steve.lhomme at free.fr Wed Jan 28 11:35:32 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Wed, 28 Jan 2004 11:35:32 +0100 Subject: [Matroska-devel] Re: [Media-api] Design ideas for the editing system. In-Reply-To: <20040128003313.7954.qmail@mail.com> References: <20040128003313.7954.qmail@mail.com> Message-ID: <40179074.3070403@free.fr> Toby Hudon wrote: > Ok, now that we're supposedly working on the file format, I've been thinking about what we really need to put in there. > > Basicly my main idea is that we have something that looks like this: > 1 or more major media types (audio/video/text), specifics like codec or colorspace are unimportant. I agree if the architecture can be extended later. Any hacker will be able to add it's own format then. As long as we can handle the most tricky cases. One feature we need is the easy transcoding of AVI files into MKV/MKA files. With an option to keep VfW/DShow/ACM compatibility or convert to the native Matroska format. > For each media type, there exists ONE control stream, and one or more source streams. All have timecodes. > > The control stream basicly is the master timecode system, and the timecodes in each control stream (not source streams) should be linked so they always sync, this way we can make sure our video and audio line up. Why do you need a 3rd stream to have 2 streams in sync ? > The source streams each have their own (relative) timecode sequences that we can access. Roger that. > So, to edit a file, for simple things like cuts, speed up, slow down, and reverse, all we have to do is in the master control stream indicate what timecode of what source track we want at a given "master clock" in the control stream, and the direction and rate of play. We just indicate which tracks are active then and what relative timecodes from those tracks we want to use. Since we can associate with any timecode from the source tracks looping or time scaling is not a problem, and just changing which track is active or inactive or which timecode we wish to display in a track lets us perform cuts. This would basicly be able to perform most of what VirtualDub and such do without much effort, all it takes is editing which track and position you want at each point in time. > > Now, as for more complex effects, you'd have to have an external system to render them, so it would be a bit more like function calls or ML tags. I.e., for a fade effect, we might indicate two active tracks in the control stream, and their start timecode, rate, and direction of play, then have another variable which tells the editor we wish to render an effect or apply some filter here. The parameters passed to that effect or filter would probably vary depending on which one it is, so it probably needs to be a bit more thought out than what I've done so far. So basicly to fade we say something in the control stream like: > > 50: I suggest we have a look at the possibilities of SMIL instead of reinventing the wheel. > By putting everything in the control stream, this means we can take source tracks from existing files (direct stream copy) without modification other than just parsing them into the container, regardless of codec or attributes. This means adding a new video source track to an existing edit project should be as simple as selecting a new file to read source from, and doing a data copy into a new track on the project file. Granted there's probably going to be some sort of fun involving interleaving the new data etc, but that should be transparent to this process and handled by the container for the editing file format. Yes, the Direct Stream Copy is something really important. > Rendering a project to a final output file is as simple as reading the control stream in order, displaying the relative parts of the source streams as needed, and calling various rendering plugins to handle transitions and effects at specified times. All we need to do is take the desired output samplerate/framerate of the video we're creating, and generate the result at each point in time we need a frame. This may require some interpolation but that's things that should probably be handled "transparently" by the editor for ease of use. I realize this will be much harder than it sounds but at least it should only need to be written once if done right. IMO the pull model might not be a good idea. But why not. We need to make sure it works fine with VFR content too. From spyder at matroska.org Wed Jan 28 17:29:33 2004 From: spyder at matroska.org (John Cannon) Date: Wed, 28 Jan 2004 10:29:33 -0600 Subject: [Matroska-devel] MPEG in MKV Message-ID: Hi, Pamel asked me to send a message about the method of storing MPEG video in MKV. So here it is: - Frames are placed in individual blocks - References are set accordingly - Frames are put in coding order(ie. IPBBPBBPBB) - All stream headers excluding GOP header go in the codec private AND are also left in the stream where they were found. - GOP headers may optionally be excluded as according to the specs. - RFF flags MUST be left intact as any change to them would destroy the MPEG compliance. - You may also duplicate the sqeuence header before each I frame in order to allow easy stream editing without having to find the previous one. - All headers should be placed before the next frame in the stream and should be put in the same matroska block as that frame. -AR should be set in the mkv elements too. Did I miss anything? Spyder From rbultje at ronald.bitfreak.net Wed Jan 28 18:02:42 2004 From: rbultje at ronald.bitfreak.net (Ronald S. Bultje) Date: Wed, 28 Jan 2004 18:02:42 +0100 Subject: [Matroska-devel] MPEG in MKV In-Reply-To: References: Message-ID: <1075309361.14275.129.camel@shrek.bitfreak.net> On Wed, 2004-01-28 at 17:29, John Cannon wrote: > - GOP headers may optionally be excluded as according to the specs. Which specs? Any Linux MPEG decoder that I know of *requires* MPEG headers (at least the sequence header, but I think the GOP header too) to operate correctly. I don't know how this works for DirectShow, but I'm guessing something similar. My experiences/experiments with alternative video elementary streams layouts in WMP (win2k/XP) haven't been too good. Basically, you have to "fix" the stream everywhere where you "break" it. If so, what's the use of allowing it to be removed? It only complicates the demuxer and muxer. Apart from that, seems similar to MPGI in AVI - so it's fine, I guess. The fact that MPEG-4 is stored in display and MPEG-1 in coding order is logical (specs), but confusing. I'd make this an explicit note in your Matroska specs. Ronald PS: why do stream headers go into codecpivate? Where do you use them? -- Ronald Bultje Linux Video/Multimedia developer From jcsston at wiesneronline.net Wed Jan 28 19:01:23 2004 From: jcsston at wiesneronline.net (Jory) Date: Wed, 28 Jan 2004 12:01:23 -0600 Subject: [Matroska-general] Re: [Matroska-devel] Re: Variable Framerate, plugin based video editing tool References: <20040126201838.16629.qmail@web12902.mail.yahoo.com> <40157889.3060408@free.fr><4015B3C2.4040604@matroska.org> <4015EE41.10309@matroska.org><40162E26.4040200@free.fr> <40162F02.30809@free.fr><40163152.5060203@free.fr> <40177BD0.6040200@matroska.org><20040128094422.GN14653@bunkus.org> <40178CF7.3090700@free.fr> Message-ID: <000001c3e5ca$996da4c0$0200a8c0@jcsston> ----- Original Message ----- From: "Steve Lhomme" To: "Discussion about the current and future development of Matroska" ; "General talk about Matroska and other products" Sent: Wednesday, January 28, 2004 4:20 AM Subject: [Matroska-general] Re: [Matroska-devel] Re: Variable Framerate, plugin based video editing tool > Moritz Bunkus wrote: > > > Heya, > > > > I agree with Chris here. This project will be big enough as it is, and I > > fear we won't get anywhere with so few people if we spend our energy now > > on something that is not the first thing to decide. Actually we can do a > > LOT of work before we even get to this stage where such an edit format > > will be required, and I hope we can concentrate on that instead. > > Sure. But you will also lose a lot of precious time/energy if you start > coding and think afterwards. IMO we should have a far view of what we > want to do to keep that in mind when designing, and then coding. That > was my basic idea of throwing random thoughts in the basket. > I agree here too. When I first started VFRE (VFR Encoder), I coded like crazy for two days on the internal framework (in/out streams/pin, format types, etc.) and now I don't have a clue of how it works because I never had done any planning for it. (It doesn't work BTW ;) > > Then we need some kind of API for the demuxers / readers / > > whateveryouwanttocallit. This API must be powerful enough to get all the > > information out of a Matroska file. It will not be enough to have > > something like libavformat (meaning only the basics, open a file, get > > the next frame, have a rough description of the codecs etc). The same > > goes for the output layer. And we need a framer layer (functions/modules > > that split a stream of e.g. MP3 frames into the individual frames). > > I suggest investigating some time to search if we will have to reinvent > the wheel or not. There are maybe GStreamer, Helix and Quicktime that > are possible to use for the main 3 desktop OSes. GStreamer being the > most open one, but the less advanced so far. I think GStreamer would be our best target. Helix is nice and very DShow/COM like, but it has no docs whatsoever, and it is not GPL/LGPL friendly. I don't know anything about Quicktime, but if IIRC the support under Linux is not that great. (I may be wrong here) > > > That's only the background. We also need someone who's willing to do GUI > > programming. I'm not - I don't like it, and more importantly, I'm not > > good at it. The GUI (like the core) must be cross platform, so the > > Yes, that's also my problem : the GUI. And we can't give that to a VB > coder... Maybe Jory would be interrested ? > I would be interested in helping with the GUI, but I wouldn't want to do it all myself. ;) Also the plugins would need a good options interface/GUI. Prehaps we could do something like I prototyped in LemAPI. " // Here you supply your supported options, names, types (Integer, String, Boolean), and supply a short description about the option " then for each plugin we could generate a small options dialog with the XML options fragment. ---------------------------------------------------------- | MPA Input Options | | Plugin by Steve Lhomme | | | | X Copy Info Frames | | O Read LAME Info Frame | | Frame Size : 10 (a spinbox control) | | | | OK Cancel | ---------------------------------------------------------- The checkbox would have the desc fields as tooltips. With that type of data it should also be easy to create .htm/.txt docs for those who want to script from scratch. > > it correctly). Gtk might be a solution as it does run on Windows. I'd > > prefer wxWindows as it is very comprehensive and takes care of a lot of > > xplatform issues right away. > > Yes, and it looks native ! Which is the best way to have a user feel > comfortable. (and is probably the most efficient CPU wise). > I wouldn't use anything but wxWindows. :) GTK, along with it not looking native, requires a ton of version dependant .dll's. Which under Windows is just asking for trouble. GIMP doesn't work here because of that, some rogue png.dll is the wrong version and crashes it. Later, Jory From spyder at matroska.org Wed Jan 28 19:19:24 2004 From: spyder at matroska.org (John Cannon) Date: Wed, 28 Jan 2004 12:19:24 -0600 Subject: [Matroska-devel] Re: MPEG in MKV In-Reply-To: <1075309361.14275.129.camel@shrek.bitfreak.net> References: <1075309361.14275.129.camel@shrek.bitfreak.net> Message-ID: <4017FD2C.2010106@matroska.org> Ronald S. Bultje wrote: > On Wed, 2004-01-28 at 17:29, John Cannon wrote: > >>- GOP headers may optionally be excluded as according to the specs. > > > Which specs? ISO MPEG-2 says: "Group of picture header is an optional header that can be used immediately before a coded I-frame to indicate to the decoder if the first consecutive B-pictures immediately following the coded I-frame can be reconstructed properly in the case of a random access." This makes me believe it's not required. > Any Linux MPEG decoder that I know of *requires* MPEG headers (at least > the sequence header, but I think the GOP header too) to operate > correctly. I don't know how this works for DirectShow, but I'm guessing > something similar. My experiences/experiments with alternative video > elementary streams layouts in WMP (win2k/XP) haven't been too good. > Basically, you have to "fix" the stream everywhere where you "break" it. > If so, what's the use of allowing it to be removed? It only complicates > the demuxer and muxer. Of course they require the sequence headers but the GOP header only serves one purpose, to tell the decoder if the following GOP has some broken/missing references. IMO if the decoder MUST use this it's simply broken. Perhaps we should only include them if they tell that the gop is broken? > Apart from that, seems similar to MPGI in AVI - so it's fine, I guess. > The fact that MPEG-4 is stored in display and MPEG-1 in coding order is > logical (specs), but confusing. I'd make this an explicit note in your > Matroska specs. ummm...doesn't native mpeg4 use coding order? > Ronald > > PS: why do stream headers go into codecpivate? Where do you use them? > Well, it makes it easier for DirectShow since we need the sequence header to create the output format. If it can be done without it, i don't know that we really need it there. Any ideas? Toff? Spyder From spyder at matroska.org Wed Jan 28 19:19:24 2004 From: spyder at matroska.org (John Cannon) Date: Wed, 28 Jan 2004 12:19:24 -0600 Subject: [Matroska-devel] Re: MPEG in MKV In-Reply-To: <1075309361.14275.129.camel@shrek.bitfreak.net> References: <1075309361.14275.129.camel@shrek.bitfreak.net> Message-ID: <4017FD2C.2010106@matroska.org> Ronald S. Bultje wrote: > On Wed, 2004-01-28 at 17:29, John Cannon wrote: > >>- GOP headers may optionally be excluded as according to the specs. > > > Which specs? ISO MPEG-2 says: "Group of picture header is an optional header that can be used immediately before a coded I-frame to indicate to the decoder if the first consecutive B-pictures immediately following the coded I-frame can be reconstructed properly in the case of a random access." This makes me believe it's not required. > Any Linux MPEG decoder that I know of *requires* MPEG headers (at least > the sequence header, but I think the GOP header too) to operate > correctly. I don't know how this works for DirectShow, but I'm guessing > something similar. My experiences/experiments with alternative video > elementary streams layouts in WMP (win2k/XP) haven't been too good. > Basically, you have to "fix" the stream everywhere where you "break" it. > If so, what's the use of allowing it to be removed? It only complicates > the demuxer and muxer. Of course they require the sequence headers but the GOP header only serves one purpose, to tell the decoder if the following GOP has some broken/missing references. IMO if the decoder MUST use this it's simply broken. Perhaps we should only include them if they tell that the gop is broken? > Apart from that, seems similar to MPGI in AVI - so it's fine, I guess. > The fact that MPEG-4 is stored in display and MPEG-1 in coding order is > logical (specs), but confusing. I'd make this an explicit note in your > Matroska specs. ummm...doesn't native mpeg4 use coding order? > Ronald > > PS: why do stream headers go into codecpivate? Where do you use them? > Well, it makes it easier for DirectShow since we need the sequence header to create the output format. If it can be done without it, i don't know that we really need it there. Any ideas? Toff? Spyder From chris at matroska.org Wed Jan 28 19:29:27 2004 From: chris at matroska.org (Christian HJ Wiesner) Date: Wed, 28 Jan 2004 19:29:27 +0100 Subject: [Matroska-devel] Re: MPEG in MKV In-Reply-To: <4017FD2C.2010106@matroska.org> References: <1075309361.14275.129.camel@shrek.bitfreak.net> <4017FD2C.2010106@matroska.org> Message-ID: <4017FF87.1030604@matroska.org> John Cannon wrote: > Ronald S. Bultje wrote: > >> Apart from that, seems similar to MPGI in AVI - so it's fine, I guess. >> The fact that MPEG-4 is stored in display and MPEG-1 in coding order is >> logical (specs), but confusing. I'd make this an explicit note in your >> Matroska specs. > > > ummm...doesn't native mpeg4 use coding order? > Spyder frames are *ALWAYS* in coding order in matroska, only timestamps in the blocks represent display order ... Christian From chris at matroska.org Wed Jan 28 19:48:51 2004 From: chris at matroska.org (Christian HJ Wiesner) Date: Wed, 28 Jan 2004 19:48:51 +0100 Subject: [Matroska-devel] Re: Variable Framerate, plugin based video editing tool In-Reply-To: <000001c3e5ca$996da4c0$0200a8c0@jcsston> References: <20040126201838.16629.qmail@web12902.mail.yahoo.com> <40157889.3060408@free.fr><4015B3C2.4040604@matroska.org> <4015EE41.10309@matroska.org><40162E26.4040200@free.fr> <40162F02.30809@free.fr><40163152.5060203@free.fr> <40177BD0.6040200@matro <000001c3e5ca$996da4c0$0200a8c0@jcsston> Message-ID: <40180413.4030809@matroska.org> Lets focus on matroska-devel from now on, ok guys ? Jory wrote: >>Moritz Bunkus wrote: >> >>>Heya, >>> >>>I agree with Chris here. This project will be big enough as it is, and I >>>fear we won't get anywhere with so few people if we spend our energy now >>>on something that is not the first thing to decide. Actually we can do a >>>LOT of work before we even get to this stage where such an edit format >>>will be required, and I hope we can concentrate on that instead. >>> >>> >>Sure. But you will also lose a lot of precious time/energy if you start >>coding and think afterwards. IMO we should have a far view of what we >>want to do to keep that in mind when designing, and then coding. That >>was my basic idea of throwing random thoughts in the basket. >> >> >I agree here too. >When I first started VFRE (VFR Encoder), I coded like crazy for two days on >the internal framework (in/out streams/pin, format types, etc.) and now I >don't have a clue of how it works because I never had done any planning for >it. (It doesn't work BTW ;) > Good point Jory. But Mosu never said we shouldnt do any planning on the scripting language, we are basically discussing now what the initial scope of the planning should be like. It seems Mosu and me prefer to keep it simple to start with, and extend it later. robux4 on the other hand wants to invest more time to be spent at the beginning, to save us from bad surprises afterwards. Maybe Cyrius has the scripting language already in his head and will lauch about us now, as we invest so much time into discussing whats better, instead of simply doing it ;) .... >>>Then we need some kind of API for the demuxers / readers / >>>whateveryouwanttocallit. This API must be powerful enough to get all the >>>information out of a Matroska file. It will not be enough to have >>>something like libavformat (meaning only the basics, open a file, get >>>the next frame, have a rough description of the codecs etc). The same >>>goes for the output layer. And we need a framer layer (functions/modules >>>that split a stream of e.g. MP3 frames into the individual frames). >>> >>> >>I suggest investigating some time to search if we will have to reinvent >>the wheel or not. There are maybe GStreamer, Helix and Quicktime that >>are possible to use for the main 3 desktop OSes. GStreamer being the >>most open one, but the less advanced so far. >> >> > >I think GStreamer would be our best target. >Helix is nice and very DShow/COM like, but it has no docs whatsoever, and it >is not GPL/LGPL friendly. >I don't know anything about Quicktime, but if IIRC the support under Linux >is not that great. (I may be wrong here) > > I also believe either Gstreamer, or a self made platform are the solutions to go for ? Why ? Well, as you all know i am thinking political. MOV is the standard container for Quicktime, RM the same for Helix. As we plan to make the editor opensource and plugin based, the following will happen if we base it on either of them : Somebody will make an output plugin for the standard container of the platform we were using, say thank you, and people wont use matroska because the other container will be better supported. So, instead of helping matroska to become better accepted, we will damage the project with the editor. I know you guys dont like this kind of thinking, as you believe that users will go for the technically best solution, and freedom is everything. But please, lets be realistic about that : MOV is a pretty powerful container, and the advantages of matroska compared to it, the better ( or at least easier ) extendability, will maybe show in 5 years the earliest, if new, powerful compression formats will come to market, requesting special support from the container. Everything thats available right now can be stored in MOV just fine, and normal users will see more widely supported 'standard' in it than matroska currently is. My point here is, if we were using QT as basis for what we are trying to do, we had to make a lot of codec plugins based on the QT API, for many different formats like SSA, USF, AAC, whatever. Doing that, we'd dig matroska's grave, as this would enable Quicktime to support all the same content than whats possible in matroska. Same, maybe a bit different, is valid for using Helix. So, from a political point of view, only Gstreamer or our own solution are viable options. Sorry for this non-technical point of view :) ... >>>That's only the background. We also need someone who's willing to do GUI >>>programming. I'm not - I don't like it, and more importantly, I'm not >>>good at it. The GUI (like the core) must be cross platform, so the >>> >>> >>Yes, that's also my problem : the GUI. And we can't give that to a VB >>coder... Maybe Jory would be interrested ? >> > >I would be interested in helping with the GUI, but I wouldn't want to do it >all myself. ;) > Thanks Jory, this is highly appreciated :) Christian > > > From steve.lhomme at free.fr Wed Jan 28 20:55:09 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Wed, 28 Jan 2004 20:55:09 +0100 Subject: [Matroska-devel] Re: Variable Framerate, plugin based video editing tool In-Reply-To: <40180413.4030809@matroska.org> References: <20040126201838.16629.qmail@web12902.mail.yahoo.com> <40157889.3060408@free.fr><4015B3C2.4040604@matroska.org> <4015EE41.10309@matroska.org><40162E26.4040200@free.fr> <40162F02.30809@free.fr><40163152.5060203@free.fr> <40177BD0.6040200@matro <000001c3e5ca$996da4c0$0200a8c0@jcsston> <40180413.4030809@matroska.org> Message-ID: <4018139D.2090002@free.fr> Christian HJ Wiesner wrote: >> I agree here too. >> When I first started VFRE (VFR Encoder), I coded like crazy for two >> days on >> the internal framework (in/out streams/pin, format types, etc.) and now I >> don't have a clue of how it works because I never had done any >> planning for >> it. (It doesn't work BTW ;) >> > Good point Jory. But Mosu never said we shouldnt do any planning on the > scripting language, we are basically discussing now what the initial > scope of the planning should be like. It seems Mosu and me prefer to > keep it simple to start with, and extend it later. robux4 on the other > hand wants to invest more time to be spent at the beginning, to save us > from bad surprises afterwards. Mmm, that's what we did with Matroska. And it was worth ! Now a software that won't share much of his code with other parts needs a different thinking. But still, good programming always start with a good analysis. You're not going to build a good/stable house on weak foundations. > Somebody will make an output plugin for the standard container of the > platform we were using, say thank you, and people wont use matroska > because the other container will be better supported. So, instead of > helping matroska to become better accepted, we will damage the project > with the editor. Don't be a fool Christian. This is going to happen anyway whatever way we choose ! > My point here is, if we were using QT as basis for what we are trying to > do, we had to make a lot of codec plugins based on the QT API, for many > different formats like SSA, USF, AAC, whatever. Doing that, we'd dig > matroska's grave, as this would enable Quicktime to support all the same > content than whats possible in matroska. Same, maybe a bit different, is > valid for using Helix. See above. > So, from a political point of view, only Gstreamer or our own solution > are viable options. Sorry for this non-technical point of view :) ... Well of course it makes sense. But it's still good to pick some good ideas here and there when we can. From steve.lhomme at free.fr Wed Jan 28 20:10:03 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Wed, 28 Jan 2004 20:10:03 +0100 Subject: [Matroska-devel] Re: Variable Framerate, plugin based video editing tool In-Reply-To: <000001c3e5ca$996da4c0$0200a8c0@jcsston> References: <20040126201838.16629.qmail@web12902.mail.yahoo.com> <40157889.3060408@free.fr><4015B3C2.4040604@matroska.org> <4015EE41.10309@matroska.org><40162E26.4040200@free.fr> <40162F02.30809@free.fr><40163152.5060203@free.fr> <40177BD0.6040200@matroska.org><20040128094422.GN14653@bunkus.org> <40178CF7.3090700@free.fr> <000001c3e5ca$996da4c0$0200a8c0@jcsston> Message-ID: <4018090B.6080409@free.fr> Jory wrote: > Also the plugins would need a good options interface/GUI. Prehaps we could > do something like I prototyped in LemAPI. > " > // Here you supply your supported options, names, types (Integer, String, > Boolean), and supply a short description about the option > > > > " > then for each plugin we could generate a small options dialog with the XML > options fragment. > ---------------------------------------------------------- > | MPA Input Options | > | Plugin by Steve Lhomme | > | > | > | X Copy Info Frames | > | O Read LAME Info Frame | > | Frame Size : 10 (a spinbox control) | > | > | > | OK Cancel > | > ---------------------------------------------------------- > > The checkbox would have the desc fields as tooltips. With that type of data > it should also be easy to create .htm/.txt docs for those who want to script > from scratch. Yup. One interresting thing I saw in the iTunes library is the way they store data in XML. They do something like : 8 This way you only have a limited set of XML tags and you can verify the content easily. ...just an idea :) From steve.lhomme at free.fr Thu Jan 29 10:03:08 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Thu, 29 Jan 2004 10:03:08 +0100 Subject: [Matroska-devel] Re: [Media-api] Design ideas for the editing system. In-Reply-To: <20040129003105.69886.qmail@mail.com> References: <20040129003105.69886.qmail@mail.com> Message-ID: <4018CC4C.6010408@free.fr> > Well I'm not sure exactly what the difference is but I'll take your word for it. Obviously we'll have to sync the control stream to the file, or vice versa actually. We know the editing stream is in sync because it defines sync. Whatever it says for a specific timecode needs to be inserted at that timecode. Even if it's just a storage file I can think we'll be wanting to play it for previewing at some point. It's like the PNG files that Fireworks saves. You can preview them but it doesn't contain all the features you get when you open them with Fireworks. The preview is just a help, just an "accident" because they use a format that can actually be displayed as such. >>BTW, that makes me think that we should be able to edit a video based on >>the audio timecodes, not video. So if the audio to start/stop the movie >>is in the middle of a video frame, we just cut the timecode of the video >>frame. >> > > > Umm... but if the audio and video are both synced what does it matter? Their control streams should have the same timecodes, just the source streams will be different. Or are you talking about when a cut falls in the middle of a video or audio frame's duration? Yes (very hard to edit your emails with long long lines). > I say we enclude the whole frame of course but if control says stop then the stream stops. Otherwise pasting another stream on the end of this in the editor won't come out quite right. If the next frame is only displayed for 0.01ms then so be it, that's where the timecode said stop. If we want to do a "cut at nearest frame" that's a function that could be specified by an editor tool, and it could be audio or video, and nearest keyframe would likely be desired as well. Cut at keyframe boundaries is a feature we need. But what I mean is cutting inside the frames. Sound has a bigger time resolution than video. And so there are more frames/samples to decide to cut. Then to preserve the original stream you should be able to change the length of a video frame depending on the one of the audio : [ video frame ] [ audio samples ] ^ cut here > Yeah I'd think we might need to include that for VFR. For CFR we could assume it from the specified framerate of course. Well the whole opint of this editor is that it can do VFR. CFR is just a smaller case of VFR :) From rbultje at ronald.bitfreak.net Thu Jan 29 10:12:19 2004 From: rbultje at ronald.bitfreak.net (Ronald S. Bultje) Date: Thu, 29 Jan 2004 10:12:19 +0100 Subject: [Matroska-devel] Re: MPEG in MKV In-Reply-To: <4017FD2C.2010106@matroska.org> References: <1075309361.14275.129.camel@shrek.bitfreak.net> <4017FD2C.2010106@matroska.org> Message-ID: <1075367538.2251.143.camel@shrek.bitfreak.net> Hi John, On Wed, 2004-01-28 at 19:19, John Cannon wrote: > Ronald S. Bultje wrote: > > On Wed, 2004-01-28 at 17:29, John Cannon wrote: > >>- GOP headers may optionally be excluded as according to the specs. > > Which specs? > ISO MPEG-2 says: > "Group of picture header is an optional header that can be used > immediately before a coded I-frame to > indicate to the decoder if the first consecutive B-pictures immediately > following the coded I-frame can > be reconstructed properly in the case of a random access." This makes > me believe it's not required. I can't find any such thing in the MPEG-1 video specs (11172-2). I only looked at it briefly, though. I do know that several decoders or parsers (parsing bitstream to AVI-/matroska-compatible frame blocks) sync on the GOP-/sequence-header *pairs*. Don't know about decoders, I'm too lazy to check those. MPEG-1 and -2 might differ in this respect, though. I don't have the MPEG-2 specs here, I don't really use MPEG-2 much yet (as a developer). > Of course they require the sequence headers but the GOP header only > serves one purpose, to tell the decoder if the following GOP has some > broken/missing references. IMO if the decoder MUST use this it's simply > broken. Perhaps we should only include them if they tell that the gop > is broken? It makes sense to remove it from a *logical* point of view. I'm just talking about the *practical* part of it. I don't want to rewrite all sorts of stuff because some container format (heh ;) ) thought it'd be cool to do things differently. Apparently, for MPEG-2, it's legal to omit the GOP header, which sounds fine to me. I can't find that in the MPEG-1 specs, so I'm scary to allow it (explicitly) for MPEG-1, too. I'd say that it's fairly logical to allow it for MPEG-2 only, then (even though most MPEG-1/2 combi decoders will decode MPEG-1 with missing GOP headers just fine, too, simply because that simplifies their implementation as a combi-decoder). > > Apart from that, seems similar to MPGI in AVI - so it's fine, I guess. > > The fact that MPEG-4 is stored in display and MPEG-1 in coding order is > > logical (specs), but confusing. I'd make this an explicit note in your > > Matroska specs. > ummm...doesn't native mpeg4 use coding order? Afaik, that depends on the implementation (xvid, divx, 3ivx, blax, foox, barx, ...). ISO MPEG-4 stores everything in coding order, but nobody really uses ISO MPEG-4 much yet right now. But there, too: I don't have any specs handy. These things are way too expensive for me, and my employer already gave me the MPEG-1 specs, can't ask too much, can I? ;). > > PS: why do stream headers go into codecpivate? Where do you use them? > Well, it makes it easier for DirectShow since we need the sequence > header to create the output format. If it can be done without it, i > don't know that we really need it there. Any ideas? Toff? Well, GStreamer or ffmpeg doesn't need it... I'm no DirectShow expert, though. Ronald -- Ronald Bultje Linux Video/Multimedia developer From suiryc at yahoo.com Thu Jan 29 14:51:37 2004 From: suiryc at yahoo.com (Cyrius) Date: Thu, 29 Jan 2004 05:51:37 -0800 (PST) Subject: [Matroska-devel] Re: Variable Framerate, plugin based video editing tool In-Reply-To: <4018090B.6080409@free.fr> Message-ID: <20040129135137.96483.qmail@web12906.mail.yahoo.com> --- Steve Lhomme wrote: > Jory wrote: > > > Also the plugins would need a good options interface/GUI. Prehaps > we could > > do something like I prototyped in LemAPI. > > " > > // Here you supply your supported options, names, types (Integer, > String, > > Boolean), and supply a short description about the option > > > > > > > > " > > then for each plugin we could generate a small options dialog with > the XML > > options fragment. > > ---------------------------------------------------------- > > | MPA Input Options > | > > | Plugin by Steve Lhomme | > > | > > | > > | X Copy Info Frames > | > > | O Read LAME Info Frame > | > > | Frame Size : 10 (a spinbox control) > | > > | > > | > > | OK Cancel > > | > > ---------------------------------------------------------- > > > > The checkbox would have the desc fields as tooltips. With that type > of data > > it should also be easy to create .htm/.txt docs for those who want > to script > > from scratch. > > Yup. > One interresting thing I saw in the iTunes library is the way they > store > data in XML. They do something like : > 8 > > This way you only have a limited set of XML tags and you can verify > the > content easily. > ...just an idea :) Using XML for describing the plugin options is indeed a nice idea. But I guess its use was also to allow users to change the settings in this XML file. Don't forget we will need to write the settings inside the 'script' file used to describe the current project in the editor. On IRC we discussed a bit on the format that this script file could be, e.g. using XML syntax or real scripts (like AVISynth). We concluded that XML was able to do things as advanced as pure scripting, but would require a lot more space (due to the XML syntax, with tags etc) than scripts. Now including XML settings in an XML file is easy :p, but I don't think that would be too good in a pure script file. The other possiblity would be to use XML only to describe the options of a plugin. i.e. the plugin give something like ... The program would interpret this XML structure and display a nice 'GUI' (either a real GUI, or using the command line configuration tools like in Linux ;)) to the user. But we would give the values back using a defined function in the plugin, something like : plugin.setOption("blah", 5); or plugin.setOption("blah", "5"); etc which would fit more nicely in a script. Any other ideas ? Best regards Cyrius __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free web site building tool. Try it! http://webhosting.yahoo.com/ps/sb/ From suiryc at yahoo.com Thu Jan 29 15:09:46 2004 From: suiryc at yahoo.com (Cyrius) Date: Thu, 29 Jan 2004 06:09:46 -0800 (PST) Subject: [Matroska-devel] Re: Variable Framerate, plugin based video editing tool In-Reply-To: <40178CF7.3090700@free.fr> Message-ID: <20040129140946.64068.qmail@web12901.mail.yahoo.com> --- Steve Lhomme wrote: > Moritz Bunkus wrote: > > > Heya, > > > > I agree with Chris here. This project will be big enough as it is, > and I > > fear we won't get anywhere with so few people if we spend our > energy now > > on something that is not the first thing to decide. Actually we can > do a > > LOT of work before we even get to this stage where such an edit > format > > will be required, and I hope we can concentrate on that instead. > > Sure. But you will also lose a lot of precious time/energy if you > start > coding and think afterwards. IMO we should have a far view of what we > > want to do to keep that in mind when designing, and then coding. That > > was my basic idea of throwing random thoughts in the basket. Some thoughts about this script file are necessary from the beginning, in order to prevent bad surprises ;) (i.e. when we add a new feature we must think about how to control it in the script beforehand). Unfortunately it's generaly useless to think too much in advance. >From my experience you never think about every possible case and you end up sending your initial thoughts to trash because they don't fit anymore. > > I like Chris' roadmap so far, especially the first four points. > What I > > really want to have is to have the core and the GUI separated from > each > > other. I also want to have the core being completely scriptable. > Ideally > > Mmm, that script your talking about for phase 1 is the same one I was > talking about... Yes, but you want to try and define everything for this script file before starting to code. While a better thing could be to work a bit on both while progressing. > > the GUI would only translate its actions (open file, seek to time > x, get > > the number of tracks etc) into such script commands. Therefore this > > script language needs some thinking. I have very little experience > with > > such stuff, so others are probably more knowledgable (avisynth > users?). > > Maybe Cyrius has some. Because VDub is also scriptable a bit (at > least > exectue batch processings). I know a bit how VirtualDub scripts work. I am not sure but I think I read somewhere (maybe in the sources) that it was based on AVISynth (for the parsing module that is), or the contrary. Basically VirtualDub scripts are like a C++ file with objects you manipulate (VirtualDub.video.SetCompression(...)), with the base objects (VirtualDub, VirtualDub.video, ...) being already defined. Best regards Cyrius PS: we should also decide which ML to use for talking at the moment. We can't post in 4 MLs each time :p For technical things I send to the matroska-devel ML For features that would be matroska-general (and possibly matroska-devel) virtualdubmod MLs are a bit useless I think because we never talked in it, so I don't think people in it are interested and the media-api ML would be more for a media API ;) __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free web site building tool. Try it! http://webhosting.yahoo.com/ps/sb/ From suiryc at yahoo.com Thu Jan 29 15:19:33 2004 From: suiryc at yahoo.com (Cyrius) Date: Thu, 29 Jan 2004 06:19:33 -0800 (PST) Subject: [Matroska-devel] Re: [Media-api] Design ideas for the editing system. In-Reply-To: <40179074.3070403@free.fr> Message-ID: <20040129141933.48579.qmail@web12902.mail.yahoo.com> --- Steve Lhomme wrote: > Toby Hudon wrote: > > > Ok, now that we're supposedly working on the file format, I've been > thinking about what we really need to put in there. > > > > Basicly my main idea is that we have something that looks like > this: > > 1 or more major media types (audio/video/text), specifics like > codec or colorspace are unimportant. > > I agree if the architecture can be extended later. Any hacker will be > > able to add it's own format then. As long as we can handle the most > tricky cases. Of course the script file would have to be extensible. This can be achieved easly with either XML files or real script files. > One feature we need is the easy transcoding of AVI files into MKV/MKA > > files. With an option to keep VfW/DShow/ACM compatibility or convert > to > the native Matroska format. Maybe, but this kind of things would go in the plugin options. The editor isn't meant to revolve around one format. > IMO the pull model might not be a good idea. But why not. We need to > make sure it works fine with VFR content too. With spyder we already talked about using either push or pull. IIRC we concluded that both systems had good and bad points, but for editing purposes a pull system may be better. Indeed when pulling you are sure to control (almost) eveything where you are (i.e. you ask for one frame, and you will get one - or maybe a returned value telling you there were not enough data). But when you push you can't really control what happens afterwards (pushing a frame in a system that double your framerate by duplicating frames will output 2 frames at the end, while you may want only one at a time). Best regards Cyrius __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free web site building tool. Try it! http://webhosting.yahoo.com/ps/sb/ From suiryc at yahoo.com Thu Jan 29 15:23:24 2004 From: suiryc at yahoo.com (Cyrius) Date: Thu, 29 Jan 2004 06:23:24 -0800 (PST) Subject: [Matroska-devel] Re: Variable Framerate, plugin based video editing tool In-Reply-To: <000001c3e5ca$996da4c0$0200a8c0@jcsston> Message-ID: <20040129142324.49428.qmail@web12905.mail.yahoo.com> --- Jory wrote: > ----- Original Message ----- > > Moritz Bunkus wrote: > > > > > Heya, > > > > > > I agree with Chris here. This project will be big enough as it > is, and I > > > fear we won't get anywhere with so few people if we spend our > energy now > > > on something that is not the first thing to decide. Actually we > can do a > > > LOT of work before we even get to this stage where such an edit > format > > > will be required, and I hope we can concentrate on that instead. > > > > Sure. But you will also lose a lot of precious time/energy if you > start > > coding and think afterwards. IMO we should have a far view of what > we > > want to do to keep that in mind when designing, and then coding. > That > > was my basic idea of throwing random thoughts in the basket. > > > I agree here too. > When I first started VFRE (VFR Encoder), I coded like crazy for two > days on > the internal framework (in/out streams/pin, format types, etc.) and > now I > don't have a clue of how it works because I never had done any > planning for > it. (It doesn't work BTW ;) Yes, working on only one aspect of such a large project can lead to troubles afterwards ;) > I think GStreamer would be our best target. > Helix is nice and very DShow/COM like, but it has no docs whatsoever, > and it > is not GPL/LGPL friendly. > I don't know anything about Quicktime, but if IIRC the support under > Linux > is not that great. (I may be wrong here) Yes, gstreamer may be a good basis, if we can get it to work under Windows ;) > I wouldn't use anything but wxWindows. :) Me too :) Best regards Cyrius __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free web site building tool. Try it! http://webhosting.yahoo.com/ps/sb/ From suiryc at yahoo.com Thu Jan 29 15:27:55 2004 From: suiryc at yahoo.com (Cyrius) Date: Thu, 29 Jan 2004 06:27:55 -0800 (PST) Subject: [Matroska-devel] Re: Variable Framerate, plugin based video editing tool In-Reply-To: <40180413.4030809@matroska.org> Message-ID: <20040129142755.50454.qmail@web12905.mail.yahoo.com> --- Christian HJ Wiesner wrote: > Lets focus on matroska-devel from now on, ok guys ? :) > Good point Jory. But Mosu never said we shouldnt do any planning on > the > scripting language, we are basically discussing now what the initial > scope of the planning should be like. It seems Mosu and me prefer to > keep it simple to start with, and extend it later. robux4 on the > other > hand wants to invest more time to be spent at the beginning, to save > us > from bad surprises afterwards. > > Maybe Cyrius has the scripting language already in his head and will > lauch about us now, as we invest so much time into discussing whats > better, instead of simply doing it ;) .... I think like Mosu and you (see my previous mails). And the scripting language isn't in my head :p Best regards Cyrius __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free web site building tool. Try it! http://webhosting.yahoo.com/ps/sb/ From suiryc at yahoo.com Thu Jan 29 15:34:20 2004 From: suiryc at yahoo.com (Cyrius) Date: Thu, 29 Jan 2004 06:34:20 -0800 (PST) Subject: [Matroska-devel] Re: [Media-api] Design ideas for the editing system. In-Reply-To: <20040128191955.86977.qmail@mail.com> Message-ID: <20040129143420.61821.qmail@web12908.mail.yahoo.com> --- Toby Hudon wrote: > > One feature we need is the easy transcoding of AVI files into > MKV/MKA > > files. With an option to keep VfW/DShow/ACM compatibility or > convert to > > the native Matroska format. > > > > I think our best best is the photoshop-like approach. Force > everything into a single multitrack MKV for editing when we load it > as a source, then perform conversion back to other formats like AVI > at final render time if the user specifies that in options. Since > editing assumes we're going to be making changes, there's no point in > preserving an existing container structure since we'll need to > completely tear it down to edit and rebuild it for final output > anyway. For transcoding I suggest we just completely rip the existing > streams out of the source file with appropriate container demuxers > and re-mux them into the project MKV as direct stream copy, so > there's no decode/encode. That should be possible, right? I disagree here. We are talking about a video editor, i.e. projects that could be 2GB large or much more. The users won't wait for a 2GB file to be saved each time they save the current state of their project because we find it convenient (not even talking about the user being angry to see 2GB or more free space lost because of that). Best regards Cyrius __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free web site building tool. Try it! http://webhosting.yahoo.com/ps/sb/ From suiryc at yahoo.com Thu Jan 29 15:39:46 2004 From: suiryc at yahoo.com (Cyrius) Date: Thu, 29 Jan 2004 06:39:46 -0800 (PST) Subject: [Matroska-devel] Re: [Media-api] Design ideas for the editing system. In-Reply-To: <40181822.6020908@free.fr> Message-ID: <20040129143946.52935.qmail@web12902.mail.yahoo.com> > BTW, that makes me think that we should be able to edit a video based > on > the audio timecodes, not video. So if the audio to start/stop the > movie > is in the middle of a video frame, we just cut the timecode of the > video > frame. > > The problem of a pull model is that you know when a frame > (audio/video) > starts, but not when it ends. Or maybe it should be included in the > pulling request (ending timecode)... I think you would have the same problem with a push system. Unless you reserve a way for the push function to also give the ending timecode of the frame ... Best regards Cyrius __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free web site building tool. Try it! http://webhosting.yahoo.com/ps/sb/ From steve.lhomme at free.fr Thu Jan 29 16:04:47 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Thu, 29 Jan 2004 16:04:47 +0100 Subject: [Matroska-devel] Re: Variable Framerate, plugin based video editing tool In-Reply-To: <20040129135137.96483.qmail@web12906.mail.yahoo.com> References: <20040129135137.96483.qmail@web12906.mail.yahoo.com> Message-ID: <4019210F.5030103@free.fr> Cyrius wrote: > Now including XML settings in an XML file is easy :p, but I don't think > that would be too good in a pure script file. > > The other possiblity would be to use XML only to describe the options > of a plugin. i.e. the plugin give something like > > > ... > Yes but by mixing XML with something else you need to add a parser where you have one already writen (GStreamer already needs an XML interpreter). From steve.lhomme at free.fr Thu Jan 29 16:07:24 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Thu, 29 Jan 2004 16:07:24 +0100 Subject: [Matroska-devel] Re: Variable Framerate, plugin based video editing tool In-Reply-To: <20040129140946.64068.qmail@web12901.mail.yahoo.com> References: <20040129140946.64068.qmail@web12901.mail.yahoo.com> Message-ID: <401921AC.6010006@free.fr> Cyrius wrote: > Basically VirtualDub scripts are like a C++ file with objects you > manipulate (VirtualDub.video.SetCompression(...)), with the base > objects (VirtualDub, VirtualDub.video, ...) being already defined. I think that's the kind of thing we need. > PS: we should also decide which ML to use for talking at the moment. We > can't post in 4 MLs each time :p > For technical things I send to the matroska-devel ML > For features that would be matroska-general (and possibly > matroska-devel) > virtualdubmod MLs are a bit useless I think because we never talked in > it, so I don't think people in it are interested > and the media-api ML would be more for a media API ;) Or maybe we should have a new ML for the global thing ? matroska-tcve ? (as the idea is to do it for Matroska) From steve.lhomme at free.fr Thu Jan 29 16:09:18 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Thu, 29 Jan 2004 16:09:18 +0100 Subject: [Matroska-devel] Re: Variable Framerate, plugin based video editing tool In-Reply-To: <20040129142324.49428.qmail@web12905.mail.yahoo.com> References: <20040129142324.49428.qmail@web12905.mail.yahoo.com> Message-ID: <4019221E.1060508@free.fr> Cyrius wrote: >>I think GStreamer would be our best target. >>Helix is nice and very DShow/COM like, but it has no docs whatsoever, >>and it >>is not GPL/LGPL friendly. >>I don't know anything about Quicktime, but if IIRC the support under >>Linux >>is not that great. (I may be wrong here) > > > Yes, gstreamer may be a good basis, if we can get it to work under > Windows ;) I will ! But not tonight... From suiryc at yahoo.com Thu Jan 29 17:46:15 2004 From: suiryc at yahoo.com (Cyrius) Date: Thu, 29 Jan 2004 08:46:15 -0800 (PST) Subject: [Matroska-devel] Re: Variable Framerate, plugin based video editing tool In-Reply-To: <4019210F.5030103@free.fr> Message-ID: <20040129164615.18150.qmail@web12907.mail.yahoo.com> --- Steve Lhomme wrote: > Cyrius wrote: > > > Now including XML settings in an XML file is easy :p, but I don't > think > > that would be too good in a pure script file. > > > > The other possiblity would be to use XML only to describe the > options > > of a plugin. i.e. the plugin give something like > > > > value="5" /> > > ... > > > > Yes but by mixing XML with something else you need to add a parser > where > you have one already writen (GStreamer already needs an XML > interpreter). Yes, but if the script files used for the editor are real scripts (and not XML) then anyway you would mix the 2. __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free web site building tool. Try it! http://webhosting.yahoo.com/ps/sb/ From suiryc at yahoo.com Thu Jan 29 17:51:48 2004 From: suiryc at yahoo.com (Cyrius) Date: Thu, 29 Jan 2004 08:51:48 -0800 (PST) Subject: [Matroska-devel] Re: Variable Framerate, plugin based video editing tool In-Reply-To: <401921AC.6010006@free.fr> Message-ID: <20040129165148.7033.qmail@web12901.mail.yahoo.com> --- Steve Lhomme wrote: > Cyrius wrote: > > > Basically VirtualDub scripts are like a C++ file with objects you > > manipulate (VirtualDub.video.SetCompression(...)), with the base > > objects (VirtualDub, VirtualDub.video, ...) being already defined. > > I think that's the kind of thing we need. If we choose to walk down the script path, then I also think this is a good solution. This way people using VirtualDub or AVISynth won't need to learn a whole new syntax ;) So back to my previous mail about plugin options (that you can also set inside script files). If we go the script way, then the idea I talked about ('plugin.setOption(name,value)' or so) may be better than using XML all the way ('plugin.setOptions(my_whole_settings_in_a_xml_format)' or so). > > PS: we should also decide which ML to use for talking at the > moment. We > > can't post in 4 MLs each time :p > > For technical things I send to the matroska-devel ML > > For features that would be matroska-general (and possibly > > matroska-devel) > > virtualdubmod MLs are a bit useless I think because we never talked > in > > it, so I don't think people in it are interested > > and the media-api ML would be more for a media API ;) > > Or maybe we should have a new ML for the global thing ? > matroska-tcve ? (as the idea is to do it for Matroska) >From my point of view the editor isn't meant to revolve around Matroska. As already discussed with ChrisHJW on IRC I agree that the matroska 'plugin' could be integrated in the main project, but in now way the editor should be 'matroska-dependant'. __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free web site building tool. Try it! http://webhosting.yahoo.com/ps/sb/ From paul at msn.com Thu Jan 29 20:52:03 2004 From: paul at msn.com (Paul Bryson) Date: Thu, 29 Jan 2004 13:52:03 -0600 Subject: [Matroska-devel] Re: Re: MPEG in MKV References: <1075309361.14275.129.camel@shrek.bitfreak.net><4017FD2C.2010106@matroska.org> <1075367538.2251.143.camel@shrek.bitfreak.net> Message-ID: "Ronald S. Bultje" wrote... > Apparently, for MPEG-2, it's legal to omit the GOP header, which sounds > fine to me. I can't find that in the MPEG-1 specs, so I'm scary to allow > it (explicitly) for MPEG-1, too. I'd say that it's fairly logical to > allow it for MPEG-2 only, then (even though most MPEG-1/2 combi decoders > will decode MPEG-1 with missing GOP headers just fine, too, simply > because that simplifies their implementation as a combi-decoder). It sounds like the thing to do then is to make a sample of MPEG-1 with the GOP header missing and see if anything b0rks on playing it back. If nothing does, then we should be fine. Pamel From paul at msn.com Thu Jan 29 21:30:39 2004 From: paul at msn.com (Paul Bryson) Date: Thu, 29 Jan 2004 14:30:39 -0600 Subject: [Matroska-devel] Re: [Media-api] Design ideas for the editingsystem. References: <20040128191955.86977.qmail@mail.com> <20040129143420.61821.qmail@web12908.mail.yahoo.com> Message-ID: "Cyrius" wrote... > --- Toby Hudon wrote: > > > One feature we need is the easy transcoding of AVI files into > > MKV/MKA > > > files. With an option to keep VfW/DShow/ACM compatibility or > > convert to > > > the native Matroska format. > > > > > > > I think our best best is the photoshop-like approach. Force > > everything into a single multitrack MKV for editing when we load it > > as a source, then perform conversion back to other formats like AVI > > at final render time if the user specifies that in options. Since > > editing assumes we're going to be making changes, there's no point in > > preserving an existing container structure since we'll need to > > completely tear it down to edit and rebuild it for final output > > anyway. For transcoding I suggest we just completely rip the existing > > streams out of the source file with appropriate container demuxers > > and re-mux them into the project MKV as direct stream copy, so > > there's no decode/encode. That should be possible, right? > > I disagree here. > We are talking about a video editor, i.e. projects that could be 2GB > large or much more. The users won't wait for a 2GB file to be saved > each time they save the current state of their project because we find > it convenient (not even talking about the user being angry to see 2GB > or more free space lost because of that). You could still use a Matroska file to store all of the editing information, but just reference the original files. You could reference Matroska Tracks by using the "SegmentUID - TrackUID" method. Pamel From steve.lhomme at free.fr Thu Jan 29 21:39:22 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Thu, 29 Jan 2004 21:39:22 +0100 Subject: [Matroska-devel] Re: Variable Framerate, plugin based video editing tool In-Reply-To: <20040129165148.7033.qmail@web12901.mail.yahoo.com> References: <20040129165148.7033.qmail@web12901.mail.yahoo.com> Message-ID: <40196F7A.6020108@free.fr> Cyrius wrote: >>From my point of view the editor isn't meant to revolve around > Matroska. > As already discussed with ChrisHJW on IRC I agree that the matroska > 'plugin' could be integrated in the main project, but in now way the > editor should be 'matroska-dependant'. I know. That's just to keep the marketing guy happy :D From spyder at matroska.org Fri Jan 30 02:05:09 2004 From: spyder at matroska.org (John Cannon) Date: Thu, 29 Jan 2004 19:05:09 -0600 Subject: [Matroska-devel] Re: Variable Framerate, plugin based video editing tool In-Reply-To: <40196F7A.6020108@free.fr> References: <20040129165148.7033.qmail@web12901.mail.yahoo.com> <40196F7A.6020108@free.fr> Message-ID: <4019ADC5.1030503@matroska.org> Steve Lhomme wrote: > Cyrius wrote: > >>> From my point of view the editor isn't meant to revolve around >> >> Matroska. >> As already discussed with ChrisHJW on IRC I agree that the matroska >> 'plugin' could be integrated in the main project, but in now way the >> editor should be 'matroska-dependant'. > > > I know. That's just to keep the marketing guy happy :D > > _______________________________________________ > Matroska-devel mailing list > Matroska-devel at lists.matroska.org > http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel > Of course, I plan to make a closed source NUT reader ;) I've already got code to read their variable length coding so it shouldn't be too hard to support the "best format ever" ;) And no, I will not release the source code. :P John From paul at msn.com Fri Jan 30 10:05:51 2004 From: paul at msn.com (Paul Bryson) Date: Fri, 30 Jan 2004 03:05:51 -0600 Subject: [Matroska-devel] New Notes.html added to specs Message-ID: I added a new page to CVS to complement the specs. There are several cases so far when a particular portion of the may be written correctly, but it can be difficult to understand without some lengthy discussion and examples, and I am adding these cases to this page. This is for all of those lengthy discussions that are not NEEDED in the specs, but would help in understanding and implementing them. http://matroska.org/technical/specs/notes.html I will slowly add more to this page as I search through the mailinglist archives. Pamel From moritz at bunkus.org Fri Jan 30 10:11:15 2004 From: moritz at bunkus.org (Moritz Bunkus) Date: Fri, 30 Jan 2004 10:11:15 +0100 Subject: [Matroska-devel] New Notes.html added to specs In-Reply-To: References: Message-ID: <20040130091115.GA14653@bunkus.org> Heya, very good. This should have been done much earlier, so I really appreciate it. Mosu -- If Darl McBride was in charge, he'd probably make marriage unconstitutional too, since clearly it de-emphasizes the commercial nature of normal human interaction, and probably is a major impediment to the commercial growth of prostitution. - Linus Torvalds From paul at msn.com Fri Jan 30 18:51:30 2004 From: paul at msn.com (Paul Bryson) Date: Fri, 30 Jan 2004 11:51:30 -0600 Subject: [Matroska-devel] Re: [Media-api] Design ideas for the editingsystem - How to handle audio References: <20040129003105.69886.qmail@mail.com> <4018CC4C.6010408@free.fr> Message-ID: This occured to me as I was considering how to improve the Block2 design for Matroska. The problem encountered in Matroska is that there are never exactly precise timestamps that you can use for an audio sample because each sample takes a length of time that cannot be expressed as a single number. For instance, a single CD audio sample is 1/44100 seconds long. There is not a good way to express the samples timecode as a rational number. Its not a huge issue in Matroska because you can express the timecode with enough accuracy that you know exactly what sample you are talking about. However, its also not as elegant as I would like so I was trying to think of a better way to do this, and one way was to store the sample number in the Block2 and use that to calculate the timecode. This seems simple since audio streams always have the same samplerate throughout the stream. But then I remembered something that Steve mentioned. "What if you want the samplerate to change in the audio stream?" If you have a variable sample rate stream, then you cannot know the timecode from the sample number. There are currently no sources like this, or codecs that support this, but it is possible a chicken/egg problem. There cannot be any sources like this because there are no systems that support it. I doubt it is even possible in current hardware. But, with the prevalence of soft DSPs, it is not unthinkable for this to be common within the next 10 years. So, given this, how should audio be handled in the new Media-api? By sample number, by timecode, or some other method? How should this be handled in the new editing system? Pamel From steve.lhomme at free.fr Fri Jan 30 20:52:51 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Fri, 30 Jan 2004 20:52:51 +0100 Subject: [Matroska-devel] Re: Design ideas for the editingsystem - How to handle audio In-Reply-To: References: <20040129003105.69886.qmail@mail.com> <4018CC4C.6010408@free.fr> Message-ID: <401AB613.2050703@free.fr> Paul Bryson wrote: > This occured to me as I was considering how to improve the Block2 design for > Matroska. The problem encountered in Matroska is that there are never exactly > precise timestamps that you can use for an audio sample because each sample > takes a length of time that cannot be expressed as a single number. For > instance, a single CD audio sample is 1/44100 seconds long. There is not a good > way to express the samples timecode as a rational number. Its not a huge issue > in Matroska because you can express the timecode with enough accuracy that you > know exactly what sample you are talking about. > > However, its also not as elegant as I would like so I was trying to think of a > better way to do this, and one way was to store the sample number in the Block2 > and use that to calculate the timecode. This seems simple since audio streams > always have the same samplerate throughout the stream. But then I remembered > something that Steve mentioned. You're reinventing the problem of Ogg. You need the codec to interpret a counter. Well, not exactly. But you don't need a new Block for that. I added such an element when we wanted better sample accuracy. It was in the BlockAdditional IIRC. In Matroska the timestamp is what matters. If you change that everything gets complicated. From jcsston at wiesneronline.net Sat Jan 31 06:18:38 2004 From: jcsston at wiesneronline.net (Jory) Date: Fri, 30 Jan 2004 23:18:38 -0600 Subject: [Matroska-devel] TCME GUI Ideas References: <20040126201838.16629.qmail@web12902.mail.yahoo.com> <40157889.3060408@free.fr><4015B3C2.4040604@matroska.org> <4015EE41.10309@matroska.org><40162E26.4040200@free.fr> <40162F02.30809@free.fr><40163152.5060203@free.fr> <40177BD0.6040200@matro<000001c3e5ca$996da4c0$0200a8c0@jcsston><40180413.4030809@matroska.org> <4018139D.2090002@free.fr> Message-ID: <000301c3e7b9$d1225500$0200a8c0@jcsston> I have been doing a lot of thinking about the GUI and what type of interface we would have. So far I have came up with the following: 1. VirtualDub-like interface Pros: Simple, Many users will already know how to use it. Cons: Single Video Track, no visual of the Audio Track 2. Adobe Premiere-like interface Pros: Flexible, Layering, Lots of A/V/S Tracks Cons: Complex, May scare away some users. 3. Blend Only have a single video track, but provide better editing options for the audio/subtitle tracks. Pros: Only a little more complex than a VirtualDub-like interface. Cons: No Layering, Titles not possible? >From these three idea I like the third the best for a start. Later on, we could add a more complex interface for advanced users and true NLE purposes. BTW When browsing the GStreamer mailing lists, I found Pupuedit, an open-source Linux NLE that plans on using GStreamer http://pupuedit.sourceforge.net/ Should we contact the developer and ask if he would be interested in joining us? For the license issue: After reading the new choices, the LGPL gets my vote. It's GPL-friendly, while not being infectious. A good compromise IMHO. :) Also about the porting of GStreamer for Windows. One idea I had is to have the GStreamer core, libglib, libiconv, libxml2 all in one gstreamer-0.7.0.dll. This may be impossible, but if it is it would be cool to only have one .dll required by the editor (even if it is large). Last but not least Would creating a TCME project at the this point, to collaborate the GStreamer port be wise? Feel free to comment, Jory From chris at matroska.org Sat Jan 31 07:40:01 2004 From: chris at matroska.org (Christian HJ Wiesner) Date: Sat, 31 Jan 2004 07:40:01 +0100 Subject: [Matroska-devel] TCME GUI Ideas In-Reply-To: <000301c3e7b9$d1225500$0200a8c0@jcsston> References: <20040126201838.16629.qmail@web12902.mail.yahoo.com> <40157889.3060408@free.fr><4015B3C2.4040604@matroska.org> <4015EE41.10309@matroska.org><40162E26.4040200@free.fr> <40162F02.30809@free.fr><40163152.5060203@free.fr> <40177BD0.6040200@matro <000301c3e7b9$d1225500$0200a8c0@jcsston> Message-ID: <401B4DC1.1050800@matroska.org> Jory wrote: >I have been doing a lot of thinking about the GUI and what type of interface >we would have. So far I have came up with the following: >1. VirtualDub-like interface >Pros: Simple, Many users will already know how to use it. >Cons: Single Video Track, no visual of the Audio Track >2. Adobe Premiere-like interface >Pros: Flexible, Layering, Lots of A/V/S Tracks >Cons: Complex, May scare away some users. >3. Blend >Only have a single video track, but provide better editing options for the >audio/subtitle tracks. >Pros: Only a little more complex than a VirtualDub-like interface. >Cons: No Layering, Titles not possible? >>From these three idea I like the third the best for a start. Later on, we >could add a more complex interface for advanced users and true NLE purposes. > > Sounds good to me also :) >BTW When browsing the GStreamer mailing lists, I found Pupuedit, an >open-source Linux NLE that plans on using GStreamer >http://pupuedit.sourceforge.net/ >Should we contact the developer and ask if he would be interested in joining >us? > > Thats done already, the author behind it is ploum, he is a steady guest on #gstreamer and expressed his wish to collaborate already. He and a friend ( both from F ) plan to make this editor as their diploma thesis :) .... >For the license issue: >After reading the new choices, the LGPL gets my vote. It's GPL-friendly, >while not being infectious. A good compromise IMHO. :) > > I personally find it to be too weak, sorry ..... meanwhile my vote goes to GPL .... >Also about the porting of GStreamer for Windows. One idea I had is to have >the GStreamer core, libglib, libiconv, libxml2 all in one >gstreamer-0.7.0.dll. This may be impossible, but if it is it would be cool >to only have one .dll required by the editor (even if it is large). > > What about making a huge DirectShow filter from it :D !! Not like ffdshow, that contradicts the idea of DShow by trying to play dozens of formats, but in a more intelligent way, only using the stuff we need like overlays and the like. The filter could be responsible to play virtual 'gst-files', while they are only commands/scripts indicating what file to play, and how ...... crazy idea, i know :) .... >Last but not least >Would creating a TCME project at the this point, to collaborate the >GStreamer port be wise? >Feel free to comment, Jory > > robux4 has the confirmation from gstreamer people already about using their CVS :) ... Christian From chris at matroska.org Sat Jan 31 09:45:54 2004 From: chris at matroska.org (Christian HJ Wiesner) Date: Sat, 31 Jan 2004 09:45:54 +0100 Subject: [Matroska-devel] ASFtoMKV Recorder Message-ID: <401B6B42.2080606@matroska.org> Hi Gabest, i was trying to use ASF Recorder on a couple of movies for my son, but the source link that WMP was pointing me to is rendered by Graphedit in a 'XML Playlist' ??? Attached jpg is showing the graph and the URL. Seems to be some kind of protection ? Any chance to circumvent this ? Christian -------------- next part -------------- A non-text attachment was scrubbed... Name: ASFrecorder.JPG Type: image/jpeg Size: 70843 bytes Desc: not available URL: From Liisachan at faireal.net Sat Jan 31 09:53:44 2004 From: Liisachan at faireal.net (Liisachan) Date: Sat, 31 Jan 2004 17:53:44 +0900 Subject: [Matroska-devel] ASFtoMKV Recorder In-Reply-To: <401B6B42.2080606@matroska.org> References: <401B6B42.2080606@matroska.org> Message-ID: <401B6D18.2030908@faireal.net> Open that .asx file with Note Pad. There you can see the true URL... greets Liisachan. Christian HJ Wiesner wrote: > Hi Gabest, > > i was trying to use ASF Recorder on a couple of movies for my son, but > the source link that WMP was pointing me to is rendered by Graphedit > in a 'XML Playlist' ??? Attached jpg is showing the graph and the URL. > Seems to be some kind of protection ? Any chance to circumvent this ? > > Christian > > ------------------------------------------------------------------------ > >------------------------------------------------------------------------ > >_______________________________________________ >Matroska-devel mailing list >Matroska-devel at lists.matroska.org >http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel > > From suiryc at yahoo.com Sat Jan 31 16:22:09 2004 From: suiryc at yahoo.com (Cyrius) Date: Sat, 31 Jan 2004 07:22:09 -0800 (PST) Subject: [Matroska-devel] TCME GUI Ideas In-Reply-To: <000301c3e7b9$d1225500$0200a8c0@jcsston> Message-ID: <20040131152209.69679.qmail@web12901.mail.yahoo.com> --- Jory wrote: > I have been doing a lot of thinking about the GUI and what type of > interface > we would have. > > So far I have came up with the following: > 1. VirtualDub-like interface > Pros: Simple, Many users will already know how to use it. > Cons: Single Video Track, no visual of the Audio Track > > 2. Adobe Premiere-like interface > Pros: Flexible, Layering, Lots of A/V/S Tracks > Cons: Complex, May scare away some users. > > 3. Blend > Only have a single video track, but provide better editing options > for the > audio/subtitle tracks. > Pros: Only a little more complex than a VirtualDub-like interface. > Cons: No Layering, Titles not possible? > > >From these three idea I like the third the best for a start. Later > on, we > could add a more complex interface for advanced users and true NLE > purposes. > > BTW When browsing the GStreamer mailing lists, I found Pupuedit, an > open-source Linux NLE that plans on using GStreamer > http://pupuedit.sourceforge.net/ > Should we contact the developer and ask if he would be interested in > joining > us? Belgabor mentioned another NLE editor under Linux (for KDE) : http://www.uchian.pwp.blueyonder.co.uk/kdenlive.html screenshots: http://www.uchian.pwp.blueyonder.co.uk/kdenlive_screenshots.html It is mainly a GUI (with some other things) around the renderer Piave which belongs to another Linux project. The GUI of this project and pupuedit seems a bit alike :) > For the license issue: > After reading the new choices, the LGPL gets my vote. It's > GPL-friendly, > while not being infectious. A good compromise IMHO. :) I'm also for L-GPL or GPL. __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free web site building tool. Try it! http://webhosting.yahoo.com/ps/sb/