From mohankumarhs at tataelxsi.co.in Thu Feb 10 07:38:17 2011 From: mohankumarhs at tataelxsi.co.in (Mohan Kumar H S) Date: Thu, 10 Feb 2011 12:08:17 +0530 Subject: [Matroska-general] Request for MKV Formats Details. Message-ID: <4D5387D9.1020109@tataelxsi.co.in> An HTML attachment was scrubbed... URL: From slhomme at matroska.org Mon Feb 21 21:04:19 2011 From: slhomme at matroska.org (Steve Lhomme) Date: Mon, 21 Feb 2011 21:04:19 +0100 Subject: [Matroska-general] Matroska v3 Message-ID: Hi everyone, Today we are starting a new iteration of Matroska called v3. For now it's just adding the elements used for 3D. There might be new elements used later. The specifications reflect these changes: http://www.matroska.org/technical/specs/index.html They are now generated using an XML "source" file. That file can be used to generate documentation and also code. libmatroska2 will soon use it to generate the C classes it's using. So there is never a mismatch between the code and the specs. http://matroska.svn.sourceforge.net/viewvc/matroska/trunk/foundation_src/spectool/specdata.xml?view=markup http://matroska.svn.sourceforge.net/viewvc/matroska/trunk/foundation_src/spectool/ -- Steve Lhomme Matroska association Chairman From ashwood at msn.com Thu Feb 24 08:17:39 2011 From: ashwood at msn.com (Joseph Ashwood) Date: Wed, 23 Feb 2011 23:17:39 -0800 Subject: [Matroska-general] [Matroska-devel] Matroska v3 In-Reply-To: References: Message-ID: I'd like to see a few metadata changes for V3. Not having read the spec recently, and admittedly not having as much time to dedicate to this as I would like, some of this may already be included. I know of one company with an interest in adding some metadata to various elements. This metadata would be safely ignorable, so any parser that doesn't understand the metadata can and should ignore it with no detrimental effects, except the small increase in file size. As such I'd really like to see some clarity in the spec that this is acceptable, along with clarity that such additional metadata MUST be safely ignorable. How widespread the use of this will be is debatable, but the hope is that files from [sorry not giving out even that data yet, at least not publicly] will be widespread. The same company will be offering contributions on the tag discussion that was happening recently, but will happily work within whatever restrictions are finalized. The only problem I see with the proposals so far is that they don't cover that many videos and audios have different edits. Just off the top of my head, I know that Caligula had at least 6 different edits, ranging from a generally acceptable rating suggesting adult supervision, to one edit that is illegal throughout most of the world, not including the pre-release edits. Add in releases that are language specific, the various "child-safe" editting services, and the others. It is actually quite easy for a particular movie to have over a dozen versions, and having worked on music significantly, there are often several final versions; one for radio, one for CD, one for online sales, one for radio-edit CD, one for etc. Having some way for the file to identify itself among these different versions would be useful. The big problem is the naming, unlike software versions, very often the versions are simultaneous, and I'm open to suggestions. Joe From slhomme at matroska.org Sat Feb 26 11:16:46 2011 From: slhomme at matroska.org (Steve Lhomme) Date: Sat, 26 Feb 2011 11:16:46 +0100 Subject: [Matroska-general] [Matroska-devel] Matroska v3 In-Reply-To: References: Message-ID: On Thu, Feb 24, 2011 at 8:17 AM, Joseph Ashwood wrote: > I'd like to see a few metadata changes for V3. Not having read the spec > recently, and admittedly not having as much time to dedicate to this as I > would like, some of this may already be included. > > I know of one company with an interest in adding some metadata to various > elements. This metadata would be safely ignorable, so any parser that > doesn't understand the metadata can and should ignore it with no detrimental > effects, except the small increase in file size. As such I'd really like to > see some clarity in the spec that this is acceptable, along with clarity > that such additional metadata MUST be safely ignorable. How widespread the > use of this will be is debatable, but the hope is that files from [sorry not > giving out even that data yet, at least not publicly] will be widespread. By ignorable, you mean not visible if not supported ? The best way to do that would rather be to use proprietary EBML elements. Any Matroska parser will skip such data if they don't know what they do. For example DivX has some proprietary extensions and it doesn't create any problems. Tags on the other hand can be shown, since they have a user friendly name. > The same company will be offering contributions on the tag discussion that > was happening recently, but will happily work within whatever restrictions > are finalized. The only problem I see with the proposals so far is that they > don't cover that many videos and audios have different edits. Just off the > top of my head, I know that Caligula had at least 6 different edits, ranging > from a generally acceptable rating suggesting adult supervision, to one edit > that is illegal throughout most of the world, not including the pre-release There is a EditionUID target exacly for that. Although the specs should be clearer on how mixing targets should work. > edits. Add in releases that are language specific, the various "child-safe" > editting services, and the others. It is actually quite easy for a > particular movie to have over a dozen versions, and having worked on music > significantly, there are often several final versions; one for radio, one > for CD, one for online sales, one for radio-edit CD, one for etc. Having > some way for the file to identify itself among these different versions > would be useful. Do you mean for the user or for archiving ? I know for music there is ISRC that exactly defines exactly one recording that can't be mismatched with any other. I don't know if there is something like that for movies. > The big problem is the naming, unlike software versions, very often the > versions are simultaneous, and I'm open to suggestions. This is more for human reading. Tags can be edited and users might change it to the way they prefer. I'm not sure one set of naming rules could ever apply. Artists will definitely use outside of any boundaries for fun. -- Steve Lhomme Matroska association Chairman