From sjimeno at ya.com Tue Feb 1 12:57:38 2011 From: sjimeno at ya.com (Santiago Jimeno) Date: Tue, 1 Feb 2011 12:57:38 +0100 Subject: [Matroska-devel] Hi, question about the MKV tags In-Reply-To: References: Message-ID: <8B9241CBAC8B4AF69D411FBC37353EDB@JSASUS> Steve said "The reason for this is that some apps may support attachments and not tags. The cover art system is much simpler to support than tags (when done properly)." Indeed it's easier of supporting. But the practical problem is presented when it's necessary to support at the same time the edition with Tags and Pictures modifications and besides in two different blocks. This complicates the code a lot. The ideal thing would be Tags and Picture were in oneself block and with preference at the file end. If the target of the file is streaming for network reading, picture should be before Cluster. But if the target is to make a file that can be modified later on (for example to organize a collection in a PC) the picture location should be, as before I said, at the file end next to Tags. Anyway if Tags and Picture are edited (mainly if one adds information) will necessarily go at the end. On the other hand it's more difficult of working when picture is in the same block with fonts and subtitles. In another message Steve said: "In fact right now nobody cares about tags." But not only the external programs. I take enough time working in tags and my impression is that the programs that make Matroska files neither take care of it. Tags is not generally added when a file is converted to Matroska, even when the original file already includes them. I think that one acts in such way that once made the Matroska file is expected that nobody modifies it. When adding or editing Tags and Pictures is necessary to modify also SeekHead. For this is necessary (it should be mandatory) this block has a VOID space later. Well, this is the situation of some files tested: - Haali adds only 14 bytes of VOID space. If one adds Tags at the file end we would need a minimum of 17 bytes for Seek entry. Conclusion: one cannot add SeekHead entry. Less still if one modifies Pictures in Attachments. - Direct Show adds 130 bytes of VOID space. A little fair but enough. - MkvMerge doesn't add VOID space in versions 4.0.0 and 4.1.1. Fortunately in the remaining versions Mosu is very generous and he adds a VOID space of 4000 bytes. We are of luck that most of files Matroska are made with mkvmerge. - An example of complicated design for Tags is the sample provided for pictures in cover_art.mkv file. Tags and Attachments are before Cluster. If one modifies them then they will go at the file end. But the VOID space after SeekHead is 0 bytes. Finally I have been able to modify the file deleting 4 bytes of CRC that had each entry to be able to include the new entries for Tags and Attachments. I think it would be necessary to setting some clearer norms for impeling the inclusion of Tags in the files and to favor its edition. But as the specifications leave a wide field of freedom at least some recommendations should be made. - The VOID space after SeekHead should be if not mandatory at least very recommendable - Tags should be at the file end with preference. - In pictures case, if the target of the file is not streaming, the Attachments block should be after Cluster. Mkvmerge uses two SeekHead blocks, one for master elements at beginning of file and another before the cluster blocks. This good design approach could also be applied to Attachments. One Attachments could be before Cluster for fonts and subtitles and other one after Cluster for Pictures and maybe also for Lyrics. - But the ideal thing would be to be able to include Pictures like a SimpleTag inside Tags. For not modifying the design of the Matroska container substantially it could be optional according to the file target (streaming or other) to put the Pictures in Attachments or in Tags but not in both at the same time. So I propose to declare official a SimpleTag for Pictures with the following outline: TagName: PICTURE OR COVERTART TagBinary: Identical structure of Attachments Picture including in the binary code FILEDESC, FILENAME, FILEMIMETYPE and FILEDATA, that is to say, the ID3 APIC structure. In the event of being necessary the compatibility for UTF8 the whole binary code can be converted to Base64 (thus vorbis does it). But this fills 25% more space Regards. Santiago PS. If somebody has tested my program FileList for Tags http://personales.ya.com/sjimeno/Download/MATROSKAFileList.zip I would thank the comments or suggestions . ----- Original Message ----- From: "Steve Lhomme" To: "Discussion about the current and future development of Matroska" Sent: Monday, January 31, 2011 1:32 PM Subject: Re: [Matroska-devel] Hi, question about the MKV tags > The reason for this is that some apps may support attachments and not > tags. The cover art system is much simpler to support than tags (when > done properly). > > And yes, when editing tags/cover art you have to check if it can fit > in the original place, if not you have to : > - void the old version > - write the new version at the end > - update the segment size > - update the position of the tags/attachment in the SeekHead section > > That's more or less what you'd have to do in any container anyway, > except some may not have a Void element and would always put these > data at the end (not nice for network reading). > > On Mon, Jan 31, 2011 at 1:23 PM, Santiago Jimeno wrote: >> Hi all >> >> In the email I sent speaking about CodecSpecs a while ago, I said that I >> would write other about Tags. >> I think the current message provides me this opportunity. >> >> Reading Tags is relatively easy (in spite of Nested Tags) in Visual .NET >> because of the easiness that .NET provides to work with XML Documents. >> >> Editing or re-writing Tags is complicated. But I have it done in my >> program >> FileList. >> But it's not still completed because of the difficulties that I have >> found >> with Cover Art. >> >> Cover Art are in a Attachments block (separated of Tags block) that is a >> bag >> for everything that also includes fonts, text and subtitles and located >> in >> any place of the file. The result in this case is that, in spite of its >> initial advantages, it doesn't exist a program for editing Tags and I >> think >> it's for the extreme difficulty that implies to almost modify the whole >> file. I think that to have two different blocks for Tags and Pictures is >> not >> a good design. In Flac files a similar thing happens. >> >> I am working in two possible solutions. >> 1.- Declaring VOID the block part that contains Pictures and writing them >> at >> the file end (next to Tags) in a second Attachments block. >> 2.- Including them in a new SimpleTag COVERART inside TAGS, >> maintaining its structure. The binary data could be written as >> >> or as in Base64 so that was compatible with UTF8 (Vorbis >> Comments do it this way). >> >> If somebody wants to test FileList program, one can download it in >> http://personales.ya.com/sjimeno/Download/MATROSKAFileList.zip >> To show edit form --> double click in List Item. >> This program is designed for audio files MKA, although it also reads >> video >> files MKV. Apply Tags edition is disabled at the moment due to the >> problem >> above mentioned. >> >> Regards. Santiago Jimeno >> >> _______________________________________________ >> Matroska-devel mailing list >> Matroska-devel at lists.matroska.org >> http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel >> Read Matroska-Devel on GMane: >> http://dir.gmane.org/gmane.comp.multimedia.matroska.devel >> > > > > -- > Steve Lhomme > Matroska association Chairman > _______________________________________________ > Matroska-devel mailing list > Matroska-devel at lists.matroska.org > http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel > Read Matroska-Devel on GMane: > http://dir.gmane.org/gmane.comp.multimedia.matroska.devel > From boris.juraga at gmail.com Tue Feb 1 20:33:00 2011 From: boris.juraga at gmail.com (Boris Juraga) Date: Tue, 1 Feb 2011 20:33:00 +0100 Subject: [Matroska-devel] About Matroska Tags Message-ID: I am starting to create profiles for tagging that make sense, like for tv shows and movies, and i like to use some standard here. I am unable to find a good sample for use of nested tags in case it is needed. I think it is nececary to place good examples on the matroska site including actors. I think this is the way you intended to use the ACTOR, CHARACTER and other alike: 70 TITLE The Simpsons ORIGINAL_MEDIA_TYPE TV CONTENT_TYPE Show ACTOR Real Person #1 Name CHARACTER The Character#1 Name ACTOR Real Person #2 Name CHARACTER The Character#2 Name .... other tags for season and episode are removed for this example If that is the way--ok, if i am wrong please provide a good sample for multiple actor/character combos and i will take that and reuse it for multiple directors, producers and other multiples From slhomme at matroska.org Tue Feb 1 21:27:54 2011 From: slhomme at matroska.org (Steve Lhomme) Date: Tue, 1 Feb 2011 21:27:54 +0100 Subject: [Matroska-devel] About Matroska Tags In-Reply-To: References: Message-ID: Yes this is the correct way to add actors in the tags. On Tue, Feb 1, 2011 at 8:33 PM, Boris Juraga wrote: > I am starting to create profiles for tagging that make sense, like for > tv shows and movies, and i like to use some standard here. I am unable > to find a good sample for use of nested tags in case it is needed. I > think it is nececary to place good examples on the matroska site > including actors. I think this is the way you intended to use the > ACTOR, CHARACTER and other alike: > > > > ? ? > ? ? > ? ? ? ? > ? ? ? ? ? ?70 > ? ? ? ? > ? ? ? ? > ? ? ? ? ? ?TITLE > ? ? ? ? ? ?The Simpsons > ? ? ? ? > ? ? ? ? > ? ? ? ? ? ?ORIGINAL_MEDIA_TYPE > ? ? ? ? ? ?TV > ? ? ? ? > ? ? ? ? > ? ? ? ? ? ?CONTENT_TYPE > ? ? ? ? ? ?Show > ? ? ? ? > > ? ? ? ? > ? ? ? ? ? ?ACTOR > ? ? ? ? ? ?Real Person #1 Name > ? ? ? ? ? ? > ? ? ? ? ? ? ? CHARACTER > ? ? ? ? ? ? ? The Character#1 Name > ? ? ? ? ? ? > ? ? ? ? > ? ? ? ? > ? ? ? ? ? ?ACTOR > ? ? ? ? ? ?Real Person #2 Name > ? ? ? ? ? ? > ? ? ? ? ? ? ? CHARACTER > ? ? ? ? ? ? ? The Character#2 Name > ? ? ? ? ? ? > ? ? ? ? > ? ? > .... other tags for season and episode are removed for this example > > > If that is the way--ok, if i am wrong please provide a good sample for > multiple actor/character combos and i will take that and reuse it for > multiple directors, producers and other multiples > _______________________________________________ > Matroska-devel mailing list > Matroska-devel at lists.matroska.org > http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel > Read Matroska-Devel on GMane: http://dir.gmane.org/gmane.comp.multimedia.matroska.devel > -- Steve Lhomme Matroska association Chairman From slhomme at matroska.org Tue Feb 1 21:50:12 2011 From: slhomme at matroska.org (Steve Lhomme) Date: Tue, 1 Feb 2011 21:50:12 +0100 Subject: [Matroska-devel] Hi, question about the MKV tags In-Reply-To: <8B9241CBAC8B4AF69D411FBC37353EDB@JSASUS> References: <8B9241CBAC8B4AF69D411FBC37353EDB@JSASUS> Message-ID: On Tue, Feb 1, 2011 at 12:57 PM, Santiago Jimeno wrote: > Steve said "The reason for this is that some apps may support attachments > and not tags. The cover art system is much simpler to support than tags > (when done properly)." > > Indeed it's easier of supporting. But the practical problem is presented > when it's necessary to support at the same time the edition with Tags and > Pictures modifications and besides in two different blocks. This complicates > the code a lot. The ideal thing would be Tags and Picture were in oneself > block and with preference at the file end. Then you could argue chapters should be in tags. So there is just one system to deal with everything. But these features are made modular on purpose. We are not going to change that now. > If the target of the file is streaming for network reading, picture should > be before Cluster. But if the target is to make a file that can be modified > later on (for example to organize a collection in a PC) the picture location > should be, as before I said, at the file end next to Tags. In fact I think cover art is very unlikely to be edited further by the user (unless it was not originally present). Tags that are open-ended (which unlimited possible extensions) can always be enhanced with more data. Cover Art rarely differs. All the rationale behind the choice of positions can be found here : http://www.matroska.org/technical/order/index.html > Anyway if Tags and Picture are edited (mainly if one adds information) will > necessarily go at the end. On the other hand it's more difficult of working > when picture is in the same block with fonts and subtitles. Subtitles are in the stream, not as attachments. It is true for fonts. > In another message Steve said: ?"In fact right now nobody cares about tags." > But not only the external programs. I take enough time working in tags and > my impression is that the programs that make Matroska files neither take > care of it. Tags is not generally added when a file is converted to > Matroska, even when the original file already includes them. I think that > one acts in such way that once made the Matroska file is expected that > nobody modifies it. I don't think it's reasonable to add tags and assuming noone will change them. Even the content I buy on music stores, I customize the tags to meet my archiving system. > When adding or editing Tags and Pictures is necessary to modify also > SeekHead. For this is necessary (it should be mandatory) this block has a > VOID space later. Well, this is the situation of some files tested: mkclean leaves room for tags indeed (not attachments). mkvtoolnix also produces a large void at the beggining of the file for such changes. I'm not sure it should be a rule to impose, but more a guideline. > - Haali adds only 14 bytes of VOID space. If one adds Tags at the file end > we would need a minimum of 17 bytes for Seek entry. Conclusion: ?one cannot > add SeekHead entry. Less still if one modifies Pictures in Attachments. > > - Direct Show adds 130 bytes of VOID space. A little fair but enough. > > - MkvMerge doesn't add VOID space in versions 4.0.0 and 4.1.1. Fortunately > in the remaining versions Mosu is very generous and he adds a VOID space of > 4000 bytes. We are of luck that most of files Matroska are made with > mkvmerge. > > - An example of complicated design for Tags is the sample provided for > pictures in cover_art.mkv file. Tags and Attachments are before Cluster. If > one modifies them then they will go at the file end. But the VOID space > after SeekHead is 0 bytes. Finally I have been able to modify the file > deleting 4 bytes of CRC that had each entry to be able to include the new > entries for Tags and Attachments. Look at the section "Optimum layout after editing tags" in the Order Guideline. When editing tags/attachments and they don't fit in their original place, they should be moved at the end. That leaves plenty of room at the front to add new elements in the SeekHead. > I think it would be necessary to setting some clearer norms for impeling the > inclusion of Tags in the files and to favor its edition. But as the > specifications leave a wide field of freedom at least some recommendations > should be made. > > - The VOID space after SeekHead should be if not mandatory at least very > recommendable Correct. I will try to add that somewhere. The ordering guideline may be the most appropriate place for now, as it discusses each "level-1" elements placement in general. > - Tags should be at the file end with preference. In fact the preference is at the front. Although in most cases where it will have been edited, it will end up at the end. > - In pictures case, if the target of the file is not streaming, the > Attachments block should be after Cluster. Mkvmerge uses two SeekHead > blocks, one for master elements at beginning of file and another before the > cluster blocks. This good design approach could also be applied to > Attachments. One Attachments could be before Cluster for fonts and subtitles > and other one after Cluster for Pictures and maybe also for Lyrics. In fact the 2 SeekHead approach was dropped recently. Noone could remember why it was done in the first place. And it's more complex to support on the player side. > - But the ideal thing would be to be able to include Pictures like a > SimpleTag inside Tags. For not modifying the design of the Matroska > container substantially it could be optional according to the file target > (streaming or other) to put the Pictures in Attachments or in Tags but not > in both at the same time. Adding binary in tags should be avoided, because it's not implied how to interpret it. For pictures it could be JPEG, PNG, SVG, etc. Attachments have a MIME type for that, tags don't. You can notice in the specs the very few formats with binary values are those with only one possible format. > So I propose to declare official a SimpleTag for Pictures with the following > outline: > > TagName: PICTURE OR COVERTART > > TagBinary: ?Identical structure of Attachments Picture including in the > binary code FILEDESC, FILENAME, FILEMIMETYPE and FILEDATA, that is to say, > the ID3 APIC structure. In the event of being necessary the compatibility > for UTF8 the whole binary code can be converted to Base64 (thus vorbis does > it). But this fills 25% more space So you want to add attachments inside a TagBinary element ? That deserves some reflection... I still don't know what's wrong with attachments as they are now. > Regards. Santiago > > PS. If somebody has tested my program FileList for Tags > http://personales.ya.com/sjimeno/Download/MATROSKAFileList.zip > I would thank the comments or suggestions Error 2755 in the MSI installer (Vista 64 bits in english) > ----- Original Message ----- From: "Steve Lhomme" > To: "Discussion about the current and future development of Matroska" > > Sent: Monday, January 31, 2011 1:32 PM > Subject: Re: [Matroska-devel] Hi, question about the MKV tags > > >> The reason for this is that some apps may support attachments and not >> tags. The cover art system is much simpler to support than tags (when >> done properly). >> >> And yes, when editing tags/cover art you have to check if it can fit >> in the original place, if not you have to : >> - void the old version >> - write the new version at the end >> - update the segment size >> - update the position of the tags/attachment in the SeekHead section >> >> That's more or less what you'd have to do in any container anyway, >> except some may not have a Void element and would always put these >> data at the end (not nice for network reading). >> >> On Mon, Jan 31, 2011 at 1:23 PM, Santiago Jimeno wrote: >>> >>> Hi all >>> >>> In the email I sent speaking about CodecSpecs a while ago, I said that I >>> would write other about Tags. >>> I think the current message provides me this opportunity. >>> >>> Reading Tags is relatively easy (in spite of Nested Tags) in Visual .NET >>> because of the easiness that .NET provides to work with XML Documents. >>> >>> Editing or re-writing Tags is complicated. But I have it done in my >>> program >>> FileList. >>> But it's not still completed because of the difficulties that I have >>> found >>> with Cover Art. >>> >>> Cover Art are in a Attachments block (separated of Tags block) that is a >>> bag >>> for everything that also includes fonts, text and subtitles and located >>> in >>> any place of the file. The result in this case is that, in spite of its >>> initial advantages, it doesn't exist a program for editing Tags and I >>> think >>> it's for the extreme difficulty that implies to almost modify the whole >>> file. I think that to have two different blocks for Tags and Pictures is >>> not >>> a good design. In Flac files a similar thing happens. >>> >>> I am working in two possible solutions. >>> 1.- Declaring VOID the block part that contains Pictures and writing them >>> at >>> the file end (next to Tags) in a second Attachments block. >>> 2.- Including them in a new SimpleTag COVERART inside TAGS, >>> maintaining its structure. The binary data could be written as >>> >>> or as in Base64 so that was compatible with UTF8 (Vorbis >>> Comments do it this way). >>> >>> If somebody wants to test FileList program, one can download it in >>> http://personales.ya.com/sjimeno/Download/MATROSKAFileList.zip >>> To show edit form --> double click in List Item. >>> This program is designed for audio files MKA, although it also reads >>> video >>> files MKV. Apply Tags edition is disabled at the moment due to the >>> problem >>> above mentioned. >>> >>> Regards. Santiago Jimeno >>> >>> _______________________________________________ >>> Matroska-devel mailing list >>> Matroska-devel at lists.matroska.org >>> http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel >>> Read Matroska-Devel on GMane: >>> http://dir.gmane.org/gmane.comp.multimedia.matroska.devel >>> >> >> >> >> -- >> Steve Lhomme >> Matroska association Chairman >> _______________________________________________ >> Matroska-devel mailing list >> Matroska-devel at lists.matroska.org >> http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel >> Read Matroska-Devel on GMane: >> http://dir.gmane.org/gmane.comp.multimedia.matroska.devel >> > > > _______________________________________________ > Matroska-devel mailing list > Matroska-devel at lists.matroska.org > http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel > Read Matroska-Devel on GMane: > http://dir.gmane.org/gmane.comp.multimedia.matroska.devel > -- Steve Lhomme Matroska association Chairman From sjimeno at ya.com Wed Feb 2 03:27:44 2011 From: sjimeno at ya.com (Santiago Jimeno) Date: Wed, 2 Feb 2011 03:27:44 +0100 Subject: [Matroska-devel] Hi, question about the MKV tags In-Reply-To: References: <8B9241CBAC8B4AF69D411FBC37353EDB@JSASUS> Message-ID: <170B1CF627D047A08D57C9943E872C6A@JSASUS> Thank you to accept my suggestion regarding the VOID space behind SeekHead. Regarding installation error see you this post: http://blog.colinmackay.net/archive/2007/06/21/36.aspx As for covertart, including it in audio files was, as you know, an idea of ID3 that integrated it in Tags block and with binary code. All Tags systems adapted as better they could this idea. Generally transcribing the same APIC ID3 format almost literally. All the current systems (ID3, iTunes-MP4, WMA-ASF, APE, VORBIS) integrate coverart inside the Tags block. This is fundamentally for effectiveness when writing and editing. There are only two exceptions FLAC and MATROSKA. Sometimes WMA, if there is one Picture of big size, put it outside of the Tags block. But this is due to a space problem caused by a design error (there is only an Int16 to specify Data Length, with what the maximum size for each picture is 65535 bytes). FLAC works with Vorbis Comments Tags system. Previously it included coverart in a PICTURE block separated since Vorbis had not decided where to include it. When Vorbis decided to include coverart put it inside the Tags block. Now FLAC can write coverart in two places: in the old place and inside Vorbis Comments (??). Of course, FLAC won't change neither this as Martin Leese of FLAC team told me. Steve said "I still don't know what's wrong with attachments as they are now." There is not wrong with Attachments just as they are. It's a good idea for streaming. But for all the other cases it's more effective and more rational to include them in the Tags block. When all Tags systems make it this way for something will be. I only can add my suggestions for my experience working with Tags. Maybe if you try to write code to edit Tags and covertart you coincide with me. As for the blocks location it's also ineffective to locate them in the file middle knowing that when being edited they will be placed at the file end. When editing Attachments and Tags in cover_art.mkv file and are transferred at the file end leaves a excessive VOID space of aprox. 416000 bytes (very possibly useless). On the other hand the normal thing is not that the pictures are already inserted and we don't need to change them, the normal thing is that there is not any and we have to put them. Steve said: "Adding binary in tags should be avoided, because it's not implied how to interpret it. For pictures it could be JPEG, PNG, SVG, etc. Attachments have a MIME type for that, tags don't. You can notice in the specs the very few formats with binary values are those with only one possible format." The APIC ID3 format, the same one also adopted by Matroska in Attachments, includes all necessary data to interpret the binary code that goes next and one can put it perfectly inside the Tags block. When all Tags are declared as UTF8 string, like in Vorbis case, what they have made with covertart is to translate the whole package to Base68 that is compatible with UTF8. Lastly, like FLAC case, I can only do suggestions. The decisions and the future of Tags depend on Matroska team if one wants that the Tags system is something more than a project. I'm collaborating to improve the development of Matroska Tags with my 'almost' completed editor (I think it's the only one at the moment). But as you say at the beginning of your message: "So there is just one system to deal with everything" Regards. Santiago ----- Original Message ----- From: "Steve Lhomme" To: "Discussion about the current and future development of Matroska" Sent: Tuesday, February 01, 2011 9:50 PM Subject: Re: [Matroska-devel] Hi, question about the MKV tags On Tue, Feb 1, 2011 at 12:57 PM, Santiago Jimeno wrote: > Steve said "The reason for this is that some apps may support attachments > and not tags. The cover art system is much simpler to support than tags > (when done properly)." > > Indeed it's easier of supporting. But the practical problem is presented > when it's necessary to support at the same time the edition with Tags and > Pictures modifications and besides in two different blocks. This > complicates > the code a lot. The ideal thing would be Tags and Picture were in oneself > block and with preference at the file end. Then you could argue chapters should be in tags. So there is just one system to deal with everything. But these features are made modular on purpose. We are not going to change that now. > If the target of the file is streaming for network reading, picture should > be before Cluster. But if the target is to make a file that can be > modified > later on (for example to organize a collection in a PC) the picture > location > should be, as before I said, at the file end next to Tags. In fact I think cover art is very unlikely to be edited further by the user (unless it was not originally present). Tags that are open-ended (which unlimited possible extensions) can always be enhanced with more data. Cover Art rarely differs. All the rationale behind the choice of positions can be found here : http://www.matroska.org/technical/order/index.html > Anyway if Tags and Picture are edited (mainly if one adds information) > will > necessarily go at the end. On the other hand it's more difficult of > working > when picture is in the same block with fonts and subtitles. Subtitles are in the stream, not as attachments. It is true for fonts. > In another message Steve said: "In fact right now nobody cares about > tags." > But not only the external programs. I take enough time working in tags and > my impression is that the programs that make Matroska files neither take > care of it. Tags is not generally added when a file is converted to > Matroska, even when the original file already includes them. I think that > one acts in such way that once made the Matroska file is expected that > nobody modifies it. I don't think it's reasonable to add tags and assuming noone will change them. Even the content I buy on music stores, I customize the tags to meet my archiving system. > When adding or editing Tags and Pictures is necessary to modify also > SeekHead. For this is necessary (it should be mandatory) this block has a > VOID space later. Well, this is the situation of some files tested: mkclean leaves room for tags indeed (not attachments). mkvtoolnix also produces a large void at the beggining of the file for such changes. I'm not sure it should be a rule to impose, but more a guideline. > - Haali adds only 14 bytes of VOID space. If one adds Tags at the file end > we would need a minimum of 17 bytes for Seek entry. Conclusion: one cannot > add SeekHead entry. Less still if one modifies Pictures in Attachments. > > - Direct Show adds 130 bytes of VOID space. A little fair but enough. > > - MkvMerge doesn't add VOID space in versions 4.0.0 and 4.1.1. Fortunately > in the remaining versions Mosu is very generous and he adds a VOID space > of > 4000 bytes. We are of luck that most of files Matroska are made with > mkvmerge. > > - An example of complicated design for Tags is the sample provided for > pictures in cover_art.mkv file. Tags and Attachments are before Cluster. > If > one modifies them then they will go at the file end. But the VOID space > after SeekHead is 0 bytes. Finally I have been able to modify the file > deleting 4 bytes of CRC that had each entry to be able to include the new > entries for Tags and Attachments. Look at the section "Optimum layout after editing tags" in the Order Guideline. When editing tags/attachments and they don't fit in their original place, they should be moved at the end. That leaves plenty of room at the front to add new elements in the SeekHead. > I think it would be necessary to setting some clearer norms for impeling > the > inclusion of Tags in the files and to favor its edition. But as the > specifications leave a wide field of freedom at least some recommendations > should be made. > > - The VOID space after SeekHead should be if not mandatory at least very > recommendable Correct. I will try to add that somewhere. The ordering guideline may be the most appropriate place for now, as it discusses each "level-1" elements placement in general. > - Tags should be at the file end with preference. In fact the preference is at the front. Although in most cases where it will have been edited, it will end up at the end. > - In pictures case, if the target of the file is not streaming, the > Attachments block should be after Cluster. Mkvmerge uses two SeekHead > blocks, one for master elements at beginning of file and another before > the > cluster blocks. This good design approach could also be applied to > Attachments. One Attachments could be before Cluster for fonts and > subtitles > and other one after Cluster for Pictures and maybe also for Lyrics. In fact the 2 SeekHead approach was dropped recently. Noone could remember why it was done in the first place. And it's more complex to support on the player side. > - But the ideal thing would be to be able to include Pictures like a > SimpleTag inside Tags. For not modifying the design of the Matroska > container substantially it could be optional according to the file target > (streaming or other) to put the Pictures in Attachments or in Tags but not > in both at the same time. Adding binary in tags should be avoided, because it's not implied how to interpret it. For pictures it could be JPEG, PNG, SVG, etc. Attachments have a MIME type for that, tags don't. You can notice in the specs the very few formats with binary values are those with only one possible format. > So I propose to declare official a SimpleTag for Pictures with the > following > outline: > > TagName: PICTURE OR COVERTART > > TagBinary: Identical structure of Attachments Picture including in the > binary code FILEDESC, FILENAME, FILEMIMETYPE and FILEDATA, that is to say, > the ID3 APIC structure. In the event of being necessary the compatibility > for UTF8 the whole binary code can be converted to Base64 (thus vorbis > does > it). But this fills 25% more space So you want to add attachments inside a TagBinary element ? That deserves some reflection... I still don't know what's wrong with attachments as they are now. > Regards. Santiago > > PS. If somebody has tested my program FileList for Tags > http://personales.ya.com/sjimeno/Download/MATROSKAFileList.zip > I would thank the comments or suggestions Error 2755 in the MSI installer (Vista 64 bits in english) > ----- Original Message ----- From: "Steve Lhomme" > To: "Discussion about the current and future development of Matroska" > > Sent: Monday, January 31, 2011 1:32 PM > Subject: Re: [Matroska-devel] Hi, question about the MKV tags > > >> The reason for this is that some apps may support attachments and not >> tags. The cover art system is much simpler to support than tags (when >> done properly). >> >> And yes, when editing tags/cover art you have to check if it can fit >> in the original place, if not you have to : >> - void the old version >> - write the new version at the end >> - update the segment size >> - update the position of the tags/attachment in the SeekHead section >> >> That's more or less what you'd have to do in any container anyway, >> except some may not have a Void element and would always put these >> data at the end (not nice for network reading). >> >> On Mon, Jan 31, 2011 at 1:23 PM, Santiago Jimeno wrote: >>> >>> Hi all >>> >>> In the email I sent speaking about CodecSpecs a while ago, I said that I >>> would write other about Tags. >>> I think the current message provides me this opportunity. >>> >>> Reading Tags is relatively easy (in spite of Nested Tags) in Visual .NET >>> because of the easiness that .NET provides to work with XML Documents. >>> >>> Editing or re-writing Tags is complicated. But I have it done in my >>> program >>> FileList. >>> But it's not still completed because of the difficulties that I have >>> found >>> with Cover Art. >>> >>> Cover Art are in a Attachments block (separated of Tags block) that is a >>> bag >>> for everything that also includes fonts, text and subtitles and located >>> in >>> any place of the file. The result in this case is that, in spite of its >>> initial advantages, it doesn't exist a program for editing Tags and I >>> think >>> it's for the extreme difficulty that implies to almost modify the whole >>> file. I think that to have two different blocks for Tags and Pictures is >>> not >>> a good design. In Flac files a similar thing happens. >>> >>> I am working in two possible solutions. >>> 1.- Declaring VOID the block part that contains Pictures and writing >>> them >>> at >>> the file end (next to Tags) in a second Attachments block. >>> 2.- Including them in a new SimpleTag COVERART inside TAGS, >>> maintaining its structure. The binary data could be written as >>> >>> or as in Base64 so that was compatible with UTF8 (Vorbis >>> Comments do it this way). >>> >>> If somebody wants to test FileList program, one can download it in >>> http://personales.ya.com/sjimeno/Download/MATROSKAFileList.zip >>> To show edit form --> double click in List Item. >>> This program is designed for audio files MKA, although it also reads >>> video >>> files MKV. Apply Tags edition is disabled at the moment due to the >>> problem >>> above mentioned. >>> >>> Regards. Santiago Jimeno >>> >>> _______________________________________________ >>> Matroska-devel mailing list >>> Matroska-devel at lists.matroska.org >>> http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel >>> Read Matroska-Devel on GMane: >>> http://dir.gmane.org/gmane.comp.multimedia.matroska.devel >>> >> >> >> >> -- >> Steve Lhomme >> Matroska association Chairman >> _______________________________________________ >> Matroska-devel mailing list >> Matroska-devel at lists.matroska.org >> http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel >> Read Matroska-Devel on GMane: >> http://dir.gmane.org/gmane.comp.multimedia.matroska.devel >> > > > _______________________________________________ > Matroska-devel mailing list > Matroska-devel at lists.matroska.org > http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel > Read Matroska-Devel on GMane: > http://dir.gmane.org/gmane.comp.multimedia.matroska.devel > -- Steve Lhomme Matroska association Chairman _______________________________________________ Matroska-devel mailing list Matroska-devel at lists.matroska.org http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel Read Matroska-Devel on GMane: http://dir.gmane.org/gmane.comp.multimedia.matroska.devel From slhomme at matroska.org Wed Feb 2 21:09:08 2011 From: slhomme at matroska.org (Steve Lhomme) Date: Wed, 2 Feb 2011 21:09:08 +0100 Subject: [Matroska-devel] Hi, question about the MKV tags In-Reply-To: <170B1CF627D047A08D57C9943E872C6A@JSASUS> References: <8B9241CBAC8B4AF69D411FBC37353EDB@JSASUS> <170B1CF627D047A08D57C9943E872C6A@JSASUS> Message-ID: On Wed, Feb 2, 2011 at 3:27 AM, Santiago Jimeno wrote: > Thank you to accept my suggestion regarding the VOID space behind SeekHead. > > Regarding installation error see you this post: > http://blog.colinmackay.net/archive/2007/06/21/36.aspx > > As for covertart, including it in audio files was, as you know, an idea of > ID3 that integrated it in Tags block and with binary code. All Tags systems > adapted as better they could this idea. Generally transcribing the same APIC > ID3 format almost literally. But none of them had proper file attachment support. That's why they used this hack. > All the current systems (ID3, iTunes-MP4, WMA-ASF, APE, VORBIS) integrate > coverart inside the Tags block. This is fundamentally for effectiveness when > writing and editing. There are only two exceptions FLAC and MATROSKA. > Sometimes WMA, if there is one Picture of big size, put it outside of the > Tags block. But this is due to a space problem caused by a design error > (there is only an Int16 to specify Data Length, with what the maximum size > for each picture is 65535 bytes). I understand that cover art may be considered as a metadata. > FLAC works with Vorbis Comments Tags system. Previously it included coverart > in a PICTURE block separated since Vorbis had not decided where to include > it. When Vorbis decided to include coverart put it inside the Tags block. > Now FLAC can write coverart in two places: in the old place and inside > Vorbis Comments (??). Of course, FLAC won't change neither this as Martin > Leese of FLAC team told me. > > Steve said "I still don't know what's wrong with attachments as they are > now." > There is not wrong with Attachments just as they are. It's a good idea for > streaming. But for all the other cases it's more effective and more rational > to include them in the Tags block. When all Tags systems make it this way > for something will be. I only can add ?my suggestions for my experience > working with Tags. Maybe if you try to write code to edit Tags and covertart > you coincide with me. As for the blocks location it's also ineffective to The thing is, cover art is usually for the entire segment, whereas in Matroska tags are often not for the whole segment. That's why I think it's good that it's easy and straightforward to be able to read cover art without having to support all the tag system. Attachments are flat and very easy to parse. Tags have different level and signification depending on some values. So anything could be easily misunderstood as cover art if not implemented properly. > locate them in the file middle knowing that when being edited they will be > placed at the file end. When editing Attachments and Tags in cover_art.mkv > file and are transferred at the file end ?leaves a excessive VOID space of > aprox. 416000 bytes (very possibly useless). On the other hand the normal > thing is not that the pictures are already inserted and we don't need to > change them, the normal thing is that there is not any and we have to put > them. That's actually a good point to separate the cover art in attachment and tags that are usually edited. In the system you propose, adding one byte in the existing tags would make a big empty void in the file. That's ugly. Like I said, cover art are rarely edited. They are either added or removed, but rarely modified. And as the "ordering guideline" suggests, there are many good reasons why all these metadata should be at the front whenever possible. > Steve said: "Adding binary in tags should be avoided, because it's not > implied how to interpret it. For pictures it could be JPEG, PNG, SVG, etc. > Attachments have a MIME type for that, tags don't. You can notice in the > specs the very few formats with binary values are those with only one > possible format." > The APIC ID3 format, the same one also adopted by Matroska in Attachments, > includes all necessary data to interpret the binary code that goes next and > one can put it perfectly inside the Tags block. When all Tags are declared > as UTF8 string, like in Vorbis case, what they have made with covertart is > to translate the whole package to Base68 that is compatible with UTF8. We're certainly not going to use Base64 when our format is good at handling binary data. ID3 is badly designed and basically a hack over something missing in MP3 and then other formats. There's no reason to copy its flaws. > Lastly, like FLAC case, I can only do suggestions. The decisions and the > future of Tags depend on Matroska team if one wants that the Tags system is > something more than a project. I'm collaborating to improve the development > of Matroska Tags with my 'almost' completed editor (I think it's the only > one at the moment). But as you say at the beginning of your message: "So > there is just one system to deal with everything" Well, there has many many "only one moment" in the past about tag changes. I think we have reached a good consensus on everything that is possible. Maybe adding a MIME type next to binary data in tags could be a good move. But the recommended/default cover art should be in attachments in my opinion. That also makes it easier to make tools to scan for "files" inside matroska files if they are all in the same place. -- Steve Lhomme Matroska association Chairman From sjimeno at ya.com Wed Feb 2 23:23:56 2011 From: sjimeno at ya.com (Santiago Jimeno) Date: Wed, 2 Feb 2011 23:23:56 +0100 Subject: [Matroska-devel] Hi, question about the MKV tags In-Reply-To: References: <8B9241CBAC8B4AF69D411FBC37353EDB@JSASUS><170B1CF627D047A08D57C9943E872C6A@JSASUS> Message-ID: <90FFF839753D46459DE90AA19F0EF60D@JSASUS> Only some puntualizaci?n: Steve said: "In the system you propose, adding one byte in the existing tags would make a big empty void in the file" Not if they are already at the end of the file, a block is substituted for other and the file only increases 1 byte, without empty spaces, because there is not any other block at the end (a simple file append). Santiago said: "When editing Attachments and Tags in cover_art.mkv file and are transferred at the file end leaves a excessive VOID space of aprox. 416000 bytes (very possibly useless)." Of this enormous bytes number that I mention, correspond to the Tags 315 bytes, the rest is the space left empty for the pictures. Steve said: "Like I said, cover art are rarely edited. They are either added or removed, but rarely modified." The pictures can be extracted, modified and added again. But even this way, in fact they can only be added or deleted (for me this is editing the pictures). But if one is added the block necessarily moves at the end and leaves VOID space . Regarding picture structure in Attachments, anyone can realize that it's almost identical to APIC ID3. Here a comparison of both structures. ID3 MATROSKA ---- FileName Mime type FileMimeType Picture type ---- Description FileDescription Picture data FileData Lastly, as I said in my message, I only do suggestions, the decisions belong to you. Now I should work according to the current norms of the container. I will try to finish the editor when I can (I work in the one in my free time). Have me to the current of your opinion if you are able to install the program and to test it Regards. Santiago ----- Original Message ----- From: "Steve Lhomme" To: "Discussion about the current and future development of Matroska" Sent: Wednesday, February 02, 2011 9:09 PM Subject: Re: [Matroska-devel] Hi, question about the MKV tags On Wed, Feb 2, 2011 at 3:27 AM, Santiago Jimeno wrote: > Thank you to accept my suggestion regarding the VOID space behind > SeekHead. > > Regarding installation error see you this post: > http://blog.colinmackay.net/archive/2007/06/21/36.aspx > > As for covertart, including it in audio files was, as you know, an idea of > ID3 that integrated it in Tags block and with binary code. All Tags > systems > adapted as better they could this idea. Generally transcribing the same > APIC > ID3 format almost literally. But none of them had proper file attachment support. That's why they used this hack. > All the current systems (ID3, iTunes-MP4, WMA-ASF, APE, VORBIS) integrate > coverart inside the Tags block. This is fundamentally for effectiveness > when > writing and editing. There are only two exceptions FLAC and MATROSKA. > Sometimes WMA, if there is one Picture of big size, put it outside of the > Tags block. But this is due to a space problem caused by a design error > (there is only an Int16 to specify Data Length, with what the maximum size > for each picture is 65535 bytes). I understand that cover art may be considered as a metadata. > FLAC works with Vorbis Comments Tags system. Previously it included > coverart > in a PICTURE block separated since Vorbis had not decided where to include > it. When Vorbis decided to include coverart put it inside the Tags block. > Now FLAC can write coverart in two places: in the old place and inside > Vorbis Comments (??). Of course, FLAC won't change neither this as Martin > Leese of FLAC team told me. > > Steve said "I still don't know what's wrong with attachments as they are > now." > There is not wrong with Attachments just as they are. It's a good idea for > streaming. But for all the other cases it's more effective and more > rational > to include them in the Tags block. When all Tags systems make it this way > for something will be. I only can add my suggestions for my experience > working with Tags. Maybe if you try to write code to edit Tags and > covertart > you coincide with me. As for the blocks location it's also ineffective to The thing is, cover art is usually for the entire segment, whereas in Matroska tags are often not for the whole segment. That's why I think it's good that it's easy and straightforward to be able to read cover art without having to support all the tag system. Attachments are flat and very easy to parse. Tags have different level and signification depending on some values. So anything could be easily misunderstood as cover art if not implemented properly. > locate them in the file middle knowing that when being edited they will be > placed at the file end. When editing Attachments and Tags in cover_art.mkv > file and are transferred at the file end leaves a excessive VOID space of > aprox. 416000 bytes (very possibly useless). On the other hand the normal > thing is not that the pictures are already inserted and we don't need to > change them, the normal thing is that there is not any and we have to put > them. That's actually a good point to separate the cover art in attachment and tags that are usually edited. In the system you propose, adding one byte in the existing tags would make a big empty void in the file. That's ugly. Like I said, cover art are rarely edited. They are either added or removed, but rarely modified. And as the "ordering guideline" suggests, there are many good reasons why all these metadata should be at the front whenever possible. > Steve said: "Adding binary in tags should be avoided, because it's not > implied how to interpret it. For pictures it could be JPEG, PNG, SVG, etc. > Attachments have a MIME type for that, tags don't. You can notice in the > specs the very few formats with binary values are those with only one > possible format." > The APIC ID3 format, the same one also adopted by Matroska in Attachments, > includes all necessary data to interpret the binary code that goes next > and > one can put it perfectly inside the Tags block. When all Tags are declared > as UTF8 string, like in Vorbis case, what they have made with covertart is > to translate the whole package to Base68 that is compatible with UTF8. We're certainly not going to use Base64 when our format is good at handling binary data. ID3 is badly designed and basically a hack over something missing in MP3 and then other formats. There's no reason to copy its flaws. > Lastly, like FLAC case, I can only do suggestions. The decisions and the > future of Tags depend on Matroska team if one wants that the Tags system > is > something more than a project. I'm collaborating to improve the > development > of Matroska Tags with my 'almost' completed editor (I think it's the only > one at the moment). But as you say at the beginning of your message: "So > there is just one system to deal with everything" Well, there has many many "only one moment" in the past about tag changes. I think we have reached a good consensus on everything that is possible. Maybe adding a MIME type next to binary data in tags could be a good move. But the recommended/default cover art should be in attachments in my opinion. That also makes it easier to make tools to scan for "files" inside matroska files if they are all in the same place. -- Steve Lhomme Matroska association Chairman _______________________________________________ Matroska-devel mailing list Matroska-devel at lists.matroska.org http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel Read Matroska-Devel on GMane: http://dir.gmane.org/gmane.comp.multimedia.matroska.devel From slhomme at matroska.org Thu Feb 3 07:27:04 2011 From: slhomme at matroska.org (Steve Lhomme) Date: Thu, 3 Feb 2011 07:27:04 +0100 Subject: [Matroska-devel] Hi, question about the MKV tags In-Reply-To: <90FFF839753D46459DE90AA19F0EF60D@JSASUS> References: <8B9241CBAC8B4AF69D411FBC37353EDB@JSASUS> <170B1CF627D047A08D57C9943E872C6A@JSASUS> <90FFF839753D46459DE90AA19F0EF60D@JSASUS> Message-ID: On Wed, Feb 2, 2011 at 11:23 PM, Santiago Jimeno wrote: > Only some puntualizaci?n: > > Steve said: "In the system you propose, adding one byte in the existing tags > would make a big empty void in the file" > Not if they are already at the end of the file, a block is substituted for > other and the file only increases 1 byte, without empty spaces, because > there is not any other block at the end (a simple file append). Yes but again. Your reason to put it at the end is for editing. My reason to put it at the wrong is for better reading. For example seeking in HTTP is slow. It's much better if everything is at the front. > Regarding picture structure in Attachments, anyone can realize that it's > almost identical to APIC ID3. Here a comparison of both structures. > > ID3 ? ? ? ? ? ? ? ? ? ? MATROSKA > ---- ? ? ? ? ? ? ? ? ? ? FileName > Mime type ? ? ? ? ? FileMimeType > Picture type ? ? ? ? ---- > Description ? ? ? ? ?FileDescription > Picture data ? ? ? ? FileData > > Lastly, as I said in my message, I only do suggestions, the decisions belong > to you. Now I should work according to the current norms of the container. I > will try to finish the editor when I can (I work in the one in my free > time). > > Have me to the current of your opinion if you are able to install the > program and to test ?it Not yet. I will try but I don't know when. > Regards. Santiago > > ----- Original Message ----- From: "Steve Lhomme" > To: "Discussion about the current and future development of Matroska" > > Sent: Wednesday, February 02, 2011 9:09 PM > Subject: Re: [Matroska-devel] Hi, question about the MKV tags > > > On Wed, Feb 2, 2011 at 3:27 AM, Santiago Jimeno wrote: >> >> Thank you to accept my suggestion regarding the VOID space behind >> SeekHead. >> >> Regarding installation error see you this post: >> http://blog.colinmackay.net/archive/2007/06/21/36.aspx >> >> As for covertart, including it in audio files was, as you know, an idea of >> ID3 that integrated it in Tags block and with binary code. All Tags >> systems >> adapted as better they could this idea. Generally transcribing the same >> APIC >> ID3 format almost literally. > > But none of them had proper file attachment support. That's why they > used this hack. > >> All the current systems (ID3, iTunes-MP4, WMA-ASF, APE, VORBIS) integrate >> coverart inside the Tags block. This is fundamentally for effectiveness >> when >> writing and editing. There are only two exceptions FLAC and MATROSKA. >> Sometimes WMA, if there is one Picture of big size, put it outside of the >> Tags block. But this is due to a space problem caused by a design error >> (there is only an Int16 to specify Data Length, with what the maximum size >> for each picture is 65535 bytes). > > I understand that cover art may be considered as a metadata. > >> FLAC works with Vorbis Comments Tags system. Previously it included >> coverart >> in a PICTURE block separated since Vorbis had not decided where to include >> it. When Vorbis decided to include coverart put it inside the Tags block. >> Now FLAC can write coverart in two places: in the old place and inside >> Vorbis Comments (??). Of course, FLAC won't change neither this as Martin >> Leese of FLAC team told me. >> >> Steve said "I still don't know what's wrong with attachments as they are >> now." >> There is not wrong with Attachments just as they are. It's a good idea for >> streaming. But for all the other cases it's more effective and more >> rational >> to include them in the Tags block. When all Tags systems make it this way >> for something will be. I only can add my suggestions for my experience >> working with Tags. Maybe if you try to write code to edit Tags and >> covertart >> you coincide with me. As for the blocks location it's also ineffective to > > The thing is, cover art is usually for the entire segment, whereas in > Matroska tags are often not for the whole segment. That's why I think > it's good that it's easy and straightforward to be able to read cover > art without having to support all the tag system. Attachments are flat > and very easy to parse. Tags have different level and signification > depending on some values. So anything could be easily misunderstood as > cover art if not implemented properly. > >> locate them in the file middle knowing that when being edited they will be >> placed at the file end. When editing Attachments and Tags in cover_art.mkv >> file and are transferred at the file end leaves a excessive VOID space of >> aprox. 416000 bytes (very possibly useless). On the other hand the normal >> thing is not that the pictures are already inserted and we don't need to >> change them, the normal thing is that there is not any and we have to put >> them. > > That's actually a good point to separate the cover art in attachment > and tags that are usually edited. In the system you propose, adding > one byte in the existing tags would make a big empty void in the file. > That's ugly. Like I said, cover art are rarely edited. They are either > added or removed, but rarely modified. And as the "ordering guideline" > suggests, there are many good reasons why all these metadata should be > at the front whenever possible. > >> Steve said: "Adding binary in tags should be avoided, because it's not >> implied how to interpret it. For pictures it could be JPEG, PNG, SVG, etc. >> Attachments have a MIME type for that, tags don't. You can notice in the >> specs the very few formats with binary values are those with only one >> possible format." >> The APIC ID3 format, the same one also adopted by Matroska in Attachments, >> includes all necessary data to interpret the binary code that goes next >> and >> one can put it perfectly inside the Tags block. When all Tags are declared >> as UTF8 string, like in Vorbis case, what they have made with covertart is >> to translate the whole package to Base68 that is compatible with UTF8. > > We're certainly not going to use Base64 when our format is good at > handling binary data. ID3 is badly designed and basically a hack over > something missing in MP3 and then other formats. There's no reason to > copy its flaws. > >> Lastly, like FLAC case, I can only do suggestions. The decisions and the >> future of Tags depend on Matroska team if one wants that the Tags system >> is >> something more than a project. I'm collaborating to improve the >> development >> of Matroska Tags with my 'almost' completed editor (I think it's the only >> one at the moment). But as you say at the beginning of your message: "So >> there is just one system to deal with everything" > > Well, there has many many "only one moment" in the past about tag > changes. I think we have reached a good consensus on everything that > is possible. Maybe adding a MIME type next to binary data in tags > could be a good move. But the recommended/default cover art should be > in attachments in my opinion. That also makes it easier to make tools > to scan for "files" inside matroska files if they are all in the same > place. > > -- > Steve Lhomme > Matroska association Chairman > _______________________________________________ > Matroska-devel mailing list > Matroska-devel at lists.matroska.org > http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel > Read Matroska-Devel on GMane: > http://dir.gmane.org/gmane.comp.multimedia.matroska.devel > > > _______________________________________________ > Matroska-devel mailing list > Matroska-devel at lists.matroska.org > http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel > Read Matroska-Devel on GMane: > http://dir.gmane.org/gmane.comp.multimedia.matroska.devel > -- Steve Lhomme Matroska association Chairman From sjimeno at ya.com Thu Feb 3 13:34:25 2011 From: sjimeno at ya.com (Santiago Jimeno) Date: Thu, 3 Feb 2011 13:34:25 +0100 Subject: [Matroska-devel] Hi, question about the MKV tags In-Reply-To: References: Message-ID: <44A5FDC3001C4157B802B5CF9C94827C@JSASUS> Steve said : "Your reason to put it at the end is for editing. My reason to put it at the wrong is for better reading. For example seeking in HTTP is slow. It's much better if everything is at the front." For that reasons I said in a previous message: "I take enough time working in tags and my impression is that the programs that make Matroska files neither take care of it. Tags is not generally added when a file is converted to Matroska, even when the original file already includes them. I think that one acts in such way that once made the Matroska file is expected that nobody modifies it." If we want Matroska Tags are successful (up to now very little) we should think on all aspects: file reading, tags writing when one creates the file and edition easiness. And we should give practical solutions to all them without preferences for none, since the end users will be who imposes their preferences. But actually on last two aspects nobody doesn't take care. For take care on last two aspects I offered those three proposals: 1- Appropriate Void space behind SeekHead. 2- Tags always at the end. 3- Possibility to include Picture inside Tags besides the possibility that they are also included in Attachments according the file target or file use. These three proposals don't modify the global structure of the container. Only are modified Order Guidelines on blocks location. How this to make? It's very easy and I see for your answers that you are already beginning to meditate on it. If they stay like they are now, I have already exposed the current situation: they will always finish at the end with big empty and useless spaces in the middle. Respecting the container norms to the maximum I don't have more remedy than to always put Tags and Pictures at the end when I write editing code. The best thing would be then Order Guidelines specifies definitive positions for both blocks from the same moment of file creation, and if they form one only block at the end would be still better. But I'm not an obstinate person and I think other possibilities. If you prefer everything at the beginning then we can put Tags or Pictures at the beginning. But if they are edited and we don't want to leave big empty spaces in middle and neither they always terminate at the end then they should be taken out of Segment (maybe being included in Header) so it doesn't affect to the localization of Cluster blocks whose position is measured from Segment. Editing would be also easy this way, but this affects to the current structure of the container and causes incompatibility back. Be which is team decision, I think it's necessary to thoroughly meditate on above-mentioned and on Order Guidelines locations. Maybe other Matroska programmers could also give an opinion on this. A less important question: Where we put LYRICS? Is it possible to add an official SimpleTag with this Tagname? Regards. Santiago ----- Original Message ----- From: "Steve Lhomme" To: "Discussion about the current and future development of Matroska" Sent: Thursday, February 03, 2011 7:27 AM Subject: Re: [Matroska-devel] Hi, question about the MKV tags On Wed, Feb 2, 2011 at 11:23 PM, Santiago Jimeno wrote: > Only some puntualizaci?n: > > Steve said: "In the system you propose, adding one byte in the existing > tags > would make a big empty void in the file" > Not if they are already at the end of the file, a block is substituted for > other and the file only increases 1 byte, without empty spaces, because > there is not any other block at the end (a simple file append). Yes but again. Your reason to put it at the end is for editing. My reason to put it at the wrong is for better reading. For example seeking in HTTP is slow. It's much better if everything is at the front. > Regarding picture structure in Attachments, anyone can realize that it's > almost identical to APIC ID3. Here a comparison of both structures. > > ID3 MATROSKA > ---- FileName > Mime type FileMimeType > Picture type ---- > Description FileDescription > Picture data FileData > > Lastly, as I said in my message, I only do suggestions, the decisions > belong > to you. Now I should work according to the current norms of the container. > I > will try to finish the editor when I can (I work in the one in my free > time). > > Have me to the current of your opinion if you are able to install the > program and to test it Not yet. I will try but I don't know when. > Regards. Santiago > > ----- Original Message ----- From: "Steve Lhomme" > To: "Discussion about the current and future development of Matroska" > > Sent: Wednesday, February 02, 2011 9:09 PM > Subject: Re: [Matroska-devel] Hi, question about the MKV tags > > > On Wed, Feb 2, 2011 at 3:27 AM, Santiago Jimeno wrote: >> >> Thank you to accept my suggestion regarding the VOID space behind >> SeekHead. >> >> Regarding installation error see you this post: >> http://blog.colinmackay.net/archive/2007/06/21/36.aspx >> >> As for covertart, including it in audio files was, as you know, an idea >> of >> ID3 that integrated it in Tags block and with binary code. All Tags >> systems >> adapted as better they could this idea. Generally transcribing the same >> APIC >> ID3 format almost literally. > > But none of them had proper file attachment support. That's why they > used this hack. > >> All the current systems (ID3, iTunes-MP4, WMA-ASF, APE, VORBIS) integrate >> coverart inside the Tags block. This is fundamentally for effectiveness >> when >> writing and editing. There are only two exceptions FLAC and MATROSKA. >> Sometimes WMA, if there is one Picture of big size, put it outside of the >> Tags block. But this is due to a space problem caused by a design error >> (there is only an Int16 to specify Data Length, with what the maximum >> size >> for each picture is 65535 bytes). > > I understand that cover art may be considered as a metadata. > >> FLAC works with Vorbis Comments Tags system. Previously it included >> coverart >> in a PICTURE block separated since Vorbis had not decided where to >> include >> it. When Vorbis decided to include coverart put it inside the Tags block. >> Now FLAC can write coverart in two places: in the old place and inside >> Vorbis Comments (??). Of course, FLAC won't change neither this as Martin >> Leese of FLAC team told me. >> >> Steve said "I still don't know what's wrong with attachments as they are >> now." >> There is not wrong with Attachments just as they are. It's a good idea >> for >> streaming. But for all the other cases it's more effective and more >> rational >> to include them in the Tags block. When all Tags systems make it this way >> for something will be. I only can add my suggestions for my experience >> working with Tags. Maybe if you try to write code to edit Tags and >> covertart >> you coincide with me. As for the blocks location it's also ineffective to > > The thing is, cover art is usually for the entire segment, whereas in > Matroska tags are often not for the whole segment. That's why I think > it's good that it's easy and straightforward to be able to read cover > art without having to support all the tag system. Attachments are flat > and very easy to parse. Tags have different level and signification > depending on some values. So anything could be easily misunderstood as > cover art if not implemented properly. > >> locate them in the file middle knowing that when being edited they will >> be >> placed at the file end. When editing Attachments and Tags in >> cover_art.mkv >> file and are transferred at the file end leaves a excessive VOID space of >> aprox. 416000 bytes (very possibly useless). On the other hand the normal >> thing is not that the pictures are already inserted and we don't need to >> change them, the normal thing is that there is not any and we have to put >> them. > > That's actually a good point to separate the cover art in attachment > and tags that are usually edited. In the system you propose, adding > one byte in the existing tags would make a big empty void in the file. > That's ugly. Like I said, cover art are rarely edited. They are either > added or removed, but rarely modified. And as the "ordering guideline" > suggests, there are many good reasons why all these metadata should be > at the front whenever possible. > >> Steve said: "Adding binary in tags should be avoided, because it's not >> implied how to interpret it. For pictures it could be JPEG, PNG, SVG, >> etc. >> Attachments have a MIME type for that, tags don't. You can notice in the >> specs the very few formats with binary values are those with only one >> possible format." >> The APIC ID3 format, the same one also adopted by Matroska in >> Attachments, >> includes all necessary data to interpret the binary code that goes next >> and >> one can put it perfectly inside the Tags block. When all Tags are >> declared >> as UTF8 string, like in Vorbis case, what they have made with covertart >> is >> to translate the whole package to Base68 that is compatible with UTF8. > > We're certainly not going to use Base64 when our format is good at > handling binary data. ID3 is badly designed and basically a hack over > something missing in MP3 and then other formats. There's no reason to > copy its flaws. > >> Lastly, like FLAC case, I can only do suggestions. The decisions and the >> future of Tags depend on Matroska team if one wants that the Tags system >> is >> something more than a project. I'm collaborating to improve the >> development >> of Matroska Tags with my 'almost' completed editor (I think it's the only >> one at the moment). But as you say at the beginning of your message: "So >> there is just one system to deal with everything" > > Well, there has many many "only one moment" in the past about tag > changes. I think we have reached a good consensus on everything that > is possible. Maybe adding a MIME type next to binary data in tags > could be a good move. But the recommended/default cover art should be > in attachments in my opinion. That also makes it easier to make tools > to scan for "files" inside matroska files if they are all in the same > place. > > -- > Steve Lhomme > Matroska association Chairman > _______________________________________________ > Matroska-devel mailing list > Matroska-devel at lists.matroska.org > http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel > Read Matroska-Devel on GMane: > http://dir.gmane.org/gmane.comp.multimedia.matroska.devel > > > _______________________________________________ > Matroska-devel mailing list > Matroska-devel at lists.matroska.org > http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel > Read Matroska-Devel on GMane: > http://dir.gmane.org/gmane.comp.multimedia.matroska.devel > -- Steve Lhomme Matroska association Chairman _______________________________________________ Matroska-devel mailing list Matroska-devel at lists.matroska.org http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel Read Matroska-Devel on GMane: http://dir.gmane.org/gmane.comp.multimedia.matroska.devel From boris.juraga at gmail.com Thu Feb 3 15:03:08 2011 From: boris.juraga at gmail.com (Boris Juraga) Date: Thu, 3 Feb 2011 15:03:08 +0100 Subject: [Matroska-devel] Hi, question about the MKV tags In-Reply-To: <44A5FDC3001C4157B802B5CF9C94827C@JSASUS> References: <44A5FDC3001C4157B802B5CF9C94827C@JSASUS> Message-ID: Well ok, i respect other people opinions, i am here to read them and express mine too. To Santiago: All this pushing to make the tags at the end of the file as a standard -- you have to understand that it benefits only you, and Matroska is made to be the only flexible container in the world in my opinion. No one is stoping you and your app to place the tags at the end (Reasons: you are lazy to move parts of file, you dont know how to insert (reserve) void space after the tags, you are woried about speed and need of remuxing, etc.), but it is not in the specs and there are allot more reasons that the tags are in the front (again: Matroska is flexible container). I am making tag reading, tag creating and soon tag writing app too, so i best understand you and the problems you have, but it has to stay this way as it benefits a wider group of users, apps and scenarios. Also as Steve said about the pictures in tags -- the other containers had to hack their specs so they are able to contain cover art, Matroska has attachments for that. Also cover art is not going to be edited (read: removed and added new), but either if the file does not contain cover art it will be added, or if contains some it will be appended (completed). For this i think it is normal to wait the remuxing process. Tags are much much smaller in bytes and are much much complex for creating, so i think they are like this for a reason -- flexibility. I think that placing pictures in the tags is arbitrary. It does not suit anyone. If you think of a scenario where this will be inevitable please share it here. In the mean time tell me how your app handles tags and will it be used like a library for other applications to build UI, or you allow people to edit them. If the latter is true, i hope you made it to the place where you have to think of different tags "profiles" for different file types. Boris Juraga From pushparaj.dominic at nxp.com Thu Feb 3 10:09:48 2011 From: pushparaj.dominic at nxp.com (Pushparaj Dominic) Date: Thu, 3 Feb 2011 10:09:48 +0100 Subject: [Matroska-devel] A question on effort required for porting mkv demuxer Message-ID: Hi, We are planning to have Matroska demuxer ported onto our Trimedia platform in the future. In this connection, I would like to know how much is the average effort required for porting Matroska container demuxer on any typical embedded platform including typically the effort for optimizing using compiler ( for any platform , if we have effort that would be fine.) Thanks & Regards, Pushp Systems Architect -Software, [cid:image001.png at 01CBC3B0.3551BA00], Manyata Information Technology Park, Nagavara Village, Kasaba Hobli, Bangalore 560 045 India Tel: +91-80-40247133 Cell: +91-9845598733 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 3243 bytes Desc: image001.png URL: From slhomme at matroska.org Fri Feb 4 08:39:53 2011 From: slhomme at matroska.org (Steve Lhomme) Date: Fri, 4 Feb 2011 08:39:53 +0100 Subject: [Matroska-devel] A question on effort required for porting mkv demuxer In-Reply-To: References: Message-ID: There are plenty of free libraries existing. For embedded you may not want to use our C++ library. You could use the C versions 'libebml2/libmatroska2), otherwise Haali's parser is pretty popular and free as well. Steve On Thu, Feb 3, 2011 at 10:09 AM, Pushparaj Dominic < pushparaj.dominic at nxp.com> wrote: > Hi, > > We are planning to have Matroska demuxer ported onto our Trimedia > platform in the future. In this connection, I would like to know how much is > the average effort required for porting Matroska container demuxer on any > typical embedded platform including typically the effort for optimizing > using compiler ( for any platform , if we have effort that would be fine.) > > > > Thanks & Regards, > > *Pushp* > > Systems Architect -Software, > > , > > Manyata Information Technology Park, Nagavara Village, Kasaba Hobli, > Bangalore 560 045 India > *Tel:* +91-80-40247133 *Cell:* +91-9845598733 > > > > _______________________________________________ > Matroska-devel mailing list > Matroska-devel at lists.matroska.org > http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel > Read Matroska-Devel on GMane: > http://dir.gmane.org/gmane.comp.multimedia.matroska.devel > -- Steve Lhomme Matroska association Chairman -------------- next part -------------- An HTML attachment was scrubbed... URL: From slhomme at matroska.org Sat Feb 5 10:57:35 2011 From: slhomme at matroska.org (Steve Lhomme) Date: Sat, 5 Feb 2011 10:57:35 +0100 Subject: [Matroska-devel] multiple video streams stereo 3D mode broken In-Reply-To: <83F9BA8D634AB948A4DCAD9D2026E9740143DD089138@IBM-336-KKVZP3V.dynamicsnetwork.net> References: <83F9BA8D634AB948A4DCAD9D2026E9740143DD089133@IBM-336-KKVZP3V.dynamicsnetwork.net> <83F9BA8D634AB948A4DCAD9D2026E9740143DD089134@IBM-336-KKVZP3V.dynamicsnetwork.net> <83F9BA8D634AB948A4DCAD9D2026E9740143DD089136@IBM-336-KKVZP3V.dynamicsnetwork.net> <83F9BA8D634AB948A4DCAD9D2026E9740143DD089138@IBM-336-KKVZP3V.dynamicsnetwork.net> Message-ID: Moving the discussion to the list at some other people may be interrested. On Fri, Feb 4, 2011 at 6:49 PM, Dorian Muthig wrote: > Hello, > > Whilst converting a local library to the new format wouldn't be much of a problem, for files from a remote source I still can be sure about the format used, especially since people don't usually update their muxing software regularly and stick to what they know and rely on. > The old format made sense very well. If the first or default video is a stream with stereo mode set to 1 or 2, I need to look for the second complementary stream that uses the stereo mode for the other eye. The playback software then combines the picture from both streams into a display or projector output for stereoscopic viewing. > There may not have been a large consumer space for 3D viewing at home at the time, but small production environments and 3D movie theaters have used the format due to its codec versatility. I understand. But it should not be left to guessing which track should be combined with what other. Imagine you have 2 right eye and 2 left eye tracks (for example a multi angle video). There was nothing to know which should be used. I think it's too late now to change the values again (and leave empty the fields that were used). So since such systems use a custom player, I guess they can be updated to check which mkvmerge value was used (unless they also used custom muxers). It's not much more complex than checking for a new field. Such players should also be updated to handle the new TrackOperation system too. I'll add in my TODO a tack to make the mkvmerge check and StereoMode fix. Steve > Best regards, > > Dorian Muthig > IT & Intelligence Services > Phone: +49 1522 9290158 (callerID required) > Twitter: @dorianmuthig > contact at dorianmuthig.com > ? Please consider the environment before printing this document! > > > -----Original Message----- > From: Steve Lhomme [mailto:slhomme at matroska.org] > Sent: Friday, February 04, 2011 1:55 PM > To: Dorian Muthig > Subject: Re: multiple video streams stereo 3D mode broken > > If necessary If can add a feature to mkclean to turn old files into new ones, assuming they are made with older mkvmerge versions. > > The old system with one side of the stereo per track without anything to tell how they are combined is just not good. It was there as a placeholder a long time ago before we had any idea how 3D would be used. It's sad that mkvmerge presented the feature when it was really not considered stable. > > On Fri, Feb 4, 2011 at 12:37 PM, Dorian Muthig wrote: >> Hello, >> >> I was planning on updating a system to the new specifications and this caused a conflict with existing use that would render the system effectively useless upon change. >> >> Best regards, >> >> Dorian Muthig >> IT & Intelligence Services >> Phone: +49 1522 9290158 (callerID required) >> Twitter: @dorianmuthig >> contact at dorianmuthig.com >> P Please consider the environment before printing this document! >> >> >> -----Original Message----- >> From: Steve Lhomme [mailto:slhomme at matroska.org] >> Sent: Friday, February 04, 2011 12:18 PM >> To: Dorian Muthig >> Subject: Re: multiple video streams stereo 3D mode broken >> >> I know changing something that was potentially used is bad. But do you actually know a system that was using the old specs ? You seem to be talking about a system, but not that it is actually using 3D inside Matroska. >> >> According to this http://www.matroska.org/node/1/revisions the StereoMode values were changed in September 2010. >> >> On Fri, Feb 4, 2011 at 12:12 PM, Dorian Muthig wrote: >>> Hello, >>> >>> Thank you for your quick reply. >>> >>> I do not know of any consumer software, but I am aware of a few custom solutions utilizing polarized projection systems that feed separate video streams to two projectors. The problem is, files created according to the old specifications played back with software of the new specification, would discard the second video stream and display garbage on the first display. It further renders the parameters 1 through 3 for video streams of the new kind useless and requires a computationally expensive or at least inefficient way to detect the stereoscopy format. This means if I want to support both formats, I need to find additional metadata or analyze the picture before deciding to split the picture or loading the second video stream, which according to the new specifications is more likely to contain a different and optionally alternate choice of content. >>> Adding new functionality is good. Removing and replacing functionality under the assumption nobody used it, is always a bad idea. >>> >>> Best regards, >>> >>> Dorian Muthig >>> IT & Intelligence Services >>> Phone: +49 1522 9290158 (callerID required) >>> Twitter: @dorianmuthig >>> contact at dorianmuthig.com >>> P Please consider the environment before printing this document! >>> >>> -----Original Message----- >>> From: Steve Lhomme [mailto:slhomme at matroska.org] >>> Sent: Friday, February 04, 2011 11:23 AM >>> To: Dorian Muthig >>> Subject: Re: multiple video streams stereo 3D mode broken >>> >>> Are you aware of any software that could play files the old values ? >>> >>> On Fri, Feb 4, 2011 at 8:53 AM, Dorian Muthig wrote: >>>> Hello, >>>> >>>> >>>> >>>> In the new revision of the specifications in regard to the >>>> StereoMode field there is an issue with backward compatibility. The >>>> earlier spec defined 0 (no stereo/mono), 1 (left), 2 (right), 3 >>>> (both). While there is no change for non-stereo content, it is no >>>> longer possible to use two separate video streams and content >>>> creating the format would no longer play correctly on playback >>>> software written according to the new specifications. You should >>>> keep the old modes and only have added the new ones for the consumer >>>> playback formats. In production environments it is common to keep >>>> the video streams separately (modes >>>> 1 and 2) or to define the type of stereo mode used in the video >>>> stream headers (mode 3). For backward compatibility those settings >>>> should have remained as is and the new settings be amended starting >>>> with mode 4, resulting in 14 total modes. While TrackCombinePlanes >>>> are a solution for new content with separate video streams, they do not solve the playback problem with files muxed according to the old specification. >>>> >>>> >>>> >>>> Best regards, >>>> >>>> >>>> >>>> Dorian Muthig >>>> >>>> IT & Intelligence Services >>>> >>>> Phone: +49 1522 9290158 (callerID required) >>>> >>>> Twitter: @dorianmuthig >>>> >>>> contact at dorianmuthig.com >>>> >>>> P Please consider the environment before printing this document! >>>> >>>> >>> >>> >>> >>> -- >>> Steve Lhomme >>> Matroska association Chairman >>> >> >> >> >> -- >> Steve Lhomme >> Matroska association Chairman >> > > > > -- > Steve Lhomme > Matroska association Chairman > -- Steve Lhomme Matroska association Chairman From slhomme at matroska.org Sat Feb 5 13:49:52 2011 From: slhomme at matroska.org (Steve Lhomme) Date: Sat, 5 Feb 2011 13:49:52 +0100 Subject: [Matroska-devel] multiple video streams stereo 3D mode broken In-Reply-To: <83F9BA8D634AB948A4DCAD9D2026E9740143E760D4B7@IBM-336-KKVZP3V.dynamicsnetwork.net> References: <83F9BA8D634AB948A4DCAD9D2026E9740143DD089133@IBM-336-KKVZP3V.dynamicsnetwork.net> <83F9BA8D634AB948A4DCAD9D2026E9740143DD089134@IBM-336-KKVZP3V.dynamicsnetwork.net> <83F9BA8D634AB948A4DCAD9D2026E9740143DD089136@IBM-336-KKVZP3V.dynamicsnetwork.net> <83F9BA8D634AB948A4DCAD9D2026E9740143DD089138@IBM-336-KKVZP3V.dynamicsnetwork.net> <83F9BA8D634AB948A4DCAD9D2026E9740143E760D4B7@IBM-336-KKVZP3V.dynamicsnetwork.net> Message-ID: Mm, this is embarrassing. I wish we had the info that people were actually using the StereoMode feature already. Especially now that we have release libmatroska and mkvtoolnix. Still, is there a single custom player that handles these files or many ? Can you point me to the people who are doing it ? There might be ways to work things out on the technical side. If they only support separate tracks and not side by side, then all the files they would encounter with the newer values would contain the TrackOperation element. And for old files/muxers it would be StereoMode 1 and 2. So that could be the "easy" detection. Of course this breaks if they support side by side as defined in values 1 and 2. Steve On Sat, Feb 5, 2011 at 12:33 PM, Dorian Muthig wrote: > Hello, > > A few production solutions use a custom muxer for video stream to MKV recording with the indexes added after recording completion, but the application of choice was mostly Haali's DS Mux due to mkvmerge's problems with the VC-1 codec bitstream, some types of AVC and all types of AVS (popular in China and only used in entirely custom solutions), the unsupported tags have in that case been added later via a header and tag editor. The Matroska headers are very minimalistic in some cases and do not include the parameter for the writing application. > As for the viewing angles, those are usually referenced in the track title or chapters, since there's no property in the specifications for that. More common are different aspect ratios, resolutions and video languages, which can be easily detected via the appropriate meta data and simple logic. In order to fool the detection for the old format you would have to intentionally make a file with incorrect parameters for language and aspect ratio or image size. Whilst this can occur, it is more likely that those parameters are missing and only the needed streams (left and right video plus audio) are included in one file due to laziness of the file author. > > Best regards, > > Dorian Muthig > IT & Intelligence Services > Phone: +49 1522 9290158 (callerID required) > Twitter: @dorianmuthig > contact at dorianmuthig.com > ? Please consider the environment before printing this document! > > -----Original Message----- > From: Steve Lhomme [mailto:slhomme at matroska.org] > Sent: Saturday, February 05, 2011 10:58 AM > To: Dorian Muthig > Cc: Matroska Devel > Subject: Re: multiple video streams stereo 3D mode broken > > Moving the discussion to the list at some other people may be interrested. > > On Fri, Feb 4, 2011 at 6:49 PM, Dorian Muthig wrote: >> Hello, >> >> Whilst converting a local library to the new format wouldn't be much of a problem, for files from a remote source I still can be sure about the format used, especially since people don't usually update their muxing software regularly and stick to what they know and rely on. >> The old format made sense very well. If the first or default video is a stream with stereo mode set to 1 or 2, I need to look for the second complementary stream that uses the stereo mode for the other eye. The playback software then combines the picture from both streams into a display or projector output for stereoscopic viewing. >> There may not have been a large consumer space for 3D viewing at home at the time, but small production environments and 3D movie theaters have used the format due to its codec versatility. > > I understand. But it should not be left to guessing which track should be combined with what other. Imagine you have 2 right eye and 2 left eye tracks (for example a multi angle video). There was nothing to know which should be used. > > I think it's too late now to change the values again (and leave empty the fields that were used). So since such systems use a custom player, I guess they can be updated to check which mkvmerge value was used (unless they also used custom muxers). It's not much more complex than checking for a new field. Such players should also be updated to handle the new TrackOperation system too. > > I'll add in my TODO a tack to make the mkvmerge check and StereoMode fix. > > Steve > >> Best regards, >> >> Dorian Muthig >> IT & Intelligence Services >> Phone: +49 1522 9290158 (callerID required) >> Twitter: @dorianmuthig >> contact at dorianmuthig.com >> P Please consider the environment before printing this document! >> >> >> -----Original Message----- >> From: Steve Lhomme [mailto:slhomme at matroska.org] >> Sent: Friday, February 04, 2011 1:55 PM >> To: Dorian Muthig >> Subject: Re: multiple video streams stereo 3D mode broken >> >> If necessary If can add a feature to mkclean to turn old files into new ones, assuming they are made with older mkvmerge versions. >> >> The old system with one side of the stereo per track without anything to tell how they are combined is just not good. It was there as a placeholder a long time ago before we had any idea how 3D would be used. It's sad that mkvmerge presented the feature when it was really not considered stable. >> >> On Fri, Feb 4, 2011 at 12:37 PM, Dorian Muthig wrote: >>> Hello, >>> >>> I was planning on updating a system to the new specifications and this caused a conflict with existing use that would render the system effectively useless upon change. >>> >>> Best regards, >>> >>> Dorian Muthig >>> IT & Intelligence Services >>> Phone: +49 1522 9290158 (callerID required) >>> Twitter: @dorianmuthig >>> contact at dorianmuthig.com >>> P Please consider the environment before printing this document! >>> >>> >>> -----Original Message----- >>> From: Steve Lhomme [mailto:slhomme at matroska.org] >>> Sent: Friday, February 04, 2011 12:18 PM >>> To: Dorian Muthig >>> Subject: Re: multiple video streams stereo 3D mode broken >>> >>> I know changing something that was potentially used is bad. But do you actually know a system that was using the old specs ? You seem to be talking about a system, but not that it is actually using 3D inside Matroska. >>> >>> According to this http://www.matroska.org/node/1/revisions the StereoMode values were changed in September 2010. >>> >>> On Fri, Feb 4, 2011 at 12:12 PM, Dorian Muthig wrote: >>>> Hello, >>>> >>>> Thank you for your quick reply. >>>> >>>> I do not know of any consumer software, but I am aware of a few custom solutions utilizing polarized projection systems that feed separate video streams to two projectors. The problem is, files created according to the old specifications played back with software of the new specification, would discard the second video stream and display garbage on the first display. It further renders the parameters 1 through 3 for video streams of the new kind useless and requires a computationally expensive or at least inefficient way to detect the stereoscopy format. This means if I want to support both formats, I need to find additional metadata or analyze the picture before deciding to split the picture or loading the second video stream, which according to the new specifications is more likely to contain a different and optionally alternate choice of content. >>>> Adding new functionality is good. Removing and replacing functionality under the assumption nobody used it, is always a bad idea. >>>> >>>> Best regards, >>>> >>>> Dorian Muthig >>>> IT & Intelligence Services >>>> Phone: +49 1522 9290158 (callerID required) >>>> Twitter: @dorianmuthig >>>> contact at dorianmuthig.com >>>> P Please consider the environment before printing this document! >>>> >>>> -----Original Message----- >>>> From: Steve Lhomme [mailto:slhomme at matroska.org] >>>> Sent: Friday, February 04, 2011 11:23 AM >>>> To: Dorian Muthig >>>> Subject: Re: multiple video streams stereo 3D mode broken >>>> >>>> Are you aware of any software that could play files the old values ? >>>> >>>> On Fri, Feb 4, 2011 at 8:53 AM, Dorian Muthig wrote: >>>>> Hello, >>>>> >>>>> >>>>> >>>>> In the new revision of the specifications in regard to the >>>>> StereoMode field there is an issue with backward compatibility. The >>>>> earlier spec defined 0 (no stereo/mono), 1 (left), 2 (right), 3 >>>>> (both). While there is no change for non-stereo content, it is no >>>>> longer possible to use two separate video streams and content >>>>> creating the format would no longer play correctly on playback >>>>> software written according to the new specifications. You should >>>>> keep the old modes and only have added the new ones for the >>>>> consumer playback formats. In production environments it is common >>>>> to keep the video streams separately (modes >>>>> 1 and 2) or to define the type of stereo mode used in the video >>>>> stream headers (mode 3). For backward compatibility those settings >>>>> should have remained as is and the new settings be amended starting >>>>> with mode 4, resulting in 14 total modes. While TrackCombinePlanes >>>>> are a solution for new content with separate video streams, they do not solve the playback problem with files muxed according to the old specification. >>>>> >>>>> >>>>> >>>>> Best regards, >>>>> >>>>> >>>>> >>>>> Dorian Muthig >>>>> >>>>> IT & Intelligence Services >>>>> >>>>> Phone: +49 1522 9290158 (callerID required) >>>>> >>>>> Twitter: @dorianmuthig >>>>> >>>>> contact at dorianmuthig.com >>>>> >>>>> P Please consider the environment before printing this document! >>>>> >>>>> >>>> >>>> >>>> >>>> -- >>>> Steve Lhomme >>>> Matroska association Chairman >>>> >>> >>> >>> >>> -- >>> Steve Lhomme >>> Matroska association Chairman >>> >> >> >> >> -- >> Steve Lhomme >> Matroska association Chairman >> > > > > -- > Steve Lhomme > Matroska association Chairman > -- Steve Lhomme Matroska association Chairman From slhomme at matroska.org Sat Feb 5 13:59:07 2011 From: slhomme at matroska.org (Steve Lhomme) Date: Sat, 5 Feb 2011 13:59:07 +0100 Subject: [Matroska-devel] Hi, question about the MKV tags In-Reply-To: <44A5FDC3001C4157B802B5CF9C94827C@JSASUS> References: <44A5FDC3001C4157B802B5CF9C94827C@JSASUS> Message-ID: On Thu, Feb 3, 2011 at 1:34 PM, Santiago Jimeno wrote: > If we want Matroska Tags are successful (up to now very little) we should > think on all aspects: file reading, tags writing when one creates the file > and edition easiness. And we should give practical solutions to all them > without preferences for none, since the end users will be who imposes their > preferences. But actually on last two aspects nobody doesn't take care. This is precisely why the case of Tags is taking particular care in the "ordering guideline". In an ideal world, tags should always be at the front. After all ID3v2 is always at the front and I haven't seen much people complain. Sometimes when you edit such files you have to rewrite the whole file. This is OK for audio files, but terrible for video files. So at least we provide the option, emphasing that whenever possible they should be at the front. Because it's easier for streaming or scanning files. > For take care on last two aspects I offered those three proposals: 1- > Appropriate Void space behind SeekHead. 2- Tags always at the end. 3- > Possibility to include Picture inside Tags besides the possibility that they > are also included in Attachments according the file target or file use. > These three proposals don't modify the global structure of the container. > Only are modified Order Guidelines on blocks location. How this to make? > It's very easy and I see for your answers that you are already beginning to > meditate on it. I will add #1 soon to the ordering guideline. #2 is not a good option #3 still thinking about it. > If they stay like they are now, I have already exposed the current > situation: ?they will always finish at the end with big empty and useless > spaces in the middle. Respecting the container norms to the maximum I don't > have more remedy than to always put Tags and Pictures at the end when I > write editing code. The best thing would be then Order Guidelines specifies > definitive positions for both blocks from the same moment of file creation, > and if they form one only block at the end would be still better. You have a good (negative) point here. Even when they are at the end, if attachments and tags are modified at the same time, you still need to update the positions in the SeekHead at the front of the file. So whether they were at the front of the back still requires the ability to edit the SeekHead. Which is the most "complex" part when having to move tags from the front to the back. > Be which is team decision, I think it's necessary to thoroughly meditate on > above-mentioned and on Order Guidelines locations. Maybe other Matroska > programmers could also give an opinion on this. I agree. > A less important question: ?Where we put LYRICS? Is it possible to add an > official SimpleTag with this Tagname? Lyrics should be a subtitle track IMO. But there should be a way to tell that a particular subtitle track is for lyrics (or karaoke). I'll have to check the specs if there's already something like that. Steve > Regards. Santiago > > ----- Original Message ----- From: "Steve Lhomme" > To: "Discussion about the current and future development of Matroska" > > Sent: Thursday, February 03, 2011 7:27 AM > Subject: Re: [Matroska-devel] Hi, question about the MKV tags > > > On Wed, Feb 2, 2011 at 11:23 PM, Santiago Jimeno wrote: >> >> Only some puntualizaci?n: >> >> Steve said: "In the system you propose, adding one byte in the existing >> tags >> would make a big empty void in the file" >> Not if they are already at the end of the file, a block is substituted for >> other and the file only increases 1 byte, without empty spaces, because >> there is not any other block at the end (a simple file append). > > Yes but again. Your reason to put it at the end is for editing. My > reason to put it at the wrong is for better reading. For example > seeking in HTTP is slow. It's much better if everything is at the > front. > >> Regarding picture structure in Attachments, anyone can realize that it's >> almost identical to APIC ID3. Here a comparison of both structures. >> >> ID3 MATROSKA >> ---- FileName >> Mime type FileMimeType >> Picture type ---- >> Description FileDescription >> Picture data FileData >> >> Lastly, as I said in my message, I only do suggestions, the decisions >> belong >> to you. Now I should work according to the current norms of the container. >> I >> will try to finish the editor when I can (I work in the one in my free >> time). >> >> Have me to the current of your opinion if you are able to install the >> program and to test it > > Not yet. I will try but I don't know when. > >> Regards. Santiago >> >> ----- Original Message ----- From: "Steve Lhomme" >> To: "Discussion about the current and future development of Matroska" >> >> Sent: Wednesday, February 02, 2011 9:09 PM >> Subject: Re: [Matroska-devel] Hi, question about the MKV tags >> >> >> On Wed, Feb 2, 2011 at 3:27 AM, Santiago Jimeno wrote: >>> >>> Thank you to accept my suggestion regarding the VOID space behind >>> SeekHead. >>> >>> Regarding installation error see you this post: >>> http://blog.colinmackay.net/archive/2007/06/21/36.aspx >>> >>> As for covertart, including it in audio files was, as you know, an idea >>> of >>> ID3 that integrated it in Tags block and with binary code. All Tags >>> systems >>> adapted as better they could this idea. Generally transcribing the same >>> APIC >>> ID3 format almost literally. >> >> But none of them had proper file attachment support. That's why they >> used this hack. >> >>> All the current systems (ID3, iTunes-MP4, WMA-ASF, APE, VORBIS) integrate >>> coverart inside the Tags block. This is fundamentally for effectiveness >>> when >>> writing and editing. There are only two exceptions FLAC and MATROSKA. >>> Sometimes WMA, if there is one Picture of big size, put it outside of the >>> Tags block. But this is due to a space problem caused by a design error >>> (there is only an Int16 to specify Data Length, with what the maximum >>> size >>> for each picture is 65535 bytes). >> >> I understand that cover art may be considered as a metadata. >> >>> FLAC works with Vorbis Comments Tags system. Previously it included >>> coverart >>> in a PICTURE block separated since Vorbis had not decided where to >>> include >>> it. When Vorbis decided to include coverart put it inside the Tags block. >>> Now FLAC can write coverart in two places: in the old place and inside >>> Vorbis Comments (??). Of course, FLAC won't change neither this as Martin >>> Leese of FLAC team told me. >>> >>> Steve said "I still don't know what's wrong with attachments as they are >>> now." >>> There is not wrong with Attachments just as they are. It's a good idea >>> for >>> streaming. But for all the other cases it's more effective and more >>> rational >>> to include them in the Tags block. When all Tags systems make it this way >>> for something will be. I only can add my suggestions for my experience >>> working with Tags. Maybe if you try to write code to edit Tags and >>> covertart >>> you coincide with me. As for the blocks location it's also ineffective to >> >> The thing is, cover art is usually for the entire segment, whereas in >> Matroska tags are often not for the whole segment. That's why I think >> it's good that it's easy and straightforward to be able to read cover >> art without having to support all the tag system. Attachments are flat >> and very easy to parse. Tags have different level and signification >> depending on some values. So anything could be easily misunderstood as >> cover art if not implemented properly. >> >>> locate them in the file middle knowing that when being edited they will >>> be >>> placed at the file end. When editing Attachments and Tags in >>> cover_art.mkv >>> file and are transferred at the file end leaves a excessive VOID space of >>> aprox. 416000 bytes (very possibly useless). On the other hand the normal >>> thing is not that the pictures are already inserted and we don't need to >>> change them, the normal thing is that there is not any and we have to put >>> them. >> >> That's actually a good point to separate the cover art in attachment >> and tags that are usually edited. In the system you propose, adding >> one byte in the existing tags would make a big empty void in the file. >> That's ugly. Like I said, cover art are rarely edited. They are either >> added or removed, but rarely modified. And as the "ordering guideline" >> suggests, there are many good reasons why all these metadata should be >> at the front whenever possible. >> >>> Steve said: "Adding binary in tags should be avoided, because it's not >>> implied how to interpret it. For pictures it could be JPEG, PNG, SVG, >>> etc. >>> Attachments have a MIME type for that, tags don't. You can notice in the >>> specs the very few formats with binary values are those with only one >>> possible format." >>> The APIC ID3 format, the same one also adopted by Matroska in >>> Attachments, >>> includes all necessary data to interpret the binary code that goes next >>> and >>> one can put it perfectly inside the Tags block. When all Tags are >>> declared >>> as UTF8 string, like in Vorbis case, what they have made with covertart >>> is >>> to translate the whole package to Base68 that is compatible with UTF8. >> >> We're certainly not going to use Base64 when our format is good at >> handling binary data. ID3 is badly designed and basically a hack over >> something missing in MP3 and then other formats. There's no reason to >> copy its flaws. >> >>> Lastly, like FLAC case, I can only do suggestions. The decisions and the >>> future of Tags depend on Matroska team if one wants that the Tags system >>> is >>> something more than a project. I'm collaborating to improve the >>> development >>> of Matroska Tags with my 'almost' completed editor (I think it's the only >>> one at the moment). But as you say at the beginning of your message: "So >>> there is just one system to deal with everything" >> >> Well, there has many many "only one moment" in the past about tag >> changes. I think we have reached a good consensus on everything that >> is possible. Maybe adding a MIME type next to binary data in tags >> could be a good move. But the recommended/default cover art should be >> in attachments in my opinion. That also makes it easier to make tools >> to scan for "files" inside matroska files if they are all in the same >> place. >> >> -- >> Steve Lhomme >> Matroska association Chairman >> _______________________________________________ >> Matroska-devel mailing list >> Matroska-devel at lists.matroska.org >> http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel >> Read Matroska-Devel on GMane: >> http://dir.gmane.org/gmane.comp.multimedia.matroska.devel >> >> >> _______________________________________________ >> Matroska-devel mailing list >> Matroska-devel at lists.matroska.org >> http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel >> Read Matroska-Devel on GMane: >> http://dir.gmane.org/gmane.comp.multimedia.matroska.devel >> > > > > -- > Steve Lhomme > Matroska association Chairman > _______________________________________________ > Matroska-devel mailing list > Matroska-devel at lists.matroska.org > http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel > Read Matroska-Devel on GMane: > http://dir.gmane.org/gmane.comp.multimedia.matroska.devel > > > _______________________________________________ > Matroska-devel mailing list > Matroska-devel at lists.matroska.org > http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel > Read Matroska-Devel on GMane: > http://dir.gmane.org/gmane.comp.multimedia.matroska.devel > -- Steve Lhomme Matroska association Chairman From contact at dorianmuthig.com Sat Feb 5 12:33:35 2011 From: contact at dorianmuthig.com (Dorian Muthig) Date: Sat, 5 Feb 2011 12:33:35 +0100 Subject: [Matroska-devel] multiple video streams stereo 3D mode broken In-Reply-To: References: <83F9BA8D634AB948A4DCAD9D2026E9740143DD089133@IBM-336-KKVZP3V.dynamicsnetwork.net> <83F9BA8D634AB948A4DCAD9D2026E9740143DD089134@IBM-336-KKVZP3V.dynamicsnetwork.net> <83F9BA8D634AB948A4DCAD9D2026E9740143DD089136@IBM-336-KKVZP3V.dynamicsnetwork.net> <83F9BA8D634AB948A4DCAD9D2026E9740143DD089138@IBM-336-KKVZP3V.dynamicsnetwork.net> Message-ID: <83F9BA8D634AB948A4DCAD9D2026E9740143E760D4B7@IBM-336-KKVZP3V.dynamicsnetwork.net> Hello, A few production solutions use a custom muxer for video stream to MKV recording with the indexes added after recording completion, but the application of choice was mostly Haali's DS Mux due to mkvmerge's problems with the VC-1 codec bitstream, some types of AVC and all types of AVS (popular in China and only used in entirely custom solutions), the unsupported tags have in that case been added later via a header and tag editor. The Matroska headers are very minimalistic in some cases and do not include the parameter for the writing application. As for the viewing angles, those are usually referenced in the track title or chapters, since there's no property in the specifications for that. More common are different aspect ratios, resolutions and video languages, which can be easily detected via the appropriate meta data and simple logic. In order to fool the detection for the old format you would have to intentionally make a file with incorrect parameters for language and aspect ratio or image size. Whilst this can occur, it is more likely that those parameters are missing and only the needed streams (left and right video plus audio) are included in one file due to laziness of the file author. Best regards, Dorian Muthig IT & Intelligence Services Phone: +49 1522 9290158 (callerID required) Twitter: @dorianmuthig contact at dorianmuthig.com ? Please consider the environment before printing this document! -----Original Message----- From: Steve Lhomme [mailto:slhomme at matroska.org] Sent: Saturday, February 05, 2011 10:58 AM To: Dorian Muthig Cc: Matroska Devel Subject: Re: multiple video streams stereo 3D mode broken Moving the discussion to the list at some other people may be interrested. On Fri, Feb 4, 2011 at 6:49 PM, Dorian Muthig wrote: > Hello, > > Whilst converting a local library to the new format wouldn't be much of a problem, for files from a remote source I still can be sure about the format used, especially since people don't usually update their muxing software regularly and stick to what they know and rely on. > The old format made sense very well. If the first or default video is a stream with stereo mode set to 1 or 2, I need to look for the second complementary stream that uses the stereo mode for the other eye. The playback software then combines the picture from both streams into a display or projector output for stereoscopic viewing. > There may not have been a large consumer space for 3D viewing at home at the time, but small production environments and 3D movie theaters have used the format due to its codec versatility. I understand. But it should not be left to guessing which track should be combined with what other. Imagine you have 2 right eye and 2 left eye tracks (for example a multi angle video). There was nothing to know which should be used. I think it's too late now to change the values again (and leave empty the fields that were used). So since such systems use a custom player, I guess they can be updated to check which mkvmerge value was used (unless they also used custom muxers). It's not much more complex than checking for a new field. Such players should also be updated to handle the new TrackOperation system too. I'll add in my TODO a tack to make the mkvmerge check and StereoMode fix. Steve > Best regards, > > Dorian Muthig > IT & Intelligence Services > Phone: +49 1522 9290158 (callerID required) > Twitter: @dorianmuthig > contact at dorianmuthig.com > P Please consider the environment before printing this document! > > > -----Original Message----- > From: Steve Lhomme [mailto:slhomme at matroska.org] > Sent: Friday, February 04, 2011 1:55 PM > To: Dorian Muthig > Subject: Re: multiple video streams stereo 3D mode broken > > If necessary If can add a feature to mkclean to turn old files into new ones, assuming they are made with older mkvmerge versions. > > The old system with one side of the stereo per track without anything to tell how they are combined is just not good. It was there as a placeholder a long time ago before we had any idea how 3D would be used. It's sad that mkvmerge presented the feature when it was really not considered stable. > > On Fri, Feb 4, 2011 at 12:37 PM, Dorian Muthig wrote: >> Hello, >> >> I was planning on updating a system to the new specifications and this caused a conflict with existing use that would render the system effectively useless upon change. >> >> Best regards, >> >> Dorian Muthig >> IT & Intelligence Services >> Phone: +49 1522 9290158 (callerID required) >> Twitter: @dorianmuthig >> contact at dorianmuthig.com >> P Please consider the environment before printing this document! >> >> >> -----Original Message----- >> From: Steve Lhomme [mailto:slhomme at matroska.org] >> Sent: Friday, February 04, 2011 12:18 PM >> To: Dorian Muthig >> Subject: Re: multiple video streams stereo 3D mode broken >> >> I know changing something that was potentially used is bad. But do you actually know a system that was using the old specs ? You seem to be talking about a system, but not that it is actually using 3D inside Matroska. >> >> According to this http://www.matroska.org/node/1/revisions the StereoMode values were changed in September 2010. >> >> On Fri, Feb 4, 2011 at 12:12 PM, Dorian Muthig wrote: >>> Hello, >>> >>> Thank you for your quick reply. >>> >>> I do not know of any consumer software, but I am aware of a few custom solutions utilizing polarized projection systems that feed separate video streams to two projectors. The problem is, files created according to the old specifications played back with software of the new specification, would discard the second video stream and display garbage on the first display. It further renders the parameters 1 through 3 for video streams of the new kind useless and requires a computationally expensive or at least inefficient way to detect the stereoscopy format. This means if I want to support both formats, I need to find additional metadata or analyze the picture before deciding to split the picture or loading the second video stream, which according to the new specifications is more likely to contain a different and optionally alternate choice of content. >>> Adding new functionality is good. Removing and replacing functionality under the assumption nobody used it, is always a bad idea. >>> >>> Best regards, >>> >>> Dorian Muthig >>> IT & Intelligence Services >>> Phone: +49 1522 9290158 (callerID required) >>> Twitter: @dorianmuthig >>> contact at dorianmuthig.com >>> P Please consider the environment before printing this document! >>> >>> -----Original Message----- >>> From: Steve Lhomme [mailto:slhomme at matroska.org] >>> Sent: Friday, February 04, 2011 11:23 AM >>> To: Dorian Muthig >>> Subject: Re: multiple video streams stereo 3D mode broken >>> >>> Are you aware of any software that could play files the old values ? >>> >>> On Fri, Feb 4, 2011 at 8:53 AM, Dorian Muthig wrote: >>>> Hello, >>>> >>>> >>>> >>>> In the new revision of the specifications in regard to the >>>> StereoMode field there is an issue with backward compatibility. The >>>> earlier spec defined 0 (no stereo/mono), 1 (left), 2 (right), 3 >>>> (both). While there is no change for non-stereo content, it is no >>>> longer possible to use two separate video streams and content >>>> creating the format would no longer play correctly on playback >>>> software written according to the new specifications. You should >>>> keep the old modes and only have added the new ones for the >>>> consumer playback formats. In production environments it is common >>>> to keep the video streams separately (modes >>>> 1 and 2) or to define the type of stereo mode used in the video >>>> stream headers (mode 3). For backward compatibility those settings >>>> should have remained as is and the new settings be amended starting >>>> with mode 4, resulting in 14 total modes. While TrackCombinePlanes >>>> are a solution for new content with separate video streams, they do not solve the playback problem with files muxed according to the old specification. >>>> >>>> >>>> >>>> Best regards, >>>> >>>> >>>> >>>> Dorian Muthig >>>> >>>> IT & Intelligence Services >>>> >>>> Phone: +49 1522 9290158 (callerID required) >>>> >>>> Twitter: @dorianmuthig >>>> >>>> contact at dorianmuthig.com >>>> >>>> P Please consider the environment before printing this document! >>>> >>>> >>> >>> >>> >>> -- >>> Steve Lhomme >>> Matroska association Chairman >>> >> >> >> >> -- >> Steve Lhomme >> Matroska association Chairman >> > > > > -- > Steve Lhomme > Matroska association Chairman > -- Steve Lhomme Matroska association Chairman -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5592 bytes Desc: not available URL: From contact at dorianmuthig.com Sat Feb 5 14:23:34 2011 From: contact at dorianmuthig.com (Dorian Muthig) Date: Sat, 5 Feb 2011 14:23:34 +0100 Subject: [Matroska-devel] multiple video streams stereo 3D mode broken In-Reply-To: References: <83F9BA8D634AB948A4DCAD9D2026E9740143DD089133@IBM-336-KKVZP3V.dynamicsnetwork.net> <83F9BA8D634AB948A4DCAD9D2026E9740143DD089134@IBM-336-KKVZP3V.dynamicsnetwork.net> <83F9BA8D634AB948A4DCAD9D2026E9740143DD089136@IBM-336-KKVZP3V.dynamicsnetwork.net> <83F9BA8D634AB948A4DCAD9D2026E9740143DD089138@IBM-336-KKVZP3V.dynamicsnetwork.net> <83F9BA8D634AB948A4DCAD9D2026E9740143E760D4B7@IBM-336-KKVZP3V.dynamicsnetwork.net> Message-ID: <83F9BA8D634AB948A4DCAD9D2026E9740143E760D4B9@IBM-336-KKVZP3V.dynamicsnetwork.net> Hello, Well, the thing is side-by-side formats are growing popular now since that's how the revised VC-1 and AVC specs are doing it to achieve better compression. This means there needs to be new playback software that supports those formats and I don't see how to do this according to the specifications, since enabling the proper support with Matroska would break the old formats. It would be much better if it were possible to implement a worry free solution. There are a few people who are unwilling to upgrade for reasons unknown, along the lines of "Why fix it, if it isn't broken?". Best regards, Dorian Muthig IT & Intelligence Services Phone: +49 1522 9290158 (callerID required) Twitter: @dorianmuthig contact at dorianmuthig.com ? Please consider the environment before printing this document! -----Original Message----- From: Steve Lhomme [mailto:slhomme at matroska.org] Sent: Saturday, February 05, 2011 1:50 PM To: Dorian Muthig Cc: Matroska Devel Subject: Re: multiple video streams stereo 3D mode broken Mm, this is embarrassing. I wish we had the info that people were actually using the StereoMode feature already. Especially now that we have release libmatroska and mkvtoolnix. Still, is there a single custom player that handles these files or many ? Can you point me to the people who are doing it ? There might be ways to work things out on the technical side. If they only support separate tracks and not side by side, then all the files they would encounter with the newer values would contain the TrackOperation element. And for old files/muxers it would be StereoMode 1 and 2. So that could be the "easy" detection. Of course this breaks if they support side by side as defined in values 1 and 2. Steve On Sat, Feb 5, 2011 at 12:33 PM, Dorian Muthig wrote: > Hello, > > A few production solutions use a custom muxer for video stream to MKV recording with the indexes added after recording completion, but the application of choice was mostly Haali's DS Mux due to mkvmerge's problems with the VC-1 codec bitstream, some types of AVC and all types of AVS (popular in China and only used in entirely custom solutions), the unsupported tags have in that case been added later via a header and tag editor. The Matroska headers are very minimalistic in some cases and do not include the parameter for the writing application. > As for the viewing angles, those are usually referenced in the track title or chapters, since there's no property in the specifications for that. More common are different aspect ratios, resolutions and video languages, which can be easily detected via the appropriate meta data and simple logic. In order to fool the detection for the old format you would have to intentionally make a file with incorrect parameters for language and aspect ratio or image size. Whilst this can occur, it is more likely that those parameters are missing and only the needed streams (left and right video plus audio) are included in one file due to laziness of the file author. > > Best regards, > > Dorian Muthig > IT & Intelligence Services > Phone: +49 1522 9290158 (callerID required) > Twitter: @dorianmuthig > contact at dorianmuthig.com > P Please consider the environment before printing this document! > > -----Original Message----- > From: Steve Lhomme [mailto:slhomme at matroska.org] > Sent: Saturday, February 05, 2011 10:58 AM > To: Dorian Muthig > Cc: Matroska Devel > Subject: Re: multiple video streams stereo 3D mode broken > > Moving the discussion to the list at some other people may be interrested. > > On Fri, Feb 4, 2011 at 6:49 PM, Dorian Muthig wrote: >> Hello, >> >> Whilst converting a local library to the new format wouldn't be much of a problem, for files from a remote source I still can be sure about the format used, especially since people don't usually update their muxing software regularly and stick to what they know and rely on. >> The old format made sense very well. If the first or default video is a stream with stereo mode set to 1 or 2, I need to look for the second complementary stream that uses the stereo mode for the other eye. The playback software then combines the picture from both streams into a display or projector output for stereoscopic viewing. >> There may not have been a large consumer space for 3D viewing at home at the time, but small production environments and 3D movie theaters have used the format due to its codec versatility. > > I understand. But it should not be left to guessing which track should be combined with what other. Imagine you have 2 right eye and 2 left eye tracks (for example a multi angle video). There was nothing to know which should be used. > > I think it's too late now to change the values again (and leave empty the fields that were used). So since such systems use a custom player, I guess they can be updated to check which mkvmerge value was used (unless they also used custom muxers). It's not much more complex than checking for a new field. Such players should also be updated to handle the new TrackOperation system too. > > I'll add in my TODO a tack to make the mkvmerge check and StereoMode fix. > > Steve > >> Best regards, >> >> Dorian Muthig >> IT & Intelligence Services >> Phone: +49 1522 9290158 (callerID required) >> Twitter: @dorianmuthig >> contact at dorianmuthig.com >> P Please consider the environment before printing this document! >> >> >> -----Original Message----- >> From: Steve Lhomme [mailto:slhomme at matroska.org] >> Sent: Friday, February 04, 2011 1:55 PM >> To: Dorian Muthig >> Subject: Re: multiple video streams stereo 3D mode broken >> >> If necessary If can add a feature to mkclean to turn old files into new ones, assuming they are made with older mkvmerge versions. >> >> The old system with one side of the stereo per track without anything to tell how they are combined is just not good. It was there as a placeholder a long time ago before we had any idea how 3D would be used. It's sad that mkvmerge presented the feature when it was really not considered stable. >> >> On Fri, Feb 4, 2011 at 12:37 PM, Dorian Muthig wrote: >>> Hello, >>> >>> I was planning on updating a system to the new specifications and this caused a conflict with existing use that would render the system effectively useless upon change. >>> >>> Best regards, >>> >>> Dorian Muthig >>> IT & Intelligence Services >>> Phone: +49 1522 9290158 (callerID required) >>> Twitter: @dorianmuthig >>> contact at dorianmuthig.com >>> P Please consider the environment before printing this document! >>> >>> >>> -----Original Message----- >>> From: Steve Lhomme [mailto:slhomme at matroska.org] >>> Sent: Friday, February 04, 2011 12:18 PM >>> To: Dorian Muthig >>> Subject: Re: multiple video streams stereo 3D mode broken >>> >>> I know changing something that was potentially used is bad. But do you actually know a system that was using the old specs ? You seem to be talking about a system, but not that it is actually using 3D inside Matroska. >>> >>> According to this http://www.matroska.org/node/1/revisions the StereoMode values were changed in September 2010. >>> >>> On Fri, Feb 4, 2011 at 12:12 PM, Dorian Muthig wrote: >>>> Hello, >>>> >>>> Thank you for your quick reply. >>>> >>>> I do not know of any consumer software, but I am aware of a few custom solutions utilizing polarized projection systems that feed separate video streams to two projectors. The problem is, files created according to the old specifications played back with software of the new specification, would discard the second video stream and display garbage on the first display. It further renders the parameters 1 through 3 for video streams of the new kind useless and requires a computationally expensive or at least inefficient way to detect the stereoscopy format. This means if I want to support both formats, I need to find additional metadata or analyze the picture before deciding to split the picture or loading the second video stream, which according to the new specifications is more likely to contain a different and optionally alternate choice of content. >>>> Adding new functionality is good. Removing and replacing functionality under the assumption nobody used it, is always a bad idea. >>>> >>>> Best regards, >>>> >>>> Dorian Muthig >>>> IT & Intelligence Services >>>> Phone: +49 1522 9290158 (callerID required) >>>> Twitter: @dorianmuthig >>>> contact at dorianmuthig.com >>>> P Please consider the environment before printing this document! >>>> >>>> -----Original Message----- >>>> From: Steve Lhomme [mailto:slhomme at matroska.org] >>>> Sent: Friday, February 04, 2011 11:23 AM >>>> To: Dorian Muthig >>>> Subject: Re: multiple video streams stereo 3D mode broken >>>> >>>> Are you aware of any software that could play files the old values ? >>>> >>>> On Fri, Feb 4, 2011 at 8:53 AM, Dorian Muthig wrote: >>>>> Hello, >>>>> >>>>> >>>>> >>>>> In the new revision of the specifications in regard to the >>>>> StereoMode field there is an issue with backward compatibility. >>>>> The earlier spec defined 0 (no stereo/mono), 1 (left), 2 (right), >>>>> 3 (both). While there is no change for non-stereo content, it is >>>>> no longer possible to use two separate video streams and content >>>>> creating the format would no longer play correctly on playback >>>>> software written according to the new specifications. You should >>>>> keep the old modes and only have added the new ones for the >>>>> consumer playback formats. In production environments it is common >>>>> to keep the video streams separately (modes >>>>> 1 and 2) or to define the type of stereo mode used in the video >>>>> stream headers (mode 3). For backward compatibility those settings >>>>> should have remained as is and the new settings be amended >>>>> starting with mode 4, resulting in 14 total modes. While >>>>> TrackCombinePlanes are a solution for new content with separate video streams, they do not solve the playback problem with files muxed according to the old specification. >>>>> >>>>> >>>>> >>>>> Best regards, >>>>> >>>>> >>>>> >>>>> Dorian Muthig >>>>> >>>>> IT & Intelligence Services >>>>> >>>>> Phone: +49 1522 9290158 (callerID required) >>>>> >>>>> Twitter: @dorianmuthig >>>>> >>>>> contact at dorianmuthig.com >>>>> >>>>> P Please consider the environment before printing this document! >>>>> >>>>> >>>> >>>> >>>> >>>> -- >>>> Steve Lhomme >>>> Matroska association Chairman >>>> >>> >>> >>> >>> -- >>> Steve Lhomme >>> Matroska association Chairman >>> >> >> >> >> -- >> Steve Lhomme >> Matroska association Chairman >> > > > > -- > Steve Lhomme > Matroska association Chairman > -- Steve Lhomme Matroska association Chairman -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5592 bytes Desc: not available URL: From sjimeno at ya.com Sat Feb 5 17:28:25 2011 From: sjimeno at ya.com (Santiago Jimeno) Date: Sat, 5 Feb 2011 17:28:25 +0100 Subject: [Matroska-devel] Hi, question about the MKV tags In-Reply-To: References: <44A5FDC3001C4157B802B5CF9C94827C@JSASUS> Message-ID: <5D55D5E45DD1438DB62E4955305BC62B@JSASUS> In the first place I should clarify some things: I am writing a tag editor for all systems of existent Tags and Matroska tags is only one of them. The link I put to MatroskaFileList contains only an extract (some classes) of the whole editor. I don't have in Matroska Tags a special interest. I have the same interest that with any other Tags system (I don't have preferences). I wrote indicating, mistaken or not, what I proposed to improve the Tags edition. But the decision corresponds to Matroska team that are who can want a bigger success for the Tags. If Matroska Tags is successful I will maintain the edition in my program, anyone are the norms. If they are not successful I will remove it. For your tranquility I already commented the problems of FLAC and WMA-ASF. WMA-ASF write Tags and Pictures in 5 file blocks different. An complete example of complexity. None of my messages contained personal criticizes and my opinions were based on data of my experience. I don't have necessity to support personal comments and without arguments of somebody as the such Boris that doesn't know me of anything. For that reason, if you have some interest in continuing talking about this topic I suggest that we pass to private messages. As for your message. I don't have problem if Tags or Attachments are at the front or at the end. But they are really at file middle and this is what originates big empty spaces and other problems. So if they are really at front it will be necessary to take them out of Segment and to put them in Header block to make them independent of Cluster blokcs. But this will vary the current structure of the container, with incompatibilty back or al least important changes. For that reason I insisted on putting them at end (that doesn't modify the container structure) and not for any other interest. But in spite of the flexibility, the best thing as much for reading than for writing is to always find the blocks in the same place. If Tags continues at file middle it will be necessary to endow them of the appropriate padding, like in SeekHead. But which is the appropriate padding to add Pictures at Segment middle? One megabyte or more? There is not problem to write SeekHead if there is space void behind. All the systems of Tags demand some modification type when being edited (blocks size, Seekhead or what they request) and in some cases a simple word modification supposes to write sizes in multiple places. But anyway writing SeekHead is not complex. I change its content in a dynamic way during the edition. Then, when concluding it's only necessary to write Seek block on its place (if there is space void like in mkvmerge, or even smaller void size). As for LYRICS there is two posiblidades. To show them in real time and this would be a subtitle in a player. As my program it's not a player I only think about to add it like TagString in a SimpleTag and with TargetType = 30 (track). Regards. Santiago ----- Original Message ----- From: "Steve Lhomme" To: "Discussion about the current and future development of Matroska" Sent: Saturday, February 05, 2011 1:59 PM Subject: Re: [Matroska-devel] Hi, question about the MKV tags On Thu, Feb 3, 2011 at 1:34 PM, Santiago Jimeno wrote: > If we want Matroska Tags are successful (up to now very little) we should > think on all aspects: file reading, tags writing when one creates the file > and edition easiness. And we should give practical solutions to all them > without preferences for none, since the end users will be who imposes > their > preferences. But actually on last two aspects nobody doesn't take care. This is precisely why the case of Tags is taking particular care in the "ordering guideline". In an ideal world, tags should always be at the front. After all ID3v2 is always at the front and I haven't seen much people complain. Sometimes when you edit such files you have to rewrite the whole file. This is OK for audio files, but terrible for video files. So at least we provide the option, emphasing that whenever possible they should be at the front. Because it's easier for streaming or scanning files. > For take care on last two aspects I offered those three proposals: 1- > Appropriate Void space behind SeekHead. 2- Tags always at the end. 3- > Possibility to include Picture inside Tags besides the possibility that > they > are also included in Attachments according the file target or file use. > These three proposals don't modify the global structure of the container. > Only are modified Order Guidelines on blocks location. How this to make? > It's very easy and I see for your answers that you are already beginning > to > meditate on it. I will add #1 soon to the ordering guideline. #2 is not a good option #3 still thinking about it. > If they stay like they are now, I have already exposed the current > situation: they will always finish at the end with big empty and useless > spaces in the middle. Respecting the container norms to the maximum I > don't > have more remedy than to always put Tags and Pictures at the end when I > write editing code. The best thing would be then Order Guidelines > specifies > definitive positions for both blocks from the same moment of file > creation, > and if they form one only block at the end would be still better. You have a good (negative) point here. Even when they are at the end, if attachments and tags are modified at the same time, you still need to update the positions in the SeekHead at the front of the file. So whether they were at the front of the back still requires the ability to edit the SeekHead. Which is the most "complex" part when having to move tags from the front to the back. > Be which is team decision, I think it's necessary to thoroughly meditate > on > above-mentioned and on Order Guidelines locations. Maybe other Matroska > programmers could also give an opinion on this. I agree. > A less important question: Where we put LYRICS? Is it possible to add an > official SimpleTag with this Tagname? Lyrics should be a subtitle track IMO. But there should be a way to tell that a particular subtitle track is for lyrics (or karaoke). I'll have to check the specs if there's already something like that. Steve > Regards. Santiago > > ----- Original Message ----- From: "Steve Lhomme" > To: "Discussion about the current and future development of Matroska" > > Sent: Thursday, February 03, 2011 7:27 AM > Subject: Re: [Matroska-devel] Hi, question about the MKV tags > > > On Wed, Feb 2, 2011 at 11:23 PM, Santiago Jimeno wrote: >> >> Only some puntualizaci?n: >> >> Steve said: "In the system you propose, adding one byte in the existing >> tags >> would make a big empty void in the file" >> Not if they are already at the end of the file, a block is substituted >> for >> other and the file only increases 1 byte, without empty spaces, because >> there is not any other block at the end (a simple file append). > > Yes but again. Your reason to put it at the end is for editing. My > reason to put it at the wrong is for better reading. For example > seeking in HTTP is slow. It's much better if everything is at the > front. > >> Regarding picture structure in Attachments, anyone can realize that it's >> almost identical to APIC ID3. Here a comparison of both structures. >> >> ID3 MATROSKA >> ---- FileName >> Mime type FileMimeType >> Picture type ---- >> Description FileDescription >> Picture data FileData >> >> Lastly, as I said in my message, I only do suggestions, the decisions >> belong >> to you. Now I should work according to the current norms of the >> container. >> I >> will try to finish the editor when I can (I work in the one in my free >> time). >> >> Have me to the current of your opinion if you are able to install the >> program and to test it > > Not yet. I will try but I don't know when. > >> Regards. Santiago >> >> ----- Original Message ----- From: "Steve Lhomme" >> To: "Discussion about the current and future development of Matroska" >> >> Sent: Wednesday, February 02, 2011 9:09 PM >> Subject: Re: [Matroska-devel] Hi, question about the MKV tags >> >> >> On Wed, Feb 2, 2011 at 3:27 AM, Santiago Jimeno wrote: >>> >>> Thank you to accept my suggestion regarding the VOID space behind >>> SeekHead. >>> >>> Regarding installation error see you this post: >>> http://blog.colinmackay.net/archive/2007/06/21/36.aspx >>> >>> As for covertart, including it in audio files was, as you know, an idea >>> of >>> ID3 that integrated it in Tags block and with binary code. All Tags >>> systems >>> adapted as better they could this idea. Generally transcribing the same >>> APIC >>> ID3 format almost literally. >> >> But none of them had proper file attachment support. That's why they >> used this hack. >> >>> All the current systems (ID3, iTunes-MP4, WMA-ASF, APE, VORBIS) >>> integrate >>> coverart inside the Tags block. This is fundamentally for effectiveness >>> when >>> writing and editing. There are only two exceptions FLAC and MATROSKA. >>> Sometimes WMA, if there is one Picture of big size, put it outside of >>> the >>> Tags block. But this is due to a space problem caused by a design error >>> (there is only an Int16 to specify Data Length, with what the maximum >>> size >>> for each picture is 65535 bytes). >> >> I understand that cover art may be considered as a metadata. >> >>> FLAC works with Vorbis Comments Tags system. Previously it included >>> coverart >>> in a PICTURE block separated since Vorbis had not decided where to >>> include >>> it. When Vorbis decided to include coverart put it inside the Tags >>> block. >>> Now FLAC can write coverart in two places: in the old place and inside >>> Vorbis Comments (??). Of course, FLAC won't change neither this as >>> Martin >>> Leese of FLAC team told me. >>> >>> Steve said "I still don't know what's wrong with attachments as they are >>> now." >>> There is not wrong with Attachments just as they are. It's a good idea >>> for >>> streaming. But for all the other cases it's more effective and more >>> rational >>> to include them in the Tags block. When all Tags systems make it this >>> way >>> for something will be. I only can add my suggestions for my experience >>> working with Tags. Maybe if you try to write code to edit Tags and >>> covertart >>> you coincide with me. As for the blocks location it's also ineffective >>> to >> >> The thing is, cover art is usually for the entire segment, whereas in >> Matroska tags are often not for the whole segment. That's why I think >> it's good that it's easy and straightforward to be able to read cover >> art without having to support all the tag system. Attachments are flat >> and very easy to parse. Tags have different level and signification >> depending on some values. So anything could be easily misunderstood as >> cover art if not implemented properly. >> >>> locate them in the file middle knowing that when being edited they will >>> be >>> placed at the file end. When editing Attachments and Tags in >>> cover_art.mkv >>> file and are transferred at the file end leaves a excessive VOID space >>> of >>> aprox. 416000 bytes (very possibly useless). On the other hand the >>> normal >>> thing is not that the pictures are already inserted and we don't need to >>> change them, the normal thing is that there is not any and we have to >>> put >>> them. >> >> That's actually a good point to separate the cover art in attachment >> and tags that are usually edited. In the system you propose, adding >> one byte in the existing tags would make a big empty void in the file. >> That's ugly. Like I said, cover art are rarely edited. They are either >> added or removed, but rarely modified. And as the "ordering guideline" >> suggests, there are many good reasons why all these metadata should be >> at the front whenever possible. >> >>> Steve said: "Adding binary in tags should be avoided, because it's not >>> implied how to interpret it. For pictures it could be JPEG, PNG, SVG, >>> etc. >>> Attachments have a MIME type for that, tags don't. You can notice in the >>> specs the very few formats with binary values are those with only one >>> possible format." >>> The APIC ID3 format, the same one also adopted by Matroska in >>> Attachments, >>> includes all necessary data to interpret the binary code that goes next >>> and >>> one can put it perfectly inside the Tags block. When all Tags are >>> declared >>> as UTF8 string, like in Vorbis case, what they have made with covertart >>> is >>> to translate the whole package to Base68 that is compatible with UTF8. >> >> We're certainly not going to use Base64 when our format is good at >> handling binary data. ID3 is badly designed and basically a hack over >> something missing in MP3 and then other formats. There's no reason to >> copy its flaws. >> >>> Lastly, like FLAC case, I can only do suggestions. The decisions and the >>> future of Tags depend on Matroska team if one wants that the Tags system >>> is >>> something more than a project. I'm collaborating to improve the >>> development >>> of Matroska Tags with my 'almost' completed editor (I think it's the >>> only >>> one at the moment). But as you say at the beginning of your message: "So >>> there is just one system to deal with everything" >> >> Well, there has many many "only one moment" in the past about tag >> changes. I think we have reached a good consensus on everything that >> is possible. Maybe adding a MIME type next to binary data in tags >> could be a good move. But the recommended/default cover art should be >> in attachments in my opinion. That also makes it easier to make tools >> to scan for "files" inside matroska files if they are all in the same >> place. >> >> -- >> Steve Lhomme >> Matroska association Chairman >> _______________________________________________ >> Matroska-devel mailing list >> Matroska-devel at lists.matroska.org >> http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel >> Read Matroska-Devel on GMane: >> http://dir.gmane.org/gmane.comp.multimedia.matroska.devel >> >> >> _______________________________________________ >> Matroska-devel mailing list >> Matroska-devel at lists.matroska.org >> http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel >> Read Matroska-Devel on GMane: >> http://dir.gmane.org/gmane.comp.multimedia.matroska.devel >> > > > > -- > Steve Lhomme > Matroska association Chairman > _______________________________________________ > Matroska-devel mailing list > Matroska-devel at lists.matroska.org > http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel > Read Matroska-Devel on GMane: > http://dir.gmane.org/gmane.comp.multimedia.matroska.devel > > > _______________________________________________ > Matroska-devel mailing list > Matroska-devel at lists.matroska.org > http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel > Read Matroska-Devel on GMane: > http://dir.gmane.org/gmane.comp.multimedia.matroska.devel > -- Steve Lhomme Matroska association Chairman _______________________________________________ Matroska-devel mailing list Matroska-devel at lists.matroska.org http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel Read Matroska-Devel on GMane: http://dir.gmane.org/gmane.comp.multimedia.matroska.devel From slhomme at matroska.org Sat Feb 5 18:16:14 2011 From: slhomme at matroska.org (Steve Lhomme) Date: Sat, 5 Feb 2011 18:16:14 +0100 Subject: [Matroska-devel] Hi, question about the MKV tags In-Reply-To: <5D55D5E45DD1438DB62E4955305BC62B@JSASUS> References: <44A5FDC3001C4157B802B5CF9C94827C@JSASUS> <5D55D5E45DD1438DB62E4955305BC62B@JSASUS> Message-ID: On Sat, Feb 5, 2011 at 5:28 PM, Santiago Jimeno wrote: > I wrote indicating, mistaken or not, what I proposed to improve the Tags > edition. But the decision corresponds to Matroska team that are who can want > a bigger success for the Tags. If Matroska Tags is successful I will > maintain the edition in my program, anyone are the norms. If they are not > successful I will remove it. For your tranquility I already commented the > problems of FLAC and WMA-ASF. WMA-ASF write Tags and Pictures in 5 file > blocks different. An complete example of complexity. > None of my messages contained personal criticizes and my opinions were based > on data of my experience. I don't have necessity to support personal > comments and without arguments of somebody as the such Boris that doesn't > know me of anything. > For that reason, if you have some interest in continuing talking about this > topic I suggest that we pass to private messages. I agree, no need to go to the personal level. But technical discussions have to be done publicly whenever possible, to make sure all that have an opinion can express in time. (the recent problem with StereoMode changes is a good example of something that could have been avoided with more public talks) > There is not problem to write SeekHead if there is space void behind. All > the systems of Tags demand some modification type when being edited (blocks > size, Seekhead or what they request) and in some cases a simple word > modification supposes to write sizes in multiple places. But anyway writing > SeekHead is not complex. I change its content in a dynamic way during the > edition. Then, when concluding it's only necessary to write Seek block on > its place (if there is space void like in mkvmerge, or even smaller void > size). Yes, I will change the specs to make sure it's clear that padding after SeekHead is recommended (even for things that don't even exist yet in Matroska). > As for LYRICS there is two posiblidades. To show them in real time and this > would be a subtitle in a player. As my program it's not a player I only > think about to add it like TagString in a SimpleTag and with TargetType = 30 > (track). I'd rather keep it as synchronized, because that's the best way to use it. One thing I hate is when the same information is found twice in a file. Because if one is changed, the other is unlikely to be fixed. Plus it takes more space. Same reason why I prefer cover art in one place and not 2 possible (and since cover art is already common as attachment, that mode has to prevail). But for lyrics I guess it could be put in tags too, because adding the syncrhonisation info is a lot of work and will never happen in basic tag editors. So I will add an "entity" in the tags specification. Steve From slhomme at matroska.org Sat Feb 5 18:22:29 2011 From: slhomme at matroska.org (Steve Lhomme) Date: Sat, 5 Feb 2011 18:22:29 +0100 Subject: [Matroska-devel] Hi, question about the MKV tags In-Reply-To: References: <44A5FDC3001C4157B802B5CF9C94827C@JSASUS> <5D55D5E45DD1438DB62E4955305BC62B@JSASUS> Message-ID: On Sat, Feb 5, 2011 at 6:16 PM, Steve Lhomme wrote: > On Sat, Feb 5, 2011 at 5:28 PM, Santiago Jimeno wrote: >> As for LYRICS there is two posiblidades. To show them in real time and this >> would be a subtitle in a player. As my program it's not a player I only >> think about to add it like TagString in a SimpleTag and with TargetType = 30 >> (track). > > I'd rather keep it as synchronized, because that's the best way to use > it. One thing I hate is when the same information is found twice in a > file. Because if one is changed, the other is unlikely to be fixed. > Plus it takes more space. Same reason why I prefer cover art in one > place and not 2 possible (and since cover art is already common as > attachment, that mode has to prevail). But for lyrics I guess it could > be put in tags too, because adding the syncrhonisation info is a lot > of work and will never happen in basic tag editors. So I will add an > "entity" in the tags specification. Done -- Steve Lhomme Matroska association Chairman From slhomme at matroska.org Sat Feb 5 18:26:14 2011 From: slhomme at matroska.org (Steve Lhomme) Date: Sat, 5 Feb 2011 18:26:14 +0100 Subject: [Matroska-devel] Hi, question about the MKV tags In-Reply-To: References: <44A5FDC3001C4157B802B5CF9C94827C@JSASUS> Message-ID: On Sat, Feb 5, 2011 at 1:59 PM, Steve Lhomme wrote: > On Thu, Feb 3, 2011 at 1:34 PM, Santiago Jimeno wrote: >> For take care on last two aspects I offered those three proposals: 1- >> Appropriate Void space behind SeekHead. 2- Tags always at the end. 3- >> Possibility to include Picture inside Tags besides the possibility that they >> are also included in Attachments according the file target or file use. >> These three proposals don't modify the global structure of the container. >> Only are modified Order Guidelines on blocks location. How this to make? >> It's very easy and I see for your answers that you are already beginning to >> meditate on it. > > I will add #1 soon to the ordering guideline. Done -- Steve Lhomme Matroska association Chairman From boris.juraga at gmail.com Sat Feb 5 19:02:28 2011 From: boris.juraga at gmail.com (Boris Juraga) Date: Sat, 5 Feb 2011 19:02:28 +0100 Subject: [Matroska-devel] Hi, question about the MKV tags In-Reply-To: References: <44A5FDC3001C4157B802B5CF9C94827C@JSASUS> Message-ID: To Santiago: I hope you did not get offended -- it was not my goal. But i second Steve that all technical conversations are to be public, and i am building a lot of tools for Matroska currently for my own needs but when done i will publish them and i too care about this format. Unlike you, i have selected to work only with Matroska files exclusive (my preference), as they are the only ones versatile enough (for me) to what i need (all metadata and covers and subtitles and whatnot inside the file). I am here to express support to this container and make my contribution to it. Some specifications are there for a reason, there are ones that dont suit me -- but suit the wider audience so i accept them. As Steve already made changes to the Ordering guide i can only hope all Matroska file creators will adopt, and the seek head will be "faster" to edit. I am currently thinking about such space after my tags so i can edit them too (in my case i like to place them at he front). Still thinking of how much void to place after tags. You see if you allow images to be placed inside the tags only one thing will come out of it -- The tags are going to get exponentially bigger and there will be no way to edit them in the current position but you will have to place them at the end or remux he whole file. This will be the culprit for empty holes all over the file, not the current specifications. If anyone has anything to say or add please feel free to do it here From sjimeno at ya.com Sat Feb 5 19:39:18 2011 From: sjimeno at ya.com (Santiago Jimeno) Date: Sat, 5 Feb 2011 19:39:18 +0100 Subject: [Matroska-devel] Hi, question about the MKV tags In-Reply-To: References: <44A5FDC3001C4157B802B5CF9C94827C@JSASUS><5D55D5E45DD1438DB62E4955305BC62B@JSASUS> Message-ID: > I agree, no need to go to the personal level. But technical > discussions have to be done publicly whenever possible, to make sure > all that have an opinion can express in time. (the recent problem with > StereoMode changes is a good example of something that could have been > avoided with more public talks) OK. I don't have problem. > Yes, I will change the specs to make sure it's clear that padding > after SeekHead is recommended (even for things that don't even exist > yet in Matroska). Thank you. It would be fine to warn to authors personally. I have only found problems in example files (cover_art.mkv), in those of Haali (puts only 14 bytes), and mkvmerge only in 4.0.0 and 4.1.1 versions (Test 1 samples) Maybe it would also be necessary to specify advisable size. Mkvmerge uses 4000 (maybe for including all cluster blocks). I have calculated that all master elements (included first cluster location, I think it's the only one truly necessary here) will have a size something smaller than 400 bytes. > But for lyrics I guess it could > be put in tags too, because adding the syncrhonisation info is a lot > of work and will never happen in basic tag editors. So I will add an > "entity" in the tags specification. I agree. Thank you again. Let's me to know your decisions in other fields. The two pending aspects need something more meditation. Tell me if I can help on some aspect.. Finishing my program will take me some time. I will add it to the link when I can. Regards. Santiago ----- Original Message ----- From: "Steve Lhomme" To: "Discussion about the current and future development of Matroska" Sent: Saturday, February 05, 2011 6:16 PM Subject: Re: [Matroska-devel] Hi, question about the MKV tags > On Sat, Feb 5, 2011 at 5:28 PM, Santiago Jimeno wrote: >> I wrote indicating, mistaken or not, what I proposed to improve the Tags >> edition. But the decision corresponds to Matroska team that are who can >> want >> a bigger success for the Tags. If Matroska Tags is successful I will >> maintain the edition in my program, anyone are the norms. If they are not >> successful I will remove it. For your tranquility I already commented the >> problems of FLAC and WMA-ASF. WMA-ASF write Tags and Pictures in 5 file >> blocks different. An complete example of complexity. >> None of my messages contained personal criticizes and my opinions were >> based >> on data of my experience. I don't have necessity to support personal >> comments and without arguments of somebody as the such Boris that doesn't >> know me of anything. >> For that reason, if you have some interest in continuing talking about >> this >> topic I suggest that we pass to private messages. > > I agree, no need to go to the personal level. But technical > discussions have to be done publicly whenever possible, to make sure > all that have an opinion can express in time. (the recent problem with > StereoMode changes is a good example of something that could have been > avoided with more public talks) > >> There is not problem to write SeekHead if there is space void behind. All >> the systems of Tags demand some modification type when being edited >> (blocks >> size, Seekhead or what they request) and in some cases a simple word >> modification supposes to write sizes in multiple places. But anyway >> writing >> SeekHead is not complex. I change its content in a dynamic way during the >> edition. Then, when concluding it's only necessary to write Seek block on >> its place (if there is space void like in mkvmerge, or even smaller void >> size). > > Yes, I will change the specs to make sure it's clear that padding > after SeekHead is recommended (even for things that don't even exist > yet in Matroska). > >> As for LYRICS there is two posiblidades. To show them in real time and >> this >> would be a subtitle in a player. As my program it's not a player I only >> think about to add it like TagString in a SimpleTag and with TargetType = >> 30 >> (track). > > I'd rather keep it as synchronized, because that's the best way to use > it. One thing I hate is when the same information is found twice in a > file. Because if one is changed, the other is unlikely to be fixed. > Plus it takes more space. Same reason why I prefer cover art in one > place and not 2 possible (and since cover art is already common as > attachment, that mode has to prevail). But for lyrics I guess it could > be put in tags too, because adding the syncrhonisation info is a lot > of work and will never happen in basic tag editors. So I will add an > "entity" in the tags specification. > > Steve > _______________________________________________ > Matroska-devel mailing list > Matroska-devel at lists.matroska.org > http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel > Read Matroska-Devel on GMane: > http://dir.gmane.org/gmane.comp.multimedia.matroska.devel > From slhomme at matroska.org Mon Feb 7 08:51:43 2011 From: slhomme at matroska.org (Steve Lhomme) Date: Mon, 7 Feb 2011 08:51:43 +0100 Subject: [Matroska-devel] Hi, question about the MKV tags In-Reply-To: References: <44A5FDC3001C4157B802B5CF9C94827C@JSASUS> <5D55D5E45DD1438DB62E4955305BC62B@JSASUS> Message-ID: On Sat, Feb 5, 2011 at 7:39 PM, Santiago Jimeno wrote: >> Yes, I will change the specs to make sure it's clear that padding >> after SeekHead is recommended (even for things that don't even exist >> yet in Matroska). > > Thank you. It would be fine to warn to authors personally. > I have only found problems in example files (cover_art.mkv), in those of > Haali (puts only 14 bytes), and mkvmerge only in 4.0.0 and 4.1.1 versions > (Test 1 samples) OK, I will first update mkclean to leave more space (right now there's only space for one element). And then I will make a test1 bis. I have a list of other features I have to put in a new test suite too. > Maybe it would also be necessary to specify advisable size. Mkvmerge uses > 4000 (maybe for including all cluster blocks). That's probably too much. > I have calculated that all master elements (included first cluster location, > I think it's the only one truly necessary here) will have a size something > smaller than 400 bytes. Yes. Right now mkclean leaves room for 1 link at the end. I should probably be safer with 3 or 4. I suppose tags at the front could do with a bit of padding too for easier editing without have to move it to the end or move all the data in the file. -- Steve Lhomme Matroska association Chairman From slhomme at matroska.org Mon Feb 7 08:56:33 2011 From: slhomme at matroska.org (Steve Lhomme) Date: Mon, 7 Feb 2011 08:56:33 +0100 Subject: [Matroska-devel] StereoMode Message-ID: Hi everyone, It seems we (I) went a little fast on the StereoMode value changes. It turns out some systems were already using the 3D Matroska system in place before. Even though it was just experimental and not really satisfactory (no way to link 2 tracks together to tell they form the 3D planes). So we either need to update the recently updated values, or simply add a Matroska v3 which would include StereoMode and TrackOperation. This way it's easy to detect systems that were using the old values. I will then add a link in the specs to explain what the v2 values where and why it changed. Opinions ? I already published a news about the issue here: http://www.matroska.org/news/stereomode.html -- Steve Lhomme Matroska association Chairman From sjimeno at ya.com Mon Feb 7 13:56:09 2011 From: sjimeno at ya.com (Santiago Jimeno) Date: Mon, 7 Feb 2011 13:56:09 +0100 Subject: [Matroska-devel] Hi, question about the MKV tags In-Reply-To: References: <44A5FDC3001C4157B802B5CF9C94827C@JSASUS><5D55D5E45DD1438DB62E4955305BC62B@JSASUS> Message-ID: <19C1440BEA2C40C785856F9C6E1666C9@JSASUS> As for SeekHead: The maximum size of one entry is 17 bytes without CRC or 21 bytes with CRC. The possible entries are: -SegmentInfo -Track -Chapters -Attachments -Tags -Cueing -First Cluster I think it would be good to put First Cluster location here. This would provide us a complete file map and their positions and we could go to them without parsing whole file. We could also calculate easily the size of each master element. It's not necessary to specify all cluster blocks location here. Cueing is for this. Then the minimum size would be 21 x 7 = 147. But I would put padding with bigger size for the future (among 200-300 bytes). As for Tags-Pictures there are three ways of placing them: at the beginning of the file (ID3.2), at the end (APE, WAV) or at the middle (iTunes, Vorbis, WMA, Matroska). Anyway to avoid problems (with or without padding) the best thing would be to make them independent of Media Data. Some Tags systems solve it dividing the file in two parts. Header, metadata and other information blocks in one file part and Media Data in the other file part. In the case of Matroska when being at the middle, inside Segment and before Cluster, does these last ones being too sensitive to the variations or modifications before. The solution of declaring Void the modified blocks originates empty spaces with little utility and increases the file size. Moving them at the end becomes contradictory the Order Guidelines for fixing a definitive position that an Editor can find easily. The padding addiction in Tags is a possible solution (if this may be guaranteed in the future), but then the biggest problem for its great size is caused by Attachments (Pictures). If a program write matroska file for the first time all elements and their positions only depend on the author's will. But modifying or editing should foresee all possibilities and any other thing that multiple authors can imagine. This is the difficulty that I pointed out and not my limitations, although maybe I have them. Then it's necessary to evaluate the three ways of Tags and Attachments placement and which would be more useful in function of the better container design. Placed at the beginning, it should be outside Segment, like Header's child. Our limit cannot be to have to rewrite the whole file. Mkvmerge specifies how many time takes to build file (Audio and Video) and in all cases it supposes more or less 1 second. This, with the modern computers, is perfectly acceptable even also for edition. Placed at the end, I have already explained the possible advantages (even inside the segment) and writing is very easy. Placed inside Segment and before Cluster, I have also explained the problems. Placed after Cluster, it's the same that placed at the end. Regards. Santiago ----- Original Message ----- From: "Steve Lhomme" To: "Discussion about the current and future development of Matroska" Sent: Monday, February 07, 2011 8:51 AM Subject: Re: [Matroska-devel] Hi, question about the MKV tags > On Sat, Feb 5, 2011 at 7:39 PM, Santiago Jimeno wrote: >>> Yes, I will change the specs to make sure it's clear that padding >>> after SeekHead is recommended (even for things that don't even exist >>> yet in Matroska). >> >> Thank you. It would be fine to warn to authors personally. >> I have only found problems in example files (cover_art.mkv), in those of >> Haali (puts only 14 bytes), and mkvmerge only in 4.0.0 and 4.1.1 versions >> (Test 1 samples) > > OK, I will first update mkclean to leave more space (right now there's > only space for one element). And then I will make a test1 bis. I have > a list of other features I have to put in a new test suite too. > >> Maybe it would also be necessary to specify advisable size. Mkvmerge uses >> 4000 (maybe for including all cluster blocks). > > That's probably too much. > >> I have calculated that all master elements (included first cluster >> location, >> I think it's the only one truly necessary here) will have a size >> something >> smaller than 400 bytes. > > Yes. Right now mkclean leaves room for 1 link at the end. I should > probably be safer with 3 or 4. I suppose tags at the front could do > with a bit of padding too for easier editing without have to move it > to the end or move all the data in the file. > > > -- > Steve Lhomme > Matroska association Chairman > _______________________________________________ > Matroska-devel mailing list > Matroska-devel at lists.matroska.org > http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel > Read Matroska-Devel on GMane: > http://dir.gmane.org/gmane.comp.multimedia.matroska.devel > From boris.juraga at gmail.com Mon Feb 7 14:45:34 2011 From: boris.juraga at gmail.com (Boris Juraga) Date: Mon, 7 Feb 2011 14:45:34 +0100 Subject: [Matroska-devel] Hi, question about the MKV tags In-Reply-To: <19C1440BEA2C40C785856F9C6E1666C9@JSASUS> References: <44A5FDC3001C4157B802B5CF9C94827C@JSASUS> <5D55D5E45DD1438DB62E4955305BC62B@JSASUS> <19C1440BEA2C40C785856F9C6E1666C9@JSASUS> Message-ID: There is allot activity here about the tags finally. I can only give you few proposals of mine too. While working with the tags, attachments, reading, writing and whatnot i have made few conclusions of mine: 1. By far the most susceptible to change are indeed the tags and as they are much smaller than even one cover art, it will not hurt much the file to either write them in the most optimal location -> early in the file and add few (2,3,4)KB of void after them, and enough after the seekhead for few additions to it. 2. Even if after this optimum tags layout left you needing more space than the one provided in case 1. , void them and move them to the back (for example batch editing tags for allot of mkv's that did not had tags and were not optimized by case 1.), or remux the file and adding another 2,3,4 kB void space after them -- depending on the author of the app and the scenario, even pop up a message box to ask for preference. 3. Attachments are always a big deal, so in my opinion it is normal to remux the file after adding lets say 4 cover art images in total of one megabyte or even more (someone will add 1080pixels images) so i would suggest remuxing after this. 4. In case 3. if you remux the file it wont hurt you to make sure about the tags by following the case 1. so you get 2 good things . This are just proposals and i am interested in opinions on them. So far i am thinking to use this algorithm in my tag\attachment editor, so if i miss on something here feel free to contribute From boris.juraga at gmail.com Mon Feb 7 14:50:51 2011 From: boris.juraga at gmail.com (Boris Juraga) Date: Mon, 7 Feb 2011 14:50:51 +0100 Subject: [Matroska-devel] Hi, question about the MKV tags In-Reply-To: References: <44A5FDC3001C4157B802B5CF9C94827C@JSASUS> <5D55D5E45DD1438DB62E4955305BC62B@JSASUS> <19C1440BEA2C40C785856F9C6E1666C9@JSASUS> Message-ID: P.S. can there be some default tags entered in the ront of the file the first time the mkv is created? With tools like mkvmerge and similar? like this draft below? TITLE and the void space ? From sjimeno at ya.com Thu Feb 10 12:10:03 2011 From: sjimeno at ya.com (Santiago Jimeno) Date: Thu, 10 Feb 2011 12:10:03 +0100 Subject: [Matroska-devel] Hi, question about the MKV tags In-Reply-To: References: <44A5FDC3001C4157B802B5CF9C94827C@JSASUS><5D55D5E45DD1438DB62E4955305BC62B@JSASUS> Message-ID: <3E923FEEF3674EEF9F7E0D1480B3BF7A@JSASUS> >> Yes, I will change the specs to make sure it's clear that padding >> after SeekHead is recommended (even for things that don't even exist >> yet in Matroska). > OK, I will first update mkclean to leave more space (right now there's > only space for one element). Testing files I see there are two possibilities to put space: - After SeekHead (This is what mkvmerge does ), as Segment child - Inside SeekHead at the end How do you plan to put it?. On the other hand, in the same test I have found that there is apps that invert the elements placement in SeekHead and Tags In Tags (TagString before TagName) and in Seek (SEEKPOSITION before SEEKID) Example of AVI-Mux GUI : http://samples.mplayerhq.hu/Matroska/Mushishi24-head.mkv I know there is not a fixed elements order, but is it of common sense to do this in these cases?. Should we give as valid this fact or to ignore Tags data? My battery of samples is small for tests. Would I be able to get several more? Regards. Santiag From moritz at bunkus.org Thu Feb 10 12:15:14 2011 From: moritz at bunkus.org (Moritz Bunkus) Date: Thu, 10 Feb 2011 12:15:14 +0100 Subject: [Matroska-devel] Hi, question about the MKV tags In-Reply-To: <3E923FEEF3674EEF9F7E0D1480B3BF7A@JSASUS> References: <3E923FEEF3674EEF9F7E0D1480B3BF7A@JSASUS> Message-ID: <201102101215.14859.moritz@bunkus.org> Hey, On Thursday 10 February 2011 12:10:03 Santiago Jimeno wrote: > I know there is not a fixed elements order, but is it of common sense > to do this in these cases?. Should we give as valid this fact or to > ignore Tags data? That case is perfectly valid. You said it yourself -- there's no fixed element order. mkvmerge also doesn't enforce any order -- e.g. if you create a tag XML file with a certain order then mkvmerge will most likely not change the order. Regards, Mosu -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From slhomme at matroska.org Sat Feb 12 08:54:42 2011 From: slhomme at matroska.org (Steve Lhomme) Date: Sat, 12 Feb 2011 08:54:42 +0100 Subject: [Matroska-devel] Official Tags In-Reply-To: References: Message-ID: Hello Jaroslaw, On Thu, Feb 10, 2011 at 1:32 PM, grok wrote: > Hello, > > First of all, thank you for designing the best media container out there. > > I had a quick search through the mailing lists and other than > unanswered questions didn't find anything relevant. I've been looking > for a tag to put external database IDs like IMDB into a MKV file and > haven't found one that is suitable. > > Therefore I'd like to propose adding a new official tag or at least > specifying one that would allow storing such information. > > In simplest form it could look like this: > > ? ? > ? ? ?EXTERNAL_DB > ? ? ? ? > ? ? ? ? ?IMDB > ? ? ? ? ?tt123456 > ? ? ? ? > ? ? ? ? > ? ? ? ? ?TMDB > ? ? ? ? ?1256 > ? ? ? ? > ? ? > > Where "EXTERNAL_DB" would be an official tag and the attributes like > "IMDB" would be unspecified to avoid amending spec every time some > database becomes relevant. > > Is it something that makes sense from your point of view? That does sound good to me. Let's see if there are comments on this. Also if you or anyone else can think of other relevant DBs (discogs for music ? musicbrainz ? amazon store ?). Maybe an accompanying URL or at least DNS for the service could be good. Maybe the DNS as the tag name ? There could be an issue if one DNS have 2 different DBs (ie IDs not matching in the 2 different DBs) for music and video. Steve > Regards, > -- > Jaroslaw Zachwieja > -- Steve Lhomme Matroska association Chairman From boris.juraga at gmail.com Sat Feb 12 10:12:39 2011 From: boris.juraga at gmail.com (Boris Juraga) Date: Sat, 12 Feb 2011 10:12:39 +0100 Subject: [Matroska-devel] Official Tags In-Reply-To: References: Message-ID: Well i certainly like this idea, and the structure seems very thought out so i support this. On Sat, Feb 12, 2011 at 8:54 AM, Steve Lhomme wrote: > Hello Jaroslaw, > > On Thu, Feb 10, 2011 at 1:32 PM, grok wrote: >> Hello, >> >> First of all, thank you for designing the best media container out there. >> >> I had a quick search through the mailing lists and other than >> unanswered questions didn't find anything relevant. I've been looking >> for a tag to put external database IDs like IMDB into a MKV file and >> haven't found one that is suitable. >> >> Therefore I'd like to propose adding a new official tag or at least >> specifying one that would allow storing such information. >> >> In simplest form it could look like this: >> >> ? ? >> ? ? ?EXTERNAL_DB >> ? ? ? ? >> ? ? ? ? ?IMDB >> ? ? ? ? ?tt123456 >> ? ? ? ? >> ? ? ? ? >> ? ? ? ? ?TMDB >> ? ? ? ? ?1256 >> ? ? ? ? >> ? ? >> >> Where "EXTERNAL_DB" would be an official tag and the attributes like >> "IMDB" would be unspecified to avoid amending spec every time some >> database becomes relevant. >> >> Is it something that makes sense from your point of view? > > That does sound good to me. Let's see if there are comments on this. > Also if you or anyone else can think of other relevant DBs (discogs > for music ? musicbrainz ? amazon store ?). Maybe an accompanying URL > or at least DNS for the service could be good. Maybe the DNS as the > tag name ? There could be an issue if one DNS have 2 different DBs (ie > IDs not matching in the 2 different DBs) for music and video. > > Steve > >> Regards, >> -- >> Jaroslaw Zachwieja >> > > > > -- > Steve Lhomme > Matroska association Chairman > _______________________________________________ > Matroska-devel mailing list > Matroska-devel at lists.matroska.org > http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel > Read Matroska-Devel on GMane: http://dir.gmane.org/gmane.comp.multimedia.matroska.devel > From slhomme at matroska.org Sat Feb 12 10:22:22 2011 From: slhomme at matroska.org (Steve Lhomme) Date: Sat, 12 Feb 2011 10:22:22 +0100 Subject: [Matroska-devel] Hi, question about the MKV tags In-Reply-To: <3E923FEEF3674EEF9F7E0D1480B3BF7A@JSASUS> References: <44A5FDC3001C4157B802B5CF9C94827C@JSASUS> <5D55D5E45DD1438DB62E4955305BC62B@JSASUS> <3E923FEEF3674EEF9F7E0D1480B3BF7A@JSASUS> Message-ID: On Thu, Feb 10, 2011 at 12:10 PM, Santiago Jimeno wrote: >>> Yes, I will change the specs to make sure it's clear that padding >>> after SeekHead is recommended (even for things that don't even exist >>> yet in Matroska). >> >> OK, I will first update mkclean to leave more space (right now there's >> only space for one element). > > Testing files I see there are two possibilities to put space: > - After SeekHead (This is what mkvmerge does ), as Segment child > - Inside SeekHead at the end > How do you plan to put it?. mkclean puts the Void inside the SeekHead element. In the end the result is almost the same. The only difference is that then the SeekHead already has the right amount of bytes in the header for its total side. The downside is that adding new elements at the level 1 would mean editing the SeekHead header to grab some octets from it so they can be used around it. So maybe I should put the Void outside of SeekHead but make sure it has the right space to edit its "internal" size. > On the other hand, in the same test I have found that there is apps that > invert the elements placement in SeekHead and Tags > In Tags (TagString before TagName) and in Seek (SEEKPOSITION before SEEKID) > Example of AVI-Mux GUI : > http://samples.mplayerhq.hu/Matroska/Mushishi24-head.mkv > > I know there is not a fixed elements order, but is it of common sense to do > this in these cases?. > Should we give as valid this fact or to ignore Tags data? This is the intention of Alexander Noe (author of AVI-Mux GUI) to put elements in random position when possible. So that readers don't assume fixed positions. This is to ensure better long term compatibility. -- Steve Lhomme Matroska association Chairman From slhomme at matroska.org Sat Feb 12 10:24:10 2011 From: slhomme at matroska.org (Steve Lhomme) Date: Sat, 12 Feb 2011 10:24:10 +0100 Subject: [Matroska-devel] Hi, question about the MKV tags In-Reply-To: References: <44A5FDC3001C4157B802B5CF9C94827C@JSASUS> <5D55D5E45DD1438DB62E4955305BC62B@JSASUS> <19C1440BEA2C40C785856F9C6E1666C9@JSASUS> Message-ID: On Mon, Feb 7, 2011 at 2:45 PM, Boris Juraga wrote: > 3. Attachments are always a big deal, so in my opinion it is normal to > remux the file after adding lets say 4 cover art images in total of > one megabyte or even more (someone will add 1080pixels images) so i > would suggest remuxing after this. I agree -- Steve Lhomme Matroska association Chairman From slhomme at matroska.org Sat Feb 12 10:35:31 2011 From: slhomme at matroska.org (Steve Lhomme) Date: Sat, 12 Feb 2011 10:35:31 +0100 Subject: [Matroska-devel] Hi, question about the MKV tags In-Reply-To: <19C1440BEA2C40C785856F9C6E1666C9@JSASUS> References: <44A5FDC3001C4157B802B5CF9C94827C@JSASUS> <5D55D5E45DD1438DB62E4955305BC62B@JSASUS> <19C1440BEA2C40C785856F9C6E1666C9@JSASUS> Message-ID: On Mon, Feb 7, 2011 at 1:56 PM, Santiago Jimeno wrote: > As for SeekHead: The maximum size of one entry is 17 bytes without CRC or 21 > bytes with CRC. > The possible entries are: > -SegmentInfo > -Track > -Chapters > -Attachments > -Tags > -Cueing > -First Cluster > > I think it would be good to put First Cluster location here. This would > provide us a complete file map and their positions and we could go to them > without parsing whole file. We could also calculate easily the size of each > master element. That's a good idea > It's not necessary to specify all cluster blocks location here. Cueing is > for this. > Then the minimum size would be 21 x 7 = 147. But I would put padding with > bigger size for the future (among 200-300 bytes). Yes, you never know if someday there won't be more level 1 elements. > Anyway to avoid problems (with or without padding) the best thing would be > to make them independent of Media Data. Some Tags systems solve it dividing No, this is not good. Matroska tags not only describes the whole content, but it can describe chapters, tracks and attachments. So it has to be at the same level as those, ie inside the segment. A Segment is an "integral" entity, it should not look outside for data about it. Plus when segments are chained you would not know if the tag applies to the one before or after. (chained segments are really a pain to edit tags too) I am planning to add a new Level 0 element to reference segments. But I don't think tags fit in there. > the file in two parts. Header, metadata and other information blocks in one > file part and Media Data in the other file part. > In the case of Matroska when being at the middle, inside Segment and before > Cluster, does these last ones being too sensitive to the variations or > modifications before. The solution of declaring Void the modified blocks > originates empty spaces with little utility and increases the file size. > Moving them at the end becomes contradictory the Order Guidelines for fixing > a definitive position that an Editor can find easily. The padding addiction > in Tags is a possible solution (if this may be guaranteed in the future), > but then the biggest problem for its great size is caused by Attachments > (Pictures). The ordering guidelines does take in consideration the case of editing tags in case it needs to be moved at the end. -- Steve Lhomme Matroska association Chairman From moritz at bunkus.org Sat Feb 12 10:56:41 2011 From: moritz at bunkus.org (Moritz Bunkus) Date: Sat, 12 Feb 2011 10:56:41 +0100 Subject: [Matroska-devel] Hi, question about the MKV tags In-Reply-To: References: <44A5FDC3001C4157B802B5CF9C94827C@JSASUS> <5D55D5E45DD1438DB62E4955305BC62B@JSASUS> <3E923FEEF3674EEF9F7E0D1480B3BF7A@JSASUS> Message-ID: <49cd4dd216d1df78dd2c6f20a8542a65@www.bunkus.org> Hey, On Sat, 12 Feb 2011 10:22:22 +0100, Steve Lhomme wrote: > mkclean puts the Void inside the SeekHead element. In the end the > result is almost the same. Not really. The code in mmg/mkvpropedit that can place chapters, tags or whatever level 1 element in existing files only looks for void elements at the first level -- meaning if they're children of the segment. It does not consider void elements inside level 1 elements e.g. in seekheads. It will also not remove voids in a seekhead or reduce its sizes. Putting the void into the seekhead certainly allows for storing more seekentries in the seekhead with the proper code. However, it makes such code a lot more complex than it already is. If you don't know how complex all the situations can get then I suggest you take a look at http://www.bunkus.org/cgi-bin/gitweb.cgi?p=mkvtoolnix.git;a=blob;f=src/common/kax_analyzer.cpp;h=e76bea635280f962e0651f25860562777827f2e4;hb=HEAD That file is actually documented properly and therefore worth a read if one is implementing something similar, and if we're discussing where to put void elements. > The only difference is that then the > SeekHead already has the right amount of bytes in the header for its > total side. The downside is that adding new elements at the level 1 > would mean editing the SeekHead header to grab some octets from it so > they can be used around it. That downside is what I'm talking about as well. Let's not make this code more complicated that it already is. There's a reason why there are few tools to handle the Matroska file structure that way instead of relying on other tools to simply remux the whole file, and putting void inside level 1 elements only adds to that complexity. > This is the intention of Alexander Noe (author of AVI-Mux GUI) to put > elements in random position when possible. So that readers don't > assume fixed positions. This is to ensure better long term > compatibility. I agree with Alex on this. Even though mkvmerge doesn't do it to the extent that AVI-Mux GUI does mkvmerge often does things that annoy existing readers while staying 100% spec compliant -- e.g. make header removal the default or use SimpleBlocks by default. mkvmerge switching to them caused almost the same outcry about "incompatible files" that activating header removal compression did. Regards, mosu From slhomme at matroska.org Sat Feb 12 11:46:50 2011 From: slhomme at matroska.org (Steve Lhomme) Date: Sat, 12 Feb 2011 11:46:50 +0100 Subject: [Matroska-devel] Hi, question about the MKV tags In-Reply-To: <49cd4dd216d1df78dd2c6f20a8542a65@www.bunkus.org> References: <44A5FDC3001C4157B802B5CF9C94827C@JSASUS> <5D55D5E45DD1438DB62E4955305BC62B@JSASUS> <3E923FEEF3674EEF9F7E0D1480B3BF7A@JSASUS> <49cd4dd216d1df78dd2c6f20a8542a65@www.bunkus.org> Message-ID: On Sat, Feb 12, 2011 at 10:56 AM, Moritz Bunkus wrote: > Hey, > > On Sat, 12 Feb 2011 10:22:22 +0100, Steve Lhomme wrote: > >> mkclean puts the Void inside the SeekHead element. In the end the >> result is almost the same. > > Not really. The code in mmg/mkvpropedit that can place chapters, tags or > whatever level 1 element in existing files only looks for void elements at > the first level -- meaning if they're children of the segment. It does not > consider void elements inside level 1 elements e.g. in seekheads. It will > also not remove voids in a seekhead or reduce its sizes. > > Putting the void into the seekhead certainly allows for storing more > seekentries in the seekhead with the proper code. However, it makes such > code a lot more complex than it already is. If you don't know how complex > all the situations can get then I suggest you take a look at > http://www.bunkus.org/cgi-bin/gitweb.cgi?p=mkvtoolnix.git;a=blob;f=src/common/kax_analyzer.cpp;h=e76bea635280f962e0651f25860562777827f2e4;hb=HEAD > > That file is actually documented properly and therefore worth a read if one > is implementing something similar, and if we're discussing where to put void > elements. I added a second remark about padding. http://www.matroska.org/technical/order/index.html This one at Level 1. I think the one in SeekHead to alter the content of SeekHead is good as well. Of course it's a waste when there's Level 1 padding just after. In the end it's up to the muxer to use, one, the other or both padding. I will modify mkclean to put some padding at both levels. Steve -- Steve Lhomme Matroska association Chairman From boris.juraga at gmail.com Sat Feb 12 11:52:56 2011 From: boris.juraga at gmail.com (Boris Juraga) Date: Sat, 12 Feb 2011 11:52:56 +0100 Subject: [Matroska-devel] Hi, question about the MKV tags In-Reply-To: <49cd4dd216d1df78dd2c6f20a8542a65@www.bunkus.org> References: <44A5FDC3001C4157B802B5CF9C94827C@JSASUS> <5D55D5E45DD1438DB62E4955305BC62B@JSASUS> <3E923FEEF3674EEF9F7E0D1480B3BF7A@JSASUS> <49cd4dd216d1df78dd2c6f20a8542a65@www.bunkus.org> Message-ID: >> This is the intention of Alexander Noe (author of AVI-Mux GUI) to put >> elements in random position when possible. So that readers don't >> assume fixed positions. This is to ensure better long term >> compatibility. > > I agree with Alex on this. Even though mkvmerge doesn't do it to the extent > that AVI-Mux GUI does mkvmerge often does things that annoy existing readers > while staying 100% spec compliant Well i like your approach on this, but you see, then you are "forcing" other people (99.99% of the people using mkvmerge to convert from various containers to Matroska) who can not develop their own muxers and tools for matroska to see the container from your perspective. Not to disrespect you or your work, but if you cared about Matroska in the way you stated above you would've made a tag editor that does not remux the file and we would not be having this conversation. I would simple download a Matroska Tag Editor.exe from somewhere and stick with only creating the Mtroska Media Library i first started building. But now i have almost complete application, and no app to build the "complete" matroska files. So this is the downside of open source, and i know that no one makes money on this, and to use its own time "for free" is givingto the world but we need to make one good tag editor now, and it better only support simple matroska files, so people can start to use it. media centers can start using it. and then we can version it and upgrade. If i knew how to run an open source project on sourceforge or similar i would by now. But untill recently i was a full time employed C# developer so my perspective on open source is just opening. Again, no disrespect meant, my point is that i think We should make something for Matroska, and not just for us. From slhomme at matroska.org Sat Feb 12 13:18:03 2011 From: slhomme at matroska.org (Steve Lhomme) Date: Sat, 12 Feb 2011 13:18:03 +0100 Subject: [Matroska-devel] Hi, question about the MKV tags In-Reply-To: References: <44A5FDC3001C4157B802B5CF9C94827C@JSASUS> <5D55D5E45DD1438DB62E4955305BC62B@JSASUS> <3E923FEEF3674EEF9F7E0D1480B3BF7A@JSASUS> <49cd4dd216d1df78dd2c6f20a8542a65@www.bunkus.org> Message-ID: I agree that a good tag editor for Matroska is much needed. You have to realise that Matroska is mostly used for video and video tag support is almost non existent is most players and probably in Media Centers too. It's all a chicken and egg problem. I try to push Matroska tags whenever I can but it's not an easy sell. But as this thread suggests, there is a growing demand and some tools are on the way. I would do one myself but right now my TODO list is already full as it is. So I leave the job to someone else for now. Steve On Sat, Feb 12, 2011 at 11:52 AM, Boris Juraga wrote: >>> This is the intention of Alexander Noe (author of AVI-Mux GUI) to put >>> elements in random position when possible. So that readers don't >>> assume fixed positions. This is to ensure better long term >>> compatibility. >> >> I agree with Alex on this. Even though mkvmerge doesn't do it to the extent >> that AVI-Mux GUI does mkvmerge often does things that annoy existing readers >> while staying 100% spec compliant > > Well i like your approach on this, but you see, then you are "forcing" > other people (99.99% of the people using mkvmerge to convert from > various containers to Matroska) who can not develop their own muxers > and tools for matroska to see the container from your perspective. Not > to disrespect you or your work, but if you cared about Matroska in the > way you stated above you would've made a tag editor that does not > remux the file and we would not be having this conversation. I would > simple download a Matroska Tag Editor.exe from somewhere and stick > with only creating the Mtroska Media Library i first started building. > But now i have almost complete application, and no app to build the > "complete" matroska files. So this is the downside of open source, and > i know that no one makes money on this, and to use its own time "for > free" is givingto the world but we need to make one good tag editor > now, and it better only support simple matroska files, so people can > start to use it. media centers can start using it. and then we can > version it and upgrade. If i knew how to run an open source project on > sourceforge or similar i would by now. But untill recently i was a > full time employed C# developer so my perspective on open source is > just opening. > > Again, no disrespect meant, my point is that i think We should make > something for Matroska, and not just for us. > _______________________________________________ > Matroska-devel mailing list > Matroska-devel at lists.matroska.org > http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel > Read Matroska-Devel on GMane: http://dir.gmane.org/gmane.comp.multimedia.matroska.devel > -- Steve Lhomme Matroska association Chairman From boris.juraga at gmail.com Sat Feb 12 14:00:35 2011 From: boris.juraga at gmail.com (Boris Juraga) Date: Sat, 12 Feb 2011 14:00:35 +0100 Subject: [Matroska-devel] Hi, question about the MKV tags In-Reply-To: References: <44A5FDC3001C4157B802B5CF9C94827C@JSASUS> <5D55D5E45DD1438DB62E4955305BC62B@JSASUS> <3E923FEEF3674EEF9F7E0D1480B3BF7A@JSASUS> <49cd4dd216d1df78dd2c6f20a8542a65@www.bunkus.org> Message-ID: Well, yes but i dont even hope for media players to support tags, they simply dont need them. So to state that as a reason is not valid. Media centers on the other hand dont support that as from their point of view it is no worth it their time to write tag readers and on top of that tag writers. You see to test a tag reader you have to write tag writer(editor). My media library is built only around Matroska (MKA and MKV) so i need to read the tags. That i can do. I have writen my library in C# and after short period i hope to publish it - but as i stated i am new to opensource, so i have to first familiarize myself with all those licences and stuff. And for that chicken and egg, one solution comes to mind: One should make a tag editor and this discussion will have point. I would be glad to help in any way i can but i can not start the project, it has to be someone more directly linked to Matroska, one with the power to write the specs. So then i guess i will keep developing my app and hope that one day someone will make use of it. For now it will serve only me and my friends. From boris.juraga at gmail.com Sat Feb 12 14:09:34 2011 From: boris.juraga at gmail.com (Boris Juraga) Date: Sat, 12 Feb 2011 14:09:34 +0100 Subject: [Matroska-devel] Hi, question about the MKV tags In-Reply-To: References: <44A5FDC3001C4157B802B5CF9C94827C@JSASUS> <5D55D5E45DD1438DB62E4955305BC62B@JSASUS> <3E923FEEF3674EEF9F7E0D1480B3BF7A@JSASUS> <49cd4dd216d1df78dd2c6f20a8542a65@www.bunkus.org> Message-ID: Just to give you an idea of what i like to build http://bjsoft.weebly.com/mkv.html this is just a placeholder for now, nothing else on the site, images are a few days old and the UI is a bit changed, but it is still good enough to present my ideas. From slhomme at matroska.org Sat Feb 12 15:13:21 2011 From: slhomme at matroska.org (Steve Lhomme) Date: Sat, 12 Feb 2011 15:13:21 +0100 Subject: [Matroska-devel] Hi, question about the MKV tags In-Reply-To: References: <44A5FDC3001C4157B802B5CF9C94827C@JSASUS> <5D55D5E45DD1438DB62E4955305BC62B@JSASUS> <3E923FEEF3674EEF9F7E0D1480B3BF7A@JSASUS> <49cd4dd216d1df78dd2c6f20a8542a65@www.bunkus.org> Message-ID: Looks good. Is it going to be Windows only ? I suppose it could work on OS X/Linux using Mono if you are doing it in C#. Steve On Sat, Feb 12, 2011 at 2:09 PM, Boris Juraga wrote: > Just to give you an idea of what i like to build > > http://bjsoft.weebly.com/mkv.html > > this is just a placeholder for now, nothing else on the site, images > are a few days old and the UI is a bit changed, but it is still good > enough to present my ideas. > _______________________________________________ > Matroska-devel mailing list > Matroska-devel at lists.matroska.org > http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel > Read Matroska-Devel on GMane: http://dir.gmane.org/gmane.comp.multimedia.matroska.devel > -- Steve Lhomme Matroska association Chairman From sjimeno at ya.com Sat Feb 12 16:35:21 2011 From: sjimeno at ya.com (Santiago Jimeno) Date: Sat, 12 Feb 2011 16:35:21 +0100 Subject: [Matroska-devel] Hi, question about the MKV tags In-Reply-To: References: <44A5FDC3001C4157B802B5CF9C94827C@JSASUS><5D55D5E45DD1438DB62E4955305BC62B@JSASUS><3E923FEEF3674EEF9F7E0D1480B3BF7A@JSASUS> Message-ID: Steve > mkclean puts the Void inside the SeekHead element. In the end the > result is almost the same. Mosu >Not really. Indeed is not the same thing. I agree with Mosu. For that reason I asked the question. And the same question is expandable for the rest (Tags, Attachments). As for padding in Attachments (without Remux) would maybe give for an extensive new thread. But I agree also with Steve that should have padding there where it is necessary. Inside the amendable elements and for each segment. But they should be very well calculated for not increasing file size. We don't have another election if one want to preserve the current container structure. Mosu, if you think that rewriting SeekHead (padding inside) does most complex the code, this is not anything in comparison with writing an editor (without Remux) keeping in mind each programmer's occurrences. So my code is full of conditional. But modify SeekHead is the simplest thing in comparison with other edition tasks. So I should look for padding in the elements to modify and in the segment. I have already corrected my code to upgrade it to the "aleatory" system. I have also included code for Lyrics. But if I should keep in mind all the possible aspects of flexibility, why should not other programmers do it ? They should also look for padding inside each element (if they want to adapt it). I think that the extreme (excessive normative or flexibility) is erroneous. The better thing is a balance among both things. But it seems that Steve is beginning to think that he maybe should in the future to put some "must" more than those that there is in Order Guidelines. Finally, each app. is what is. And other users should adapt to what that app. does, as well as the app. adapts to the container requirements . For the moment one cannot demand more. But if somebody wants more he can begin to work without depending on any app. PS for Mosu. When I finish therewith I would like to recapture what we speak about TrueHd bug and of calculation of the file play duration. Regards. Santiago From slhomme at matroska.org Sat Feb 12 16:57:45 2011 From: slhomme at matroska.org (Steve Lhomme) Date: Sat, 12 Feb 2011 16:57:45 +0100 Subject: [Matroska-devel] Hi, question about the MKV tags In-Reply-To: References: <44A5FDC3001C4157B802B5CF9C94827C@JSASUS> <5D55D5E45DD1438DB62E4955305BC62B@JSASUS> <3E923FEEF3674EEF9F7E0D1480B3BF7A@JSASUS> Message-ID: On Sat, Feb 12, 2011 at 4:35 PM, Santiago Jimeno wrote: > I think that the extreme (excessive normative or flexibility) is erroneous. > The better thing is a balance among both things. But it seems that Steve is > beginning to think that he maybe should in the future to put some "must" > more than those that there is in Order Guidelines. I already updated the page (again) to reflect more what should be done. After thinking more, there's no need to put the padding "inside" the SeekHead. Just after but at Level 1 is fine. That leaves more freedom to easily move stuff at Level 1. I already changed mkclean in SVN to do that. Now I'm adding a link to the first Cluster. This is almost done. -- Steve Lhomme Matroska association Chairman From sjimeno at ya.com Mon Feb 14 11:04:43 2011 From: sjimeno at ya.com (Santiago Jimeno) Date: Mon, 14 Feb 2011 11:04:43 +0100 Subject: [Matroska-devel] Hi, question about the MKV tags In-Reply-To: References: <44A5FDC3001C4157B802B5CF9C94827C@JSASUS><5D55D5E45DD1438DB62E4955305BC62B@JSASUS><3E923FEEF3674EEF9F7E0D1480B3BF7A@JSASUS> Message-ID: <2C05CE9A1A884CD6B5364B5B27E0799F@JSASUS> Steve > I already updated the page (again) to reflect more what should be > done. After thinking more, there's no need to put the padding "inside" > the SeekHead. Just after but at Level 1 is fine. That leaves more > freedom to easily move stuff at Level 1. Should I understand that the same approach will be applied to the padding of Tags and Attachments or any other element? I am writing the code of "Apply Changes" for editing and I would want to have clear the things. Then I should also understand that the padding that continues to an element (as segment child) should be for later use of that element and to respect it. Is it this way the thing?. Will it be respected? Because it can happen that if somebody needs to write Tags and he finds a big padding in Segment, for example after SeekInfo or after Tracks, he writes the Tags there and annul somehow the possibility to modify the element that preceded it . Regards. Santiago From moritz at bunkus.org Mon Feb 14 11:08:52 2011 From: moritz at bunkus.org (Moritz Bunkus) Date: Mon, 14 Feb 2011 11:08:52 +0100 Subject: [Matroska-devel] Hi, question about the MKV tags In-Reply-To: <2C05CE9A1A884CD6B5364B5B27E0799F@JSASUS> References: <2C05CE9A1A884CD6B5364B5B27E0799F@JSASUS> Message-ID: <201102141108.52310.moritz@bunkus.org> Hey, On Monday 14 February 2011 11:04:43 Santiago Jimeno wrote: > Then I should also understand that the padding that continues to an element > (as segment child) should be for later use of that element and to respect > it. Hmm not really. A void element doesn't have any such semantics -- it's simply a placeholder where other elements can be written. > Is it this way the thing?. Will it be respected? Certainly not. > Because it can happen that if somebody needs to write Tags and he finds a > big padding in Segment, for example after SeekInfo or after Tracks, he > writes the Tags there and annul somehow the possibility to modify the > element that preceded it . That's what mmg/mkvpropedit do already with chapters and soon with tags. Regards, Mosu -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From sjimeno at ya.com Mon Feb 14 14:09:06 2011 From: sjimeno at ya.com (Santiago Jimeno) Date: Mon, 14 Feb 2011 14:09:06 +0100 Subject: [Matroska-devel] Hi, question about the MKV tags In-Reply-To: <201102141108.52310.moritz@bunkus.org> References: <2C05CE9A1A884CD6B5364B5B27E0799F@JSASUS> <201102141108.52310.moritz@bunkus.org> Message-ID: > > Then I should also understand that the padding that continues to an > > element > > (as segment child) should be for later use of that element and to > > respect > > it. > Hmm not really. A void element doesn't have any such semantics -- it's > simply a placeholder where other elements can be written. > > Is it this way the thing?. Will it be respected? > Certainly not. > > Because it can happen that if somebody needs to write Tags and he finds > > a > > big padding in Segment, for example after SeekInfo or after Tracks, he > > writes the Tags there and annul somehow the possibility to modify the > > element that preceded it . > That's what mmg/mkvpropedit do already with chapters and soon with tags. > Regards, > Mosu Then the possible advantage of adding padding after an element is annulled or very reduced. Mainly for SeekHead but also for any other element. Then could we understand that if the padding is included inside Level 1 Elements it will be respected? I think that it would be. Since it would not be looked for to write other elements and it is not necessary to write code to look for it. If it is modified (rewrited) is only necessary to guide us by the element size. In other words, you don't need code to look for it. You should only keep it in mind if you rewrote the element. This is a limitation for the admirers of the random flexibility but without necessity of putting an authoritarian sentence in Order Guidelines. Mosu, I understand your problems and complaints about this and the painful thing that it is write again a code that works perfectly. This has already happened me with the example file of AVI-Mux GUI ......that also writes padding inside SeekHead !!. Another "aleatory" case: the file http://samples.mplayerhq.hu/Matroska/anamorphic/starwars10MB-1.mkv (VirtualDubMod) writes InfoSegment before SeekHead. But I think what makes more complex the code is not the changes (if they are meditated and studied) but the excessive flexibility (understanding this as random thing according to each programmer's personal approach). Playing with the aleatory thing is not scientific. Einstein said "God doesn't play to the dice" I have calculated that there are 10 possibilities of combinations for Tags and Attachmets when are edited together (without remux). Once this is established, it is necessary to write code for several different placement possibilities for each one of them: before cluster, after cluster or on free padding. Would it be less complex to do this? - Indeed yes Then? Regards. Santiago From moritz at bunkus.org Mon Feb 14 14:24:59 2011 From: moritz at bunkus.org (Moritz Bunkus) Date: Mon, 14 Feb 2011 14:24:59 +0100 Subject: [Matroska-devel] Hi, question about the MKV tags In-Reply-To: References: <201102141108.52310.moritz@bunkus.org> Message-ID: <201102141424.59792.moritz@bunkus.org> Hey, On Monday 14 February 2011 14:09:06 Santiago Jimeno wrote: > Then could we understand that if the padding is included inside Level > 1 Elements it will be respected? Not really, why should it be? Let's assume you have this layout: SeekHead + Void Chapters Cluster Meaning the seekhead contains the void as a child. Now my application wants to change chapters, but there's no space behind the chapters. My application could simply remove the void from the seekhead freeing up space before the chapters and move the chapters to the front. That's perfectly legal. > I think that it would be. No. You would only rely on application developers to be lazy and to implement void detection only on the same level. Also I don't think there's actually a real need for padding for each and every level 1 element. There's only one case that should always be checked: that there's enough space in front of the first cluster for at least a seekhead with a single entry. That seekhead can point to a secondary seekhead (e.g. near the end of the file) that contains pointers to all the other level 1 elements. How much space would you pad with anyway? For chapters this is easy. Or is it? I've seen people use chapters that occupy more than 2 KB. And tags? Hell, they can be even longer, e.g. if you include movie descriptions and reviews. There's simply no useful way to estimate the amount of space needed after attachments -- because you have no clue what any other user might want to attach later. Leaving voids everywhere is not a proper solution. We're coming from the tags perspective here: they should be placed at a certain location (other elements as well). But there are practical limitations where you can put those elements if you're not rewriting the whole file. That's true for each and every file format. You can only gain more flexibility in this situation by trading it for efficiency (namely wasting a lot of space with void elements). Therefore: don't. Use voids where they're useful, e.g. by allowing for space for the seekhead to expand a little. Or for track header editing applications like mmg's header editor. > Mosu, I understand your problems and complaints about this and the > painful thing that it is write again a code that works perfectly. No, I don't object to the amount of work involved, I object to the principal of leaving void elements everywhere. It doesn't gain you anything in the general case. > Another "aleatory" case: the file > http://samples.mplayerhq.hu/Matroska/anamorphic/starwars10MB-1.mkv > (VirtualDubMod) writes InfoSegment before SeekHead. Perfectly valid. The seekhead should only be located before the first cluster -- if a seekhead is present at all. You don't even need one in life streaming cases as long as all other relevant level 1 elements (at least segment info and track headers) occur before the first cluster. Any application handling attachments and tags has to be flexible enough to locate them wherever they are as long as they either occur before the first cluster or they're indexed via seekheads. Therefore the placement strategy for non-remuxes can only be a guideline -- "place them at ... if possible, otherwise put them wherever is convenient". Regards, Mosu -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From moritz at bunkus.org Mon Feb 14 14:32:59 2011 From: moritz at bunkus.org (Moritz Bunkus) Date: Mon, 14 Feb 2011 14:32:59 +0100 Subject: [Matroska-devel] Hi, question about the MKV tags In-Reply-To: <201102141424.59792.moritz@bunkus.org> References: <201102141424.59792.moritz@bunkus.org> Message-ID: <201102141432.59502.moritz@bunkus.org> Hey, On Monday 14 February 2011 14:24:59 Moritz Bunkus wrote: > Therefore: don't. Use voids where they're useful, e.g. by allowing for > space for the seekhead to expand a little. Or for track header editing > applications like mmg's header editor. Actually, the void after the track headers is just as superfluous as the voids I'm arguing against. Track headers don't HAVE to be located in front of the first cluster -- but it sure is nicer or even required for streaming purposes (required if the stream cannot be seeked). Regards, Mosu -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From slhomme at matroska.org Mon Feb 14 17:03:41 2011 From: slhomme at matroska.org (Steve Lhomme) Date: Mon, 14 Feb 2011 17:03:41 +0100 Subject: [Matroska-devel] Hi, question about the MKV tags In-Reply-To: <201102141424.59792.moritz@bunkus.org> References: <201102141108.52310.moritz@bunkus.org> <201102141424.59792.moritz@bunkus.org> Message-ID: On Mon, Feb 14, 2011 at 2:24 PM, Moritz Bunkus wrote: > Also I don't think there's actually a real need for padding for each and > every level 1 element. There's only one case that should always be > checked: that there's enough space in front of the first cluster for at > least a seekhead with a single entry. That seekhead can point to a > secondary seekhead (e.g. near the end of the file) that contains > pointers to all the other level 1 elements. So are we back to using double Seek Heads ? I thought this was deprecated. It adds extra complexity for a fundamental part that is supposed to make the file handling easier. > Leaving voids everywhere is not a proper solution. I agree >> Another "aleatory" case: ?the file >> http://samples.mplayerhq.hu/Matroska/anamorphic/starwars10MB-1.mkv >> (VirtualDubMod) writes InfoSegment before SeekHead. > > Perfectly valid. The seekhead should only be located before the first > cluster -- if a seekhead is present at all. You don't even need one in > life streaming cases as long as all other relevant level 1 elements (at > least segment info and track headers) occur before the first cluster. It is valid indeed but kinda defeat the point of the Seek Head if you find Level 1 elements before. By the way for the adaptive streaming "profile" (aka guideline), we will need to tighten the rules for placement. As there needs to be a part that it clearly for playback initialization (with Segment Info and Track Info at least) and one with the seeking info (Cues). I'd put Seek Head in the former. Luckily with such a design it matters less is the Seek Head is at the front or not (ie more mkvmerge friendly), but it's still not good when simply streaming as a progressive download. -- Steve Lhomme Matroska association Chairman From sjimeno at ya.com Mon Feb 14 17:26:29 2011 From: sjimeno at ya.com (Santiago Jimeno) Date: Mon, 14 Feb 2011 17:26:29 +0100 Subject: [Matroska-devel] Hi, question about the MKV tags In-Reply-To: <201102141424.59792.moritz@bunkus.org> References: <201102141108.52310.moritz@bunkus.org> <201102141424.59792.moritz@bunkus.org> Message-ID: If padding behind Seekhead is used (inside or after) for other necessities, the supposed advantage is annulled. Everything is possible to be changed. But it is not the possibility but the certainty this padding won't be respected, what do that I insist in that the best solution is to put it inside SeekHead. Mosu > Leaving voids everywhere is not a proper solution. I also think it is not necessary leaving padding everywhere. But I am saying a while ago that for avoiding them there are few alternatives in the current situation. If we want to avoid big padding there are only two alternatives: - Taking metadata out of Segment - Putting metadata always at the end. But now, I can only adapt to the established. Mosu > There's only one case that should always be checked: that there's enough space in front of the first cluster for at least a seekhead with a single entry. That seekhead can point to a secondary seekhead (e.g. near the end of the file) that contains pointers to all the other level 1 elements. OK. But this option is deprecated in Order Guidelines. Regards. Santiago From moritz at bunkus.org Mon Feb 14 19:00:33 2011 From: moritz at bunkus.org (Moritz Bunkus) Date: Mon, 14 Feb 2011 19:00:33 +0100 Subject: [Matroska-devel] Hi, question about the MKV tags In-Reply-To: References: <201102141108.52310.moritz@bunkus.org> <201102141424.59792.moritz@bunkus.org> Message-ID: Hey, On Mon, 14 Feb 2011 17:03:41 +0100, Steve Lhomme wrote: > So are we back to using double Seek Heads ? I thought this was > deprecated. It adds extra complexity for a fundamental part that is > supposed to make the file handling easier. It's almost trivial to support linked seekheads -- simply make seekhead parsing recursive. Also it's not the standard behaviour of mkvmerge. But mmg's chapter editor/track header editor and mkvpropedit will fall back to creating such structures if there's not enough room before the first cluster for storing the whole seekhead. There are only three options in such cases: 1. refuse to modify the file, 2. remux the whole file into a temporary one & overwrite the original one afterwards and 3. create two linked seekheads, a small one before the first cluster and a larger one at the back of the file. Like I said, this is the exception, not the rule. > It is valid indeed but kinda defeat the point of the Seek Head if you > find Level 1 elements before. The simplest algorithm that works both with seekable and with non-seekable files is: while (!cluster_found) { read_next_level1_element if (is_cluster) break; else if (is_seekhead && stream_is_seekable) parse_seekhead_and_read_other_level1_elements; else if (is_track_headers) parse_track_headers; else if (is_segmentinfo) ... } if (!segmentinfo_found || !track_headers_found) error; Also it doesn't defeat any point. The seekhead can still (and most likely will) point to stuff at the end of the file, e.g. at least the cues. > Luckily with such a design it matters less is > the Seek Head is at the front or not (ie more mkvmerge friendly), mkvmerge doesn't care. If it finds a seekhead before the first cluster then that seekhead and all the ones referenced from it are used. If it doesn't then mkvmerge requires the track headers and segment info to be located before the first cluster as well. If it also finds tags/attachments/chapters before the first cluster then those are used as well. Pretty much like the dummy algorithm above: "it will be used if it is found by reading up to the first cluster and following all seekheads founduntil then". Regards, mosu From moritz at bunkus.org Mon Feb 14 19:03:34 2011 From: moritz at bunkus.org (Moritz Bunkus) Date: Mon, 14 Feb 2011 19:03:34 +0100 Subject: [Matroska-devel] Hi, question about the MKV tags In-Reply-To: References: <201102141108.52310.moritz@bunkus.org> <201102141424.59792.moritz@bunkus.org> Message-ID: Hey, On Mon, 14 Feb 2011 17:26:29 +0100, Santiago Jimeno wrote: > OK. But this option is deprecated in Order Guidelines. True, but this is also not meant as the rule, but as the exception of the rule like I've written in my response to Steve. mkvmerge leaves a lot more space after the seekhead so that you can index several more additional level 1 elements without having to resort to creating two linked seekheads. This space is really small compared to leaving voids for e.g. tags, chapters or attachments. mkvmerge is a bit generous here though: it reservers 4096 bytes for the seekhead and the following void element even though that could be cut down to 256 bytes or less for 99.9% of all cases. Regards, mosu From slhomme at matroska.org Mon Feb 14 20:11:29 2011 From: slhomme at matroska.org (Steve Lhomme) Date: Mon, 14 Feb 2011 20:11:29 +0100 Subject: [Matroska-devel] Hi, question about the MKV tags In-Reply-To: References: <201102141108.52310.moritz@bunkus.org> <201102141424.59792.moritz@bunkus.org> Message-ID: On Mon, Feb 14, 2011 at 7:00 PM, Moritz Bunkus wrote: > On Mon, 14 Feb 2011 17:03:41 +0100, Steve Lhomme wrote: > >> So are we back to using double Seek Heads ? I thought this was >> deprecated. It adds extra complexity for a fundamental part that is >> supposed to make the file handling easier. > > It's almost trivial to support linked seekheads -- simply make seekhead > parsing recursive. > > Also it's not the standard behaviour of mkvmerge. But mmg's chapter > editor/track header editor and mkvpropedit will fall back to creating such > structures if there's not enough room before the first cluster for storing > the whole seekhead. There are only three options in such cases: > > 1. refuse to modify the file, > 2. remux the whole file into a temporary one & overwrite the original one > afterwards and > 3. create two linked seekheads, a small one before the first cluster and a > larger one at the back of the file. > > Like I said, this is the exception, not the rule. Yes, but whether it happens 50% of the time or 0.1%, players have to support it. And add extra code and extra test cases. Also I think both in terms of Matroska and WebM here. At least WebM is new and has new code in browsers (well, only in FireFox for sure). So far they took a strict policy on anything eccentric that is forbidden. I think the double and then triple, quadruple, etc) Seek head falls in that category. Plus, it is very bad for progressive download, which is how WebM works now. That's why for WebM it's strongly advised to put the Cues at the front. Seeking is an 'expensive' operation in HTTP. In the end I think it's better to take a level 1 element from the front to put it on the back to get room to update the SeekHead at the front (not the Segment Info or Track Info of course). The only case it's not possible is when adding a Level 1 element not found at the front and there was no room for a link to it near the Seek Head. That's why it should be highly recommended to add enough room after the Seek Head for a few level 1 elements. So that at least it can contain all known Level 1 elements and a few more for future compatibility. >> It is valid indeed but kinda defeat the point of the Seek Head if you >> find Level 1 elements before. > > The simplest algorithm that works both with seekable and with non-seekable > files is: > > while (!cluster_found) { > ?read_next_level1_element > ?if (is_cluster) > ? ?break; > ?else if (is_seekhead && stream_is_seekable) > ? ?parse_seekhead_and_read_other_level1_elements; > ?else if (is_track_headers) > ? ?parse_track_headers; > ?else if (is_segmentinfo) > ?... > } > > if (!segmentinfo_found || !track_headers_found) > ?error; Yes, it's very important to use the Seek Head as soon as it's found. Even for non seekable stream. In the case of HTTP I assume a new connection/thread has to be created to load an element not found close enough and then synchronisation between the main reader and that thread, if it can be avoided in the main use case, it's better. -- Steve Lhomme Matroska association Chairman From grok at zyxxyz.eu Tue Feb 15 13:36:46 2011 From: grok at zyxxyz.eu (grok) Date: Tue, 15 Feb 2011 12:36:46 +0000 Subject: [Matroska-devel] Official Tags Message-ID: Hi All, Another question would be the DB identifiers. Since they're attributes to EXTERNAL_DB, is anyone bothered about the name for the databases? So far I have come up with: IMDB - http://imdb.com TVDB - http://thetvdb.com TMDB - http://themoviedb.org IBBC - http://www.bbc.co.uk AMZN - http://amazon.{com,co.uk,fr,...} MBRZ - http://musicbrainz.org DSCG - http://discogs.com Perhaps 4 letters are too few? Perhaps any length would be appropriate or a top-level URL would be more desired instead of a (4 letter) identifier. On the other hand, FOURCC is an established (not necessarily good) practice. Any comments? -- Jaroslaw Zachwieja From boris.juraga at gmail.com Tue Feb 15 13:45:02 2011 From: boris.juraga at gmail.com (Boris Juraga) Date: Tue, 15 Feb 2011 13:45:02 +0100 Subject: [Matroska-devel] Hi, question about the MKV tags In-Reply-To: References: <201102141108.52310.moritz@bunkus.org> <201102141424.59792.moritz@bunkus.org> Message-ID: Well from the conversation till now i have one conclusion - no proper tags support is near, not without full remux. So i will use a workaround i was using before trying to use the tag system. I will create spec complying xml file containing the tags and called tags.xml, and instead of adding it to mkvmerge as a global tags xml file - i will add it as attachment. And it will be fixed size xml document. I think 5KB is more than enough for tags for movie or episode. and as it is fixed size, i will use my current tag\attachment reader to seek to it and simply over write it with the new tags.xml. As the files are exactly the same size no problems will occur. Simply if the new tags are bigger than 5KB i will remux. I cant think of a single problem with this solution, no one is reading tags at the moment so my app will work. From slhomme at matroska.org Tue Feb 15 16:01:19 2011 From: slhomme at matroska.org (Steve Lhomme) Date: Tue, 15 Feb 2011 16:01:19 +0100 Subject: [Matroska-devel] Hi, question about the MKV tags In-Reply-To: References: <201102141108.52310.moritz@bunkus.org> <201102141424.59792.moritz@bunkus.org> Message-ID: So there is no tag support now, so you're going to use a proprietary and limited and undocumented way to do it just for yourself ? Hoping the problem of doing it the clean way will solve by itself ? On Tue, Feb 15, 2011 at 1:45 PM, Boris Juraga wrote: > Well from the conversation till now i have one conclusion - no proper > tags support is near, not without full remux. So i will use a > workaround i was using before trying to use the tag system. I will > create spec complying xml file containing the tags and called > tags.xml, and instead of adding it to mkvmerge as a global tags xml > file - i will add it as attachment. And it will be fixed size xml > document. I think 5KB is more than enough for tags for movie or > episode. and as it is fixed size, i will use my current tag\attachment > reader to seek to it and simply over write it with the new tags.xml. > As the files are exactly the same size no problems will occur. Simply > if the new tags are bigger than 5KB i will remux. > > I cant think of a single problem with this solution, no one is reading > tags at the moment so my app will work. > _______________________________________________ > Matroska-devel mailing list > Matroska-devel at lists.matroska.org > http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel > Read Matroska-Devel on GMane: http://dir.gmane.org/gmane.comp.multimedia.matroska.devel > -- Steve Lhomme Matroska association Chairman From sjimeno at ya.com Tue Feb 15 18:47:43 2011 From: sjimeno at ya.com (Santiago Jimeno) Date: Tue, 15 Feb 2011 18:47:43 +0100 Subject: [Matroska-devel] Hi, question about the MKV tags In-Reply-To: References: <201102141108.52310.moritz@bunkus.org><201102141424.59792.moritz@bunkus.org> Message-ID: <2B150051BEDE49AE9AA22031A4BBCA92@JSASUS> I suppose that you now have seen the problem closely and you understand better what I am meaning from my first message . But you have surrendered soon. I take 2 months studying and working about Matroska Tags for writing an editor without remux. The code is very advanced. I have prepared everithing necessary for editing (reading, showing and writing of Tags and Attachments blocks and also handling of SeekHead and SegmentSize) I only have to finish writing one function "ApplyChanges" Here, all aspects related with the Tags edition are already developed. Also the relative thing to the Pictures deletion. In spite of the complexity of Tags edition, with nested tags, etc, I don't have problem. The true difficulty is Attachments, its independencie of Tags, its size, its file position and also the multiple locations that suppose the addici?n of this for the whole. Also Attachments (thanks to random apps) may have Pictures and Fonts blended in any order, independently of what Order Guidelines says. I summarize the situation: If there is only Tags -> there are 3 edition possibilities with two location combinations. Total (without repeating) 5 possibilities. Already implemented If Pics + Tags -> there are 10 edition possibilities with 4 location combinations. Total (without repeating) 34 possibilities. I only have written 7 of them. Surely the code already written could cover 80% or more than our necessities. But I should write code until for the less likely thing. Example: what happens if the space after SeekHead is only of 1 byte when VOID needs 2 bytes at least (ID and Length=0) For this reason I am proposing the changes that I said in my previous messages. Of them, the simple integration of Pictures inside Tags would suppose an enormous reduci?n of complexity (from 34 to 5 possibilities) And still less complexity if we also fix a definitive location. Then: Pictures or Tags? Or both together in one block? But the decision doesn't correspond me. Regards. Santiago ----- Original Message ----- From: "Steve Lhomme" To: "Discussion about the current and future development of Matroska" Sent: Tuesday, February 15, 2011 4:01 PM Subject: Re: [Matroska-devel] Hi, question about the MKV tags > So there is no tag support now, so you're going to use a proprietary > and limited and undocumented way to do it just for yourself ? Hoping > the problem of doing it the clean way will solve by itself ? > > On Tue, Feb 15, 2011 at 1:45 PM, Boris Juraga > wrote: >> Well from the conversation till now i have one conclusion - no proper >> tags support is near, not without full remux. So i will use a >> workaround i was using before trying to use the tag system. I will >> create spec complying xml file containing the tags and called >> tags.xml, and instead of adding it to mkvmerge as a global tags xml >> file - i will add it as attachment. And it will be fixed size xml >> document. I think 5KB is more than enough for tags for movie or >> episode. and as it is fixed size, i will use my current tag\attachment >> reader to seek to it and simply over write it with the new tags.xml. >> As the files are exactly the same size no problems will occur. Simply >> if the new tags are bigger than 5KB i will remux. >> >> I cant think of a single problem with this solution, no one is reading >> tags at the moment so my app will work. >> _______________________________________________ >> Matroska-devel mailing list >> Matroska-devel at lists.matroska.org >> http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel >> Read Matroska-Devel on GMane: >> http://dir.gmane.org/gmane.comp.multimedia.matroska.devel >> > > > > -- > Steve Lhomme > Matroska association Chairman > _______________________________________________ > Matroska-devel mailing list > Matroska-devel at lists.matroska.org > http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel > Read Matroska-Devel on GMane: > http://dir.gmane.org/gmane.comp.multimedia.matroska.devel > From boris.juraga at gmail.com Tue Feb 15 20:36:31 2011 From: boris.juraga at gmail.com (Boris Juraga) Date: Tue, 15 Feb 2011 20:36:31 +0100 Subject: [Matroska-devel] Hi, question about the MKV tags In-Reply-To: <2B150051BEDE49AE9AA22031A4BBCA92@JSASUS> References: <201102141108.52310.moritz@bunkus.org> <201102141424.59792.moritz@bunkus.org> <2B150051BEDE49AE9AA22031A4BBCA92@JSASUS> Message-ID: On Tue, Feb 15, 2011 at 6:47 PM, Santiago Jimeno wrote: > I suppose that you now have seen the problem closely and you understand > better what I am meaning from my first message . > But you have surrendered soon. > The only way i did this is mostly becouse you and your approach to tags in matroska. Instead of working with the others to solve the problem you just bring more and more problems to the table, most of which dont even relate to tags. So for now i will retire from tags so i dont create more confusion, and when there will be better (more optimistic) crowd i will be back. From slhomme at matroska.org Tue Feb 15 20:49:42 2011 From: slhomme at matroska.org (Steve Lhomme) Date: Tue, 15 Feb 2011 20:49:42 +0100 Subject: [Matroska-devel] Hi, question about the MKV tags In-Reply-To: <2B150051BEDE49AE9AA22031A4BBCA92@JSASUS> References: <201102141108.52310.moritz@bunkus.org> <201102141424.59792.moritz@bunkus.org> <2B150051BEDE49AE9AA22031A4BBCA92@JSASUS> Message-ID: Pictures in tags solve nothing and add more combinations, because they are already in use today. You can't discard the past like that. If you want to reduce the possible case you need to handle, always move the tags and the attachment at the end of the segment. No one is forcing you to make perfect files. In fact it's usually the way anything is coded. Start with the normal/easy case, and only later optimize. All we have talked about is how to make the most optimal files in the trickiest conditions. But none of this is mandatory. The only thing mandatory is to make valid files and void past data when you have moved them (no doublon). Steve On Tue, Feb 15, 2011 at 6:47 PM, Santiago Jimeno wrote: > I suppose that you now have seen the problem closely and you understand > better what I am meaning from my first message . > But you have surrendered soon. > > I take 2 months studying and working about Matroska Tags for writing an > editor without remux. > The code is very advanced. I have prepared everithing necessary for editing > (reading, showing and writing of Tags and Attachments blocks and also > handling of SeekHead and SegmentSize) > I only have to finish writing one function "ApplyChanges" > Here, all aspects related with the Tags edition are already developed. Also > the relative thing to the Pictures deletion. > In spite of the complexity of Tags edition, with nested tags, etc, I don't > have problem. > The true difficulty is Attachments, its independencie of Tags, its size, its > file position and also the multiple locations that suppose the addici?n of > this for the whole. > Also Attachments (thanks to random apps) may have Pictures and Fonts blended > in any order, independently of what Order Guidelines says. > > I summarize the situation: > If there is only Tags -> ?there are 3 edition possibilities with two > location combinations. Total (without repeating) 5 possibilities. Already > implemented > If Pics + Tags -> ?there are 10 edition possibilities with 4 location > combinations. ?Total (without repeating) 34 possibilities. I only have > written 7 of them. > > Surely the code already written could cover 80% or more than our > necessities. But I should write code until for the less likely thing. > Example: what happens if the space after SeekHead is only of 1 byte when > VOID needs 2 bytes at least (ID and Length=0) > > For this reason I am proposing the changes that I said in my previous > messages. > Of them, the simple integration of Pictures inside Tags would suppose an > enormous reduci?n of complexity (from 34 to 5 possibilities) > And still less complexity if we also fix a definitive location. > Then: Pictures or Tags? Or both together in one block? > But the decision doesn't correspond me. > > Regards. Santiago > > ----- Original Message ----- From: "Steve Lhomme" > To: "Discussion about the current and future development of Matroska" > > Sent: Tuesday, February 15, 2011 4:01 PM > Subject: Re: [Matroska-devel] Hi, question about the MKV tags > > >> So there is no tag support now, so you're going to use a proprietary >> and limited and undocumented way to do it just for yourself ? Hoping >> the problem of doing it the clean way will solve by itself ? >> >> On Tue, Feb 15, 2011 at 1:45 PM, Boris Juraga >> wrote: >>> >>> Well from the conversation till now i have one conclusion - no proper >>> tags support is near, not without full remux. So i will use a >>> workaround i was using before trying to use the tag system. I will >>> create spec complying xml file containing the tags and called >>> tags.xml, and instead of adding it to mkvmerge as a global tags xml >>> file - i will add it as attachment. And it will be fixed size xml >>> document. I think 5KB is more than enough for tags for movie or >>> episode. and as it is fixed size, i will use my current tag\attachment >>> reader to seek to it and simply over write it with the new tags.xml. >>> As the files are exactly the same size no problems will occur. Simply >>> if the new tags are bigger than 5KB i will remux. >>> >>> I cant think of a single problem with this solution, no one is reading >>> tags at the moment so my app will work. >>> _______________________________________________ >>> Matroska-devel mailing list >>> Matroska-devel at lists.matroska.org >>> http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel >>> Read Matroska-Devel on GMane: >>> http://dir.gmane.org/gmane.comp.multimedia.matroska.devel >>> >> >> >> >> -- >> Steve Lhomme >> Matroska association Chairman >> _______________________________________________ >> Matroska-devel mailing list >> Matroska-devel at lists.matroska.org >> http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel >> Read Matroska-Devel on GMane: >> http://dir.gmane.org/gmane.comp.multimedia.matroska.devel >> > > > _______________________________________________ > Matroska-devel mailing list > Matroska-devel at lists.matroska.org > http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel > Read Matroska-Devel on GMane: > http://dir.gmane.org/gmane.comp.multimedia.matroska.devel > -- Steve Lhomme Matroska association Chairman From slhomme at matroska.org Tue Feb 15 21:01:59 2011 From: slhomme at matroska.org (Steve Lhomme) Date: Tue, 15 Feb 2011 21:01:59 +0100 Subject: [Matroska-devel] Official Tags In-Reply-To: References: Message-ID: On Tue, Feb 15, 2011 at 1:36 PM, grok wrote: > Since they're attributes to EXTERNAL_DB, is anyone bothered about the > name for the databases? So far I have come up with: > > IMDB - http://imdb.com > TVDB - http://thetvdb.com > TMDB - http://themoviedb.org > IBBC - http://www.bbc.co.uk > > AMZN - http://amazon.{com,co.uk,fr,...} > MBRZ - http://musicbrainz.org > DSCG - http://discogs.com > > Perhaps 4 letters are too few? Perhaps any length would be appropriate > or a top-level URL would be more desired instead of a (4 letter) > identifier. On the other hand, FOURCC is an established (not > necessarily good) practice. We don't have size limits/restrictions for tags. One of the idea is that some tag editors present the tags as raw pairs to the users. So it's better if the name make sense to the user. The Amazon case is good example of the issue with just a name. It would rather be AMAZON_US/AMAZON_UK/AMAZON_FR/AMAZON_DE or amazon.com/amazon.co.uk/amazon.fr/amazon.de. I'm still not sure which is better. In both case you don't get the actual URL to get the required information (and there may be more than one, XML and JSON output for ex). So maybe just a generic uppercase name for the site is enough. Steve > Any comments? > -- > Jaroslaw Zachwieja > _______________________________________________ > Matroska-devel mailing list > Matroska-devel at lists.matroska.org > http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel > Read Matroska-Devel on GMane: http://dir.gmane.org/gmane.comp.multimedia.matroska.devel > -- Steve Lhomme Matroska association Chairman From pkoshevoy at gmail.com Tue Feb 15 21:11:23 2011 From: pkoshevoy at gmail.com (Pavel Koshevoy) Date: Tue, 15 Feb 2011 13:11:23 -0700 Subject: [Matroska-devel] Hi, question about the MKV tags In-Reply-To: References: <201102141108.52310.moritz@bunkus.org> <201102141424.59792.moritz@bunkus.org> <2B150051BEDE49AE9AA22031A4BBCA92@JSASUS> Message-ID: <4D5ADDEB.2090502@gmail.com> Hi, I've been following this discussion, and I can see the issues. I agree with Steve here, to simplify the Tags problem it is better to do what is easy. Placing tags are at the end the file may not be optimal for streaming, but that is a problem that already has a solution in the form of remuxing. Not every tool (tags editor) should attempt to solve every problem. Personally, I know I am not interested in writing Void elements into files. I want my mkv/webm files to be as small as possible, with no space wasted. This is just as valid as the goal of making files easier to edit (tags, attachments). I've taken the implementation of my goal pretty far by creating a 3-pass muxer: 1 -- remove all void elements so no space is wasted, calculate element positions 2 -- optimize number of bytes required to encode element position variable length integers 3 -- write the file Pavel. On 2/15/2011 12:49 PM, Steve Lhomme wrote: > Pictures in tags solve nothing and add more combinations, because they > are already in use today. You can't discard the past like that. > > If you want to reduce the possible case you need to handle, always > move the tags and the attachment at the end of the segment. No one is > forcing you to make perfect files. In fact it's usually the way > anything is coded. Start with the normal/easy case, and only later > optimize. All we have talked about is how to make the most optimal > files in the trickiest conditions. But none of this is mandatory. The > only thing mandatory is to make valid files and void past data when > you have moved them (no doublon). > > Steve > > On Tue, Feb 15, 2011 at 6:47 PM, Santiago Jimeno wrote: >> I suppose that you now have seen the problem closely and you understand >> better what I am meaning from my first message . >> But you have surrendered soon. >> >> I take 2 months studying and working about Matroska Tags for writing an >> editor without remux. >> The code is very advanced. I have prepared everithing necessary for editing >> (reading, showing and writing of Tags and Attachments blocks and also >> handling of SeekHead and SegmentSize) >> I only have to finish writing one function "ApplyChanges" >> Here, all aspects related with the Tags edition are already developed. Also >> the relative thing to the Pictures deletion. >> In spite of the complexity of Tags edition, with nested tags, etc, I don't >> have problem. >> The true difficulty is Attachments, its independencie of Tags, its size, its >> file position and also the multiple locations that suppose the addici?n of >> this for the whole. >> Also Attachments (thanks to random apps) may have Pictures and Fonts blended >> in any order, independently of what Order Guidelines says. >> >> I summarize the situation: >> If there is only Tags -> there are 3 edition possibilities with two >> location combinations. Total (without repeating) 5 possibilities. Already >> implemented >> If Pics + Tags -> there are 10 edition possibilities with 4 location >> combinations. Total (without repeating) 34 possibilities. I only have >> written 7 of them. >> >> Surely the code already written could cover 80% or more than our >> necessities. But I should write code until for the less likely thing. >> Example: what happens if the space after SeekHead is only of 1 byte when >> VOID needs 2 bytes at least (ID and Length=0) >> >> For this reason I am proposing the changes that I said in my previous >> messages. >> Of them, the simple integration of Pictures inside Tags would suppose an >> enormous reduci?n of complexity (from 34 to 5 possibilities) >> And still less complexity if we also fix a definitive location. >> Then: Pictures or Tags? Or both together in one block? >> But the decision doesn't correspond me. >> >> Regards. Santiago >> >> ----- Original Message ----- From: "Steve Lhomme" >> To: "Discussion about the current and future development of Matroska" >> >> Sent: Tuesday, February 15, 2011 4:01 PM >> Subject: Re: [Matroska-devel] Hi, question about the MKV tags >> >> >>> So there is no tag support now, so you're going to use a proprietary >>> and limited and undocumented way to do it just for yourself ? Hoping >>> the problem of doing it the clean way will solve by itself ? >>> >>> On Tue, Feb 15, 2011 at 1:45 PM, Boris Juraga >>> wrote: >>>> Well from the conversation till now i have one conclusion - no proper >>>> tags support is near, not without full remux. So i will use a >>>> workaround i was using before trying to use the tag system. I will >>>> create spec complying xml file containing the tags and called >>>> tags.xml, and instead of adding it to mkvmerge as a global tags xml >>>> file - i will add it as attachment. And it will be fixed size xml >>>> document. I think 5KB is more than enough for tags for movie or >>>> episode. and as it is fixed size, i will use my current tag\attachment >>>> reader to seek to it and simply over write it with the new tags.xml. >>>> As the files are exactly the same size no problems will occur. Simply >>>> if the new tags are bigger than 5KB i will remux. >>>> >>>> I cant think of a single problem with this solution, no one is reading >>>> tags at the moment so my app will work. >>>> _______________________________________________ >>>> Matroska-devel mailing list >>>> Matroska-devel at lists.matroska.org >>>> http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel >>>> Read Matroska-Devel on GMane: >>>> http://dir.gmane.org/gmane.comp.multimedia.matroska.devel >>>> >>> >>> >>> -- >>> Steve Lhomme >>> Matroska association Chairman >>> _______________________________________________ >>> Matroska-devel mailing list >>> Matroska-devel at lists.matroska.org >>> http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel >>> Read Matroska-Devel on GMane: >>> http://dir.gmane.org/gmane.comp.multimedia.matroska.devel >>> >> >> _______________________________________________ >> Matroska-devel mailing list >> Matroska-devel at lists.matroska.org >> http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel >> Read Matroska-Devel on GMane: >> http://dir.gmane.org/gmane.comp.multimedia.matroska.devel >> > > From grok at zyxxyz.eu Tue Feb 15 21:44:35 2011 From: grok at zyxxyz.eu (Jaroslaw Zachwieja) Date: Tue, 15 Feb 2011 20:44:35 +0000 Subject: [Matroska-devel] Official Tags In-Reply-To: References: Message-ID: On 15 February 2011 20:01, Steve Lhomme wrote: > The Amazon case is good example of the issue with just a name. It > would rather be AMAZON_US/AMAZON_UK/AMAZON_FR/AMAZON_DE or > amazon.com/amazon.co.uk/amazon.fr/amazon.de. I'm still not sure which > is better. In both case you don't get the actual URL to get the > required information (and there may be more than one, XML and JSON > output for ex). So maybe just a generic uppercase name for the site is > enough. I like this idea -- and I would even take it further. How about taking the FQDN of the database as the capitalised tag: AMAZON_CO_UK / AMAZON_DE / IMDB_COM / THEMOVIEDB_ORG / BBC_CO_UK / ... I agree that the actual URL for the XML / JSON may not be a good idea, sites tend to change things -- this should be left to the interpreting software, especially since to access most APIs a key is required; this way the software can be kept up-to-date with the API. However the FQDN is more of a company asset these days and this tends to be preserved over time. Another benefit of this approach is that we can still keep the EXTERNAL_DB tag as official and keep the attribute names specified as capitalised FQDN with s/\./_/g in the standard. If no one objects to the above, I'll get on to writing example tagfiles and presenting them here for approval. -- grok From slhomme at matroska.org Tue Feb 15 22:08:29 2011 From: slhomme at matroska.org (Steve Lhomme) Date: Tue, 15 Feb 2011 22:08:29 +0100 Subject: [Matroska-devel] Official Tags In-Reply-To: References: Message-ID: Sounds all good to me. On Tue, Feb 15, 2011 at 9:44 PM, Jaroslaw Zachwieja wrote: > On 15 February 2011 20:01, Steve Lhomme wrote: >> The Amazon case is good example of the issue with just a name. It >> would rather be AMAZON_US/AMAZON_UK/AMAZON_FR/AMAZON_DE or >> amazon.com/amazon.co.uk/amazon.fr/amazon.de. I'm still not sure which >> is better. In both case you don't get the actual URL to get the >> required information (and there may be more than one, XML and JSON >> output for ex). So maybe just a generic uppercase name for the site is >> enough. > > I like this idea -- and I would even take it further. > > How about taking the FQDN of the database as the capitalised tag: > > AMAZON_CO_UK / AMAZON_DE / IMDB_COM / THEMOVIEDB_ORG / BBC_CO_UK / ... > > I agree that the actual URL for the XML / JSON may not be a good idea, > sites tend to change things -- this should be left to the interpreting > software, especially since to access most APIs a key is required; this > way the software can be kept up-to-date with the API. However the FQDN > is more of a company asset these days and this tends to be preserved > over time. > > Another benefit of this approach is that we can still keep the > EXTERNAL_DB tag as official and keep the attribute names specified as > capitalised FQDN with s/\./_/g in the standard. > > If no one objects to the above, I'll get on to writing example > tagfiles and presenting them here for approval. > -- > grok > _______________________________________________ > Matroska-devel mailing list > Matroska-devel at lists.matroska.org > http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel > Read Matroska-Devel on GMane: http://dir.gmane.org/gmane.comp.multimedia.matroska.devel > -- Steve Lhomme Matroska association Chairman From sjimeno at ya.com Tue Feb 15 22:53:08 2011 From: sjimeno at ya.com (Santiago Jimeno) Date: Tue, 15 Feb 2011 22:53:08 +0100 Subject: [Matroska-devel] Hi, question about the MKV tags In-Reply-To: <4D5ADDEB.2090502@gmail.com> References: <201102141108.52310.moritz@bunkus.org> <201102141424.59792.moritz@bunkus.org> <2B150051BEDE49AE9AA22031A4BBCA92@JSASUS> <4D5ADDEB.2090502@gmail.com> Message-ID: Hi Pavel I know remuxing file is a possible solution. I have never questioned it. But this cannot make it everybody. It is also necessary to keep in mind the number of files to process and the time of process. My goal is to make an editor that can be managed by everybody. Showing and editing Tags in a simple way for people that don't know about Matroska functionality and much less about XML . AdingTags by means of a XML file is easy with mkvmerge and besides making it well, also remuxing file. But this is only in the hand of some developers that know XML, and not all. Plus, it is not useful to make what is already made. In any event if I point out the problems it is because I am working on it. Some of them I have already given practical solution in my code and some suggestions have been accepted. Regards. Santiago ----- Original Message ----- From: "Pavel Koshevoy" To: Sent: Tuesday, February 15, 2011 9:11 PM Subject: Re: [Matroska-devel] Hi, question about the MKV tags Hi, I've been following this discussion, and I can see the issues. I agree with Steve here, to simplify the Tags problem it is better to do what is easy. Placing tags are at the end the file may not be optimal for streaming, but that is a problem that already has a solution in the form of remuxing. Not every tool (tags editor) should attempt to solve every problem. Personally, I know I am not interested in writing Void elements into files. I want my mkv/webm files to be as small as possible, with no space wasted. This is just as valid as the goal of making files easier to edit (tags, attachments). I've taken the implementation of my goal pretty far by creating a 3-pass muxer: 1 -- remove all void elements so no space is wasted, calculate element positions 2 -- optimize number of bytes required to encode element position variable length integers 3 -- write the file Pavel. On 2/15/2011 12:49 PM, Steve Lhomme wrote: > Pictures in tags solve nothing and add more combinations, because they > are already in use today. You can't discard the past like that. > > If you want to reduce the possible case you need to handle, always > move the tags and the attachment at the end of the segment. No one is > forcing you to make perfect files. In fact it's usually the way > anything is coded. Start with the normal/easy case, and only later > optimize. All we have talked about is how to make the most optimal > files in the trickiest conditions. But none of this is mandatory. The > only thing mandatory is to make valid files and void past data when > you have moved them (no doublon). > > Steve > > On Tue, Feb 15, 2011 at 6:47 PM, Santiago Jimeno wrote: >> I suppose that you now have seen the problem closely and you understand >> better what I am meaning from my first message . >> But you have surrendered soon. >> >> I take 2 months studying and working about Matroska Tags for writing an >> editor without remux. >> The code is very advanced. I have prepared everithing necessary for >> editing >> (reading, showing and writing of Tags and Attachments blocks and also >> handling of SeekHead and SegmentSize) >> I only have to finish writing one function "ApplyChanges" >> Here, all aspects related with the Tags edition are already developed. >> Also >> the relative thing to the Pictures deletion. >> In spite of the complexity of Tags edition, with nested tags, etc, I >> don't >> have problem. >> The true difficulty is Attachments, its independencie of Tags, its size, >> its >> file position and also the multiple locations that suppose the addici?n >> of >> this for the whole. >> Also Attachments (thanks to random apps) may have Pictures and Fonts >> blended >> in any order, independently of what Order Guidelines says. >> >> I summarize the situation: >> If there is only Tags -> there are 3 edition possibilities with two >> location combinations. Total (without repeating) 5 possibilities. Already >> implemented >> If Pics + Tags -> there are 10 edition possibilities with 4 location >> combinations. Total (without repeating) 34 possibilities. I only have >> written 7 of them. >> >> Surely the code already written could cover 80% or more than our >> necessities. But I should write code until for the less likely thing. >> Example: what happens if the space after SeekHead is only of 1 byte when >> VOID needs 2 bytes at least (ID and Length=0) >> >> For this reason I am proposing the changes that I said in my previous >> messages. >> Of them, the simple integration of Pictures inside Tags would suppose an >> enormous reduci?n of complexity (from 34 to 5 possibilities) >> And still less complexity if we also fix a definitive location. >> Then: Pictures or Tags? Or both together in one block? >> But the decision doesn't correspond me. >> >> Regards. Santiago >> >> ----- Original Message ----- From: "Steve Lhomme" >> To: "Discussion about the current and future development of Matroska" >> >> Sent: Tuesday, February 15, 2011 4:01 PM >> Subject: Re: [Matroska-devel] Hi, question about the MKV tags >> >> >>> So there is no tag support now, so you're going to use a proprietary >>> and limited and undocumented way to do it just for yourself ? Hoping >>> the problem of doing it the clean way will solve by itself ? >>> >>> On Tue, Feb 15, 2011 at 1:45 PM, Boris Juraga >>> wrote: >>>> Well from the conversation till now i have one conclusion - no proper >>>> tags support is near, not without full remux. So i will use a >>>> workaround i was using before trying to use the tag system. I will >>>> create spec complying xml file containing the tags and called >>>> tags.xml, and instead of adding it to mkvmerge as a global tags xml >>>> file - i will add it as attachment. And it will be fixed size xml >>>> document. I think 5KB is more than enough for tags for movie or >>>> episode. and as it is fixed size, i will use my current tag\attachment >>>> reader to seek to it and simply over write it with the new tags.xml. >>>> As the files are exactly the same size no problems will occur. Simply >>>> if the new tags are bigger than 5KB i will remux. >>>> >>>> I cant think of a single problem with this solution, no one is reading >>>> tags at the moment so my app will work. >>>> _______________________________________________ >>>> Matroska-devel mailing list >>>> Matroska-devel at lists.matroska.org >>>> http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel >>>> Read Matroska-Devel on GMane: >>>> http://dir.gmane.org/gmane.comp.multimedia.matroska.devel >>>> >>> >>> >>> -- >>> Steve Lhomme >>> Matroska association Chairman >>> _______________________________________________ >>> Matroska-devel mailing list >>> Matroska-devel at lists.matroska.org >>> http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel >>> Read Matroska-Devel on GMane: >>> http://dir.gmane.org/gmane.comp.multimedia.matroska.devel >>> >> >> _______________________________________________ >> Matroska-devel mailing list >> Matroska-devel at lists.matroska.org >> http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel >> Read Matroska-Devel on GMane: >> http://dir.gmane.org/gmane.comp.multimedia.matroska.devel >> > > _______________________________________________ Matroska-devel mailing list Matroska-devel at lists.matroska.org http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel Read Matroska-Devel on GMane: http://dir.gmane.org/gmane.comp.multimedia.matroska.devel From sjimeno at ya.com Wed Feb 16 13:25:34 2011 From: sjimeno at ya.com (Santiago Jimeno) Date: Wed, 16 Feb 2011 13:25:34 +0100 Subject: [Matroska-devel] Hi, question about the MKV tags In-Reply-To: References: <201102141108.52310.moritz@bunkus.org><201102141424.59792.moritz@bunkus.org><2B150051BEDE49AE9AA22031A4BBCA92@JSASUS> Message-ID: <5E1575BAE87C43B4B446C17E43AF4C6C@JSASUS> Hi Steve It doesn't exist an easy way and another difficult way of approaching to the work with metadata. I see two ways: or it is approached or it is not approached. It seems that up to now the election is the second. I don't intend to make perfect programs. But when editing I have to foresee the problems. And if my code doesn't foresee it when writing data will damage the file and I are not a dilettante. As for the working technique I agree with you: "Start with the normal/easy case, and only later optimize." I have worked this way up to now. The structure of Matroska Tags is the most complex than all Tags systems. But I found interesting and it added new aspects. It was worthwhile to attempt it. Once I resolved the complex aspects of Tags and once I have prepared the added/changed data I had to write them. This was then the work normal/easy. The outline of ApplyChanges in pseudo-code is: If Hastag (previous tag) If HasDelete Delete (2 locations) else if HasChanges if Size < = Old Size + padding Write + padding (2 locations) else Write at end Else (No Tag) if HasChanges (New) Write at end This code works perfectly and without errors. Now it was necessary to expand it with Pictures. And in that point we are. >From the simple previous code, I pass to study the possibilities and I meet with 32. If I don't want to damage the file I should not leave to contemplate any, although it is not very used: If there is Tags, Pictures or not If Delete or Change/Add for each one 2 Locations (before and after cluster) for each one And I only think about the possibility to use padding that there is just after (still not other VOID elements ). The code, if there is only Attachments, would be identical to the previous one. But now there are two separate blocks. You try to group them in combinations of two elements and to include them on outline above. The proportion grows in a geometric way. It is still more complex than the supposed complexity of Tags structure that made desist to so much people, and also much more than what Mosu said about SekHead-Void. I wonder if it would be this the reason of desisting. I have not invented any problem. They were and are there. I have limited to point out them and to propose possible alternative according my working experience with other Tags system. And I don't also think that to point out them is pessimistic. That depends on each person's character. As these were delicate aspects of Matroska structure (it seems not understood), I told you we treated them in private if you had interest. If I wrote again to the mail list is because you requested it to me. What to do? I think about several options 1- Work with what there is and just as it is (obviating and ignoring the problems) 2- Study background problem, isolating him and to expose it to the community 3- Propose possible alternative or changes (mistaken or not) 4- Implement Tags and to leave Pictures (some app would work with Pictures and others with Tags (?)) 5- Abandon the work I had opted for 2 and 3. But I should maybe choose another option. Regards. Santiago ----- Original Message ----- From: "Steve Lhomme" To: "Discussion about the current and future development of Matroska" Sent: Tuesday, February 15, 2011 8:49 PM Subject: Re: [Matroska-devel] Hi, question about the MKV tags Pictures in tags solve nothing and add more combinations, because they are already in use today. You can't discard the past like that. If you want to reduce the possible case you need to handle, always move the tags and the attachment at the end of the segment. No one is forcing you to make perfect files. In fact it's usually the way anything is coded. Start with the normal/easy case, and only later optimize. All we have talked about is how to make the most optimal files in the trickiest conditions. But none of this is mandatory. The only thing mandatory is to make valid files and void past data when you have moved them (no doublon). Steve On Tue, Feb 15, 2011 at 6:47 PM, Santiago Jimeno wrote: > I suppose that you now have seen the problem closely and you understand > better what I am meaning from my first message . > But you have surrendered soon. > > I take 2 months studying and working about Matroska Tags for writing an > editor without remux. > The code is very advanced. I have prepared everithing necessary for > editing > (reading, showing and writing of Tags and Attachments blocks and also > handling of SeekHead and SegmentSize) > I only have to finish writing one function "ApplyChanges" > Here, all aspects related with the Tags edition are already developed. > Also > the relative thing to the Pictures deletion. > In spite of the complexity of Tags edition, with nested tags, etc, I don't > have problem. > The true difficulty is Attachments, its independencie of Tags, its size, > its > file position and also the multiple locations that suppose the addici?n of > this for the whole. > Also Attachments (thanks to random apps) may have Pictures and Fonts > blended > in any order, independently of what Order Guidelines says. > > I summarize the situation: > If there is only Tags -> there are 3 edition possibilities with two > location combinations. Total (without repeating) 5 possibilities. Already > implemented > If Pics + Tags -> there are 10 edition possibilities with 4 location > combinations. Total (without repeating) 34 possibilities. I only have > written 7 of them. > > Surely the code already written could cover 80% or more than our > necessities. But I should write code until for the less likely thing. > Example: what happens if the space after SeekHead is only of 1 byte when > VOID needs 2 bytes at least (ID and Length=0) > > For this reason I am proposing the changes that I said in my previous > messages. > Of them, the simple integration of Pictures inside Tags would suppose an > enormous reduci?n of complexity (from 34 to 5 possibilities) > And still less complexity if we also fix a definitive location. > Then: Pictures or Tags? Or both together in one block? > But the decision doesn't correspond me. > > Regards. Santiago > > ----- Original Message ----- From: "Steve Lhomme" > To: "Discussion about the current and future development of Matroska" > > Sent: Tuesday, February 15, 2011 4:01 PM > Subject: Re: [Matroska-devel] Hi, question about the MKV tags > > >> So there is no tag support now, so you're going to use a proprietary >> and limited and undocumented way to do it just for yourself ? Hoping >> the problem of doing it the clean way will solve by itself ? >> >> On Tue, Feb 15, 2011 at 1:45 PM, Boris Juraga >> wrote: >>> >>> Well from the conversation till now i have one conclusion - no proper >>> tags support is near, not without full remux. So i will use a >>> workaround i was using before trying to use the tag system. I will >>> create spec complying xml file containing the tags and called >>> tags.xml, and instead of adding it to mkvmerge as a global tags xml >>> file - i will add it as attachment. And it will be fixed size xml >>> document. I think 5KB is more than enough for tags for movie or >>> episode. and as it is fixed size, i will use my current tag\attachment >>> reader to seek to it and simply over write it with the new tags.xml. >>> As the files are exactly the same size no problems will occur. Simply >>> if the new tags are bigger than 5KB i will remux. >>> >>> I cant think of a single problem with this solution, no one is reading >>> tags at the moment so my app will work. >>> _______________________________________________ >>> Matroska-devel mailing list >>> Matroska-devel at lists.matroska.org >>> http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel >>> Read Matroska-Devel on GMane: >>> http://dir.gmane.org/gmane.comp.multimedia.matroska.devel >>> >> >> >> >> -- >> Steve Lhomme >> Matroska association Chairman >> _______________________________________________ >> Matroska-devel mailing list >> Matroska-devel at lists.matroska.org >> http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel >> Read Matroska-Devel on GMane: >> http://dir.gmane.org/gmane.comp.multimedia.matroska.devel >> > > > _______________________________________________ > Matroska-devel mailing list > Matroska-devel at lists.matroska.org > http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel > Read Matroska-Devel on GMane: > http://dir.gmane.org/gmane.comp.multimedia.matroska.devel > -- Steve Lhomme Matroska association Chairman _______________________________________________ Matroska-devel mailing list Matroska-devel at lists.matroska.org http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel Read Matroska-Devel on GMane: http://dir.gmane.org/gmane.comp.multimedia.matroska.devel From moritz at bunkus.org Wed Feb 16 13:36:25 2011 From: moritz at bunkus.org (Moritz Bunkus) Date: Wed, 16 Feb 2011 13:36:25 +0100 Subject: [Matroska-devel] Hi, question about the MKV tags In-Reply-To: <5E1575BAE87C43B4B446C17E43AF4C6C@JSASUS> References: <5E1575BAE87C43B4B446C17E43AF4C6C@JSASUS> Message-ID: <201102161336.25728.moritz@bunkus.org> Hey, On Wednesday 16 February 2011 13:25:34 Santiago Jimeno wrote: > If Hastag (previous tag) > If HasDelete > Delete (2 locations) > else if HasChanges > if Size < = Old Size + padding > Write + padding (2 locations) > else > Write at end > Else (No Tag) > if HasChanges (New) > Write at end Sounds more or less reasonable. But: > The code, if there is only Attachments, would be identical to the > previous one. But now there are two separate blocks. You try to group > them in combinations of two elements and to include them on outline > above. The proportion grows in a geometric way. Not really. A pragmatic approach would be: 1. Overwrite all existing elements you want to replace (tags & attachments) with void elements 2. Overwrite all consecutive void elements with a single one occupying the space the consecutive ones occupied before 3. For each element you want to write: 3.1. Look for a void element with enough space for the element. If found replace void element with element to write & create new smaller void behind it. 3.2. If not found write new element at the end. 4. Update metaseek elements etc. This may not result in 100% optimal files in any case, but like Steve said that is not the goal. It will result in perfectly valid files though. And it scales perfectly well with the number of elements you need to write (e.g. if you decide to modify chapters as well for some reason). > I have not invented any problem. They were and are there. From my point of view the problem you're having is that you insist on creating optimal files. While being a noble goal it is not really necessary at this stage. Regards, Mosu -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From sjimeno at ya.com Wed Feb 16 14:16:29 2011 From: sjimeno at ya.com (Santiago Jimeno) Date: Wed, 16 Feb 2011 14:16:29 +0100 Subject: [Matroska-devel] Hi, question about the MKV tags In-Reply-To: <201102161336.25728.moritz@bunkus.org> References: <5E1575BAE87C43B4B446C17E43AF4C6C@JSASUS> <201102161336.25728.moritz@bunkus.org> Message-ID: Thank Mosu. I already have developed my outline. I will compare it with your suggestion of pragmatic approach But my primordial goal is that the file is not damaged. Regards. Santiago ----- Original Message ----- From: "Moritz Bunkus" To: Sent: Wednesday, February 16, 2011 1:36 PM Subject: Re: [Matroska-devel] Hi, question about the MKV tags From moritz at bunkus.org Wed Feb 16 14:25:36 2011 From: moritz at bunkus.org (Moritz Bunkus) Date: Wed, 16 Feb 2011 14:25:36 +0100 Subject: [Matroska-devel] Hi, question about the MKV tags In-Reply-To: References: <201102161336.25728.moritz@bunkus.org> Message-ID: <201102161425.36232.moritz@bunkus.org> Hey, On Wednesday 16 February 2011 14:16:29 Santiago Jimeno wrote: > I already have developed my outline. I will compare it with your suggestion > of pragmatic approach > But my primordial goal is that the file is not damaged. Don't get me wrong: My approach doesn't damage the file in any way. At worst it will place an element somewhere it might not be found so easily in certain situations (e.g. tags at the end of the file are not found if the file is streamed and the streaming method doesn't support seeking). But those disadvantages are present with the other proposed methods as well. Meaning: my worst case scenario is still 100% valid, and in situations where random access to a file is available the content will be found by demuxers that are implemented correctly. Regards, Mosu -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From sjimeno at ya.com Wed Feb 16 15:17:10 2011 From: sjimeno at ya.com (Santiago Jimeno) Date: Wed, 16 Feb 2011 15:17:10 +0100 Subject: [Matroska-devel] Hi, question about the MKV tags In-Reply-To: <201102161425.36232.moritz@bunkus.org> References: <201102161336.25728.moritz@bunkus.org> <201102161425.36232.moritz@bunkus.org> Message-ID: <3187389B9C3143E29BEE8F5C68386CC6@JSASUS> OK. Thank you again I didn't refer to your approach when I said I don't want to damage the file. I find your approach very interesting, but I want to see it more slowly and to compare it with mine. My outline depends on the inexpert user's orders and it is based on combinations of 2. But one of those combinations is that one of both elements won't modify. And therefore I don't need overwriting with void. It is one of the things that at first sight I need to revise. A question: Did you test the app. I put in the link? I have added the modifications about random elements. Apply is disabled, but I need opinions on the general and visual aspects. Regards. Santiago ----- Original Message ----- From: "Moritz Bunkus" To: Sent: Wednesday, February 16, 2011 2:25 PM Subject: Re: [Matroska-devel] Hi, question about the MKV tags > _______________________________________________ > Matroska-devel mailing list > Matroska-devel at lists.matroska.org > http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel > Read Matroska-Devel on GMane: > http://dir.gmane.org/gmane.comp.multimedia.matroska.devel From moritz at bunkus.org Wed Feb 16 15:21:18 2011 From: moritz at bunkus.org (Moritz Bunkus) Date: Wed, 16 Feb 2011 15:21:18 +0100 Subject: [Matroska-devel] Hi, question about the MKV tags In-Reply-To: <3187389B9C3143E29BEE8F5C68386CC6@JSASUS> References: <201102161425.36232.moritz@bunkus.org> <3187389B9C3143E29BEE8F5C68386CC6@JSASUS> Message-ID: <201102161521.20947.moritz@bunkus.org> Hey, On Wednesday 16 February 2011 15:17:10 Santiago Jimeno wrote: > A question: Did you test the app. I put in the link? > I have added the modifications about random elements. Apply is disabled, > but I need opinions on the general and visual aspects. So far I haven't. I'll test it this weekend (I won't have time before Sunday, sorry). Regards, Mosu -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From dan6992 at hotmail.com Wed Feb 16 22:57:25 2011 From: dan6992 at hotmail.com (Dan Haddix) Date: Wed, 16 Feb 2011 21:57:25 +0000 Subject: [Matroska-devel] S_DVBSUB Message-ID: I'm new to this list, and MKV in general, but I've just read the threads about how you plan to handle the new S_DVBSUB type and I completely disagree with the design. I understand the reasoning behind it, since MKV was not designed to hold multiple sub-streams in a single track, but you're basically redesigning an established, widely used, standard because it doesn't fit into MKVs normal usage. The method you've proposed is going to force muxers to parse the real DVB packets into separate tracks for storage inside the MKV and then the player/demuxer to recombine those tracks back into their original format so that their decoders, which were written to handle the packets as they are stored in TS, can properly parse them. This seems like a very arrogant way to handle it. The TS format wasn't really designed to hold multiple sub-streams on a single PID either, but the DVB subtitle format still does it. Why should MKV get to redesign the format just because you guys disagree with the established design? I personally think that DVB subtitle packets should be stored in a single MKV track as-is with the CodecPrivate data set to the same data used in the descriptor section of the TS PMT. This will allow applications that already support the TS DVB subtitle format to easily add support for DVB subtitles in MKV because they wont have to do any special parsing other then decoding the CodecPrivate to simulate a TS PMT entry. I think that making it this simple will increase the chances the format will be adopted by standalone players and applications which are not written by the open source community. Anyway that's my opinion. If you disagree then I purpose that you add a new format called S_DVBSUB/TS which stores the packets as described above. We'll see which one catches on faster. Dan -------------- next part -------------- An HTML attachment was scrubbed... URL: From sjimeno at ya.com Thu Feb 17 11:50:16 2011 From: sjimeno at ya.com (Santiago Jimeno) Date: Thu, 17 Feb 2011 11:50:16 +0100 Subject: [Matroska-devel] Hi, question about the MKV tags In-Reply-To: <201102161336.25728.moritz@bunkus.org> References: <5E1575BAE87C43B4B446C17E43AF4C6C@JSASUS> <201102161336.25728.moritz@bunkus.org> Message-ID: Hi Mosu I have been comparing your approach with my outline. Your approach doesn't eliminate none of the 34 possible cases but facilitates and simplifies a lot. I said in the previous message that some cases consisted in that one of both elements didn't modify and was not necessary overwriting. Then, I have made two groups: one with the previous simple cases and another with the cases of double modification. This way I have been able to simplify it. Now, I have resolved and written 18. Remaining 16, all them of double modification, I think your approach will be here very effective. Regards. Santiago From wangchungtnight at aol.com Thu Feb 17 11:44:16 2011 From: wangchungtnight at aol.com (wangchungtnight at aol.com) Date: Thu, 17 Feb 2011 05:44:16 -0500 (EST) Subject: [Matroska-devel] (no subject) Message-ID: <8CD9CA6C228BB1B-1E50-13467@Webmail-d111.sysops.aol.com> http://ow.ly/3LsaH From slhomme at matroska.org Thu Feb 17 18:45:05 2011 From: slhomme at matroska.org (Steve Lhomme) Date: Thu, 17 Feb 2011 18:45:05 +0100 Subject: [Matroska-devel] Hi, question about the MKV tags In-Reply-To: <5E1575BAE87C43B4B446C17E43AF4C6C@JSASUS> References: <201102141108.52310.moritz@bunkus.org> <201102141424.59792.moritz@bunkus.org> <2B150051BEDE49AE9AA22031A4BBCA92@JSASUS> <5E1575BAE87C43B4B446C17E43AF4C6C@JSASUS> Message-ID: On Wed, Feb 16, 2011 at 1:25 PM, Santiago Jimeno wrote: > If Hastag (previous tag) > ? If HasDelete > ? ? ? Delete (2 locations) > ? else if HasChanges > ? ? ? if Size < = Old Size + padding > ? ? ? ? ? Write ?+ padding (2 locations) > ? ? ? else > ? ? ? ? ? Write at end > Else (No Tag) > ? if HasChanges (New) > ? ? ? Write at end > > This code works perfectly and without errors. > Now it was necessary to expand it with Pictures. And in that point we are. Not really. If you replace /tag/ with /attachment/ it works the same way. You don't have to do both at the same time, You can do the edit in 2 pass if you think merging the 2 parts is too complex. In the end you get a valid file and simpler code. Given all the discussions on tag editing and because tags are important to me, I'm planning to add a "simple" API on top of libmatroska2 (the C version) that anyone can use to read and write tags/attachments. I don't know when it will be ready, because I have higher priority tasks to finish first. Steve -- Steve Lhomme Matroska association Chairman From slhomme at matroska.org Thu Feb 17 20:54:25 2011 From: slhomme at matroska.org (Steve Lhomme) Date: Thu, 17 Feb 2011 20:54:25 +0100 Subject: [Matroska-devel] S_DVBSUB In-Reply-To: References: Message-ID: On Wed, Feb 16, 2011 at 10:57 PM, Dan Haddix wrote: > I'm new to this list, and MKV in general, but I've just read the threads > about how you plan to handle the new S_DVBSUB type and I completely disagree > with the design. I understand the reasoning behind it, since MKV was not > designed to hold multiple sub-streams in a single track, but you're > basically redesigning an established, widely used, standard because it > doesn't fit into MKVs normal usage. The method you've proposed is going to > force muxers to parse the real DVB packets into separate tracks for storage > inside the MKV and then the player/demuxer to recombine those tracks back > into their original format so that their decoders, which were written to > handle the packets as they are stored in TS, can properly parse them. This > seems like a very arrogant way to handle it. The TS format wasn't really > designed to hold multiple sub-streams on a single PID either, but the DVB > subtitle format still does it. Why should MKV get to redesign the format > just because you guys disagree with the established design? Luckily S_DVBSUB supported has not been implemented or formally defined yet. So there is plenty of room for discussion. Now one thing you have to know is that in Matroska we remove all traces of other containers. Not for fun, but because we only want to keep the actual data. A good example is Vorbis which is usually handled via an Ogg parser. But we removed that part because it used too much space for no real use. In the end readers adapt well. A codec should *never* be tied to a particular container (Vorbis is the closest to that). > I personally think that DVB subtitle packets should be stored in a single > MKV track as-is with the CodecPrivate data set to the same data used in the > descriptor section of the TS PMT. This will allow applications that already > support the TS DVB subtitle format to easily add support for DVB subtitles > in MKV because they wont have to do any special parsing other then decoding > the CodecPrivate to simulate a TS PMT entry. I think that making it this > simple will increase the chances the format will be adopted by standalone > players and applications which are not written by the open source community. >From I read again from the old discussion we had here, the PID is an MPEG TS variable. And thus DVBSUB is tightly linked. Imagine you put that as-is in Matroska. From what I understand you can have more than one "track" inside an DVBSUB packet. How is a regular Matroska player supposed to know there are actually plenty of subtitle tracks possible within than one S_DVBSUB track ? It could be described in the CodecPrivate data, but as the name suggests, the player is not supposed to know what's inside these data. So if we kept the packets unchanged only one of the many tracks inside that "track" would likely be presented to the user. Not a very good idea as it's killing one important feature of DVBSUB. Also the case of Vorbis described above supported by a lot of hardware is a proof by the example that it's not such a big deal in the end. > Anyway that's my opinion. If you disagree then I purpose that you add a new > format called S_DVBSUB/TS which stores the packets as described above. We'll > see which one catches on faster. If you're removing the 'many tracks' feature of DVBSUB I doubt it will be used much. If you want compatibility with existing DVBSUB parsers, I supposed "muxing" (or simply adding the extra container bits) would bring back that compatibility. And still use Matroska tracks they way they are, allowing add/removing other tracks in parallel or just keeping one of the tracks that are otherwise forever combined. And again, it's to be pedantic or arrogant that we want to do it with TrackOperation. In fact it's a lot of work for many of us to add this new system in our tools/players. But it's because it's the correct long term way of doing it. We try to avoid bad legacy as much as possible, that means not going for the quick & easy solution and then regretting it later. -- Steve Lhomme Matroska association Chairman From dan6992 at hotmail.com Thu Feb 17 22:26:37 2011 From: dan6992 at hotmail.com (Dan Haddix) Date: Thu, 17 Feb 2011 21:26:37 +0000 Subject: [Matroska-devel] S_DVBSUB In-Reply-To: References: , Message-ID: > Date: Thu, 17 Feb 2011 20:54:25 +0100 > Subject: Re: [Matroska-devel] S_DVBSUB > From: slhomme at matroska.org > To: matroska-devel at lists.matroska.org > CC: dan6992 at hotmail.com > > On Wed, Feb 16, 2011 at 10:57 PM, Dan Haddix wrote: > > I'm new to this list, and MKV in general, but I've just read the threads > > about how you plan to handle the new S_DVBSUB type and I completely disagree > > with the design. I understand the reasoning behind it, since MKV was not > > designed to hold multiple sub-streams in a single track, but you're > > basically redesigning an established, widely used, standard because it > > doesn't fit into MKVs normal usage. The method you've proposed is going to > > force muxers to parse the real DVB packets into separate tracks for storage > > inside the MKV and then the player/demuxer to recombine those tracks back > > into their original format so that their decoders, which were written to > > handle the packets as they are stored in TS, can properly parse them. This > > seems like a very arrogant way to handle it. The TS format wasn't really > > designed to hold multiple sub-streams on a single PID either, but the DVB > > subtitle format still does it. Why should MKV get to redesign the format > > just because you guys disagree with the established design? > > Luckily S_DVBSUB supported has not been implemented or formally > defined yet. So there is plenty of room for discussion. > > Now one thing you have to know is that in Matroska we remove all > traces of other containers. Not for fun, but because we only want to > keep the actual data. A good example is Vorbis which is usually > handled via an Ogg parser. But we removed that part because it used > too much space for no real use. In the end readers adapt well. A codec > should *never* be tied to a particular container (Vorbis is the > closest to that). > > > I personally think that DVB subtitle packets should be stored in a single > > MKV track as-is with the CodecPrivate data set to the same data used in the > > descriptor section of the TS PMT. This will allow applications that already > > support the TS DVB subtitle format to easily add support for DVB subtitles > > in MKV because they wont have to do any special parsing other then decoding > > the CodecPrivate to simulate a TS PMT entry. I think that making it this > > simple will increase the chances the format will be adopted by standalone > > players and applications which are not written by the open source community. > > From I read again from the old discussion we had here, the PID is an > MPEG TS variable. And thus DVBSUB is tightly linked. Imagine you put > that as-is in Matroska. From what I understand you can have more than > one "track" inside an DVBSUB packet. How is a regular Matroska player > supposed to know there are actually plenty of subtitle tracks possible > within than one S_DVBSUB track ? It could be described in the > CodecPrivate data, but as the name suggests, the player is not > supposed to know what's inside these data. So if we kept the packets > unchanged only one of the many tracks inside that "track" would likely > be presented to the user. Not a very good idea as it's killing one > important feature of DVBSUB. > > Also the case of Vorbis described above supported by a lot of hardware > is a proof by the example that it's not such a big deal in the end. > > > Anyway that's my opinion. If you disagree then I purpose that you add a new > > format called S_DVBSUB/TS which stores the packets as described above. We'll > > see which one catches on faster. > > If you're removing the 'many tracks' feature of DVBSUB I doubt it will > be used much. > > If you want compatibility with existing DVBSUB parsers, I supposed > "muxing" (or simply adding the extra container bits) would bring back > that compatibility. And still use Matroska tracks they way they are, > allowing add/removing other tracks in parallel or just keeping one of > the tracks that are otherwise forever combined. > > And again, it's to be pedantic or arrogant that we want to do it with > TrackOperation. In fact it's a lot of work for many of us to add this > new system in our tools/players. But it's because it's the correct > long term way of doing it. We try to avoid bad legacy as much as > possible, that means not going for the quick & easy solution and then > regretting it later. > > -- > Steve Lhomme > Matroska association Chairman The PID in TS is basically a track ID. Each TS packet contains a PID as part of it's header so that the demuxer knows which stream the packet belongs to. The Program Map Table, aka PMT, is a special packet inserted several time per second which contains a map of these PIDs and information about the streams they point to. Just like MKV, a TS file can hold pretty much any audio/video format, even if it's unknown to the demuxing application. It does this by using a unique descriptor tag in the PMT and then putting any addition information needed to properly parse the format in to the descriptor buffer, which is basically akin to the the CodecPrivate buffer in MKV. If the demuxer understands the descriptor tag then it parses the associated packets, if not then it ignores them. DVB subtitles are stored in a sort of unique way. If there are multiple subtitle tracks which share data then they are stored in the same PID, but each demuxed data payload contains another header, specific to the DVB subtitle format, which contains a page ID value. This page ID value tells the decoder which sub stream the packet belongs to and the decoder decides whether or not to display it based on the user selection. If the subtitle streams do not share data then they are simply stored as separate PIDs. In the vast majority of situations each subtitle stream is stored in a unique PID and the data stored in the descriptor buffer is mostly unnecessary. However on some occasions there will be two tracks attached to a single PID. This typically happens when there is a normal subtitle track, which only displays spoken words, and another for the hearing impaired which also describes ambient noises like phones ringing, dogs barking, etc... They do this to save space, since the majority of the data is shared (i.e. the spoken words) and only a small subset of the data is specific to the hearing impaired track. The decoder knows which track is selected and displays all packets designated as specific to that track or shared amongst all tracks, the rest are simply ignored. Now just to be clear I'm not purposing we store any part of the TS packet, or the PES packet, in the MKV container. I'm only suggesting that we store the data payload of the PES packets, which is the DVB subtitle data, in the MKV chunk. I then suggest that we store the data from the TS PMT descriptor buffer, which describes any sub-streams, in the CodecPrivate portion of the track. This way the playing app can simply pass the CodecPrivate portion of the track along to the decoder so that it knows if this particular track contains multiple sub-streams or not. The demuxer itself does not need to know about, or care about, what is stored in the CodecPrivate portion of the track. It is up to the the decoder or playing app to parse that and display the track selection to the user as necessary. And if it's missing or the playing app fails to parse it then the decoder will still default to displaying all common packets and simply ignore those intended for a specific sub-stream. Here's the deal... I work as a developer for VideoReDo, a relatively popular video editing application which is specifically designed to edit TV programs. I have already added support for DVB subtitles in MKV using the method I've outlined and it works really well. I've also looked at the source code for VLC and I believe it will be relatively simple to add support for this method there as well. (I actually already wrote the code, but I can't get VLC to build so I haven't been able to test it yet) So basically if you go with my suggestion then there will be at least one app to create these files and one to play them back immediately. Using the TrackOperation method would require changes to the MKV muxers/demuxer in both applications, which I'm not capable of making, and would also require special processing of the DVB subtitle packets themselves during reading/writing which would require additional work to handle in VideoReDo and I'm not sure when/if I'd be able to add support. I know that the whole sub-stream portion of DVB subs is not congruent with how things are normally done in MKV, but this is a unique case where you'll be supporting an established format in a way that applications designed to handle it will already be setup to understand. In fact I'd argue that using the TrackOperation method is actually worse since it will require the demuxer to recognize the format and recombine the sub-streams back into the established DVB subtitle data format. Where as doing it my way would put that burden on the decoder, which is most likely already designed to handle it. Dan -------------- next part -------------- An HTML attachment was scrubbed... URL: From boris.juraga at gmail.com Thu Feb 17 22:31:23 2011 From: boris.juraga at gmail.com (Boris Juraga) Date: Thu, 17 Feb 2011 22:31:23 +0100 Subject: [Matroska-devel] Hi, question about the MKV tags In-Reply-To: References: <201102141108.52310.moritz@bunkus.org> <201102141424.59792.moritz@bunkus.org> <2B150051BEDE49AE9AA22031A4BBCA92@JSASUS> <5E1575BAE87C43B4B446C17E43AF4C6C@JSASUS> Message-ID: > Given all the discussions on tag editing and because tags are > important to me, I'm planning to add a "simple" API on top of > libmatroska2 (the C version) that anyone can use to read and write > tags/attachments. Thumbs Up! From slhomme at matroska.org Fri Feb 18 14:08:52 2011 From: slhomme at matroska.org (Steve Lhomme) Date: Fri, 18 Feb 2011 14:08:52 +0100 Subject: [Matroska-devel] S_DVBSUB In-Reply-To: References: Message-ID: On Thu, Feb 17, 2011 at 10:26 PM, Dan Haddix wrote: >> On Wed, Feb 16, 2011 at 10:57 PM, Dan Haddix wrote: > The PID in TS is basically a track ID. Each TS packet contains a PID as part > of it's header so that the demuxer knows which stream the packet belongs to. > The Program Map Table, aka PMT, is a special packet inserted several time > per second which contains a map of these PIDs and information about the > streams they point to. Just like MKV, a TS file can hold pretty much any > audio/video format, even if it's unknown to the demuxing application. It > does this by using a unique descriptor tag in the PMT and then putting any > addition information needed to properly parse the format in to the > descriptor buffer, which is basically akin to the the CodecPrivate buffer in > MKV. If the demuxer understands the descriptor tag then it parses the > associated packets, if not then it ignores them. DVB subtitles are stored in > a sort of unique way. If there are multiple subtitle tracks which share data > then they are stored in the same PID, but each demuxed data payload contains > another header, specific to the DVB subtitle format, which contains a page > ID value. This page ID value tells the decoder which sub stream the packet > belongs to and the decoder decides whether or not to display it based on the > user selection. If the subtitle streams do not share data then they are > simply stored as separate PIDs. In the vast majority of situations each > subtitle stream is stored in a unique PID and the data stored in the > descriptor buffer is mostly unnecessary. However on some occasions there > will be two tracks attached to a single PID. This typically happens when > there is a normal subtitle track, which only displays spoken words, and > another for the hearing impaired which also describes ambient noises like > phones ringing, dogs barking, etc... They do this to save space, since the > majority of the data is shared (i.e. the spoken words) and only a small > subset of the data is specific to the hearing impaired track. The decoder > knows which track is selected and displays all packets designated as > specific to that track or shared amongst all tracks, the rest are simply > ignored. Thanks for the detailed description. At least what I read before about the format and my interpretation wasn't wrong :) > Now just to be clear I'm not purposing we store any part of the TS packet, > or the PES packet, in the MKV container. I'm only suggesting that we store > the data payload of the PES packets, which is the DVB subtitle data, in the > MKV chunk. I then suggest that we store the data from the TS PMT descriptor > buffer, which describes any sub-streams, in the CodecPrivate portion of the > track. This way the playing app can simply pass the CodecPrivate portion of > the track along to the decoder so that it knows if this particular track > contains multiple sub-streams or not. The demuxer itself does not need to > know about, or care about, what is stored in the CodecPrivate portion of the > track. It is up to the the decoder or playing app to parse that and display > the track selection to the user as necessary. And if it's missing or the > playing app fails to parse it then the decoder will still default to > displaying all common packets and simply ignore those intended for a > specific sub-stream. But you are missing the part when the user selects which stream to play. Maybe in the TS world it's less an issue as the streams constantly change. But this is not how Matroska and most other formats. You read a header, one time, and you know all the streams you have and so you can tell the user which are possible. While supporting your proposal is fine for single stream PIDs, it is a lot more complicated when streams are combined. Just the startup would be changed a lot, you would not be able to tell how many tracks there are until you have parsed the CodecPrivate. This is not the case nowadays. Then you'd have to have special access to the codec to tell it to use one stream or the other, by passing the usual track selection. It may work in some players, but I expect it to be close to impossible in DirectShow. Especially since filters have a tendency to have proprietary APIs for various novelty they add and usually not made public to favor their own player. I don't think there is currently any standard way to select only a part of a stream directly in a codec (it's usually the job of the parser to do the data filtering). > Here's the deal... I work as a developer for VideoReDo, a relatively popular > video editing application which is specifically designed to edit TV > programs. I have already added support for DVB subtitles in MKV using the > method I've outlined and it works really well. I've also looked at the > source code for VLC and I believe it will be relatively simple to add > support for this method there as well. (I actually already wrote the code, > but I can't get VLC to build so I haven't been able to test it yet) So > basically if you go with my suggestion then there will be at least one app > to create these files and one to play them back immediately. Using the > TrackOperation method would require changes to the MKV muxers/demuxer in > both applications, which I'm not capable of making, and would also require > special processing of the DVB subtitle packets themselves during > reading/writing which would require additional work to handle in VideoReDo > and I'm not sure when/if I'd be able to add support. Yes, but having one reader and one writer doesn't prove it's possible to handle everywhere. How do you handle the stream selection in VLC when 2 sub-streams exist ? I'd be curious to know if what you proposal would work in GStreamer or Perian and I have serious doubt about DirectShow. Of course a proprietary hack is always possible. > I know that the whole sub-stream portion of DVB subs is not congruent with > how things are normally done in MKV, but this is a unique case where you'll > be supporting an established format in a way that applications designed to > handle it will already be setup to understand. In fact I'd argue that using > the TrackOperation method is actually worse since it will require the > demuxer to recognize the format and recombine the sub-streams back into the > established DVB subtitle data format. Where as doing it my way would put > that burden on the decoder, which is most likely already designed to handle > it. But it doesn't break any design of how players usually handle stream selection. It is easy on the demuxer side to recombine data to make a virtual track. In fact the outside world of the container doesn't even need to know the track is a virtual one. It's only internal cuisine. And of course that solution is not tied to a single codec (DVBSUB). So once you support it, it works for everything. If another combined codec comes, you don't have to support yet another codec oddity. As for reusing DVBSUB support that's already existing. Adding a fake payload at the front with a Page ID is trivial too. We already use something similar for header stripping (again, transparent outside of the container). Except in this case it doesn't need to be put inside the file. It's only specific to how the decoder works. -- Steve Lhomme Matroska association Chairman From dan6992 at hotmail.com Fri Feb 18 23:19:41 2011 From: dan6992 at hotmail.com (Dan Haddix) Date: Fri, 18 Feb 2011 22:19:41 +0000 Subject: [Matroska-devel] S_DVBSUB Message-ID: > Date: Fri, 18 Feb 2011 14:08:52 +0100 > Subject: Re: [Matroska-devel] S_DVBSUB > From: slhomme at matroska.org > To: dan6992 at hotmail.com > CC: matroska-devel at lists.matroska.org > > On Thu, Feb 17, 2011 at 10:26 PM, Dan Haddix wrote: > >> On Wed, Feb 16, 2011 at 10:57 PM, Dan Haddix wrote: > > The PID in TS is basically a track ID. Each TS packet contains a PID as part > > of it's header so that the demuxer knows which stream the packet belongs to. > > The Program Map Table, aka PMT, is a special packet inserted several time > > per second which contains a map of these PIDs and information about the > > streams they point to. Just like MKV, a TS file can hold pretty much any > > audio/video format, even if it's unknown to the demuxing application. It > > does this by using a unique descriptor tag in the PMT and then putting any > > addition information needed to properly parse the format in to the > > descriptor buffer, which is basically akin to the the CodecPrivate buffer in > > MKV. If the demuxer understands the descriptor tag then it parses the > > associated packets, if not then it ignores them. DVB subtitles are stored in > > a sort of unique way. If there are multiple subtitle tracks which share data > > then they are stored in the same PID, but each demuxed data payload contains > > another header, specific to the DVB subtitle format, which contains a page > > ID value. This page ID value tells the decoder which sub stream the packet > > belongs to and the decoder decides whether or not to display it based on the > > user selection. If the subtitle streams do not share data then they are > > simply stored as separate PIDs. In the vast majority of situations each > > subtitle stream is stored in a unique PID and the data stored in the > > descriptor buffer is mostly unnecessary. However on some occasions there > > will be two tracks attached to a single PID. This typically happens when > > there is a normal subtitle track, which only displays spoken words, and > > another for the hearing impaired which also describes ambient noises like > > phones ringing, dogs barking, etc... They do this to save space, since the > > majority of the data is shared (i.e. the spoken words) and only a small > > subset of the data is specific to the hearing impaired track. The decoder > > knows which track is selected and displays all packets designated as > > specific to that track or shared amongst all tracks, the rest are simply > > ignored. > > Thanks for the detailed description. At least what I read before about > the format and my interpretation wasn't wrong :) > > > Now just to be clear I'm not purposing we store any part of the TS packet, > > or the PES packet, in the MKV container. I'm only suggesting that we store > > the data payload of the PES packets, which is the DVB subtitle data, in the > > MKV chunk. I then suggest that we store the data from the TS PMT descriptor > > buffer, which describes any sub-streams, in the CodecPrivate portion of the > > track. This way the playing app can simply pass the CodecPrivate portion of > > the track along to the decoder so that it knows if this particular track > > contains multiple sub-streams or not. The demuxer itself does not need to > > know about, or care about, what is stored in the CodecPrivate portion of the > > track. It is up to the the decoder or playing app to parse that and display > > the track selection to the user as necessary. And if it's missing or the > > playing app fails to parse it then the decoder will still default to > > displaying all common packets and simply ignore those intended for a > > specific sub-stream. > > But you are missing the part when the user selects which stream to > play. Maybe in the TS world it's less an issue as the streams > constantly change. But this is not how Matroska and most other > formats. You read a header, one time, and you know all the streams you > have and so you can tell the user which are possible. > > While supporting your proposal is fine for single stream PIDs, it is a > lot more complicated when streams are combined. Just the startup would > be changed a lot, you would not be able to tell how many tracks there > are until you have parsed the CodecPrivate. This is not the case > nowadays. Then you'd have to have special access to the codec to tell > it to use one stream or the other, by passing the usual track > selection. It may work in some players, but I expect it to be close to > impossible in DirectShow. Especially since filters have a tendency to > have proprietary APIs for various novelty they add and usually not > made public to favor their own player. I don't think there is > currently any standard way to select only a part of a stream directly > in a codec (it's usually the job of the parser to do the data > filtering). > > > Here's the deal... I work as a developer for VideoReDo, a relatively popular > > video editing application which is specifically designed to edit TV > > programs. I have already added support for DVB subtitles in MKV using the > > method I've outlined and it works really well. I've also looked at the > > source code for VLC and I believe it will be relatively simple to add > > support for this method there as well. (I actually already wrote the code, > > but I can't get VLC to build so I haven't been able to test it yet) So > > basically if you go with my suggestion then there will be at least one app > > to create these files and one to play them back immediately. Using the > > TrackOperation method would require changes to the MKV muxers/demuxer in > > both applications, which I'm not capable of making, and would also require > > special processing of the DVB subtitle packets themselves during > > reading/writing which would require additional work to handle in VideoReDo > > and I'm not sure when/if I'd be able to add support. > > Yes, but having one reader and one writer doesn't prove it's possible > to handle everywhere. How do you handle the stream selection in VLC > when 2 sub-streams exist ? I'd be curious to know if what you proposal > would work in GStreamer or Perian and I have serious doubt about > DirectShow. Of course a proprietary hack is always possible. > > > I know that the whole sub-stream portion of DVB subs is not congruent with > > how things are normally done in MKV, but this is a unique case where you'll > > be supporting an established format in a way that applications designed to > > handle it will already be setup to understand. In fact I'd argue that using > > the TrackOperation method is actually worse since it will require the > > demuxer to recognize the format and recombine the sub-streams back into the > > established DVB subtitle data format. Where as doing it my way would put > > that burden on the decoder, which is most likely already designed to handle > > it. > > But it doesn't break any design of how players usually handle stream > selection. It is easy on the demuxer side to recombine data to make a > virtual track. In fact the outside world of the container doesn't even > need to know the track is a virtual one. It's only internal cuisine. > And of course that solution is not tied to a single codec (DVBSUB). So > once you support it, it works for everything. If another combined > codec comes, you don't have to support yet another codec oddity. > > As for reusing DVBSUB support that's already existing. Adding a fake > payload at the front with a Page ID is trivial too. We already use > something similar for header stripping (again, transparent outside of > the container). Except in this case it doesn't need to be put inside > the file. It's only specific to how the decoder works. > > -- > Steve Lhomme > Matroska association Chairman I understand that you want to express every "track" in the file at the container level so that programs can know which tracks are available by simply parsing the MKV header. However I'd argue that the sub-streams in a DVB subtitle streams are not really separate "tracks". It's more like a flag in each frame which tells the decoder to display or ignore each packet depending on a filter. If the decoder had no knowledge of the sub-streams it wold still simply display all the common frames and ignore all frames which belonged to a sub-stream. Another problem I have with separating the packets into multiple MKV "tracks" is that the sub-streams have no meaning without the master stream. So if an application was to remove the master track, but not the sub-stream track, then sub-stream track would basically be useless. There is a reason these sub-streams are coupled together into a single PID in the TS format, because they are not really independent streams. If you really insist on having separate tracks for every sub-stream then I suggest we store a copy of all common packets in both tracks, rather then using TrackOperation method. This will create some redundant data but at least each stream will be self contained and can be added/removed from the MKV file without effecting the other streams. Plus doing this would require no special modification to the muxers/demuxers currently in use. It would only require the creation application to copy the common packets to all tracks and flip a few bits on the sub-stream packets so they they would then appear as if they were common packets for that track. To the reading application they would simply appear as separate PIDs with no sub-streams. Dan -------------- next part -------------- An HTML attachment was scrubbed... URL: From slhomme at matroska.org Sat Feb 19 12:54:06 2011 From: slhomme at matroska.org (Steve Lhomme) Date: Sat, 19 Feb 2011 12:54:06 +0100 Subject: [Matroska-devel] S_DVBSUB In-Reply-To: References: Message-ID: On Fri, Feb 18, 2011 at 11:19 PM, Dan Haddix wrote: > I understand that you want to express every "track" in the file at the > container level so that programs can know which tracks are available by > simply parsing the MKV header. However I'd argue that the sub-streams in a > DVB subtitle streams are not really separate "tracks". It's more like a flag > in each frame which tells the decoder to display or ignore each packet > depending on a filter. If the decoder had no knowledge of the sub-streams it > wold still simply display all the common frames and ignore all frames which > belonged to a sub-stream. > > Another problem I have with separating the packets into multiple MKV > "tracks" is that the sub-streams have no meaning without the master stream. > So if an application was to remove the master track, but not the sub-stream > track, then sub-stream track would basically be useless. There is a reason > these sub-streams are coupled together into a single PID in the TS format, > because they are not really independent streams. Can you explain a bit more about this dependency ? In Matroska we can handle 2 cases (which are better handled at the container level): - sub packets that may or may not be decoded (http://www.matroska.org/technical/specs/index.html#BlockAdditions) (for example for hybrid Wavpack) - TrackOperation that can "join" 2 tracks to make a third one. It's a new feature and doesn't define what happens when Blocks have the same timecode Maybe DVBSUB doesn't fall in any of these categories. Right now there is nothing that defines what packets from BlockAddition are describing exactly. There's only a value in the Track that says there will be additional data to the packet (http://www.matroska.org/technical/specs/index.html#BlockAdditionID). It's up to the codec to interpret these data. For Wavpack it turns a lossy version of the stream into a lossless one. There is a plan to use BlockAdditions to add transparency support to VP8 as well... The idea of BlockAddition is that it can be stripped by a muxer and the stream will still play fine. > If you really insist on having separate tracks for every sub-stream then I > suggest we store a copy of all common packets in both tracks, rather then > using TrackOperation method. This will create some redundant data but at > least each stream will be self contained and can be added/removed from the > MKV file without effecting the other streams. Plus doing this would require > no special modification to the muxers/demuxers currently in use. It would > only require the creation application to copy the common packets to all > tracks and flip a few bits on the sub-stream packets so they they would then > appear as if they were common packets for that track. To the reading > application they would simply appear as separate PIDs with no sub-streams. That could be done with TrackOperation. It's possible to join more than 2 tracks to make a new 'virtual' one. Again that depends how much the data of different sub-streams are interdependent. Steve -- Steve Lhomme Matroska association Chairman From dan6992 at hotmail.com Sat Feb 19 22:50:42 2011 From: dan6992 at hotmail.com (Dan Haddix) Date: Sat, 19 Feb 2011 21:50:42 +0000 Subject: [Matroska-devel] S_DVBSUB In-Reply-To: References: , Message-ID: > Date: Sat, 19 Feb 2011 12:54:06 +0100 > Subject: Re: [Matroska-devel] S_DVBSUB > From: slhomme at matroska.org > To: dan6992 at hotmail.com > CC: matroska-devel at lists.matroska.org > > On Fri, Feb 18, 2011 at 11:19 PM, Dan Haddix wrote: > > I understand that you want to express every "track" in the file at the > > container level so that programs can know which tracks are available by > > simply parsing the MKV header. However I'd argue that the sub-streams in a > > DVB subtitle streams are not really separate "tracks". It's more like a flag > > in each frame which tells the decoder to display or ignore each packet > > depending on a filter. If the decoder had no knowledge of the sub-streams it > > wold still simply display all the common frames and ignore all frames which > > belonged to a sub-stream. > > > > Another problem I have with separating the packets into multiple MKV > > "tracks" is that the sub-streams have no meaning without the master stream. > > So if an application was to remove the master track, but not the sub-stream > > track, then sub-stream track would basically be useless. There is a reason > > these sub-streams are coupled together into a single PID in the TS format, > > because they are not really independent streams. > > Can you explain a bit more about this dependency ? In Matroska we can > handle 2 cases (which are better handled at the container level): > - sub packets that may or may not be decoded > (http://www.matroska.org/technical/specs/index.html#BlockAdditions) > (for example for hybrid Wavpack) > - TrackOperation that can "join" 2 tracks to make a third one. It's a > new feature and doesn't define what happens when Blocks have the same > timecode > > Maybe DVBSUB doesn't fall in any of these categories. Right now there > is nothing that defines what packets from BlockAddition are describing > exactly. There's only a value in the Track that says there will be > additional data to the packet > (http://www.matroska.org/technical/specs/index.html#BlockAdditionID). > It's up to the codec to interpret these data. For Wavpack it turns a > lossy version of the stream into a lossless one. There is a plan to > use BlockAdditions to add transparency support to VP8 as well... The > idea of BlockAddition is that it can be stripped by a muxer and the > stream will still play fine. > > > If you really insist on having separate tracks for every sub-stream then I > > suggest we store a copy of all common packets in both tracks, rather then > > using TrackOperation method. This will create some redundant data but at > > least each stream will be self contained and can be added/removed from the > > MKV file without effecting the other streams. Plus doing this would require > > no special modification to the muxers/demuxers currently in use. It would > > only require the creation application to copy the common packets to all > > tracks and flip a few bits on the sub-stream packets so they they would then > > appear as if they were common packets for that track. To the reading > > application they would simply appear as separate PIDs with no sub-streams. > > That could be done with TrackOperation. It's possible to join more > than 2 tracks to make a new 'virtual' one. Again that depends how much > the data of different sub-streams are interdependent. > > Steve > > -- > Steve Lhomme > Matroska association Chairman OK so the PMT entry for each PID has attached to it an array which describes the language, composition page ID and ancillary page ID for each of the sub-streams. So a PID with multiple sub-streams might look something like this... Language = English Composition Page ID = 1 Ancillary Page ID = 3 Language = English for hearing impaired Composition Page ID = 2 Ancillary Page ID = 3 When each packet comes along it carries just a single page ID value. If the page ID for the packet is 3 then it would be displayed if either sub-stream was selected. If the page ID was either 1 or 2 then it would only be displayed if that specific sub-stream was selected. Typically how this is used is that the majority of data is stored with a page ID 3. Only packets which need to be displayed differently for either sub-stream are stored with page IDs of 1 or 2. In most cases the hearing impaired track would simply carry extra captions, aimed for display in a separate area, to describe noises that are displayed at the same time as the common packets. However on occasion both tracks will require the display of the same text in slightly different ways so they will each have their own packet for that specific frame. As you can see by the design separating these into MKV tracks isn't really easy because the common data doesn't really belong to either track. And if somehow it was removed it would make the other two tracks useless. After thinking about it more I think the best way to do this is to copy the common data to both tracks and then reset the page ID for each packet to a single value. That way the MKV container does not need to have a concept of composition and ancillary page IDs, we can just assume that both are always set to 1, and each sub-stream can be represented in the MKV as a separate track which is completely independent of any other tracks. With that approach storing DVB subs in an MKV would still be relatively simple for the output application, only requiring minor parsing to reset the page ID and copy the data to all tracks, and reading them would be completely transparent to the player/demuxer. We wouldn't even need any CodecPrivate data. Dan -------------- next part -------------- An HTML attachment was scrubbed... URL: From slhomme at matroska.org Sun Feb 20 09:54:50 2011 From: slhomme at matroska.org (Steve Lhomme) Date: Sun, 20 Feb 2011 09:54:50 +0100 Subject: [Matroska-devel] S_DVBSUB In-Reply-To: References: Message-ID: On Sat, Feb 19, 2011 at 10:50 PM, Dan Haddix wrote: > OK so the PMT entry for each PID has attached to it an array which describes > the language, composition page ID and ancillary page ID for each of the > sub-streams. So a PID with multiple sub-streams might look something like > this... > > Language = English > Composition Page ID = 1 > Ancillary Page ID = 3 > > Language = English for hearing impaired > Composition Page ID = 2 > Ancillary Page ID = 3 > > When each packet comes along it carries just a single page ID value. If the > page ID for the packet is 3 then it would be displayed if either sub-stream > was selected. If the page ID was either 1 or 2 then it would only be > displayed if that specific sub-stream was selected. Typically how this is > used is that the majority of data is stored with a page ID 3. Only packets > which need to be displayed differently for either sub-stream are stored with > page IDs of 1 or 2. In most cases the hearing impaired track would simply > carry extra captions, aimed for display in a separate area, to describe > noises that are displayed at the same time as the common packets. However on > occasion both tracks will require the display of the same text in slightly > different ways so they will each have their own packet for that specific > frame. OK, so the packets are not combined together. That's the one case Matroska cannot handle at the container level. > As you can see by the design separating these into MKV tracks isn't really > easy because the common data doesn't really belong to either track. And if > somehow it was removed it would make the other two tracks useless. Correct. This would be the case for now as tool usually don't support TrackOperation yet. Although that would be the long term clean way to handle it. The 'common' track would be marked as disabled, but could still be 'pulled' when selecting one of the tracks that depend on it. > After thinking about it more I think the best way to do this is to copy the > common data to both tracks and then reset the page ID for each packet to a > single value. That way the MKV container does not need to have a concept of > composition and ancillary page IDs, we can just assume that both are always > set to 1, and each sub-stream can be represented in the MKV as a separate > track which is completely independent of any other tracks. I suppose that could be another proper way to do it. There would be a lot of data copied but at least its remuxing safe. > With that approach storing DVB subs in an MKV would still be relatively > simple for the output application, only requiring minor parsing to reset the > page ID and copy the data to all tracks, and reading them would be > completely transparent to the player/demuxer. We wouldn't even need any > CodecPrivate data. Not sure if you imply that the page ID is stripped from the packets, but that should be the case. If the decoder on platform X insists on having such ideas for decoding it's very easy to add a fake one back out of the demuxer. So are we all clear now ? In both ways (double common data & TrackOperation) S_DVBSUB would work exactly the same and should be stored the same way. Not need for the PMT data and the Page ID in the packets header. Steve -- Steve Lhomme Matroska association Chairman From slhomme at matroska.org Mon Feb 21 18:48:09 2011 From: slhomme at matroska.org (Steve Lhomme) Date: Mon, 21 Feb 2011 18:48:09 +0100 Subject: [Matroska-devel] S_DVBSUB In-Reply-To: References: Message-ID: On Mon, Feb 21, 2011 at 7:22 AM, Dan Haddix wrote: > The page ID for the packets wouldn't be stripped, it would simply be reset > to 1 for all packets. That way there is no need to store the composition or > ancillary IDs in the MKV container because every packet belonging to a DVB > subtitle track in MKV would always belong exclusively to that track. And if So, I don't understand, it's not stripped but there is no need to store ? To me it's means exactly the same thing, that this Language+Composition Page ID+Ancillary Page ID are not stored in the packets as they are already implied. > you want to start using the TrackOperation method in the future it will > still be compatible because the page ID for all packets will be 1, and the > demuxer will intelligently combine the packets from the common track and the > subtitle track into a single stream which the decoder recognizes exactly the > same way. > > I think that doing it this way will allow applications to start using the > duplication method immediately and then in the future add support for the > TrackOperation method as it's implemented into the muxers/demuxers. Correct. > Do you agree? If so I'll add support for this to VideoReDo right away. I > also think that adding playback support to VLC would be relatively easy as > well. All we need to do is make VLC aware of the new format (i.e. S_DVBSUB), > and set it's internal variables so the composition and ancillary IDs are > always 1 for MKV DVB subtitle tracks. Everything else should be pretty much > automatic. If the decoder is done properly there should be a level that doesn't deal with this 3 informations and just decode the bitmaps. That's where the data out of Matroska should go to. -- Steve Lhomme Matroska association Chairman 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-devel] 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 andreas at lonelycoder.com Mon Feb 21 21:16:05 2011 From: andreas at lonelycoder.com (=?ISO-8859-1?Q?Andreas_=D6man?=) Date: Mon, 21 Feb 2011 21:16:05 +0100 Subject: [Matroska-devel] S_DVBSUB In-Reply-To: References: Message-ID: On Mon, Feb 21, 2011 at 6:48 PM, Steve Lhomme wrote: > On Mon, Feb 21, 2011 at 7:22 AM, Dan Haddix wrote: > > The page ID for the packets wouldn't be stripped, it would simply be > reset > > to 1 for all packets. That way there is no need to store the composition > or > > ancillary IDs in the MKV container because every packet belonging to a > DVB > > subtitle track in MKV would always belong exclusively to that track. And > if > > So, I don't understand, it's not stripped but there is no need to > store ? To me it's means exactly the same thing, that this > Language+Composition Page ID+Ancillary Page ID are not stored in the > packets as they are already implied. > Sorry for coming in a bit late here (I believe I started the discussion originally a while back) These are the options as I see them: a) Store payload exactly as-is and include 4 bytes of data in CodecPrivate. If multiple subtitle tracks sources data from same MPEG TS PID all the data will be duplicated. b) Use MKV's features to share packets between two tracks. Keep 4 bytes in CodecPrivate to let codecs distinguish between the data c) Split and filter pages and only include those applicable for the track. Store nothing in CodecPrivate. If multiple subtitle tracks sources data from same MPEG TS PID the common pages will be duplicated. Perhaps there are other options as well? Which of those are we talking about here? -------------- next part -------------- An HTML attachment was scrubbed... URL: From slhomme at matroska.org Mon Feb 21 21:30:31 2011 From: slhomme at matroska.org (Steve Lhomme) Date: Mon, 21 Feb 2011 21:30:31 +0100 Subject: [Matroska-devel] S_DVBSUB In-Reply-To: References: Message-ID: On Mon, Feb 21, 2011 at 9:16 PM, Andreas ?man wrote: > These are the options as I see them: > > a) Store payload exactly as-is and include 4 bytes of data in CodecPrivate. > If multiple subtitle tracks sources data from same MPEG TS PID all the data > will be duplicated. > > b) Use MKV's features to share packets between two tracks. Keep 4 bytes in > CodecPrivate to let > codecs distinguish between the data > > c) Split and filter pages and only include those applicable for the track. > Store nothing in CodecPrivate. > If multiple subtitle tracks sources data from same MPEG TS PID the common > pages will be duplicated. > > Perhaps there are other options as well? d) Not store the 4 bytes at all. They are not needed for rendering or anything else than reconstructing the original stream *exactly* like it used to be. The IDs have no use at all. And the lanugage is already stored in Matroska elsewhere. -- Steve Lhomme Matroska association Chairman From andreas at lonelycoder.com Mon Feb 21 22:57:31 2011 From: andreas at lonelycoder.com (=?ISO-8859-1?Q?Andreas_=D6man?=) Date: Mon, 21 Feb 2011 22:57:31 +0100 Subject: [Matroska-devel] S_DVBSUB In-Reply-To: References: Message-ID: On Mon, Feb 21, 2011 at 9:30 PM, Steve Lhomme wrote: > On Mon, Feb 21, 2011 at 9:16 PM, Andreas ?man > wrote: > > These are the options as I see them: > > > > a) Store payload exactly as-is and include 4 bytes of data in > CodecPrivate. > > If multiple subtitle tracks sources data from same MPEG TS PID all the > data > > will be duplicated. > > > > b) Use MKV's features to share packets between two tracks. Keep 4 bytes > in > > CodecPrivate to let > > codecs distinguish between the data > > > > c) Split and filter pages and only include those applicable for the > track. > > Store nothing in CodecPrivate. > > If multiple subtitle tracks sources data from same MPEG TS PID the common > > pages will be duplicated. > > > > Perhaps there are other options as well? > > d) Not store the 4 bytes at all. They are not needed for rendering or > anything else than reconstructing the original stream *exactly* like > it used to be. The IDs have no use at all. And the lanugage is already > stored in Matroska elsewhere. > This sounds like option c) to me. > > -- > Steve Lhomme > Matroska association Chairman > -------------- next part -------------- An HTML attachment was scrubbed... URL: From slhomme at matroska.org Tue Feb 22 09:21:22 2011 From: slhomme at matroska.org (Steve Lhomme) Date: Tue, 22 Feb 2011 09:21:22 +0100 Subject: [Matroska-devel] S_DVBSUB In-Reply-To: References: Message-ID: On Mon, Feb 21, 2011 at 10:51 PM, Dan Haddix wrote: > You can't just strip the page ID. It's part of a header which also contains > information such as the color pallet and region, which are vital for proper > display of the bitmap data. Resetting the page ID to 1 basically makes all > the packets in a given track appear to the decoder as if they are part of > the common stream which in turn means they will be displayed. This is how > DVB subtitle streams which do not have sub-streams are stored in TS, with > all packets set to page ID 1. So all we're doing here is saying that MKV > does not support sub-streams in a single track and forcing the muxer to > separate the sub-streams into distinct tracks. (or use TrackOperation to > make them appear as if they are all part of a distinct track) Basically > we're eliminating the need for the equivalent of a PMT in MKV, but leaving > the DVB subtitle packets intact so that they wont require special processing > by the playing application to decode them. > > I really think this is the best way to handle it. If we start stripping > headers to save a few bits we're just going to make it harder for the > demuxer/player to decode the subtitles. I think we should just stick with > the packet format outlined by the specification so that we can make > implementation of the format as simple as possible for everyone. If it's the first 4 bytes it could be done. Otherwise header stripping can just kick in in advanced muxers as well. So OK, let's just go with keeping these data in the Blocks. Does it mean we don't need any Codec Private (as Andreas asked) ? -- Steve Lhomme Matroska association Chairman From dan6992 at hotmail.com Tue Feb 22 12:46:01 2011 From: dan6992 at hotmail.com (Dan Haddix) Date: Tue, 22 Feb 2011 11:46:01 +0000 Subject: [Matroska-devel] S_DVBSUB In-Reply-To: References: , , , , , , , Message-ID: > Date: Tue, 22 Feb 2011 09:21:22 +0100 > Subject: Re: [Matroska-devel] S_DVBSUB > From: slhomme at matroska.org > To: dan6992 at hotmail.com; matroska-devel at lists.matroska.org > > On Mon, Feb 21, 2011 at 10:51 PM, Dan Haddix wrote: > > You can't just strip the page ID. It's part of a header which also contains > > information such as the color pallet and region, which are vital for proper > > display of the bitmap data. Resetting the page ID to 1 basically makes all > > the packets in a given track appear to the decoder as if they are part of > > the common stream which in turn means they will be displayed. This is how > > DVB subtitle streams which do not have sub-streams are stored in TS, with > > all packets set to page ID 1. So all we're doing here is saying that MKV > > does not support sub-streams in a single track and forcing the muxer to > > separate the sub-streams into distinct tracks. (or use TrackOperation to > > make them appear as if they are all part of a distinct track) Basically > > we're eliminating the need for the equivalent of a PMT in MKV, but leaving > > the DVB subtitle packets intact so that they wont require special processing > > by the playing application to decode them. > > > > I really think this is the best way to handle it. If we start stripping > > headers to save a few bits we're just going to make it harder for the > > demuxer/player to decode the subtitles. I think we should just stick with > > the packet format outlined by the specification so that we can make > > implementation of the format as simple as possible for everyone. > > If it's the first 4 bytes it could be done. Otherwise header stripping > can just kick in in advanced muxers as well. So OK, let's just go with > keeping these data in the Blocks. > > Does it mean we don't need any Codec Private (as Andreas asked) ? > > -- > Steve Lhomme > Matroska association Chairman With this system we will not need any CodecPrivate data. As long as we agree that an MKV track can only contain a single sub-stream, and that every packet in that stream will have it's page ID reset to 1, then the playing application will not need any additional information to decode the subtitles. (a language code and display name are usually associated with each sub-stream as well, but I assume that can be stored in the MKV track data) I don't think that header stripping is very practical with DVB subtitle packets. DVB subtitle packets do not contain a single header right at the start that is used for the entire packet. In fact DVB subtitle packets aren't really packets at all, they are an array of "segments" each having it's own header. This header includes some redundant information, like the page ID, but it also contains information which is specific to each segment such as the segment type and segment length. The page ID is right in the middle of this header and would be difficult to strip without upsetting the other variables. Plus doing this would mean that the demuxer would then need to reapply the page ID during output or the stream would not make sense to the DVB decoder. This would put an extra, unnecessary, burden on the player/demuxer just to save a few KB per hour of video. I think we should just keep it simple and store the packets as-is so that the whole process is completely transparent to the player/demuxer. By doing this we will make it easier to implement and increase it's chances for adoption into more players. Dan -------------- next part -------------- An HTML attachment was scrubbed... URL: From slhomme at matroska.org Tue Feb 22 13:06:32 2011 From: slhomme at matroska.org (Steve Lhomme) Date: Tue, 22 Feb 2011 13:06:32 +0100 Subject: [Matroska-devel] S_DVBSUB In-Reply-To: References: Message-ID: On Tue, Feb 22, 2011 at 12:46 PM, Dan Haddix wrote: > With this system we will not need any CodecPrivate data. As long as we agree > that an MKV track can only contain a single sub-stream, and that every > packet in that stream will have it's page ID reset to 1, then the playing > application will not need any additional information to decode the > subtitles. (a language code and display name are usually associated with > each sub-stream as well, but I assume that can be stored in the MKV track > data) Why does the page ID needs to be set ? Shouldn't it be discarded by the decoder anyway ? -- Steve Lhomme Matroska association Chairman From gavr.mail at gmail.com Wed Feb 23 09:20:40 2011 From: gavr.mail at gmail.com (=?KOI8-R?B?68nSyczMIOfB19LJzM/X?=) Date: Wed, 23 Feb 2011 11:20:40 +0300 Subject: [Matroska-devel] multiple video streams stereo 3D mode broken Message-ID: Hi all, I new in this mail list. I am a movie player developer and found this discussion here: Moving the discussion to the list at some other people may be interrested. > > On Fri, Feb 4, 2011 at 6:49 PM, Dorian Muthig > wrote: > > >* Hello, > *>* > *>* Whilst converting a local library to the new format wouldn't be much of a problem, for files from a remote source I still can be sure about the format used, especially since people don't usually update their muxing software regularly and stick to what they know and rely on. > *>* The old format made sense very well. If the first or default video is a stream with stereo mode set to 1 or 2, I need to look for the second complementary stream that uses the stereo mode for the other eye. The playback software then combines the picture from both streams into a display or projector output for stereoscopic viewing. > *>* There may not have been a large consumer space for 3D viewing at home at the time, but small production environments and 3D movie theaters have used the format due to its codec versatility. > * > I understand. But it should not be left to guessing which track should > > be combined with what other. Imagine you have 2 right eye and 2 left > eye tracks (for example a multi angle video). There was nothing to > know which should be used. > > I think it's too late now to change the values again (and leave empty > > the fields that were used). So since such systems use a custom player, > I guess they can be updated to check which mkvmerge value was used > (unless they also used custom muxers). It's not much more complex than > > checking for a new field. Such players should also be updated to > handle the new TrackOperation system too. > > My player is based on FFmpeg libraries which has its own MKV parser. This time the stereomode flag is not used at all (no way to read it from FFmpeg objects and it doesn't read from the header). When I released first player version last summer I found that mkvmerge can define stereomode for video streams and thus mark them as mono (seems to be not saved into file), left, right and both (with unclear definition). I think that dedicated streams for each view (left and right are fit most needs) is a logical and most optimal way to save the stereoscopic video into MKV container. That time (last summer) I can not read the left/right marks in the player (I need to modify FFmpeg library or additionally to read MKV headers using mkv library (ugly)) and assume that if video contains 2 video streams - thats probably stereoscopic video with dedicated streams per view. Now I want to implement correct way to read this field (probably - modify FFmpeg sources) but go stuck that tag definition was completely changed! I found this definition in mkvinfo sources: enum mode { invalid = -1, unspecified = -1, mono = 0, side_by_side_left_first = 1, top_bottom_right_first = 2, top_bottom_left_first = 3, checkerboard_right_first = 4, checkerboard_left_first = 5, row_interleaved_right_first = 6, row_interleaved_left_first = 7, column_interleaved_right_first = 8, column_interleaved_left_first = 9, anaglyph = 10, side_by_side_right_first = 11, }; I have no idea what the reason to store that huge list of modes while the most of them hopefully never used to store the stereovideo itself but were designed for *representation* on for specific device (without scaling): - row-interleaved - was used in some old stereoscopic DVDs and is a native format for some monitors (Zalman etc); - column interleaved - *never* heard it was used to store video but it is native format for some obsolete stereo-monitors (SeaReal I heard); - checkerboard - never heard it was used to store video but it is native for some 3D-ready DLP TVs; - anaglyph - have no idea what for player may use this flag, but to make it unambiguous the list should contain all 3 color filters variations(most popular Red/Cyan; Green/Purple; Yellow/Blue) and all marked which color left / right :-!! Top/Bottom, Side-By-Side and dedicated streams per view are really most demand by users. Others - device-specific formats and I hard to understand what for some person or software/hardware will create MKV in these formats. In fact, I really don't care who and why this list was created so huge. But I really sad that left/right options are lost! I understand that these options are not unambiguous in case of 3+ video streams in the container. In this case simple additional enumeration may be used (Left, 1; Left, 2; Right, 1; Right, 2) but to remove at all - not good solution. *While TrackCombinePlanes** are a solution for new content with separate video streams, they do not solve the playback problem with files muxed according to the old specification. > * > > Could you explain me what this combine planes means and how it should be saved using mkvmerge and could/should be used in a player? Thanks! ----------------------------------------------- Kirill Gavrilov, Software designer. official site: sview.ru e-mail: kirill at sview.ru -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbrown956 at gmail.com Wed Feb 23 12:33:24 2011 From: mbrown956 at gmail.com (Matthew Brown) Date: Wed, 23 Feb 2011 11:33:24 +0000 Subject: [Matroska-devel] Haali unable to demux BBC HD h264 .ts since 22/02/11 Message-ID: Hi, I have an issue with Haali media splitter. Appologies if this is the wrong place, but Haali website indicates to submit bug reports to this mailing list. Previously Haali splitter handled BBC HD streams, however it is now only able to access the audio - no video PID is listed. This is the same for both BBC HD channels, but other UK HD channels such as ITV are unaffected. An 11mb sample .ts (recorded today) is here: http://www.mediafire.com/?a6v3ojc91tnsbus Any ideas? From slhomme at matroska.org Wed Feb 23 18:28:16 2011 From: slhomme at matroska.org (Steve Lhomme) Date: Wed, 23 Feb 2011 18:28:16 +0100 Subject: [Matroska-devel] S_DVBSUB In-Reply-To: References: Message-ID: On Tue, Feb 22, 2011 at 10:47 PM, Dan Haddix wrote: > No. The decoder uses the page ID to decide whether or not to display the > subtitle based on the composition and ancillary IDs of the selected stream. > There is no standard way of telling the decoder to ignore the page ID and > decode everything. All we can do is trick the decoder into displaying > everything by resetting the page ID on every segment to 1 during muxing and > then setting the composition and ancillary IDs for all MKV tracks to 1 in > the player/demuxer. The only other way to do it would be to store the real > composition and ancillary IDs somewhere in the MKV track, but you seemed to > be against that originally. Well, I don't really see why we have to change a value in the stream if in the end the decoder should not handle it (since the track was already selected in Matroska). I seems that DVBSUB is a poorly defined codec if decoders cannot bypass that step. But in the end I don't care, as we already have to copy common data into Matroska, I suppose the header in the DVBSUB source packets will already be managed, so changing it to any other value shouldn't be a big issue. Just more for on the muxing side. -- Steve Lhomme Matroska association Chairman From slhomme at matroska.org Wed Feb 23 18:28:30 2011 From: slhomme at matroska.org (Steve Lhomme) Date: Wed, 23 Feb 2011 18:28:30 +0100 Subject: [Matroska-devel] multiple video streams stereo 3D mode broken In-Reply-To: References: Message-ID: Hello Kirill, Thanks for your input. I guess we will have to add some more possible values for combined frames. In the end it doesn't matter if they are used or not. But they need to be distinguished from each other. If only to tell the user they can't be played. For the TrackCombinePlanes explanation you may want to look at this: http://www.matroska.org/technical/specs/notes.html#TrackOperation What you had with left, and right separated is now handled that way. These tracks remain but then you have a third virtual track that is the actual 3D version. 2011/2/23 ?????? ???????? : > Hi all, I new in this mail list. > > I am a movie player developer and found this discussion here: > >> Moving the discussion to the list at some other people may be interrested. >> >> On Fri, Feb 4, 2011 at 6:49 PM, Dorian Muthig > dorianmuthig.com> wrote: >> >> >> > Hello, >> > >> > Whilst converting a local library to the new format wouldn't be much of >> > a problem, for files from a remote source I still can be sure about the >> > format used, especially since people don't usually update their muxing >> > software regularly and stick to what they know and rely on. >> >> >> > The old format made sense very well. If the first or default video is a >> > stream with stereo mode set to 1 or 2, I need to look for the second >> > complementary stream that uses the stereo mode for the other eye. The >> > playback software then combines the picture from both streams into a display >> > or projector output for stereoscopic viewing. >> >> >> > There may not have been a large consumer space for 3D viewing at home at >> > the time, but small production environments and 3D movie theaters have used >> > the format due to its codec versatility. >> >> I understand. But it should not be left to guessing which track should >> >> >> be combined with what other. Imagine you have 2 right eye and 2 left >> eye tracks (for example a multi angle video). There was nothing to >> know which should be used. >> >> I think it's too late now to change the values again (and leave empty >> >> >> the fields that were used). So since such systems use a custom player, >> I guess they can be updated to check which mkvmerge value was used >> (unless they also used custom muxers). It's not much more complex than >> >> >> checking for a new field. Such players should also be updated to >> handle the new TrackOperation system too. > > My player is based on FFmpeg libraries which has its own MKV parser. This > time the stereomode flag is not used at all > (no way to read it from FFmpeg objects and it doesn't read from the header). > > When I released first player version last summer I found that mkvmerge can > define stereomode for video streams > and thus mark them as mono (seems to be not saved into file), left, right > and both (with unclear definition). > > I think that dedicated streams for each view (left and right are fit most > needs) is a logical and most optimal way > to save the stereoscopic video into MKV container. That time (last summer) I > can not read the left/right marks in the player > (I need to modify FFmpeg library or additionally to read MKV headers using > mkv library (ugly)) and assume that if > video contains 2 video streams - thats probably stereoscopic video with > dedicated streams per view. > > Now I want to implement correct way to read this field (probably - modify > FFmpeg sources) but go stuck that tag definition was completely changed! > I found this definition in mkvinfo sources: > enum mode { > ??? invalid??????????????????????? = -1, > ??? unspecified??????????????????? = -1, > ??? mono?????????????????????????? =? 0, > ??? side_by_side_left_first??????? =? 1, > ??? top_bottom_right_first???????? =? 2, > ??? top_bottom_left_first????????? =? 3, > ??? checkerboard_right_first?????? =? 4, > ??? checkerboard_left_first??????? =? 5, > ??? row_interleaved_right_first??? =? 6, > ??? row_interleaved_left_first???? =? 7, > ??? column_interleaved_right_first =? 8, > ??? column_interleaved_left_first? =? 9, > ??? anaglyph?????????????????????? = 10, > ??? side_by_side_right_first?????? = 11, > ? }; > > I have no idea what the reason to store that huge list of modes while the > most of them hopefully never used to store the stereovideo > itself but were designed for representation on for specific device (without > scaling): > > row-interleaved - was used in some old stereoscopic DVDs and is a native > format for some monitors (Zalman etc); > column interleaved - never heard it was used to store video but it is native > format for some obsolete stereo-monitors (SeaReal I heard); > checkerboard - never heard it was used to store video but it is native for > some 3D-ready DLP TVs; > anaglyph - have no idea what for player may use this flag, but to make it > unambiguous the list should contain all 3 color filters variations (most > popular Red/Cyan; Green/Purple; Yellow/Blue) and all marked which color left > / right :-!! > > Top/Bottom, Side-By-Side and dedicated streams per view are really most > demand by users. Others - device-specific formats and I hard to understand > what for some person or software/hardware will create MKV in these formats. > > In fact, I really don't care who and why this list was created so huge. But > I really sad that left/right options are lost! > I understand that these options are not unambiguous in case of 3+ video > streams in the container. > In this case simple additional enumeration may be used (Left, 1; Left, 2; > Right, 1; Right, 2) but to remove at all - not good solution. > >> While TrackCombinePlanes are a solution for new content with separate >> video streams, they do not solve the playback problem with files muxed >> according to the old specification. > > Could you explain me what this combine planes means and how it should be > saved using mkvmerge and could/should be used in a player? > > Thanks! > ----------------------------------------------- > Kirill Gavrilov, > Software designer. > > official site: sview.ru > e-mail: kirill at sview.ru > > _______________________________________________ > Matroska-devel mailing list > Matroska-devel at lists.matroska.org > http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel > Read Matroska-Devel on GMane: > http://dir.gmane.org/gmane.comp.multimedia.matroska.devel > -- Steve Lhomme Matroska association Chairman From andreas at lonelycoder.com Wed Feb 23 19:36:18 2011 From: andreas at lonelycoder.com (=?ISO-8859-1?Q?Andreas_=D6man?=) Date: Wed, 23 Feb 2011 19:36:18 +0100 Subject: [Matroska-devel] S_DVBSUB In-Reply-To: References: Message-ID: On Wed, Feb 23, 2011 at 6:28 PM, Steve Lhomme wrote: > On Tue, Feb 22, 2011 at 10:47 PM, Dan Haddix wrote: > > No. The decoder uses the page ID to decide whether or not to display the > > subtitle based on the composition and ancillary IDs of the selected > stream. > > There is no standard way of telling the decoder to ignore the page ID and > > decode everything. All we can do is trick the decoder into displaying > > everything by resetting the page ID on every segment to 1 during muxing > and > > then setting the composition and ancillary IDs for all MKV tracks to 1 in > > the player/demuxer. The only other way to do it would be to store the > real > > composition and ancillary IDs somewhere in the MKV track, but you seemed > to > > be against that originally. > > Well, I don't really see why we have to change a value in the stream > if in the end the decoder should not handle it (since the track was > already selected in Matroska). I seems that DVBSUB is a poorly defined > codec if decoders cannot bypass that step. > FFmpeg's DVBSUB decoder will decode all pages if no CodecPrivate data is available. So atleast that one should work fine without any modification to the page IDs > > But in the end I don't care, as we already have to copy common data > into Matroska, I suppose the header in the DVBSUB source packets will > already be managed, so changing it to any other value shouldn't be a > big issue. Just more for on the muxing side. > > -- > Steve Lhomme > Matroska association Chairman > _______________________________________________ > Matroska-devel mailing list > Matroska-devel at lists.matroska.org > http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel > Read Matroska-Devel on GMane: > http://dir.gmane.org/gmane.comp.multimedia.matroska.devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gavr.mail at gmail.com Wed Feb 23 21:40:59 2011 From: gavr.mail at gmail.com (=?KOI8-R?B?68nSyczMIOfB19LJzM/X?=) Date: Wed, 23 Feb 2011 23:40:59 +0300 Subject: [Matroska-devel] multiple video streams stereo 3D mode broken In-Reply-To: References: Message-ID: Thanks for reply and for links. About backward compatibility. As I found, old stereomode (had only mono/left/right/both values) was saved with ID 0x53B9. The new stereomode flag has id 0x53B8 and has another values enumeration with only combined modes. This mean that old flag will not be read by new parser at all (mkvinfo show me 'DummyElement' for old files) thus old value will not be reinterpret by any program in wrong way (but will be ignored). Technically both flags could be safely read for full compatibility. Am I right? I found this in specification notice: > The pixel count of the track (PixelWidth/PixelHeight) should be the raw > amount of pixels (for example 3840x1080 for full HD side by side) and the > DisplayWidth/Height in pixels should be the amount of pixels for one plane > (1920x1080 for that full HD stream) > The only reason for this strange behaviour - to simplify DAR settings by the user (if he know about this). But if player has no support for stereoplayback and probably - doesn't fit this special agreement, than video will be shown with wrong Display Aspect Ratio (because it will be applied for combined stereopair). This is sans logique for me to apply different PAR/DAR for each combined mode. Is this agreement is final and will never changed? The only players I heard (I have no any) that do this like this - some hardware stereoscopic players. But they do this regardless PAR/DAR settings in container - they just ALWAYS show 1080p/720p video (for combined stereopair - thus video is anamorphic) as 16:9 for one plane (according to selected source format). If agreement for PAR/DAR is final (at least for matroska container), than FFmpeg library should ALWAYS apply special PAR conversion according stereomode flag to fit the agreement (thus video will be shown with correct aspect ratio regardless stereo support in the player). For the TrackCombinePlanes explanation you may want to look at this: > http://www.matroska.org/technical/specs/notes.html#TrackOperation > > What you had with left, and right separated is now handled that way. > These tracks remain but then you have a third virtual track that is > the actual 3D version. > As I understand, virtual tracks declared are created in other layer (not as track options). And virtual tracks aware parser will just ignore this information (and stereo video tracks will still be available just without any way to distinct them while technically TrackPlaneType currently has very simple definition). Thats not bad. Another of my question was: Could you explain me what this combine planes means and how it should be > saved using mkvmerge and could/should be used in a player? > I fail to find support for combine planes in current mkv tools (mkvmerge and mkvpropedit). I should understand - it is in progress? To support new behaviour in my program I should change FFmpeg matroska parser (and probably define some new definitions in API). So, I want to ask - is someone from matroska developers responsible to save FFmpeg implementation in sync? I'm not yet FFmpeg developer but I'll try to create patch if noone from resident developers is interest in it. ----------------- Kirill Gavrilov, Software designer. official site: sview.ru e-mail: kirill at sview.ru -------------- next part -------------- An HTML attachment was scrubbed... URL: From dan6992 at hotmail.com Thu Feb 24 00:02:00 2011 From: dan6992 at hotmail.com (Dan Haddix) Date: Wed, 23 Feb 2011 23:02:00 +0000 Subject: [Matroska-devel] S_DVBSUB In-Reply-To: References: , , , , , , , , , , , Message-ID: > Date: Wed, 23 Feb 2011 18:28:16 +0100 > Subject: Re: [Matroska-devel] S_DVBSUB > From: slhomme at matroska.org > To: dan6992 at hotmail.com; matroska-devel at lists.matroska.org > > On Tue, Feb 22, 2011 at 10:47 PM, Dan Haddix wrote: > > No. The decoder uses the page ID to decide whether or not to display the > > subtitle based on the composition and ancillary IDs of the selected stream. > > There is no standard way of telling the decoder to ignore the page ID and > > decode everything. All we can do is trick the decoder into displaying > > everything by resetting the page ID on every segment to 1 during muxing and > > then setting the composition and ancillary IDs for all MKV tracks to 1 in > > the player/demuxer. The only other way to do it would be to store the real > > composition and ancillary IDs somewhere in the MKV track, but you seemed to > > be against that originally. > > Well, I don't really see why we have to change a value in the stream > if in the end the decoder should not handle it (since the track was > already selected in Matroska). I seems that DVBSUB is a poorly defined > codec if decoders cannot bypass that step. > > But in the end I don't care, as we already have to copy common data > into Matroska, I suppose the header in the DVBSUB source packets will > already be managed, so changing it to any other value shouldn't be a > big issue. Just more for on the muxing side. > > -- > Steve Lhomme > Matroska association Chairman The page ID of the segments have to match either the composition or ancillary ID set for the track or the decoder will ignore them. Some decoders may have the ability to be set to a "decode all" mode and ignore the page ID, but there is no standard way of doing that so I'm not sure we can depend on it always being available in every application. Plus we also have to think about applications, like VideoReDo, which have the ability to convert from MKV to TS. A TS file needs to have the proper composition and ancillary IDs stored in it's PMT. If we don't reset the page IDs of every segment to a static, known, value or store the original composition and ancillary IDs in the MKV somewhere then we'd have to scan the entire file checking every segment just to determine the proper values. That is far from ideal. Maybe we should just go back to my original idea of storing the original PMT data in CodecPrivate. If the playing app knows how to read that then it can, if not then it can just set it's DVB subtitle decoder to "decode all" and it will still work. That way we don't have to mess with the page ID in the original segments and we'll have the proper composition and ancillary IDs available for applications that want to convert to TS. Dan -------------- next part -------------- An HTML attachment was scrubbed... URL: From ashwood at msn.com Thu Feb 24 07:51:52 2011 From: ashwood at msn.com (Joseph Ashwood) Date: Wed, 23 Feb 2011 22:51:52 -0800 Subject: [Matroska-devel] Matroska v3 In-Reply-To: References: Message-ID: I've split this into different messages on different subjects. I have also limited this one to the dev list, not to exclude the the general list, but because this is not current but future oriented. Since we seem to be moving decidedly towards a V3, this seems to be a good time to discuss adding significant features. I've seen some interest from manufacturers to implement haptics in video moving forward. The devices for doing this are so varied that a single standard really isn't possible yet. The devices themself vary from a subwoofer-like device attached to the bottom of the seat to certain devices of an adult nature. Right now, haptic devices are extremely rare, but I've seen either market ready or working prototypes for roughly a dozen such devices. Its also worth noting that multiple devices may be used at the same time (e.g. one seat shifter, one wind simulator). In terms of how to implement, I think the appropriate path is 0 or more separate streams, of which 0 or more streams may be active, each stream dedicated to one device (although some devices may be compound). Many of the streams will be very similar to subtitle tracks, although as implemented right now many of them include DRM. I'm in favor of it simply being their problem to make that work, most of them don't seem to mind that. The other option that seems to be used is an audio track, again I think its up to them to make it work, even though this on is easier (heavily compressed audio and a low pass filter). So what is the view on including a new type of stream for haptics devices? Joe 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-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 Fri Feb 25 14:15:52 2011 From: slhomme at matroska.org (Steve Lhomme) Date: Fri, 25 Feb 2011 14:15:52 +0100 Subject: [Matroska-devel] S_DVBSUB In-Reply-To: References: Message-ID: On Thu, Feb 24, 2011 at 12:02 AM, Dan Haddix wrote: > The page ID of the segments have to match either the composition or > ancillary ID set for the track or the decoder will ignore them. Some > decoders may have the ability to be set to a "decode all" mode and ignore > the page ID, but there is no standard way of doing that so I'm not sure we > can depend on it always being available in every application. Plus we also > have to think about applications, like VideoReDo, which have the ability to > convert from MKV to TS. A TS file needs to have the proper composition and > ancillary IDs stored in it's PMT. If we don't reset the page IDs of every > segment to a static, known, value or store the original composition and > ancillary IDs in the MKV somewhere then we'd have to scan the entire file > checking every segment just to determine the proper values. That is far from > ideal. > > Maybe we should just go back to my original idea of storing the original PMT > data in CodecPrivate. If the playing app knows how to read that then it can, > if not then it can just set it's DVB subtitle decoder to "decode all" and it > will still work. That way we don't have to mess with the page ID in the > original segments and we'll have the proper composition and ancillary IDs > available for applications that want to convert to TS. Yes, that won't hurt much and if some decoders need it, then it's there. -- Steve Lhomme Matroska association Chairman From dan6992 at hotmail.com Sat Feb 26 01:21:44 2011 From: dan6992 at hotmail.com (Dan Haddix) Date: Sat, 26 Feb 2011 00:21:44 +0000 Subject: [Matroska-devel] S_DVBSUB In-Reply-To: References: , , , , , , , , , , , , , Message-ID: > Date: Fri, 25 Feb 2011 14:15:52 +0100 > Subject: Re: [Matroska-devel] S_DVBSUB > From: slhomme at matroska.org > To: dan6992 at hotmail.com > CC: matroska-devel at lists.matroska.org; andreas at lonelycoder.com > > On Thu, Feb 24, 2011 at 12:02 AM, Dan Haddix wrote: > > The page ID of the segments have to match either the composition or > > ancillary ID set for the track or the decoder will ignore them. Some > > decoders may have the ability to be set to a "decode all" mode and ignore > > the page ID, but there is no standard way of doing that so I'm not sure we > > can depend on it always being available in every application. Plus we also > > have to think about applications, like VideoReDo, which have the ability to > > convert from MKV to TS. A TS file needs to have the proper composition and > > ancillary IDs stored in it's PMT. If we don't reset the page IDs of every > > segment to a static, known, value or store the original composition and > > ancillary IDs in the MKV somewhere then we'd have to scan the entire file > > checking every segment just to determine the proper values. That is far from > > ideal. > > > > Maybe we should just go back to my original idea of storing the original PMT > > data in CodecPrivate. If the playing app knows how to read that then it can, > > if not then it can just set it's DVB subtitle decoder to "decode all" and it > > will still work. That way we don't have to mess with the page ID in the > > original segments and we'll have the proper composition and ancillary IDs > > available for applications that want to convert to TS. > > Yes, that won't hurt much and if some decoders need it, then it's there. > > -- > Steve Lhomme > Matroska association Chairman OK so the only stipulation I would have is that if the muxer is not going to store composition and ancillary IDs in CodecPrivate then they MUST reset the page ID on all segments to a single known value. (0 would be OK) That way programs that need those values can default to known value if the CodecPrivate data does not exist. Also are we agreed that the CodecPrivate will contain data in the same format as the descriptor data from the TS PMT? It has the following format... ISO_639_language_code - 24 bits subtitling_type - 8 bits composition_page_id - 16 bits ancillary_page_id - 16 bits Normally this is stored as an array for each substream, but since we're only allowing a single stream to be stored in each MKV track we could stipulate that the CodecPrivate can only contain these 8 bytes. Dan -------------- next part -------------- An HTML attachment was scrubbed... URL: From slhomme at matroska.org Sat Feb 26 08:43:45 2011 From: slhomme at matroska.org (Steve Lhomme) Date: Sat, 26 Feb 2011 08:43:45 +0100 Subject: [Matroska-devel] S_DVBSUB In-Reply-To: References: Message-ID: On Sat, Feb 26, 2011 at 1:21 AM, Dan Haddix wrote: >> Date: Fri, 25 Feb 2011 14:15:52 +0100 >> Subject: Re: [Matroska-devel] S_DVBSUB >> From: slhomme at matroska.org >> To: dan6992 at hotmail.com >> CC: matroska-devel at lists.matroska.org; andreas at lonelycoder.com >> >> On Thu, Feb 24, 2011 at 12:02 AM, Dan Haddix wrote: >> > The page ID of the segments have to match either the composition or >> > ancillary ID set for the track or the decoder will ignore them. Some >> > decoders may have the ability to be set to a "decode all" mode and >> > ignore >> > the page ID, but there is no standard way of doing that so I'm not sure >> > we >> > can depend on it always being available in every application. Plus we >> > also >> > have to think about applications, like VideoReDo, which have the ability >> > to >> > convert from MKV to TS. A TS file needs to have the proper composition >> > and >> > ancillary IDs stored in it's PMT. If we don't reset the page IDs of >> > every >> > segment to a static, known, value or store the original composition and >> > ancillary IDs in the MKV somewhere then we'd have to scan the entire >> > file >> > checking every segment just to determine the proper values. That is far >> > from >> > ideal. >> > >> > Maybe we should just go back to my original idea of storing the original >> > PMT >> > data in CodecPrivate. If the playing app knows how to read that then it >> > can, >> > if not then it can just set it's DVB subtitle decoder to "decode all" >> > and it >> > will still work. That way we don't have to mess with the page ID in the >> > original segments and we'll have the proper composition and ancillary >> > IDs >> > available for applications that want to convert to TS. >> >> Yes, that won't hurt much and if some decoders need it, then it's there. >> >> -- >> Steve Lhomme >> Matroska association Chairman > > OK so the only stipulation I would have is that if the muxer is not going to > store composition and ancillary IDs in CodecPrivate then they MUST reset the > page ID on all segments to a single known value. (0 would be OK) That way > programs that need those values can default to known value if the > CodecPrivate data does not exist. I'm not sure we should allow both. If some players need the info, at muxing time you have no way to know and should not restrict the plyer use, especially if the Codec ID is the same. So I think it should always be there. > Also are we agreed that the CodecPrivate will contain data in the same > format as the descriptor data from the TS PMT? It has the following > format... > > ISO_639_language_code - 24 bits > subtitling_type??????????????? - 8 bits > composition_page_id????? - 16 bits > ancillary_page_id?????????? - 16 bits > > Normally this is stored as an array for each substream, but since we're only > allowing a single stream to be stored in each MKV track we could stipulate > that the CodecPrivate can only contain these 8 bytes. Correct -- Steve Lhomme Matroska association Chairman From dan6992 at hotmail.com Sat Feb 26 10:32:01 2011 From: dan6992 at hotmail.com (Dan Haddix) Date: Sat, 26 Feb 2011 09:32:01 +0000 Subject: [Matroska-devel] S_DVBSUB In-Reply-To: References: , , , , , , , , , , , , , , , Message-ID: > Date: Sat, 26 Feb 2011 08:43:45 +0100 > Subject: Re: [Matroska-devel] S_DVBSUB > From: slhomme at matroska.org > To: dan6992 at hotmail.com > CC: matroska-devel at lists.matroska.org; andreas at lonelycoder.com > > On Sat, Feb 26, 2011 at 1:21 AM, Dan Haddix wrote: > >> Date: Fri, 25 Feb 2011 14:15:52 +0100 > >> Subject: Re: [Matroska-devel] S_DVBSUB > >> From: slhomme at matroska.org > >> To: dan6992 at hotmail.com > >> CC: matroska-devel at lists.matroska.org; andreas at lonelycoder.com > >> > >> On Thu, Feb 24, 2011 at 12:02 AM, Dan Haddix wrote: > >> > The page ID of the segments have to match either the composition or > >> > ancillary ID set for the track or the decoder will ignore them. Some > >> > decoders may have the ability to be set to a "decode all" mode and > >> > ignore > >> > the page ID, but there is no standard way of doing that so I'm not sure > >> > we > >> > can depend on it always being available in every application. Plus we > >> > also > >> > have to think about applications, like VideoReDo, which have the ability > >> > to > >> > convert from MKV to TS. A TS file needs to have the proper composition > >> > and > >> > ancillary IDs stored in it's PMT. If we don't reset the page IDs of > >> > every > >> > segment to a static, known, value or store the original composition and > >> > ancillary IDs in the MKV somewhere then we'd have to scan the entire > >> > file > >> > checking every segment just to determine the proper values. That is far > >> > from > >> > ideal. > >> > > >> > Maybe we should just go back to my original idea of storing the original > >> > PMT > >> > data in CodecPrivate. If the playing app knows how to read that then it > >> > can, > >> > if not then it can just set it's DVB subtitle decoder to "decode all" > >> > and it > >> > will still work. That way we don't have to mess with the page ID in the > >> > original segments and we'll have the proper composition and ancillary > >> > IDs > >> > available for applications that want to convert to TS. > >> > >> Yes, that won't hurt much and if some decoders need it, then it's there. > >> > >> -- > >> Steve Lhomme > >> Matroska association Chairman > > > > OK so the only stipulation I would have is that if the muxer is not going to > > store composition and ancillary IDs in CodecPrivate then they MUST reset the > > page ID on all segments to a single known value. (0 would be OK) That way > > programs that need those values can default to known value if the > > CodecPrivate data does not exist. > > I'm not sure we should allow both. If some players need the info, at > muxing time you have no way to know and should not restrict the plyer > use, especially if the Codec ID is the same. So I think it should > always be there. > > > Also are we agreed that the CodecPrivate will contain data in the same > > format as the descriptor data from the TS PMT? It has the following > > format... > > > > ISO_639_language_code - 24 bits > > subtitling_type - 8 bits > > composition_page_id - 16 bits > > ancillary_page_id - 16 bits > > > > Normally this is stored as an array for each substream, but since we're only > > allowing a single stream to be stored in each MKV track we could stipulate > > that the CodecPrivate can only contain these 8 bytes. > > Correct > -- > Steve Lhomme > Matroska association Chairman OK I think we have a plan. I'm going to lay it out one more time just for posterity... If a DVB subtitle stream contains more then one substream then the muxer must separate each substream into individual MKV tracks. This can be done by either... a) creating a copy of each segment who's page ID corresponds to either the composition or the ancillary ID of the substream to that track or b) using the TrackOperation tag to create a virtual track which automatically combines segments from two other tracks which contain the ancillary data and the composition data respectively. In addition each MKV track will contain 8 bytes of CodecPrivate data which will contain the following information... ISO_639_language_code - 24 bits subtitling_type - 8 bits composition_page_id - 16 bits ancillary_page_id - 16 bits No default values are assumed for these variables so if the CodecPrivate data is missing, or malformed, then the track will be treated as invalid and rejected by the player/demuxer. If that sounds right then I will add support to VRD for the next release. I can also help add playback support to VLC. Although I can't currently build VLC so someone else will need to build the changes and test them out. Any volunteers? Now that we're done with this do we want to discuss how best to store 608/708 captions and Teletext? :) Dan -------------- next part -------------- An HTML attachment was scrubbed... URL: From slhomme at matroska.org Sat Feb 26 10:34:32 2011 From: slhomme at matroska.org (Steve Lhomme) Date: Sat, 26 Feb 2011 10:34:32 +0100 Subject: [Matroska-devel] S_DVBSUB In-Reply-To: References: Message-ID: On Sat, Feb 26, 2011 at 10:32 AM, Dan Haddix wrote: > OK I think we have a plan. I'm going to lay it out one more time just for > posterity... > > If a DVB subtitle stream contains more then one substream then the muxer > must separate each substream into individual MKV tracks. This can be done by > either... a) creating a copy of each segment who's page ID corresponds to > either the composition or the ancillary ID of the substream to that track or > b) using the TrackOperation tag to create a virtual track which > automatically combines segments from two other tracks which contain the > ancillary data and the composition data respectively. > > In addition each MKV track will contain 8 bytes of CodecPrivate data which > will contain the following information... > > ISO_639_language_code - 24 bits > subtitling_type??????????????? - 8 bits > composition_page_id????? - 16 bits > ancillary_page_id?????????? - 16 bits > > No default values are assumed for these variables so if the CodecPrivate > data is missing, or malformed, then the track will be treated as invalid and > rejected by the player/demuxer. > > If that sounds right then I will add support to VRD for the next release. I > can also help add playback support to VLC. Although I can't currently build > VLC so someone else will need to build the changes and test them out. Any > volunteers? Not for now. I have plenty of things to do on VLC but I lack the time. What platform are you building VLC on ? On windows it turns out it's easier to use a Linux Virtual Machine to cross-build it, and then use the package on windows (via local network sharing). > Now that we're done with this do we want to discuss how best to store > 608/708 captions and Teletext? :) Good luck ;) -- Steve Lhomme Matroska association Chairman From slhomme at matroska.org Sat Feb 26 11:08:02 2011 From: slhomme at matroska.org (Steve Lhomme) Date: Sat, 26 Feb 2011 11:08:02 +0100 Subject: [Matroska-devel] Matroska v3 In-Reply-To: References: Message-ID: On Thu, Feb 24, 2011 at 7:51 AM, Joseph Ashwood wrote: > Since we seem to be moving decidedly towards a V3, this seems to be a good > time to discuss adding significant features. I've seen some interest from > manufacturers to implement haptics in video moving forward. That sounds interresting. > The devices for doing this are so varied that a single standard really isn't > possible yet. The devices themself vary from a subwoofer-like device > attached to the bottom of the seat to certain devices of an adult nature. Sounds like different track types would be needed to do that. And corresponding "codecs" to define the effects to use with their parameters. > Right now, haptic devices are extremely rare, but I've seen either market > ready or working prototypes for roughly a dozen such devices. Its also worth > noting that multiple devices may be used at the same time (e.g. one seat > shifter, one wind simulator). > > In terms of how to implement, I think the appropriate path is 0 or more > separate streams, of which 0 or more streams may be active, each stream > dedicated to one device (although some devices may be compound). Many of the > streams will be very similar to subtitle tracks, although as implemented > right now many of them include DRM. I'm in favor of it simply being their > problem to make that work, most of them don't seem to mind that. The other > option that seems to be used is an audio track, again I think its up to them > to make it work, even though this on is easier (heavily compressed audio and > a low pass filter). > > So what is the view on including a new type of stream for haptics devices? As said above it's probably good to have a separate track for that (or more than one). In the end the audio and video streams should work just like they do now. It would be possible to use BlockAddition for an extra sub-woofer track using the same audio codec. But most audio codec have some kind of high pass filter to remove everything under 20 Hz. (I think the CD format too). So a special codec may be needed for that as well. It would be good to have a list of possible types of haptics to know how we can handle them. For example the sub-woofer may not say it's an audio track but a sub-woofer track, so that players that don't have such capabilities skip it. For the other streams they may just be an extra "haptic" track type and the codec would define what it does ? So that leaves freedom on what features a "codec" can provide. -- Steve Lhomme Matroska association Chairman 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-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 From andreas at lonelycoder.com Sat Feb 26 12:48:23 2011 From: andreas at lonelycoder.com (=?ISO-8859-1?Q?Andreas_=D6man?=) Date: Sat, 26 Feb 2011 12:48:23 +0100 Subject: [Matroska-devel] S_DVBSUB In-Reply-To: References: Message-ID: On Sat, Feb 26, 2011 at 1:21 AM, Dan Haddix wrote: > > Date: Fri, 25 Feb 2011 14:15:52 +0100 > > > Subject: Re: [Matroska-devel] S_DVBSUB > > From: slhomme at matroska.org > > To: dan6992 at hotmail.com > > CC: matroska-devel at lists.matroska.org; andreas at lonelycoder.com > > > > > On Thu, Feb 24, 2011 at 12:02 AM, Dan Haddix > wrote: > > > The page ID of the segments have to match either the composition or > > > ancillary ID set for the track or the decoder will ignore them. Some > > > decoders may have the ability to be set to a "decode all" mode and > ignore > > > the page ID, but there is no standard way of doing that so I'm not sure > we > > > can depend on it always being available in every application. Plus we > also > > > have to think about applications, like VideoReDo, which have the > ability to > > > convert from MKV to TS. A TS file needs to have the proper composition > and > > > ancillary IDs stored in it's PMT. If we don't reset the page IDs of > every > > > segment to a static, known, value or store the original composition and > > > ancillary IDs in the MKV somewhere then we'd have to scan the entire > file > > > checking every segment just to determine the proper values. That is far > from > > > ideal. > > > > > > Maybe we should just go back to my original idea of storing the > original PMT > > > data in CodecPrivate. If the playing app knows how to read that then it > can, > > > if not then it can just set it's DVB subtitle decoder to "decode all" > and it > > > will still work. That way we don't have to mess with the page ID in the > > > original segments and we'll have the proper composition and ancillary > IDs > > > available for applications that want to convert to TS. > > > > Yes, that won't hurt much and if some decoders need it, then it's there. > > > > -- > > Steve Lhomme > > Matroska association Chairman > > OK so the only stipulation I would have is that if the muxer is not going > to store composition and ancillary IDs in CodecPrivate then they MUST reset > the page ID on all segments to a single known value. (0 would be OK) That > way programs that need those values can default to known value if the > CodecPrivate data does not exist. > > Also are we agreed that the CodecPrivate will contain data in the same > format as the descriptor data from the TS PMT? It has the following > format... > > ISO_639_language_code - 24 bits > subtitling_type - 8 bits > composition_page_id - 16 bits > ancillary_page_id - 16 bits > Makes sense but I guess it would be preferred if applications also sets the normal track language tag? Also, which one should take precedence if they differ during demuxing? I would expect that the native matroska tag is preferred in those cases? > > Normally this is stored as an array for each substream, but since we're > only allowing a single stream to be stored in each MKV track we could > stipulate that the CodecPrivate can only contain these 8 bytes. > > Dan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andreas at lonelycoder.com Sat Feb 26 12:56:34 2011 From: andreas at lonelycoder.com (=?ISO-8859-1?Q?Andreas_=D6man?=) Date: Sat, 26 Feb 2011 12:56:34 +0100 Subject: [Matroska-devel] S_DVBSUB In-Reply-To: References: Message-ID: On Sat, Feb 26, 2011 at 10:34 AM, Steve Lhomme wrote: > On Sat, Feb 26, 2011 at 10:32 AM, Dan Haddix wrote: > > OK I think we have a plan. I'm going to lay it out one more time just for > > posterity... > > > > If a DVB subtitle stream contains more then one substream then the muxer > > must separate each substream into individual MKV tracks. This can be done > by > > either... a) creating a copy of each segment who's page ID corresponds to > > either the composition or the ancillary ID of the substream to that track > or > > b) using the TrackOperation tag to create a virtual track which > > automatically combines segments from two other tracks which contain the > > ancillary data and the composition data respectively. > > > > In addition each MKV track will contain 8 bytes of CodecPrivate data > which > > will contain the following information... > > > > ISO_639_language_code - 24 bits > > subtitling_type - 8 bits > > composition_page_id - 16 bits > > ancillary_page_id - 16 bits > > > > No default values are assumed for these variables so if the CodecPrivate > > data is missing, or malformed, then the track will be treated as invalid > and > > rejected by the player/demuxer. > > > > If that sounds right then I will add support to VRD for the next release. > I > > can also help add playback support to VLC. Although I can't currently > build > > VLC so someone else will need to build the changes and test them out. Any > > volunteers? > > Not for now. I have plenty of things to do on VLC but I lack the time. > What platform are you building VLC on ? On windows it turns out it's > easier to use a Linux Virtual Machine to cross-build it, and then use > the package on windows (via local network sharing). > I'll fix my video recording application 'Tvheadend' [1] to write S_DVBSUB correctly. Currently it just writes the data and stores 4 bytes in CodecPrivate (mostly because this was easiest at the time and required a 1 line patch in FFmpeg to work) Perhaps when we're done we could do some interop tests? > > > Now that we're done with this do we want to discuss how best to store > > 608/708 captions and Teletext? :) > > Good luck ;) > Heh, Tvheadend just decodes each language from its teletext page and writes those as S_TEXT/UTF8. The obvious upside is that it works with most players out there. Downside is that colors, etc are lost. Perhaps writing it as SSA or something would be better. I'm personally very much against inventing a new encoding as there are ways to encode text subtitles already. [1] http://www.lonelycoder.com/tvheadend -------------- next part -------------- An HTML attachment was scrubbed... URL: From slhomme at matroska.org Sat Feb 26 13:04:42 2011 From: slhomme at matroska.org (Steve Lhomme) Date: Sat, 26 Feb 2011 13:04:42 +0100 Subject: [Matroska-devel] S_DVBSUB In-Reply-To: References: Message-ID: On Sat, Feb 26, 2011 at 12:48 PM, Andreas ?man wrote: >> OK so the only stipulation I would have is that if the muxer is not going >> to store composition and ancillary IDs in CodecPrivate then they MUST reset >> the page ID on all segments to a single known value. (0 would be OK) That >> way programs that need those values can default to known value if the >> CodecPrivate data does not exist. >> >> Also are we agreed that the CodecPrivate will contain data in the same >> format as the descriptor data from the TS PMT? It has the following >> format... >> >> ISO_639_language_code - 24 bits >> subtitling_type??????????????? - 8 bits >> composition_page_id????? - 16 bits >> ancillary_page_id?????????? - 16 bits > > Makes sense but I guess it would be preferred if applications also sets the > normal track language tag? > Also, which one should take precedence if they differ during demuxing? I > would expect that the native matroska tag is preferred in those cases? Yes, all information that is inside a codec and also exists at the container should also appear in the container. And the container takes precedence. Just like video width/height and forcing an aspect ratio. >> Normally this is stored as an array for each substream, but since we're >> only allowing a single stream to be stored in each MKV track we could >> stipulate that the CodecPrivate can only contain these 8 bytes. >> >> Dan > > -- Steve Lhomme Matroska association Chairman From dan6992 at hotmail.com Sat Feb 26 20:23:47 2011 From: dan6992 at hotmail.com (Dan Haddix) Date: Sat, 26 Feb 2011 19:23:47 +0000 Subject: [Matroska-devel] S_DVBSUB In-Reply-To: References: , , , , , , , , , , , , , , , , Message-ID: > Date: Sat, 26 Feb 2011 13:04:42 +0100 > Subject: Re: [Matroska-devel] S_DVBSUB > From: slhomme at matroska.org > To: andreas at lonelycoder.com > CC: dan6992 at hotmail.com; matroska-devel at lists.matroska.org > > On Sat, Feb 26, 2011 at 12:48 PM, Andreas ?man wrote: > >> OK so the only stipulation I would have is that if the muxer is not going > >> to store composition and ancillary IDs in CodecPrivate then they MUST reset > >> the page ID on all segments to a single known value. (0 would be OK) That > >> way programs that need those values can default to known value if the > >> CodecPrivate data does not exist. > >> > >> Also are we agreed that the CodecPrivate will contain data in the same > >> format as the descriptor data from the TS PMT? It has the following > >> format... > >> > >> ISO_639_language_code - 24 bits > >> subtitling_type - 8 bits > >> composition_page_id - 16 bits > >> ancillary_page_id - 16 bits > > > > Makes sense but I guess it would be preferred if applications also sets the > > normal track language tag? > > Also, which one should take precedence if they differ during demuxing? I > > would expect that the native matroska tag is preferred in those cases? > > Yes, all information that is inside a codec and also exists at the > container should also appear in the container. And the container takes > precedence. Just like video width/height and forcing an aspect ratio. > > >> Normally this is stored as an array for each substream, but since we're > >> only allowing a single stream to be stored in each MKV track we could > >> stipulate that the CodecPrivate can only contain these 8 bytes. > >> > >> Dan > > > > > > > > -- > Steve Lhomme > Matroska association Chairman I agree that the MKV language should take president. However if the muxer does it right they should match, so it shouldn't be a big problem. Dan -------------- next part -------------- An HTML attachment was scrubbed... URL: From slhomme at matroska.org Sun Feb 27 09:54:02 2011 From: slhomme at matroska.org (Steve Lhomme) Date: Sun, 27 Feb 2011 09:54:02 +0100 Subject: [Matroska-devel] multiple video streams stereo 3D mode broken In-Reply-To: References: Message-ID: Hi, 2011/2/23 ?????? ???????? : > About backward compatibility. As I found, old stereomode (had only > mono/left/right/both values) was saved with ID 0x53B9. > The new stereomode flag has id 0x53B8 and has another values enumeration > with only combined modes. In fact I think the specs have always said 0x53B8 but libmatroska had 0x53B9 instead. It was fixed in libmatroska 0.9.0 released in may 2010. The oldeest revision of the specs we have with a date : http://www.matroska.org/node/1/revisions/1/view (also may 2010) > This mean that old flag will not be read by new parser at all (mkvinfo show > me 'DummyElement' for old files) > thus old value will not be reinterpret by any program in wrong way (but will > be ignored). > Technically both flags could be safely read for full compatibility. Am I > right? Yes, except this is due to a libmatroska bug. I don't know if other code was used to produce/read such files. Current readers should use the values pre-defined in StereoMode when: it's 0x53B8 and Matroska version EBMLReadVersion is 3 or more. Otherwise the old values can be assumed. In WebM 0x53B8 is sufficient to know it's the new values. And of course 0x53B9 will mean old values. > I found this in specification notice: >> >> The pixel count of the track (PixelWidth/PixelHeight) should be the raw >> amount of pixels (for example 3840x1080 for full HD side by side) and the >> DisplayWidth/Height in pixels should be the amount of pixels for one plane >> (1920x1080 for that full HD stream) > > The only reason for this strange behaviour - to simplify DAR settings by the > user (if he know about this). > But if player has no support for stereoplayback and probably - doesn't fit > this special agreement, than video will be shown with wrong Display Aspect > Ratio > (because it will be applied for combined stereopair). This is sans logique > for me to apply different PAR/DAR for each combined mode. > Is this agreement is final and will never changed? It can change, but this is only the case when video is encoding side-by-side. If the reader doesn't know about StereoMode there's even less chance it would be able to tell the decoder to keep only one side. So in any case the display is screwed. In the case the playback chain knows about StereoMode and side-by-side then it's the way to tell if the resolution is half the regular one or the full one on the final display. > The only players I heard (I have no any) that do this like this - some > hardware stereoscopic players. But they do this regardless PAR/DAR settings > in container > - they just ALWAYS show 1080p/720p video (for combined stereopair - thus > video is anamorphic) as 16:9 for one plane (according to selected source > format). If they don't care about the PAR/DAR then there is no issue. > If agreement for PAR/DAR is final (at least for matroska container), > than FFmpeg library should ALWAYS apply special PAR conversion according > stereomode flag to fit the agreement > (thus video will be shown with correct aspect ratio regardless stereo > support in the player). Does FFmpeg have the flags to tell a video is side by side ? I think if you reencode a video with FFmpeg it will keep the aspect ratio on the output. So all you need is make sure the pixel resolution you set is still matching the side-by-side aspect. >> For the TrackCombinePlanes explanation you may want to look at this: >> http://www.matroska.org/technical/specs/notes.html#TrackOperation >> >> What you had with left, and right separated is now handled that way. >> These tracks remain but then you have a third virtual track that is >> the actual 3D version. > > As I understand, virtual tracks declared are created in other layer (not as > track options). No, they are declared just like any other track. That's the whole point, that everything that applies to tracks apply to virtual ones as well. > And virtual tracks aware parser will just ignore this information (and > stereo video tracks will still be available > just without any way to distinct them while technically TrackPlaneType > currently has very simple definition). > Thats not bad. Parsers that don't know about TrackOperation will not be able to play these tracks. That's one of the reason for the bump to Matroska v3. A file marked as readable by v3 (and up) compliant readers and can only handle v2 may decide not to play the file. The left and right tracks may be marked as NOT Enabled as well (0xB9) and then the player ens up with just the virtual track that it can't play anyway. > Another of my question was: >> >> Could you explain me what this combine planes means and how it should be >> saved using mkvmerge and could/should be used in a player? > > I fail to find support for combine planes in current mkv tools (mkvmerge and > mkvpropedit). > I should understand - it is in progress? Yes > To support new behaviour in my program I should change FFmpeg matroska > parser (and probably define some new definitions in API). > So, I want to ask - is someone from matroska developers responsible to save > FFmpeg implementation in sync? > I'm not yet FFmpeg developer but I'll try to create patch if noone from > resident developers is interest in it. I haven't followed the work on FFmpeg for a while, but no there is no direct contact to make this happen. Usually people add features in their programs when they encounter files they can't play. I suppose 3D is quite new and I don't think FFmpeg has been tweaked yet to handle all the 3D possibilities. The best way to find out is ask on their mailing lists or IRC channel. Steve -- Steve Lhomme Matroska association Chairman From slhomme at matroska.org Sun Feb 27 10:11:25 2011 From: slhomme at matroska.org (Steve Lhomme) Date: Sun, 27 Feb 2011 10:11:25 +0100 Subject: [Matroska-devel] multiple video streams stereo 3D mode broken In-Reply-To: References: Message-ID: I added a note about the older values of StereoMode: http://www.matroska.org/technical/specs/notes.html#3D 2011/2/27 Steve Lhomme : > Hi, > > 2011/2/23 ?????? ???????? : >> About backward compatibility. As I found, old stereomode (had only >> mono/left/right/both values) was saved with ID 0x53B9. >> The new stereomode flag has id 0x53B8 and has another values enumeration >> with only combined modes. > > In fact I think the specs have always said 0x53B8 but libmatroska had > 0x53B9 instead. It was fixed in libmatroska 0.9.0 released in may > 2010. > The oldeest revision of the specs we have with a date : > http://www.matroska.org/node/1/revisions/1/view (also may 2010) > >> This mean that old flag will not be read by new parser at all (mkvinfo show >> me 'DummyElement' for old files) >> thus old value will not be reinterpret by any program in wrong way (but will >> be ignored). >> Technically both flags could be safely read for full compatibility. Am I >> right? > > Yes, except this is due to a libmatroska bug. I don't know if other > code was used to produce/read such files. > > Current readers should use the values pre-defined in StereoMode when: > it's 0x53B8 and Matroska version EBMLReadVersion is 3 or more. > Otherwise the old values can be assumed. In WebM 0x53B8 is sufficient > to know it's the new values. > > And of course 0x53B9 will mean old values. > >> I found this in specification notice: >>> >>> The pixel count of the track (PixelWidth/PixelHeight) should be the raw >>> amount of pixels (for example 3840x1080 for full HD side by side) and the >>> DisplayWidth/Height in pixels should be the amount of pixels for one plane >>> (1920x1080 for that full HD stream) >> >> The only reason for this strange behaviour - to simplify DAR settings by the >> user (if he know about this). >> But if player has no support for stereoplayback and probably - doesn't fit >> this special agreement, than video will be shown with wrong Display Aspect >> Ratio >> (because it will be applied for combined stereopair). This is sans logique >> for me to apply different PAR/DAR for each combined mode. >> Is this agreement is final and will never changed? > > It can change, but this is only the case when video is encoding > side-by-side. If the reader doesn't know about StereoMode there's even > less chance it would be able to tell the decoder to keep only one > side. So in any case the display is screwed. > In the case the playback chain knows about StereoMode and side-by-side > then it's the way to tell if the resolution is half the regular one or > the full one on the final display. > >> The only players I heard (I have no any) that do this like this - some >> hardware stereoscopic players. But they do this regardless PAR/DAR settings >> in container >> - they just ALWAYS show 1080p/720p video (for combined stereopair - thus >> video is anamorphic) as 16:9 for one plane (according to selected source >> format). > > If they don't care about the PAR/DAR then there is no issue. > >> If agreement for PAR/DAR is final (at least for matroska container), >> than FFmpeg library should ALWAYS apply special PAR conversion according >> stereomode flag to fit the agreement >> (thus video will be shown with correct aspect ratio regardless stereo >> support in the player). > > Does FFmpeg have the flags to tell a video is side by side ? > > I think if you reencode a video with FFmpeg it will keep the aspect > ratio on the output. So all you need is make sure the pixel resolution > you set is still matching the side-by-side aspect. > >>> For the TrackCombinePlanes explanation you may want to look at this: >>> http://www.matroska.org/technical/specs/notes.html#TrackOperation >>> >>> What you had with left, and right separated is now handled that way. >>> These tracks remain but then you have a third virtual track that is >>> the actual 3D version. >> >> As I understand, virtual tracks declared are created in other layer (not as >> track options). > > No, they are declared just like any other track. That's the whole > point, that everything that applies to tracks apply to virtual ones as > well. > >> And virtual tracks aware parser will just ignore this information (and >> stereo video tracks will still be available >> just without any way to distinct them while technically TrackPlaneType >> currently has very simple definition). >> Thats not bad. > > Parsers that don't know about TrackOperation will not be able to play > these tracks. That's one of the reason for the bump to Matroska v3. A > file marked as readable by v3 (and up) compliant readers and can only > handle v2 may decide not to play the file. The left and right tracks > may be marked as NOT Enabled as well (0xB9) and then the player ens up > with just the virtual track that it can't play anyway. > >> Another of my question was: >>> >>> Could you explain me what this combine planes means and how it should be >>> saved using mkvmerge and could/should be used in a player? >> >> I fail to find support for combine planes in current mkv tools (mkvmerge and >> mkvpropedit). >> I should understand - it is in progress? > > Yes > >> To support new behaviour in my program I should change FFmpeg matroska >> parser (and probably define some new definitions in API). >> So, I want to ask - is someone from matroska developers responsible to save >> FFmpeg implementation in sync? >> I'm not yet FFmpeg developer but I'll try to create patch if noone from >> resident developers is interest in it. > > I haven't followed the work on FFmpeg for a while, but no there is no > direct contact to make this happen. Usually people add features in > their programs when they encounter files they can't play. I suppose 3D > is quite new and I don't think FFmpeg has been tweaked yet to handle > all the 3D possibilities. The best way to find out is ask on their > mailing lists or IRC channel. > > Steve > > -- > Steve Lhomme > Matroska association Chairman > -- Steve Lhomme Matroska association Chairman From ssrinivas456 at gmail.com Sun Feb 27 11:54:53 2011 From: ssrinivas456 at gmail.com (Sandiri Srinivas) Date: Sun, 27 Feb 2011 02:54:53 -0800 Subject: [Matroska-devel] Sir I Want to Learn In-Reply-To: References: Message-ID: Sir My Name is Srinivas IAm Very Interested in Making MKV Video Sir i have Small Doubt i have one Video in Avi With Normal Clarity Can I Make in MKV high Clarity Please Send Full Tutorial Video how to create Mkv Video Thanking you Sir Srinivas Waiting for Your Answer Once again Thanking you Sir -------------- next part -------------- An HTML attachment was scrubbed... URL: From cwiesner at matroska.org Sun Feb 27 20:00:03 2011 From: cwiesner at matroska.org (Christian Wiesner) Date: Sun, 27 Feb 2011 20:00:03 +0100 Subject: [Matroska-devel] Sir I Want to Learn In-Reply-To: References: Message-ID: Dear Sir, no, this is unfortunately impossible. matroska is just a container for video and audio streams, the 'clarity' of the video stream will not change if you create a MKV from your AVI. Regards Christian P.S. This question should not have gone to matroska-devel, but to matroska-users 2011/2/27 Sandiri Srinivas > > Sir > > My Name is Srinivas > > IAm Very Interested in Making MKV Video > > Sir i have Small Doubt > > i have one Video in Avi With Normal Clarity Can I Make in MKV high Clarity > > Please Send Full Tutorial Video how to create Mkv Video > > Thanking you Sir > Srinivas > > Waiting for Your Answer > > Once again > Thanking you Sir > > > _______________________________________________ > Matroska-devel mailing list > Matroska-devel at lists.matroska.org > http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel > Read Matroska-Devel on GMane: > http://dir.gmane.org/gmane.comp.multimedia.matroska.devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: