From slhomme at matroska.org Wed Sep 1 13:36:02 2010 From: slhomme at matroska.org (Steve Lhomme) Date: Wed, 1 Sep 2010 13:36:02 +0200 Subject: [Matroska-devel] TrackOperation Message-ID: Hello everyone, Following the recent discussions on 3D video in Matroska and the inclusion of S_DVBSUB, I combined the 2 issues into a single solution. There is now a new element in Matroska TrackOperation that allows defining a track as the "sum" of other tracks. http://www.matroska.org/technical/specs/index.html#TrackOperation This important that the TrackEnabled element is repected in the future, especially for S_DVBSUB as individual parts are not meant to be used separately. Here are basic examples of how the TrackOperation works: 3D video track #4 is the sum of planes from left = track #1 right = track #2 backgroundd = track #3 Track #4 TrackOperation Track3DCombine Track3DLeft = #1 Track3DRight = #2 Track3DBackground = #3 DVBSub track 4 is the sum of blocks from particular = track 1 (disabled) common = track 2 (disabled) Track #4 TrackOperation TrackJoinBlocks TrackJoin = #1 TrackJoin = #2 DVBSub track 5 is the sum of blocks from particular = track 3 (disabled) common = track 2 (disabled) Track #5 TrackOperation TrackJoinBlocks TrackJoin = #3 TrackJoin = #2 It's almost set in stone now. But comments are welcome. The next phase will be to produce files using these elements and have something to play them back... -------------- next part -------------- An HTML attachment was scrubbed... URL: From aurel at gnuage.org Wed Sep 1 17:41:46 2010 From: aurel at gnuage.org (Aurelien Jacobs) Date: Wed, 1 Sep 2010 17:41:46 +0200 Subject: [Matroska-devel] TrackOperation In-Reply-To: References: Message-ID: <20100901154146.GA11510@gnuage.org> On Wed, Sep 01, 2010 at 01:36:02PM +0200, Steve Lhomme wrote: > Hello everyone, > > Following the recent discussions on 3D video in Matroska and the inclusion > of S_DVBSUB, I combined the 2 issues into a single solution. There is now a > new element in Matroska TrackOperation that allows defining a track as the > "sum" of other tracks. > > http://www.matroska.org/technical/specs/index.html#TrackOperation For now, this is far too imprecise to be able to implement this in a muxer/demuxer. > DVBSub track 4 is the sum of blocks from > particular = track 1 (disabled) > common = track 2 (disabled) > > Track #4 > TrackOperation > TrackJoinBlocks > TrackJoin = #1 > TrackJoin = #2 > > DVBSub track 5 is the sum of blocks from > particular = track 3 (disabled) > common = track 2 (disabled) > > Track #5 > TrackOperation > TrackJoinBlocks > TrackJoin = #3 > TrackJoin = #2 IIUC a demuxer should not present Track #1 to #3 to the outer world at all. And it should present Track #4 and #5 as if they were normal track. But I have no idea what TrackJoinBlocks means. The description is: Contains the list of all tracks whose Blocks need to be combined to create this virtual track. But there is no definition of combined... It could mean to do a XOR between each bits of the 2 blocks from the 2 tracks (or any kind of mathematical operation). More realistically, it could mean to interleave block from the 2 tracks (in their order of appearance in the mkv bitstream ?). Or to pick one block from track #1 and one block from track #2 and concatenate them to generate one block of track #4 (in which order should they be concatenated ?). Is it required that the 2 tracks which are joined have the same number of blocks and that each block from Track #1 has a corresponding block in Track #2 with the exact same timestamp ? what should a demuxer do if it's not the case (non matching timestamp, which could be due to one block missing in one of the stream) ? So overall, you should describe precisely and in a non-ambiguous way how a demuxer is supposed to generate the "virtual" blocks of Track #4 including its timestamp and flags. Also, you should describe how to write a seeking index (Cueing Data) for such a Virtual Track which contains no Block by itself... Aurel From slhomme at matroska.org Wed Sep 1 18:18:36 2010 From: slhomme at matroska.org (Steve Lhomme) Date: Wed, 1 Sep 2010 18:18:36 +0200 Subject: [Matroska-devel] TrackOperation In-Reply-To: <20100901154146.GA11510@gnuage.org> References: <20100901154146.GA11510@gnuage.org> Message-ID: Yeah, but then you could say the say about every field in the Matroska specs. That's why there are the spec notes and I should probably put an entry in there too. To describe the points you are talking about, especially the cueing data, which I hadn't thought of yet. In the other hand I think "Join Blocks" is pretty self explanatory for anyone who has done a muxer/demuxer. Noone would ever had the idea of doing some binary operation on the content of frames that can only be understoof by the codec, which is not meant to be understood at the container level. So the only way to join blocks I can think of if that presenting each as if they came from track #4 or track #5. On Wed, Sep 1, 2010 at 5:41 PM, Aurelien Jacobs wrote: > On Wed, Sep 01, 2010 at 01:36:02PM +0200, Steve Lhomme wrote: > > Hello everyone, > > > > Following the recent discussions on 3D video in Matroska and the > inclusion > > of S_DVBSUB, I combined the 2 issues into a single solution. There is now > a > > new element in Matroska TrackOperation that allows defining a track as > the > > "sum" of other tracks. > > > > http://www.matroska.org/technical/specs/index.html#TrackOperation > > For now, this is far too imprecise to be able to implement this in a > muxer/demuxer. > > > DVBSub track 4 is the sum of blocks from > > particular = track 1 (disabled) > > common = track 2 (disabled) > > > > Track #4 > > TrackOperation > > TrackJoinBlocks > > TrackJoin = #1 > > TrackJoin = #2 > > > > DVBSub track 5 is the sum of blocks from > > particular = track 3 (disabled) > > common = track 2 (disabled) > > > > Track #5 > > TrackOperation > > TrackJoinBlocks > > TrackJoin = #3 > > TrackJoin = #2 > > IIUC a demuxer should not present Track #1 to #3 to the outer world at > all. And it should present Track #4 and #5 as if they were normal track. > But I have no idea what TrackJoinBlocks means. The description is: > Contains the list of all tracks whose Blocks need > to be combined to create this virtual track. > But there is no definition of combined... It could mean to do a XOR > between each bits of the 2 blocks from the 2 tracks (or any kind of > mathematical operation). > More realistically, it could mean to interleave block from the 2 tracks > (in their order of appearance in the mkv bitstream ?). Or to pick one > block from track #1 and one block from track #2 and concatenate them to > generate one block of track #4 (in which order should they be > concatenated ?). > Is it required that the 2 tracks which are joined have the same number > of blocks and that each block from Track #1 has a corresponding block > in Track #2 with the exact same timestamp ? what should a demuxer do if > it's not the case (non matching timestamp, which could be due to one > block missing in one of the stream) ? > > So overall, you should describe precisely and in a non-ambiguous way > how a demuxer is supposed to generate the "virtual" blocks of Track #4 > including its timestamp and flags. > > Also, you should describe how to write a seeking index (Cueing Data) for > such a Virtual Track which contains no Block by itself... > > Aurel > _______________________________________________ > Matroska-devel mailing list > Matroska-devel at lists.matroska.org > http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel > Read Matroska-Devel on GMane: > http://dir.gmane.org/gmane.comp.multimedia.matroska.devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From smeulf at hotmail.fr Wed Sep 1 20:09:42 2010 From: smeulf at hotmail.fr (Smeulf) Date: Wed, 1 Sep 2010 20:09:42 +0200 Subject: [Matroska-devel] and Tags -> Discution extend to chapters specs In-Reply-To: References: Message-ID: Hi Steve, Hi All, First, thanks for your answer. The real problem is this one : I've 1 video stream, 2 audio and 2 subtitles (one for each audio). The first audio is the movie, and the second is the director's comments. And I was looking for a way to have for a chapter (or an edition maybe...) one default sound track, and one default subtitle, diffrents of the mkv defaults. In my imagination, i'd like to have something like this : MKV : Default audio=audiotrack1 / default subs=none Edition (Chapter?) 1 : Default audio=audiotrack1 / default subs=subtrack3 Edition (Chapter?) 2 : Default audio=audiotrack2 / default subs=subtrack4 Is there an easy way to do this ? Should I use menues ? In this case have you got a kind of tutorial to do this ? If not, I've got some ideas I coul'd summit... Thakns again. From: Steve Lhomme Sent: Tuesday, August 31, 2010 8:56 PM To: Discussion about the current and future development of Matroska Subject: Re: [Matroska-devel] and Tags Tags are not meant to select anything during playback. They are meant to just describe the content. Chapters and Chapter codecs could do what you want. But there is currently nothing in the chapter codecs that can select a track if another is selected (if that's what you want to achieve). On Sat, Aug 28, 2010 at 12:35 AM, Moi Smeulf wrote: Hello, I was wondering if Haali Media Splitter for Windows supports and tags ? If yes, can someone explain me how it works, cause i really don't understant how to make a chapter to select a sp?cific audio track and a specific subtitle ? (Maybe it's not made for my goal...) Thanks in advance. _______________________________________________ Matroska-devel mailing list Matroska-devel at lists.matroska.org http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel Read Matroska-Devel on GMane: http://dir.gmane.org/gmane.comp.multimedia.matroska.devel -------------------------------------------------------------------------------- _______________________________________________ Matroska-devel mailing list Matroska-devel at lists.matroska.org http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel Read Matroska-Devel on GMane: http://dir.gmane.org/gmane.comp.multimedia.matroska.devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From aurel at gnuage.org Thu Sep 2 01:04:32 2010 From: aurel at gnuage.org (Aurelien Jacobs) Date: Thu, 2 Sep 2010 01:04:32 +0200 Subject: [Matroska-devel] TrackOperation In-Reply-To: References: <20100901154146.GA11510@gnuage.org> Message-ID: <20100901230432.GA13904@gnuage.org> On Wed, Sep 01, 2010 at 06:18:36PM +0200, Steve Lhomme wrote: > Yeah, but then you could say the say about every field in the Matroska > specs. That's why there are the spec notes and I should probably put an > entry in there too. To describe the points you are talking about, especially > the cueing data, which I hadn't thought of yet. > > In the other hand I think "Join Blocks" is pretty self explanatory for > anyone who has done a muxer/demuxer. I wrote several muxer/demuxer... Still "Join Blocks" is far from self explanatory. > Noone would ever had the idea of doing > some binary operation on the content of frames that can only be understoof > by the codec, which is not meant to be understood at the container level. Well, yes. This was just a dumb idea of how this could be misinterpreted at the extrem... Nothing to be taken seriously. > So the only way to join blocks I can think of if that presenting each as if > they came from track #4 or track #5. So you mean just interleaving blocks from Track #1 and #2 in the order they appear in the stream ? If so, the word "join" is rather misleading as you never actually join 2 blocks together into one. You just interleave blocks from 2 tracks. And if interleaving was what you meant, you will need to explain how the demuxer is supposed handle 2 blocks from 2 tracks having the same timestamp. The decoder won't be able to present 2 different frames at the same presentation timestamp. Aurel From slhomme at matroska.org Thu Sep 2 08:13:29 2010 From: slhomme at matroska.org (Steve Lhomme) Date: Thu, 2 Sep 2010 08:13:29 +0200 Subject: [Matroska-devel] TrackOperation In-Reply-To: <20100901230432.GA13904@gnuage.org> References: <20100901154146.GA11510@gnuage.org> <20100901230432.GA13904@gnuage.org> Message-ID: On Thu, Sep 2, 2010 at 1:04 AM, Aurelien Jacobs wrote: > On Wed, Sep 01, 2010 at 06:18:36PM +0200, Steve Lhomme wrote: > > So the only way to join blocks I can think of if that presenting each as > if > > they came from track #4 or track #5. > > So you mean just interleaving blocks from Track #1 and #2 in the order > they appear in the stream ? If so, the word "join" is rather misleading > as you never actually join 2 blocks together into one. You just > interleave blocks from 2 tracks. > So you propose TrackInterleaveBlocks instead of TrackJoinBlocks ? I can do that. > And if interleaving was what you meant, you will need to explain how the > demuxer is supposed handle 2 blocks from 2 tracks having the same > timestamp. The decoder won't be able to present 2 different frames at > the same presentation timestamp. I think the best thing would be to drop frames that overlap the one already displayed. That would probably be a little tricky depending on how the synchronisation and buffering works. So while it's a recommandation, it's hard to enforce it. I don't think people will use TrackInterleaveBlocks with anything other than subtitles though. If they really want 2 overlapping tracks to play together, that should be up to the player to allow more than one kind of track to play at once (audio and audio commentary for example). But wether it is for audio or video it's very not practical. Still, overlapping subs could suck to read as well and not be supported by the rendering system. So I say, whoever comes first gets the display. The same problem exist for one subs track where the duration is set incorrectly and can overlap with the previous frame. In that case the new frame should replace the previous one. On the Cues, it's the same thing: they should be "interleaved" to create the one for the virtual track. Although it's rare to have Cues for subs channels and to use these for the seeking in the file. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dk-moisbink at rambler.ru Fri Sep 3 15:25:09 2010 From: dk-moisbink at rambler.ru (=?windows-1251?B?yuXy7uXiIMzg8ODy?=) Date: Fri, 03 Sep 2010 17:25:09 +0400 Subject: [Matroska-devel] Need help Message-ID: <153340919.1283520309.131448536.46520@mcgi-wr-4.rambler.ru> Hello, I write a program video converter, it is based on the DirectShow filters precisely to Haali Media Splitter and ffdshow issue where I can find out their COM interfaces so that I can customize them, from their program and not from the registry From slhomme at matroska.org Sun Sep 5 10:38:14 2010 From: slhomme at matroska.org (Steve Lhomme) Date: Sun, 5 Sep 2010 10:38:14 +0200 Subject: [Matroska-devel] TrackOperation In-Reply-To: References: Message-ID: I modified the system for the 3D tracks so that each track can be defined with more details. Here is how it works: 3D video track #4 is the sum of planes from left = track #1 right = track #2 backgroundd = track #3 Track #4 TrackOperation Track3DCombine TrackPlane TrackPlaneUID = #1 TrackPlaneType = 0 (left eye) TrackPlane TrackPlaneUID = #2 TrackPlaneType = 1 (right eye) TrackPlane TrackPlaneUID = #3 TrackPlaneType = 3 (background eye) I will also add some more information on how it's all supposed to work in the Specification Notes page. http://www.matroska.org/technical/specs/notes.html On Wed, Sep 1, 2010 at 1:36 PM, Steve Lhomme wrote: > Hello everyone, > > Following the recent discussions on 3D video in Matroska and the inclusion > of S_DVBSUB, I combined the 2 issues into a single solution. There is now a > new element in Matroska TrackOperation that allows defining a track as the > "sum" of other tracks. > > http://www.matroska.org/technical/specs/index.html#TrackOperation > > This important that the TrackEnabled element is repected in the future, > especially for S_DVBSUB as individual parts are not meant to be used > separately. > > Here are basic examples of how the TrackOperation works: > > 3D video track #4 is the sum of planes from > left = track #1 > right = track #2 > backgroundd = track #3 > > Track #4 > TrackOperation > Track3DCombine > Track3DLeft = #1 > Track3DRight = #2 > Track3DBackground = #3 > > > > DVBSub track 4 is the sum of blocks from > particular = track 1 (disabled) > common = track 2 (disabled) > > Track #4 > TrackOperation > TrackJoinBlocks > TrackJoin = #1 > TrackJoin = #2 > > DVBSub track 5 is the sum of blocks from > particular = track 3 (disabled) > common = track 2 (disabled) > > Track #5 > TrackOperation > TrackJoinBlocks > TrackJoin = #3 > TrackJoin = #2 > > It's almost set in stone now. But comments are welcome. > > The next phase will be to produce files using these elements and have > something to play them back... > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aurel at gnuage.org Sun Sep 5 23:56:09 2010 From: aurel at gnuage.org (Aurelien Jacobs) Date: Sun, 5 Sep 2010 23:56:09 +0200 Subject: [Matroska-devel] TrackOperation In-Reply-To: References: <20100901154146.GA11510@gnuage.org> <20100901230432.GA13904@gnuage.org> Message-ID: <20100905215608.GA12849@gnuage.org> On Thu, Sep 02, 2010 at 08:13:29AM +0200, Steve Lhomme wrote: > On Thu, Sep 2, 2010 at 1:04 AM, Aurelien Jacobs wrote: > > > On Wed, Sep 01, 2010 at 06:18:36PM +0200, Steve Lhomme wrote: > > > So the only way to join blocks I can think of if that presenting each as > > if > > > they came from track #4 or track #5. > > > > So you mean just interleaving blocks from Track #1 and #2 in the order > > they appear in the stream ? If so, the word "join" is rather misleading > > as you never actually join 2 blocks together into one. You just > > interleave blocks from 2 tracks. > > > > So you propose TrackInterleaveBlocks instead of TrackJoinBlocks ? I can do > that. Well, "interleave" is just the first word which came to my mind. I don't know if it's the best word for this, but at least it sounds more descriptive than "join". So yes, TrackInterleaveBlocks sounds better to me. But it might be possible to find even better... > On the Cues, it's the same thing: they should be "interleaved" to create the > one for the virtual track. If blocks are simply interleaved, yes this sounds quite obvious (but still need to be written explicitely). > Although it's rare to have Cues for subs channels > and to use these for the seeking in the file. Nothing in the spec is restricting TrackInterleaveBlocks to subtitles, so a demuxer can't make any assumption about this. Aurel From aurel at gnuage.org Sun Sep 5 23:58:45 2010 From: aurel at gnuage.org (Aurelien Jacobs) Date: Sun, 5 Sep 2010 23:58:45 +0200 Subject: [Matroska-devel] test4.mkv looks invalid Message-ID: <20100905215845.GB12849@gnuage.org> Hi, I was trying to demux test4.mkv from the matroska_test_w1 test suite [1], and I just can't figure out how it is supposed to be demuxed. mkvalidator says this file is valid, but it really looks broken to me. Here is what I found out. This file has a perfectly valid and straightforward EBML Header. Then at offset 0x18 starts a Segment (18 53 80 67) followed by its size (FF, which means unknow size, which is totally expected since this file was created with the --live option). Then I expect to read an element ID, but instead, I read a long serie of 0x0A. This is quite invalid, as this means a 5 bytes element ID, while maximum is supposed to be 4 bytes. But even if I consider 5 bytes element ID OK, and treat it as an unknown element, the element length would then be *huge* and I would thus skip the rest of the file. If I overwrite the first 3 0x0A bytes with a Void element (EC 40 83), the file suddenly looks perfectly valid an playable. So I really wonder what this 0x0A serie is supposed the mean, and if there is a valid way to parse it according to the spec, or if it is just invalid ? Aurel [1] http://sourceforge.net/projects/matroska/files/test_files/matroska_test_w1.zip/download From slhomme at matroska.org Mon Sep 6 08:09:22 2010 From: slhomme at matroska.org (Steve Lhomme) Date: Mon, 6 Sep 2010 08:09:22 +0200 Subject: [Matroska-devel] test4.mkv looks invalid In-Reply-To: <20100905215845.GB12849@gnuage.org> References: <20100905215845.GB12849@gnuage.org> Message-ID: This file is similar to the first captures I got from a GStreamer (webm) server. They may have changed it, but I don't think so. The idea of a live stream is that the encoder keeps encoding and producing Clusters and whenever a client connects the EBML/Matroska header is first send and then the Clusters. But the server is unlikely to know the Cluster boundary (more work for the server for each opening connection, which can be a lot for a thousands of client). So it may start sending the end of the previously started Cluster. This is a stretch on the specs and is considered OK for the "live" mode of Matroska, because it makes server a lot easier to make. To parse such a file you should handle the EBML/Matroska head and then look for the 4 bytes of a Cluster. libebml and libebml2 can handle that. They may detect false Void elements in the stream (global elements) but there is also a size detection to avoid false alarms and one way or another it always end up finding the valid Cluster. This is the same system that needs to be used in any Matroska demuxer to handle damaged files without much troubles anyway. On Sun, Sep 5, 2010 at 11:58 PM, Aurelien Jacobs wrote: > Hi, > > I was trying to demux test4.mkv from the matroska_test_w1 test suite [1], > and I just can't figure out how it is supposed to be demuxed. mkvalidator > says this file is valid, but it really looks broken to me. > > Here is what I found out. > This file has a perfectly valid and straightforward EBML Header. > Then at offset 0x18 starts a Segment (18 53 80 67) followed by its size > (FF, which means unknow size, which is totally expected since this file > was created with the --live option). > Then I expect to read an element ID, but instead, I read a long serie of > 0x0A. This is quite invalid, as this means a 5 bytes element ID, while > maximum is supposed to be 4 bytes. But even if I consider 5 bytes element > ID OK, and treat it as an unknown element, the element length would then > be *huge* and I would thus skip the rest of the file. > > If I overwrite the first 3 0x0A bytes with a Void element (EC 40 83), > the file suddenly looks perfectly valid an playable. > > So I really wonder what this 0x0A serie is supposed the mean, and if > there is a valid way to parse it according to the spec, or if it is just > invalid ? > > Aurel > > [1] > http://sourceforge.net/projects/matroska/files/test_files/matroska_test_w1.zip/download > _______________________________________________ > Matroska-devel mailing list > Matroska-devel at lists.matroska.org > http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel > Read Matroska-Devel on GMane: > http://dir.gmane.org/gmane.comp.multimedia.matroska.devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From slhomme at matroska.org Mon Sep 6 08:42:26 2010 From: slhomme at matroska.org (Steve Lhomme) Date: Mon, 6 Sep 2010 08:42:26 +0200 Subject: [Matroska-devel] TrackOperation In-Reply-To: <20100905215608.GA12849@gnuage.org> References: <20100901154146.GA11510@gnuage.org> <20100901230432.GA13904@gnuage.org> <20100905215608.GA12849@gnuage.org> Message-ID: Aurelien, I updated the specs and also added a paragraph about the whole TrackOperation thing in the specification notes. That should cover all you have said. On Sun, Sep 5, 2010 at 11:56 PM, Aurelien Jacobs wrote: > On Thu, Sep 02, 2010 at 08:13:29AM +0200, Steve Lhomme wrote: > > On Thu, Sep 2, 2010 at 1:04 AM, Aurelien Jacobs > wrote: > > > > > On Wed, Sep 01, 2010 at 06:18:36PM +0200, Steve Lhomme wrote: > > > > So the only way to join blocks I can think of if that presenting each > as > > > if > > > > they came from track #4 or track #5. > > > > > > So you mean just interleaving blocks from Track #1 and #2 in the order > > > they appear in the stream ? If so, the word "join" is rather misleading > > > as you never actually join 2 blocks together into one. You just > > > interleave blocks from 2 tracks. > > > > > > > So you propose TrackInterleaveBlocks instead of TrackJoinBlocks ? I can > do > > that. > > Well, "interleave" is just the first word which came to my mind. I don't > know if it's the best word for this, but at least it sounds more > descriptive than "join". > So yes, TrackInterleaveBlocks sounds better to me. But it might be > possible to find even better... > > > On the Cues, it's the same thing: they should be "interleaved" to create > the > > one for the virtual track. > > If blocks are simply interleaved, yes this sounds quite obvious (but > still need to be written explicitely). > > > Although it's rare to have Cues for subs channels > > and to use these for the seeking in the file. > > Nothing in the spec is restricting TrackInterleaveBlocks to subtitles, > so a demuxer can't make any assumption about this. > > Aurel > _______________________________________________ > Matroska-devel mailing list > Matroska-devel at lists.matroska.org > http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel > Read Matroska-Devel on GMane: > http://dir.gmane.org/gmane.comp.multimedia.matroska.devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From moritz at bunkus.org Mon Sep 6 09:03:46 2010 From: moritz at bunkus.org (Moritz Bunkus) Date: Mon, 6 Sep 2010 09:03:46 +0200 Subject: [Matroska-devel] test4.mkv looks invalid In-Reply-To: References: <20100905215845.GB12849@gnuage.org> Message-ID: <201009060903.49470.moritz@bunkus.org> Hey, with all due respect I think Aurel has a point. He isn't talking about the cluster having an unknown size as being problematic, not at all. He's talking about a series of random bytes after a valid element header, in this case 0x0a. If it were 0x00 I would somehow understand that you'd argue that these should be considered "normal junk" or something like that, but not on 0x0a. The specs don't talk about stuffing bytes at all. So a spec compliant reader would see 0x0a, interpret it just as Aurel said ("read EBML ID. 0x0a = five bytes ID length => more than 4 bytes => invalid sequence, fall back to 'scan for next known ID mode'"). This would be a spec compliant reader, but I hardly call such a file valid or spec compliant. You could say that any player playing such a file would get bonus points for being error resilient, but you cannot make it a prerequisite for passing spec compliance tests. Regards, Mosu -- If Darl McBride was in charge, he'd probably make marriage unconstitutional too, since clearly it de-emphasizes the commercial nature of normal human interaction, and probably is a major impediment to the commercial growth of prostitution. - Linus Torvalds -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From slhomme at matroska.org Mon Sep 6 13:08:18 2010 From: slhomme at matroska.org (Steve Lhomme) Date: Mon, 6 Sep 2010 13:08:18 +0200 Subject: [Matroska-devel] test4.mkv looks invalid In-Reply-To: <201009060903.49470.moritz@bunkus.org> References: <20100905215845.GB12849@gnuage.org> <201009060903.49470.moritz@bunkus.org> Message-ID: Hi, First, do we all agree that it's a feature that is made to simplify Matroska live servers ? If you understand that part, you understand why there is some junk. I understand it would be nicer if the server was making sure it would start sending data at a Cluster boundary, but that means it needs a little more intelligence and it seems it's not the common thing to do for live servers. So taking that in account, I made sure someone who is serious about supporting live streaming know about this issue. First I wanted to use truly random data, but it would create too many possible false alarms and different files at each run of mkclean --live. So I use 0x0A which is an invalid EBML ID (limited to 4 bytes in size) and so all the 0x0A should be discarded no matter what. It's actually easier on the Matroska parser than if the data were truly random. Also it's a good test file to test error resilience of the parser too (or skipping unknown data). I could make different test files for each particular aspect of Matroska files that need to be tested, but it's a lot more work, time, space, so I combine a few features per file. On Mon, Sep 6, 2010 at 9:03 AM, Moritz Bunkus wrote: > Hey, > > with all due respect I think Aurel has a point. He isn't talking about > the cluster having an unknown size as being problematic, not at > all. He's talking about a series of random bytes after a valid element > header, in this case 0x0a. If it were 0x00 I would somehow understand > that you'd argue that these should be considered "normal junk" or > something like that, but not on 0x0a. > > The specs don't talk about stuffing bytes at all. So a spec compliant > reader would see 0x0a, interpret it just as Aurel said ("read EBML > ID. 0x0a = five bytes ID length => more than 4 bytes => invalid > sequence, fall back to 'scan for next known ID mode'"). This would be a > spec compliant reader, but I hardly call such a file valid or spec > compliant. > > You could say that any player playing such a file would get bonus points > for being error resilient, but you cannot make it a prerequisite for > passing spec compliance tests. > > Regards, > 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 > > _______________________________________________ > Matroska-devel mailing list > Matroska-devel at lists.matroska.org > http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel > Read Matroska-Devel on GMane: > http://dir.gmane.org/gmane.comp.multimedia.matroska.devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From slhomme at matroska.org Mon Sep 13 13:51:17 2010 From: slhomme at matroska.org (Steve Lhomme) Date: Mon, 13 Sep 2010 13:51:17 +0200 Subject: [Matroska-devel] TrackOperation In-Reply-To: References: Message-ID: If you mean the way planes are combined into 2 (side by side, top bottom, etc), I just added it to StereoMode and more explanations here: http://www.matroska.org/technical/specs/notes.html#3D http://www.matroska.org/technical/specs/index.html# StereoMode I think that Matroska now covers all the cases I've been presented. I'll leave you a few more days to comment and then I will consider this final and make a more formal announcement. Then we can start making samples and find a player that can handle them... On Thu, Sep 2, 2010 at 8:21 PM, Alok Ahuja wrote: > Hi Steve, > > Thank you for this spec. Will you also be doing an update to the 3D Spec to > include the source and render modes as we had previously discussed? > > Regards, > Alok > > > On Wed, Sep 1, 2010 at 4:36 AM, Steve Lhomme wrote: > >> Hello everyone, >> >> Following the recent discussions on 3D video in Matroska and the inclusion >> of S_DVBSUB, I combined the 2 issues into a single solution. There is now a >> new element in Matroska TrackOperation that allows defining a track as the >> "sum" of other tracks. >> >> http://www.matroska.org/technical/specs/index.html#TrackOperation >> >> This important that the TrackEnabled element is repected in the future, >> especially for S_DVBSUB as individual parts are not meant to be used >> separately. >> >> Here are basic examples of how the TrackOperation works: >> >> 3D video track #4 is the sum of planes from >> left = track #1 >> right = track #2 >> backgroundd = track #3 >> >> Track #4 >> TrackOperation >> Track3DCombine >> Track3DLeft = #1 >> Track3DRight = #2 >> Track3DBackground = #3 >> >> >> >> DVBSub track 4 is the sum of blocks from >> particular = track 1 (disabled) >> common = track 2 (disabled) >> >> Track #4 >> TrackOperation >> TrackJoinBlocks >> TrackJoin = #1 >> TrackJoin = #2 >> >> DVBSub track 5 is the sum of blocks from >> particular = track 3 (disabled) >> common = track 2 (disabled) >> >> Track #5 >> TrackOperation >> TrackJoinBlocks >> TrackJoin = #3 >> TrackJoin = #2 >> >> It's almost set in stone now. But comments are welcome. >> >> The next phase will be to produce files using these elements and have >> something to play them back... >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From slhomme at matroska.org Mon Sep 13 21:52:15 2010 From: slhomme at matroska.org (Steve Lhomme) Date: Mon, 13 Sep 2010 21:52:15 +0200 Subject: [Matroska-devel] libmatroska 1.0.0: KaxBlockData memory leak In-Reply-To: References: Message-ID: Hi Vadim, Please send such emails to the mailing list. Your fix is not correct. As you only cover one case of SetReferencedBlock() when the other one is used, you are going to release memory that is owned by someone else. Maybe you are not using this case, but it is used a lot elsewhere. I will investigate why my crash fixes when I have time. On Fri, Sep 10, 2010 at 1:56 PM, Vadim Golopupov wrote: > I tried your files. You didn't fix the bug, you made critical bug. I have > error: > > Unhandled exception at 0x005506e3 in p.exe: 0xC0000005: Access violation > reading location 0xfeeefeee. > > ~KaxBlockBlob() { > #if MATROSKA_VERSION >= 2 > if (bUseSimpleBlock) > delete Block.simpleblock; > else > #endif // MATROSKA_VERSION > delete Block.group; <-- PROBLEM HERE > } > > I think you should make changes only which i send with mail to you. > > 2010/9/10 Steve Lhomme > > I think I fixed it in SVN. >> Please next time send your email to the dev mailing list. There are more >> chances you'll have some comments and support from other people using the v1 >> libs. >> >> And thanks for reporting the bug :) >> >> Steve >> >> >> On Fri, Sep 3, 2010 at 10:11 PM, Vadim Golopupov wrote: >> >>> libmatroska 1.0.0 - The memory leak happens if you add frame with >>> Future/Past Reference. >>> >>> Here is the function from the KaxBlockData.cpp: >>> >>> void KaxReferenceBlock::SetReferencedBlock(const KaxBlockGroup & >>> aRefdBlock) >>> { >>> KaxBlockBlob *block_blob = new KaxBlockBlob(BLOCK_BLOB_NO_SIMPLE); >>> block_blob->SetBlockGroup(*const_cast(&aRefdBlock)); >>> RefdBlock = block_blob; >>> SetValueIsSet(); >>> } >>> >>> >>> KaxBlockBlob *block_blob = new KaxBlockBlob(BLOCK_BLOB_NO_SIMPLE); <- >>> this memory will never be free. >>> >>> To free this memory you need make changes in KaxBlockData.h: >>> >>> ~KaxReferenceBlock() >>> { >>> if (RefdBlock) { >>> delete RefdBlock; >>> RefdBlock = 0; >>> } >>> } >>> >>> >>> >> > > > -- > Vadim Golopupov > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From iwanmail at o2.pl Wed Sep 15 18:05:53 2010 From: iwanmail at o2.pl (=?UTF-8?Q?iwanmail?=) Date: Wed, 15 Sep 2010 18:05:53 +0200 Subject: [Matroska-devel] =?utf-8?q?Feature_Request_/_Bug_Report_/_Haali_M?= =?utf-8?q?edia_Splitter_-_amount_of_tracks_limited=3F?= Message-ID: <67555911.e887852.4c90eee1.5badd@o2.pl> //versions MKVmerge: 4.3.0 Haali Media Splitter: 1.10.262.12 (14/08/2010) mpc-hc: 1.4.2499.0 //source AVC 1080p High at L4.1 x264 core 92 r1510 33d382a @13.3Mbs Recently, I tried to mux the above source with 2 audio tracks (DTS at 1500 and AC3 at 448) and 33 subtitle tracks (2 SubRip text subs and 31 FullHD SUP/PGS bitmap subs). After muxing I encountered a little problem: Haali Media Splitter (SysTray) read only 32 tracks out of total 36. 4 sub tracks were gone even in mpc-hc > right-click > navigate > subtitle lang. When opening in mpc the movie doesn't start and stays at 00:00 as if it was unable to cooperate with Haali due to exceeded amount of tracks (2^5 (sic!)). But when I seek at least once the movie plays. This is unacceptable while mkvmerge lets mux more than 32 tracks. Also VLC can read more than 32 tracks. Can it be something done with this disadvantage? By iwanmail at o2.pl From pierre30 at gmail.com Wed Sep 15 20:10:52 2010 From: pierre30 at gmail.com (Pierre) Date: Wed, 15 Sep 2010 18:10:52 +0000 (UTC) Subject: [Matroska-devel] Pause/resume problem with Winamp and Haali Media Splitter Message-ID: Hello, That is the first time I post a message so I hope I do it correctly. First of all thank you for your splitter. I'm using Haali Media Splitter with Winamp to play matroska files. I noticed what it seems to be an incompatibility between the two since the 20/05/2010 version. The problem is as follows. I watch a mkv movie (h264+mp3 or XviD+mp3) in Winamp then I pause and very often when I resume the playback restarts at the time where it begins before (begining of the movie or seeking place if moving into the file). The problem was not there with earlier versions (27/03/2010 and before). I tried with Media Player Classic with the latest versions of Haali Media Splitter but all is fine. When I pause it resumes at the same place. I think the problem comes from a change made between 27/03/2010 and 20/05/2010. I don't know if I am alone in the case. Maybe it's a problem of configuration or a bug in Winamp but it's strange that with version 27/03/2010 it works fine and with version of 20/05/2010 I begin to experience problems. I hope I was clear enough and you could fix this for future releases or give me a solution. Best regards. From jalanmanish at gmail.com Thu Sep 16 15:08:37 2010 From: jalanmanish at gmail.com (Manish Jalan) Date: Thu, 16 Sep 2010 18:38:37 +0530 Subject: [Matroska-devel] Crash in splitter.ax on Windows XP Vista and 7 Message-ID: Hello, Haali is a great splitter for Windows. It enables media playback in WMP especially for non MS media types like mp4. Sometimes we have observed crashes in splitter.ax on Windows XP, Vista as well as 7 while playing mp4 files. Our observation suggests that the crash occurs whenever the user has made a seek request. One example is when user drags the media tracker to change position of the video. Another example is when the media position is changed periodically to simulate fast forward or rewind motion. If some one could investigate the problem based on our observation, that would be of great help. We have a great splitter at our hands. Just need to make it more reliable. Regards, Manish S. Jalan -------------- next part -------------- An HTML attachment was scrubbed... URL: From slhomme at matroska.org Sun Sep 19 17:05:36 2010 From: slhomme at matroska.org (Steve Lhomme) Date: Sun, 19 Sep 2010 17:05:36 +0200 Subject: [Matroska-devel] Misc News Message-ID: It has been a while since I emailed about what's going on in the Matroska world. I often put news [1] on the website and even more often on Twitter [2]. But there may be some of view who don't follow these channels. So here is a recap of what has happened lately. The biggest and most important news of all is the suite of 8 test files [3] we produced. They are made to test players for correct Matroska compatibility/scalability. Make sure you test your devices and let us know what you find out. It's also important to let the manufacturer know where there are issues so they can fix them early in the product life (deprecated products won't be updated and you will not be able to play some perfectly valid Matroska files in the future). We now have 3D support in the specs via the StereoMode and TrackOperation fields. Check in the specifications [4] and the specification notes [5] for more details. There is currently no tools to make such files, or even play them. We are going to work on that in the coming weeks, especially in mkvmerge and VLC. There is a new guideline for cover art [6] in Matroska as there has been many demands and everyone seems to be doing their own incompatible thing. So now people have some rules of what they should expect from Matroska files and how they should put their cover arts in there. The order guideline [7] changed a little recently by recommending to put attachments at the front of the file. This is better for fonts and for cover art. mkclean and mkvalidator are progressing nicely and produce good result. But they are still consider beta tools until they reach version 1.0.0. This is the same with libebml2/libmatroska2 on which these tools are based. The internal code can change here and there before it's considered stable. It shouldn't be long anymore as there aren't so many things left to be done for version 1.0.0. [1] http://www.matroska.org/news/index.html [2] http://twitter.com/MatroskaOrg [3] http://www.matroska.org/downloads/test_w1.html [4] http://www.matroska.org/technical/specs/index.html [5] http://www.matroska.org/technical/specs/notes.html#3D [6] http://www.matroska.org/technical/cover_art/index.html [7] http://www.matroska.org/technical/order/index.html From Shailesh.Shah at harmonicinc.com Tue Sep 21 03:07:37 2010 From: Shailesh.Shah at harmonicinc.com (Shailesh Shah) Date: Mon, 20 Sep 2010 18:07:37 -0700 Subject: [Matroska-devel] Hi Message-ID: <614EA5F28EEB044B9F1C618FD5D3662959231E7681@EXCH-CMS.hlit.local> Hello, I am going to work on to support Matroska format in our product and was wondering if I can be part of the email list. Thx -------------- next part -------------- An HTML attachment was scrubbed... URL: From slhomme at matroska.org Tue Sep 21 14:04:22 2010 From: slhomme at matroska.org (Steve Lhomme) Date: Tue, 21 Sep 2010 14:04:22 +0200 Subject: [Matroska-devel] Hi In-Reply-To: <614EA5F28EEB044B9F1C618FD5D3662959231E7681@EXCH-CMS.hlit.local> References: <614EA5F28EEB044B9F1C618FD5D3662959231E7681@EXCH-CMS.hlit.local> Message-ID: Of course, subscribing to our mailing lists is free. And talking is free too. On Tue, Sep 21, 2010 at 3:07 AM, Shailesh Shah wrote: > Hello, > > > > I am going to work on to support Matroska format in our product and was > wondering if I can be part of the email list. > > > > Thx > > _______________________________________________ > Matroska-devel mailing list > Matroska-devel at lists.matroska.org > http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel > Read Matroska-Devel on GMane: > http://dir.gmane.org/gmane.comp.multimedia.matroska.devel > From chymmylt at hotmail.com Wed Sep 22 10:36:57 2010 From: chymmylt at hotmail.com (Chymmylt Bwoid) Date: Wed, 22 Sep 2010 04:36:57 -0400 Subject: [Matroska-devel] Chapters and Subtitles from MP4 files. Message-ID: The Haali Media Splitter works great for almost everything I need. The one place it falls short for me is with MP4's with embedded subtitles and chapters. It splits them out fine from MKV files but with MP4s the only option it gives for me is selecting audio track (or it would appear video track though I've never tried to embed multiple video tracks in a file?). Am I missing something basic or is there ANYWAY possible this could be added as a feature. I encoded my entire DVD collection in MP4 format (800+ movies) and it would be a major P.I.T.A. to go back and redo all this just to enable this functionality and I suspect I am far from the only person who would like this ability. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mladen.ninic at dotpulse.ch Wed Sep 29 14:53:30 2010 From: mladen.ninic at dotpulse.ch (Mladen Ninic) Date: Wed, 29 Sep 2010 14:53:30 +0200 Subject: [Matroska-devel] Hello I have a Question about Matroska Message-ID: Hello this is Mladen, I have an little question about Matroska, it is possible to play dis file format on a Website, when yes how can I do this ? When not, can I convert this fileformat to *.flv on a Server. Thans Regrades ________________________________________________________________________ Mladen Ninic IT DotPulse Web-Agentur AG Hardstrasse 219 8037 Z?rich Fon: +41 (0) 44 277 71 21 Fax : +41 (0) 44 277 71 12 http://www.dotpulse.ch mailto:mladen.ninic at dotpulse.ch ________________________________________________________________________ Diese Mitteilung erfolgt vertraulich und nur zum Gebrauch durch den oder die Adressaten. Sie kann durch das gesetzliche Berufs-, Amts- oder Gesch?ftsgeheimnis gesch?tzte Informationen enthalten. Sollte sie irrt?mlich an Sie erfolgt sein, d?rfen Sie die erhaltenen Informationen weder nutzen noch offen legen. Bitte benachrichtigen Sie uns gegebenenfalls telefonisch oder mit Antwort-Mail (info at dotpulse.ch) und l?schen Sie diese Nachricht und alle Anh?nge dazu unverz?glich. Besten Dank. -------------- next part -------------- An HTML attachment was scrubbed... URL: From surf.uk at gmail.com Wed Sep 29 15:15:54 2010 From: surf.uk at gmail.com (ross cuthbertson) Date: Wed, 29 Sep 2010 14:15:54 +0100 Subject: [Matroska-devel] matroska container makes playback stutter Message-ID: I have more problems with Matroska than another container format. Below is a sample based on a 640x360 24fps 5sec clip. Although I have more problems on 1080p resolutions. The encoder I'm using: FFmpeg version SVN-r24323, Copyright (c) 2000-2010 the FFmpeg developers built on Jul 19 2010 10:58:48 with gcc 4.4.3 configuration: --enable-gpl --enable-version3 --enable-nonfree --enable-postproc --enable-pthreads --enable-libfaac --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libtheora --enable-libvorbis --enable-libvpx --enable-libx264 --enable-libxvid --enable-x11grab --enable-runtime-cpudetect --enable-zlib --enable-libdirac --enable-libschroedinger --enable-vdpau libavutil 50.22. 0 / 50.22. 0 libavcodec 52.84. 0 / 52.84. 0 libavformat 52.75. 0 / 52.75. 0 libavdevice 52. 2. 0 / 52. 2. 0 libavfilter 1.25. 1 / 1.25. 1 libswscale 0.11. 0 / 0.11. 0 libpostproc 51. 2. 0 / 51. 2. 0 This plays fine in ffplay: ffmpeg -i input.avi -vcodec libx264 -vpre medium -crf 20 no_stutter.mkv http://dl.dropbox.com/u/6743276/mkv_stutter/no_stutter_libx264.mkv This plays fine in ffplay: ffmpeg -i input.avi -vcodec libschroedinger -qscale 7 no_stutter_libschro.nut http://dl.dropbox.com/u/6743276/mkv_stutter/no_stutter_libschro.nut This stutters in ffplay, even though the above does not: ffmpeg -i input.avi -vcodec libschroedinger -qscale 7 stutter_libschro.mkv http://dl.dropbox.com/u/6743276/mkv_stutter/stutter_libschro.mkv The above seams to play ok in VLC but has lots of the following errors: ... [0x22a7240] main subpicture error: blending YUVA to I422 failed [0x22a7240] main subpicture error: blending YUVA to I422 failed [0x22a7240] main subpicture error: blending YUVA to I422 failed [0x22a7240] main subpicture error: blending YUVA to I422 failed [0x22a7240] main subpicture error: blending YUVA to I422 failed [0x22a7240] main subpicture error: blending YUVA to I422 failed [0x22a7240] main subpicture error: blending YUVA to I422 failed [0x22a7240] main subpicture error: blending YUVA to I422 failed [0x22a7240] main subpicture error: blending YUVA to I422 failed [0x22a7240] main subpicture error: blending YUVA to I422 failed [0x22a7240] main subpicture error: blending YUVA to I422 failed ... -------------- next part -------------- An HTML attachment was scrubbed... URL: From slhomme at matroska.org Wed Sep 29 20:31:50 2010 From: slhomme at matroska.org (Steve Lhomme) Date: Wed, 29 Sep 2010 20:31:50 +0200 Subject: [Matroska-devel] Hello I have a Question about Matroska In-Reply-To: References: Message-ID: It's technically possible to put a Matroska file on a web server and many video players will be able to read it without problems. Now if you mean inside a web page like Flash. This is currently not possible. But WebM can do that and it's the same as Matroska, just forcing the codecs to be VP8 and Vorbis. 2010/9/29 Mladen Ninic : > Hello this is Mladen, > > I have an little question about Matroska, it is possible to play dis file > format on a Website, when yes how can I do this ? > > When not, can I convert this fileformat to *.flv on a Server. > > Thans > > Regrades > ________________________________________________________________________ > > Mladen Ninic > IT > > DotPulse Web-Agentur AG > Hardstrasse 219 > 8037 Z?rich > > Fon: +41 (0) 44? 277 71 21 > Fax : +41 (0) 44 277 71 12 > > http://www.dotpulse.ch > mailto:mladen.ninic at dotpulse.ch > ________________________________________________________________________ > > Diese Mitteilung erfolgt vertraulich und nur zum Gebrauch durch den oder > die Adressaten. Sie kann durch das gesetzliche Berufs-, Amts- oder > Gesch?ftsgeheimnis gesch?tzte Informationen enthalten. Sollte sie > irrt?mlich an Sie erfolgt sein, d?rfen Sie die erhaltenen Informationen > weder nutzen noch offen legen. Bitte benachrichtigen Sie uns > gegebenenfalls telefonisch oder mit Antwort-Mail (info at dotpulse.ch) > und l?schen Sie diese Nachricht und alle Anh?nge dazu unverz?glich. > Besten Dank. > > _______________________________________________ > Matroska-devel mailing list > Matroska-devel at lists.matroska.org > http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel > Read Matroska-Devel on GMane: > http://dir.gmane.org/gmane.comp.multimedia.matroska.devel > From slhomme at matroska.org Wed Sep 29 20:50:22 2010 From: slhomme at matroska.org (Steve Lhomme) Date: Wed, 29 Sep 2010 20:50:22 +0200 Subject: [Matroska-devel] matroska container makes playback stutter In-Reply-To: References: Message-ID: And if you compare #1 and #3 the difference is the (obscure) codec. So the conclusion that the container is the problem is not exactly correct. I have no idea what that codec is. But maybe support for it in Matroska is just not well implemented in general. Now looking at the timecodes in mkvinfo I can see the problem: |+ Cluster | + Cluster timecode: 1.000s | + SimpleBlock (key, track number 1, 1 frame(s), timecode 1.000s = 00:00:01.000) | + Frame with size 9476 | + SimpleBlock (track number 1, 1 frame(s), timecode 0.875s = 00:00:00.875) | + Frame with size 1639 | + SimpleBlock (track number 1, 1 frame(s), timecode 0.917s = 00:00:00.917) | + Frame with size 2380 | + SimpleBlock (track number 1, 1 frame(s), timecode 0.958s = 00:00:00.958) | + Frame with size 2246 | + SimpleBlock (track number 1, 1 frame(s), timecode 1.167s = 00:00:01.167) | + Frame with size 8005 The codec seems to use B frames. After a key frame (1.000) you get past frames (0.875, 0.917, 0.958). Dunno how it's stored in NUT but maybe it has a different order or something that makes players happy about it. The file looks correct to me (and mkvalidator). So I suggest asking the VLC or FFmpeg developpers why this could produce stutter. Given the error given by VLC maybe the bitstream may be bogus, as a result of an incorrect muxing in FFmpeg. On Wed, Sep 29, 2010 at 3:15 PM, ross cuthbertson wrote: > I have more problems with Matroska than another container format. Below is a > sample based on a 640x360 24fps 5sec clip. Although I have more problems on > 1080p resolutions. > > The encoder I'm using: > > FFmpeg version SVN-r24323, Copyright (c) 2000-2010 the FFmpeg developers > ? built on Jul 19 2010 10:58:48 with gcc 4.4.3 > ? configuration: --enable-gpl --enable-version3 --enable-nonfree > --enable-postproc --enable-pthreads --enable-libfaac --enable-libmp3lame > --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libtheora > --enable-libvorbis --enable-libvpx --enable-libx264 --enable-libxvid > --enable-x11grab --enable-runtime-cpudetect --enable-zlib --enable-libdirac > --enable-libschroedinger --enable-vdpau > ? libavutil???? 50.22. 0 / 50.22. 0 > ? libavcodec??? 52.84. 0 / 52.84. 0 > ? libavformat?? 52.75. 0 / 52.75. 0 > ? libavdevice?? 52. 2. 0 / 52. 2. 0 > ? libavfilter??? 1.25. 1 /? 1.25. 1 > ? libswscale???? 0.11. 0 /? 0.11. 0 > ? libpostproc?? 51. 2. 0 / 51. 2. 0 > > > This plays fine in ffplay: > > ffmpeg -i input.avi -vcodec libx264 -vpre medium -crf 20 no_stutter.mkv > http://dl.dropbox.com/u/6743276/mkv_stutter/no_stutter_libx264.mkv > > > > This plays fine in ffplay: > > ffmpeg -i input.avi -vcodec libschroedinger -qscale 7 > no_stutter_libschro.nut > http://dl.dropbox.com/u/6743276/mkv_stutter/no_stutter_libschro.nut > > This stutters in ffplay, even though the above does not: > > ffmpeg -i input.avi -vcodec libschroedinger -qscale 7 stutter_libschro.mkv > http://dl.dropbox.com/u/6743276/mkv_stutter/stutter_libschro.mkv > > The above seams to play ok in VLC but has lots of the following errors: > > ... > [0x22a7240] main subpicture error: blending YUVA to I422 failed > [0x22a7240] main subpicture error: blending YUVA to I422 failed > [0x22a7240] main subpicture error: blending YUVA to I422 failed > [0x22a7240] main subpicture error: blending YUVA to I422 failed > [0x22a7240] main subpicture error: blending YUVA to I422 failed > [0x22a7240] main subpicture error: blending YUVA to I422 failed > [0x22a7240] main subpicture error: blending YUVA to I422 failed > [0x22a7240] main subpicture error: blending YUVA to I422 failed > [0x22a7240] main subpicture error: blending YUVA to I422 failed > [0x22a7240] main subpicture error: blending YUVA to I422 failed > [0x22a7240] main subpicture error: blending YUVA to I422 failed > ... > > _______________________________________________ > Matroska-devel mailing list > Matroska-devel at lists.matroska.org > http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel > Read Matroska-Devel on GMane: > http://dir.gmane.org/gmane.comp.multimedia.matroska.devel > From slhomme at matroska.org Wed Sep 29 20:56:50 2010 From: slhomme at matroska.org (Steve Lhomme) Date: Wed, 29 Sep 2010 20:56:50 +0200 Subject: [Matroska-devel] matroska container makes playback stutter In-Reply-To: References: Message-ID: Also I just played the 3 files in VLC and they play fine. I don't get any stutter. I have a strong machine, but I doubt one container can make decoding significantly slower than another. I see the same error in VLC for the NUT and the Matroska versions of the same file: [0x22a7240] main subpicture error: blending YUVA to I422 failed So that rules out this explaination why it stutters for you. On Wed, Sep 29, 2010 at 8:50 PM, Steve Lhomme wrote: > And if you compare #1 and #3 the difference is the (obscure) codec. So > the conclusion that the container is the problem is not exactly > correct. > > I have no idea what that codec is. But maybe support for it in > Matroska is just not well implemented in general. Now looking at the > timecodes in mkvinfo I can see the problem: > > |+ Cluster > | + Cluster timecode: 1.000s > | + SimpleBlock (key, track number 1, 1 frame(s), timecode 1.000s = > 00:00:01.000) > | ?+ Frame with size 9476 > | + SimpleBlock (track number 1, 1 frame(s), timecode 0.875s = 00:00:00.875) > | ?+ Frame with size 1639 > | + SimpleBlock (track number 1, 1 frame(s), timecode 0.917s = 00:00:00.917) > | ?+ Frame with size 2380 > | + SimpleBlock (track number 1, 1 frame(s), timecode 0.958s = 00:00:00.958) > | ?+ Frame with size 2246 > | + SimpleBlock (track number 1, 1 frame(s), timecode 1.167s = 00:00:01.167) > | ?+ Frame with size 8005 > > The codec seems to use B frames. After a key frame (1.000) you get > past frames (0.875, 0.917, 0.958). Dunno how it's stored in NUT but > maybe it has a different order or something that makes players happy > about it. The file looks correct to me (and mkvalidator). So I suggest > asking the VLC or FFmpeg developpers why this could produce stutter. > Given the error given by VLC maybe the bitstream may be bogus, as a > result of an incorrect muxing in FFmpeg. > > On Wed, Sep 29, 2010 at 3:15 PM, ross cuthbertson wrote: >> I have more problems with Matroska than another container format. Below is a >> sample based on a 640x360 24fps 5sec clip. Although I have more problems on >> 1080p resolutions. >> >> The encoder I'm using: >> >> FFmpeg version SVN-r24323, Copyright (c) 2000-2010 the FFmpeg developers >> ? built on Jul 19 2010 10:58:48 with gcc 4.4.3 >> ? configuration: --enable-gpl --enable-version3 --enable-nonfree >> --enable-postproc --enable-pthreads --enable-libfaac --enable-libmp3lame >> --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libtheora >> --enable-libvorbis --enable-libvpx --enable-libx264 --enable-libxvid >> --enable-x11grab --enable-runtime-cpudetect --enable-zlib --enable-libdirac >> --enable-libschroedinger --enable-vdpau >> ? libavutil???? 50.22. 0 / 50.22. 0 >> ? libavcodec??? 52.84. 0 / 52.84. 0 >> ? libavformat?? 52.75. 0 / 52.75. 0 >> ? libavdevice?? 52. 2. 0 / 52. 2. 0 >> ? libavfilter??? 1.25. 1 /? 1.25. 1 >> ? libswscale???? 0.11. 0 /? 0.11. 0 >> ? libpostproc?? 51. 2. 0 / 51. 2. 0 >> >> >> This plays fine in ffplay: >> >> ffmpeg -i input.avi -vcodec libx264 -vpre medium -crf 20 no_stutter.mkv >> http://dl.dropbox.com/u/6743276/mkv_stutter/no_stutter_libx264.mkv >> >> >> >> This plays fine in ffplay: >> >> ffmpeg -i input.avi -vcodec libschroedinger -qscale 7 >> no_stutter_libschro.nut >> http://dl.dropbox.com/u/6743276/mkv_stutter/no_stutter_libschro.nut >> >> This stutters in ffplay, even though the above does not: >> >> ffmpeg -i input.avi -vcodec libschroedinger -qscale 7 stutter_libschro.mkv >> http://dl.dropbox.com/u/6743276/mkv_stutter/stutter_libschro.mkv >> >> The above seams to play ok in VLC but has lots of the following errors: >> >> ... >> [0x22a7240] main subpicture error: blending YUVA to I422 failed >> [0x22a7240] main subpicture error: blending YUVA to I422 failed >> [0x22a7240] main subpicture error: blending YUVA to I422 failed >> [0x22a7240] main subpicture error: blending YUVA to I422 failed >> [0x22a7240] main subpicture error: blending YUVA to I422 failed >> [0x22a7240] main subpicture error: blending YUVA to I422 failed >> [0x22a7240] main subpicture error: blending YUVA to I422 failed >> [0x22a7240] main subpicture error: blending YUVA to I422 failed >> [0x22a7240] main subpicture error: blending YUVA to I422 failed >> [0x22a7240] main subpicture error: blending YUVA to I422 failed >> [0x22a7240] main subpicture error: blending YUVA to I422 failed >> ... >> >> _______________________________________________ >> Matroska-devel mailing list >> Matroska-devel at lists.matroska.org >> http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel >> Read Matroska-Devel on GMane: >> http://dir.gmane.org/gmane.comp.multimedia.matroska.devel >> > From slhomme at matroska.org Wed Sep 29 21:01:30 2010 From: slhomme at matroska.org (Steve Lhomme) Date: Wed, 29 Sep 2010 21:01:30 +0200 Subject: [Matroska-devel] matroska container makes playback stutter In-Reply-To: References: Message-ID: Can you tell me if this file stutters on your machine too ? http://devcenter.coreforge.org/corefiles/get.php?id=cc-fmnpgjwk On Wed, Sep 29, 2010 at 8:56 PM, Steve Lhomme wrote: > Also I just played the 3 files in VLC and they play fine. I don't get any stutter. I have a strong machine, but I doubt one container can make decoding significantly slower than another. > > I see the same error in VLC for the NUT and the Matroska versions of the same file: > [0x22a7240] main subpicture error: blending YUVA to I422 failed > > So that rules out this explaination why it stutters for you. > > On Wed, Sep 29, 2010 at 8:50 PM, Steve Lhomme wrote: >> And if you compare #1 and #3 the difference is the (obscure) codec. So >> the conclusion that the container is the problem is not exactly >> correct. >> >> I have no idea what that codec is. But maybe support for it in >> Matroska is just not well implemented in general. Now looking at the >> timecodes in mkvinfo I can see the problem: >> >> |+ Cluster >> | + Cluster timecode: 1.000s >> | + SimpleBlock (key, track number 1, 1 frame(s), timecode 1.000s = >> 00:00:01.000) >> | ?+ Frame with size 9476 >> | + SimpleBlock (track number 1, 1 frame(s), timecode 0.875s = 00:00:00.875) >> | ?+ Frame with size 1639 >> | + SimpleBlock (track number 1, 1 frame(s), timecode 0.917s = 00:00:00.917) >> | ?+ Frame with size 2380 >> | + SimpleBlock (track number 1, 1 frame(s), timecode 0.958s = 00:00:00.958) >> | ?+ Frame with size 2246 >> | + SimpleBlock (track number 1, 1 frame(s), timecode 1.167s = 00:00:01.167) >> | ?+ Frame with size 8005 >> >> The codec seems to use B frames. After a key frame (1.000) you get >> past frames (0.875, 0.917, 0.958). Dunno how it's stored in NUT but >> maybe it has a different order or something that makes players happy >> about it. The file looks correct to me (and mkvalidator). So I suggest >> asking the VLC or FFmpeg developpers why this could produce stutter. >> Given the error given by VLC maybe the bitstream may be bogus, as a >> result of an incorrect muxing in FFmpeg. >> >> On Wed, Sep 29, 2010 at 3:15 PM, ross cuthbertson wrote: >>> I have more problems with Matroska than another container format. Below is a >>> sample based on a 640x360 24fps 5sec clip. Although I have more problems on >>> 1080p resolutions. >>> >>> The encoder I'm using: >>> >>> FFmpeg version SVN-r24323, Copyright (c) 2000-2010 the FFmpeg developers >>> ? built on Jul 19 2010 10:58:48 with gcc 4.4.3 >>> ? configuration: --enable-gpl --enable-version3 --enable-nonfree >>> --enable-postproc --enable-pthreads --enable-libfaac --enable-libmp3lame >>> --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libtheora >>> --enable-libvorbis --enable-libvpx --enable-libx264 --enable-libxvid >>> --enable-x11grab --enable-runtime-cpudetect --enable-zlib --enable-libdirac >>> --enable-libschroedinger --enable-vdpau >>> ? libavutil???? 50.22. 0 / 50.22. 0 >>> ? libavcodec??? 52.84. 0 / 52.84. 0 >>> ? libavformat?? 52.75. 0 / 52.75. 0 >>> ? libavdevice?? 52. 2. 0 / 52. 2. 0 >>> ? libavfilter??? 1.25. 1 /? 1.25. 1 >>> ? libswscale???? 0.11. 0 /? 0.11. 0 >>> ? libpostproc?? 51. 2. 0 / 51. 2. 0 >>> >>> >>> This plays fine in ffplay: >>> >>> ffmpeg -i input.avi -vcodec libx264 -vpre medium -crf 20 no_stutter.mkv >>> http://dl.dropbox.com/u/6743276/mkv_stutter/no_stutter_libx264.mkv >>> >>> >>> >>> This plays fine in ffplay: >>> >>> ffmpeg -i input.avi -vcodec libschroedinger -qscale 7 >>> no_stutter_libschro.nut >>> http://dl.dropbox.com/u/6743276/mkv_stutter/no_stutter_libschro.nut >>> >>> This stutters in ffplay, even though the above does not: >>> >>> ffmpeg -i input.avi -vcodec libschroedinger -qscale 7 stutter_libschro.mkv >>> http://dl.dropbox.com/u/6743276/mkv_stutter/stutter_libschro.mkv >>> >>> The above seams to play ok in VLC but has lots of the following errors: >>> >>> ... >>> [0x22a7240] main subpicture error: blending YUVA to I422 failed >>> [0x22a7240] main subpicture error: blending YUVA to I422 failed >>> [0x22a7240] main subpicture error: blending YUVA to I422 failed >>> [0x22a7240] main subpicture error: blending YUVA to I422 failed >>> [0x22a7240] main subpicture error: blending YUVA to I422 failed >>> [0x22a7240] main subpicture error: blending YUVA to I422 failed >>> [0x22a7240] main subpicture error: blending YUVA to I422 failed >>> [0x22a7240] main subpicture error: blending YUVA to I422 failed >>> [0x22a7240] main subpicture error: blending YUVA to I422 failed >>> [0x22a7240] main subpicture error: blending YUVA to I422 failed >>> [0x22a7240] main subpicture error: blending YUVA to I422 failed >>> ... >>> >>> _______________________________________________ >>> Matroska-devel mailing list >>> Matroska-devel at lists.matroska.org >>> http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel >>> Read Matroska-Devel on GMane: >>> http://dir.gmane.org/gmane.comp.multimedia.matroska.devel >>> >> > > From vgolopupov at gmail.com Thu Sep 30 13:28:52 2010 From: vgolopupov at gmail.com (Vadim Golopupov) Date: Thu, 30 Sep 2010 14:28:52 +0300 Subject: [Matroska-devel] Fwd: libmatroska 1.0.0: KaxBlockData memory leak In-Reply-To: References: Message-ID: ---------- Forwarded message ---------- From: Vadim Golopupov Date: 2010/9/30 Subject: Re: libmatroska 1.0.0: KaxBlockData memory leak To: Steve Lhomme Hello, Steve. You are right. My previous fix was not correct. I looked at the code carefully and made a new change. As i said, the problem arises from here: void KaxReferenceBlock::SetReferencedBlock(const KaxBlockGroup & aRefdBlock) { KaxBlockBlob *block_blob = new KaxBlockBlob(BLOCK_BLOB_NO_SIMPLE); // <--- allocates memory block_blob->SetBlockGroup(*const_cast(&aRefdBlock)); RefdBlock = block_blob; // <--- it should be only reference, but now it has allocated memory, so this memory sometime must be free SetValueIsSet(); } Because allocated memory was not free, as i asked you, you made some changes to free it. But you forgot correct one more place in "KaxBlock.h": ~KaxBlockBlob() { #if MATROSKA_VERSION >= 2 if (bUseSimpleBlock) delete Block.simpleblock; #endif // MATROSKA_VERSION //else // <--- this row must be commented //delete Block.group; // <--- this row must be commented, because at the moment when we get here, the memory is already free. That is why i have "Access violation error" } It explains, why i got error after your changes and you not. Because you use KaxSimpleBlock, and i KaxBlockGroup. From function above "Block" it is union: union { KaxBlockGroup *group; #if MATROSKA_VERSION >= 2 KaxSimpleBlock *simpleblock; #endif // MATROSKA_VERSION } Block; Modified file attached with letter. 2010/9/13 Steve Lhomme Hi Vadim, > > Please send such emails to the mailing list. > > Your fix is not correct. As you only cover one case of SetReferencedBlock() > when the other one is used, you are going to release memory that is owned by > someone else. Maybe you are not using this case, but it is used a lot > elsewhere. > > I will investigate why my crash fixes when I have time. > > On Fri, Sep 10, 2010 at 1:56 PM, Vadim Golopupov wrote: > >> I tried your files. You didn't fix the bug, you made critical bug. I have >> error: >> >> Unhandled exception at 0x005506e3 in p.exe: 0xC0000005: Access violation >> reading location 0xfeeefeee. >> >> ~KaxBlockBlob() { >> #if MATROSKA_VERSION >= 2 >> if (bUseSimpleBlock) >> delete Block.simpleblock; >> else >> #endif // MATROSKA_VERSION >> delete Block.group; <-- PROBLEM HERE >> } >> >> I think you should make changes only which i send with mail to you. >> >> 2010/9/10 Steve Lhomme >> >> I think I fixed it in SVN. >>> Please next time send your email to the dev mailing list. There are more >>> chances you'll have some comments and support from other people using the v1 >>> libs. >>> >>> And thanks for reporting the bug :) >>> >>> Steve >>> >>> >>> On Fri, Sep 3, 2010 at 10:11 PM, Vadim Golopupov wrote: >>> >>>> libmatroska 1.0.0 - The memory leak happens if you add frame with >>>> Future/Past Reference. >>>> >>>> Here is the function from the KaxBlockData.cpp: >>>> >>>> void KaxReferenceBlock::SetReferencedBlock(const KaxBlockGroup & >>>> aRefdBlock) >>>> { >>>> KaxBlockBlob *block_blob = new KaxBlockBlob(BLOCK_BLOB_NO_SIMPLE); >>>> block_blob->SetBlockGroup(*const_cast(&aRefdBlock)); >>>> RefdBlock = block_blob; >>>> SetValueIsSet(); >>>> } >>>> >>>> >>>> KaxBlockBlob *block_blob = new KaxBlockBlob(BLOCK_BLOB_NO_SIMPLE); <- >>>> this memory will never be free. >>>> >>>> To free this memory you need make changes in KaxBlockData.h: >>>> >>>> ~KaxReferenceBlock() >>>> { >>>> if (RefdBlock) { >>>> delete RefdBlock; >>>> RefdBlock = 0; >>>> } >>>> } >>>> >>>> >>>> >>> >> >> >> -- >> Vadim Golopupov >> >> > -- Vadim Golopupov -- Vadim Golopupov -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: KaxBlock.rar Type: application/octet-stream Size: 3750 bytes Desc: not available URL: