From chris at matroska.org Mon Nov 1 11:32:07 2004 From: chris at matroska.org (Christian HJ Wiesner) Date: Mon, 01 Nov 2004 11:32:07 +0100 Subject: [Matroska-devel] New Build of MPC with internal splitters disabled by default ? Message-ID: <418610A7.4090305@matroska.org> Hi guys, lo Gabest, is it possible to build MPC so that the internal splitters are disabled by default, or only used if no primary DShow parser is found ? We get more and more complaints of MPC users who cant open MKV files using the new INT 64 block duration elements. Toff, could you do that in your spare free time ? Gabest, would you upload this new build on sourceforge then ? Christian From alexander.noe at s2001.tu-chemnitz.de Mon Nov 1 11:35:47 2004 From: alexander.noe at s2001.tu-chemnitz.de (Alexander Noe') Date: Mon, 01 Nov 2004 11:35:47 +0100 Subject: [Matroska-devel] New Build of MPC with internal splitters disabled by default ? In-Reply-To: <418610A7.4090305@matroska.org> References: <418610A7.4090305@matroska.org> Message-ID: <41861183.3090207@hrz.tu-chemnitz.de> Christian HJ Wiesner wrote: > > Hi guys, lo Gabest, > > is it possible to build MPC so that the internal splitters are > disabled by default, or only used if no primary DShow parser is found > ? We get more and more complaints of MPC users who cant open MKV files > using the new INT 64 block duration elements. Then they should fix their files, no? Alex From chris at matroska.org Mon Nov 1 11:38:09 2004 From: chris at matroska.org (Christian HJ Wiesner) Date: Mon, 01 Nov 2004 11:38:09 +0100 Subject: [Matroska-devel] New Build of MPC with internal splitters disabled by default ? In-Reply-To: <41861183.3090207@hrz.tu-chemnitz.de> References: <418610A7.4090305@matroska.org> <41861183.3090207@hrz.tu-chemnitz.de> Message-ID: <41861211.5080404@matroska.org> Alexander Noe' wrote: > Christian HJ Wiesner wrote: > >> >> Hi guys, lo Gabest, >> >> is it possible to build MPC so that the internal splitters are >> disabled by default, or only used if no primary DShow parser is found >> ? We get more and more complaints of MPC users who cant open MKV >> files using the new INT 64 block duration elements. > > > Then they should fix their files, no? > Alex No. These files are 100% perfectly spec compliant, and if MPC 's internal parser cant support them, it has to be updated or disabled. Christian From Liisachan at faireal.net Mon Nov 1 12:04:03 2004 From: Liisachan at faireal.net (Liisachan) Date: Mon, 01 Nov 2004 20:04:03 +0900 Subject: [Matroska-devel] New Build of MPC with internal splitters disabledby default ? In-Reply-To: <41861211.5080404@matroska.org> References: <41861183.3090207@hrz.tu-chemnitz.de> <41861211.5080404@matroska.org> Message-ID: <20041101200403KtC?2e@faireal.net> Hi, Did you check MPC 6.4.8.3 cvs versions that can correctly open newer MKV muxed by mkvmerge 0.9.5+? http://forum.doom9.org/showthread.php?s=&threadid=29798&perpage=20&pagenumber=94 MPC that can play newer MKV by itself is a lot better than using old MPC with disabled old internal filter. BTW, altho I know I'm talking about what I shouldnt do, if you really wanted to do so, the Matroska Pack (installer) could disable MPC's internal MatroskaSplitter forcefully in this hackish way: LPCTSTR lpszKeyMPCSettings = "Software\\Gabest\\Media PlayerClassic\\Settings"; LPCTSTR lpszValueName = "SrcFilters"; HKEY hKeyMPCSettings = NULL; RegOpenKeyEx( HKEY_CURRENT_USER, lpszKeyMPCSettings, 0, KEY_ALL_ACCESS, &hKeyMPCSettings ); RegQueryValueEx( hKeyMPCSettings, lpszValueName, NULL, &dwType, bytes, &dwBytes ); // Read the Current Settings for SrcFIlters dwCurrentData = MAKEWPARAM( MAKEWORD( bytes[ 0 ], bytes[ 1 ] ), MAKEWORD( bytes[ 2 ], bytes[ 3 ] ) ); // Alter the data to disable MatroskaSplitter dwNewData = ( dwCurrentData & 0xFFFFFFBF ); bytes[ 0 ] = LOBYTE( LOWORD( dwNewData ) ); bytes[ 1 ] = HIBYTE( LOWORD( dwNewData ) ); bytes[ 2 ] = LOBYTE( HIWORD( dwNewData ) ); bytes[ 3 ] = HIBYTE( HIWORD( dwNewData ) ); // Write that hacked data without asking the user :P RegSetValueEx( hKeyMPCSettings, lpszValueName, 0, REG_DWORD, bytes, 4 ); RegCloseKey( hKeyMPCSettings ); I know this is noobish, bad, too violent way to do things, so please dont get angry...^^; Liisachan Christian HJ Wiesner wrote: > Alexander Noe' wrote: > > > Christian HJ Wiesner wrote: > > > >> > >> Hi guys, lo Gabest, > >> > >> is it possible to build MPC so that the internal splitters are > >> disabled by default, or only used if no primary DShow parser is found > >> ? We get more and more complaints of MPC users who cant open MKV > >> files using the new INT 64 block duration elements. > > > > > > Then they should fix their files, no? > > Alex > > No. These files are 100% perfectly spec compliant, and if MPC 's > internal parser cant support them, it has to be updated or disabled. > > Christian > _______________________________________________ > Matroska-devel mailing list > Matroska-devel at lists.matroska.org > http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel From slogmeister at earthlink.net Mon Nov 8 01:33:45 2004 From: slogmeister at earthlink.net (Slogmeister Extraordinaire) Date: Sun, 07 Nov 2004 18:33:45 -0600 Subject: [Matroska-devel] About your 0.93 installer Message-ID: <6.1.2.0.0.20041107183142.019ee170@pop.earthlink.net> I recently downloaded a movie that uses your codec. While the codec seems to work well, your installer took the liberty of re-arranging all the icons on my desktop. It was highly annoying. Just thought you'd like to know. Keep up the good work! - Jason Eberhardt From Liisachan at faireal.net Mon Nov 8 11:32:29 2004 From: Liisachan at faireal.net (Liisachan) Date: Mon, 08 Nov 2004 19:32:29 +0900 Subject: [Matroska-devel] About your 0.93 installer In-Reply-To: <6.1.2.0.0.20041107183142.019ee170@pop.earthlink.net> References: <6.1.2.0.0.20041107183142.019ee170@pop.earthlink.net> Message-ID: <20041108193229t9=SBZ@faireal.net> Hi, what you are talking about is *not* the official installers released by Matroska.org, so i'm afraid the dev ppl here in this list can do little about it. Please get the official, authentic versions here: http://packs.matroska.org/ I am the author of that unofficial installer (aka Lazy Man's MKV), and I am sorry for you, but I am not a dev, just a user like you. Don't blame matroska ppl for this, plz. Did you read the webpage before installing? http://hp.vector.co.jp/authors/VA022257/matroska/ It says: - The current version of this installer is mkvinst_b93.exe - The previous version (stable) is mkvinst_b92.exe You might want to choose the stable version next time. Fyi, that newest version works a bit aggressively for several reasons, partly related to the problem in MatroskaProp: http://forum.doom9.org/showthread.php?s=&postid=561001 it's not so unusual that the feature you hate is actually what the other ppl really need. Liisachan Slogmeister Extraordinaire wrote: > I recently downloaded a movie that uses your codec. While the codec seems > to work well, your installer took the liberty of re-arranging all the icons > on my desktop. It was highly annoying. > > Just thought you'd like to know. Keep up the good work! > > - Jason Eberhardt > > > _______________________________________________ > Matroska-devel mailing list > Matroska-devel at lists.matroska.org > http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel From lenior at quicknet.nl Mon Nov 8 15:47:21 2004 From: lenior at quicknet.nl (Laurens) Date: Mon, 8 Nov 2004 15:47:21 +0100 Subject: [Matroska-devel] Translation Message-ID: <001f01c4c5a1$dc142210$0300a8c0@LAURENS> Hi, My name is Laurens Lenior. In the past I made Dutch translations for several programs/sites/forums (like eDonkey, WowBB, Shareaza a.o.). I was wondering if you need any Dutch translations for the Matroska website and/or software? Regards, Laurens Lenior From moritz at bunkus.org Mon Nov 8 16:40:18 2004 From: moritz at bunkus.org (Moritz Bunkus) Date: Mon, 8 Nov 2004 16:40:18 +0100 Subject: [Matroska-devel] adding a 'forced display' flag? Message-ID: <20041108154018.GW5928@bunkus.org> Hey, after the confusion lately about the 'default track' flag I thought I'd post this on the ML. The situation: We have a 'default track' flag that says that this track is the default track for its kind. The usage of this flag from the POV of a player is: 1. Has the user selected a specific track for this kind? If yes, then use that track. If not, goto 2. 2. Has the user chosen to view such tracks in general? If not, don't display a track of this kind (!). 3. Does one of the tracks of this kind have its default flag set? If yes display this track, don't display such a track otherwise. Remember that the default value for the 'default track' flag is '1'. So if it's not written in the file then it is implicitely set to '1'. The problem was that TCMP interpreted the presence of the 'default track' flag with a value of '1' as 'always show such a track' which is not what this flag was inteded for. Therefore we need a new flag, let's call it 'force display' for the time being. It's default value should be '0' obviously. One problem I see with it, however, is that it totally smashes 'default track' if it is set. Meaning that 'default track' simply has no meaning whatsoever if 'force display' is set to '1'. So maybe another option would be adding another value to 'default track': '0': nope, it isn't the default track, '1': yes, it is the default track, but only display it if the user wants tracks of this kind, '2': yes, definitely display it. Please also note that I personally don't like players forcing me to view stuff I haven't selected. I'm always in favour of a player giving the user the choice whether he wants to see something or not. This will weaken such a flag/option. Opinions? Mosu -- If Darl McBride was in charge, he'd probably make marriage unconstitutional too, since clearly it de-emphasizes the commercial nature of normal human interaction, and probably is a major impediment to the commercial growth of prostitution. - Linus Torvalds From steve.lhomme at free.fr Wed Nov 10 11:28:18 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Wed, 10 Nov 2004 11:28:18 +0100 Subject: [Matroska-devel] Translation In-Reply-To: <001f01c4c5a1$dc142210$0300a8c0@LAURENS> References: <001f01c4c5a1$dc142210$0300a8c0@LAURENS> Message-ID: <4191ED42.6050905@free.fr> Laurens a ?crit : > Hi, > > My name is Laurens Lenior. In the past I made Dutch translations for > several programs/sites/forums (like eDonkey, WowBB, Shareaza a.o.). I > was wondering if you need any Dutch translations for the Matroska > website and/or software? As long as it's free, yes :) If you can write clean XHTML we can give you an account on our webserver so that you update the pages you want (the most important ones are the homepage and the pack page). Otherwise just send me the translations and I'll add them to the site. cya PS: you can reach us with IRC too if you want to discuss details faster. From steve.lhomme at free.fr Wed Nov 10 12:26:43 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Wed, 10 Nov 2004 12:26:43 +0100 Subject: [Matroska-devel] Translation In-Reply-To: <000601c4c717$1fb18780$0300a8c0@LAURENS> References: <001f01c4c5a1$dc142210$0300a8c0@LAURENS> <4191ED42.6050905@free.fr> <000601c4c717$1fb18780$0300a8c0@LAURENS> Message-ID: <4191FAF3.4080005@free.fr> Laurens a ?crit : > Of course it's free :) > I'm also a professional webdesigner, so updating the HTML files will be > no problem for me. If you give me a webserver account I will see what I > can do. > > Cya. The account is not FTP but using Subversion (something similar to CVS). You can use TortoiseSVN to access it. Also I insist on maintaining the HTML code layout (not that it just looks similar in the browser). It will help us track changes and update it if needed. And ensure that all pages in all languages are rendered the same. You can access all our websites from (the URL you need inside TortoiseSVN) : https://svn.matroska.org/svn/www/trunk/matroska/ or bigger : https://svn.matroska.org/svn/www/trunk/ From steve.lhomme at free.fr Wed Nov 10 18:23:51 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Wed, 10 Nov 2004 18:23:51 +0100 Subject: [Matroska-devel] Credits Message-ID: <41924EA7.5060609@free.fr> BTW, I'm going to add you to the credits page. What name should I use there ? If you want to activate your pages (the flag) you need to add : (instead of "eng" in the original english pages) You also have to add to all similar pages in other languages : (including yours) -- robUx4 on blog From moritz at bunkus.org Thu Nov 11 12:22:41 2004 From: moritz at bunkus.org (Moritz Bunkus) Date: Thu, 11 Nov 2004 12:22:41 +0100 Subject: [Matroska-devel] Translation In-Reply-To: <001f01c4c5a1$dc142210$0300a8c0@LAURENS> References: <001f01c4c5a1$dc142210$0300a8c0@LAURENS> Message-ID: <20041111112241.GS5928@bunkus.org> Hey, I just wanted to say 'thanks' for the help :) Mosu -- If Darl McBride was in charge, he'd probably make marriage unconstitutional too, since clearly it de-emphasizes the commercial nature of normal human interaction, and probably is a major impediment to the commercial growth of prostitution. - Linus Torvalds From steve.lhomme at free.fr Mon Nov 15 10:20:23 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Mon, 15 Nov 2004 10:20:23 +0100 Subject: [Matroska-devel] adding a 'forced display' flag? In-Reply-To: <20041108154018.GW5928@bunkus.org> References: <20041108154018.GW5928@bunkus.org> Message-ID: <419874D7.1060505@free.fr> Moritz Bunkus a ?crit : > Hey, > > after the confusion lately about the 'default track' flag I thought I'd > post this on the ML. > > The situation: We have a 'default track' flag that says that this track > is the default track for its kind. The usage of this flag from the POV > of a player is: > > 1. Has the user selected a specific track for this kind? If yes, then > use that track. If not, goto 2. > 2. Has the user chosen to view such tracks in general? If not, don't > display a track of this kind (!). > 3. Does one of the tracks of this kind have its default flag set? If yes > display this track, don't display such a track otherwise. > > Remember that the default value for the 'default track' flag is '1'. So > if it's not written in the file then it is implicitely set to '1'. > > The problem was that TCMP interpreted the presence of the 'default > track' flag with a value of '1' as 'always show such a track' which is > not what this flag was inteded for. > > Therefore we need a new flag, let's call it 'force display' for the > time being. It's default value should be '0' obviously. One problem I > see with it, however, is that it totally smashes 'default track' if it > is set. Meaning that 'default track' simply has no meaning whatsoever if > 'force display' is set to '1'. So maybe another option would be adding > another value to 'default track': > '0': nope, it isn't the default track, > '1': yes, it is the default track, but only display it if the user wants > tracks of this kind, > '2': yes, definitely display it. > > Please also note that I personally don't like players forcing me to view > stuff I haven't selected. I'm always in favour of a player giving the > user the choice whether he wants to see something or not. This will > weaken such a flag/option. > > Opinions? Sorry for the lag. I'm just recovering from vacation time. :) Well. The force feature should be like in DVDs for subtitles. You have no option to disable some kind of subs. But for subs it makes sense to have it in different languages (ie unlike what is done on DVD). So IMO many tracks could have the forced flag, depending on what language the user prefers (falling back to the "default track" if none is found). So my preference goes to a separate flag. From steve.lhomme at free.fr Mon Nov 15 15:47:18 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Mon, 15 Nov 2004 15:47:18 +0100 Subject: [Matroska-devel] Re: DirectShow conversion to Gstreamer In-Reply-To: References: <41891AE2.3040006@matroska.org> Message-ID: <4198C176.8000005@free.fr> Check the archives of the (also dead) media-api project. Arioch /BDV/ a ?crit : > The stars so gaily glistened... (Wed, 03 Nov 2004 18:52:34 +0100 @786) > ...while the fading voice of Christian whispered through the darkness: > > CHW> that requires an open-standard codec > CHW> API based on a powerful framework. > > So, Universal Codec Interface initiative is dead now ? > I wonder, what are GStreamer API and UCI if to compare their technical > design, was there any loose? -- robUx4 on blog From moritz at bunkus.org Tue Nov 16 13:00:51 2004 From: moritz at bunkus.org (Moritz Bunkus) Date: Tue, 16 Nov 2004 13:00:51 +0100 Subject: [Matroska-devel] adding a 'forced display' flag? In-Reply-To: <419874D7.1060505@free.fr> References: <20041108154018.GW5928@bunkus.org> <419874D7.1060505@free.fr> Message-ID: <20041116120051.GJ5928@bunkus.org> Hey, > Well. The force feature should be like in DVDs for subtitles. You have > no option to disable some kind of subs. Hmm, if I'm not mistaken then this is a feature of the "menu" system etc, not a track feature, or am I wrong? Anyway, I don't like that (personally I don't like the whole "forced display" issue at all). This would require players to be able to play two subtitle tracks at the same time. Otherwise the user wouldn't be able to switch subtitle tracks at all, and that would be VERY bad. mplayer and xine can only display one, and I'm not sure about vlc and gstreamer based ones, but I rather doubt vlc can display more than one. Ok, this is a technical issue, but I still think that forcing the user to watch something in a pre-set way is bad. Users like to have a choice. So what I'm ok with would be that having a "weak forced" flag. "Weak" because it does allow the selection of other tracks instead of the "weak forced" one, but if no other is selected, then this one will be shown. Another thing is that "forced" can not be "enforced" by us. Unlike the DVD forum we don't hand out "Matroska compatible" stickers and signs, so we cannot really control how players are implemented -- only ask the authors that they implement it the way we want it. > But for subs it makes sense to have it in different languages (ie > unlike what is done on DVD). So IMO many tracks could have the forced > flag, depending on what language the user prefers (falling back to the > "default track" if none is found). some pseudo code: sub_track = NULL if (user_wants_subtitles_in_a_specific_langauge) { sub_track = find_first_sub_track(language == wanted_sub_language && forced_flag == true) } if (sub_track == NULL) { sub_track = find_first_sub_track(forced_flag == true) } if ((sub_track == NULL) and user_wants_subtitles_in_a_specific_language) { sub_track = find_first_sub_track(langauge == wanted_sub_language) } if ((sub_track == NULL) and user_wants_subtitles) { sub_track = find_first_sub_track(default_flag == true) } Something like this? Awfully involved, hard to explain to the ones creating Matroska files. All in all I'm against adding a "forced display" flag. So you others -- what is your opinion? Even a short "I'm for it" or "I'm against it" would be nice, but if only Steve and I decide about spec changes then I wouldn't be comfortable with it. Mosu -- If Darl McBride was in charge, he'd probably make marriage unconstitutional too, since clearly it de-emphasizes the commercial nature of normal human interaction, and probably is a major impediment to the commercial growth of prostitution. - Linus Torvalds From alexander.noe at s2001.tu-chemnitz.de Tue Nov 16 13:09:04 2004 From: alexander.noe at s2001.tu-chemnitz.de (Alexander Noe') Date: Tue, 16 Nov 2004 13:09:04 +0100 Subject: [Matroska-devel] adding a 'forced display' flag? In-Reply-To: <419874D7.1060505@free.fr> References: <20041108154018.GW5928@bunkus.org> <419874D7.1060505@free.fr> Message-ID: <4199EDE0.5010401@hrz.tu-chemnitz.de> Steve Lhomme wrote: > > Well. The force feature should be like in DVDs for subtitles. You have > no option to disable some kind of subs. Why exactly do you want to add a possibility to make broken and useless files? Alex From moritz at bunkus.org Tue Nov 16 13:10:14 2004 From: moritz at bunkus.org (Moritz Bunkus) Date: Tue, 16 Nov 2004 13:10:14 +0100 Subject: [Matroska-devel] CodecPrivate for MPEG-1 and MPEG-2 video Message-ID: <20041116121014.GK5928@bunkus.org> Hey, Let's talk about V_MPEG1 and V_MPEG2 :) Our specs page says: The matroska video stream will contain a demuxed Elementary Stream (ES), where block boundaries are still to be defined. Its recommended to use MPEG2MKV.exe for creating those files, and to compare the results with selfmade implementations Spyder has told me he puts a sequence header into the CodecPrivate. The sequence header contains information like width, height, FPS and pixel aspect ratio among other things. While some of these fields are present in the Matroska track headers others are not (like the picture coding extension). So we cannot simply drop it. Personally I'm voting for not putting anything into the the CodecPrivate. At least not as mandatory information. The muxing app MAY put a sequence header there, e.g. if the MPEG ES doesn't start with one (every MPEG decoder needs a sequence header before it can decode the data). Spyder? Any preference, additional thoughts? Mosu -- If Darl McBride was in charge, he'd probably make marriage unconstitutional too, since clearly it de-emphasizes the commercial nature of normal human interaction, and probably is a major impediment to the commercial growth of prostitution. - Linus Torvalds From steve.lhomme at free.fr Tue Nov 16 15:05:45 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Tue, 16 Nov 2004 15:05:45 +0100 Subject: [Matroska-devel] adding a 'forced display' flag? In-Reply-To: <4199EDE0.5010401@hrz.tu-chemnitz.de> References: <20041108154018.GW5928@bunkus.org> <419874D7.1060505@free.fr> <4199EDE0.5010401@hrz.tu-chemnitz.de> Message-ID: <419A0939.5030201@free.fr> Alexander Noe' a ?crit : > Steve Lhomme wrote: > >> >> Well. The force feature should be like in DVDs for subtitles. You have >> no option to disable some kind of subs. > > > Why exactly do you want to add a possibility to make broken and useless > files? Because, as you know, I'm working on the DVD compatibility. And the forced flag is not only used to annoy the user. As we already discussed it can be used when someone in a movie speaks in a foreign language (like klingon) and the text is translated, regardless of the subtitle configuration. In such a configuration, the forced sub, wouldn't overlap with normal subs. The other case is when a logo is displayed all the video long. Then both subs can be displayed at the same time. And DVDs support that. So the question is not why support it, but why *not* support it ? (lazyness and lack of support are IMO not arguments, just problems) From chris at matroska.org Tue Nov 16 15:37:18 2004 From: chris at matroska.org (Christian HJ Wiesner) Date: Tue, 16 Nov 2004 15:37:18 +0100 Subject: [Matroska-devel] adding a 'forced display' flag? In-Reply-To: <4199EDE0.5010401@hrz.tu-chemnitz.de> References: <20041108154018.GW5928@bunkus.org> <419874D7.1060505@free.fr> <4199EDE0.5010401@hrz.tu-chemnitz.de> Message-ID: <419A109E.5060403@matroska.org> Alexander Noe' schrieb: > Steve Lhomme wrote: > >> Well. The force feature should be like in DVDs for subtitles. You >> have no option to disable some kind of subs. > > > Why exactly do you want to add a possibility to make broken and > useless files? > Alex So you believe DVDs with forced subs are all broken ? Jesus Alex, Steve was making a valid proposal. Do you really think it is helpful to insult him to find out what the best option is ? After all, we are trying hard to find a way for offering the same menue functionalities than DVDs, but in a single file. As a result of that, we should make up our mind how to treat forced subs, dont you agree ? In the end, the player dev can always decide to override that if he doesnt like it. Christian From steve.lhomme at free.fr Tue Nov 16 15:35:44 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Tue, 16 Nov 2004 15:35:44 +0100 Subject: [Matroska-devel] CodecPrivate for MPEG-1 and MPEG-2 video In-Reply-To: <20041116121014.GK5928@bunkus.org> References: <20041116121014.GK5928@bunkus.org> Message-ID: <419A1040.4090006@free.fr> Moritz Bunkus a ?crit : > Hey, > > Let's talk about V_MPEG1 and V_MPEG2 :) Our specs page says: > > The matroska video stream will contain a demuxed Elementary Stream > (ES), where block boundaries are still to be defined. Its recommended > to use MPEG2MKV.exe for creating those files, and to compare the > results with selfmade implementations > > Spyder has told me he puts a sequence header into the CodecPrivate. The > sequence header contains information like width, height, FPS and pixel > aspect ratio among other things. While some of these fields are present > in the Matroska track headers others are not (like the picture coding > extension). So we cannot simply drop it. > > Personally I'm voting for not putting anything into the the > CodecPrivate. At least not as mandatory information. The muxing app > MAY put a sequence header there, e.g. if the MPEG ES doesn't start with > one (every MPEG decoder needs a sequence header before it can decode the > data). > > Spyder? Any preference, additional thoughts? Well, that's quite a change. Because so far we always assume the CodecPrivate is filled for each CodecID. Having an optional CodecPrivate wasn't discussed so far (?). IMO eitherr we have it, or not. But in between is only hacky for no good reason. It's up to spyder to tell if we need the missing data or not. From alexander.noe at s2001.tu-chemnitz.de Tue Nov 16 15:45:14 2004 From: alexander.noe at s2001.tu-chemnitz.de (Alexander Noe') Date: Tue, 16 Nov 2004 15:45:14 +0100 Subject: [Matroska-devel] adding a 'forced display' flag? In-Reply-To: <419A109E.5060403@matroska.org> References: <20041108154018.GW5928@bunkus.org> <419874D7.1060505@free.fr> <4199EDE0.5010401@hrz.tu-chemnitz.de> <419A109E.5060403@matroska.org> Message-ID: <419A127A.5030902@hrz.tu-chemnitz.de> Christian HJ Wiesner wrote: >> >> Why exactly do you want to add a possibility to make broken and >> useless files? >> Alex > > > So you believe DVDs with forced subs are all broken ? Some are. Basicly, all DVDs only containing natural languages in combination with forced subs are. > Jesus Alex, Steve was making a valid proposal. Jesus yourself > Do you really think it is helpful to insult him to find out what the > best option is? Wessie! > After all, we are trying hard to find a way for offering the same > menue functionalities than DVDs, but in a single file. As a result of > that, we should make up our mind how to treat forced subs, dont you > agree ? Yeah, how to treat them, not how to annoy the user with them. > In the end, the player dev can always decide to override that if he > doesnt like it. Ah, so you DO agree with me, but you just wanted to say sth.... You should really read the last messages again: How shall a player override it if it can't be overridden?? Alex From alexander.noe at s2001.tu-chemnitz.de Tue Nov 16 15:49:07 2004 From: alexander.noe at s2001.tu-chemnitz.de (Alexander Noe') Date: Tue, 16 Nov 2004 15:49:07 +0100 Subject: [Matroska-devel] adding a 'forced display' flag? In-Reply-To: <419A0939.5030201@free.fr> References: <20041108154018.GW5928@bunkus.org> <419874D7.1060505@free.fr> <4199EDE0.5010401@hrz.tu-chemnitz.de> <419A0939.5030201@free.fr> Message-ID: <419A1363.6060300@hrz.tu-chemnitz.de> Steve Lhomme wrote: > Alexander Noe' a ?crit : > >> Steve Lhomme wrote: >> >>> >>> Well. The force feature should be like in DVDs for subtitles. You >>> have no option to disable some kind of subs. >> >> >> >> Why exactly do you want to add a possibility to make broken and >> useless files? > > > Because, as you know, I'm working on the DVD compatibility. But you are welcome to drop the crappy parts. > And the forced flag is not only used to annoy the user. But it is close to that. > As we already discussed it can be used when someone in a movie speaks > in a foreign language (like klingon) and the text is translated, > regardless of the subtitle configuration. In such a configuration, the > forced sub, wouldn't overlap with normal subs. Too bad that this is not only done with klingon, vulcan, romulan etc... Just get a german Cruel Intensions DVD and you'll see what I mean. > The other case is when a logo is displayed all the video long. Then > both subs can be displayed at the same time. And DVDs support that. So > the question is not why support it, but why *not* support it ? > (lazyness and lack of support are IMO not arguments, just problems) If you want something like subs that are on by default (e.g. using the default flag), then tell Gabest to use the default flag... mkvmerge and avi-mux gui have been able to set it for a long time already. Alex From steve.lhomme at free.fr Tue Nov 16 15:49:37 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Tue, 16 Nov 2004 15:49:37 +0100 Subject: [Matroska-devel] adding a 'forced display' flag? In-Reply-To: <419A127A.5030902@hrz.tu-chemnitz.de> References: <20041108154018.GW5928@bunkus.org> <419874D7.1060505@free.fr> <4199EDE0.5010401@hrz.tu-chemnitz.de> <419A109E.5060403@matroska.org> <419A127A.5030902@hrz.tu-chemnitz.de> Message-ID: <419A1381.7080902@free.fr> Alexander Noe' a ?crit : > You should really read the last messages again: How shall a player override > it if it can't be overridden?? That's a moo point :D In other words, it doesn't matter if some apps don't treat forced flags, as well as languages for tracks, etc. That doesn't mean the feature should no existed and be supported by some apps, if they want to. From moritz at bunkus.org Tue Nov 16 15:54:20 2004 From: moritz at bunkus.org (Moritz Bunkus) Date: Tue, 16 Nov 2004 15:54:20 +0100 Subject: [Matroska-devel] adding a 'forced display' flag? In-Reply-To: <419A0939.5030201@free.fr> References: <20041108154018.GW5928@bunkus.org> <419874D7.1060505@free.fr> <4199EDE0.5010401@hrz.tu-chemnitz.de> <419A0939.5030201@free.fr> Message-ID: <20041116145420.GD17956@bunkus.org> Hey, > Because, as you know, I'm working on the DVD compatibility. And the > forced flag is not only used to annoy the user. True, but it may very well be abused. Like DVD has asked last week -- he wants to use it often, it seems. The "problem" is that we cannot call a player "Matroska compatible" if it allows to switch off such forced subs. Anyway, for full DVD support we definitely need it, so we should include it. But again, then we should not INSIST on the player authors making it 'un-switch-offable' (yeah I know, my English is bad today). > So the question is not why support it, but why *not* support it ? Abuse, but I'm ok with it if we "allow" player authors to let their users turn them off. Maybe mit a warning about "not being able to fully enjoy the greatness of this movie" or sth like that. > (lazyness and lack of support are IMO not arguments, just problems) True. Mosu -- ==> Ciao, Mosu (Moritz Bunkus) From moritz at bunkus.org Tue Nov 16 15:54:29 2004 From: moritz at bunkus.org (Moritz Bunkus) Date: Tue, 16 Nov 2004 15:54:29 +0100 Subject: [Matroska-devel] adding a 'forced display' flag? In-Reply-To: <419A1363.6060300@hrz.tu-chemnitz.de> References: <20041108154018.GW5928@bunkus.org> <419874D7.1060505@free.fr> <4199EDE0.5010401@hrz.tu-chemnitz.de> <419A0939.5030201@free.fr> <419A1363.6060300@hrz.tu-chemnitz.de> Message-ID: <20041116145429.GE17956@bunkus.org> Hey, > If you want something like subs that are on by default (e.g. using the > default flag), No, that's NOT what the default flag is for. It does NOT tell the player to turn on the subs by default! It only tells it that IF the user wants subs that this track should be used by default unless the user says otherwise. Mosu -- ==> Ciao, Mosu (Moritz Bunkus) From alexander.noe at s2001.tu-chemnitz.de Tue Nov 16 15:59:59 2004 From: alexander.noe at s2001.tu-chemnitz.de (Alexander Noe') Date: Tue, 16 Nov 2004 15:59:59 +0100 Subject: [Matroska-devel] adding a 'forced display' flag? In-Reply-To: <20041116145429.GE17956@bunkus.org> References: <20041108154018.GW5928@bunkus.org> <419874D7.1060505@free.fr> <4199EDE0.5010401@hrz.tu-chemnitz.de> <419A0939.5030201@free.fr> <419A1363.6060300@hrz.tu-chemnitz.de> <20041116145429.GE17956@bunkus.org> Message-ID: <419A15EF.3060700@hrz.tu-chemnitz.de> Moritz Bunkus wrote: >Hey, > > > >>If you want something like subs that are on by default (e.g. using the >>default flag), >> >> > >No, that's NOT what the default flag is for. It does NOT tell the player >to turn on the subs by default! It only tells it that IF the user wants >subs that this track should be used by default unless the user says >otherwise. > > I meant that 2 subtitle tracks should be made from one that contains forced subs. Then, one of the "forced" ones can be marked as default, and the user can select between e.g. "german - normal", "german - forced only", "english - normal", "english - forced only" etc or "none". Alex From steve.lhomme at free.fr Tue Nov 16 16:13:48 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Tue, 16 Nov 2004 16:13:48 +0100 Subject: [Matroska-devel] adding a 'forced display' flag? In-Reply-To: <419A1363.6060300@hrz.tu-chemnitz.de> References: <20041108154018.GW5928@bunkus.org> <419874D7.1060505@free.fr> <4199EDE0.5010401@hrz.tu-chemnitz.de> <419A0939.5030201@free.fr> <419A1363.6060300@hrz.tu-chemnitz.de> Message-ID: <419A192C.6080107@free.fr> Alexander Noe' a ?crit : >> As we already discussed it can be used when someone in a movie speaks >> in a foreign language (like klingon) and the text is translated, >> regardless of the subtitle configuration. In such a configuration, the >> forced sub, wouldn't overlap with normal subs. > > > Too bad that this is not only done with klingon, vulcan, romulan etc... > Just get a german Cruel Intensions DVD and you'll see what I mean. Can you explain what that DVD has ? From alexander.noe at s2001.tu-chemnitz.de Tue Nov 16 16:19:40 2004 From: alexander.noe at s2001.tu-chemnitz.de (Alexander Noe') Date: Tue, 16 Nov 2004 16:19:40 +0100 Subject: [Matroska-devel] adding a 'forced display' flag? In-Reply-To: <419A192C.6080107@free.fr> References: <20041108154018.GW5928@bunkus.org> <419874D7.1060505@free.fr> <4199EDE0.5010401@hrz.tu-chemnitz.de> <419A0939.5030201@free.fr> <419A1363.6060300@hrz.tu-chemnitz.de> <419A192C.6080107@free.fr> Message-ID: <419A1A8C.7010308@hrz.tu-chemnitz.de> Steve Lhomme wrote: > Alexander Noe' a ?crit : > >>> As we already discussed it can be used when someone in a movie >>> speaks in a foreign language (like klingon) and the text is >>> translated, regardless of the subtitle configuration. In such a >>> configuration, the forced sub, wouldn't overlap with normal subs. >> >> >> >> Too bad that this is not only done with klingon, vulcan, romulan etc... >> Just get a german Cruel Intensions DVD and you'll see what I mean. > > > Can you explain what that DVD has ? Due to copyright reasons (!), the complete german subtitle is forced if the audio is set to english. Alex From steve.lhomme at free.fr Tue Nov 16 16:18:58 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Tue, 16 Nov 2004 16:18:58 +0100 Subject: [Matroska-devel] adding a 'forced display' flag? In-Reply-To: <20041116145420.GD17956@bunkus.org> References: <20041108154018.GW5928@bunkus.org> <419874D7.1060505@free.fr> <4199EDE0.5010401@hrz.tu-chemnitz.de> <419A0939.5030201@free.fr> <20041116145420.GD17956@bunkus.org> Message-ID: <419A1A62.4090208@free.fr> Moritz Bunkus a ?crit : > Anyway, for full DVD support we definitely need it, so we should include > it. > > But again, then we should not INSIST on the player authors making it > 'un-switch-offable' (yeah I know, my English is bad today). As a user, I would probably want them always turned off ! But an "author" would probably like the default behaviour of some nice players that keep it on. And I respect authors :D From steve.lhomme at free.fr Tue Nov 16 16:25:51 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Tue, 16 Nov 2004 16:25:51 +0100 Subject: [Matroska-devel] adding a 'forced display' flag? In-Reply-To: <419A1A8C.7010308@hrz.tu-chemnitz.de> References: <20041108154018.GW5928@bunkus.org> <419874D7.1060505@free.fr> <4199EDE0.5010401@hrz.tu-chemnitz.de> <419A0939.5030201@free.fr> <419A1363.6060300@hrz.tu-chemnitz.de> <419A192C.6080107@free.fr> <419A1A8C.7010308@hrz.tu-chemnitz.de> Message-ID: <419A1BFF.6000006@free.fr> Alexander Noe' a ?crit : > Steve Lhomme wrote: > >> Alexander Noe' a ?crit : >> >>>> As we already discussed it can be used when someone in a movie >>>> speaks in a foreign language (like klingon) and the text is >>>> translated, regardless of the subtitle configuration. In such a >>>> configuration, the forced sub, wouldn't overlap with normal subs. >>> >>> >>> >>> >>> Too bad that this is not only done with klingon, vulcan, romulan etc... >>> Just get a german Cruel Intensions DVD and you'll see what I mean. >> >> >> >> Can you explain what that DVD has ? > > > Due to copyright reasons (!), the complete german subtitle is forced > if the audio is set to english. That falls in the category "respect the author". But as we like freedom, we won't enforce respect, just suggest it :D From steve.lhomme at free.fr Tue Nov 16 16:32:33 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Tue, 16 Nov 2004 16:32:33 +0100 Subject: [Matroska-devel] adding a 'forced display' flag? In-Reply-To: <419A15EF.3060700@hrz.tu-chemnitz.de> References: <20041108154018.GW5928@bunkus.org> <419874D7.1060505@free.fr> <4199EDE0.5010401@hrz.tu-chemnitz.de> <419A0939.5030201@free.fr> <419A1363.6060300@hrz.tu-chemnitz.de> <20041116145429.GE17956@bunkus.org> <419A15EF.3060700@hrz.tu-chemnitz.de> Message-ID: <419A1D91.4030701@free.fr> Alexander Noe' a ?crit : > Moritz Bunkus wrote: > >> Hey, >> >> >> >>> If you want something like subs that are on by default (e.g. using >>> the default flag), >>> >> >> >> No, that's NOT what the default flag is for. It does NOT tell the player >> to turn on the subs by default! It only tells it that IF the user wants >> subs that this track should be used by default unless the user says >> otherwise. >> >> > I meant that 2 subtitle tracks should be made from one that contains > forced subs. Then, one of the "forced" ones can be marked as default, > and the user can select between e.g. "german - normal", "german - > forced only", > "english - normal", "english - forced only" etc or "none". But you forget that the default flag applies to all kinds of track, not just subs. The default flag is to tell "if you don't know what track to use in the list, use this one". It doesn't say anything else. The forced flag would say "regardless of the playback option, this track has to be used". At least that how it works on DVDs. But I would prefer it a nicer way, ie having multiple forced track, one for each language supported and a default one if the language is not found. From mike at po.cs.msu.su Tue Nov 16 16:13:28 2004 From: mike at po.cs.msu.su (Mike Matsnev) Date: Tue, 16 Nov 2004 18:13:28 +0300 Subject: [Matroska-devel] CodecPrivate for MPEG-1 and MPEG-2 video In-Reply-To: <419A1040.4090006@free.fr> References: <20041116121014.GK5928@bunkus.org> <419A1040.4090006@free.fr> Message-ID: <419A1918.8080705@po.cs.msu.su> Steve Lhomme wrote: >> Personally I'm voting for not putting anything into the the >> CodecPrivate. At least not as mandatory information. The muxing app >> MAY put a sequence header there, e.g. if the MPEG ES doesn't start with >> one (every MPEG decoder needs a sequence header before it can decode the >> data). >> >> Spyder? Any preference, additional thoughts? > > > Well, that's quite a change. Because so far we always assume the > CodecPrivate is filled for each CodecID. Having an optional CodecPrivate > wasn't discussed so far (?). IMO eitherr we have it, or not. But in > between is only hacky for no good reason. It's up to spyder to tell if > we need the missing data or not. Some codecs do not use CodecPrivate, it's already optional. I accidentally replied privately to Mosu, but windows mpeg1/2 decoders require the sequence header in the media type's format block, and I don't really want to write code to reconstruct the seq. header from other header values, or read the first frame to extract it from there. /Mike From alexander.noe at s2001.tu-chemnitz.de Tue Nov 16 16:46:07 2004 From: alexander.noe at s2001.tu-chemnitz.de (Alexander Noe') Date: Tue, 16 Nov 2004 16:46:07 +0100 Subject: [Matroska-devel] adding a 'forced display' flag? In-Reply-To: <419A1D91.4030701@free.fr> References: <20041108154018.GW5928@bunkus.org> <419874D7.1060505@free.fr> <4199EDE0.5010401@hrz.tu-chemnitz.de> <419A0939.5030201@free.fr> <419A1363.6060300@hrz.tu-chemnitz.de> <20041116145429.GE17956@bunkus.org> <419A15EF.3060700@hrz.tu-chemnitz.de> <419A1D91.4030701@free.fr> Message-ID: <419A20BF.20802@hrz.tu-chemnitz.de> Steve Lhomme wrote: > > But you forget that the default flag applies to all kinds of track, > not just subs. The default flag is to tell "if you don't know what > track to use in the list, use this one". It doesn't say anything else. I don't... > > The forced flag would say "regardless of the playback option, this > track has to be used". That's exactly what I consider inacceptable. > At least that how it works on DVDs. I know, and that's why I wouldn't buy that cruel intentions DVD, even though the movie is worth the money (imho). Alex From steve.lhomme at free.fr Tue Nov 16 16:49:23 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Tue, 16 Nov 2004 16:49:23 +0100 Subject: [Matroska-devel] adding a 'forced display' flag? In-Reply-To: <419A20BF.20802@hrz.tu-chemnitz.de> References: <20041108154018.GW5928@bunkus.org> <419874D7.1060505@free.fr> <4199EDE0.5010401@hrz.tu-chemnitz.de> <419A0939.5030201@free.fr> <419A1363.6060300@hrz.tu-chemnitz.de> <20041116145429.GE17956@bunkus.org> <419A15EF.3060700@hrz.tu-chemnitz.de> <419A1D91.4030701@free.fr> <419A20BF.20802@hrz.tu-chemnitz.de> Message-ID: <419A2183.6080403@free.fr> Alexander Noe' a ?crit : > Steve Lhomme wrote: > >> >> But you forget that the default flag applies to all kinds of track, >> not just subs. The default flag is to tell "if you don't know what >> track to use in the list, use this one". It doesn't say anything else. > > > I don't... > >> >> The forced flag would say "regardless of the playback option, this >> track has to be used". > > > That's exactly what I consider inacceptable. What you don't like is the way you can't get rid of it in DVDs. Which is _very_ unlikely to happen with Matroska. Especially since we add features for users, so if they don't like it they will use an older version of the software... From moritz at bunkus.org Tue Nov 16 16:54:12 2004 From: moritz at bunkus.org (Moritz Bunkus) Date: Tue, 16 Nov 2004 16:54:12 +0100 Subject: [Matroska-devel] CodecPrivate for MPEG-1 and MPEG-2 video In-Reply-To: <419A1918.8080705@po.cs.msu.su> References: <20041116121014.GK5928@bunkus.org> <419A1040.4090006@free.fr> <419A1918.8080705@po.cs.msu.su> Message-ID: <20041116155412.GA19160@bunkus.org> Hey, > >Well, that's quite a change. Because so far we always assume the > >CodecPrivate is filled for each CodecID. Nope. Simply take MP3, PCM or even the RealVideo codecs -- the CodecPrivate is empty for all of those. > I accidentally replied privately to Mosu, but windows mpeg1/2 decoders > require the sequence header in the media type's format block, Ok, then let's do what spyder has done as well and put the first sequence header into the CodecPrivate. However, the sequence header will not be removed from the first frame. I just want to have an agreement on the topic. Mosu -- ==> Ciao, Mosu (Moritz Bunkus) From steve.lhomme at free.fr Tue Nov 16 16:57:36 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Tue, 16 Nov 2004 16:57:36 +0100 Subject: [Matroska-devel] CodecPrivate for MPEG-1 and MPEG-2 video In-Reply-To: <20041116155412.GA19160@bunkus.org> References: <20041116121014.GK5928@bunkus.org> <419A1040.4090006@free.fr> <419A1918.8080705@po.cs.msu.su> <20041116155412.GA19160@bunkus.org> Message-ID: <419A2370.5050706@free.fr> Moritz Bunkus a ?crit : > Hey, > > >>>Well, that's quite a change. Because so far we always assume the >>>CodecPrivate is filled for each CodecID. > > > Nope. Simply take MP3, PCM or even the RealVideo codecs -- the > CodecPrivate is empty for all of those. So it's filled... to empty :D (the way it's in the specs) >>I accidentally replied privately to Mosu, but windows mpeg1/2 decoders >>require the sequence header in the media type's format block, > > > Ok, then let's do what spyder has done as well and put the first > sequence header into the CodecPrivate. However, the sequence header will > not be removed from the first frame. IMO it's one or the other... Only in the CodecPrivate look logical to me. That would make concatenation cleaner. From chris at matroska.org Tue Nov 16 17:05:29 2004 From: chris at matroska.org (Christian HJ Wiesner) Date: Tue, 16 Nov 2004 17:05:29 +0100 Subject: [Matroska-devel] CodecPrivate for MPEG-1 and MPEG-2 video In-Reply-To: <419A2370.5050706@free.fr> References: <20041116121014.GK5928@bunkus.org> <419A1040.4090006@free.fr> <419A1918.8080705@po.cs.msu.su> <20041116155412.GA19160@bunkus.org> <419A2370.5050706@free.fr> Message-ID: <419A2549.3090100@matroska.org> Steve Lhomme schrieb: > IMO it's one or the other... Only in the CodecPrivate look logical to > me. That would make concatenation cleaner. IIRC thats not correct, because sequence header can change many times during the track/movie. If you consider the right solution being the one thats ideal for concatenation or editing, then the sequence header should be left inside the frame IMO, even if this means a bit less saving on overhead compared to MPEG container. But, i am pretty sure all this has been discussed many times already, even here on this list. Christian From rbultje at ronald.bitfreak.net Tue Nov 16 16:59:55 2004 From: rbultje at ronald.bitfreak.net (Ronald S. Bultje) Date: Tue, 16 Nov 2004 16:59:55 +0100 Subject: [Matroska-devel] CodecPrivate for MPEG-1 and MPEG-2 video In-Reply-To: <20041116155412.GA19160@bunkus.org> References: <20041116121014.GK5928@bunkus.org> <419A1040.4090006@free.fr> <419A1918.8080705@po.cs.msu.su> <20041116155412.GA19160@bunkus.org> Message-ID: <1100620791.2767.100.camel@tux.lan> On Tue, 2004-11-16 at 16:54, Moritz Bunkus wrote: > Ok, then let's do what spyder has done as well and put the first > sequence header into the CodecPrivate. However, the sequence header will > not be removed from the first frame. And what's the use of that? :). Ronald -- Ronald S. Bultje From moritz at bunkus.org Tue Nov 16 18:07:37 2004 From: moritz at bunkus.org (Moritz Bunkus) Date: Tue, 16 Nov 2004 18:07:37 +0100 Subject: [Matroska-devel] CodecPrivate for MPEG-1 and MPEG-2 video In-Reply-To: <419A2549.3090100@matroska.org> References: <20041116121014.GK5928@bunkus.org> <419A1040.4090006@free.fr> <419A1918.8080705@po.cs.msu.su> <20041116155412.GA19160@bunkus.org> <419A2370.5050706@free.fr> <419A2549.3090100@matroska.org> Message-ID: <20041116170737.GL5928@bunkus.org> Hey, > IIRC thats not correct, because sequence header can change many times > during the track/movie. If you consider the right solution being the one > thats ideal for concatenation or editing, then the sequence header > should be left inside the frame IMO, even if this means a bit less > saving on overhead compared to MPEG container. I don't think that the sequence header has such a big impact on overhead. And yes, they may occur more than once. If we decide to throw them all out then we have to start using CodecState, too, for the places where the sequence header changes. I don't even know the exact layout / size of a sequence header. That's why I'd like some input from spyder here. > But, i am pretty sure all this has been discussed many times already, > even here on this list. No, it hasn't :) That's why I've brought it up. (Nearly) the same discussion will follow one day for MPEG-4. The thing is that MPEG-2 and MPEG-4 seem to be stored differently in MP4, though, so we can't just say "let's do it like the MP4 guys" either. MPEG-2 in MP4 simply contains the sequence headers in the frames, and there's no "private data" in the ESDS (elementary stream descriptor). For MPEG-4 it's the other way round. The ESDS contains private data which is missing in the frames. This is a big difference compared to how it is stored in AVI: In AVI, each MPEG-4 I frame contains this private data (if I'm not mistaken). Mosu -- If Darl McBride was in charge, he'd probably make marriage unconstitutional too, since clearly it de-emphasizes the commercial nature of normal human interaction, and probably is a major impediment to the commercial growth of prostitution. - Linus Torvalds From alexander.noe at s2001.tu-chemnitz.de Tue Nov 16 18:47:18 2004 From: alexander.noe at s2001.tu-chemnitz.de (Alexander Noe') Date: Tue, 16 Nov 2004 18:47:18 +0100 Subject: [Matroska-devel] adding a 'forced display' flag? In-Reply-To: <419A2183.6080403@free.fr> References: <20041108154018.GW5928@bunkus.org> <419874D7.1060505@free.fr> <4199EDE0.5010401@hrz.tu-chemnitz.de> <419A0939.5030201@free.fr> <419A1363.6060300@hrz.tu-chemnitz.de> <20041116145429.GE17956@bunkus.org> <419A15EF.3060700@hrz.tu-chemnitz.de> <419A1D91.4030701@free.fr> <419A20BF.20802@hrz.tu-chemnitz.de> <419A2183.6080403@free.fr> Message-ID: <419A3D26.1070604@hrz.tu-chemnitz.de> Steve Lhomme wrote: > Alexander Noe' a ?crit : > >> Steve Lhomme wrote: >> >>> >>> But you forget that the default flag applies to all kinds of track, >>> not just subs. The default flag is to tell "if you don't know what >>> track to use in the list, use this one". It doesn't say anything else. >> >> >> >> I don't... >> >>> >>> The forced flag would say "regardless of the playback option, this >>> track has to be used". >> >> >> >> That's exactly what I consider inacceptable. > > > What you don't like is the way you can't get rid of it in DVDs. Which > is _very_ unlikely to happen with Matroska. Especially since we add > features for users, so if they don't like it they will use an older > version of the software... Yeah, add new stuff so that people have more reason to use older versions :oOOOOOOOOOOOO Alex From spyder at matroska.org Tue Nov 16 18:57:45 2004 From: spyder at matroska.org (John Cannon) Date: Tue, 16 Nov 2004 11:57:45 -0600 Subject: [Matroska-devel] Re: CodecPrivate for MPEG-1 and MPEG-2 video In-Reply-To: <20041116170737.GL5928@bunkus.org> References: <20041116121014.GK5928@bunkus.org> <419A1040.4090006@free.fr> <419A1918.8080705@po.cs.msu.su> <20041116155412.GA19160@bunkus.org> <419A2370.5050706@free.fr> <419A2549.3090100@matroska.org> <20041116170737.GL5928@bunkus.org> Message-ID: Moritz Bunkus wrote: > I don't think that the sequence header has such a big impact on > overhead. And yes, they may occur more than once. If we decide to throw > them all out then we have to start using CodecState, too, for the places > where the sequence header changes. I don't even know the exact layout / > size of a sequence header. That's why I'd like some input from spyder > here. Very little impact, It's only like 88 bytes for most MPEG-2 clips I have, less for MPEG-1 IIRC. It's usually repeated at every GOP so you may as well consider it part of the I frame. I'm OK with not putting it in the codec private data but we decided to put a copy there because of DirectShow's retardedness as Haali stated. Sane decoders don't need the header beforehand (see libmpeg2). IMO removing the headers entirely from the stream is a bad idea. It makes the whole process much more complex and you're separating the codec stream. It just has to be reinterleaved on playback anyway so it's silly. John From paul at msn.com Tue Nov 16 19:51:45 2004 From: paul at msn.com (Paul Bryson) Date: Tue, 16 Nov 2004 12:51:45 -0600 Subject: [Matroska-devel] Re: CodecPrivate for MPEG-1 and MPEG-2 video References: <20041116121014.GK5928@bunkus.org><419A1040.4090006@free.fr> <419A1918.8080705@po.cs.msu.su> <20041116155412.GA19160@bunkus.org><419A2370.5050706@free.fr> <419A2549.3090100@matroska.org><20041116170737.GL5928@bunkus.org> Message-ID: "John Cannon" wrote... > IMO removing the headers entirely from the stream is a bad idea. It makes > the whole process much more complex and you're separating the codec > stream. It just has to be reinterleaved on playback anyway so it's silly. I'm sure we've had this discussion before. I don't feel like actually tracking it down in the ML, but it was early in the year, February maybe? Anyway, It should be optional. If the headers are identical for each GOP, then why would a decoder need them repeated all the time? Atamido From moritz at bunkus.org Tue Nov 16 19:57:37 2004 From: moritz at bunkus.org (Moritz Bunkus) Date: Tue, 16 Nov 2004 19:57:37 +0100 Subject: [Matroska-devel] Re: CodecPrivate for MPEG-1 and MPEG-2 video In-Reply-To: References: <419A1918.8080705@po.cs.msu.su> Message-ID: <20041116185737.GN5928@bunkus.org> Hey, it's not like we remove such stuff all the time. We do for AAC, we don't for AC3/MP3/DTS. So I'm actually for the easier route -- putting one sequence header into CodecPrivate and leave the stream intact. Mosu -- If Darl McBride was in charge, he'd probably make marriage unconstitutional too, since clearly it de-emphasizes the commercial nature of normal human interaction, and probably is a major impediment to the commercial growth of prostitution. - Linus Torvalds From alexander.noe at s2001.tu-chemnitz.de Tue Nov 16 20:01:40 2004 From: alexander.noe at s2001.tu-chemnitz.de (Alexander Noe') Date: Tue, 16 Nov 2004 20:01:40 +0100 Subject: [Matroska-devel] Re: CodecPrivate for MPEG-1 and MPEG-2 video In-Reply-To: <20041116185737.GN5928@bunkus.org> References: <419A1918.8080705@po.cs.msu.su> <20041116185737.GN5928@bunkus.org> Message-ID: <419A4E94.5040907@hrz.tu-chemnitz.de> Moritz Bunkus wrote: >Hey, > >it's not like we remove such stuff all the time. We do for AAC, we don't >for AC3/MP3/DTS. > The reason it has to be removed for AAC is that the AAC Decoders b0rk if it isn't. You know, it is removed for AAC-in-AVI as well... Alex From moritz at bunkus.org Tue Nov 16 20:04:03 2004 From: moritz at bunkus.org (Moritz Bunkus) Date: Tue, 16 Nov 2004 20:04:03 +0100 Subject: [Matroska-devel] Re: CodecPrivate for MPEG-1 and MPEG-2 video In-Reply-To: <419A4E94.5040907@hrz.tu-chemnitz.de> References: <419A1918.8080705@po.cs.msu.su> <20041116185737.GN5928@bunkus.org> <419A4E94.5040907@hrz.tu-chemnitz.de> Message-ID: <20041116190403.GO5928@bunkus.org> Hey, > The reason it has to be removed for AAC is that the AAC Decoders b0rk > if it isn't. faad doesn't. You can feed it a raw ADTS stream with headers. Mosu -- If Darl McBride was in charge, he'd probably make marriage unconstitutional too, since clearly it de-emphasizes the commercial nature of normal human interaction, and probably is a major impediment to the commercial growth of prostitution. - Linus Torvalds From spyder at matroska.org Wed Nov 17 00:52:26 2004 From: spyder at matroska.org (John Cannon) Date: Tue, 16 Nov 2004 17:52:26 -0600 Subject: [Matroska-devel] Re: CodecPrivate for MPEG-1 and MPEG-2 video In-Reply-To: References: <20041116121014.GK5928@bunkus.org><419A1040.4090006@free.fr> <419A1918.8080705@po.cs.msu.su> <20041116155412.GA19160@bunkus.org><419A2370.5050706@free.fr> <419A2549.3090100@matroska.org><20041116170737.GL5928@bunkus.org> Message-ID: Paul Bryson wrote: > I'm sure we've had this discussion before. I don't feel like actually > tracking it down in the ML, but it was early in the year, February maybe? > Anyway, It should be optional. If the headers are identical for each GOP, > then why would a decoder need them repeated all the time? It _IS_ optional. The MPEG-2 spec allows the headers to be repeated as often as the encoder desires. The only requirement is that there be 1 somewhere and also that the parameters stay basically the same except for a few elements. The spec recommends they be placed before each GOP for faster seeking and easier editing but AFAIK there is no requirement. I don't want to have to reconstruct the stream on demux though. So I vote for leaving the stream intact. John From steve.lhomme at free.fr Wed Nov 17 11:23:37 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Wed, 17 Nov 2004 11:23:37 +0100 Subject: [Matroska-devel] Re: CodecPrivate for MPEG-1 and MPEG-2 video In-Reply-To: References: <20041116121014.GK5928@bunkus.org><419A1040.4090006@free.fr> <419A1918.8080705@po.cs.msu.su> <20041116155412.GA19160@bunkus.org><419A2370.5050706@free.fr> <419A2549.3090100@matroska.org><20041116170737.GL5928@bunkus.org> Message-ID: <419B26A9.2050104@free.fr> John Cannon a ?crit : > Paul Bryson wrote: > >> I'm sure we've had this discussion before. I don't feel like actually >> tracking it down in the ML, but it was early in the year, February >> maybe? Anyway, It should be optional. If the headers are identical >> for each GOP, then why would a decoder need them repeated all the time? > > > It _IS_ optional. The MPEG-2 spec allows the headers to be repeated as > often as the encoder desires. The only requirement is that there be 1 > somewhere and also that the parameters stay basically the same except > for a few elements. The spec recommends they be placed before each GOP > for faster seeking and easier editing but AFAIK there is no requirement. > I don't want to have to reconstruct the stream on demux though. So I > vote for leaving the stream intact. OK, let me see what we have : - The data are needed for decoding - It can be multiple times in the stream - It can change during the stream (unimportant data only ?) - DirectShow decoders need it (separated from the stream ?) If the only reason to have it is because of DirectShow, maybe we can find other ways to do it. It depends if the data are needed when the pin is connected or only during playback. If it's during playback then we can put the first frame in the codec data and that's it. IMO it doesn't make sense to have codec private data stored in tracks if that data can change during playback ! In this case it should be in the Block, but so far we haven't used this. From steve.lhomme at free.fr Wed Nov 17 11:27:19 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Wed, 17 Nov 2004 11:27:19 +0100 Subject: [Matroska-devel] adding a 'forced display' flag? In-Reply-To: <419A3D26.1070604@hrz.tu-chemnitz.de> References: <20041108154018.GW5928@bunkus.org> <419874D7.1060505@free.fr> <4199EDE0.5010401@hrz.tu-chemnitz.de> <419A0939.5030201@free.fr> <419A1363.6060300@hrz.tu-chemnitz.de> <20041116145429.GE17956@bunkus.org> <419A15EF.3060700@hrz.tu-chemnitz.de> <419A1D91.4030701@free.fr> <419A20BF.20802@hrz.tu-chemnitz.de> <419A2183.6080403@free.fr> <419A3D26.1070604@hrz.tu-chemnitz.de> Message-ID: <419B2787.8080204@free.fr> Alexander Noe' a ?crit : >>>> But you forget that the default flag applies to all kinds of track, >>>> not just subs. The default flag is to tell "if you don't know what >>>> track to use in the list, use this one". It doesn't say anything else. >>> >>> >>> >>> >>> I don't... >>> >>>> >>>> The forced flag would say "regardless of the playback option, this >>>> track has to be used". >>> >>> >>> >>> >>> That's exactly what I consider inacceptable. >> >> >> >> What you don't like is the way you can't get rid of it in DVDs. Which >> is _very_ unlikely to happen with Matroska. Especially since we add >> features for users, so if they don't like it they will use an older >> version of the software... > > > Yeah, add new stuff so that people have more reason to use older > versions :oOOOOOOOOOOOO Like 64 bits floats ? Anyway, Matroska's goal has always been to be feature rich. And at least have the same one as on DVDs, just with more flexibility. So this force flag is exactly what could achieve this. You could see the same content as on your DVD, with the same features or with more freedom... From moritz at bunkus.org Wed Nov 17 11:58:46 2004 From: moritz at bunkus.org (Moritz Bunkus) Date: Wed, 17 Nov 2004 11:58:46 +0100 Subject: [Matroska-devel] adding a 'forced display' flag? In-Reply-To: <419B2787.8080204@free.fr> References: <4199EDE0.5010401@hrz.tu-chemnitz.de> <419A0939.5030201@free.fr> <419A1363.6060300@hrz.tu-chemnitz.de> <20041116145429.GE17956@bunkus.org> <419A15EF.3060700@hrz.tu-chemnitz.de> <419A1D91.4030701@free.fr> <419A20BF.20802@hrz.tu-chemnitz.de> <419A2183.6080403@free.fr> <419A3D26.1070604@hrz.tu-chemnitz.de> <419B2787.8080204@free.fr> Message-ID: <20041117105845.GP5928@bunkus.org> Hey, > Anyway, Matroska's goal has always been to be feature rich. And at least > have the same one as on DVDs, just with more flexibility. So this force > flag is exactly what could achieve this. You could see the same content > as on your DVD, with the same features or with more freedom... I agree. So the question is how exactly we'll handle these two flags. We have to add that to the specs with a very clear description. Maybe even provide some pseudo code like I've done earlier. I'll start with a description of the "default track" flag: The "default track" flag is a hint for the playback application and SHOULD always be changeable by the user. If the user wants to see or hear a track of a certain kind (audio, video, subtitles) and she hasn't chosen a specific track then the player SHOULD use the first track of that kind whose "default track" flag is set to "1". If no such track is found then the first track of this kind SHOULD be chosen. Only one track of a kind MAY have its "default track" flag set in a segment. If a track entry does not contain the "default track" flag element then its default value "1" is to be used. The last sentence is just a reminder that Matroska knows default values even though most apps always write that field nowadays. First try for the "forced display" flag: The "forced display" flag tells the playback application that it MUST display/play this track or another track of the same kind that also has its "forced display" flag set. The "forced display" flag overrides the "default track" flag. If more than one track of a kind has its "forced display" flag set then the playback application MAY chose one of those tracks based on the user's preferences (e.g. choice of language). Thoughts? (Apart from "I don't like this flag at all". I think we all agree that playback apps should always allow the user to switch off such forced stuff even though it does negate the "forced" aspect.) Mosu -- If Darl McBride was in charge, he'd probably make marriage unconstitutional too, since clearly it de-emphasizes the commercial nature of normal human interaction, and probably is a major impediment to the commercial growth of prostitution. - Linus Torvalds From mike at po.cs.msu.su Wed Nov 17 12:07:10 2004 From: mike at po.cs.msu.su (Mike Matsnev) Date: Wed, 17 Nov 2004 14:07:10 +0300 Subject: [Matroska-devel] Re: CodecPrivate for MPEG-1 and MPEG-2 video In-Reply-To: <419B26A9.2050104@free.fr> References: <20041116121014.GK5928@bunkus.org><419A1040.4090006@free.fr> <419A1918.8080705@po.cs.msu.su> <20041116155412.GA19160@bunkus.org><419A2370.5050706@free.fr> <419A2549.3090100@matroska.org><20041116170737.GL5928@bunkus.org> <419B26A9.2050104@free.fr> Message-ID: <419B30DE.90200@po.cs.msu.su> Steve Lhomme wrote: > OK, let me see what we have : > - The data are needed for decoding > - It can be multiple times in the stream > - It can change during the stream (unimportant data only ?) > - DirectShow decoders need it (separated from the stream ?) > > If the only reason to have it is because of DirectShow, maybe we can > find other ways to do it. It depends if the data are needed when the pin > is connected or only during playback. If it's during playback then we > can put the first frame in the codec data and that's it. Sequence header is needed to connect pins. > IMO it doesn't make sense to have codec private data stored in tracks if > that data can change during playback ! In this case it should be in the > Block, but so far we haven't used this. /Mike From suiryc at yahoo.com Wed Nov 17 12:02:16 2004 From: suiryc at yahoo.com (Cyrius) Date: Wed, 17 Nov 2004 03:02:16 -0800 (PST) Subject: [Matroska-devel] Re: CodecPrivate for MPEG-1 and MPEG-2 video In-Reply-To: Message-ID: <20041117110216.71681.qmail@web53607.mail.yahoo.com> --- John Cannon wrote: > Paul Bryson wrote: > > > I'm sure we've had this discussion before. I don't feel like > actually > > tracking it down in the ML, but it was early in the year, February > maybe? > > Anyway, It should be optional. If the headers are identical for > each GOP, > > then why would a decoder need them repeated all the time? > > It _IS_ optional. The MPEG-2 spec allows the headers to be repeated > as > often as the encoder desires. The only requirement is that there be 1 > > somewhere and also that the parameters stay basically the same except > > for a few elements. The spec recommends they be placed before each > GOP > for faster seeking and easier editing but AFAIK there is no > requirement. > I don't want to have to reconstruct the stream on demux though. > So > I vote for leaving the stream intact. > > John Plus when demuxing you wouldn't always get back the original stream (since it may have only one header at the beginning of the stream). I would also vote for keeping the stream intact (since overhead impact isn't big) and have a copy of the first header in the CodecPrivateData (for frameworks needing such data beforehand). __________________________________ Do you Yahoo!? The all-new My Yahoo! - Get yours free! http://my.yahoo.com From steve.lhomme at free.fr Wed Nov 17 12:44:02 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Wed, 17 Nov 2004 12:44:02 +0100 Subject: [Matroska-devel] Re: CodecPrivate for MPEG-1 and MPEG-2 video In-Reply-To: <419B30DE.90200@po.cs.msu.su> References: <20041116121014.GK5928@bunkus.org><419A1040.4090006@free.fr> <419A1918.8080705@po.cs.msu.su> <20041116155412.GA19160@bunkus.org><419A2370.5050706@free.fr> <419A2549.3090100@matroska.org><20041116170737.GL5928@bunkus.org> <419B26A9.2050104@free.fr> <419B30DE.90200@po.cs.msu.su> Message-ID: <419B3982.5010402@free.fr> Mike Matsnev a ?crit : > Steve Lhomme wrote: > >> OK, let me see what we have : >> - The data are needed for decoding >> - It can be multiple times in the stream >> - It can change during the stream (unimportant data only ?) >> - DirectShow decoders need it (separated from the stream ?) >> >> If the only reason to have it is because of DirectShow, maybe we can >> find other ways to do it. It depends if the data are needed when the >> pin is connected or only during playback. If it's during playback then >> we can put the first frame in the codec data and that's it. > > Sequence header is needed to connect pins. It's time to get rid of DirectShow then ;) Are there any codec for which you need to feed the first frame in DShow ? That could be an (hacky (as DShow)) option... From steve.lhomme at free.fr Wed Nov 17 13:59:12 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Wed, 17 Nov 2004 13:59:12 +0100 Subject: [Matroska-devel] adding a 'forced display' flag? In-Reply-To: <20041117105845.GP5928@bunkus.org> References: <4199EDE0.5010401@hrz.tu-chemnitz.de> <419A0939.5030201@free.fr> <419A1363.6060300@hrz.tu-chemnitz.de> <20041116145429.GE17956@bunkus.org> <419A15EF.3060700@hrz.tu-chemnitz.de> <419A1D91.4030701@free.fr> <419A20BF.20802@hrz.tu-chemnitz.de> <419A2183.6080403@free.fr> <419A3D26.1070604@hrz.tu-chemnitz.de> <419B2787.8080204@free.fr> <20041117105845.GP5928@bunkus.org> Message-ID: <419B4B20.1010903@free.fr> Moritz Bunkus a ?crit : > I agree. So the question is how exactly we'll handle these two flags. We > have to add that to the specs with a very clear description. Maybe even > provide some pseudo code like I've done earlier. I'll start with a > description of the "default track" flag: > > The "default track" flag is a hint for the playback application and > SHOULD always be changeable by the user. If the user wants to see or IMO it's not good to define a feature according to another. Both flags are quite independant and if not, that would probably be the forced flag that relies on the default. > hear a track of a certain kind (audio, video, subtitles) and she > hasn't chosen a specific track then the player SHOULD use the first > track of that kind whose "default track" flag is set to "1". If no > such track is found then the first track of this kind SHOULD be > chosen. That's kinda long for the specs. > Only one track of a kind MAY have its "default track" flag set in a > segment. If a track entry does not contain the "default track" flag > element then its default value "1" is to be used. > > The last sentence is just a reminder that Matroska knows default values > even though most apps always write that field nowadays. So it can be dropped. > First try for the "forced display" flag: I don't like the word "display". The forced flag should be usable for all kinds of data. > The "forced display" flag tells the playback application that it MUST > display/play this track or another track of the same kind that also > has its "forced display" flag set. The "forced display" flag overrides > the "default track" flag. Nop. At least on DVD you can play the forced tracks and the "main" one at the same time (used only for subs AFAIK). > If more than one track of a kind has its "forced display" flag set > then the playback application MAY chose one of those tracks based on > the user's preferences (e.g. choice of language). Well, not exactly it's the choice of language, or the default flag (or whatever the application wants if none is found). Here are my versions : * Default Flag : The default flag specifies which track of a kind (audio, video, subs) SHOULD be used if no language found matches the user preference. * Forced Flag : The forced flag specifies that a track MUST be used during playback. There can be many forced track for a kind (audio, video, subs), the player should select the one which language matches the user preference or the default + forced track. Overlay MAY happen between a forced and non-forced track of the same kind. From moritz at bunkus.org Wed Nov 17 14:08:32 2004 From: moritz at bunkus.org (Moritz Bunkus) Date: Wed, 17 Nov 2004 14:08:32 +0100 Subject: [Matroska-devel] adding a 'forced display' flag? In-Reply-To: <419B4B20.1010903@free.fr> References: <419A1363.6060300@hrz.tu-chemnitz.de> <20041116145429.GE17956@bunkus.org> <419A15EF.3060700@hrz.tu-chemnitz.de> <419A1D91.4030701@free.fr> <419A20BF.20802@hrz.tu-chemnitz.de> <419A2183.6080403@free.fr> <419A3D26.1070604@hrz.tu-chemnitz.de> <419B2787.8080204@free.fr> <20041117105845.GP5928@bunkus.org> <419B4B20.1010903@free.fr> Message-ID: <20041117130832.GR5928@bunkus.org> Hey, > That's kinda long for the specs. We don't have to put this into the main table. The table can contain a short version and a link to the longer explanation which will be part of the official specs, too. > >The last sentence is just a reminder that Matroska knows default values > >even though most apps always write that field nowadays. > > So it can be dropped. Sure, but I'd like some clarification here. The current version leaves too much room for ambiguity as we've seen when TCMP and AVIMux GUI handled the flag differently. > I don't like the word "display". The forced flag should be usable for > all kinds of data. Ups, my bad. Call it "forced playback" or just "forced". > Nop. At least on DVD you can play the forced tracks and the "main" one > at the same time (used only for subs AFAIK). Yes, that's definitely what I want to express, too. > Here are my versions : > > * Default Flag : > > The default flag specifies which track of a kind (audio, video, subs) > SHOULD be used if no language found matches the user preference. > > > * Forced Flag : > > The forced flag specifies that a track MUST be used during playback. > There can be many forced track for a kind (audio, video, subs), the > player should select the one which language matches the user preference > or the default + forced track. Overlay MAY happen between a forced and > non-forced track of the same kind. Those are nice, but like I've said, I'd prefer some more explanation for both (based on your proposals). Those explanations can really be on a separate page. Mosu -- If Darl McBride was in charge, he'd probably make marriage unconstitutional too, since clearly it de-emphasizes the commercial nature of normal human interaction, and probably is a major impediment to the commercial growth of prostitution. - Linus Torvalds From jcsston at jory.info Wed Nov 17 18:06:46 2004 From: jcsston at jory.info (Jory Stone) Date: Wed, 17 Nov 2004 11:06:46 -0600 Subject: [Matroska-devel] Re: CodecPrivate for MPEG-1 and MPEG-2 video References: <20041116121014.GK5928@bunkus.org><419A1040.4090006@free.fr> <419A1918.8080705@po.cs.msu.su> <20041116155412.GA19160@bunkus.org><419A2370.5050706@free.fr> <419A2549.3090100@matroska.org><20041116170737.GL5928@bunkus.org> <419B26A9.2050104@free.fr><419B30DE.90200@po.cs.msu.su> <419B3982.5010402@free.fr> Message-ID: <005501c4ccd6$d074a6f0$6b00a8c0@jcsston> Remember Vorbis? ;) Though it required 3 frame, not just 1. I also vote for keeping the sequence header intact. Unless someone plans on write a custom MPEG-1/2 decoder for Matroska for every framework out there. Jory ----- Original Message ----- From: "Steve Lhomme" To: "Discussion about the current and future development of Matroska" Sent: Wednesday, November 17, 2004 5:44 AM Subject: Re: [Matroska-devel] Re: CodecPrivate for MPEG-1 and MPEG-2 video Mike Matsnev a ?crit : > Steve Lhomme wrote: > >> OK, let me see what we have : >> - The data are needed for decoding >> - It can be multiple times in the stream >> - It can change during the stream (unimportant data only ?) >> - DirectShow decoders need it (separated from the stream ?) >> >> If the only reason to have it is because of DirectShow, maybe we can find >> other ways to do it. It depends if the data are needed when the pin is >> connected or only during playback. If it's during playback then we can >> put the first frame in the codec data and that's it. > > Sequence header is needed to connect pins. It's time to get rid of DirectShow then ;) Are there any codec for which you need to feed the first frame in DShow ? That could be an (hacky (as DShow)) option... _______________________________________________ Matroska-devel mailing list Matroska-devel at lists.matroska.org http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel From alexander.noe at s2001.tu-chemnitz.de Wed Nov 17 19:57:20 2004 From: alexander.noe at s2001.tu-chemnitz.de (Alexander Noe') Date: Wed, 17 Nov 2004 19:57:20 +0100 Subject: [Matroska-devel] Re: CodecPrivate for MPEG-1 and MPEG-2 video In-Reply-To: <005501c4ccd6$d074a6f0$6b00a8c0@jcsston> References: <20041116121014.GK5928@bunkus.org><419A1040.4090006@free.fr> <419A1918.8080705@po.cs.msu.su> <20041116155412.GA19160@bunkus.org><419A2370.5050706@free.fr> <419A2549.3090100@matroska.org><20041116170737.GL5928@bunkus.org> <419B26A9.2050104@free.fr><419B30DE.90200@po.cs.msu.su> <419B3982.5010402@free.fr> <005501c4ccd6$d074a6f0$6b00a8c0@jcsston> Message-ID: <419B9F10.4080701@hrz.tu-chemnitz.de> Jory Stone wrote: > Remember Vorbis? ;) > > Though it required 3 frame, not just 1. Those 3 "frames" don't contain audio data. That's why you usually speak about "packets": A packet can be an initialization packet (the 3 packets you are refering to) or a frame containing audio data. Alex From moritz at bunkus.org Wed Nov 17 20:00:18 2004 From: moritz at bunkus.org (Moritz Bunkus) Date: Wed, 17 Nov 2004 20:00:18 +0100 Subject: [Matroska-devel] Re: CodecPrivate for MPEG-1 and MPEG-2 video In-Reply-To: <005501c4ccd6$d074a6f0$6b00a8c0@jcsston> References: <419A1918.8080705@po.cs.msu.su> <419B3982.5010402@free.fr> <005501c4ccd6$d074a6f0$6b00a8c0@jcsston> Message-ID: <20041117190018.GU5928@bunkus.org> Hey, > Remember Vorbis? ;) > > Though it required 3 frame, not just 1. True, true, but we put those packets into the CodecPrivate in a separatable way. So for the sake of convenience I vote for the same as Cyrius: leave the stream as it is and ALSO put the first sequence header into the CodecPrivate. All known MPEG1/2 decoders will be fine if they encounter multiple sequence headers (because 1. this is in the MPEG specs and 2. every stream contains more than one of those anyway), so it won't harm anyone and provide information for those frameworks that need the data up front. In fact I also dislike the way we're handling AAC by encoding stuff that should belong into the CodecPrivate in the CodecID. The demuxer has to reconstruct that private data from the CodecID... Bad choice back then IMHO :( (Yes, I'm responsible, too.) Mosu -- If Darl McBride was in charge, he'd probably make marriage unconstitutional too, since clearly it de-emphasizes the commercial nature of normal human interaction, and probably is a major impediment to the commercial growth of prostitution. - Linus Torvalds From spyder at matroska.org Wed Nov 17 20:08:10 2004 From: spyder at matroska.org (John Cannon) Date: Wed, 17 Nov 2004 13:08:10 -0600 Subject: [Matroska-devel] Re: CodecPrivate for MPEG-1 and MPEG-2 video In-Reply-To: <419B3982.5010402@free.fr> References: <20041116121014.GK5928@bunkus.org><419A1040.4090006@free.fr> <419A1918.8080705@po.cs.msu.su> <20041116155412.GA19160@bunkus.org><419A2370.5050706@free.fr> <419A2549.3090100@matroska.org><20041116170737.GL5928@bunkus.org> <419B26A9.2050104@free.fr> <419B30DE.90200@po.cs.msu.su> <419B3982.5010402@free.fr> Message-ID: Steve Lhomme wrote: > Mike Matsnev a ?crit : > >> Steve Lhomme wrote: >> >>> OK, let me see what we have : >>> - The data are needed for decoding >>> - It can be multiple times in the stream >>> - It can change during the stream (unimportant data only ?) >>> - DirectShow decoders need it (separated from the stream ?) >>> >>> If the only reason to have it is because of DirectShow, maybe we can >>> find other ways to do it. It depends if the data are needed when the >>> pin is connected or only during playback. If it's during playback >>> then we can put the first frame in the codec data and that's it. >> >> >> Sequence header is needed to connect pins. > > > It's time to get rid of DirectShow then ;) > > Are there any codec for which you need to feed the first frame in DShow > ? That could be an (hacky (as DShow)) option... The reason behind this is that not all containers specify resolution etc. for streams inside. An example is an MPEG Transport Stream. The decoder must have the sequence header before it can determine the resolution. Of course, this is easily obtained from the stream but some frameworks may need to know the resolution BEFORE decoding actually begins. I don't know how DirectShow works but gstreamer is capable of running a pipeline before all pins have been connected I believe. This way when the resolution has been determined the next filters can be connected. I see no harm in putting the header itself in the private data and just leaving the whole stream intact otherwise. Also, the information which can change in the header(quantizer matrices) is crucial to proper decoding so you can't just use one header. From paul at msn.com Thu Nov 18 07:30:25 2004 From: paul at msn.com (Paul Bryson) Date: Thu, 18 Nov 2004 00:30:25 -0600 Subject: [Matroska-devel] Re: CodecPrivate for MPEG-1 and MPEG-2 video References: <20041116121014.GK5928@bunkus.org><419A1040.4090006@free.fr> <419A1918.8080705@po.cs.msu.su> <20041116155412.GA19160@bunkus.org><419A2370.5050706@free.fr> <419A2549.3090100@matroska.org><20041116170737.GL5928@bunkus.org> <419B26A9.2050104@free.fr> <419B30DE.90200@po.cs.msu.su><419B3982.5010402@free.fr> Message-ID: "John Cannon" wrote... > Also, the information which can change in the header(quantizer matrices) > is crucial to proper decoding so you can't just use one header. I found what I was talking about. http://article.gmane.org/gmane.comp.multimedia.matroska.devel/1221 the gist is to store the sequence header in the stream, but make storing the GOP in the stream optional. I guess if the sequence header is required by the stream it should be stored in the CodecPrivate too. Atamido From steve.lhomme at free.fr Fri Nov 19 13:35:52 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Fri, 19 Nov 2004 13:35:52 +0100 Subject: [Matroska-devel] Re: [Matroska-cvs] [matroska] r953 - trunk/libebml/make/mingw32 In-Reply-To: <200411191217.iAJCHMQY046309@matroska.org> References: <200411191217.iAJCHMQY046309@matroska.org> Message-ID: <419DE8A8.2040704@free.fr> svn-commit-mail at lists.matroska.org a ?crit : > Author: mosu > Date: 2004-11-19 15:17:21 +0300 (Fri, 19 Nov 2004) > New Revision: 953 > > Modified: > trunk/libebml/make/mingw32/Makefile > Log: > Compile libebml as a DLL by default (is anyone except me using this mingw Makefile anyway?). Do not remove the dependency file on "make clean". > > Modified: trunk/libebml/make/mingw32/Makefile > =================================================================== > --- trunk/libebml/make/mingw32/Makefile 2004-11-17 14:51:26 UTC (rev 952) > +++ trunk/libebml/make/mingw32/Makefile 2004-11-19 12:17:21 UTC (rev 953) > @@ -4,7 +4,7 @@ > # Normally libebml is built as a static library. > # Uncomment this if you want a shared library instead. > # ATTENTION: If your app uses this DLL you have to define EBML_DLL ! > -#SHARED = yes > +SHARED = yes As you compile on Linux, you might just set this variable when you compile libebml and libmatroska. Because it's not safe for anyone to compile the libraries only to realise later they have to uncheck something in the Makefile so that it works. Otherwise you should update the comment too. I don't encourage the use of a DLL version because it's only compatible with MinGW32 programs. That's not the way people are used to work on Windows. From moritz at bunkus.org Fri Nov 19 13:55:09 2004 From: moritz at bunkus.org (Moritz Bunkus) Date: Fri, 19 Nov 2004 13:55:09 +0100 Subject: [Matroska-devel] Re: [Matroska-cvs] [matroska] r953 - trunk/libebml/make/mingw32 In-Reply-To: <419DE8A8.2040704@free.fr> References: <200411191217.iAJCHMQY046309@matroska.org> <419DE8A8.2040704@free.fr> Message-ID: <20041119125509.GB5928@bunkus.org> Hey, > As you compile on Linux, you might just set this variable when you > compile libebml and libmatroska. Because it's not safe for anyone to > compile the libraries only to realise later they have to uncheck > something in the Makefile so that it works. Otherwise you should update > the comment too. The Makefile for libmatroska was broken the whole time anyway, because it had 'EBML_DLL = yes' since... forever now. Now it is at least conclusive. I'll modify the comments in the Makefiles about the DLLs only working with mingw compiled programs. (BTW: Isn't this true for the static libs as well? I guess that g++ and MSVC use different name mangling syntaxes, so this should be a general warning...) > I don't encourage the use of a DLL version because it's only compatible > with MinGW32 programs. And this is in the MinGW32 Makefile, not a general decision for Windows :) So if someone actually uses it (it = this Makefile) then she should be aware that there may be problems. > That's not the way people are used to work on Windows. True, but like I said, no one else uses this Makefile anyway. And I just want some more comfort :) Mosu -- If Darl McBride was in charge, he'd probably make marriage unconstitutional too, since clearly it de-emphasizes the commercial nature of normal human interaction, and probably is a major impediment to the commercial growth of prostitution. - Linus Torvalds From steve.lhomme at free.fr Fri Nov 19 13:57:11 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Fri, 19 Nov 2004 13:57:11 +0100 Subject: [Matroska-devel] Re: [Matroska-cvs] [matroska] r953 - trunk/libebml/make/mingw32 In-Reply-To: <20041119125509.GB5928@bunkus.org> References: <200411191217.iAJCHMQY046309@matroska.org> <419DE8A8.2040704@free.fr> <20041119125509.GB5928@bunkus.org> Message-ID: <419DEDA7.8030001@free.fr> Moritz Bunkus a ?crit : > Hey, > > >>As you compile on Linux, you might just set this variable when you >>compile libebml and libmatroska. Because it's not safe for anyone to >>compile the libraries only to realise later they have to uncheck >>something in the Makefile so that it works. Otherwise you should update >>the comment too. > > > The Makefile for libmatroska was broken the whole time anyway, because > it had 'EBML_DLL = yes' since... forever now. Now it is at least > conclusive. I'll modify the comments in the Makefiles about the DLLs > only working with mingw compiled programs. (BTW: Isn't this true for the > static libs as well? I guess that g++ and MSVC use different name > mangling syntaxes, so this should be a general warning...) Yes, but when you find a DLL you might think you can use it with any other Windows program. When you find a .a or .so file you know it won't work with your MS compiler... >>I don't encourage the use of a DLL version because it's only compatible >>with MinGW32 programs. > > > And this is in the MinGW32 Makefile, not a general decision for Windows > :) So if someone actually uses it (it = this Makefile) then she should > be aware that there may be problems. > > >>That's not the way people are used to work on Windows. > > > True, but like I said, no one else uses this Makefile anyway. And I just > want some more comfort :) Well, your logic implies noone will ever use it anyway. From moritz at bunkus.org Fri Nov 19 14:04:54 2004 From: moritz at bunkus.org (Moritz Bunkus) Date: Fri, 19 Nov 2004 14:04:54 +0100 Subject: [Matroska-devel] Re: [Matroska-cvs] [matroska] r953 - trunk/libebml/make/mingw32 In-Reply-To: <419DEDA7.8030001@free.fr> References: <200411191217.iAJCHMQY046309@matroska.org> <419DE8A8.2040704@free.fr> <20041119125509.GB5928@bunkus.org> <419DEDA7.8030001@free.fr> Message-ID: <20041119130454.GC5928@bunkus.org> Hey, > Yes, but when you find a DLL you might think you can use it with any > other Windows program. When you find a .a or .so file you know it won't > work with your MS compiler... Uhm... Huh? How is that an argument? My runtime package has always contained such a DLL, but certainly not the headers. I will NOT put such a stupid warning into my runtime package because it is just that, a runtime package. The libebml downloads we offer on the other hand do NOT contain a DLL. So I don't see your point that an existing DLL might confuse someone... because there ain't one in the official lib* downloads. > Well, your logic implies noone will ever use it anyway. That was my intention, yes. Sad but true. (Maybe not so sad. Mingw is hardly the most convenient programming environment on Windows.) Mosu -- If Darl McBride was in charge, he'd probably make marriage unconstitutional too, since clearly it de-emphasizes the commercial nature of normal human interaction, and probably is a major impediment to the commercial growth of prostitution. - Linus Torvalds From moritz at bunkus.org Fri Nov 19 14:21:03 2004 From: moritz at bunkus.org (Moritz Bunkus) Date: Fri, 19 Nov 2004 14:21:03 +0100 Subject: [Matroska-devel] Re: [Matroska-cvs] [matroska] r953 - trunk/libebml/make/mingw32 In-Reply-To: <20041119130454.GC5928@bunkus.org> References: <200411191217.iAJCHMQY046309@matroska.org> <419DE8A8.2040704@free.fr> <20041119125509.GB5928@bunkus.org> <419DEDA7.8030001@free.fr> <20041119130454.GC5928@bunkus.org> Message-ID: <20041119132103.GD5928@bunkus.org> Hey, > Uhm... Huh? How is that an argument? My runtime package has always > contained such a DLL, but certainly not the headers. I will NOT put such > a stupid warning into my runtime package because it is just that, a > runtime package. Ups wrong, my runtime package does not contain libebml.dll and libmatroska.dll -- only the actual mkvtoolnix .rars do. Mosu -- If Darl McBride was in charge, he'd probably make marriage unconstitutional too, since clearly it de-emphasizes the commercial nature of normal human interaction, and probably is a major impediment to the commercial growth of prostitution. - Linus Torvalds From steve.lhomme at free.fr Fri Nov 19 14:51:42 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Fri, 19 Nov 2004 14:51:42 +0100 Subject: [Matroska-devel] Re: from MOHAX (coruppted matroska file tread at CORECODEC forum) In-Reply-To: <1385395879.20041119154933@mail.ru> References: <1385395879.20041119154933@mail.ru> Message-ID: <419DFA6E.3010609@free.fr> Miller on mail.ru a ?crit : > Hello robux4, > > I am from > http://corecodec.com/modules.php?op=modload&name=PNphpBB2&file=viewtopic&p=6494#6494 > > full.rar - result of mkvinfo in GUI mode, all elements At the end of the file I see : (MKVInfo) | + Block group at 707486756 (MKVInfo) | + Reference block: -40.000000ms at 707486759 (MKVInfo) | + Block (track number 1, 1 frame(s), timecode 2549.160s = 00:42:29.160000000) at 707486762 (MKVInfo) | + Frame with size 8652 (MKVInfo) | + Unknown element: DummyElement at 707495421 (MKVInfo) | + Unknown element: DummyElement at 707495549 (MKVInfo) | + Unknown element: DummyElement at 707502090 (MKVInfo) | + Unknown element: DummyElement at 707514406 (MKVInfo) | + Unknown element: DummyElement at 707521666 (MKVInfo) | + Unknown element: DummyElement at 707521728 (MKVInfo) | + Unknown element: DummyElement at 707521801 ... So it seems your file is badly corrupter and libebml cannot find a valid Cluster/Chapter/Whatever after that in the file. Maybe your file wasn't downloaded completely ? (you can see data stops at 42 minutes) Can you try the output of this program on the same file ? http://www-user.tu-chemnitz.de/~noe/Video-Zeug/mkvverify/index-eng.html From moritz at bunkus.org Mon Nov 22 23:13:53 2004 From: moritz at bunkus.org (Moritz Bunkus) Date: Mon, 22 Nov 2004 23:13:53 +0100 Subject: [Matroska-devel] problem with AAC-in-Matroska Message-ID: <20041122221353.GG14213@bunkus.org> Hey, The fact that we do not store the AAC ESDS decoder config bytes in the CodecPrivate is coming back to haunt us, it seems. So far we have two "types": 1. Normal AAC with two bytes of AAC ESDS decoder config data (= "decoder_config" from now on). It contains the object type index, the sampling frequency index and the number of channels. 2. The SBR extension to AAC (also called HE-AAC). It has five bytes of decoder_config. The first two are identical to the simple one. The next three contain a constant ("sync extension" = 0x02b7) and the output sampling frequency index. So far we could map that 1:1 onto the Matroska structures. But now a user has uploaded a file with what I believe is called "parametric stereo" (which is another extension on top of SBR (?)). This one contains _four_ bytes of decoder_config. Stepping through libfaad's initialization routine revealed some additional info being stored there which we definitely cannot map onto Matroska elements. So what do we do about this? I see the following options: 1. Create the appropriate elements in Matroska, invent one/some more CodecID(s), and keep CodecPrivate empty. 2. Create one/some new CodecID(s) and explicitely say that for these the CodecPrivate MUST contain the complete decoder_config. 3. Like 2. but also change the specs so that for all other AAC types CodecPrivate MAY contain the complete decoder_config. If CodecPrivate hsa been set then the demuxer can simply pass that data over to the decoder. If it hasn't been set then nothing changes, because the demuxers are already able to reconstruct the decoder_config for all supported AAC types ("normal" and "SBR"). 4. Do nothing. This way those "parametric stereo" files are recognized as being SBR (because their sampling frequency is 24000 Hz, and the standard says that all files with a sampling frequency <= 24000 Hz are implicitely SBR). The problem is that two bytes of decoder_config are simply lost. This may make some files undecodable. Here are my preferences: 4. sucks because this means that Matroska doesn't support such files. 1. sucks because it would be us constantly chasing after some standards and inventing elements that will only be used for a single codec type. Also we really shouldn't translate codec-specific stuff into general container level stuff. 2. is nice, but 3. is IMHO a bit better -- although it doesn't have any real advantage over 2. I've uploaded the sample to http://www.bunkus.org/videotools/mkvtoolnix/temp/problem_sample.3gp Mosu -- If Darl McBride was in charge, he'd probably make marriage unconstitutional too, since clearly it de-emphasizes the commercial nature of normal human interaction, and probably is a major impediment to the commercial growth of prostitution. - Linus Torvalds From moritz at bunkus.org Mon Nov 22 23:18:29 2004 From: moritz at bunkus.org (Moritz Bunkus) Date: Mon, 22 Nov 2004 23:18:29 +0100 Subject: [Matroska-devel] CodecPrivate for MPEG-1 and MPEG-2 video In-Reply-To: <20041116121014.GK5928@bunkus.org> References: <20041116121014.GK5928@bunkus.org> Message-ID: <20041122221829.GH14213@bunkus.org> Hey, so to sum it up: About four people opted for storing the first sequence header in the CodecPrivate and leaving all sequence headers in the stream as they are ( = leaving the stream intact). One was against that and for removing the sequence headers from the streams. The rest was silent. So unless someone speaks up now I'll add this stuff to the specs soon. Mosu -- If Darl McBride was in charge, he'd probably make marriage unconstitutional too, since clearly it de-emphasizes the commercial nature of normal human interaction, and probably is a major impediment to the commercial growth of prostitution. - Linus Torvalds From mike at po.cs.msu.su Tue Nov 23 09:10:16 2004 From: mike at po.cs.msu.su (Mike Matsnev) Date: Tue, 23 Nov 2004 11:10:16 +0300 Subject: [Matroska-devel] problem with AAC-in-Matroska In-Reply-To: <20041122221353.GG14213@bunkus.org> References: <20041122221353.GG14213@bunkus.org> Message-ID: <41A2F068.6020805@po.cs.msu.su> Moritz Bunkus wrote: > 1. Create the appropriate elements in Matroska, invent one/some more > CodecID(s), and keep CodecPrivate empty. > 2. Create one/some new CodecID(s) and explicitely say that for these the > CodecPrivate MUST contain the complete decoder_config. > 3. Like 2. but also change the specs so that for all other AAC types > CodecPrivate MAY contain the complete decoder_config. If CodecPrivate > hsa been set then the demuxer can simply pass that data over to the > decoder. If it hasn't been set then nothing changes, because the > demuxers are already able to reconstruct the decoder_config for all > supported AAC types ("normal" and "SBR"). > 4. Do nothing. This way those "parametric stereo" files are recognized > as being SBR (because their sampling frequency is 24000 Hz, and the > standard says that all files with a sampling frequency <= 24000 Hz > are implicitely SBR). The problem is that two bytes of decoder_config > are simply lost. This may make some files undecodable. I vote for 3. This way new files will be mostly compatible with old splitters, and new software will simply use CodecPrivate if it's present. I suggest we use plain "A_AAC" and set CodecPrivate for files that don't map to existing IDs. /Mike From steve.lhomme at free.fr Tue Nov 23 09:26:52 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Tue, 23 Nov 2004 09:26:52 +0100 Subject: [Matroska-devel] [Fwd: Re[2]: from MOHAX (coruppted matroska file tread at CORECODEC forum)] Message-ID: <41A2F44C.7060609@free.fr> Alex, what does this mkvverify message means ? -------- Message original -------- Sujet: Re[2]: from MOHAX (coruppted matroska file tread at CORECODEC forum) Date: Tue, 23 Nov 2004 11:07:38 +0300 De: Miller on mail.ru R?pondre ?: Miller on mail.ru Pour: Steve Lhomme R?f?rences: <1385395879.20041119154933 at mail.ru> <419DFA6E.3010609 at free.fr> Hello Steve, Friday, November 19, 2004, 4:51:42 PM, you wrote: SL> Miller on mail.ru a ?crit : >> Hello robux4, >> >> I am from >> http://corecodec.com/modules.php?op=modload&name=PNphpBB2&file=viewtopic&p=6494#6494 >> >> full.rar - result of mkvinfo in GUI mode, all elements SL> At the end of the file I see : SL> (MKVInfo) | + Block group at 707486756 SL> (MKVInfo) | + Reference block: -40.000000ms at 707486759 SL> (MKVInfo) | + Block (track number 1, 1 frame(s), timecode 2549.160s = SL> 00:42:29.160000000) at 707486762 SL> (MKVInfo) | + Frame with size 8652 SL> (MKVInfo) | + Unknown element: DummyElement at 707495421 SL> (MKVInfo) | + Unknown element: DummyElement at 707495549 SL> (MKVInfo) | + Unknown element: DummyElement at 707502090 SL> (MKVInfo) | + Unknown element: DummyElement at 707514406 SL> (MKVInfo) | + Unknown element: DummyElement at 707521666 SL> (MKVInfo) | + Unknown element: DummyElement at 707521728 SL> (MKVInfo) | + Unknown element: DummyElement at 707521801 SL> ... SL> So it seems your file is badly corrupter and libebml cannot find a valid SL> Cluster/Chapter/Whatever after that in the file. Maybe your file wasn't SL> downloaded completely ? SL> (you can see data stops at 42 minutes) Hmm, I this has too noticed :) Exists program, which corrects mkv-file (as DivFix)? SL> Can you try the output of this program on the same file ? SL> http://www-user.tu-chemnitz.de/~noe/Video-Zeug/mkvverify/index-eng.html Result of this program work (errors.txt): (mkv parser) note: Seekhead contains link to another Seekhead. -- Best regards, Miller mailto:v_Miller at mail.ru -- robUx4 on blog From steve.lhomme at free.fr Tue Nov 23 09:32:59 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Tue, 23 Nov 2004 09:32:59 +0100 Subject: [Matroska-devel] problem with AAC-in-Matroska In-Reply-To: <20041122221353.GG14213@bunkus.org> References: <20041122221353.GG14213@bunkus.org> Message-ID: <41A2F5BB.2050704@free.fr> Moritz Bunkus a ?crit : > So far we could map that 1:1 onto the Matroska structures. But now a > user has uploaded a file with what I believe is called "parametric > stereo" (which is another extension on top of SBR (?)). This one Indeed, that's being developped a lot at Ahead. It's said to improve even more SBR (and make the top codec for low bitrates). > contains _four_ bytes of decoder_config. Stepping through libfaad's > initialization routine revealed some additional info being stored there > which we definitely cannot map onto Matroska elements. > > So what do we do about this? I see the following options: > > 1. Create the appropriate elements in Matroska, invent one/some more > CodecID(s), and keep CodecPrivate empty. > 2. Create one/some new CodecID(s) and explicitely say that for these the > CodecPrivate MUST contain the complete decoder_config. > 3. Like 2. but also change the specs so that for all other AAC types > CodecPrivate MAY contain the complete decoder_config. If CodecPrivate > hsa been set then the demuxer can simply pass that data over to the > decoder. If it hasn't been set then nothing changes, because the > demuxers are already able to reconstruct the decoder_config for all > supported AAC types ("normal" and "SBR"). > 4. Do nothing. This way those "parametric stereo" files are recognized > as being SBR (because their sampling frequency is 24000 Hz, and the > standard says that all files with a sampling frequency <= 24000 Hz > are implicitely SBR). The problem is that two bytes of decoder_config > are simply lost. This may make some files undecodable. > > Here are my preferences: > > 4. sucks because this means that Matroska doesn't support such files. > > 1. sucks because it would be us constantly chasing after some standards > and inventing elements that will only be used for a single codec > type. Also we really shouldn't translate codec-specific stuff into > general container level stuff. > > 2. is nice, but 3. is IMHO a bit better -- although it doesn't have any > real advantage over 2. If 3 keeps the old CodecIDs and improve themn that's the way to go. IMO we don't want 5 IDs to handle basically the same codec... From moritz at bunkus.org Tue Nov 23 11:35:30 2004 From: moritz at bunkus.org (Moritz Bunkus) Date: Tue, 23 Nov 2004 11:35:30 +0100 Subject: [Matroska-devel] problem with AAC-in-Matroska In-Reply-To: <41A2F5BB.2050704@free.fr> References: <20041122221353.GG14213@bunkus.org> <41A2F5BB.2050704@free.fr> Message-ID: <20041123103529.GO14213@bunkus.org> Hey, > If 3 keeps the old CodecIDs and improve themn that's the way to go. IMO > we don't want 5 IDs to handle basically the same codec... Yeah. I like Mike's proposal, too. Introduce one new CodecID called A_AAC. For this CodecID CodecPrivate MUST contain the decoder_config. This will not break older splitters as it is a 'normal addition', so only files with the new A_AAC CodecID will require updated splitters. Mosu -- If Darl McBride was in charge, he'd probably make marriage unconstitutional too, since clearly it de-emphasizes the commercial nature of normal human interaction, and probably is a major impediment to the commercial growth of prostitution. - Linus Torvalds From moritz at bunkus.org Tue Nov 23 15:31:28 2004 From: moritz at bunkus.org (Moritz Bunkus) Date: Tue, 23 Nov 2004 15:31:28 +0100 Subject: [Matroska-devel] problem with AAC-in-Matroska In-Reply-To: <20041123103529.GO14213@bunkus.org> References: <20041122221353.GG14213@bunkus.org> <41A2F5BB.2050704@free.fr> <20041123103529.GO14213@bunkus.org> Message-ID: <20041123143128.GU14213@bunkus.org> Hey, here's a mkvtoolnix build that supports such files. For "normal" and "SBR" AAC (read: for AAC with 2 or 5 bytes decoder_config) it'll use the old CodecIDs. For other stuff it'll use A_AAC and put the decoder_config into CodecPrivate. http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/HEAD/mkvtoolnix-head-20041123-1.rar Two sample files are also available along with their remuxed versions at http://www.bunkus.org/videotools/mkvtoolnix/temp/aac/ Mosu -- If Darl McBride was in charge, he'd probably make marriage unconstitutional too, since clearly it de-emphasizes the commercial nature of normal human interaction, and probably is a major impediment to the commercial growth of prostitution. - Linus Torvalds From vegard_p at broadpark.no Tue Nov 23 18:18:22 2004 From: vegard_p at broadpark.no (Vegard Pettersen) Date: Tue, 23 Nov 2004 18:18:22 +0100 Subject: [Matroska-devel] RFC on implementing metadata-handling for per-chapter track-splitting on extraction Message-ID: <200411231818.23001.vegard_p@broadpark.no> What I am currently looking at, is extracting only parts of a matroska track, and handling the metadata-modifications that this entails. As an example, extracting specific CD-tracks for a flac-file with 13 tracks requires modifications of the file-headers on output and so on. Since I expect this to be required for other files than flacs, I'm wondering if you have any views on how to implement this so as for it to be more easily expandable to handling metadata for all filetypes. Cheers, Vegard Pettersen From alexander.noe at s2001.tu-chemnitz.de Tue Nov 23 21:34:16 2004 From: alexander.noe at s2001.tu-chemnitz.de (Alexander Noe') Date: Tue, 23 Nov 2004 21:34:16 +0100 Subject: [Matroska-devel] [Fwd: Re[2]: from MOHAX (coruppted matroska file tread at CORECODEC forum)] In-Reply-To: <41A2F44C.7060609@free.fr> References: <41A2F44C.7060609@free.fr> Message-ID: <41A39EC8.8020503@hrz.tu-chemnitz.de> Steve Lhomme wrote: > Alex, what does this mkvverify message means ? It means that a seekhead contains a link to a seekhead. > > SL> At the end of the file I see : > > SL> (MKVInfo) | + Block group at 707486756 > SL> (MKVInfo) | + Reference block: -40.000000ms at 707486759 > SL> (MKVInfo) | + Block (track number 1, 1 frame(s), timecode > 2549.160s = > SL> 00:42:29.160000000) at 707486762 > SL> (MKVInfo) | + Frame with size 8652 > SL> (MKVInfo) | + Unknown element: DummyElement at 707495421 > SL> (MKVInfo) | + Unknown element: DummyElement at 707495549 > SL> (MKVInfo) | + Unknown element: DummyElement at 707502090 > SL> (MKVInfo) | + Unknown element: DummyElement at 707514406 > SL> (MKVInfo) | + Unknown element: DummyElement at 707521666 > SL> (MKVInfo) | + Unknown element: DummyElement at 707521728 > SL> (MKVInfo) | + Unknown element: DummyElement at 707521801 > SL> ... Can you do mkvverify -fulldump >output.txt, compress output.txt to ace or rar or zip, and then send it to me? Alex From paul at msn.com Tue Nov 23 21:53:49 2004 From: paul at msn.com (Paul Bryson) Date: Tue, 23 Nov 2004 14:53:49 -0600 Subject: [Matroska-devel] Re: CodecPrivate for MPEG-1 and MPEG-2 video References: <20041116121014.GK5928@bunkus.org> <20041122221829.GH14213@bunkus.org> Message-ID: "Moritz Bunkus" wrote... > Hey, > > so to sum it up: About four people opted for storing the first > sequence header in the CodecPrivate and leaving all sequence headers in > the stream as they are ( = leaving the stream intact). > > One was against that and for removing the sequence headers from the > streams. > > The rest was silent. > > So unless someone speaks up now I'll add this stuff to the specs soon. Does anyone have an issue with removing the [GOP] headers? Or at least making that an option? Atamido From spyder at matroska.org Wed Nov 24 01:36:42 2004 From: spyder at matroska.org (John Cannon) Date: Tue, 23 Nov 2004 18:36:42 -0600 Subject: [Matroska-devel] Re: CodecPrivate for MPEG-1 and MPEG-2 video In-Reply-To: References: <20041116121014.GK5928@bunkus.org> <20041122221829.GH14213@bunkus.org> Message-ID: Paul Bryson wrote: > Does anyone have an issue with removing the [GOP] headers? Or at least > making that an option? Actually, my code removes them. It can be modified to keep them though. It doesn't really matter with most (any?) decoders. The header simply tells a timestamp and whether the GOP is closed. From the spec, it looks like it is optional anyway. John From paul at msn.com Wed Nov 24 08:50:54 2004 From: paul at msn.com (Paul Bryson) Date: Wed, 24 Nov 2004 01:50:54 -0600 Subject: [Matroska-devel] Re: CodecPrivate for MPEG-1 and MPEG-2 video References: <20041116121014.GK5928@bunkus.org> <20041122221829.GH14213@bunkus.org> Message-ID: "John Cannon" wrote... > Paul Bryson wrote: > >> Does anyone have an issue with removing the [GOP] headers? Or at least >> making that an option? > > Actually, my code removes them. Yay! Don't know if it's pertinent, but I tried mpeg2mkv on an MPEG-1 video that I had, and it put the video and audio data together in a single track. I used TMPGEnc to separate the audio and video and then was able to mux the video into mkv and use mkvmerge to mux in the audio. The resulting file played fine in VLC. It didn't play in MPC, but that doesn't matter at this point I guess. Atamido From steve.lhomme at free.fr Thu Nov 25 10:38:09 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Thu, 25 Nov 2004 10:38:09 +0100 Subject: [Matroska-devel] RFC on implementing metadata-handling for per-chapter track-splitting on extraction In-Reply-To: <200411231818.23001.vegard_p@broadpark.no> References: <200411231818.23001.vegard_p@broadpark.no> Message-ID: <41A5A801.6080000@free.fr> Vegard Pettersen a ?crit : > What I am currently looking at, is extracting only parts of a matroska track, > and handling the metadata-modifications that this entails. Good. That's a basic goal a lot of ppl are looking for. > As an example, extracting specific CD-tracks for a flac-file with 13 tracks > requires modifications of the file-headers on output and so on. > Since I expect this to be required for other files than flacs, I'm wondering > if you have any views on how to implement this so as for it to be more easily > expandable to handling metadata for all filetypes. From what I understand you don't want _just_ to cut the binary file, but also make it playable :) For Matroska there is a lot of data to keep. You can have a basic view of what a Matroska file contain here : http://www.matroska.org/technical/diagram/ Further questions can take place here or on IRC :)