From fabian at greffrath.com Tue Aug 3 09:37:21 2010 From: fabian at greffrath.com (Fabian Greffrath) Date: Tue, 03 Aug 2010 09:37:21 +0200 Subject: [Matroska-devel] converting to execution character set: Invalid or incomplete multibyte or wide character In-Reply-To: <20100712123847.GX26416@jones.dk> References: <20100712113945.GW26416@jones.dk> <4C3B048D.60309@greffrath.com> <20100712123847.GX26416@jones.dk> Message-ID: <4C57C731.6000104@greffrath.com> Dear matroska developers, libmatroska is currently failing to build the test suite with gcc-4.4.4 with the following error message: make[1]: Entering directory `/home/fabian/Debian/libmatroska/make/linux' g++ -c -g -O2 -Wall -Wno-unknown-pragmas -ansi -fno-gnu-keywords -D_GNU_SOURCE -Wshadow -I/home/fabian/Debian/libmatroska/make/linux/../.. -I/home/fabian/Debian/libmatroska/make/linux/../../../libebml -o test6.o /home/fabian/Debian/libmatroska/make/linux/../../test/mux/test6.cpp /home/fabian/Debian/libmatroska/make/linux/../../test/mux/test6.cpp: In function 'int main(int, char**)': /home/fabian/Debian/libmatroska/make/linux/../../test/mux/test6.cpp:125: error: converting to execution character set: Invalid or incomplete multibyte or wide character /home/fabian/Debian/libmatroska/make/linux/../../test/mux/test6.cpp:323: error: converting to execution character set: Invalid or incomplete multibyte or wide character /home/fabian/Debian/libmatroska/make/linux/../../test/mux/test6.cpp:352: error: converting to execution character set: Invalid or incomplete multibyte or wide character /home/fabian/Debian/libmatroska/make/linux/../../test/mux/test6.cpp:355: error: converting to execution character set: Invalid or incomplete multibyte or wide character make[1]: *** [test6.o] Error 1 make[1]: Leaving directory `/home/fabian/Debian/libmatroska/make/linux' The cause for this error messages are invalid wide characters in test/mux/test6.cpp. They should be either converted to valid UTF-8 (01-execution-character-set.patch) or, in case you want to keep them as they are, the compiler should be explicitely told which character set they are to be converted from (01-input-charset.patch). Please find a patch for either case attached to this message, both are sufficient to fix the failing compilation. Cheers, Fabian -------------- next part -------------- A non-text attachment was scrubbed... Name: 01-input-charset.patch Type: text/x-diff Size: 409 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 01-execution-character-set.patch Type: text/x-diff Size: 1642 bytes Desc: not available URL: From sivrumit at yahoo.com Wed Aug 4 11:02:15 2010 From: sivrumit at yahoo.com (umit sivri) Date: Wed, 4 Aug 2010 02:02:15 -0700 (PDT) Subject: [Matroska-devel] memory leak in libmatroska::KaxCues::AddBlockGroup In-Reply-To: References: <565679.52656.qm@web32208.mail.mud.yahoo.com> <52544.46959.qm@web32203.mail.mud.yahoo.com> <201007290934.01615.moritz@bunkus.org> Message-ID: <252060.17042.qm@web32201.mail.mud.yahoo.com> test6.cpp rises segfault at the end of try block. here is gdb output: ------------------------------------------------------------------------ Creating "muxed.mkv" Program received signal SIGSEGV, Segmentation fault. 0x0000000000000071 in ?? () (gdb) back #0 0x0000000000000071 in ?? () #1 0x00007f65b84fe0b8 in ~EbmlMaster (this=0x7fffff1accd0) at workspace/libebml_svn/make/linux/../../src/EbmlMaster.cpp:81 #2 0x0000000000408f86 in ~KaxCluster (this=0x7fffff1accd0) at workspace/libmatroska_svn/make/linux/../../matroska/KaxCluster.h:52 #3 0x0000000000407a90 in main (argc=1, argv=0x7fffff1ad788) at workspace/libmatroska_svn/make/linux/../../test/mux/test6.cpp:398 ------------------------------------------------------------------------ Even though problem line shows "delete Blob4;", I found that segfault rises in kaxcluster destructor which was declared as a variable, not a pointer and came to its lifetime end with block end. Making variables pointer and not deallocating prevents segfault but rises memleaks which was the main problem to begin with. Besides, deleting lines which deallocate allocated KaxBlockBlobs in test code also prevents segfaults but then again memleak occurs. Could you verify this? ps: libebml and libmatroska are latest revisions (386 & 453) at the time of post. ________________________________ From: Steve Lhomme To: Discussion about the current and future development of Matroska Sent: Thu, July 29, 2010 10:07:29 PM Subject: Re: [Matroska-devel] memory leak in libmatroska::KaxCues::AddBlockGroup I made the changes in SVN KaxCues::AddBlockGroup() was simply removed and replaced in mux6 with a working version of the code. There might still be leaks in there but at least not this one anymore. On Thu, Jul 29, 2010 at 8:52 PM, Steve Lhomme wrote: OK, I'm looking at that antic code right now. KaxCues::AddBlockGroup() is broken anyway. At least the part where it allocates KaxBlockBlob to test if the KaxBlockGroup being added is not already in the array. It tries to find out using pointers, which obviously are never going to be true since the pointer is brand new... > > >Now KaxCues don't "own" the block they are given to reference. There is no smart >pointer here or anything, so it's up to the code that passed the pointers to >references to kill the references themselves. >But then it allocates a new KaxBlockBlob that noone really owns. This is >inconsistent. So I suggest marking this function as deprecated so that noone >uses it and coders actually use KaxCues::AddBlockBlob(const KaxBlockBlob & >BlockReference) instead and are held responsible for their reference. bool >KaxCues::AddBlockGroup(const KaxBlockGroup & BlockRef) was just added as a >helper. But it's too broken and would need bigger changes to fix this, > > >On Thu, Jul 29, 2010 at 9:34 AM, Moritz Bunkus wrote: > >Hey, >> >> >>On Thursday 29 July 2010 08:14:24 umit sivri wrote: >> >>> I searched all mkvtoolnix sources for the method usage I specified and >>> could not find any usage of KaxCues::AddBlockGroup. >> >>src/merge/cluster_helper.cpp, line 422: >> >> g_kax_cues->AddBlockBlob(*new_block_group); >> >>AddBlockBlob() does indeed not call AddBlockGroup(), and AddBlockGroup() >>allocates a new instance of KaxBlockBlob(). That instance is pushed onto >>the reference array, and that array does not delete the instances. It >>must not delete them as AddBlockBlob() pushes pointers it doesn't have >>ownership over onto the same array. So yeah, there is a memory leak in >>the library. >> >>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 ronnysaftsack at googlemail.com Thu Aug 5 19:06:39 2010 From: ronnysaftsack at googlemail.com (ronny saftsack) Date: Thu, 5 Aug 2010 19:06:39 +0200 Subject: [Matroska-devel] Cropping Message-ID: *Hello **matroska **Development.TEAM,* There is a Problem with mkvmerge: When I try to crop a x264 video with "--cropping 0:10,2,100,20" it only crops the right and the bottom... Is there anything I did wrong? Can you fix this? Congratulation you do a great work! JASs -------------- next part -------------- An HTML attachment was scrubbed... URL: From moritz at bunkus.org Thu Aug 5 19:32:43 2010 From: moritz at bunkus.org (Moritz Bunkus) Date: Thu, 5 Aug 2010 19:32:43 +0200 Subject: [Matroska-devel] Cropping In-Reply-To: References: Message-ID: <201008051932.43727.moritz@bunkus.org> Hey, On Thursday 05 August 2010 19:06:39 ronny saftsack wrote: > There is a Problem with mkvmerge: When I try to crop a x264 video with > "--cropping 0:10,2,100,20" it only crops the right and the bottom... mkvmerge does not actually crop your video track -- it only sets certain header fields to the values you've provided. It's up to the player or decoder to do the actual cropping. Therefore this is not a bug in mkvmerge. 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 From slhomme at matroska.org Thu Aug 5 20:26:58 2010 From: slhomme at matroska.org (Steve Lhomme) Date: Thu, 5 Aug 2010 20:26:58 +0200 Subject: [Matroska-devel] memory leak in libmatroska::KaxCues::AddBlockGroup In-Reply-To: <252060.17042.qm@web32201.mail.mud.yahoo.com> References: <565679.52656.qm@web32208.mail.mud.yahoo.com> <52544.46959.qm@web32203.mail.mud.yahoo.com> <201007290934.01615.moritz@bunkus.org> <252060.17042.qm@web32201.mail.mud.yahoo.com> Message-ID: I don't know how this is possible. I'm not using gcc or gdb, but a (logical) segfault should happen the same way on any platform and I get nothing. Also Blob4 is not a KaxCluster but a KaxBlockBlob. So I don't know how you get the KaxCluster to be called when calling "delete Blob4". And on top of that KaxCluster doesn't have a destructor. So maybe your code is not linked with the right library. On Wed, Aug 4, 2010 at 11:02 AM, umit sivri wrote: > > test6.cpp rises segfault at the end of try block. here is gdb output: > > ------------------------------------------------------------------------ > Creating "muxed.mkv" > > Program received signal SIGSEGV, Segmentation fault. > 0x0000000000000071 in ?? () > (gdb) back > #0 0x0000000000000071 in ?? () > #1 0x00007f65b84fe0b8 in ~EbmlMaster (this=0x7fffff1accd0) at > workspace/libebml_svn/make/linux/../../src/EbmlMaster.cpp:81 > #2 0x0000000000408f86 in ~KaxCluster (this=0x7fffff1accd0) at > workspace/libmatroska_svn/make/linux/../../matroska/KaxCluster.h:52 > #3 0x0000000000407a90 in main (argc=1, argv=0x7fffff1ad788) at > workspace/libmatroska_svn/make/linux/../../test/mux/test6.cpp:398 > ------------------------------------------------------------------------ > > Even though problem line shows "delete Blob4;", I found that segfault rises > in kaxcluster destructor which was declared as a variable, not a pointer and > came to its lifetime end with block end. > Making variables pointer and not deallocating prevents segfault but rises > memleaks which was the main problem to begin with. > Besides, deleting lines which deallocate allocated KaxBlockBlobs in test > code also prevents segfaults but then again memleak occurs. > Could you verify this? > > ps: libebml and libmatroska are latest revisions (386 & 453) at the time of > post. > > > > > ------------------------------ > *From:* Steve Lhomme > *To:* Discussion about the current and future development of Matroska < > matroska-devel at lists.matroska.org> > *Sent:* Thu, July 29, 2010 10:07:29 PM > > *Subject:* Re: [Matroska-devel] memory leak in > libmatroska::KaxCues::AddBlockGroup > > I made the changes in SVN KaxCues::AddBlockGroup() was simply removed and > replaced in mux6 with a working version of the code. There might still be > leaks in there but at least not this one anymore. > > On Thu, Jul 29, 2010 at 8:52 PM, Steve Lhomme wrote: > >> OK, I'm looking at that antic code right now. KaxCues::AddBlockGroup() is >> broken anyway. At least the part where it allocates KaxBlockBlob to test if >> the KaxBlockGroup being added is not already in the array. It tries to find >> out using pointers, which obviously are never going to be true since the >> pointer is brand new... >> >> Now KaxCues don't "own" the block they are given to reference. There is no >> smart pointer here or anything, so it's up to the code that passed the >> pointers to references to kill the references themselves. >> But then it allocates a new KaxBlockBlob that noone really owns. This is >> inconsistent. So I suggest marking this function as deprecated so that noone >> uses it and coders actually use KaxCues::AddBlockBlob(const KaxBlockBlob & >> BlockReference) instead and are held responsible for their reference. bool >> KaxCues::AddBlockGroup(const KaxBlockGroup & BlockRef) was just added as a >> helper. But it's too broken and would need bigger changes to fix this, >> >> On Thu, Jul 29, 2010 at 9:34 AM, Moritz Bunkus wrote: >> >>> Hey, >>> >>> On Thursday 29 July 2010 08:14:24 umit sivri wrote: >>> >>> > I searched all mkvtoolnix sources for the method usage I specified and >>> > could not find any usage of KaxCues::AddBlockGroup. >>> >>> src/merge/cluster_helper.cpp, line 422: >>> >>> g_kax_cues->AddBlockBlob(*new_block_group); >>> >>> AddBlockBlob() does indeed not call AddBlockGroup(), and AddBlockGroup() >>> allocates a new instance of KaxBlockBlob(). That instance is pushed onto >>> the reference array, and that array does not delete the instances. It >>> must not delete them as AddBlockBlob() pushes pointers it doesn't have >>> ownership over onto the same array. So yeah, there is a memory leak in >>> the library. >>> >>> 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 >>> >> >> > > > _______________________________________________ > 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 sivrumit at yahoo.com Fri Aug 6 09:44:14 2010 From: sivrumit at yahoo.com (umit sivri) Date: Fri, 6 Aug 2010 00:44:14 -0700 (PDT) Subject: [Matroska-devel] memory leak in libmatroska::KaxCues::AddBlockGroup In-Reply-To: References: <565679.52656.qm@web32208.mail.mud.yahoo.com> <52544.46959.qm@web32203.mail.mud.yahoo.com> <201007290934.01615.moritz@bunkus.org> <252060.17042.qm@web32201.mail.mud.yahoo.com> Message-ID: <518220.55709.qm@web32208.mail.mud.yahoo.com> Blob4 is not a kaxcluster but Clust1 and Clust2 are. In my previous post I wanted to tell segfault occurs with Clust1 or Clust2(both actually) destructors, not blob4. kaxcluster, which is an ebmlmaster has a destructor: "~ebmlmaster". As to why segfault not occurs for you, my guess is that, it occurs but you could not detect (which was the case in my first execution of the code) since it occurs at the end of try block which everything actually happens. For being sure, I'd recommend adding a printf-cout just before "return 0;" after the try-catch block, and see if it actually prints. You may have already done something like this but Im writing just to make sure. I found the fix for the segfault, too. changing kaxblockblob destructor from: ~KaxBlockBlob() { #if MATROSKA_VERSION >= 2 if (bUseSimpleBlock) delete Block.simpleblock; else #endif // MATROSKA_VERSION delete Block.group; } to: ~KaxBlockBlob() { } in kaxblock.h, starting from line 323, prevents segfault I mentioned and my code works without any memleaks and segfaults. Not sure whether my fix is the right way for all usages, but it serves my purposes. ________________________________ From: Steve Lhomme To: Discussion about the current and future development of Matroska Sent: Thu, August 5, 2010 9:26:58 PM Subject: Re: [Matroska-devel] memory leak in libmatroska::KaxCues::AddBlockGroup I don't know how this is possible. I'm not using gcc or gdb, but a (logical) segfault should happen the same way on any platform and I get nothing. Also Blob4 is not a KaxCluster but a KaxBlockBlob. So I don't know how you get the KaxCluster to be called when calling "delete Blob4". And on top of that KaxCluster doesn't have a destructor. So maybe your code is not linked with the right library. On Wed, Aug 4, 2010 at 11:02 AM, umit sivri wrote: >test6.cpp rises segfault at the end of try block. here is gdb output: > >------------------------------------------------------------------------ >Creating "muxed.mkv" > >Program received signal SIGSEGV, Segmentation fault. >0x0000000000000071 in ?? () >(gdb) back >#0 0x0000000000000071 in ?? () >#1 0x00007f65b84fe0b8 in ~EbmlMaster (this=0x7fffff1accd0) at >workspace/libebml_svn/make/linux/../../src/EbmlMaster.cpp:81 >#2 0x0000000000408f86 in ~KaxCluster (this=0x7fffff1accd0) at >workspace/libmatroska_svn/make/linux/../../matroska/KaxCluster.h:52 >#3 0x0000000000407a90 in main (argc=1, argv=0x7fffff1ad788) at >workspace/libmatroska_svn/make/linux/../../test/mux/test6.cpp:398 >------------------------------------------------------------------------ > > >Even though problem line shows "delete Blob4;", I found that segfault rises in >kaxcluster destructor which was declared as a variable, not a pointer and came >to its lifetime end with block end. >Making variables pointer and not deallocating prevents segfault but rises >memleaks which was the main problem to begin with. >Besides, deleting lines which deallocate allocated KaxBlockBlobs in test code >also prevents segfaults but then again memleak occurs. >Could you verify this? > >ps: libebml and libmatroska are latest revisions (386 & 453) at the time of >post. > > > > > > ________________________________ From: Steve Lhomme >To: Discussion about the current and future development of Matroska > >Sent: Thu, July 29, 2010 10:07:29 PM > >Subject: Re: [Matroska-devel] memory leak in libmatroska::KaxCues::AddBlockGroup > > >I made the changes in SVN KaxCues::AddBlockGroup() was simply removed and >replaced in mux6 with a working version of the code. There might still be leaks >in there but at least not this one anymore. > > >On Thu, Jul 29, 2010 at 8:52 PM, Steve Lhomme wrote: > >OK, I'm looking at that antic code right now. KaxCues::AddBlockGroup() is broken >anyway. At least the part where it allocates KaxBlockBlob to test if the >KaxBlockGroup being added is not already in the array. It tries to find out >using pointers, which obviously are never going to be true since the pointer is >brand new... >> >> >>Now KaxCues don't "own" the block they are given to reference. There is no smart >>pointer here or anything, so it's up to the code that passed the pointers to >>references to kill the references themselves. >>But then it allocates a new KaxBlockBlob that noone really owns. This is >>inconsistent. So I suggest marking this function as deprecated so that noone >>uses it and coders actually use KaxCues::AddBlockBlob(const KaxBlockBlob & >>BlockReference) instead and are held responsible for their reference. bool >>KaxCues::AddBlockGroup(const KaxBlockGroup & BlockRef) was just added as a >>helper. But it's too broken and would need bigger changes to fix this, >> >> >>On Thu, Jul 29, 2010 at 9:34 AM, Moritz Bunkus wrote: >> >>Hey, >>> >>> >>>On Thursday 29 July 2010 08:14:24 umit sivri wrote: >>> >>>> I searched all mkvtoolnix sources for the method usage I specified and >>>> could not find any usage of KaxCues::AddBlockGroup. >>> >>>src/merge/cluster_helper.cpp, line 422: >>> >>> g_kax_cues->AddBlockBlob(*new_block_group); >>> >>>AddBlockBlob() does indeed not call AddBlockGroup(), and AddBlockGroup() >>>allocates a new instance of KaxBlockBlob(). That instance is pushed onto >>>the reference array, and that array does not delete the instances. It >>>must not delete them as AddBlockBlob() pushes pointers it doesn't have >>>ownership over onto the same array. So yeah, there is a memory leak in >>>the library. >>> >>>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 >>> >> > > >_______________________________________________ >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 Sat Aug 7 10:57:36 2010 From: slhomme at matroska.org (Steve Lhomme) Date: Sat, 7 Aug 2010 10:57:36 +0200 Subject: [Matroska-devel] revisiting StereoMode tag and In-Reply-To: References: Message-ID: Here is a new variant that I think should be good enough for all the cases mentioned. I'm still not sure if the "HDMI" track combination types are necessary of if it's more a hardware capability issue. For example we don't store in Matroska wether a track is interlaced or not. As you can see the "container combining" and "internal 3D track" are now clearly separated. single "mono" track 123 mono ... stereo with 2 tracks combined stereo 234 left 123 right 123 234 single track with 2 planes 123 left-right ... stereo with 3 tracks combined stereo 234 left 123 right 345 background 123 234 345 On Fri, Jul 30, 2010 at 10:59 PM, Steve Lhomme wrote: > On Fri, Jul 30, 2010 at 12:48 AM, Alok Ahuja wrote: > >> >> >> On Thu, Jul 29, 2010 at 1:17 PM, Steve Lhomme wrote: >> >>> In Matroska the default value doesn't need to be stored. And the default >>> (and backward compatible) value for StereoPlane would be "mono" (which will >>> probably not be stored as strings). So wether it's superceded or not is not >>> an issue. Basically that tag means that the track cannot be used by current >>> 2D systems if it's something else than "mono". But in that case the codec >>> value will probably not be supported either. I don't think the current AVC >>> or MPEG2 can support non mono tracks ? They have to be combined from >>> independent tracks ? >>> >>> >> [Alok]: AVC or H.264 can support non-mono tracks by using an SEI message. >> This is a recent addition. I'm not aware of MPEG2 being able to support it. >> >> >>> What you propose sound good too. I'm just concerned wether current >>> players will be able to tell if the track is "internally 3D" or not, to know >>> if they can actually try to decode the stream or not. In other words if the >>> codec ID alone will *always* be sufficient to differentiate the 2 worlds or >>> if a flag has to be added at the current track level. >>> >>> >> [Alok]: I'm thinking of the MVC or H.264 with SEI message codec example. >> In this case, the codecID is not sufficient to differentiate between 3D and >> non-3D. This is because the bitstream specification for the aforementioned >> codecs contains the 3D info and that is optional (in case of H.264 with >> SEI). >> >> OK, so we need that information at the track level as well (2D systems may > decide they can't deal with it). Whichever though existing players will have > to be updated to make sure a 3D AVC track is not tried to be played on > existing systems. So it matters less if it's in the track entry as it is > today or the "upper" TrackDependency. Or it could still be handled at the > codec level. ie V_MPEG4/ISO/AVC and V_MPEG4/ISO/AVC3D. In matroska it > would not be possible to switch the stream kind in a segment. So it may > still be possible to split them that way. Current 2D decoders may choke on a > 3D AVC stream as well (not 100% sure). So it may be necessary anyway to make > this distinction. > > Steve > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From waveletcoeff at gmail.com Sat Aug 7 17:05:04 2010 From: waveletcoeff at gmail.com (Alok Ahuja) Date: Sat, 7 Aug 2010 08:05:04 -0700 Subject: [Matroska-devel] revisiting StereoMode tag and In-Reply-To: References: Message-ID: The HDMI supported source stereo layouts are indicative of the type of stereo source content out there - the hardware's capability for supporting them is a different issue. This is corroborated by the stereo types supported in H.264 also. In this new variant, would the definitions be as follows? StereoType mono left-right top-bottom checkerboard row-interleaved column-interleaved StereoPosition left right background The new variant in itself looks pretty clear to me on the distinction of the definitions. Thanks Steve. On Sat, Aug 7, 2010 at 1:57 AM, Steve Lhomme wrote: > Here is a new variant that I think should be good enough for all the cases > mentioned. I'm still not sure if the "HDMI" track combination types are > necessary of if it's more a hardware capability issue. For example we don't > store in Matroska wether a track is interlaced or not. > > As you can see the "container combining" and "internal 3D track" are now > clearly separated. > > single "mono" track > > 123 > mono > ... > > > stereo with 2 tracks combined > > stereo > > 234 > left > > > 123 > right > > > > 123 > > > 234 > > > single track with 2 planes > > 123 > left-right > ... > > > stereo with 3 tracks combined > > stereo > > 234 > left > > > 123 > right > > > 345 > background > > > > 123 > > > 234 > > > 345 > > > On Fri, Jul 30, 2010 at 10:59 PM, Steve Lhomme wrote: > >> On Fri, Jul 30, 2010 at 12:48 AM, Alok Ahuja wrote: >> >>> >>> >>> On Thu, Jul 29, 2010 at 1:17 PM, Steve Lhomme wrote: >>> >>>> In Matroska the default value doesn't need to be stored. And the default >>>> (and backward compatible) value for StereoPlane would be "mono" (which will >>>> probably not be stored as strings). So wether it's superceded or not is not >>>> an issue. Basically that tag means that the track cannot be used by current >>>> 2D systems if it's something else than "mono". But in that case the codec >>>> value will probably not be supported either. I don't think the current AVC >>>> or MPEG2 can support non mono tracks ? They have to be combined from >>>> independent tracks ? >>>> >>>> >>> [Alok]: AVC or H.264 can support non-mono tracks by using an SEI message. >>> This is a recent addition. I'm not aware of MPEG2 being able to support it. >>> >>> >>>> What you propose sound good too. I'm just concerned wether current >>>> players will be able to tell if the track is "internally 3D" or not, to know >>>> if they can actually try to decode the stream or not. In other words if the >>>> codec ID alone will *always* be sufficient to differentiate the 2 worlds or >>>> if a flag has to be added at the current track level. >>>> >>>> >>> [Alok]: I'm thinking of the MVC or H.264 with SEI message codec example. >>> In this case, the codecID is not sufficient to differentiate between 3D and >>> non-3D. This is because the bitstream specification for the aforementioned >>> codecs contains the 3D info and that is optional (in case of H.264 with >>> SEI). >>> >>> OK, so we need that information at the track level as well (2D systems >> may decide they can't deal with it). Whichever though existing players will >> have to be updated to make sure a 3D AVC track is not tried to be played on >> existing systems. So it matters less if it's in the track entry as it is >> today or the "upper" TrackDependency. Or it could still be handled at the >> codec level. ie V_MPEG4/ISO/AVC and V_MPEG4/ISO/AVC3D. In matroska it >> would not be possible to switch the stream kind in a segment. So it may >> still be possible to split them that way. Current 2D decoders may choke on a >> 3D AVC stream as well (not 100% sure). So it may be necessary anyway to make >> this distinction. >> >> Steve >> >> > > _______________________________________________ > Matroska-devel mailing list > Matroska-devel at lists.matroska.org > http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel > Read Matroska-Devel on GMane: > http://dir.gmane.org/gmane.comp.multimedia.matroska.devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From slhomme at matroska.org Sat Aug 7 17:10:00 2010 From: slhomme at matroska.org (Steve Lhomme) Date: Sat, 7 Aug 2010 17:10:00 +0200 Subject: [Matroska-devel] revisiting StereoMode tag and In-Reply-To: References: Message-ID: The problem is really when tracks are combined via Matroska and not inside the codec. So do "top-bottom", "checkerboard", etc make sense for the way to "mono" tracks can be combined or not ? As you can see, when the tracks are defined as dependent, they need to define which part of the dependency they are. So what would it be in this case ? On Sat, Aug 7, 2010 at 5:05 PM, Alok Ahuja wrote: > The HDMI supported source stereo layouts are indicative of the type of > stereo source content out there - the hardware's capability for supporting > them is a different issue. This is corroborated by the stereo types > supported in H.264 also. > > In this new variant, would the definitions be as follows? > > StereoType > mono > left-right > > top-bottom > checkerboard > row-interleaved > column-interleaved > > StereoPosition > left > right > background > > The new variant in itself looks pretty clear to me on the distinction of > the definitions. Thanks Steve. > > > On Sat, Aug 7, 2010 at 1:57 AM, Steve Lhomme wrote: > >> Here is a new variant that I think should be good enough for all the cases >> mentioned. I'm still not sure if the "HDMI" track combination types are >> necessary of if it's more a hardware capability issue. For example we don't >> store in Matroska wether a track is interlaced or not. >> >> As you can see the "container combining" and "internal 3D track" are now >> clearly separated. >> >> single "mono" track >> >> 123 >> mono >> ... >> >> >> stereo with 2 tracks combined >> >> stereo >> >> 234 >> left >> >> >> 123 >> right >> >> >> >> 123 >> >> >> 234 >> >> >> single track with 2 planes >> >> 123 >> left-right >> ... >> >> >> stereo with 3 tracks combined >> >> stereo >> >> 234 >> left >> >> >> 123 >> right >> >> >> 345 >> background >> >> >> >> 123 >> >> >> 234 >> >> >> 345 >> >> >> On Fri, Jul 30, 2010 at 10:59 PM, Steve Lhomme wrote: >> >>> On Fri, Jul 30, 2010 at 12:48 AM, Alok Ahuja wrote: >>> >>>> >>>> >>>> On Thu, Jul 29, 2010 at 1:17 PM, Steve Lhomme wrote: >>>> >>>>> In Matroska the default value doesn't need to be stored. And the >>>>> default (and backward compatible) value for StereoPlane would be "mono" >>>>> (which will probably not be stored as strings). So wether it's superceded or >>>>> not is not an issue. Basically that tag means that the track cannot be used >>>>> by current 2D systems if it's something else than "mono". But in that case >>>>> the codec value will probably not be supported either. I don't think the >>>>> current AVC or MPEG2 can support non mono tracks ? They have to be combined >>>>> from independent tracks ? >>>>> >>>>> >>>> [Alok]: AVC or H.264 can support non-mono tracks by using an SEI >>>> message. This is a recent addition. I'm not aware of MPEG2 being able to >>>> support it. >>>> >>>> >>>>> What you propose sound good too. I'm just concerned wether current >>>>> players will be able to tell if the track is "internally 3D" or not, to know >>>>> if they can actually try to decode the stream or not. In other words if the >>>>> codec ID alone will *always* be sufficient to differentiate the 2 worlds or >>>>> if a flag has to be added at the current track level. >>>>> >>>>> >>>> [Alok]: I'm thinking of the MVC or H.264 with SEI message codec example. >>>> In this case, the codecID is not sufficient to differentiate between 3D and >>>> non-3D. This is because the bitstream specification for the aforementioned >>>> codecs contains the 3D info and that is optional (in case of H.264 with >>>> SEI). >>>> >>>> OK, so we need that information at the track level as well (2D systems >>> may decide they can't deal with it). Whichever though existing players will >>> have to be updated to make sure a 3D AVC track is not tried to be played on >>> existing systems. So it matters less if it's in the track entry as it is >>> today or the "upper" TrackDependency. Or it could still be handled at the >>> codec level. ie V_MPEG4/ISO/AVC and V_MPEG4/ISO/AVC3D. In matroska it >>> would not be possible to switch the stream kind in a segment. So it may >>> still be possible to split them that way. Current 2D decoders may choke on a >>> 3D AVC stream as well (not 100% sure). So it may be necessary anyway to make >>> this distinction. >>> >>> Steve >>> >>> >> >> _______________________________________________ >> Matroska-devel mailing list >> Matroska-devel at lists.matroska.org >> http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel >> Read Matroska-Devel on GMane: >> http://dir.gmane.org/gmane.comp.multimedia.matroska.devel >> > > > _______________________________________________ > 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 waveletcoeff at gmail.com Sat Aug 7 18:03:23 2010 From: waveletcoeff at gmail.com (Alok Ahuja) Date: Sat, 7 Aug 2010 09:03:23 -0700 Subject: [Matroska-devel] revisiting StereoMode tag and In-Reply-To: References: Message-ID: On Sat, Aug 7, 2010 at 8:10 AM, Steve Lhomme wrote: > The problem is really when tracks are combined via Matroska and not inside > the codec. So do "top-bottom", "checkerboard", etc make sense for the way to > "mono" tracks can be combined or not ? > > [Alok] - I do not know of a practical example in which we have individual tracks representing top view or bottom view only, or for that matter checkerboard. Hence, they do not make sense for the StereoPosition tag > As you can see, when the tracks are defined as dependent, they need to > define which part of the dependency they are. So what would it be in this > case ? > > > [Alok] - I think you have StereoPosition nailed correctly to define the track dependency- left eye view, right eye view, background view. You could consider an incremental and generic "reference view" track that could be defined as a dependent of the other tracks. These references could be numerous in nature, and it would be up to the codec to choose how they are pertinent in the final representation. On Sat, Aug 7, 2010 at 5:05 PM, Alok Ahuja wrote: > >> The HDMI supported source stereo layouts are indicative of the type of >> stereo source content out there - the hardware's capability for supporting >> them is a different issue. This is corroborated by the stereo types >> supported in H.264 also. >> >> In this new variant, would the definitions be as follows? >> >> StereoType >> mono >> left-right >> >> top-bottom >> checkerboard >> row-interleaved >> column-interleaved >> >> StereoPosition >> left >> right >> background >> >> The new variant in itself looks pretty clear to me on the distinction of >> the definitions. Thanks Steve. >> >> >> On Sat, Aug 7, 2010 at 1:57 AM, Steve Lhomme wrote: >> >>> Here is a new variant that I think should be good enough for all the >>> cases mentioned. I'm still not sure if the "HDMI" track combination types >>> are necessary of if it's more a hardware capability issue. For example we >>> don't store in Matroska wether a track is interlaced or not. >>> >>> As you can see the "container combining" and "internal 3D track" are now >>> clearly separated. >>> >>> single "mono" track >>> >>> 123 >>> mono >>> ... >>> >>> >>> stereo with 2 tracks combined >>> >>> stereo >>> >>> 234 >>> left >>> >>> >>> 123 >>> right >>> >>> >>> >>> 123 >>> >>> >>> 234 >>> >>> >>> single track with 2 planes >>> >>> 123 >>> left-right >>> ... >>> >>> >>> stereo with 3 tracks combined >>> >>> stereo >>> >>> 234 >>> left >>> >>> >>> 123 >>> right >>> >>> >>> 345 >>> background >>> >>> >>> >>> 123 >>> >>> >>> 234 >>> >>> >>> 345 >>> >>> >>> On Fri, Jul 30, 2010 at 10:59 PM, Steve Lhomme wrote: >>> >>>> On Fri, Jul 30, 2010 at 12:48 AM, Alok Ahuja wrote: >>>> >>>>> >>>>> >>>>> On Thu, Jul 29, 2010 at 1:17 PM, Steve Lhomme wrote: >>>>> >>>>>> In Matroska the default value doesn't need to be stored. And the >>>>>> default (and backward compatible) value for StereoPlane would be "mono" >>>>>> (which will probably not be stored as strings). So wether it's superceded or >>>>>> not is not an issue. Basically that tag means that the track cannot be used >>>>>> by current 2D systems if it's something else than "mono". But in that case >>>>>> the codec value will probably not be supported either. I don't think the >>>>>> current AVC or MPEG2 can support non mono tracks ? They have to be combined >>>>>> from independent tracks ? >>>>>> >>>>>> >>>>> [Alok]: AVC or H.264 can support non-mono tracks by using an SEI >>>>> message. This is a recent addition. I'm not aware of MPEG2 being able to >>>>> support it. >>>>> >>>>> >>>>>> What you propose sound good too. I'm just concerned wether current >>>>>> players will be able to tell if the track is "internally 3D" or not, to know >>>>>> if they can actually try to decode the stream or not. In other words if the >>>>>> codec ID alone will *always* be sufficient to differentiate the 2 worlds or >>>>>> if a flag has to be added at the current track level. >>>>>> >>>>>> >>>>> [Alok]: I'm thinking of the MVC or H.264 with SEI message codec >>>>> example. In this case, the codecID is not sufficient to differentiate >>>>> between 3D and non-3D. This is because the bitstream specification for the >>>>> aforementioned codecs contains the 3D info and that is optional (in case of >>>>> H.264 with SEI). >>>>> >>>>> OK, so we need that information at the track level as well (2D systems >>>> may decide they can't deal with it). Whichever though existing players will >>>> have to be updated to make sure a 3D AVC track is not tried to be played on >>>> existing systems. So it matters less if it's in the track entry as it is >>>> today or the "upper" TrackDependency. Or it could still be handled at the >>>> codec level. ie V_MPEG4/ISO/AVC and V_MPEG4/ISO/AVC3D. In matroska it >>>> would not be possible to switch the stream kind in a segment. So it may >>>> still be possible to split them that way. Current 2D decoders may choke on a >>>> 3D AVC stream as well (not 100% sure). So it may be necessary anyway to make >>>> this distinction. >>>> >>>> Steve >>>> >>>> >>> >>> _______________________________________________ >>> Matroska-devel mailing list >>> Matroska-devel at lists.matroska.org >>> http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel >>> Read Matroska-Devel on GMane: >>> http://dir.gmane.org/gmane.comp.multimedia.matroska.devel >>> >> >> >> _______________________________________________ >> 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 slhomme at matroska.org Sun Aug 8 10:54:10 2010 From: slhomme at matroska.org (Steve Lhomme) Date: Sun, 8 Aug 2010 10:54:10 +0200 Subject: [Matroska-devel] revisiting StereoMode tag and In-Reply-To: References: Message-ID: On Sat, Aug 7, 2010 at 6:03 PM, Alok Ahuja wrote: > > > On Sat, Aug 7, 2010 at 8:10 AM, Steve Lhomme wrote: > >> The problem is really when tracks are combined via Matroska and not inside >> the codec. So do "top-bottom", "checkerboard", etc make sense for the way to >> "mono" tracks can be combined or not ? >> >> [Alok] - I do not know of a practical example in which we have individual > tracks representing top view or bottom view only, or for that matter > checkerboard. Hence, they do not make sense for the StereoPosition tag > OK. Let's say it's OK for now... They don't make sense to me either. It's been taking a while to get rid of interlaced encoding, I hope this weirdo modes don't get much attention anyway... > > >> As you can see, when the tracks are defined as dependent, they need to >> define which part of the dependency they are. So what would it be in this >> case ? >> >> >> [Alok] - I think you have StereoPosition nailed correctly to define the > track dependency- left eye view, right eye view, background view. You could > consider an incremental and generic "reference view" track that could be > defined as a dependent of the other tracks. These references could be > numerous in nature, and it would be up to the codec to choose how they are > pertinent in the final representation. > Yes, There can be many reference variants of the same file. For now it's undefinied which one is used. Maybe I should add a UID per Dependency unit. So they can be referenced and tagged. -------------- next part -------------- An HTML attachment was scrubbed... URL: From waveletcoeff at gmail.com Mon Aug 9 00:46:28 2010 From: waveletcoeff at gmail.com (Alok Ahuja) Date: Sun, 8 Aug 2010 15:46:28 -0700 Subject: [Matroska-devel] revisiting StereoMode tag and In-Reply-To: References: Message-ID: On Sun, Aug 8, 2010 at 1:54 AM, Steve Lhomme wrote: > On Sat, Aug 7, 2010 at 6:03 PM, Alok Ahuja wrote: > >> >> >> On Sat, Aug 7, 2010 at 8:10 AM, Steve Lhomme wrote: >> >>> The problem is really when tracks are combined via Matroska and not >>> inside the codec. So do "top-bottom", "checkerboard", etc make sense for the >>> way to "mono" tracks can be combined or not ? >>> >>> [Alok] - I do not know of a practical example in which we have individual >> tracks representing top view or bottom view only, or for that matter >> checkerboard. Hence, they do not make sense for the StereoPosition tag >> > > OK. Let's say it's OK for now... They don't make sense to me either. It's > been taking a while to get rid of interlaced encoding, I hope this weirdo > modes don't get much attention anyway... > > >> >> >>> As you can see, when the tracks are defined as dependent, they need to >>> define which part of the dependency they are. So what would it be in this >>> case ? >>> >>> >>> [Alok] - I think you have StereoPosition nailed correctly to define the >> track dependency- left eye view, right eye view, background view. You could >> consider an incremental and generic "reference view" track that could be >> defined as a dependent of the other tracks. These references could be >> numerous in nature, and it would be up to the codec to choose how they are >> pertinent in the final representation. >> > > Yes, There can be many reference variants of the same file. For now it's > undefinied which one is used. Maybe I should add a UID per Dependency unit. > So they can be referenced and tagged. > [Alok]: That sounds good. > _______________________________________________ > 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 koransky at optonline.net Tue Aug 17 10:47:46 2010 From: koransky at optonline.net (Kenneth Oransky) Date: Tue, 17 Aug 2010 08:47:46 +0000 (UTC) Subject: [Matroska-devel] Pixelation ocurs with versions 14-08-2010 and 20-05-2010 of Haali Media Splitter Message-ID: When using BD Rebuilder to make a BD-9 of Avatar pixelation occurs in the first few frames with Haali Media Splitter versions 14-08-2010 ans 20-05-2010. From broken.zhou at gmail.com Fri Aug 20 16:26:30 2010 From: broken.zhou at gmail.com (=?UTF-8?B?5ZGo5aWV6LaF?=) Date: Fri, 20 Aug 2010 22:26:30 +0800 Subject: [Matroska-devel] Bug report Message-ID: On Chinese system, the option tab of Haali Media Splitter is abnormal. Users can't change any option because of the size of the windows. -------------- next part -------------- A non-text attachment was scrubbed... Name: untitled.png Type: image/png Size: 36864 bytes Desc: not available URL: From smasher.smashes at gmail.com Fri Aug 20 16:36:41 2010 From: smasher.smashes at gmail.com (Smasher Smashes) Date: Fri, 20 Aug 2010 07:36:41 -0700 Subject: [Matroska-devel] Fwd: Haali Media Splitter Is Causing Windows Explorer to Crash In-Reply-To: References: Message-ID: Hi there, I did not know what e-mail to use. If you could forward this to the correct people, I would appreciate it. I just updated my Haali Media Splitter. Now whenever I even see a thumbnail of a .mkv file, Windows Explorer will crash. I have removed program after program and have found the problem is from the Haali Media Splitter. I also found this discussion on another forum.. http://social.answers.microsoft.com/Forums/en-US/w7files/thread/db90c294-05e6-4bbb-9182-a51e55e98349 ... where someone else had the same issue. I am hopeful that someone at your company would be able to get back to me to let me know how to correct this.. if possible.. on my end. I tried changing the last line under options from yes back to no and back again. The same crash happens. the crashing only ends when I remove the program from my system. I look forward to hearing from you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From andreas at lonelycoder.com Mon Aug 23 09:00:06 2010 From: andreas at lonelycoder.com (=?ISO-8859-1?Q?Andreas_=D6man?=) Date: Mon, 23 Aug 2010 09:00:06 +0200 Subject: [Matroska-devel] S_DVBSUB Message-ID: <4C721C76.6050604@lonelycoder.com> Hi I suggest adding a new subtitle codec: S_DVBSUB for storing DVB subtitles (ETSI EN 300 743). I also suggest (based on some discussion on IRC) that no extradata is added with composition and ancillary ID, but rather that the muxing application must filter the subtitle segments before muxing. As this is my first contact with the list; Did I miss anything? From moritz at bunkus.org Mon Aug 23 09:10:06 2010 From: moritz at bunkus.org (Moritz Bunkus) Date: Mon, 23 Aug 2010 09:10:06 +0200 Subject: [Matroska-devel] S_DVBSUB In-Reply-To: <4C721C76.6050604@lonelycoder.com> References: <4C721C76.6050604@lonelycoder.com> Message-ID: <201008230910.06519.moritz@bunkus.org> Hey ho, On Monday 23 August 2010 09:00:06 Andreas ?man wrote: > I also suggest (based on some discussion on IRC) that no extradata is > added with composition and ancillary ID, but rather that the muxing > application must filter the subtitle segments before muxing. With "extradata" he means the following: In a MPEG transport stream DVBSUBs are prefixed with four bytes of data providing a sub-stream ID. That way several streams inside that DVBSUB stream can be identified. Think of tracks in tracks. For Matroska I objected to storing streams that way as you only have one logical track in a Matroska track. Therefore the proposal to drop those four bytes and to use only one DVBSUB sub-stream in a single Matroska track. I totally agree with that :) > As this is my first contact with the list; Did I miss anything? Does that codec need any codec extra data (Matroska element 'CodecPrivate')? 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 andreas at lonelycoder.com Mon Aug 23 10:33:41 2010 From: andreas at lonelycoder.com (=?UTF-8?B?QW5kcmVhcyDDlm1hbg==?=) Date: Mon, 23 Aug 2010 10:33:41 +0200 Subject: [Matroska-devel] S_DVBSUB In-Reply-To: <201008230910.06519.moritz@bunkus.org> References: <4C721C76.6050604@lonelycoder.com> <201008230910.06519.moritz@bunkus.org> Message-ID: <4C723265.6040107@lonelycoder.com> On 08/23/2010 09:10 AM, Moritz Bunkus wrote: > Hey ho, > > On Monday 23 August 2010 09:00:06 Andreas ?man wrote: > >> I also suggest (based on some discussion on IRC) that no extradata is >> added with composition and ancillary ID, but rather that the muxing >> application must filter the subtitle segments before muxing. > > With "extradata" he means the following: > > In a MPEG transport stream DVBSUBs are prefixed with four bytes of data > providing a sub-stream ID. That way several streams inside that DVBSUB > stream can be identified. Think of tracks in tracks. Not really, those 4 bytes (2 16bit values) are from the PMT. > For Matroska I objected to storing streams that way as you only have one > logical track in a Matroska track. Therefore the proposal to drop those > four bytes and to use only one DVBSUB sub-stream in a single Matroska > track. > > I totally agree with that :) > >> As this is my first contact with the list; Did I miss anything? > > Does that codec need any codec extra data (Matroska element > 'CodecPrivate')? That was the "extradata" i was referring to above. Perhaps a bit of clarification is in place. The reason for having these composition-ID and ancillary-ID discriminators is to allow sharing of subtitle data between tracks. A good use of this is subtitles for hearing impaired. An example how this works (with MPEG TS multiplexing): In the MPEG PMT you would have two subtitle streams "English" PID 1234 composition ID = 1 ancillary ID = 0 "English for hearing impaired" PID 1234 composition ID = 1 ancillary ID = 2 Thus, in PID 1234 you would send normal text segments with segment ID 1 and hearing impaired related segments with ID 2. Effectively allowing two tracks to share most of the data. Now, when re-multiplexing this into the MKV container you have a few options. 1) Write down all packets in two tracks and attach the composition and ancillary ID as 4 bytes of codec private data. This is obviously a bit inefficient when it comes to file size. 2) Pre-filter the data so the packet only contain segments assigned to the track and disallow any codec private data. 3) Use codec private data and somehow share packets between tracks. I don't think that's possible with Matroska? Even so, would any player actually support it? Note that the term 'segment' here refers to "subpackets" in the DVB subtitle packet. Also, if anyone is further interested here is a URL to the spec. http://broadcasting.ru/pdf-standard-specifications/subtitling/dvb-sub/en300743.v1.2.1.pdf > > Regards, > Mosu > > > > > _______________________________________________ > Matroska-devel mailing list > Matroska-devel at lists.matroska.org > http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel > Read Matroska-Devel on GMane: http://dir.gmane.org/gmane.comp.multimedia.matroska.devel From slhomme at matroska.org Mon Aug 23 21:16:37 2010 From: slhomme at matroska.org (Steve Lhomme) Date: Mon, 23 Aug 2010 21:16:37 +0200 Subject: [Matroska-devel] S_DVBSUB In-Reply-To: <4C723265.6040107@lonelycoder.com> References: <4C721C76.6050604@lonelycoder.com> <201008230910.06519.moritz@bunkus.org> <4C723265.6040107@lonelycoder.com> Message-ID: Mh, that's an interresting case. I don't understand the difference between the composition ID and the ancillary ID (and the PID in your example is twice the same, is it normal?). But it's clear that the goal of sharing data between tracks is an interresting one. In clean Matroska there could be different ways to do that: - use 2 tracks and "chapter codec" to switch between one track or the other given the position. That's quite inconvenient to handle and not really in the stream itself. So I don't think it should be done that way. - use virtual tracks, or rather regular tracks but with virtual blocks. There used to be BlockVirtual for that. But the design is not clean and is deprecated. Plus it's not exactly what we want here. So we need something new. We recently added TrackDepdency for 3D playback. That's a way to combine 2 "mono" tracks to make a "stereo" one. The same could be done with subtitles. The TrackDependency creating a new track on its own, by combining 2 existing tracks. So in this case there would be 3 actual tracks: - 1: english - 2: english for hearing impaired - 3: common data between 1 and 2 None of these tracks are really usable as they are and should be marked as such (the Track FlagEnabled set to 0). And 2 TrackDependency would define the actual mix of 1+3 and 2+3 for actual playback. That means TrackDependency has to be enhanced/tuned to allow something like this. Did I miss anything or didn't understand correctly the goal here ? Steve On Mon, Aug 23, 2010 at 10:33 AM, Andreas ?man wrote: > On 08/23/2010 09:10 AM, Moritz Bunkus wrote: > >> Hey ho, >> >> On Monday 23 August 2010 09:00:06 Andreas ?man wrote: >> >> I also suggest (based on some discussion on IRC) that no extradata is >>> added with composition and ancillary ID, but rather that the muxing >>> application must filter the subtitle segments before muxing. >>> >> >> With "extradata" he means the following: >> >> In a MPEG transport stream DVBSUBs are prefixed with four bytes of data >> providing a sub-stream ID. That way several streams inside that DVBSUB >> stream can be identified. Think of tracks in tracks. >> > > Not really, those 4 bytes (2 16bit values) are from the PMT. > > > For Matroska I objected to storing streams that way as you only have one >> logical track in a Matroska track. Therefore the proposal to drop those >> four bytes and to use only one DVBSUB sub-stream in a single Matroska >> track. >> >> I totally agree with that :) >> >> As this is my first contact with the list; Did I miss anything? >>> >> >> Does that codec need any codec extra data (Matroska element >> 'CodecPrivate')? >> > > That was the "extradata" i was referring to above. > > Perhaps a bit of clarification is in place. > > The reason for having these composition-ID and ancillary-ID > discriminators is to allow sharing of subtitle data between tracks. > > A good use of this is subtitles for hearing impaired. > An example how this works (with MPEG TS multiplexing): > > In the MPEG PMT you would have two subtitle streams > "English" > PID 1234 > composition ID = 1 > ancillary ID = 0 > > "English for hearing impaired" > PID 1234 > composition ID = 1 > ancillary ID = 2 > > Thus, in PID 1234 you would send normal text segments with > segment ID 1 and hearing impaired related segments with ID 2. > Effectively allowing two tracks to share most of the data. > > Now, when re-multiplexing this into the MKV container you > have a few options. > > 1) Write down all packets in two tracks and attach the > composition and ancillary ID as 4 bytes of codec private data. > This is obviously a bit inefficient when it comes to file size. > > 2) Pre-filter the data so the packet only contain segments > assigned to the track and disallow any codec private data. > > 3) Use codec private data and somehow share packets between > tracks. I don't think that's possible with Matroska? Even so, > would any player actually support it? > > Note that the term 'segment' here refers to "subpackets" in the > DVB subtitle packet. > > Also, if anyone is further interested here is a URL to the spec. > > > http://broadcasting.ru/pdf-standard-specifications/subtitling/dvb-sub/en300743.v1.2.1.pdf > >> >> Regards, >> Mosu >> >> >> >> >> >> _______________________________________________ >> 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 ache at nagual.pp.ru Tue Aug 24 06:13:33 2010 From: ache at nagual.pp.ru (Andrey Chernov) Date: Tue, 24 Aug 2010 08:13:33 +0400 Subject: [Matroska-devel] Haali Media Splitter 14/08/2010 crash (Windows 7) Message-ID: Can't use latest Haali with CoreAVC 2.0.0 (it works under XP, but cause crash in Windows 7). It seems the problem not in CoreAVC which works nicely with about five other splitters in Windows 7 (excepting Haali's one), so I report the bug here. From at2313 at gmail.com Wed Aug 25 20:40:58 2010 From: at2313 at gmail.com (TS-Labs inc.) Date: Wed, 25 Aug 2010 21:40:58 +0300 Subject: [Matroska-devel] Incorrect M2TS VC-1 Streams Processing in HaaliSplitter (Bug/Development Request) Message-ID: <161467965.20100825214058@gmail.com> Hi all Matroska-team members! I've found, that some of BluRay streams are buggy in HS. First I thought it to be a decoders problem, but it is NOT. Same decoders work with these streams using Gabest MPEG Splitter correctly. At the link below http://multi-up.com/325677 I uploaded such incompatible video file. Could you please look closely to this problem? Thank you very much! Val -- Best regards, TS-Labs mailto:at2313 at gmail.com From smeulf at hotmail.fr Sat Aug 28 00:35:22 2010 From: smeulf at hotmail.fr (Moi Smeulf) Date: Sat, 28 Aug 2010 00:35:22 +0200 Subject: [Matroska-devel] and Tags Message-ID: 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From alan at ebenholz.co.uk Sun Aug 29 17:48:49 2010 From: alan at ebenholz.co.uk (Alan) Date: Sun, 29 Aug 2010 16:48:49 +0100 Subject: [Matroska-devel] Bug in mkWDclean? Message-ID: <4C7A8161.9030504@ebenholz.co.uk> An HTML attachment was scrubbed... URL: From andreas at lonelycoder.com Sun Aug 29 22:55:25 2010 From: andreas at lonelycoder.com (=?ISO-8859-1?Q?Andreas_=D6man?=) Date: Sun, 29 Aug 2010 22:55:25 +0200 Subject: [Matroska-devel] S_DVBSUB In-Reply-To: References: <4C721C76.6050604@lonelycoder.com> <201008230910.06519.moritz@bunkus.org> <4C723265.6040107@lonelycoder.com> Message-ID: <4C7AC93D.1020507@lonelycoder.com> On 08/23/2010 09:16 PM, Steve Lhomme wrote: > Mh, that's an interresting case. I don't understand the difference > between the composition ID and the ancillary ID (and the PID in your > example is twice the same, is it normal?). I've no idea how common it is to share data between tracks. But assuming two subtitle tracks would share data the PID would have to be the same (or they have nothing in common to share from) The composition ID and ancillary ID can just be thought of as filters. If a subtitle packet with an ID matches any of those two IDs it would be displayed. Reading the spec PDF i posted in my previous mail may clarify a bit. > > But it's clear that the goal of sharing data between tracks is an > interresting one. In clean Matroska there could be different ways to do > that: > > - use 2 tracks and "chapter codec" to switch between one track or the > other given the position. That's quite inconvenient to handle and not > really in the stream itself. So I don't think it should be done that way. > > - use virtual tracks, or rather regular tracks but with virtual blocks. > There used to be BlockVirtual for that. But the design is not clean and > is deprecated. Plus it's not exactly what we want here. So we need > something new. We recently added TrackDepdency for 3D playback. That's a > way to combine 2 "mono" tracks to make a "stereo" one. The same could be > done with subtitles. The TrackDependency creating a new track on its > own, by combining 2 existing tracks. > > So in this case there would be 3 actual tracks: > - 1: english > - 2: english for hearing impaired > - 3: common data between 1 and 2 > > None of these tracks are really usable as they are and should be marked > as such (the Track FlagEnabled set to 0). And 2 TrackDependency would > define the actual mix of 1+3 and 2+3 for actual playback. That means > TrackDependency has to be enhanced/tuned to allow something like this. > > Did I miss anything or didn't understand correctly the goal here ? No, I think you got it. As I said I've no idea how common it is to share data between tracks in the DVB real world. My gut feeling is that it isn't that common (I've never seen it in the wild). My suggestion is to leave the track sharing out of the picture for subtitles (which, after all, isn't that data intensive). One alternative would be to make the Codec Private Data optional basically saying that: - If no Private Data is present the packets must be pre-filtered by the muxing application - If Privade Data is present (4 bytes with 2 x 16bit of those IDs) the decoder should apply filtering. The only opensource decoder I've used for decoding DVB subtitles (FFmpeg) already works in exactly this way. > > Steve > > On Mon, Aug 23, 2010 at 10:33 AM, Andreas ?man > wrote: > > On 08/23/2010 09:10 AM, Moritz Bunkus wrote: > > Hey ho, > > On Monday 23 August 2010 09:00:06 Andreas ?man wrote: > > I also suggest (based on some discussion on IRC) that no > extradata is > added with composition and ancillary ID, but rather that the > muxing > application must filter the subtitle segments before muxing. > > > With "extradata" he means the following: > > In a MPEG transport stream DVBSUBs are prefixed with four bytes > of data > providing a sub-stream ID. That way several streams inside that > DVBSUB > stream can be identified. Think of tracks in tracks. > > > Not really, those 4 bytes (2 16bit values) are from the PMT. > > > For Matroska I objected to storing streams that way as you only > have one > logical track in a Matroska track. Therefore the proposal to > drop those > four bytes and to use only one DVBSUB sub-stream in a single > Matroska > track. > > I totally agree with that :) > > As this is my first contact with the list; Did I miss anything? > > > Does that codec need any codec extra data (Matroska element > 'CodecPrivate')? > > > That was the "extradata" i was referring to above. > > Perhaps a bit of clarification is in place. > > The reason for having these composition-ID and ancillary-ID > discriminators is to allow sharing of subtitle data between tracks. > > A good use of this is subtitles for hearing impaired. > An example how this works (with MPEG TS multiplexing): > > In the MPEG PMT you would have two subtitle streams > "English" > PID 1234 > composition ID = 1 > ancillary ID = 0 > > "English for hearing impaired" > PID 1234 > composition ID = 1 > ancillary ID = 2 > > Thus, in PID 1234 you would send normal text segments with > segment ID 1 and hearing impaired related segments with ID 2. > Effectively allowing two tracks to share most of the data. > > Now, when re-multiplexing this into the MKV container you > have a few options. > > 1) Write down all packets in two tracks and attach the > composition and ancillary ID as 4 bytes of codec private data. > This is obviously a bit inefficient when it comes to file size. > > 2) Pre-filter the data so the packet only contain segments > assigned to the track and disallow any codec private data. > > 3) Use codec private data and somehow share packets between > tracks. I don't think that's possible with Matroska? Even so, > would any player actually support it? > > Note that the term 'segment' here refers to "subpackets" in the > DVB subtitle packet. > > Also, if anyone is further interested here is a URL to the spec. > > http://broadcasting.ru/pdf-standard-specifications/subtitling/dvb-sub/en300743.v1.2.1.pdf > > > Regards, > Mosu > > > > > > _______________________________________________ > Matroska-devel mailing list > Matroska-devel at lists.matroska.org > > http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel > Read Matroska-Devel on GMane: > http://dir.gmane.org/gmane.comp.multimedia.matroska.devel > > > _______________________________________________ > Matroska-devel mailing list > Matroska-devel at lists.matroska.org > > http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel > Read Matroska-Devel on GMane: > http://dir.gmane.org/gmane.comp.multimedia.matroska.devel > > > > > _______________________________________________ > Matroska-devel mailing list > Matroska-devel at lists.matroska.org > http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel > Read Matroska-Devel on GMane: http://dir.gmane.org/gmane.comp.multimedia.matroska.devel From liminw at gmail.com Mon Aug 30 11:15:33 2010 From: liminw at gmail.com (Lance Wang) Date: Mon, 30 Aug 2010 17:15:33 +0800 Subject: [Matroska-devel] [bug report] HaaliSplitter can't get video stream from one mpeg ts file Message-ID: Hi developer, I have got one mpeg ts file, the video can't be displayed by HaaliSplitter. With graphedit, I can see audio filter only. But the file is played very well with vlc, coreplayer, mplayer. Please help to check whether it's bug of haalisplitter. I have upload the file to below link: http://depositfiles.com/files/vfy0q36hp Thanks, lance -------------- next part -------------- An HTML attachment was scrubbed... URL: From slhomme at matroska.org Tue Aug 31 20:46:58 2010 From: slhomme at matroska.org (Steve Lhomme) Date: Tue, 31 Aug 2010 20:46:58 +0200 Subject: [Matroska-devel] S_DVBSUB In-Reply-To: <4C7AC93D.1020507@lonelycoder.com> References: <4C721C76.6050604@lonelycoder.com> <201008230910.06519.moritz@bunkus.org> <4C723265.6040107@lonelycoder.com> <4C7AC93D.1020507@lonelycoder.com> Message-ID: > > As I said I've no idea how common it is to share data between tracks > in the DVB real world. My gut feeling is that it isn't that common (I've > never seen it in the wild). My suggestion is to leave the track sharing > out of the picture for subtitles (which, after all, isn't that data > intensive). > > One alternative would be to make the Codec Private Data optional > basically saying that: > > - If no Private Data is present the packets must be pre-filtered by the > muxing application > > - If Privade Data is present (4 bytes with 2 x 16bit of those IDs) the > decoder should apply filtering. > > The only opensource decoder I've used for decoding DVB subtitles > (FFmpeg) already works in exactly this way. > That sounds more like a hack rather than a clean solution. In Matroska we already need to mix independent tracks together for 3D videos. So I will define something more generic that works for both and hopefully more cases that could arise in the future. The Codec Private is precisely private to the codec and should not be interpreted at the container level. -------------- next part -------------- An HTML attachment was scrubbed... URL: From slhomme at matroska.org Tue Aug 31 20:56:03 2010 From: slhomme at matroska.org (Steve Lhomme) Date: Tue, 31 Aug 2010 20:56:03 +0200 Subject: [Matroska-devel] and Tags In-Reply-To: References: Message-ID: 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From slhomme at matroska.org Tue Aug 31 21:19:04 2010 From: slhomme at matroska.org (Steve Lhomme) Date: Tue, 31 Aug 2010 21:19:04 +0200 Subject: [Matroska-devel] Bug in mkWDclean? In-Reply-To: <4C7A8161.9030504@ebenholz.co.uk> References: <4C7A8161.9030504@ebenholz.co.uk> Message-ID: Hi Alan, Thanks for the report. I see an issue with a large file here. It doesn't seem to be immediatly related to the 2 GB limit (as it happens before). But I will investigate and post a fix when I have one. Steve On Sun, Aug 29, 2010 at 5:48 PM, Alan wrote: > Hi folks, > > I seem to have found a bug in the latest versions of the mkWDclean tool - > the Windows 32-bit version, running under Windows XP. > > Releases 0.5.4 and 0.5.5 both stop processing when the output file gets > close to 2Gb in size. However, version 0.5.3 works OK. > > The 0.5.4 and 0.5.5 versions of the mkclean tool do not have this error - > but these don't address the "compressed header / media player compatibility" > issue. > > From my dark and distant programming past, I suspect versions 0.5.4 and > 0.5.5 of mkWDclean.exe may have been compiled using a library that doesn't > support writing file sizes greater than 2Gb. > > Incidentally, the program doesn't crash or give an error message. It just > finishes showing the phase 2/2 status as a percentage less than 100%. > > I hope this helps - and thanks for a very useful tool! > > Alan > > _______________________________________________ > 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: