From chris at matroska.org Thu Sep 2 22:56:14 2004 From: chris at matroska.org (Christian HJ Wiesner) Date: Thu, 02 Sep 2004 22:56:14 +0200 Subject: [Matroska-devel] [Fwd: a matter of wonder - what about bin XML?] Message-ID: <413788EE.9080506@matroska.org> -------- Original Message -------- Subject: a matter of wonder - what about bin XML? Date: Tue, 31 Aug 2004 12:51:14 -0700 From: Burov Dmitry To: christianhjw at users.sourceforge.net There is a project - http://www.w3c.org/XML/Binary/ I wonder, is there something commong between it and EBML ? Thank You. From steve.lhomme at free.fr Thu Sep 2 23:06:29 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Thu, 02 Sep 2004 23:06:29 +0200 Subject: [Matroska-devel] [Fwd: a matter of wonder - what about bin XML?] In-Reply-To: <413788EE.9080506@matroska.org> References: <413788EE.9080506@matroska.org> Message-ID: <41378B55.3030400@free.fr> Christian HJ Wiesner a ?crit : > > > -------- Original Message -------- > Subject: a matter of wonder - what about bin XML? > Date: Tue, 31 Aug 2004 12:51:14 -0700 > From: Burov Dmitry > To: christianhjw at users.sourceforge.net > > > > There is a project - http://www.w3c.org/XML/Binary/ > > I wonder, is there something commong between it and EBML ? Not really. Although EBML has the XML philosphy for extending the semantic. EBML is very simple and doesn't aim to support all features of XML, not even in binary form. But it's very efficient and useful anyway :) One of the big advantage is the use of default value and mandatory elements... cya -- robUx4 on blog From steve.lhomme at free.fr Sat Sep 4 08:41:30 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Sat, 04 Sep 2004 08:41:30 +0200 Subject: [Matroska-devel] Re: javatroska In-Reply-To: References: Message-ID: <4139639A.1030806@free.fr> Ron Knutson a ?crit : > Hi, > > > > I'm working on http://videoman.sourceforge.net, a java > > manager/db for video files. I've recently added .mkv as an > > allowed file type but also need to gather basic audio/video > > data from this file type. Video Codec, bit rate, etc. In my > > search of the web for mkv information, I ran across a few > > mentions of a program called javatroska that appears to be > > related to/come from your group. I'm assuming that is a java > > based tool for mkv files. If so, could you put me in touch > > with the developer or point me to some source. Any help > > would be appreciated, as I see more mkv files in use I would > > like to provide my users with better support. You should contact Jory Stone and John Cannon, they worked on Java codes to read Matroska files. jcsston at jory.info spyder at matroska.org There is also a JEBML code in our Subversion server : http://svn.matroska.org/svn/matroska/trunk/JEBML/ -- robUx4 on blog From steve.lhomme at free.fr Mon Sep 6 11:41:36 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Mon, 06 Sep 2004 11:41:36 +0200 Subject: [Matroska-devel] IRC down Message-ID: <413C30D0.1040809@free.fr> As always when there is IRC problems, we should meet on : irc://irc.freenode.net/#matroska-dev and/or irc://irc.freenode.net/#mkav -- robUx4 on blog From paul at msn.com Tue Sep 7 01:28:04 2004 From: paul at msn.com (Paul Bryson) Date: Mon, 6 Sep 2004 18:28:04 -0500 Subject: [Matroska-devel] Re: IRC down References: <413C30D0.1040809@free.fr> Message-ID: "Steve Lhomme" wrote in message news:413C30D0.1040809 at free.fr... > As always when there is IRC problems, we should meet on : > irc://irc.freenode.net/#matroska-dev > and/or > irc://irc.freenode.net/#mkav Back up again. From ibrahimhafez at msn.com Tue Sep 7 01:39:31 2004 From: ibrahimhafez at msn.com (Ibrahim Hafez) Date: Tue, 07 Sep 2004 02:39:31 +0300 Subject: [Matroska-devel] Need Help woth MKV Message-ID: An HTML attachment was scrubbed... URL: From paul at msn.com Tue Sep 7 19:12:11 2004 From: paul at msn.com (Paul Bryson) Date: Tue, 7 Sep 2004 12:12:11 -0500 Subject: [Matroska-devel] Re: IRC down References: <413C30D0.1040809@free.fr> Message-ID: "Paul Bryson" wrote in message news:chirq5$5j1$1 at sea.gmane.org... > "Steve Lhomme" wrote in message > news:413C30D0.1040809 at free.fr... >> As always when there is IRC problems, we should meet on : >> irc://irc.freenode.net/#matroska-dev >> and/or >> irc://irc.freenode.net/#mkav > > Back up again. Down again. Atamido From bruno.pairault at noos.fr Wed Sep 8 17:18:15 2004 From: bruno.pairault at noos.fr (bruno pairault) Date: Wed, 8 Sep 2004 17:18:15 +0200 Subject: [Matroska-devel] Reading .mkv file (and seeking) when they are recording using Dshow failed !!! Message-ID: <20040908151824.D2E5B27E24@mx.noos.fr> Hi, I try to read .mkv file in construction. It fails except when I use VLC to read it. When I use MP9, the file is not closed !! When I use DX, the file is not closed !! MP9 use DX while it is not the case of VLC. I think there's a bug in the .mkv Source Filter which should return OK to read and Seek !! Reader is : Matroska Source + DivX decoder + Renderer Writer is Camera + DivX + matroska muxer + file writer. Can someone can help me to overcome this problem. I would like to use MP9 with .mkv file. -------------- next part -------------- An HTML attachment was scrubbed... URL: From moritz at bunkus.org Fri Sep 10 07:39:49 2004 From: moritz at bunkus.org (Moritz Bunkus) Date: Fri, 10 Sep 2004 07:39:49 +0200 Subject: [Matroska-devel] Re: I'd like to help work on a matroska API In-Reply-To: <200409092335.03010.vegard_p@broadpark.no> References: <200409092335.03010.vegard_p@broadpark.no> Message-ID: <20040910053949.GF31674@bunkus.org> Hi, great :) Thanks for your interest. I'm copying this to the Matroska development mailing list [1] which you should subscribe to. I'm not quite certain which parts need help, but there are others subscribed to it who can tell you more :) Anyway. Which operating system are you using? And what kind of experience do you have with programming? (No, this is not a job interview ;) We'd just like to get to know you a little bit.) Mosu [1] http://lists.matroska.org/ -- 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From moritz at bunkus.org Fri Sep 10 09:52:03 2004 From: moritz at bunkus.org (Moritz Bunkus) Date: Fri, 10 Sep 2004 09:52:03 +0200 Subject: [Matroska-devel] [vegard_p@broadpark.no: I'd like to help work on a matroska API] Message-ID: <20040910075203.GG31674@bunkus.org> Ups... Thanks for reminding me :) This was the mail I was replying to. 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 -------------- next part -------------- An embedded message was scrubbed... From: Vegard Pettersen Subject: I'd like to help work on a matroska API Date: Thu, 9 Sep 2004 23:35:02 +0200 Size: 2564 URL: From vegard_p at broadpark.no Fri Sep 10 15:48:09 2004 From: vegard_p at broadpark.no (Vegard Pettersen) Date: Fri, 10 Sep 2004 15:48:09 +0200 Subject: [Matroska-devel] Re: I'd like to help work on a matroska API In-Reply-To: <20040910053949.GF31674@bunkus.org> References: <200409092335.03010.vegard_p@broadpark.no> <20040910053949.GF31674@bunkus.org> Message-ID: <200409101548.10027.vegard_p@broadpark.no> On Friday 10 September 2004 07:39, Moritz Bunkus wrote: > Anyway. Which operating system are you using? And what kind of > experience do you have with programming? I've got a Major's degree in Software Engineering from Queensland University of Technology. My interests are C++, perl, linux, and Unicode. Currently I use SuSE 9.1 on a shuttle. I am interested in helping out with matroska simply because the concept of storing metadata in a common container appeals to me. In a perfect world, the metadata should belong in the filesystem, but we don't and never will live in such a world, so rather than having a bazillion of different fileformats all trying to do _too much_ with metadata, one container should find them and in... well, be sufficient. If I can help out with the "CD-in-matroska", that would be preferable, as the music-and-metadata of matroska interests me the most. I've got about 1200 CDs which I have encoded with fLAC to single files and cue-sheets. Well, that should tell you a bit about me, and I'm looking forward to working with you all. Cheers, Vegard From paul at msn.com Fri Sep 10 19:34:01 2004 From: paul at msn.com (Paul Bryson) Date: Fri, 10 Sep 2004 12:34:01 -0500 Subject: [Matroska-devel] Re: IRC down References: <413C30D0.1040809@free.fr> Message-ID: "Paul Bryson" wrote... > "Paul Bryson" wrote in message > news:chirq5$5j1$1 at sea.gmane.org... >> "Steve Lhomme" wrote in message >> news:413C30D0.1040809 at free.fr... >>> As always when there is IRC problems, we should meet on : >>> irc://irc.freenode.net/#matroska-dev >>> and/or >>> irc://irc.freenode.net/#mkav >> >> Back up again. > > Down again. And again.... Atamido From steve.lhomme at free.fr Sat Sep 11 08:11:22 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Sat, 11 Sep 2004 08:11:22 +0200 Subject: [Matroska-devel] Re: I'd like to help work on a matroska API In-Reply-To: <200409101548.10027.vegard_p@broadpark.no> References: <200409092335.03010.vegard_p@broadpark.no> <20040910053949.GF31674@bunkus.org> <200409101548.10027.vegard_p@broadpark.no> Message-ID: <4142970A.4040105@free.fr> Vegard Pettersen wrote: > On Friday 10 September 2004 07:39, Moritz Bunkus wrote: > >>Anyway. Which operating system are you using? And what kind of >>experience do you have with programming? > > > I've got a Major's degree in Software Engineering from Queensland University > of Technology. My interests are C++, perl, linux, and Unicode. Currently I > use SuSE 9.1 on a shuttle. All good. > I am interested in helping out with matroska simply because the concept of > storing metadata in a common container appeals to me. In a perfect world, the > metadata should belong in the filesystem, but we don't and never will live in > such a world, so rather than having a bazillion of different fileformats all > trying to do _too_much_ with metadata, one container should find them and > in... well, be sufficient. I completely agree on this. I care a lot about meta-information. All modern OS offer a way to store these informations or will in the near future. The problem is that it's OS dependant. When you transfer such files you completely lose all the meta data, especially since I don't know of any protocol that can transfer them over a network (maybe SOAP can do that quite inefficiently). So at some point you have to decide if you prefer these info to only remain on your computer or allow others do access them. That's where the containers come in. They allow storing meta-information that can be accessed locally and remotely. We're almost done with the tagging system that will store the most usual meta-information about music and movies. You can have a look this URL and comment it : http://www.matroska.org/technical/specs/tagging/ You can use this ML or our IRC channel irc://irc.corecodec.com/#matroska (might be down while I write this) There are also the forums on http://www.corecodec.com/ > If I can help out with the "CD-in-matroska", that would be preferable, as the > music-and-metadata of matroska interests me the most. I've got about 1200 CDs > which I have encoded with fLAC to single files and cue-sheets. Wonderful ! At least someone who understand the need for a tagging system that can handle such case. AFAIK there is no other than Matroska that can do that. Goldenear and Mosu have worked on it this summer. We already have alpha/beta softwares that can take your FLAC+CUE files and export them to Matroska+tags. Although since the tag system has been reworked I'm not sure it's still up to date. So you might first have a look (ask Mosu on IRC). The second part you should have a look is the foobar2000 plugin which is the only way so far to play these files decently (otherwise they play in DirectShow but you won't have access to much tags). I think it's not up to date with the tag names and the tag architecture. So if you want to code something it could be that (first ;). > Well, that should tell you a bit about me, and I'm looking forward to working > with you all. Thanks a lot to you. From vegard_p at broadpark.no Sat Sep 11 20:55:53 2004 From: vegard_p at broadpark.no (Vegard Pettersen) Date: Sat, 11 Sep 2004 20:55:53 +0200 Subject: [Matroska-devel] Request: Roadmaps Message-ID: <200409112055.53196.vegard_p@broadpark.no> From the point of view of attempting to find out where I can contribute, I find it hard to orient myself as to what is going on in the project. What I would like to see, is a roadmap for each part of the project: * who is working on what * which features are they prioritising * which features are they postphoning (where can I contribute) * for what reason are they postphoning the features (are they waiting on other parts of the project) * what are some of the plans for future development (openings for new developers, in which they can have a crack at more or less independent work) * etc. I would also like to know what channels of communication are used the most - some people post more or less development news at hydrogenaudio, some post at corecodecs.com, there is talk of a more-or-less stable IRC-channel (I loathe IRC as a medium for reliable, archivable information, myself), and then there is this mailinglist, which seems more or less formal. Just a few viewpoints, Vegard Pettersen From steve.lhomme at free.fr Sun Sep 12 16:45:32 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Sun, 12 Sep 2004 16:45:32 +0200 Subject: [Matroska-devel] Request: Roadmaps In-Reply-To: <200409112055.53196.vegard_p@broadpark.no> References: <200409112055.53196.vegard_p@broadpark.no> Message-ID: <4144610C.2060103@free.fr> Vegard Pettersen wrote: > From the point of view of attempting to find out where I can contribute, I > find it hard to orient myself as to what is going on in the project. We have a TODO page : http://www.matroska.org/team/todo.html > What I would like to see, is a roadmap for each part of the project: > * who is working on what As Mosu said, most programs are one-man projects. But as we only deal with open source softwares, anyone is free to contribute. > * which features are they prioritising We don't really have priorities. It's only what developers would like to work on, or what the users ask. For example I started working on the menu system a few weeks ago because Haali wanted to work on it. > * which features are they postphoning (where can I contribute) All that is on the TODO page. We'd like to support all that is there. And if it's there, it's not done yet :) > * for what reason are they postphoning the features (are they waiting on other > parts of the project) Time, need, lack of documentation. > * what are some of the plans for future development (openings for new > developers, in which they can have a crack at more or less independent work) We are currently working on the menu and tags that are almost not supported anywhere. There is a lot of work to do there. What I'd like is also Wavpack support before we have all Matroska features done. Because it will probably use a feature that is currently not used by other codec. > I would also like to know what channels of communication are used the most - > some people post more or less development news at hydrogenaudio, some post at > corecodecs.com, there is talk of a more-or-less stable IRC-channel (I loathe > IRC as a medium for reliable, archivable information, myself), and then there > is this mailinglist, which seems more or less formal. IRC is by far where most informations are exchanged between developpers. And we spend a lot of time there. Otherwise the mailing lists and the website (not for discussing but as a reference for the format). We also keep logs of all IRC discussions :) From moritz at bunkus.org Tue Sep 14 09:49:04 2004 From: moritz at bunkus.org (Moritz Bunkus) Date: Tue, 14 Sep 2004 09:49:04 +0200 Subject: [Matroska-devel] nut and menus Message-ID: <20040914074904.GX31674@bunkus.org> Heya, Rich Felker talking about menus & nut: http://mplayerhq.hu/pipermail/mplayer-dev-eng/2004-September/029286.html A very interesting read IMHO. 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 Sep 14 11:19:35 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Tue, 14 Sep 2004 11:19:35 +0200 Subject: [Matroska-devel] Re: NUT/menus proposal In-Reply-To: <20040913153740.GZ281@brightrain.aerifal.cx> References: <20040911091810.B06523A199@mail.mplayerhq.hu> <200409131336.03546.michaelni@gmx.at> <20040913123709.GV281@brightrain.aerifal.cx> <200409131519.09918.michaelni@gmx.at> <20040913153740.GZ281@brightrain.aerifal.cx> Message-ID: <4146B7A7.5080407@free.fr> Hi, It's nice to see menu discussions happening elsewhere, as we (matroska) are currently implementing menu support/ripping. D Richard Felker III a ?crit : > in our discussion on irc, i started with the observation that menus > consist of a bunch of resources, which at present are likely to be > still pictures, movies, subpictures, sounds, and who knows what else. You forget important parts : interactive buttons and a command language. > in principle there are only two possible places to store these > resources: inside your movie (.nut) file, or outside. > > first let's suppose we choose inside. by design a single nut file is > intended to represent only _one_ continuous unit of media. this is > very important, to avoid brain damage like dvd where we have resetting > timestamps and other nonsense. already we see that there's not a > logical place for menu resources to be muxed. in fact, if we mux the You seem to be starting from the conclusion to explain your point. IMO muxing video, audio, subs and all other kind of stuff should fit nicely in an A/V container. AFAIK on a DVD you never display video frames or audio samples in reverse order. You just play part of the DVD in a non-linear way. But the timecode (in MPEG) still highly matters. > menu resources starting at timestamp 0, they'll be _interleaved_ with > the main movie (remember correct interleaving rule). this is clearly > not what we want since it will hurt performance and makes no sense. so > instead we make up a really high starting timestamp, in order to allow > ourselves to mux the menu resources after the movie. this is > technically legal as far as i can tell, but it's still ridiculous > since it violates the design principle that a nut file should be a > single continuous unit of media. Maybe that's something that can't be changed in NUT. But it's a drawback that has no advantage. In Matroska the timecode is also very important, you can't get rid of it. But we also allow playing the file non-contiguously. This is done using chapters, with a start/stop timecode, that are saved in non-linear order and played in this same order. The file can still play linearly with old school players, but it will lack an interresting feature. Just because the player doesn't support the feature, not because the data shouldn't be there. > if we want to avoid the brain damage, the only alternatives are > sacrificing some of the clean design of nut (definitely _not_ worth it > for menus!) or storing the menu resources _outside_ of the nut file. > more on that later. How about attachments then ? > so, here comes the proposal. it's based on some comments by ivan: > > <@iive> actually menus are used for 2 things > <@iive> visually choose playing streams > <@iive> and choosing playing file > <@iive> as nut contains only one file (content) the menu is not so needed > <@iive> about choosing stream, this info is already present How would you play Memento or Irr?versible in a non-linear way without menus ? (ok in Matroska, you just select another chapter edition) > <@iive> actually, one of the biggest drawbacks of DVD menus, is that > they are different for every film > <@iive> you have no idea how many people cannot manage to turn on > bulgarian subtitles with stock DVD's In the other hand you have no idea how many people have been requesting the menu feature in Matroska. People want their rips as close to the original as possible. And there are interactive DVDs that won't make sense without all the menus features. Is it worth designing a completely new format that would store video, audio, subs, buttons, commands just to allow that ? > the nice bonus is that this format could be used with any container, > not just nut. so we might get help from people who are more interested > in menus (like the matroska crowd) so we don't have to waste our time > and dirty our hands with that stuff. The current menu system in Matroska is just a rip of the menu features in a DVD. And it's put in a "chapter codec". Which means that other codec could be used when they appear. The current system we're developping is meant to allow easy DVD -> MKV -> DVD without losing any key element. And people clearly want a single file for that, because we leave in a P2P world... I don't think .zip or .tar would either be valid options for anyone... PS: We have still not decided where the buttons should be put : in chapters or in a "Control Track". From moritz at bunkus.org Wed Sep 15 21:14:52 2004 From: moritz at bunkus.org (Moritz Bunkus) Date: Wed, 15 Sep 2004 21:14:52 +0200 Subject: [Matroska-devel] Request: Roadmaps In-Reply-To: <200409112055.53196.vegard_p@broadpark.no> References: <200409112055.53196.vegard_p@broadpark.no> Message-ID: <20040915191452.GD23274@bunkus.org> Hi, sorry for the delay. I'm more busy and lazy than usual, so I forgot about the reply I promised. But here it goes. > What I would like to see, is a roadmap for each part of the project: > * who is working on what Well basically: - mkvtoolnix ( https://www.bunkus.org/videotools/mkvtoolnix/ )is my baby, and I'm actively working on it. A bit about my plans can be found in my mail about the '1.0 release plan' at http://lists.matroska.org/pipermail/matroska-users/2004-August/000199.html - When I'm bored with mkvtoolnix or when I just need a change of scenery I work on RbMatroska, a EBML/Matroska implementation in Ruby. Yes, it's slow, yes, it's probably complicated, but it's fun, and sometimes I need that :) I don't have any specific goal for it, but what I definitely like about it is that development in Ruby is WAY faster than development in C++. As the Ruby implementation is based on on libebml/libmatroska I can prototype in Ruby and convert that to C++ later. Well, that's really not top priority ;) https://svn.matroska.org/svn/matroska/trunk/RbMatroska/ - I'm writing a couple of scripts in Ruby that take input from well-known web pages and convert those to XML tags that can be used with mkvmerge: https://svn.bunkus.org/mosu/trunk/prog/video/matroska-tag-scripts/ I don't really need help in these three projects. I could use some help with my top priority feature request, support for appending Matroska / any input files with mkvmerge. But as mkvtoolnix contains very, very involved code I don't think it'd be fair to ask you to look into that because it would require way too much time on your part. That time could be spent better. All this stuff is available for both Linux and Windows. - Haali is working on a new Matroska splitter for DirectShow. He's also trying to write a new subtitle filter on top of that. Very impressive work, but I think you said you're on Linux, so no use in helping here either. - John 'spyder442' is working on a tool that can read MPEG2 elementary streams and put them into a Matroska file. mkvmerge cannot read MPEG1/2 streams at the moment, so this is definitely one cool tool. mkvmerge can read the resulting files, though, so it is possible to have MPEG2 and e.g. Vorbis in a Matroska file ;) Again a Windows tool. - Steve 'robux4' Lhomme is working on menu support for Matroska at the moment. He's heavily looking into the DVD specs at the moment and is writing a Windows application that can convert the DVD menu structure into the corresponding Matroska XML code which in turn can be read by "experimental" mkvmerge versions. I guess that the DVD specs could definitely use some more people thinking about them. - Steve is also working on the tag specs with Prodoc and Goldenear. Prodoc is basically comparing various tag specs (ID3, Ape etc.) and discussing with Steve how best to adjust the Matroska tag specs. The goal is to have a set of official specs soon. Goldenear is the guy pushing us to get "one audio CD in one Matroska file" working. It is already working, but as we're still changing the tag specs it's not finalized yet. You can read more about this at http://www.hydrogenaudio.org/forums/index.php?showtopic=23022 and in other posts in the Hydrogenaudio forum. As you've said that this is of interest to you, too, you should probably read up about this, play around with mkvmerge's current "use a CUE sheet for chapters" function and tell us what you think could be improved. - Toff is working on several filters/plugins for Windows from time to time. I'm not really up to date with those :/ - Same goes for jcsston... - Alexander 'alexnoe' Noe is working on his Windows application "AVIMux GUI" which can write Matroska files. ... > * which features are they prioritising Well... Dunno about the others. Most work goes into finishing the tag specs and the menu/chapter specs (menus heavily depend on chapters, so those are affected as well). I work on fixing bugs in mkvtoolnix at the moment. My next feature will be a generic XML based input module that Haali requested. > * which features are they postphoning (where can I contribute) Menu specs, tag specs, chapter specs, "one CD in one Matroska file" and "multiple CDs in one Matroska file" (involving specs and chapters mostly). Probably others. > * what are some of the plans for future development (openings for new > developers, in which they can have a crack at more or less > independent work) Our biggest aim is to write a VirtualDub like application (or avidemux2 like application if you want a Linux pendant ;)) that handles Matroska files and most of Matroska's features based on gstreamer. For that Steve Lhomme has ported gstreamer to Windows. That's the only code that has been written for this so far, so there's LOTS to be done. The only other thing we've agreed upon so far is using wxWidgets (formerly wxWindows) as the GUI toolkit because it's the only powerful free/OSS cross-platform GUI toolkit available (Qt rocks more but is not free for Windows). > I would also like to know what channels of communication are used > the most - some people post more or less development news at > hydrogenaudio, some post at corecodecs.com, there is talk of a > more-or-less stable IRC-channel (I loathe IRC as a medium for > reliable, archivable information, myself), and then there is this > mailinglist, which seems more or less formal. Yes, you've mentioned them all. Our primary forums are forum.doom9.org (although we're clashing with some of the moderators there regularly), hydrogenaudio.org and corecodec.org. Those are mostly places for communicating with other users and for handling bug reports. Communication between developpers is taking place on IRC mostly. I am logging everything, and I'm online 24/7 unless my connection's broken, so I usually have everything if someone wants to look up something. Users do, too. We have users from all kinds of time zones. Most of our developpers are from France (robux4, toff), Germany (alexnoe, myself), the USA (spyder482, jcsston) and Russia (Haali). It's similar for the 'permant non-developpers' (Atamido, Prodoc, Goldenear, ChrisHJW) etc.pp. The more formal place for communication, especially when they involve more lengthy things (like this email), is this mailing list. The second important list is matroska-cvs which receives a notification about each commit to our Subversion repositories. As our web page is kept in those repos as well we'll receive commit messages about spec changes, too. That's the best way of keeping track of such changes when you're not following the discussion on IRC (like myself. I'm on 24/7, but I don't really read everything, especially lengthy discussions about the tags ;)). Well, this email is too long already, so I better stop now. Time to get a nice cup of tea. 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 Sep 15 21:28:29 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Wed, 15 Sep 2004 21:28:29 +0200 Subject: [Matroska-devel] Request: Roadmaps In-Reply-To: <20040915191452.GD23274@bunkus.org> References: <200409112055.53196.vegard_p@broadpark.no> <20040915191452.GD23274@bunkus.org> Message-ID: <414897DD.8070502@free.fr> Moritz Bunkus a ?crit : > - Steve 'robux4' Lhomme is working on menu support for Matroska at the > moment. He's heavily looking into the DVD specs at the moment and is > writing a Windows application that can convert the DVD menu structure > into the corresponding Matroska XML code which in turn can be read by > "experimental" mkvmerge versions. I guess that the DVD specs could > definitely use some more people thinking about them. Well, the application should work the same on Linux and OSX. You can get the latest build for Windows at : http://www.matroska.org/~robux4/dvd/ I'll make Linux and OS X builds when I'll have done the 2 pending TODO... From steve.lhomme at free.fr Thu Sep 16 14:33:04 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Thu, 16 Sep 2004 14:33:04 +0200 Subject: [Matroska-devel] DVD Menu Message-ID: <41498800.4010308@free.fr> I'm almost done with the chapter part of the DVD menu. I'm just missing the actual timecodes of cells in the .vob file (dunno if that's the way it's stored, I have to investigate a bit). The menu keeps 100% of the needed /partition/ data to play a DVD with menus. All commands are supported, and you can even keep the prohibited commands inside a PGC (could be enabled/disabled in the filter). The next step will be to extract audio, video, subs, buttons in separate files. Each file corresponding to a timecode in the destination matroska file that will be muxed. This way you can mux directly the files into matroska and have about the same data as on the DVD (the size might be significantly smaller than the original DVD). Or you can reencoded some files (e.g. the MPEG2 into RV9 and the AC3 into AAC) and mux these files into the matroska files. That's probably what will be used by rippers. That means we'll have to either have one track per file or merge some files that are contiguous & for the same language (before reencoding). I think the final solution should be flexible enough to allow keeping the menu or not. I'm thinking about creating a text file format to indicate to the muxer (mkvtoolnix and/or AMG) what file corresponds to what track and timecode start. Something that could look like this : Any comments highly welcome. And even better, info on VOB files ! -- robUx4 on blog From steve.lhomme at free.fr Thu Sep 16 17:39:00 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Thu, 16 Sep 2004 17:39:00 +0200 Subject: [Matroska-devel] Multi-Angle Message-ID: <4149B394.6030601@free.fr> As we're getting closer and closer to nice DVD ripping, we need to handle multi-angles... I see 3 options : - handle each angle as a separate video track - put the angles in the same track sequentially, and jump to other part of the movie when using "managed" chapters (a bit ugly, especially timecode-wise) - add support in Matroska frames/block for an angle number. IMO the latter is the cleanest. Any opinion ? -- robUx4 on blog From steve.lhomme at free.fr Thu Sep 16 17:54:04 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Thu, 16 Sep 2004 17:54:04 +0200 Subject: [Matroska-devel] Multi-Angle In-Reply-To: <4149B394.6030601@free.fr> References: <4149B394.6030601@free.fr> Message-ID: <4149B71C.30502@free.fr> Steve Lhomme a ?crit : > As we're getting closer and closer to nice DVD ripping, we need to > handle multi-angles... > > - add support in Matroska frames/block for an angle number. In this case I see 3 options to store it : - add an element in BlockGroup that would set the "sub-stream" number, mandatory that would default to 0 (or 1) for backward compatibility - put this info in the Block, that would mean adding a new octet in there (even though we could use the 5 remaining bits, but DVDs can have 255 angles) - use a flag in the Block that says there are many angle In case #2 and #3 the advantage is that we keep the same timecode+duration, as on DVD. But that needs some kind of lacing that might not be good for video frames. I prefer #1: easy and simple and more flexible. The drawback is that that means we can have many BlockGroups for the same track and with overlapping timecodes. So we can have a 4th option : - add a new BlockGroup type (maybe a BlockGroupType element inside BlockGroup) that would allow another kind of Block element. This way we can introduce the so called Block2. It will break backward compatibility for files that have multi-angle. But that's not a big deal in this case... Opinions ? -- robUx4 on blog From steve.lhomme at free.fr Thu Sep 16 19:16:32 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Thu, 16 Sep 2004 19:16:32 +0200 Subject: [Matroska-devel] Multi-Angle In-Reply-To: <4149B71C.30502@free.fr> References: <4149B394.6030601@free.fr> <4149B71C.30502@free.fr> Message-ID: <4149CA70.6090202@free.fr> Steve Lhomme a ?crit : > Steve Lhomme a ?crit : > >> As we're getting closer and closer to nice DVD ripping, we need to >> handle multi-angles... >> >> - add support in Matroska frames/block for an angle number. > > > In this case I see 3 options to store it : > - add an element in BlockGroup that would set the "sub-stream" number, > mandatory that would default to 0 (or 1) for backward compatibility > - put this info in the Block, that would mean adding a new octet in > there (even though we could use the 5 remaining bits, but DVDs can have > 255 angles) > - use a flag in the Block that says there are many angle > > In case #2 and #3 the advantage is that we keep the same > timecode+duration, as on DVD. But that needs some kind of lacing that > might not be good for video frames. > > I prefer #1: easy and simple and more flexible. The drawback is that > that means we can have many BlockGroups for the same track and with > overlapping timecodes. > > So we can have a 4th option : > - add a new BlockGroup type (maybe a BlockGroupType element inside > BlockGroup) that would allow another kind of Block element. This way we > can introduce the so called Block2. It will break backward compatibility > for files that have multi-angle. But that's not a big deal in this case... Actually all above solutions will break playback by older players when multi-angle is used. They already can't handle multiple video tracks, and this time it's even trickier. And no solution will break files using what is currently used... But if we introduce a Block2 some people might be tempted to be using that only ;) -- robUx4 on blog From agebosma at home.nl Thu Sep 16 20:47:42 2004 From: agebosma at home.nl (Age Bosma) Date: Thu, 16 Sep 2004 20:47:42 +0200 Subject: [Matroska-devel] Mapping the tag leftovers Message-ID: <4149DFCE.60302@home.nl> Ok, the following tags of ID3, APE and RIFF are the leftovers which have no mapping to Matroska yet. Some info we don't need at all, some info might already be stored elsewhere in Matroska. Can you point out those tags which can be mapped elsewhere in Matroska and where to? E.g. like: - SYNCEDLYRICS which is muxed with audio as subtitles - PICTURE which is now an attachment in image format - ISFT (software package used to create the file) which is stored elsewhere in WritingApp Only the obvious possibilities are listed here. ID3: - FILETYPE Indicates, by defined codes, which type of audio this tag defines; e.g. "MPEG Audio" (default), "MPEG 1/2 layer III", "Advanced Audio Compression", etc. - SONGLEN Length of the audio file in milliseconds. - PLAYLISTDELAY Defines the numbers of milliseconds of silence that should be inserted before this audio. - SIZE Contains the size of the audiofile in bytes, excluding the ID3v2 tag. - EVENTTIMING Allows synchronisation with key events in the audio. - MPEGLOOKUP MPEG location lookup table to increase performance and accuracy of jumps within an audio file. - SYNCEDTEMPO Synchronised tempo codes for a more accurate description of the tempo of a musical piece. - EQUALIZATION2 Subjective alignment frame to predefine an equalisation curve within the audio file. - REVERB Subjective frame that allows you to adjust echoes of different kinds. - GENERALOBJECT In this frame any type of file can be encapsulated. - BUFFERSIZE Buffer size recommended by the server using this frame (in case of streaming). - AUDIOCRYPTO Indicates if the actual audio stream is encrypted, and by whom. - LINKEDINFO Used to link information from another ID3v2 tag. - POSITIONSYNC Delivers information to the listener of how far into the audio stream he picked up. - CRYPTOREG To identify with which method a frame has been encrypted. - SEEKFRAME This frame indicates where other tags in a file/stream can be found. - AUDIOSEEKPOINT Makes seeking in audio files with variable bit rates easier using an audio seek point index. - VOLUMEADJ Used to indicate how much the volume on each channel has to be increased/decreased while the file is played. - EQUALIZATION Subjective alignment frame to predefine an equalisation curve within the audio file. - GROUPINGREG Enables grouping of otherwise unrelated frames; e.g. when some frames are to be signed. - SIGNATURE Enables a group of frames, grouped with GROUPINGREG, to be signed. APE: - FILE File location. - INDEX Indexes for quick access. - INTROPLAY Characteristic part of piece for intro playing. RIFF: - IDPI Dots Per Inch. Stores dots per inch setting of the digitizer used to produce the file, such as "300." - ILGT Lightness. Describes the changes in lightness settings on the digitizer required to produce the file. Note that the format of this information depends on hardware used. - IPLT Palette Setting. Specifies the number of colors requested when digitizing an image, such as "256." - ISHP Sharpness. Identifies the changes in sharpness for the digitizer required to produce the file (the format depends on the hardware used). - ICRP Cropped. Describes whether an image has been cropped and, if so, how it was cropped. For example, "lower right corner." - IDIM Dimensions. Specifies the size of the original subject of the file. For example, "8.5 in h, 11 in w." - ICNT* Country For more needed info you can find the temporary almost finished reference here: http://hobba.hobba.nl/audio/tagframe_temp.html Cheers, Age From paul at msn.com Fri Sep 17 00:28:29 2004 From: paul at msn.com (Paul Bryson) Date: Thu, 16 Sep 2004 17:28:29 -0500 Subject: [Matroska-devel] Re: Multi-Angle References: <4149B394.6030601@free.fr> Message-ID: "Steve Lhomme"wrote... > - handle each angle as a separate video track For files with multiple video tracks, current splitters will only show the first track. (Previously all tracks were shown at the same time but Gabest 'fixed' this.) Assuming you are writing a new splitter anyway, this shouldn't be to much of an issue. Of course, you will have to write a video switcher, and that might make life quite interesting. In one example, if you had an alternate angle for a scene from 06:34 to 08:15, then you would create a second video track with the first Block at 06:34 and the last Block at 08:15. Then when you mux the tracks together, the different angles will occupy the same physical location of the file making switching from one to the other much more seamless. (Also makes it possible to use multi-angle while streaming.) > - put the angles in the same track sequentially, and jump to other part of > the movie when using "managed" chapters (a bit ugly, especially > timecode-wise) This seems like a perfectly viable option, and would work for current players, the exception being that they would at some point show all of the angles if the entire file is played back. One possible drawback is that when using the multi-angle feature, you are almost garaunteed to have a slight pause as the player has to seek to another point in the file. Some good buffering could take care of this, but that adds complexity. > - add support in Matroska frames/block for an angle number. This seems completely unecessary as either of the other two options should work. > IMO the latter is the cleanest. Any opinion ? Honestly, either of the first two should be viable options, though one is likely to work better than the other. Assuming that making a video switcher does not prove to be to difficult, I think that I would vote for the multiple-tracks method. However the single track method seems perfectly reasonable. Atamido From electronimonyc at yahoo.com Fri Sep 17 05:21:38 2004 From: electronimonyc at yahoo.com (Brett Sherman) Date: Thu, 16 Sep 2004 20:21:38 -0700 (PDT) Subject: [Matroska-devel] mkv file help Message-ID: <20040917032138.92105.qmail@web20922.mail.yahoo.com> howdy i came across my first mkv files today and was amazed at how small the files are while downjloading and how fast they can be accessed problem is I have no idea how to open them i am using my MAC OS 10.28 typically i have been using vlc version 7.2 for my avi files but now im confused- i tried it to open the mkv but only got ausio and No picture it gave me the message "main: no suitable decoder module for fourcc `VP62'. VLC probably does not support this sound or video format. Any suggestions on how i can best play these files is much appreciated Many thanx b From moritz at bunkus.org Fri Sep 17 09:21:15 2004 From: moritz at bunkus.org (Moritz Bunkus) Date: Fri, 17 Sep 2004 09:21:15 +0200 Subject: [Matroska-devel] Multi-Angle In-Reply-To: <4149B394.6030601@free.fr> References: <4149B394.6030601@free.fr> Message-ID: <20040917072115.GO23274@bunkus.org> Hey, > - handle each angle as a separate video track Sucks. > - put the angles in the same track sequentially, and jump to other part > of the movie when using "managed" chapters (a bit ugly, especially > timecode-wise) Sucks. > - add support in Matroska frames/block for an angle number. Sucks. > IMO the latter is the cleanest. Any opinion ? A fourth. Ok, after being harsh I should explain why I think that all three options suck. What I would like to see is that multiangle files can be played on current demuxers without throwing up (if they're bug free). Of course current demuxers cannot select the other angles, but they should be able to play the default angle completely without hickuping. 1. 'Seperate video track' Bad because the players would think that there IS actually another video track. The user might then select that video track and the player would probably go to hell because it doesn't receive data for a long time, only where there are two angles. 2. 'Put angles in the same track sequentially' Bad because a) timecodes would not be continous, b) current demuxers would show all angles after another totally breaking A/V sync, c) interleaving would be completely off, d) would be non-compliant with the specs (see BlockDuration, "When not written and with no DefaultDuration, the value is assumed to be the difference between the timecode of this Block and the timecode of the next Block in "display" order (not coding order).")... I could find even more arguments against it. 2 simply sucks. 3. 'add support in Matroska frames/block for angle number' Nearly the same arguments as in 2. Mainly it would break playback on current demuxers. ---------- My proposal is that we should create a new _track type_ for this kind of thing. At the moment six track types are defined and three are used (audio, video, subtitles; complex, logo, control). I'd like to add a track that is 'associated' with another track. The track headers would ONLY contain two or three (new) elements: - TrackID, TrackUID (needed, currently used as well), - TrackAssociatedUID (the track UID this track refers to), - TrackSubID ("angle number", sub-ID for this track, defaults to 0, must/may also be written for the "main" track) All the other elements must not be present. The "associated" track has the same properties as the track it is associated to. The data packets ( = blocks) are interleaved normally according to their timecode. At those places where there are several angles available the player can display other angles if the user/control wants that. This would need small buffering IF and ONLY IF the sub-ID is != 0. If it is 0 then the demuxer can simply send all packets for that track downstream. If the sub-ID is != 0 then the player has to buffer exactly one packet for that track. It reads until it finds either a packet with the same timecode for the WANTED sub-ID or until it finds another packet with a different timecode for the "main" stream. Advantages: - Current demuxers will see unknown tracks and skip them. - Current demuxers will see blocks for a track they don't handle, so they just skip them. - The overhead will not increase. - We make use of Matroska's extensibility without requiring the user to update software -- only if they WANT the new features. "Normal" files created with those new tools will still play with old/current players. - Those new files will be just as spec compliant as current ones are. Interleaving is kept intact. Disadvantages: None that I can see. What do you think? 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 Fri Sep 17 09:29:12 2004 From: moritz at bunkus.org (Moritz Bunkus) Date: Fri, 17 Sep 2004 09:29:12 +0200 Subject: [Matroska-devel] Multi-Angle In-Reply-To: <20040917072115.GO23274@bunkus.org> References: <4149B394.6030601@free.fr> <20040917072115.GO23274@bunkus.org> Message-ID: <20040917072912.GP23274@bunkus.org> Hi, clarification: > This > would need small buffering IF and ONLY IF the sub-ID is != 0. If it is 0 > then the demuxer can simply send all packets for that track > downstream. The 'sub-ID' here is the one that should be displayed, e.g. after the user has chosen it from a menu or something like that. > If the sub-ID is != 0 then the player has to buffer exactly one packet > for that track. It reads until it finds either a packet with the same > timecode for the WANTED sub-ID or until it finds another packet with a > different timecode for the "main" stream. Same here. 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 Sep 17 09:40:05 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Fri, 17 Sep 2004 09:40:05 +0200 Subject: [Matroska-devel] Re: [Matroska-users] mkv file help In-Reply-To: <20040917032138.92105.qmail@web20922.mail.yahoo.com> References: <20040917032138.92105.qmail@web20922.mail.yahoo.com> Message-ID: <414A94D5.3070108@free.fr> Brett Sherman a ?crit : > howdy > i came across my first mkv files today and was amazed > at how small the files are while downjloading and how > fast they can be accessed > problem is I have no idea how to open them > i am using my MAC OS 10.28 > typically i have been using vlc version 7.2 for my avi > files but now im confused- i tried it to open the mkv > but only got ausio and No picture > it gave me the message > "main: no suitable decoder module for fourcc `VP62'. > VLC probably does not support this sound or video > format. > Any suggestions on how i can best play these files is > much appreciated > Many thanx VLC is a great player. But for political reasons they refuse to support proprietary codec (because it would violate the GPL). It's sad because it could be *the* player anyone could use on all platforms. Given that I have no idea what kind of codec VP62 is ! You might try MPlayerOSX which can read Matroska files too. You can get binaries from SourceForge. From steve.lhomme at free.fr Fri Sep 17 10:05:41 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Fri, 17 Sep 2004 10:05:41 +0200 Subject: [Matroska-devel] Multi-Angle In-Reply-To: <20040917072115.GO23274@bunkus.org> References: <4149B394.6030601@free.fr> <20040917072115.GO23274@bunkus.org> Message-ID: <414A9AD5.3090906@free.fr> Moritz Bunkus a ?crit : > My proposal is that we should create a new _track type_ for this kind of > thing. At the moment six track types are defined and three are used > (audio, video, subtitles; complex, logo, control). I'd like to add a > track that is 'associated' with another track. The track headers would > ONLY contain two or three (new) elements: > > - TrackID, TrackUID (needed, currently used as well), > - TrackAssociatedUID (the track UID this track refers to), > - TrackSubID ("angle number", sub-ID for this track, defaults to 0, > must/may also be written for the "main" track) We already have tracks that can be associated with others using TrackOverlay. "u-integer Specify that this track is an overlay track for the Track specified (in the u-integer)." > All the other elements must not be present. The "associated" track has > the same properties as the track it is associated to. Then IMO it should be specified. Otherwise that would make tracks with full info and the others without. And besides they may use different codec. So IMO it's better to have a full-featured track. For the rest we know it's special because it's an overlay track (could be used for audio, video, subs, etc). > Advantages: > > - Current demuxers will see unknown tracks and skip them. > - Current demuxers will see blocks for a track they don't handle, so > they just skip them. > - The overhead will not increase. > - We make use of Matroska's extensibility without requiring the user to > update software -- only if they WANT the new features. "Normal" files > created with those new tools will still play with old/current players. > - Those new files will be just as spec compliant as current ones > are. Interleaving is kept intact. > > Disadvantages: > - You can't use different codecs. - The track can't be used without the main track (not true for DVD) - you don't know if it's an audio, video or whatever track by looking at it > What do you think? You forgot to talk about my proposition for a new Block, or more specifically a new BlockGroup type (actually a BlockGroupVersion that would have value 2 in this case). IMO it makes as much good sense as using different tracks for the content (the other options are simply not good). Advantages : - no need for a track for each angle - you can have 9 angles on one part of the movie and 15 later - the parser is always looking for the same track * the main angle (corresponds to the main track in the other option) could keep the Block as it is now to keep full backward compatibility - when extractting to DVD (see dvd->mkv->dvd) it looks better to output different angles in a BlockGroup into different angle cells, than parsing all possible tracks - avoid having blocks for an angle in another cluster than the main track - The file can be easily remuxed to keep only one angle Disadvantages: - You can't use different codecs. From moritz at bunkus.org Fri Sep 17 10:25:09 2004 From: moritz at bunkus.org (Moritz Bunkus) Date: Fri, 17 Sep 2004 10:25:09 +0200 Subject: [Matroska-devel] Multi-Angle In-Reply-To: <414A9AD5.3090906@free.fr> References: <4149B394.6030601@free.fr> <20040917072115.GO23274@bunkus.org> <414A9AD5.3090906@free.fr> Message-ID: <20040917082509.GQ23274@bunkus.org> Hi, > We already have tracks that can be associated with others using > TrackOverlay. > "u-integer Specify that this track is an overlay track for the Track > specified (in the u-integer)." That's not what I meant. I want a new track type, not use another element and have a normal track. Again the argument that a current parser will be greatly confused by this. > Then IMO it should be specified. Otherwise that would make tracks with > full info and the others without. That's my idea. Have the main track contain all the codec information and have the others not contain them. > And besides they may use different codec. Ooooooooooooh my god! And different resolution, too, I guess? Is this possible on a DVD, too!? If not then we shouldn't allow this either. This is VERY complicated to handle. No one will ever support this (apart from Haali). > - You can't use different codecs. That's actually an advantage. > - The track can't be used without the main track (not true for DVD) That's not a disadvantage. You either have both tracks (main and associated) in the same file or the application that copies such an associated track out of the main file has to 'fill in' the codec data from the main track. > - you don't know if it's an audio, video or whatever track by looking > at it Just look at the associated track. This is really a non-issue. > You forgot to talk about my proposition for a new Block, Having a complete new Block might be ok (although it would be hell to handle with libmatroska) if it is ONLY used for the non-default angle packets. Old parsers could simply skip those. > or more specifically a new BlockGroup type (actually a > BlockGroupVersion that would have value 2 in this case). But this breaks things. Again. Every current parser would ignore the BlockGroupVersion element because it doesn't know it and would parse the block in the wrong way. > Advantages : > - no need for a track for each angle How is that a disadvantage? Track headers are cheap ( = small), UIDs and track IDs are plenty. > - you can have 9 angles on one part of the movie and 15 later How is that a problem? Ok, it can be a problem because the muxing app has to know the maximum number up front, but that's all. > - the parser is always looking for the same track The new one. The old one, too, and it'll BREAK because it finds much more packets or unknown block types. > * the main angle (corresponds to the main track in the other option) > could keep the Block as it is now to keep full backward compatibility Yes, that's ok, but not your BlockTypeVersion approach. We have to use a new element for that. > - when extractting to DVD (see dvd->mkv->dvd) it looks better to output > different angles in a BlockGroup into different angle cells, than > parsing all possible tracks Well... This will only be true if we break things. > - avoid having blocks for an angle in another cluster than the main > track Ok, this one's valid. > - The file can be easily remuxed to keep only one angle Only if we break things. Otherwise it's just as simple/hard as my proposal. > Disadvantages: > > - You can't use different codecs. Again, that's an advantage ;) 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 Fri Sep 17 10:31:56 2004 From: moritz at bunkus.org (Moritz Bunkus) Date: Fri, 17 Sep 2004 10:31:56 +0200 Subject: [Matroska-devel] Multi-Angle In-Reply-To: <20040917082509.GQ23274@bunkus.org> References: <4149B394.6030601@free.fr> <20040917072115.GO23274@bunkus.org> <414A9AD5.3090906@free.fr> <20040917082509.GQ23274@bunkus.org> Message-ID: <20040917083156.GR23274@bunkus.org> Hi, > > or more specifically a new BlockGroup type (actually a > > BlockGroupVersion that would have value 2 in this case). > > But this breaks things. Again. Every current parser would ignore the > BlockGroupVersion element because it doesn't know it and would parse the > block in the wrong way. I was wrong here. The BlockGroup can be kept, of course. But we still need a new block element with a new EBML ID for the reason I pointed out above. 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 Sep 17 10:42:59 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Fri, 17 Sep 2004 10:42:59 +0200 Subject: [Matroska-devel] Multi-Angle In-Reply-To: <20040917083156.GR23274@bunkus.org> References: <4149B394.6030601@free.fr> <20040917072115.GO23274@bunkus.org> <414A9AD5.3090906@free.fr> <20040917082509.GQ23274@bunkus.org> <20040917083156.GR23274@bunkus.org> Message-ID: <414AA393.8050309@free.fr> Moritz Bunkus a ?crit : > Hi, > > >>>or more specifically a new BlockGroup type (actually a >>>BlockGroupVersion that would have value 2 in this case). >> >>But this breaks things. Again. Every current parser would ignore the >>BlockGroupVersion element because it doesn't know it and would parse the >>block in the wrong way. > > > I was wrong here. The BlockGroup can be kept, of course. But we still > need a new block element with a new EBML ID for the reason I pointed out > above. Yup, and AFAIR you were part of the ones who wanted a new Block2 structure that would need less overhead. That could be a good occasion to add it. From moritz at bunkus.org Fri Sep 17 10:51:05 2004 From: moritz at bunkus.org (Moritz Bunkus) Date: Fri, 17 Sep 2004 10:51:05 +0200 Subject: [Matroska-devel] Multi-Angle In-Reply-To: <414AA393.8050309@free.fr> References: <4149B394.6030601@free.fr> <20040917072115.GO23274@bunkus.org> <414A9AD5.3090906@free.fr> <20040917082509.GQ23274@bunkus.org> <20040917083156.GR23274@bunkus.org> <414AA393.8050309@free.fr> Message-ID: <20040917085105.GS23274@bunkus.org> Hey, > Yup, and AFAIR you were part of the ones who wanted a new Block2 > structure that would need less overhead. That could be a good occasion > to add it. Yes, I was one of them. But I'm not that much inclined to force such a new block as I was back then because we ( = Matroska) don't define ourselves by having low overhead compared to other containers. At the moment I'm more in favour of not having to tell the users "you have yo upgrade your dshow filter" again. The last time is only a month ago because the Windows based apps didn't support 64bit floats. 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 Sep 17 11:05:43 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Fri, 17 Sep 2004 11:05:43 +0200 Subject: [Matroska-devel] Multi-Angle In-Reply-To: <20040917082509.GQ23274@bunkus.org> References: <4149B394.6030601@free.fr> <20040917072115.GO23274@bunkus.org> <414A9AD5.3090906@free.fr> <20040917082509.GQ23274@bunkus.org> Message-ID: <414AA8E7.3010700@free.fr> Moritz Bunkus a ?crit : > Hi, > > >>We already have tracks that can be associated with others using >>TrackOverlay. >>"u-integer Specify that this track is an overlay track for the Track >>specified (in the u-integer)." > > > That's not what I meant. I want a new track type, not use another > element and have a normal track. Again the argument that a current > parser will be greatly confused by this. So what you are asking is a new element, equivalent to Tracks ? TrackEntry ? or something else ? IMO that's quite ugly to have tracks, and "oh BTW, don't forget to read this thing that is a track and not a track at the same time, which numbers will hopefully not use another number by regular tracks". Actually you want to mix track numbers with sub-track numbers. You think it's clean to have a Matroska file with tracks that older parsers have no knowledge about ? How would current mkvmerge behave which such files that you claim are backward compatible ? BTW, about backward playability. In newer mkvmerge you forced the use of 64 bits floats even when it's not needed (only audio-only files need that), and that makes new files not playable in a few players including MPC. So don't say too loud that backward playability is a vital feature. >>And besides they may use different codec. > > > Ooooooooooooh my god! And different resolution, too, I guess? Is this > possible on a DVD, too!? If not then we shouldn't allow this > either. This is VERY complicated to handle. No one will ever support > this (apart from Haali). Well, I'm not 100% sure for DVD, but I think you can have letter-box and non-letterbox cells in the same video track, ie not the same resolution. But that's also a feature of MPEG2. And none of our solutions would handle that anyway. Using TrackOverlay can allow that feature. >>- You can't use different codecs. > > > That's actually an advantage. No, just a limitation. That's an advantage for the coders. >>- The track can't be used without the main track (not true for DVD) > > > That's not a disadvantage. You either have both tracks (main and > associated) in the same file or the application that copies such an > associated track out of the main file has to 'fill in' the codec data > from the main track. I'm mixed on that supposed easeness. Because I'm not sure some codec would not have problems if you put frames from another track in there. I'd prefer one codec instance per track (using TrackOverlay) and the overlaying is done after the codec stage. That would allow IPB frames at different locations for each track. Which seem very logical from a codec point of view (efficiency) and also to seek in the file on I frames. >>or more specifically a new BlockGroup type (actually a >>BlockGroupVersion that would have value 2 in this case). > > > But this breaks things. Again. Every current parser would ignore the > BlockGroupVersion element because it doesn't know it and would parse the > block in the wrong way. And would only read the Block as it used to do. Only other angles could make use of the new Block. We can also have BlockGroupVersion = 3 that would only use Block2, and people would know the files would not be backward compatible. >>- when extractting to DVD (see dvd->mkv->dvd) it looks better to output >>different angles in a BlockGroup into different angle cells, than >>parsing all possible tracks > > > Well... This will only be true if we break things. Neither TrackOverlay nor the BlockGroupVersion would break anything. Just adding things. >>- The file can be easily remuxed to keep only one angle > > > Only if we break things. Otherwise it's just as simple/hard as my > proposal. Again, I don't see where my 2 main options would break anything. From mike at po.cs.msu.su Fri Sep 17 11:02:08 2004 From: mike at po.cs.msu.su (Mike Matsnev) Date: Fri, 17 Sep 2004 13:02:08 +0400 Subject: [Matroska-devel] Re: Multi-Angle In-Reply-To: <20040917072115.GO23274@bunkus.org> References: <4149B394.6030601@free.fr> <20040917072115.GO23274@bunkus.org> Message-ID: <414AA810.6070802@po.cs.msu.su> A few notes: * Having different codecs in the same file is rather hard to handle, and I'd avoid it if possible, same for different resolutions. * Breaking old apps is a big no-no. In light of all this, Mosu's idea looks better. And it allows different codecs and resolutions if at some later stage we might want this (normal track info will be filled in that case). So, the only addition to the spec will be a new TrackType, and some way to tell the parser in what parts of file what additional tracks are available, like adding a list of tracks to the cluster header, or to the chapter. /Mike From steve.lhomme at free.fr Fri Sep 17 11:44:43 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Fri, 17 Sep 2004 11:44:43 +0200 Subject: [Matroska-devel] Re: Multi-Angle In-Reply-To: <414AA810.6070802@po.cs.msu.su> References: <4149B394.6030601@free.fr> <20040917072115.GO23274@bunkus.org> <414AA810.6070802@po.cs.msu.su> Message-ID: <414AB20B.8000505@free.fr> Mike Matsnev a ?crit : > A few notes: > * Having different codecs in the same file is rather hard to > handle, and I'd avoid it if possible, same for different > resolutions. > * Breaking old apps is a big no-no. Agreed. > In light of all this, Mosu's idea looks better. And it allows > different codecs and resolutions if at some later stage we > might want this (normal track info will be filled in that case). > > So, the only addition to the spec will be a new TrackType, and > some way to tell the parser in what parts of file what additional > tracks are available, like adding a list of tracks to the cluster > header, or to the chapter. IMO we should look closely at the CuenEntry and seeking functionalities we'll (not) have with all proposed systems. Also in Mosu's proposition would the TrackUID and other elements have the same EBML ID as in other places of the format ? There are pros and cons for both. But frankly TrackOverlay is not so different and much more consistent with other existing apps. Any current Matroska player will only play the first video track anyway. From moritz at bunkus.org Fri Sep 17 11:49:52 2004 From: moritz at bunkus.org (Moritz Bunkus) Date: Fri, 17 Sep 2004 11:49:52 +0200 Subject: [Matroska-devel] Multi-Angle In-Reply-To: <414AA8E7.3010700@free.fr> References: <4149B394.6030601@free.fr> <20040917072115.GO23274@bunkus.org> <414A9AD5.3090906@free.fr> <20040917082509.GQ23274@bunkus.org> <414AA8E7.3010700@free.fr> Message-ID: <20040917094952.GT23274@bunkus.org> Hey, > So what you are asking is a new element, equivalent to Tracks ? Nope. Let me draw a picture that will hopefully make clear what I propose: (best viewed with a fixed-width font) Tracks TrackEntry TrackNumber 1 TrackUID 20406080 <-+ TrackType 1 ( = video) | TrackSubID 0 <-- new FlagDefault 1 | Name 'The main angle' | CodecID 'V_MS/VFW/FOURCC' | CodecPrivate ... | Video | PixelWidth 640 | PixelHeight 480 | DisplayWidth 640 | DisplayHeight 480 | TrackEntry | TrackNumber 2 | TrackUID 1357924680 | TrackType 101 ( = associated to another track) <-- new | TrackAssociation 20406080 <-- new <-+ TrackSubID 1 <-- new Name 'A second angle' [CodecID and Video etc are missing, so copy them from the associated track] The first one (TrackNumber 1) is the one I call 'associated to', the second one the one I call 'associatee'. > TrackEntry ? or something else ? IMO that's quite ugly to have tracks, > and "oh BTW, don't forget to read this thing that is a track and not a > track at the same time, which numbers will hopefully not use another > number by regular tracks". My thing IS a track, it just has a type that's not used yet. > Actually you want to mix track numbers with sub-track numbers. No, definitely not! Such associated tracks have their own track number. Each of the associated tracks and the main track have a new element called 'sub-ID' which would probably contain the angle ID in our case. The sub-IDs and TrackNumber and TrackUID number spaces are all distinct. TrackNumber and TrackUID are unique throughout the segment, while sub-ID is unique over all tracks that belong to one association group. > You think it's clean to have a Matroska file with tracks that older > parsers have no knowledge about ? How would current mkvmerge behave > which such files that you claim are backward compatible ? Ignore them. > BTW, about backward playability. In newer mkvmerge you forced the use of > 64 bits floats even when it's not needed (only audio-only files need > that), and that makes new files not playable in a few players including > MPC. So don't say too loud that backward playability is a vital > feature. I do say it because all those splitters where not spec compliant. 64bit floats have been part of the specs since the beginning. What I want is: "if a parser is bug free and spec compliant at the moment then it should play such new files (at least the main angle) without problems". The Matroska dogma is "ignore elements that where not part of the specs at the time the demuxer was written". New files should not break parsers that follow this rule. With my proposal old charsers at least stand a chance of working properly. If they don't then we're not off worse than with other proposals because the parsers would then have to be updated in either case. > Well, I'm not 100% sure for DVD, but I think you can have letter-box and > non-letterbox cells in the same video track, ie not the same resolution. > But that's also a feature of MPEG2. And none of our solutions would > handle that anyway. Using TrackOverlay can allow that feature. Ok, the resolution change might be necessary. If the 'associatee' does not contain certain track header elements like PixelWidth etc then those are copied from the 'associated to' track. > >>- You can't use different codecs. > No, just a limitation. That's an advantage for the coders. :) Yes. But it doesn't gain you THAT much imho. Anyway, with my updated proposal you could put a CodecID into the 'associatee' and have different codecs that way. If not the demuxer must create several instances of the same codec because... > I'm mixed on that supposed easeness. Because I'm not sure some codec > would not have problems if you put frames from another track in there. > I'd prefer one codec instance per track (using TrackOverlay) and the > overlaying is done after the codec stage. That would allow IPB frames at > different locations for each track. Which seem very logical from a codec > point of view (efficiency) and also to seek in the file on I frames. ...of this. You're right, of course. > Again, I don't see where my 2 main options would break anything. They partially "break" in the sense that e.g. half empty video tracks (in the case "just add another track") will confuse players, I guess. This is not really "breaking", but it's not nice. Btw. Adding a new "BlockGroupVersion" element for each block group would cause 3 bytes overhead for _each and every frame_. Unacceptable, IMHO, even though we don't define ourselves through the overhead alone. With my proposal one big advantage is that you don't have to modify the BlockGroup, nor do you have to introduce a new Block element at all. The angle ID is contained in the track's SubID element. 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 mike at po.cs.msu.su Fri Sep 17 11:53:14 2004 From: mike at po.cs.msu.su (Mike Matsnev) Date: Fri, 17 Sep 2004 13:53:14 +0400 Subject: [Matroska-devel] Re: Multi-Angle In-Reply-To: <414AB20B.8000505@free.fr> References: <4149B394.6030601@free.fr> <20040917072115.GO23274@bunkus.org> <414AA810.6070802@po.cs.msu.su> <414AB20B.8000505@free.fr> Message-ID: <414AB40A.2080706@po.cs.msu.su> Steve Lhomme wrote: >> In light of all this, Mosu's idea looks better. And it allows >> different codecs and resolutions if at some later stage we >> might want this (normal track info will be filled in that case). >> >> So, the only addition to the spec will be a new TrackType, and >> some way to tell the parser in what parts of file what additional >> tracks are available, like adding a list of tracks to the cluster >> header, or to the chapter. > IMO we should look closely at the CuenEntry and seeking functionalities > we'll (not) have with all proposed systems. > > Also in Mosu's proposition would the TrackUID and other elements have > the same EBML ID as in other places of the format ? There are pros and > cons for both. But frankly TrackOverlay is not so different and much > more consistent with other existing apps. Any current Matroska player > will only play the first video track anyway. I meant using TrackOverlay+a new TrackType, so the track element will look like this: TrackEntry: TrackNumber 9 TrackUID 1234567 TrackType 4 (Angle) TrackOverlay 7654321 /Mike From moritz at bunkus.org Fri Sep 17 11:58:09 2004 From: moritz at bunkus.org (Moritz Bunkus) Date: Fri, 17 Sep 2004 11:58:09 +0200 Subject: [Matroska-devel] Re: Multi-Angle In-Reply-To: <414AB40A.2080706@po.cs.msu.su> References: <4149B394.6030601@free.fr> <20040917072115.GO23274@bunkus.org> <414AA810.6070802@po.cs.msu.su> <414AB20B.8000505@free.fr> <414AB40A.2080706@po.cs.msu.su> Message-ID: <20040917095809.GU23274@bunkus.org> Hey, > TrackEntry: > TrackNumber 9 > TrackUID 1234567 > TrackType 4 (Angle) > TrackOverlay 7654321 Ah yes, that would get rid of my 'TrackAssociatedID' element or whatever I called 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 Sep 17 12:15:56 2004 From: paul at msn.com (Paul Bryson) Date: Fri, 17 Sep 2004 05:15:56 -0500 Subject: [Matroska-devel] Re: Multi-Angle References: <4149B394.6030601@free.fr> <20040917072115.GO23274@bunkus.org> Message-ID: "Moritz Bunkus" wrote... > 1. 'Seperate video track' > > Bad because the players would think that there IS actually another video > track. The user might then select that video track and the player would > probably go to hell because it doesn't receive data for a long time, > only where there are two angles. On the remote possibility that a user actually selected another video track in a player that supported that (less than 3% of actual players used I would guess) AND it didn't work, then its pretty safe to assume that someone smart enough to change to a track that doesn't work can change back to a track that does. I can't see this ever being an issue. > 2. 'Put angles in the same track sequentially' > > Bad because a) timecodes would not be continous, b) current demuxers > would show all angles after another totally breaking A/V sync, c) > interleaving would be completely off, d) would be non-compliant with the > specs (see BlockDuration, "When not written and with no DefaultDuration, > the value is assumed to be the difference between the timecode of this > Block and the timecode of the next Block in "display" order (not coding > order).")... I think I was thinking of this differently. If you have a video where it begins with part A, has a part B, and ends with part D, but there is an alternate 'angle' for part B called part C, then you could store it like this: [A][B][D][C] The beginning timecodes of part C would be right after the last timecode of part D. This has the drawback of part C eventually being played in a player that doesn't honor Chapters, and also the possibility of a pause that I mentioned earlier. > My proposal is that we should create a new _track type_ for this kind of > thing. At the moment six track types are defined and three are used > (audio, video, subtitles; complex, logo, control). I'd like to add a > track that is 'associated' with another track. The track headers would > ONLY contain two or three (new) elements: To me it seems very backwards to label a VIDEO track as anything other than a video track. Even if you intend to use it as an alternate 'angle', it is still simply a video clip and could be played alone. Remember that these types of things aren't always as simple as a 1:1 alternate. For example, seamless branching where one route is just as likely to be taken as another depending on how the user sets up for what they want to watch at the beginning. Also, from the example above and using different tracks, the part C is significant longer than its counter part, part B. [...A...][...B...][...D...] [.....C.....] Do you leave a gap in the timecodes between B and D? Or what if parts B and C are both stored in separate tracks? [...A...][...D...] [.....C.....] [...B...] Or what if it is a video that has many parts that are all stored in separate tracks that are using some config set by the user to determine what order to play them in? Then which one is the 'Associated' track? For any complex scenario this just stops making any sense. Really I think that you should leave all VIDEO tracks labeled as such. The chances of any issues from this are too remotely small to be concerned about. If some player out there does have an issue, then it must not be respecting the track's FlagDefault element and it should be fixed. No need to change the specs. Atamido From moritz at bunkus.org Fri Sep 17 12:25:50 2004 From: moritz at bunkus.org (Moritz Bunkus) Date: Fri, 17 Sep 2004 12:25:50 +0200 Subject: [Matroska-devel] Re: Multi-Angle In-Reply-To: References: <4149B394.6030601@free.fr> <20040917072115.GO23274@bunkus.org> Message-ID: <20040917102550.GV23274@bunkus.org> Hey, ok, not changing the track type may work, too. We still should introduce the angle ID in the track headers and not change the block elements. That would be the least intricate way. 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 Sep 17 12:59:46 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Fri, 17 Sep 2004 12:59:46 +0200 Subject: [Matroska-devel] Multi-Angle In-Reply-To: <20040917094952.GT23274@bunkus.org> References: <4149B394.6030601@free.fr> <20040917072115.GO23274@bunkus.org> <414A9AD5.3090906@free.fr> <20040917082509.GQ23274@bunkus.org> <414AA8E7.3010700@free.fr> <20040917094952.GT23274@bunkus.org> Message-ID: <414AC3A2.8040308@free.fr> Moritz Bunkus a ?crit : > Hey, > > >>So what you are asking is a new element, equivalent to Tracks ? > > > Nope. Let me draw a picture that will hopefully make clear what I > propose: (best viewed with a fixed-width font) > > Tracks > TrackEntry > TrackNumber 1 > TrackUID 20406080 <-+ > TrackType 1 ( = video) | > TrackSubID 0 <-- new > FlagDefault 1 | > Name 'The main angle' | > CodecID 'V_MS/VFW/FOURCC' | > CodecPrivate ... | > Video | > PixelWidth 640 | > PixelHeight 480 | > DisplayWidth 640 | > DisplayHeight 480 | > TrackEntry | > TrackNumber 2 | > TrackUID 1357924680 | > TrackType 101 ( = associated to another track) <-- new | > TrackAssociation 20406080 <-- new <-+ > TrackSubID 1 <-- new > Name 'A second angle' > [CodecID and Video etc are missing, so copy them from the associated > track] I get the idea. IMO TrackOverlay == TrackSubID. I don't get what the TrackAssociation is about. What you are also asking, is changes in the specs for : - FlagEnabled - FlagDefault - FlagLacing - MinCache - TrackTimecodeScale - CodecID which all mandatory elements and all of a sudden are not present in some cases. I don't see how this solution is less breaking than others. I think there is 50% chances that MPC and other players will b0rk with messages like "dunno how to render track XYZ" because there's not even a codec set. Maybe even mkvmerge could have pb with that. TrackOverlay has been in the specs from the start and any responsible coder who encounter the element should at least trigger a warning somewhere stating he doesn't know how to support such a track. It's the same as some coders who forgot about 64 bits floats that have been there from the start. >>TrackEntry ? or something else ? IMO that's quite ugly to have tracks, >>and "oh BTW, don't forget to read this thing that is a track and not a >>track at the same time, which numbers will hopefully not use another >>number by regular tracks". > > > My thing IS a track, it just has a type that's not used yet. It is a track that has a whole new meaning, quite different that what has been said all the time. >>BTW, about backward playability. In newer mkvmerge you forced the use of >>64 bits floats even when it's not needed (only audio-only files need >>that), and that makes new files not playable in a few players including >>MPC. So don't say too loud that backward playability is a vital >>feature. > > > I do say it because all those splitters where not spec compliant. 64bit > floats have been part of the specs since the beginning. What I want is: > "if a parser is bug free and spec compliant at the moment then it should > play such new files (at least the main angle) without problems". The > Matroska dogma is "ignore elements that where not part of the specs at > the time the demuxer was written". New files should not break parsers > that follow this rule. Same goes for TrackOverlay. It's been there from the start, is quite clear, and has never been marked as "version2". > With my proposal old charsers at least stand a chance of working > properly. If they don't then we're not off worse than with other > proposals because the parsers would then have to be updated in either > case. IMO using the TrackOverlay the way it was supposed to be will create less problems than other solutions (let alone the alternative BlockGroupVersion use). >>Well, I'm not 100% sure for DVD, but I think you can have letter-box and >>non-letterbox cells in the same video track, ie not the same resolution. >>But that's also a feature of MPEG2. And none of our solutions would >>handle that anyway. Using TrackOverlay can allow that feature. > > > Ok, the resolution change might be necessary. If the 'associatee' does > not contain certain track header elements like PixelWidth etc then those > are copied from the 'associated to' track. Let's not put a lot of if() everywhere and use what has been specified already. The use of angle will, for the moment, be dependant on the DVD source, and we'll support just that. If people use different codec (IMO that should be allowed, for example some codec would do fine on Anime and bad on camera shots) and resolutions, they might have problem playing them. >>>>- You can't use different codecs. > > >>No, just a limitation. That's an advantage for the coders. > > > :) Yes. But it doesn't gain you THAT much imho. Anyway, with my updated > proposal you could put a CodecID into the 'associatee' and have > different codecs that way. If not the demuxer must create several > instances of the same codec because... Yes, several instances of codec for each track (including the overlay/angle ones) because of IPB frames, at least. So in this context, other codecs could be used too... >>Again, I don't see where my 2 main options would break anything. > > > They partially "break" in the sense that e.g. half empty video tracks > (in the case "just add another track") will confuse players, I > guess. This is not really "breaking", but it's not nice. Mh, I'm not sure which one you're talking about here. Because the half empty track that will be confusing for old players is what you propose. > Btw. Adding a new "BlockGroupVersion" element for each block group would > cause 3 bytes overhead for _each and every frame_. Unacceptable, IMHO, > even though we don't define ourselves through the overhead alone. Nop, only for the frames that have different angle. But it's true for a solution that would use only Block2... So apparently the discussion is now between a standard Track with TrackOverlay or a semi-Track with TrackAssociate. -- robUx4 on blog From steve.lhomme at free.fr Fri Sep 17 13:05:12 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Fri, 17 Sep 2004 13:05:12 +0200 Subject: [Matroska-devel] Re: Multi-Angle In-Reply-To: References: <4149B394.6030601@free.fr> <20040917072115.GO23274@bunkus.org> Message-ID: <414AC4E8.4080506@free.fr> Paul Bryson a ?crit : >>2. 'Put angles in the same track sequentially' >> > I think I was thinking of this differently. If you have a video where it > begins with part A, has a part B, and ends with part D, but there is an > alternate 'angle' for part B called part C, then you could store it like > this: > > [A][B][D][C] > > The beginning timecodes of part C would be right after the last timecode of > part D. This has the drawback of part C eventually being played in a player > that doesn't honor Chapters, and also the possibility of a pause that I > mentioned earlier. This is not clean timecode-wise at all. We should not enforce the use of /managed/ chapters to play a multi-angle file. Actually it should play without chapters. > Really I think that you should leave all VIDEO tracks labeled as such. The > chances of any issues from this are too remotely small to be concerned > about. If some player out there does have an issue, then it must not be > respecting the track's FlagDefault element and it should be fixed. No need > to change the specs. /me applauses Atamido :) I forgot about the FlagDefault which is track-type dependant: " Set if the track is the default for its TrackType." From steve.lhomme at free.fr Fri Sep 17 13:11:41 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Fri, 17 Sep 2004 13:11:41 +0200 Subject: [Matroska-devel] Multi-Angle In-Reply-To: <414AC3A2.8040308@free.fr> References: <4149B394.6030601@free.fr> <20040917072115.GO23274@bunkus.org> <414A9AD5.3090906@free.fr> <20040917082509.GQ23274@bunkus.org> <414AA8E7.3010700@free.fr> <20040917094952.GT23274@bunkus.org> <414AC3A2.8040308@free.fr> Message-ID: <414AC66D.9080706@free.fr> > Nop, only for the frames that have different angle. But it's true for a > solution that would use only Block2... So apparently the discussion is > now between a standard Track with TrackOverlay or a semi-Track with > TrackAssociate. One problem of this solution is that it makes the player quite more complex, compared to a single track with all frames marked with their angle. We will need a kind of video-mixer filter in DShow to decide which frames should be decoded for what codec (hopefully the CPU will not decode all angles during playback!) and put in the rendering window. I'd like to get the opinion of the DShow experts on that. Because no player is able to do that for the moment. From steve.lhomme at free.fr Fri Sep 17 13:23:28 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Fri, 17 Sep 2004 13:23:28 +0200 Subject: [Matroska-devel] Re: Multi-Angle In-Reply-To: References: <4149B394.6030601@free.fr> <20040917072115.GO23274@bunkus.org> Message-ID: <414AC930.7030508@free.fr> > Also, from the example above and using different tracks, the part C is > significant longer than its counter part, part B. > > [...A...][...B...][...D...] > [.....C.....] Here is another problem with current linear encoding systems: IBP frames. [A# IPBBBBBBB][B# IPBBBBIPBBBB][D# BBIPBBBBB] [C# IPBBBBBBBBBB] ^ PlayingB: This P frame is used in D# ^ PlayingC: This P frame is used in D# So when encoding, even the main track has to enforce scene changes at angle boundaries. Yes, multi-angle support is *evil* :) From moritz at bunkus.org Fri Sep 17 13:29:41 2004 From: moritz at bunkus.org (Moritz Bunkus) Date: Fri, 17 Sep 2004 13:29:41 +0200 Subject: [Matroska-devel] Multi-Angle In-Reply-To: <414AC3A2.8040308@free.fr> References: <4149B394.6030601@free.fr> <20040917072115.GO23274@bunkus.org> <414A9AD5.3090906@free.fr> <20040917082509.GQ23274@bunkus.org> <414AA8E7.3010700@free.fr> <20040917094952.GT23274@bunkus.org> <414AC3A2.8040308@free.fr> Message-ID: <20040917112940.GA23274@bunkus.org> Hey, > What you are also asking, is changes in the specs for : > - FlagEnabled ... No, I was just not thinking about that :) > Nop, only for the frames that have different angle. But it's true for > a solution that would use only Block2... Yes :( > So apparently the discussion is now between a standard Track with > TrackOverlay or a semi-Track with TrackAssociate. Then let's just use a normal track with TrackOverlay and introduce a new TrackSubID which can store the angle ID. Because as far as I understand TrackOverlay this is just the link to another track. The angle ID still has to be stored somewhere. 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 Sep 17 15:01:09 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Fri, 17 Sep 2004 15:01:09 +0200 Subject: [Matroska-devel] Multi-Angle In-Reply-To: <20040917112940.GA23274@bunkus.org> References: <4149B394.6030601@free.fr> <20040917072115.GO23274@bunkus.org> <414A9AD5.3090906@free.fr> <20040917082509.GQ23274@bunkus.org> <414AA8E7.3010700@free.fr> <20040917094952.GT23274@bunkus.org> <414AC3A2.8040308@free.fr> <20040917112940.GA23274@bunkus.org> Message-ID: <414AE015.1030702@free.fr> Moritz Bunkus a ?crit : >>So apparently the discussion is now between a standard Track with >>TrackOverlay or a semi-Track with TrackAssociate. > > > Then let's just use a normal track with TrackOverlay and introduce a new > TrackSubID which can store the angle ID. Because as far as I understand > TrackOverlay this is just the link to another track. The angle ID still > has to be stored somewhere. OK to add that one. If that's the final solution. But I'd like answers on the complexity on the player side when using overlay tracks. It's far from trivial compared to DVD cells that can replace each other in the same stream. Which is why I originally though of doing the same in Matroska (stored at the BlockGroup level). In that case you have to use the same codec for each angle and they are all parts of the same track. That would mean extending BlockGroup one way or another... If the only problem is overhead in the general case, it can be solved with having Block always for the main angle, and Block2 or whatever for other angles. But there is another problem : IPB frames have to be at the same position for all angles, which is not efficient... So I'm really mixed on all solutions. #1 is probably the way to go. But I'm concerned about players... From paul at msn.com Fri Sep 17 22:13:25 2004 From: paul at msn.com (Paul Bryson) Date: Fri, 17 Sep 2004 15:13:25 -0500 Subject: [Matroska-devel] Re: Mapping the tag leftovers References: <4149DFCE.60302@home.nl> Message-ID: "Age Bosma" wrote... > ID3: > - FILETYPE > Indicates, by defined codes, which type of audio this tag defines; > e.g. "MPEG Audio" (default), "MPEG 1/2 layer III", "Advanced Audio > Compression", etc. Should be apparent as part of the CodecID. > - SONGLEN > Length of the audio file in milliseconds. If the Matroska file contains only one stream, then you could just use the Duration element. > - PLAYLISTDELAY > Defines the numbers of milliseconds of silence that should be inserted > before this audio. I don't think there is a comparable item in Matroska > - SIZE > Contains the size of the audiofile in bytes, excluding the ID3v2 tag. If the Matroska file contains only one stream, then you could just use the Duration element and multiply it by the BPS tag. That should give you a relatively accurate size of the stream excluding container overhead. > - EVENTTIMING > Allows synchronisation with key events in the audio. I don't understand what this is for. Maybe it would be like Chapters? > - MPEGLOOKUP > MPEG location lookup table to increase performance and accuracy of > jumps within an audio file. That sounds like the Cues that are used to indicate seek points. > - SYNCEDTEMPO > Synchronised tempo codes for a more accurate description of the tempo > of a musical piece. Nothing that I know of. Although, you could make another track that just has data for tempo stuff. Make a Tempo Codec. > - EQUALIZATION2 > Subjective alignment frame to predefine an equalisation curve within > the audio file. Possibly the REPLAYGAIN info in the tags? > - REVERB > Subjective frame that allows you to adjust echoes of different kinds. Nothing I can think of. > - GENERALOBJECT > In this frame any type of file can be encapsulated. We have AttachedFile within Matroska. > - BUFFERSIZE > Buffer size recommended by the server using this frame (in case of > streaming). Nothing I can think of. > - AUDIOCRYPTO > Indicates if the actual audio stream is encrypted, and by whom. ContentEncryption within Matroska has all sorts of encryption options. > - LINKEDINFO > Used to link information from another ID3v2 tag. None. Although you can nest tags in Matroska which makes this info a bit moot. > - POSITIONSYNC > Delivers information to the listener of how far into the audio stream > he picked up. If/when Matroska is ever set up for streaming, you could tell how far in you are from the timecodes being sent. > - CRYPTOREG > To identify with which method a frame has been encrypted. ContentEncAlgo within ContentEncryption contains this info. > - SEEKFRAME > This frame indicates where other tags in a file/stream can be found. The SeekHead in Matroska contains info about where all other major elements are stored. > - AUDIOSEEKPOINT > Makes seeking in audio files with variable bit rates easier using an > audio seek point index. This is Cues again. > - VOLUMEADJ > Used to indicate how much the volume on each channel has to be > increased/decreased while the file is played. Not sure, possibly REPLAYGAIN again. > - EQUALIZATION > Subjective alignment frame to predefine an equalisation curve within > the audio file. Not sure, possibly REPLAYGAIN again. > - GROUPINGREG > Enables grouping of otherwise unrelated frames; e.g. when some frames > are to be signed. This is possible within the constraints of a Cluster in Matroska, but there isn't a way to specify a large arbitrary range for signing. > - SIGNATURE > Enables a group of frames, grouped with GROUPINGREG, to be signed. SignatureSlot witin Matroska > APE: > - FILE > File location. What is this for? > - INDEX > Indexes for quick access. Cues again. > - INTROPLAY > Characteristic part of piece for intro playing. You could mark an area as an intro by using Chapters, but there is nothing official. > RIFF: All of the RIFF tags were at one point in the Matroska tags list, but were slowly removed as they were recognized as a very niche market. If there is a need to store them, then people will undoubtedly make a custom tag, but adding them to the specs could definately fall into the category of bloat. (Somebody might someday use this tag) One that might actually get used is the ICRP tag, and if there were one, the resized tag. > - IDPI > Dots Per Inch. Stores dots per inch setting of the digitizer used to > produce the file, such as "300." > - ILGT > Lightness. Describes the changes in lightness settings on the > digitizer required to produce the file. Note that the format of this > information depends on hardware used. > - IPLT > Palette Setting. Specifies the number of colors requested when > digitizing an image, such as "256." > - ISHP > Sharpness. Identifies the changes in sharpness for the digitizer > required to produce the file (the format depends on the hardware > used). > - ICRP > Cropped. Describes whether an image has been cropped and, if so, how > it was cropped. For example, "lower right corner." > - IDIM > Dimensions. Specifies the size of the original subject of the file. > For example, "8.5 in h, 11 in w." > - ICNT* > Country Atamido From steve.lhomme at free.fr Sat Sep 18 19:31:13 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Sat, 18 Sep 2004 19:31:13 +0200 Subject: [Matroska-devel] Mapping the tag leftovers In-Reply-To: <4149DFCE.60302@home.nl> References: <4149DFCE.60302@home.nl> Message-ID: <414C70E1.1030809@free.fr> Age Bosma a ?crit : > ID3: > - FILETYPE > Indicates, by defined codes, which type of audio this tag defines; > e.g. "MPEG Audio" (default), "MPEG 1/2 layer III", "Advanced Audio > Compression", etc. In Segment > Tracks > TrackEntry > TrackType+CodecID+CodecName > - SONGLEN > Length of the audio file in milliseconds. This is the duration of the chapter the tag targets. Otherwise the Segment duration : Segment > Info > Duration > - PLAYLISTDELAY > Defines the numbers of milliseconds of silence that should be inserted > before this audio. In Segment > Tracks > TrackEntry > TrackOffset although it's probably not used yet > - SIZE > Contains the size of the audiofile in bytes, excluding the ID3v2 tag. The size of the Segment > - EVENTTIMING > Allows synchronisation with key events in the audio. No idea of what it is > - MPEGLOOKUP > MPEG location lookup table to increase performance and accuracy of > jumps within an audio file. Not really MPEG related but that's the MetaSeek and Cue entries : Segment > SeekHead Segment > Cues > - SYNCEDTEMPO > Synchronised tempo codes for a more accurate description of the tempo > of a musical piece. You should use chapters + BPM tag for that. > - EQUALIZATION2 > Subjective alignment frame to predefine an equalisation curve within > the audio file. We don't have that. > - REVERB > Subjective frame that allows you to adjust echoes of different kinds. Idem... > - GENERALOBJECT > In this frame any type of file can be encapsulated. You can put all kind of shit with new EBML elements... > - BUFFERSIZE > Buffer size recommended by the server using this frame (in case of > streaming). Somehow it's Segment > Tracks > TrackEntry > MaxCache > - AUDIOCRYPTO > Indicates if the actual audio stream is encrypted, and by whom. There is EBML encryption, but that's somehow different. There is no encryption only the coded data (so far). > - LINKEDINFO > Used to link information from another ID3v2 tag. We don't have that > - POSITIONSYNC > Delivers information to the listener of how far into the audio stream > he picked up. Dunno exactly what it means... > - CRYPTOREG > To identify with which method a frame has been encrypted. See AUDIOCRYPTO > - SEEKFRAME > This frame indicates where other tags in a file/stream can be found. That would be the Segment > MetaSeek > - AUDIOSEEKPOINT > Makes seeking in audio files with variable bit rates easier using an > audio seek point index. That would be Segment > Cues > - VOLUMEADJ > Used to indicate how much the volume on each channel has to be > increased/decreased while the file is played. That's somehow the ReplayGain, with a custom setting. Maybe we should add a GAIN tag that would be subjective (as opposed to ReplayGain). > - EQUALIZATION > Subjective alignment frame to predefine an equalisation curve within > the audio file. We don't have that > - GROUPINGREG > Enables grouping of otherwise unrelated frames; e.g. when some frames > are to be signed. Nop > - SIGNATURE > Enables a group of frames, grouped with GROUPINGREG, to be signed. Nop > APE: > - FILE > File location. Maybe that's Segment > Info > SegmentFilename > - INDEX > Indexes for quick access. MetaSeek and Cues > - INTROPLAY > Characteristic part of piece for intro playing. That could be a chapter with a special name, or a new "managed" chapter type to allow this special functionality. > RIFF: > - IDPI > Dots Per Inch. Stores dots per inch setting of the digitizer used to > produce the file, such as "300." No thanx. But we have a corresponding physical size for video frames : Segment > Tracks > TrackEntry > Video > DisplayUnit > - ILGT > Lightness. Describes the changes in lightness settings on the > digitizer required to produce the file. Note that the format of this > information depends on hardware used. No > - IPLT > Palette Setting. Specifies the number of colors requested when > digitizing an image, such as "256." Codec specific. > - ISHP > Sharpness. Identifies the changes in sharpness for the digitizer > required to produce the file (the format depends on the hardware > used). No > - ICRP > Cropped. Describes whether an image has been cropped and, if so, how > it was cropped. For example, "lower right corner." Segment > Tracks > TrackEntry > Video > PixelCropBottom + PixelCropTop + PixelCropLeft + PixelCropRight > - IDIM > Dimensions. Specifies the size of the original subject of the file. > For example, "8.5 in h, 11 in w." See IDPI > - ICNT* > Country Depends to what it applies. We have countries for tracks and chapters. From steve.lhomme at free.fr Sun Sep 19 11:18:44 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Sun, 19 Sep 2004 11:18:44 +0200 Subject: [Matroska-devel] Multi-Angle (summary) + Multi-resolution files Message-ID: <414D4EF4.8000002@free.fr> Hi, As we are in the middle of having nice DVD rips (the whole content mapping to Matroska chapters is done) we are facing 2 problems : - multi-angle - resolution changing on the fly I think these problems are somehow related. Especially because the solution for one will have to be compatible with the other. For multi-angle we have 2 solutions : - use one video track per angle, and marking this track with the number of the angle (new element required) - use one video track and put the angles for the same timecodes in the same BlockGroup The latter is closer to the DVD philosophy. Which means you only need one video stream output. But that video stream is dynamic and can be changed on the fly, especially the resolution change. But in the other hand I don't think the resolution of an angle can change in the middle... The thing is that DVD uses MPEG2 which can change the resolution any time, as long as it stays in the limits of the original resolution. But that wouldn't apply to Matroska which can have a lot of resolutions and cropping of original DVD content... It probably doesn't make sense to have different codec for different angles (well, I think it does but let's not consider this case). So both solutions are probably valid. But there is another problem. It's very common on the DVD to have the menu in 4:3 and the movie in 16:9. And I'm sure anyone would want to crop the content of the 16:9 part for better encoding efficiency. So the question is: should we use the same video track for the menu and the movie ? Or not... In the first case that means the codec has to support internal resolution change. So that would limit the possibility to only a few codec. In the second case that means we have different video streams and that the player has to select another video track when seeking to another part of the file (let alone the angle selection). I'm quite undecided on which way we should go. If we go the separate tracks way, we need managed chapters for playback. Otherwise the file will break older players. But in the other hand, a file should be playable without chapters... But doesn't seem possible in this case. For example the AngleNumber set in the TrackEntry would be used by the "chapter processor". And I think instead of a TrackSubID, it should be a TrackChapterPrivate, some private data that the "chapter processor" can use when seeking is used. So I think it should go in the chapters section, and not in the track section, especially since it depends on the "chapter codec". Something like: <- the managed edition <- track-related values 2541654 1 <- the angle number 5621 2 <- the angle number <- the actual chapters So, with this solution, that means that when seeking in the file: - you have no chapter, so you have to manually select the video/audio streams you want to play, knowing that some video tracks are overlays of other tracks. - you have managed chapters, and so the "chapter processor" (or chapter codec) has to handle the track changes, and also inform the player of resolution changes if needed... Opinions ? There is also the possibility of having a Segment for each DVD domain (3). And have a fix (final) resolution for each video track in each domain. I think that's the kind of limitation you have on DVDs. -- robUx4 on blog From paul at msn.com Mon Sep 20 10:23:09 2004 From: paul at msn.com (Paul Bryson) Date: Mon, 20 Sep 2004 03:23:09 -0500 Subject: [Matroska-devel] Re: Multi-Angle (summary) + Multi-resolution files References: <414D4EF4.8000002@free.fr> Message-ID: "Steve Lhomme" wrote... > It probably doesn't make sense to have different codec for different > angles (well, I think it does but let's not consider this case). So both > solutions are probably valid. But there is another problem. It's very > common on the DVD to have the menu in 4:3 and the movie in 16:9. And I'm > sure anyone would want to crop the content of the 16:9 part for better > encoding efficiency. So the question is: should we use the same video > track for the menu and the movie ? Or not... I would say not if they are two different resolutions. It is much simpler to use the existing tracks system. I don't know how DVD players do it, but consider this image for a moment: http://commo.de/videoswitching.png Here we have a file with three video streams. The first is the menu, say encoded at 600x400. The second is the movie itself, encoded at 700x240. The third is just there for future discussion purposes. As the first two video streams were encoded with different resolutions, and likely different encoding settings, the codecprivate data will be completely different, even though it is the same codec being used. Also, the output of the two will be dramatically different as they will be two different resolutions. I have heard that you cannot make changes to the resolution of the video renderer once the graph is built, so I am going on that assumption. When the graph is built, the Video Stream Switcher connects to all of the video streams from the Matroska Splitter. It then initializes a decoder for all of the streams using the appropriate init data. The decoders all connect to the Video Converter/Resizer with their RAW video outputs. The video resizer can see the maximum vertical and horizontal size required by all of the video streams and set the video renderer to that size. In this case, 700x400. On playback, the Video Stream Switcher only gives video packets to the decoder that should be being used. The decoding codec then passes the raw video on to the Video Converter/Resizer which pads the video with the amount required to make it fit on the Video Renderer. So while decoding the menu in the first stream, it would pad the video by 50 pixels of black on the left and the right sides. During this time, the other two decoders sit doing nothing. Once the movie is selected for playback, the Switcher start handing packets from the second stream to the second decoder. The Resizer then pads the top and the bottom with 80 pixels each. Benefits: 1. The video renderer never needs to change resolutions as the videos are always just padded. 2. Switching should be very fast because all of the decoders are initialized on start up and can start decoding video as soon as they are handed packets. 3. Only once video stream at a time getting decoded so CPU is not to high. Drawbacks: 1. Do Decoders like sitting there without being handed any packets? 2. You have to force the Video Converter/Resizer into place, and this is probably best left at the playback application level. 3. Different decoders output into different colorspaces so you would probably have to do some colorspace conversions inside of the Converter/Resizer. The Switcher would probably be built into the Splitter in real life. And the Converter/Resizer would probably be an application thing, not its own filter. It would probably also have to get info from the Switcher on which decoder to take data from. Atamido From steve.lhomme at free.fr Mon Sep 20 11:27:31 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Mon, 20 Sep 2004 11:27:31 +0200 Subject: [Matroska-devel] Re: Multi-Angle (summary) + Multi-resolution files In-Reply-To: References: <414D4EF4.8000002@free.fr> Message-ID: <414EA283.1000205@free.fr> Paul Bryson a ?crit : > "Steve Lhomme" wrote... > >>It probably doesn't make sense to have different codec for different >>angles (well, I think it does but let's not consider this case). So both >>solutions are probably valid. But there is another problem. It's very >>common on the DVD to have the menu in 4:3 and the movie in 16:9. And I'm >>sure anyone would want to crop the content of the 16:9 part for better >>encoding efficiency. So the question is: should we use the same video >>track for the menu and the movie ? Or not... > > > I would say not if they are two different resolutions. It is much simpler > to use the existing tracks system. I don't know how DVD players do it, but > consider this image for a moment: > > http://commo.de/videoswitching.png First of all, I'd like to point out that I understand that the multi-angle/multi-resolution feature won't be used much if it doesn't work with DirectShow, but it should also be usable in other conditions. The problem of video switching should really not be different than audio switching, so if Haali can support audio switching in his filter, it can probably handle video switching too... I think I'll try to play with Scenarist, maybe it allows to do multi-angle and multi-resolution DVDs. This way I'll know what are the limitations of DVDs. For example take the case of a movie that could include both 4:3 and 16:9 images. The way it's currently ripped is that you take the bigger resolution and you often have useless black lines (hopefully digital black that will compress well). I think on a DVD you can do it because the picture always have the same resolution (like 720x576) but then you can have a 16:9 frame or a 4:3. That's purely because of MPEG2. But we don't want to allow multi-resolution only for MPEG2... What you propose is to have 2 video tracks, the same way as angles, and use one or the other to use this feature. That could work if the "angle" (ie not the main video track) is the default one. When there is video you use that one, otherwise you use the track it's related to (value in TrackOverlay). But that would be more complicated when you have 2 "real" angles that can both have various resolutions. Well that could work. If the track that is marked as "angle #2" is a 'partial' track, ie it contains gap that are filled by another track. Let's see in detail... Virtual Track A : mixes Track 1 in 4:3 and partial Track 2 in 16:9 Virtual Track B : mixes Track 3 in 4:3 and partial Track 4 in 16:9 Track A is Angle #1 <- default angle to play Track B is Angle #2 _definition of the matroska tracks_ : 1 0 2 1 1 3 0 4 0 3 The problem is that Track 1 and Track 3 may contain gaps and are only playable when coupled with Track 2 and 4 respectively. This is were the multi-angle is different than the multi-resolution. For multi-angle, you can have different unrelated track entries. While for multi-resolution you need tracks that are *coupled* to for one. The TrackOverlay element is not enough to do that. We need another element to "merge" 2 or more tracks together in a bigger entity. Maybe that's what Mosu had in mind with TrackSubID. IMO for each track we could add an element like TrackGroup : the group of tracks that this track belongs to. It could also be the number of the angle like the DVD angle number (so we don't need the other element I was thinking about). The Tracks would now look like this : 1 1 1 <- angle 1 2 1 1 <- angle 1 3 0 2 <- angle 2 4 0 2 <- angle 2 1 <- the track number or the group number ? There are a few pbs to solve here : - there are 2 default tracks - the TrackOverlay is not really useful when you already have the list of tracks that form an angle. We might simply drop it, but it could also be interresting to know if a track of a group can be played alone. - a track that can be played alone could be used in many angle groups > The Switcher would probably be built into the Splitter in real life. And > the Converter/Resizer would probably be an application thing, not its own > filter. It would probably also have to get info from the Switcher on which > decoder to take data from. Hopefully Haali can tell if it's OK to do that or not. That looks a bit hacky to me. But I don't think we have another choice. From steve.lhomme at free.fr Mon Sep 20 16:06:17 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Mon, 20 Sep 2004 16:06:17 +0200 Subject: [Matroska-devel] Re: Multi-Angle (summary) + Multi-resolution files In-Reply-To: <414EA283.1000205@free.fr> References: <414D4EF4.8000002@free.fr> <414EA283.1000205@free.fr> Message-ID: <414EE3D9.4090300@free.fr> Steve Lhomme a ?crit : > Virtual Track A : mixes Track 1 in 4:3 and partial Track 2 in 16:9 > Virtual Track B : mixes Track 3 in 4:3 and partial Track 4 in 16:9 > > Track A is Angle #1 <- default angle to play > Track B is Angle #2 > > _definition of the matroska tracks_ : > > > > > 1 > 1 > 1 <- angle 1 > > > 2 > 1 > 1 <- angle 1 > > > > > 3 > 0 > 2 <- angle 2 > > > 4 > 0 > 2 <- angle 2 > 1 <- the track number or the group > number ? > > > > There are a few pbs to solve here : > - there are 2 default tracks > - the TrackOverlay is not really useful when you already have the list > of tracks that form an angle. We might simply drop it, but it could also > be interresting to know if a track of a group can be played alone. > - a track that can be played alone could be used in many angle groups I've been thinking a bit more about this second problem. Actually some tracks depends more on the other in the same group. And some can be mutualy exclusive in the same group. So we need to clarify this... The first thing is that a track should be usable with other alternative resolutions. That probably means belonging to different groups. Let's consider the following tracks : Track 1: --------------------------------------------------- Track 2: ------------ ----------- ------------- Track 3: ---------- ----- Track 4: ---------------- You can play: - Track 1 alone - Track 1 with Track 2 where applies - Track 1 with Track 3 where applies - Track 1 with Track 4 & 2 where applies - Track 1 with Track 4 & 3 where applies - Track 1 with Track 4 & 2 & 3 where applies - Track 2 with Track 3 where applies You can't play: - Track 2 alone - Track 3 alone - Track 4 alone - Track 2 with Track 4 - Track 3 with Track 4 So we need to allow all the possibilities and not allow the impossible ones. I guess that's a common problem to solve in computer science, but I don't know any good answer (yet). But when we'll have solve it, we won't have any angle & resolution problem anymore :) From steve.lhomme at free.fr Mon Sep 20 16:42:35 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Mon, 20 Sep 2004 16:42:35 +0200 Subject: [Matroska-devel] Re: Multi-Angle (summary) + Multi-resolution files In-Reply-To: <414EE3D9.4090300@free.fr> References: <414D4EF4.8000002@free.fr> <414EA283.1000205@free.fr> <414EE3D9.4090300@free.fr> Message-ID: <414EEC5B.5040109@free.fr> Steve Lhomme a ?crit : > Let's consider the following tracks : > Track 1: --------------------------------------------------- > Track 2: ------------ ----------- ------------- > Track 3: ---------- ----- > Track 4: ---------------- > > You can play: > - Track 1 alone > - Track 1 with Track 2 where applies > - Track 1 with Track 3 where applies > - Track 1 with Track 4 & 2 where applies > - Track 1 with Track 4 & 3 where applies > - Track 1 with Track 4 & 2 & 3 where applies > - Track 2 with Track 3 where applies Some of these groups means it's an "angle" and should have an angle number as on DVDs (like 1 & 2). Some of these other groups are forming one virtual track (like 2 & 3), in that case when you should have to select this virtual track and not the individual ones. > You can't play: > - Track 2 alone > - Track 3 alone > - Track 4 alone > - Track 2 with Track 4 > - Track 3 with Track 4 One possible solution would be to include pseudo tracks in the track entry. Normal tracks (without a CodecID, FlagLacing, MinCache, MaxCache, DefaultDuration, TrackTimecodeScale, TrackOffset, CodecPrivate, CodecName) and with the list of tracks that form this virtual track, optionally with an angle number. I don't think it's nice to have virtual tracks share the same EBML ID as TrackEntry, because a basic player would interpret them wrongly (well it won't be able to play them anyway) and, more important, it would break the mandotory elements rule... But let's consider it's OK for now. A virtual track could have all default values where needed and a "" (NULL) codec ID. Here is how the track definition would go : <-- (real) Track 1 --> 1 18665 video XVID 1 Main 4:3 track <-- (real) Track 2 --> 2 832 video RV9 0 <- can't be played alone 16:9 track <-- (real) Track 3 --> 3 68463132 video MPEG2 0 <- can't be played alone 16:9 other angle <-- (real) Track 4 --> 4 247476 video MJPEG 0 <- can't be played alone 4:3 other angle <-- (virtual) Track 5 --> 5 98765 video <- NULL codec ID 2 3 3 all in 16:9 <-- (angle) Track 6 --> 6 32156 video <- NULL codec ID 1 2 2 angle 2 as in the DVD This way you can merge any track (real/virtual) to form a new angle ID. From steve.lhomme at free.fr Wed Sep 22 10:03:15 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Wed, 22 Sep 2004 10:03:15 +0200 Subject: [Matroska-devel] Finally you can hide (more?) symbols with GCC Message-ID: <415131C3.9060405@free.fr> http://www.nedprod.com/programs/gccvisibility.html -- robUx4 on blog From moritz at bunkus.org Wed Sep 22 10:12:45 2004 From: moritz at bunkus.org (Moritz Bunkus) Date: Wed, 22 Sep 2004 10:12:45 +0200 Subject: [Matroska-devel] Finally you can hide (more?) symbols with GCC In-Reply-To: <415131C3.9060405@free.fr> References: <415131C3.9060405@free.fr> Message-ID: <20040922081245.GH13731@bunkus.org> Hi, > http://www.nedprod.com/programs/gccvisibility.html Windows compatibility For anyone who has worked on any sizeable portable application on both Windows and POSIX, you'll know the sense of frustration that non-Windows builds of GCC don't offer an equivalent to __declspec(dllexport) ie; the ability to mark your C/C++ interface as being that of the shared library. I say frustration because good DSO interface design is just as important for healthy coding as good class design, or correctly opaquing internal data structures. POSIX programmers generally just don't get this While the semantics can't be the same with Windows DLL's and ELF DSO's, almost all Windows-based code uses a macro to compile-time select whether dllimport or dllexport is being used. This mechanism can be easily reused with this patch so adding support to anything already able to be compiled as a Windows DLL is literally a five minute operation. ARGH! I seem to be one of those who don't get it. But it HUGELY overcomplicates things! 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 Sep 22 10:16:08 2004 From: moritz at bunkus.org (Moritz Bunkus) Date: Wed, 22 Sep 2004 10:16:08 +0200 Subject: [Matroska-devel] Finally you can hide (more?) symbols with GCC In-Reply-To: <20040922081245.GH13731@bunkus.org> References: <415131C3.9060405@free.fr> <20040922081245.GH13731@bunkus.org> Message-ID: <20040922081608.GI13731@bunkus.org> Hey, don't get me wrong. I'm not generally adversed to having to mark a function or variableas being externally visible, but having to distinguish between the two cases of building the lib itself and an app that uses that lib and having to define all kinds of EBML_DLL vs EBML_DLL_BUILD or whatever for each and every library scares me. 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 Sep 22 10:29:17 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Wed, 22 Sep 2004 10:29:17 +0200 Subject: [Matroska-devel] Finally you can hide (more?) symbols with GCC In-Reply-To: <20040922081608.GI13731@bunkus.org> References: <415131C3.9060405@free.fr> <20040922081245.GH13731@bunkus.org> <20040922081608.GI13731@bunkus.org> Message-ID: <415137DD.4080101@free.fr> I agree, the system would be better if by default the include files would set it at dllimport (or similar) and when you build the library it's using dllexport instead. Isn't that already the case ? Moritz Bunkus a ?crit : > Hey, > > don't get me wrong. I'm not generally adversed to having to mark a > function or variableas being externally visible, but having to > distinguish between the two cases of building the lib itself and an app > that uses that lib and having to define all kinds of EBML_DLL vs > EBML_DLL_BUILD or whatever for each and every library scares me. > > Mosu > -- robUx4 on blog From steve.lhomme at free.fr Wed Sep 22 10:30:31 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Wed, 22 Sep 2004 10:30:31 +0200 Subject: [Matroska-devel] Finally you can hide (more?) symbols with GCC In-Reply-To: <415131C3.9060405@free.fr> References: <415131C3.9060405@free.fr> Message-ID: <41513827.9040107@free.fr> Another good option to this system would be something like /opt:ref in MSVC : remove all code that is not referenced (and not public). I'm sure there are often dead code in large libraries... Steve Lhomme a ?crit : > http://www.nedprod.com/programs/gccvisibility.html > -- robUx4 on blog From steve.lhomme at free.fr Wed Sep 22 17:52:44 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Wed, 22 Sep 2004 17:52:44 +0200 Subject: [Matroska-devel] Anime Tags Message-ID: <41519FCC.8060408@free.fr> (from a PM in HA) > Hi Liisachan, > We are currently finishing the list of "official tags" supported in > Matroska. It includes a lot of tags for movies. Could you see, with > your anime friends, if anything is missing for anime movies ? (1) The most important item which might be missing for anime is Seiyu (Voice Actor, Voice Actoress), but one can use the ACTOR tag for Seiyu too. It might be a good idea to explicitly add about that to the ACTOR's definition. like "...including a voice actor/actress (Seiyu) for anime" Another thing related to anime that is less important but might be welcome would be : OPENING_THEME_SONG (aka OP) & ENDING_THEME_SONG (aka ED) (2) I'm not insisting this, but hypothetically speaking, there could be some tags for a subtitle track--not only for video and audio--, and if they were, they would be: TRANSLATED_BY EDITED_BY TIMED_BY TYPESET_BY (3) As for 'Technical Information' it might be a good idea to add one about the color space, especially RGB_RANGE to distinguish PC Scale and TV Scale. In the future, there might be a smart video renderer for PC that converts 16-235 to 0-255 only when the input RGB range is 16-235, and does not convert that if the input is 0-255 (already optimized for PC); so, it might be a good idea that MKV can tell the renderer about the RGB_RANGE used in video encoding. Today, ppl are often annoyed to see video rendering systems perform 16-235 to 0-255 conversion even tho the input is already 0-255 (PC Scale), i.e. needlessly converting doubly, resuting that bright colors will white out and dark colors will black out. That's it. Just some random thoughts -- robUx4 on blog From vegard_p at broadpark.no Tue Sep 21 23:38:55 2004 From: vegard_p at broadpark.no (Vegard Pettersen) Date: Tue, 21 Sep 2004 23:38:55 +0200 Subject: [Matroska-devel] Regarding "CD-in-Matroska" and Matroska's compliance with the Red Book standard (IEC 908) Message-ID: <200409212338.55930.vegard_p@broadpark.no> Attaching a simplistic table. Some feedback on this would be interesting, so that I can get a feel of which direction you want this to take - a complete 1:1 mapping of the Red Book cd-image, a subset of the metadata based on the Red Book, or just the bare essentials necessary for playing the audio-file. Also, I have tried to get in touch with goldenear at matroska.org regarding his mkaencoder aiming at being a frontend between EAC and mkvmerge, for the purpose of creating an .mka-file directly from EAC, but I haven't gotten a response in over a week. Goldenear, please respond so that we can work together on this part. Cheers, Vegard -------------- next part -------------- A non-text attachment was scrubbed... Name: cd_in_matroska.doc Type: application/msword Size: 9728 bytes Desc: not available URL: From vegard_p at broadpark.no Wed Sep 22 17:38:26 2004 From: vegard_p at broadpark.no (Vegard Pettersen) Date: Wed, 22 Sep 2004 17:38:26 +0200 Subject: [Matroska-devel] Please disregard previous mail "RE: CD-in-Matroska, " Message-ID: <200409221738.26516.vegard_p@broadpark.no> Hi, I messed up the .doc-file, so here's the plain text: --- Implementation of ?CD-in-Matroska? 1. The Lead-In may contain metadata 1.1. CD-TEXT -fLAC reportedly ditched implementing this for some reason. 1.2. ISRC (International Standard Recording Code) -The ISRC Code (International Standard Recording Code) is a unique international identifier for tracks on sound and music-video recordings. The ISRC is 12 character alpha-numeric code, which functions as a digital "fingerprint" for each track, unlike a Universal Product Code which is tied to the entire disc. In addition, the ISRC remains allocated to a track regardless of changes in ownership. It is an extremely powerful tool for royalty collection, administration, and anti-piracy safeguards in the digital arena. In other words, it may be useless. 2. Pregaps 2.1. Pregap1 of track 01 may contain a truly hidden2 track 2.2. Pregap of tracks 02-99 may contain false hidden3 tracks 3. Number of entries in TOC 3.1. The number of tracks for a CD is in the inclusive range of TRACK [01-99] 3.2. The number of indices for a TRACK is in the inclusive range of INDEX [00-99] -Incomplete implementation, only INDEX [00 ? 01] currently 4. A track may contain other datatypes than AUDIO -Uncertain, the degree to which ripping-tools implement ripping data-tracks is unknown, and the usefullness of ripping such tracks is also uncertain. 5. Other CD-Audio formats than CDDA, such as SACD, DVD-AUDIO, Dolby Surround 5.1 etc. --- Some feedback on this would be interesting, so that I can get a feel of which direction you want this to take - a complete 1:1 mapping of the Red Book cd-image, a subset of the metadata based on the Red Book, or just the bare essentials necessary for playing the audio-file. Cheers, Vegard From steve.lhomme at free.fr Thu Sep 23 11:42:04 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Thu, 23 Sep 2004 11:42:04 +0200 Subject: [Matroska-devel] Please disregard previous mail "RE: CD-in-Matroska, " In-Reply-To: <200409221738.26516.vegard_p@broadpark.no> References: <200409221738.26516.vegard_p@broadpark.no> Message-ID: <41529A6C.7070408@free.fr> Vegard Pettersen a ?crit : > Hi, Yo, > I messed up the .doc-file, so here's the plain text: Good, that's much easier to reply with an email :) > --- > Implementation of ?CD-in-Matroska? > > 1. The Lead-In may contain metadata > 1.1. CD-TEXT > -fLAC reportedly ditched implementing this for some reason. We think we do support CD-TEXT import and put these information in the tags. Even though due to the CD-TEXT limitations (all capital letters ? limited number of letters ?) it's usually better to use the tags found in a database. But for home-made CDs with CD-TEXT info, that can be useful (I have some). > 1.2. ISRC (International Standard Recording Code) > -The ISRC Code (International Standard Recording Code) is a unique > international identifier for tracks on sound and music-video recordings. The > ISRC is 12 character alpha-numeric code, which functions as a digital > "fingerprint" for each track, unlike a Universal Product Code which is tied > to the entire disc. In addition, the ISRC remains allocated to a track > regardless of changes in ownership. It is an extremely powerful tool for > royalty collection, administration, and anti-piracy safeguards in the digital > arena. > In other words, it may be useless. Nop. If you want a unique way to identify a track/mix that's with the ISRC. And that's supported in the tags. I *highly* suggest that this information be kept from the CD. > 2. Pregaps > 2.1. Pregap1 of track 01 may contain a truly hidden2 track > > 2.2. Pregap of tracks 02-99 may contain false hidden3 tracks Supported with chapters. The index is a sub-chapter of the main chapter. So we get the hidden track, which is not hidden anymore... (unless the player is configured to start at the sub-chapter with INDEX01 name/ID. > 3. Number of entries in TOC > 3.1. The number of tracks for a CD is in the inclusive range of TRACK [01-99] > > 3.2. The number of indices for a TRACK is in the inclusive range of INDEX > [00-99] > -Incomplete implementation, only INDEX [00 ? 01] currently Yes, we should support everything. > 4. A track may contain other datatypes than AUDIO > -Uncertain, the degree to which ripping-tools implement ripping data-tracks is > unknown, and the usefullness of ripping such tracks is also uncertain. It could be included as attachements. It could be optional and off by default. It's nice when the content is a video, although a proper Matroska file with the video would be nicer... > 5. Other CD-Audio formats than CDDA, such as SACD, DVD-AUDIO, Dolby Surround > 5.1 etc. > --- Computers don't support these formats very well yet. But there shouldn't be any problem supporting the audio and meta-information inside. From Liisachan at faireal.net Thu Sep 23 11:56:54 2004 From: Liisachan at faireal.net (Liisachan) Date: Thu, 23 Sep 2004 18:56:54 +0900 Subject: [Matroska-devel] Anime Tags In-Reply-To: <41519FCC.8060408@free.fr> References: <41519FCC.8060408@free.fr> Message-ID: <20040923185654yW%TCY@faireal.net> Hi, did you see my 2nd PM? I assume these 3 would be most important in anime creators: EKONTE_BY (=Storyboard by) ENSHUTSU_BY (=Animation Director) SAKUGA_KANTOKU (=Animation Supervisor) Liisachan Steve Lhomme wrote: > (from a PM in HA) > > > Hi Liisachan, > > > We are currently finishing the list of "official tags" supported in > > Matroska. It includes a lot of tags for movies. Could you see, with > > your anime friends, if anything is missing for anime movies ? > > > > (1) The most important item which might be missing for anime is Seiyu > (Voice Actor, Voice Actoress), but one can use the ACTOR tag for Seiyu > too. It might be a good idea to explicitly add about that to the ACTOR's > definition. like "...including a voice actor/actress (Seiyu) for anime" > > Another thing related to anime that is less important but might be > welcome would be : > OPENING_THEME_SONG (aka OP) > & > ENDING_THEME_SONG (aka ED) > > (2) I'm not insisting this, but hypothetically speaking, there could be > some tags for a subtitle track--not only for video and audio--, and if > they were, they would be: > TRANSLATED_BY > EDITED_BY > TIMED_BY > TYPESET_BY > > (3) As for 'Technical Information' it might be a good idea to add one > about the color space, especially RGB_RANGE to distinguish PC Scale and > TV Scale. > In the future, there might be a smart video renderer for PC that > converts 16-235 to 0-255 only when the input RGB range is 16-235, and > does not convert that if the input is 0-255 (already optimized for PC); > so, it might be a good idea that MKV can tell the renderer about the > RGB_RANGE used in video encoding. > Today, ppl are often annoyed to see video rendering systems perform > 16-235 to 0-255 conversion even tho the input is already 0-255 (PC > Scale), i.e. needlessly converting doubly, resuting that bright colors > will white out and dark colors will black out. > > That's it. Just some random thoughts > > -- > robUx4 on blog > > _______________________________________________ > 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 Thu Sep 23 15:03:17 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Thu, 23 Sep 2004 15:03:17 +0200 Subject: [Fwd: Re: [Matroska-devel] Anime Tags] Message-ID: <4152C995.6050204@free.fr> Sent it to the wrong person (me) ! -- robUx4 on blog -------------- next part -------------- An embedded message was scrubbed... From: Steve Lhomme Subject: Re: [Matroska-devel] Anime Tags Date: Wed, 22 Sep 2004 17:54:19 +0200 Size: 2589 URL: From steve.lhomme at free.fr Fri Sep 24 18:26:55 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Fri, 24 Sep 2004 18:26:55 +0200 Subject: [Matroska-devel] Re: Compiling on solaris In-Reply-To: <20040924074745.GN13731@bunkus.org> References: <20040924074745.GN13731@bunkus.org> Message-ID: <41544ACF.4000208@free.fr> Moritz Bunkus a ?crit : > Hey, > > I've committed a fix to libebml's SVN repo which fixes compilation on > Solaris: > http://svn.matroska.org/svn/matroska/trunk/libebml/ebml/c/libebml_t.h > > Steve, could you please test if this still compiles cleanly on MSVC? > I've changed the #if... thingies a lot, but I can only test on Solaris, > Linux and mingw at the moment. It works with MSVC7 :) -- robUx4 on blog From vegard_p at broadpark.no Fri Sep 24 14:10:38 2004 From: vegard_p at broadpark.no (Vegard Pettersen) Date: Fri, 24 Sep 2004 14:10:38 +0200 Subject: [Matroska-devel] Questions / suggestions regarding tags for "CD-in-Matroska" Message-ID: <200409241410.38959.vegard_p@broadpark.no> I've had a closer look at the tags-specification, and it appears that there are no formal tags for attaching CD-covers, booklets, lyrics etc., only the generic attachment-type. Wouldn't it be an idea to decide upon a standard set of tags for this information? Example: CD-cover (front cover implied): IMAGE_COVER (can be used for movies as well) CD-back: IMAGE_COVER_BACK (also good for movies) CD-booklet: This might be several pages or none. As such, it might be better suited for a chapter definition, for instance SCANNED_PAGES, with tags such as PAGE_1, PAGE_2, etc. CD-lyrics: This should be plain text, and could alse be used for transcripts of movies, audio of interviews, theatrical performances etc. It might fit in per-track as well as per-chapter. Any suggestions for a tag-name besides LYRICS? On another note, returning to the indices for a CD, on some CDs they are named. How should this naming be implemented? From vegard_p at broadpark.no Thu Sep 23 18:42:14 2004 From: vegard_p at broadpark.no (Vegard Pettersen) Date: Thu, 23 Sep 2004 18:42:14 +0200 Subject: [Matroska-devel] Re: Matroska-devel Digest, Vol 17, Issue 22 In-Reply-To: <20040923100005.C1D29440068@p15097576.pureserver.info> References: <20040923100005.C1D29440068@p15097576.pureserver.info> Message-ID: <200409231842.14249.vegard_p@broadpark.no> On Thursday 23 September 2004 12:00, matroska-devel-request at lists.matroska.org wrote: > > > 2. Pregaps > > 2.1. Pregap1 of track 01 may contain a truly hidden2 track > > > > 2.2. Pregap of tracks 02-99 may contain false hidden3 tracks > > Supported with chapters. The index is a sub-chapter of the main chapter. > So we get the hidden track, which is not hidden anymore... (unless the > player is configured to start at the sub-chapter with INDEX01 name/ID. > > > 3. Number of entries in TOC > > 3.1. The number of tracks for ?a CD is in the inclusive range of TRACK > > [01-99] > > > > 3.2. The number of indices for ?a TRACK is in the inclusive range of > > INDEX [00-99] > > -Incomplete implementation, only INDEX [00 ??" 01] currently > > Yes, we should support everything. > Sure, I've had a look at the code in mkvtoolnix/src/common/chapter_parser_cue.cpp, and I just added a vector for the INDEX [02-99] entries. With this cue-file: --- PERFORMER "Faithless" TITLE "We Come 1 (CD Single)" FILE "CDImage.wav" WAVE TRACK 01 AUDIO TITLE "We Come 1" PERFORMER "Faithless" INDEX 00 00:00:00 INDEX 01 00:01:01 TRACK 02 AUDIO TITLE "We Come 1 (Rollo & Sister Bliss Remix)" PERFORMER "Faithless" INDEX 00 05:44:27 INDEX 01 05:47:37 INDEX 02 05:47:38 INDEX 03 05:49:37 INDEX 04 05:53:37 INDEX 05 05:57:37 --- I got the output: --- ... | + ChapterString: Faithless_We Come 1 (Rollo & Sister Bliss Remix)_02 ... | + ChapterAtom ... | + ChapterTimeStart: 00:05:44.360000000 ... | + ChapterString: INDEX 00 ... | + ChapterTimeStart: 00:05:47.493333333 ... | + ChapterTimeStart: 00:05:47.506666666 ... | + ChapterString: INDEX 02 ... | + ChapterTimeStart: 00:05:49.493333333 ... | + ChapterString: INDEX 03 ... | + ChapterTimeStart: 00:05:53.493333333 ... | + ChapterString: INDEX 04 ... | + ChapterTimeStart: 00:05:57.493333333 ... | + ChapterString: INDEX 05 ... --- Is this ok? I haven't tested it much yet, but it's rather simple. Also, regarding coding standards, specifically indentation in the code, replacing tabs with two spaces, adding spaces for nested parantheses to show grouping, lining code up for legibility etc. Are there any formal standards I should use before submitting the code? In addition, how strict should preconditions be considered: should the calling function carry the responsibility for testing preconditions, or should the called? Cheers, Vegard From moritz at bunkus.org Sat Sep 25 10:48:06 2004 From: moritz at bunkus.org (Moritz Bunkus) Date: Sat, 25 Sep 2004 10:48:06 +0200 Subject: [Matroska-devel] Re: Matroska-devel Digest, Vol 17, Issue 22 In-Reply-To: <200409231842.14249.vegard_p@broadpark.no> References: <20040923100005.C1D29440068@p15097576.pureserver.info> <200409231842.14249.vegard_p@broadpark.no> Message-ID: <20040925084806.GY13731@bunkus.org> Hey, > I got the output: > --- > ... > | + ChapterString: Faithless_We Come 1 (Rollo & Sister Bliss Remix)_02 > ... > | + ChapterAtom > ... > | + ChapterTimeStart: 00:05:44.360000000 > ... > | + ChapterString: INDEX 00 > ... > | + ChapterTimeStart: 00:05:47.493333333 > ... > | + ChapterTimeStart: 00:05:47.506666666 > ... > | + ChapterString: INDEX 02 > ... > | + ChapterTimeStart: 00:05:49.493333333 > ... > | + ChapterString: INDEX 03 > ... > | + ChapterTimeStart: 00:05:53.493333333 > ... > | + ChapterString: INDEX 04 > ... > | + ChapterTimeStart: 00:05:57.493333333 > ... > | + ChapterString: INDEX 05 > ... > --- > > Is this ok? I haven't tested it much yet, but it's rather simple. Looks fine, yes. > Also, regarding coding standards, specifically indentation in the code, > replacing tabs with two spaces, adding spaces for nested parantheses to show > grouping, lining code up for legibility etc. Two spaces indentation, no tabs, parenthesis on the same line: if (...) { ... } else { ... } Not more than one "instruction" per line, not something like: if (...) return 0; but if (...) return 0; Lines not longer than 79 chars, indent function arguments at the opening parenthesis... This is basically emacs's indentation with (c-set-offset 'case-label '+) (setq default-tab-width 2) (setq tabs-always-indent nil) (setq-default indent-tabs-mode nil) ... (c-basic-offset 2) (standard-indent 2) ... > Are there any formal standards I should use before submitting the > code? Not really, I'll look over the code and reformat if it doesn't match my preferences. Don't hesitate to re-indent code e.g. if you put a "if () {...}' or a loop around it. My aim is readability, not 'least possible changes in the SVN repo'. > In addition, how strict should preconditions be considered: > should the calling function carry the responsibility for testing > preconditions, or should the called? Hmm, I don't really have anything formal on that, but I think I'm relying on the calling function to hand over useful stuff. Well, often enough the called function does some checks, but most of the time they don't (e.g. check for NULL pointers). 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 Sep 26 10:16:09 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Sun, 26 Sep 2004 10:16:09 +0200 Subject: [Matroska-devel] Re: Matroska-devel Digest, Vol 17, Issue 22 In-Reply-To: <20040925084806.GY13731@bunkus.org> References: <20040923100005.C1D29440068@p15097576.pureserver.info> <200409231842.14249.vegard_p@broadpark.no> <20040925084806.GY13731@bunkus.org> Message-ID: <41567AC9.405@free.fr> Moritz Bunkus a ?crit : > Lines not longer than 79 chars, indent function arguments at the opening > parenthesis... Mh... I found it *really* hard to read your code because of that. Some /lines/ of code would be split in 3 or 4 lines. The code just looks like a big pack of instructions. But that's your code, so you are free to do whatever you want with it. From steve.lhomme at free.fr Sun Sep 26 10:41:04 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Sun, 26 Sep 2004 10:41:04 +0200 Subject: [Matroska-devel] Questions / suggestions regarding tags for "CD-in-Matroska" In-Reply-To: <200409241410.38959.vegard_p@broadpark.no> References: <200409241410.38959.vegard_p@broadpark.no> Message-ID: <415680A0.304@free.fr> Vegard Pettersen a ?crit : > I've had a closer look at the tags-specification, and it appears that there > are no formal tags for attaching CD-covers, booklets, lyrics etc., only the > generic attachment-type. > > Wouldn't it be an idea to decide upon a standard set of tags for this > information? Definitely ! I've been thinking about that too. I think the current convention is to give the filename a special name. That also makes sense. But that means you can "detach" 2 such files in the same directory... > Example: > CD-cover (front cover implied): > IMAGE_COVER (can be used for movies as well) > > CD-back: > IMAGE_COVER_BACK (also good for movies) > > CD-booklet: > This might be several pages or none. As such, it might be better suited for a > chapter definition, for instance SCANNED_PAGES, with tags such as PAGE_1, > PAGE_2, etc. Yes, these all look like valid possibilities. IMO we should all merge them into 1 tag that could be SLEEVE_TYPE. That would be a number like : * -1 front cover * -2 back cover * -3 inside CD (on transparent CDs) * 0 page 0 of the booklet (if different than the front cover) * 1 page 1 of the booklet * . etc > CD-lyrics: > This should be plain text, and could alse be used for transcripts of movies, > audio of interviews, theatrical performances etc. > It might fit in per-track as well as per-chapter. Any suggestions for a > tag-name besides LYRICS? Well, for the lyrics or transcripts it makes more sense to have it muxed with the stream. But I understand it takes more time to have it authored this way. In the other hand, I don't think it needs a special treatment. Or maybe for lyrics, that could be displayed a special way in a nice audio player... But then that would mean the format of the lyrics should be in a given format (plain text ? HTML ? XML ? other ?). So I'm not sure we need to define that now. But if someone comes with a good solution, that could be nice. > On another note, returning to the indices for a CD, on some CDs they are > named. How should this naming be implemented? You can look at such an example here : http://www.matroska.org/technical/specs/tagging/example-audio.html#diff_cds One CD is named "Housemusic" and the other is named "Electronicbody". From steve.lhomme at free.fr Sun Sep 26 11:00:07 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Sun, 26 Sep 2004 11:00:07 +0200 Subject: [Matroska-devel] Questions / suggestions regarding tags for "CD-in-Matroska" In-Reply-To: <415680A0.304@free.fr> References: <200409241410.38959.vegard_p@broadpark.no> <415680A0.304@free.fr> Message-ID: <41568517.6030100@free.fr> Steve Lhomme a ?crit : >> CD-back: IMAGE_COVER_BACK (also good for movies) >> >> CD-booklet: This might be several pages or none. As such, it might be >> better suited for a chapter definition, for instance SCANNED_PAGES, >> with tags such as PAGE_1, PAGE_2, etc. > > > Yes, these all look like valid possibilities. IMO we should all merge > them into 1 tag that could be SLEEVE_TYPE. That would be a number like : > > * -1 front cover > * -2 back cover > * -3 inside CD (on transparent CDs) > * 0 page 0 of the booklet (if different than the front cover) > * 1 page 1 of the booklet > * . etc We also have to think about CD sets that can have a booklet per CD. In this case, we have to target the corresponding files in the part that describes the CD... And this is currently *impossible* with the system we have. Because that would mean using a few attachment UIDs in the same target as a Chapter UID. And in that case we have never specified if it means a OR or AND between the targetted elements. When using multiple chapter targets, it means a OR. But then if we add attachment to the pack, it means an AND. Maybe we could target only the attachments (with a OR, like for chapters) and also use a TargetTypeValue of 40 (PART/SESSION) for these attachments... But then we don't know to what "chapter" part it relates to... We could assume that it's always a OR between UIDs of the same type (chapter, attachment) and an AND between UIDs of different types. If you need a OR, you just don't use them in the same target 'pack'. Everyone agrees ? (if so I'll add a remark on that in the specs) From paul at msn.com Sun Sep 26 11:02:44 2004 From: paul at msn.com (Paul Bryson) Date: Sun, 26 Sep 2004 04:02:44 -0500 Subject: [Matroska-devel] Re: Questions / suggestions regarding tagsfor "CD-in-Matroska" References: <200409241410.38959.vegard_p@broadpark.no> <415680A0.304@free.fr> Message-ID: "Steve Lhomme" wrote... > Well, for the lyrics or transcripts it makes more sense to have it muxed with the stream. If its just the lyrics without any timing information, then you could just attach it. There is no way to store it in the stream without timing info. (unless you put it all in one Block, and that would just be silly.) Atamido From dgp85 at users.sourceforge.net Sun Sep 26 19:35:19 2004 From: dgp85 at users.sourceforge.net (Diego 'Flameeyes' =?ISO-8859-1?Q?Petten=F2?=) Date: Sun, 26 Sep 2004 19:35:19 +0200 Subject: [Matroska-devel] libebml documentation Message-ID: <10871895.velfQh5VnQ@flameeyes.is-a-geek.org> Hi, I wanted to use the ebml format for two opensource projects I'm working on, but I can't find a tutorial or a simple documentation about it. The api documentation is quite incomplete, and sais nothing about the way the classes should be used. Can someone point me to a more complete documentation or a tutorial? Thanks in advance, -- Diego "Flameeyes" Petten? dgp85 at users.sourceforge.net - http://flameeyes.web.ctonet.it/ From vegard_p at broadpark.no Sat Sep 25 18:54:30 2004 From: vegard_p at broadpark.no (Vegard Pettersen) Date: Sat, 25 Sep 2004 18:54:30 +0200 Subject: [Matroska-devel] "CD-in-Matroska", some questions regarding the implementation of indices Message-ID: <200409251854.30807.vegard_p@broadpark.no> First of all, is it legal for a track to have only INDEX 00, according to the Red Book? Example: --- TRACK 12 TITLE "FOO" PERFORMER "BAR" INDEX 00 00:12:34 TRACK 13 TITLE "BAR" PERFORMER "FOO" INDEX 01 00:22:34 --- Next up, the way I read what little I have currently found about the CD-TEXT standard ( http://www.cdrfaq.org/faq03.html#S3-28 ), I am slightly suspicious that the ITTS-standard (Interactive Text Transmission System) allows for data (character-encoded text and JPEG's) to be stored on a per-indice basis as well as per-cd and per-track. Can anyone help clarify that, and offer some viewpoints on how this should be approached? Cheers, Vegard From steve.lhomme at free.fr Mon Sep 27 13:33:34 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Mon, 27 Sep 2004 13:33:34 +0200 Subject: [Matroska-devel] "CD-in-Matroska", some questions regarding the implementation of indices In-Reply-To: <200409251854.30807.vegard_p@broadpark.no> References: <200409251854.30807.vegard_p@broadpark.no> Message-ID: <4157FA8E.7010906@free.fr> Vegard Pettersen a ?crit : > First of all, is it legal for a track to have only INDEX 00, according to the > Red Book? > Example: > --- > TRACK 12 > TITLE "FOO" > PERFORMER "BAR" > INDEX 00 00:12:34 > TRACK 13 > TITLE "BAR" > PERFORMER "FOO" > INDEX 01 00:22:34 > --- Only someone with access to the red-book could tell :) (maybe alexnoe ?) But I think it's impossible since the CD player has to seek on INDEX 01 (I saw that yesterday in my CD player, the CD-Text info was displayed between INDEX 00 and INDEX 01, but when you seek you get to INDEX 01) > Next up, the way I read what little I have currently found about the CD-TEXT > standard ( http://www.cdrfaq.org/faq03.html#S3-28 ), I am slightly suspicious > that the ITTS-standard (Interactive Text Transmission System) allows for data > (character-encoded text and JPEG's) to be stored on a per-indice basis as > well as per-cd and per-track. That's probably an addition over what is possible with CD-TEXT. > Can anyone help clarify that, and offer some viewpoints on how this should be > approached? If you want text and images, you just put them as attachment and add them in the tag. From christian at matroska.org Mon Sep 27 21:24:45 2004 From: christian at matroska.org (ChristianHJW) Date: Mon, 27 Sep 2004 21:24:45 +0200 Subject: [Matroska-devel] Re: Brand new DiretcX audio plugin In-Reply-To: <1096237408.17511.178.camel@finet> References: <1096237408.17511.178.camel@finet> Message-ID: <415868FD.2@matroska.org> Franti?ek Dvor(?k wrote: > because I have problems with current DirectX audio output plugin, I > wrote the new one. Main problem in the current version was looping after > end of stream and some cracking. > Cheers, Frantisek Frantisek, could this plugin be used as a basis for the Windows port of Gstreamer ? We have it ported since some time now, but we dont have any audio or video sinks yet. Would you allow that your code is being used for that ? Under what license did you release your code ? Christian matroska project admin http://www.matroska.org From steve.lhomme at free.fr Mon Sep 27 21:53:02 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Mon, 27 Sep 2004 21:53:02 +0200 Subject: [Matroska-devel] libebml documentation In-Reply-To: <10871895.velfQh5VnQ@flameeyes.is-a-geek.org> References: <10871895.velfQh5VnQ@flameeyes.is-a-geek.org> Message-ID: <41586F9E.9000709@free.fr> Diego 'Flameeyes' Petten? a ?crit : > Hi, > I wanted to use the ebml format for two opensource projects I'm working on, > but I can't find a tutorial or a simple documentation about it. > The api documentation is quite incomplete, and sais nothing about the way > the classes should be used. > > Can someone point me to a more complete documentation or a tutorial? You can have a look at libmatroska in the /test/mux/ directory. The example are not complete but show how you should use the EBML classes and create your own classes over them. If you need help you can ask here or on IRC : - irc://irc.corecodec.com/#matroska - irc://irc.freenode.net/#matroska-dev From dgp85 at users.sourceforge.net Tue Sep 28 18:25:06 2004 From: dgp85 at users.sourceforge.net (=?ISO-8859-1?Q?Diego_=27Flameeyes=27_Petten=F2?=) Date: Tue, 28 Sep 2004 18:25:06 +0200 Subject: [Matroska-devel] Errors on tests' compiling [Was: Re: libebml documentation] In-Reply-To: <41586F9E.9000709@free.fr> References: <10871895.velfQh5VnQ@flameeyes.is-a-geek.org> <41586F9E.9000709@free.fr> Message-ID: Steve Lhomme wrote: > You can have a look at libmatroska in the /test/mux/ directory. The > example are not complete but show how you should use the EBML classes > and create your own classes over them. I tried reading them and I was trying to compile them to check exactly what they do, but I'm having trouble in this: building them using the normal gcc test6.cpp -o test6, I have errors on my gentoo's gcc 3.4: test6.cpp:125:63: converting to execution character set: Invalid or incomplete multibyte or wide character test6.cpp:323:53: converting to execution character set: Invalid or incomplete multibyte or wide character test6.cpp:352:49: converting to execution character set: Invalid or incomplete multibyte or wide character test6.cpp:355:48: converting to execution character set: Invalid or incomplete multibyte or wide character Instead trying to compile libmatroska under macos using the gentoo for osx support, I have a lot of errors stating /usr/include/ebml/IOCallback.h:89: error: template with C linkage /usr/include/ebml/IOCallback.h:93: error: template with C linkage this for quite all the files. Trying to build it using Xcode 1.1 was also unsuccessful. This is quite a strange fact actually, because libebml compiled just fine using gentoo for macosx (so building it the linux way I think). TIA -- Diego 'Flameeyes' Petten? From moritz at bunkus.org Tue Sep 28 19:01:03 2004 From: moritz at bunkus.org (Moritz Bunkus) Date: Tue, 28 Sep 2004 19:01:03 +0200 Subject: [Matroska-devel] Errors on tests' compiling [Was: Re: libebml documentation] In-Reply-To: References: <10871895.velfQh5VnQ@flameeyes.is-a-geek.org> <41586F9E.9000709@free.fr> Message-ID: <20040928170102.GS27364@bunkus.org> Hey, > test6.cpp:352:49: converting to execution character set: Invalid or > incomplete multibyte or wide character Just uncomment the lines in which those characters occur. Yes, tests is broken in this regard. > Instead trying to compile libmatroska under macos using the gentoo for > osx support, I have a lot of errors stating > > /usr/include/ebml/IOCallback.h:89: error: template with C linkage > /usr/include/ebml/IOCallback.h:93: error: template with C linkage Hmm no idea about those, sorry. 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 Sep 28 21:09:39 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Tue, 28 Sep 2004 21:09:39 +0200 Subject: [Matroska-devel] Errors on tests' compiling [Was: Re: libebml documentation] In-Reply-To: References: <10871895.velfQh5VnQ@flameeyes.is-a-geek.org> <41586F9E.9000709@free.fr> Message-ID: <4159B6F3.6090903@free.fr> Diego 'Flameeyes' Petten? a ?crit : > Steve Lhomme wrote: > >> You can have a look at libmatroska in the /test/mux/ directory. The >> example are not complete but show how you should use the EBML classes >> and create your own classes over them. > > I tried reading them and I was trying to compile them to check exactly > what they do, but I'm having trouble in this: building them using the > normal gcc test6.cpp -o test6, I have errors on my gentoo's gcc 3.4: > > test6.cpp:125:63: converting to execution character set: Invalid or > incomplete multibyte or wide character > test6.cpp:323:53: converting to execution character set: Invalid or > incomplete multibyte or wide character > test6.cpp:352:49: converting to execution character set: Invalid or > incomplete multibyte or wide character > test6.cpp:355:48: converting to execution character set: Invalid or > incomplete multibyte or wide character It's because the lines include some wide chars. But AFAIK OS X doesn't support wide chars well in C++ (no std::wstring class IIRC). Maybe the chars you get are not correct because you got the files in binary. Just replace the weird characters by other weird ones. It's just to test unicode encoding. In Gentoo it's weird because it should work on any Linux. > Instead trying to compile libmatroska under macos using the gentoo for > osx support, I have a lot of errors stating > > /usr/include/ebml/IOCallback.h:89: error: template with C linkage > /usr/include/ebml/IOCallback.h:93: error: template with C linkage Really weird. It's supposed to compile on OS X. What version of the libraries did you use ? > this for quite all the files. > Trying to build it using Xcode 1.1 was also unsuccessful. I compiled it with XCode a long time ago and it worked. That even helped me find a few bugs. > This is quite a strange fact actually, because libebml compiled just > fine using gentoo for macosx (so building it the linux way I think). -- robUx4 on blog From valtri at users.sourceforge.net Tue Sep 28 21:54:30 2004 From: valtri at users.sourceforge.net (=?iso-8859-2?Q?Franti=B9ek_Dvo=F8=E1k?=) Date: Tue, 28 Sep 2004 21:54:30 +0200 Subject: [Matroska-devel] Re: Brand new DiretcX audio plugin In-Reply-To: <415868FD.2@matroska.org> References: <1096237408.17511.178.camel@finet> <415868FD.2@matroska.org> Message-ID: <1096401270.1946.32.camel@finet> Hi Christian, V Po, 27. 09. 2004 v 21:24, ChristianHJW p??e: > Frantiek Dvor(?k wrote: > > because I have problems with current DirectX audio output plugin, I > > wrote the new one. Main problem in the current version was looping after > > end of stream and some cracking. > > Cheers, Frantisek > > Frantisek, > > could this plugin be used as a basis for the Windows port of Gstreamer ? These are good news. Yes, of course. :-) And I want make some tests yet before commit into xine-lib. > We have it ported since some time now, but we dont have any audio or > video sinks yet. Would you allow that your code is being used for that ? > Under what license did you release your code ? > If you're happy with xine's GPL, there is no problem. But you need LGPL, right? :-) I agree with this license too. Cheers, Frantisek From valtri at users.sourceforge.net Tue Sep 28 23:37:18 2004 From: valtri at users.sourceforge.net (=?iso-8859-2?Q?Franti=B9ek_Dvo=F8=E1k?=) Date: Tue, 28 Sep 2004 23:37:18 +0200 Subject: [Matroska-devel] Re: Brand new DiretcX audio plugin In-Reply-To: <1096401270.1946.32.camel@finet> References: <1096237408.17511.178.camel@finet> <415868FD.2@matroska.org> <1096401270.1946.32.camel@finet> Message-ID: <1096406912.1946.60.camel@finet> Hi, again, V ?t, 28. 09. 2004 v 21:54, Franti?ek Dvo??k p??e: > > Frantisek, > > > > could this plugin be used as a basis for the Windows port of Gstreamer ? > > These are good news. Yes, of course. :-) > And I forgot to mention: I don't know plugin API in Gstreamer. But you probably know possibilities of re-using of the plugin. And using DirectSound under WIN32 isn't only one choice. In later future I'll probably study API for wave out (this way is already used in mplayer, just what I've seen from source file names). Cheers, Frantisek From jcsston at jory.info Tue Sep 28 23:44:04 2004 From: jcsston at jory.info (Jory Stone) Date: Tue, 28 Sep 2004 16:44:04 -0500 Subject: [Matroska-devel] Re: Brand new DiretcX audio plugin References: <1096237408.17511.178.camel@finet> <415868FD.2@matroska.org><1096401270.1946.32.camel@finet> <1096406912.1946.60.camel@finet> Message-ID: <005101c4a5a5$8198acf0$6b00a8c0@jcsston> Just to note, waveOut is the older sound API and has some limitations. The largest (to me) is under Win9x, any app using waveOut blocks out all other apps or is blocked out by any app using DirectSound. With DirectSound all the apps share the sound card and play together. With WinXP I haven't noticed this and I suspect that it emulates the waveOut API to DirectSound (the drivers are listed under Legacy Audio Drivers). Jory ----- Original Message ----- From: "Franti?ek Dvo??k" To: Cc: "Discussion about the current and future development of Matroska" ; "gstreamer-devel" ; "Matthew Grooms" Sent: Tuesday, September 28, 2004 4:37 PM Subject: [Matroska-devel] Re: Brand new DiretcX audio plugin Hi, again, V ?t, 28. 09. 2004 v 21:54, Franti?ek Dvo??k p??e: > > Frantisek, > > > > could this plugin be used as a basis for the Windows port of Gstreamer ? > > These are good news. Yes, of course. :-) > And I forgot to mention: I don't know plugin API in Gstreamer. But you probably know possibilities of re-using of the plugin. And using DirectSound under WIN32 isn't only one choice. In later future I'll probably study API for wave out (this way is already used in mplayer, just what I've seen from source file names). Cheers, Frantisek _______________________________________________ Matroska-devel mailing list Matroska-devel at lists.matroska.org http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel From vegard_p at broadpark.no Sun Sep 26 19:57:24 2004 From: vegard_p at broadpark.no (Vegard Pettersen) Date: Sun, 26 Sep 2004 19:57:24 +0200 Subject: [Matroska-devel] Comments on the "Audio Tags Example, Simple CD layout" at matroska.org Message-ID: <200409261957.24903.vegard_p@broadpark.no> I'm working my way through the chapters and tag examples at matroska.org, and I have a few viewpoints that may or may not be overly critical. I couldn't find a mailing list for the website, so I hope using this list is okay. * INTRODUCTION * Referring to http://www.matroska.org/technical/specs/tagging/example-audio.html#intro, I find this example confusing and possibly wrong. The statement: "Tracks 01 to 04 are linked together and are actually making just one "virtual" track to the listener.", I find unclear and inaccurate. Just because there are no pregaps between some tracks does not change the fact that each track can be sought to. The meaning of "a virtual track" appears to me to only make sense if you ignore the concept of indices in a track. When a track has indices above INDEX 01, not all CD audio players can seek to such a seekpoint, very few people bother doing that, and I don't know of _any_ CD-ROM players that seek to such seekpoints. Therefore, making a track with indices over INDEX 01 would have the effect of making "one virtual track for the listener", whilst a number of tracks with pregaps of zero seconds is still a number of individual, seekable tracks. Furthermore, I do not find the reason for grouping the four first tracks into a "00:00 - 12:28 : Baby Wants To Bleep/Rock" based on the CD-information available at amazon.com ( http://www.amazon.com/exec/obidos/tg/detail/-/B000042VQM/qid=1096218210/sr=8-3/ref=sr_8_xs_ap_i3_xgl15/104-7128524-5572701?v=glance&s=music&n=507846#product-details ), freedb.org ( http://www.freedb.org/freedb_search_fmt.php?cat=newage&id=5b0a6e09 ), or at discogs.com ( http://www.discogs.com/release/8788 ). I see this grouping as an artificial construct based on length of pregaps, and it is confusing. * ONE FILE WITH ALL TRACKS * Referring to http://www.matroska.org/technical/specs/tagging/example-audio.html#whole, this is also slightly confusing. "In this case the file contains one continuous audio track of 44:28. Chapters are used to virtually split the content in many parts, ie the CD tracks. A basic ripping application would rip the CD tracks as follows" What exactly is the combined meaning of "one continous audio track" and "the CD tracks"? Is the cd one continous track, like the early release of "Mike Oldfield_Amarok" ( http://www.freedb.org/freedb_search_fmt.php?cat=misc&id=020e0601 ), or is the meaning that there is one track with many indices which for some reason is split into tracks? Seeing that "mkvextract cuesheet foo.mka" and mkvmerge now both handle indices over INDEX 01 (mosu, can I commit this to the svn for mkvtoolnix or should I just send the modified files to you in mail?), maybe this example should be modified. I think it might be less vague if there was a CUE-file included in the example as well. * ONE FILE PER "MEANINGFULL" TRACK * Referring to: http://www.matroska.org/technical/specs/tagging/example-audio.html#meaningful, the meaning of "meaningfull" again escapes me... with a cuesheet, it is possible to burn a wav having pregaps less than two seconds, so grouping the "no pause between"-tracks into is completely artificial. Sure, I understand the argument that "you can do it if you want to", I just don't see the point. Is it indended to make gapless playback easier or something? If so, I don't see why that should be the responsibility of a container format, that's in my view a player / demuxer's responsibility. From steve.lhomme at free.fr Thu Sep 30 15:08:01 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Thu, 30 Sep 2004 15:08:01 +0200 Subject: [Matroska-devel] Comments on the "Audio Tags Example, Simple CD layout" at matroska.org In-Reply-To: <200409261957.24903.vegard_p@broadpark.no> References: <200409261957.24903.vegard_p@broadpark.no> Message-ID: <415C0531.4000808@free.fr> Hi, Vegard Pettersen a ?crit : > I'm working my way through the chapters and tag examples at matroska.org, and > I have a few viewpoints that may or may not be overly critical. > I couldn't find a mailing list for the website, so I hope using this list is > okay. Yes, it's find. Every "technical" discussion can be discussed here. > * INTRODUCTION * > Referring to > http://www.matroska.org/technical/specs/tagging/example-audio.html#intro, I > find this example confusing and possibly wrong. > The statement: "Tracks 01 to 04 are linked together and are actually making > just one "virtual" track to the listener.", I find unclear and inaccurate. In that case, I know *for sure* that those tracks are meant to be one. I know the guys who created this track and heard it in the studio before it was released. It used to be one track (called Baby Wants To Bleep) but became 4 because of contract issues with Virgin. > Just because there are no pregaps between some tracks does not change the fact > that each track can be sought to. The meaning of "a virtual track" appears to > me to only make sense if you ignore the concept of indices in a track. When a > track has indices above INDEX 01, not all CD audio players can seek to such a > seekpoint, very few people bother doing that, and I don't know of _any_ > CD-ROM players that seek to such seekpoints. Therefore, making a track with > indices over INDEX 01 would have the effect of making "one virtual track for > the listener", whilst a number of tracks with pregaps of zero seconds is > still a number of individual, seekable tracks. See above :) IIRC the contract with Virgin stated that they had to release an album. But they didn't have one. So they cut this track instead and in the end it's called a mini-album and everyone is happy. Remember that record companies are evil and they will not you use nice technologies (like CD index) if it's not what the contract says... > Furthermore, I do not find the reason for grouping the four first tracks into > a "00:00 - 12:28 : Baby Wants To Bleep/Rock" based on the CD-information > available at amazon.com > ( http://www.amazon.com/exec/obidos/tg/detail/-/B000042VQM/qid=1096218210/sr=8-3/ref=sr_8_xs_ap_i3_xgl15/104-7128524-5572701?v=glance&s=music&n=507846#product-details ), > freedb.org > ( http://www.freedb.org/freedb_search_fmt.php?cat=newage&id=5b0a6e09 ), > or at discogs.com ( http://www.discogs.com/release/8788 ). > > I see this grouping as an artificial construct based on length of pregaps, and > it is confusing. Every system should be flexible enough to care with human flows ;) > * ONE FILE WITH ALL TRACKS * > Referring to > http://www.matroska.org/technical/specs/tagging/example-audio.html#whole, > this is also slightly confusing. > "In this case the file contains one continuous audio track of 44:28. Chapters > are used to virtually split the content in many parts, ie the CD tracks. A > basic ripping application would rip the CD tracks as follows" > What exactly is the combined meaning of "one continous audio track" and "the > CD tracks"? Is the cd one continous track, like the early release of "Mike > Oldfield_Amarok" ( http://www.freedb.org/freedb_search_fmt.php?cat=misc&id=020e0601 ), > or is the meaning that there is one track with many indices which for some > reason is split into tracks? Yes. All the audio content is glued together and put in one Matroska track. > Seeing that "mkvextract cuesheet foo.mka" and mkvmerge now both handle indices > over INDEX 01 (mosu, can I commit this to the svn for mkvtoolnix or should I > just send the modified files to you in mail?), maybe this example should be > modified. I think it might be less vague if there was a CUE-file included in > the example as well. I could add the CUE file, if I know how to create one ;) > * ONE FILE PER "MEANINGFULL" TRACK * > Referring to: > http://www.matroska.org/technical/specs/tagging/example-audio.html#meaningful, > the meaning of "meaningfull" again escapes me... with a cuesheet, it is > possible to burn a wav having pregaps less than two seconds, so grouping the > "no pause between"-tracks into is completely artificial. > Sure, I understand the argument that "you can do it if you want to", I just > don't see the point. Is it indended to make gapless playback easier or > something? If so, I don't see why that should be the responsibility of a > container format, that's in my view a player / demuxer's responsibility. See above for the reasons. Now, it's a container problem, because tags are a container thing... I'd definitely have that track I heard in the studio as 1 track instead of 4. For example it sucks in a player when you have random on, and you only get a 4th of a track for stupid reasons (only iTunes allow to do that for the moment). But the nice thing in Matroska is that you don't lose the information that this track is actually cut in 4 pieces on the CD.