From ru.bizarre at gmail.com Mon Jan 1 06:24:36 2007 From: ru.bizarre at gmail.com (Bizarre) Date: Mon, 1 Jan 2007 08:24:36 +0300 Subject: [Matroska-devel] Splitter bug report Message-ID: Hi! First things first, thank you for your work, the software is great and i'd probably jump off the roof if it didnt exist =) But there is a bug in latest version. When trying to playback "chained" ogg file (which consists of several parts), it plays only first one and stops. And timebar isnt working. Tried changing the vorbis codec - CoreVorbis 1.1.0.79 and FFDShow rev 2546 built-in both didnt help. Such files are surely playable since winamp and the pda player TCPMP can handle em. Attaching the example file (3 parts) in case u need one. Try to fix the thing please :) PS Happy New Year!! -------------- next part -------------- A non-text attachment was scrubbed... Name: 11. Here I Come (Barrington Levy).ogg Type: application/ogg Size: 3787240 bytes Desc: not available URL: From chris at matroska.org Mon Jan 1 10:51:49 2007 From: chris at matroska.org (Christian HJ Wiesner) Date: Mon, 01 Jan 2007 10:51:49 +0100 Subject: [Matroska-devel] Re: Matroska In-Reply-To: References: Message-ID: <4598D9B5.8030505@matroska.org> Dear Igor, unfortunately i have little time left to invest into matroska right now. I forward this email to matroska-devel AT lists DOT matroska DOT org, our official developer email list. I hope somebody there can help you, especially Mike 'Haali' Matsnev who is also from Russia and a real master of matroska. Please subscribe to this list and direct all requests to there in future, rather than mailing individual members of the team. Christian matroska project admin Igor Hlyupin schrieb: > Hello, Christian. > I am very interested in matroska project. I plan to develop a player the same as fluxDVD (ratDVD) based on matroska container. I`ve read a post of Splinter.bk (ratDVD developer and moderator) where he answered on your questions: > > I think the one thing that matroska isn't very well suited is to represent a complete DVD as intermediate format like ratDVD. Especially the step to go back to a DVD from the intermediate format I could imagine a being a problem. When you continue in > to this direction you will probably find that you need some more information (especially in-stream) than you collect today." > > He wrote it more then one year ago. Is a conversion of DVD format to mkv and vice versa really works correctly? What is better - DVDMenuXtractor or libdvdnav? > I plan use matroska as container, USF as subtitles standard and MPEG-4 AVC as codec of video in .mkv. To develop this I need an open code of utilities to extract menu, audio and video from DVD (is it a DVDMenuXtractor?), convert mpeg-2 into H264, ma > y by convert audio formats, create .mkv file and then restore DVD from mkv. Are there any tools that could do it and can I get an open source of such tools to include them in my development? If there is no such programs could you tell me what open sour > ce tools I must use to develop it? > In future I plan to include in this player an Avivo Video Converter (AvivoXCode) to decrease the time of conversion for users who have ATI videocard. Do you have any developments of such tool? > May be you know developers of Matroska or developers of such video players and codecs who can consult me or can develop what I need? May be some of them live in Russia? > > Yours faithfully, > Igor Hlyupin, tri777ki at mail.ru, +7 903 776 18 37, Russia, Moscow > > > From steve.lhomme at free.fr Tue Jan 2 10:47:41 2007 From: steve.lhomme at free.fr (Steve Lhomme) Date: Tue, 02 Jan 2007 10:47:41 +0100 Subject: [Matroska-devel] Re: Matroska In-Reply-To: <4598D9B5.8030505@matroska.org> References: <4598D9B5.8030505@matroska.org> Message-ID: <459A2A3D.5050505@free.fr> Christian HJ Wiesner wrote: > Dear Igor, > > unfortunately i have little time left to invest into matroska right now. > I forward this email to matroska-devel AT lists DOT matroska DOT org, > our official developer email list. I hope somebody there can help you, > especially Mike 'Haali' Matsnev who is also from Russia and a real > master of matroska. Please subscribe to this list and direct all > requests to there in future, rather than mailing individual members of > the team. > > Christian > matroska project admin > > Igor Hlyupin schrieb: >> Hello, Christian. >> I am very interested in matroska project. I plan to develop a player >> the same as fluxDVD (ratDVD) based on matroska container. I`ve read a >> post of Splinter.bk (ratDVD developer and moderator) where he answered >> on your questions: >> >> I think the one thing that matroska isn't very well suited is to >> represent a complete DVD as intermediate format like ratDVD. >> Especially the step to go back to a DVD from the intermediate format I >> could imagine a being a problem. When you continue in >> to this direction you will probably find that you need some more >> information (especially in-stream) than you collect today." >> >> He wrote it more then one year ago. Is a conversion of DVD format to >> mkv and vice versa really works correctly? What is better - >> DVDMenuXtractor or libdvdnav? DVDMenuXtractor. The goal of the DVD menu in matroska is to keep as much as possible from the DVD. So that the conversion DVD->MKV->DVD loses as few information as possible. This is mostly the case. The only thing that is not mapped as in a DVD is static frames (bitmaps in menu) which are just looped and forced subtitles (that don't exist yet in matroska). Also it's possible to do a quite good DVD->MKV conversion, there is no tool right now to do MKV->DVD. >> I plan use matroska as container, USF as subtitles standard and >> MPEG-4 AVC as codec of video in .mkv. To develop this I need an open >> code of utilities to extract menu, audio and video from DVD (is it a >> DVDMenuXtractor?), convert mpeg-2 into H264, ma >> y by convert audio formats, create .mkv file and then restore DVD >> from mkv. Are there any tools that could do it and can I get an open >> source of such tools to include them in my development? If there is no >> such programs could you tell me what open sour >> ce tools I must use to develop it? >> In future I plan to include in this player an Avivo Video Converter >> (AvivoXCode) to decrease the time of conversion for users who have ATI >> videocard. Do you have any developments of such tool? >> May be you know developers of Matroska or developers of such video >> players and codecs who can consult me or can develop what I need? May >> be some of them live in Russia? If you're willing to pay people to develop the missing parts, you should contact CoreCodec who's "managing" some of the matroska devs and surely would like such tools to exist too. Steve From steve.lhomme at free.fr Tue Jan 2 12:04:31 2007 From: steve.lhomme at free.fr (Steve Lhomme) Date: Tue, 02 Jan 2007 12:04:31 +0100 Subject: [Matroska-devel] AVCHD (.m2ts) support In-Reply-To: <012701c70f31$4460d7c0$6901a8c0@unknown> References: <012701c70f31$4460d7c0$6901a8c0@unknown> Message-ID: <459A3C3F.8050101@free.fr> Andrey wrote: > Dear Dev Team, > > > > Are there any plans to support AVCHD (.m2ts) files in Haali Media > Splitter? Those files are produced by Sony HDR-SR1 camcorder. Can you provide a small sample file ? I think it would be nice to support it (as well as clean DV support that I wanted to do but never found the time). Steve From steve.lhomme at free.fr Tue Jan 2 12:02:12 2007 From: steve.lhomme at free.fr (Steve Lhomme) Date: Tue, 02 Jan 2007 12:02:12 +0100 Subject: [Matroska-devel] Request: MKV (matroska) writer plugin ? In-Reply-To: <757509610612140355m536f4f98i36f159858a3f0af5@mail.gmail.com> References: <757509610612140355m536f4f98i36f159858a3f0af5@mail.gmail.com> Message-ID: <459A3BB4.1020709@free.fr> Ryan Dunbar wrote: > Hi, > > any luck with this idea? > > can it be done? For what application/framework ? It surely can be done either in C or C++ as we have libraries to do that. Steve From adam.nylander at gmail.com Thu Jan 4 22:55:18 2007 From: adam.nylander at gmail.com (Adam Nylander) Date: Thu, 4 Jan 2007 22:55:18 +0100 Subject: [Matroska-devel] Mac OS X Message-ID: <4349B825-D418-4F35-8750-52317A2460F0@gmail.com> Hi, I wonder if you have any plans on creating a mac quicktime component, the mac community is becoming bigger and bigger, even though there is VLC and MPlayer available it would be great to be able too use QuickTime + FrontRow. Yours Sincerly, Adam From steve.lhomme at free.fr Fri Jan 5 09:52:07 2007 From: steve.lhomme at free.fr (Steve Lhomme) Date: Fri, 05 Jan 2007 09:52:07 +0100 Subject: [Matroska-devel] Mac OS X In-Reply-To: <4349B825-D418-4F35-8750-52317A2460F0@gmail.com> References: <4349B825-D418-4F35-8750-52317A2460F0@gmail.com> Message-ID: <459E11B7.9040200@free.fr> Adam Nylander wrote: > Hi, > > I wonder if you have any plans on creating a mac quicktime component, > the mac community is becoming bigger and bigger, even though there is > VLC and MPlayer available it would be great to be able too use QuickTime > + FrontRow. I wish. But we lack a developper to do it. There was an attempt a few months ago but no news since then... Steve From steve.lhomme at free.fr Mon Jan 8 13:35:02 2007 From: steve.lhomme at free.fr (Steve Lhomme) Date: Mon, 08 Jan 2007 13:35:02 +0100 Subject: [Matroska-devel] CoreMake & UTF-8 Message-ID: <45A23A76.9090603@free.fr> Hi, I'm in the process of adding CoreMake support to mkvtoolnix. This will make it easier to generate MSVC projects but only compile on OS X using XCode, support for kdevelop, etc. There are a lot of dependencies but I have most of them covered. There's iconv that I'm not sure I should add on Windows. We used it in DrDivX but later realised the code would be much smaller&easier if we used the native Win32 conversions. So is it OK generate code to use the Windows conversion functions instead of iconv on windows ? Steve -- robUx4 on blog From steve.lhomme at free.fr Mon Jan 8 14:13:24 2007 From: steve.lhomme at free.fr (Steve Lhomme) Date: Mon, 08 Jan 2007 14:13:24 +0100 Subject: [Matroska-devel] CoreMake & UTF-8 In-Reply-To: <45A23A76.9090603@free.fr> References: <45A23A76.9090603@free.fr> Message-ID: <45A24374.9070308@free.fr> Steve Lhomme wrote: > Hi, > > I'm in the process of adding CoreMake support to mkvtoolnix. This will > make it easier to generate MSVC projects but only compile on OS X using > XCode, support for kdevelop, etc. > > There are a lot of dependencies but I have most of them covered. There's > iconv that I'm not sure I should add on Windows. We used it in DrDivX > but later realised the code would be much smaller&easier if we used the > native Win32 conversions. So is it OK generate code to use the Windows > conversion functions instead of iconv on windows ? PS: This question is for Mosu, obviously. Steve From yann.renard-mailing-lists at tiscali.fr Mon Jan 8 16:03:15 2007 From: yann.renard-mailing-lists at tiscali.fr (Yann Renard) Date: Mon, 08 Jan 2007 16:03:15 +0100 Subject: [Matroska-devel] Would more StereoMode values be useful or needed? In-Reply-To: <20061207233830.19753.qmail@web27205.mail.ukl.yahoo.com> References: <20061207233830.19753.qmail@web27205.mail.ukl.yahoo.com> Message-ID: <45A25D33.4050404@tiscali.fr> David Duffy wrote: > Currently StereoMode supports mono, right, left, and both. > Should there be either another element or more values to designate over/under vs. side by side vs. alternating frames (and of course which comes first, left or right) when the setting is "both eyes"? > Would you consider that information to be useless to a reader since perhaps the video codec(s) should be responsible...? > > I can see a use for designating what the stereoscopic format is beyond just "both eyes" because then the following would be possible: > - demux could specify two video out pins and send alternating frames on alternating pins just as if there had been two streams one for left and one for right (I know, the user "shouldn't" encode that way perhaps but it would be doable and there could be reasons for doing it). > - in systems where the video decoder could be "notified" of the format it would be advantageous. I can't speak for VFW off hand but I could certainly use it in the hardware player stuff I'm working on (currently I'm encoding as side by side left/right for efficiency and assuming that I will receive left/right but the option to do over/under or right/left and know which it was for sure without making assumptions would be nice). > - it is more efficient for encoding/decoding to have combined frames (either over/under or side by side) so as not to have to create two decoder instances. So app writers could use whatever the latest and greatest video codec is (or whichever they want) without needing any special 3D support in the codec itself; and then because they know from the Matroska file that the frames are a certain orientation they would know how to interpret the decoded frame to get the desired 3D effect. > > I think it might be "cleaner" to have an optional (sub) element to designate the frame orientation for combined "both eyes" frames but it would be easier to just add more values to StereoMode. > > What do you all think? > > Thanks, > David Dear David and mailing list, first happy new year every one ! Now, I am not sure this email will answer your initial question, but I hope it will help the discussion in some way. I have been working on 3D visualisation for several years and have had the chance to test both software and hardware 3D visualisation tools. Concerning what you call stereo mode, I suggest to expand the concept of stereoscopy to relief perception in visualisation context. Let me explain : relief visualisation consists in generating a picture for each eye with correct perspective correction so the viewer can feel the depth. Stereoscopy consists in generating *two* pictures, one for the left eye, one for the right eye. Given this two pictures, the probleme is to know how one can get the left picture on the left eye and on this eye only, and the same for the right picture/eye. Usually two approaches exist with common hardware : - left/right or top/left positionning of the picture with overlapped polarized pictures and glasses or head mounted device - alternated left then right picture with shutter glasses (this needs quadbuffering but this is now "common" on PCs). Now some more recent techniques exist to output these two pictures such as autostereoscopy . Brief explanation is stereoscopy without glasses. The display is combined with some kind of filter so visulisation cones are projected to the user. The user then places himself so the left eye is in a left picture cone, and the right eye is in a right picture cone. The filter can be based on lenticular lenses or parralax barrier for example. Such stereoscopic displays have advantages of no glass but have the problem of the user to be placed correctly regarding the projection surface. For 3D interactive visualisation, this is the state of the art... But this technology is already applied to fixed posters and should be easily applied to videos and later to 3D interactive visualisation with more precision. The idea is to generate more viewpoints so the user can move wider with his eyes staying in a correct pair of cones/pictures. For printed posters, I have seen some 64 viewpoints photos that looked really impressives ! Of course, the viewpoints are interlaced in a specified way and this is no more a matter of top/bottom nor left/right projection ! Ok now, to go back on the initial topic, with such visualisation method, you understand that relief perception of a video may consist in multiple streams (I mean really more than two). Matroska may take this into account but I don't know how exactly ;) Would this be storing the different locations of the viewpoints in a specified 3D space ? Hope this helps a bit, sorry for my english, it was hard to explain all this in english but I did my best ! No time now to add pointers on reference websites... Best regards Yann Renard From moritz at bunkus.org Mon Jan 8 17:26:28 2007 From: moritz at bunkus.org (Moritz Bunkus) Date: Mon, 8 Jan 2007 17:26:28 +0100 Subject: [Matroska-devel] CoreMake & UTF-8 In-Reply-To: <45A23A76.9090603@free.fr> References: <45A23A76.9090603@free.fr> Message-ID: <200701081726.33566.moritz@bunkus.org> Hey, On Monday 08 January 2007 13:35, Steve Lhomme wrote: > There are a lot of dependencies but I have most of them > covered. There's iconv that I'm not sure I should add on Windows. We > used it in DrDivX but later realised the code would be much > smaller&easier if we used the native Win32 conversions. So is it OK > generate code to use the Windows conversion functions instead of iconv > on windows ? Sure, why not? Is it possible to get a list of supported charsets from Windows? That's how the drop-down boxes in mmg are filled: mmg gets the list from iconv and puts it into the drop-down-box. 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: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From steve.lhomme at free.fr Mon Jan 8 19:05:36 2007 From: steve.lhomme at free.fr (Steve Lhomme) Date: Mon, 08 Jan 2007 19:05:36 +0100 Subject: [Matroska-devel] CoreMake & UTF-8 In-Reply-To: <200701081726.33566.moritz@bunkus.org> References: <45A23A76.9090603@free.fr> <200701081726.33566.moritz@bunkus.org> Message-ID: <45A287F0.1000304@free.fr> Moritz Bunkus wrote: > Hey, > > On Monday 08 January 2007 13:35, Steve Lhomme wrote: > >> There are a lot of dependencies but I have most of them >> covered. There's iconv that I'm not sure I should add on Windows. We >> used it in DrDivX but later realised the code would be much >> smaller&easier if we used the native Win32 conversions. So is it OK >> generate code to use the Windows conversion functions instead of iconv >> on windows ? > > Sure, why not? Is it possible to get a list of supported charsets from > Windows? That's how the drop-down boxes in mmg are filled: mmg gets the > list from iconv and puts it into the drop-down-box. I'll let you know as I try to implement it :) Steve From davidnduffy at yahoo.co.uk Mon Jan 8 20:09:19 2007 From: davidnduffy at yahoo.co.uk (David Duffy) Date: Mon, 8 Jan 2007 19:09:19 +0000 (GMT) Subject: [Matroska-devel] Would more StereoMode values be useful or needed? Message-ID: <20070108190919.70873.qmail@web27206.mail.ukl.yahoo.com> That is a very interesting idea, I hadn't thought of more than just the two images for left and right eye. I think that to store 64 different viewpoints and be able to tell what each one is and where it should go would definitely require more detailed fields/values than the current StereoMode supports. I'm not sure what that would look like, perhaps StereoMode should be a flag of only true/false and another property(ies) for positioning? Something that could denote simply left/right eye and/or greater precision to get your 64 viewpoints? Maybe that would require several properties in an optional hierarchy under StereoMode? What does everyone think? ----- Original Message ---- From: Yann Renard To: Discussion about the current and future development of Matroska Sent: Monday, 8 January, 2007 8:03:15 AM Subject: Re: [Matroska-devel] Would more StereoMode values be useful or needed? David Duffy wrote: > Currently StereoMode supports mono, right, left, and both. > Should there be either another element or more values to designate over/under vs. side by side vs. alternating frames (and of course which comes first, left or right) when the setting is "both eyes"? > Would you consider that information to be useless to a reader since perhaps the video codec(s) should be responsible...? > > I can see a use for designating what the stereoscopic format is beyond just "both eyes" because then the following would be possible: > - demux could specify two video out pins and send alternating frames on alternating pins just as if there had been two streams one for left and one for right (I know, the user "shouldn't" encode that way perhaps but it would be doable and there could be reasons for doing it). > - in systems where the video decoder could be "notified" of the format it would be advantageous. I can't speak for VFW off hand but I could certainly use it in the hardware player stuff I'm working on (currently I'm encoding as side by side left/right for efficiency and assuming that I will receive left/right but the option to do over/under or right/left and know which it was for sure without making assumptions would be nice). > - it is more efficient for encoding/decoding to have combined frames (either over/under or side by side) so as not to have to create two decoder instances. So app writers could use whatever the latest and greatest video codec is (or whichever they want) without needing any special 3D support in the codec itself; and then because they know from the Matroska file that the frames are a certain orientation they would know how to interpret the decoded frame to get the desired 3D effect. > > I think it might be "cleaner" to have an optional (sub) element to designate the frame orientation for combined "both eyes" frames but it would be easier to just add more values to StereoMode. > > What do you all think? > > Thanks, > David Dear David and mailing list, first happy new year every one ! Now, I am not sure this email will answer your initial question, but I hope it will help the discussion in some way. I have been working on 3D visualisation for several years and have had the chance to test both software and hardware 3D visualisation tools. Concerning what you call stereo mode, I suggest to expand the concept of stereoscopy to relief perception in visualisation context. Let me explain : relief visualisation consists in generating a picture for each eye with correct perspective correction so the viewer can feel the depth. Stereoscopy consists in generating *two* pictures, one for the left eye, one for the right eye. Given this two pictures, the probleme is to know how one can get the left picture on the left eye and on this eye only, and the same for the right picture/eye. Usually two approaches exist with common hardware : - left/right or top/left positionning of the picture with overlapped polarized pictures and glasses or head mounted device - alternated left then right picture with shutter glasses (this needs quadbuffering but this is now "common" on PCs). Now some more recent techniques exist to output these two pictures such as autostereoscopy . Brief explanation is stereoscopy without glasses. The display is combined with some kind of filter so visulisation cones are projected to the user. The user then places himself so the left eye is in a left picture cone, and the right eye is in a right picture cone. The filter can be based on lenticular lenses or parralax barrier for example. Such stereoscopic displays have advantages of no glass but have the problem of the user to be placed correctly regarding the projection surface. For 3D interactive visualisation, this is the state of the art... But this technology is already applied to fixed posters and should be easily applied to videos and later to 3D interactive visualisation with more precision. The idea is to generate more viewpoints so the user can move wider with his eyes staying in a correct pair of cones/pictures. For printed posters, I have seen some 64 viewpoints photos that looked really impressives ! Of course, the viewpoints are interlaced in a specified way and this is no more a matter of top/bottom nor left/right projection ! Ok now, to go back on the initial topic, with such visualisation method, you understand that relief perception of a video may consist in multiple streams (I mean really more than two). Matroska may take this into account but I don't know how exactly ;) Would this be storing the different locations of the viewpoints in a specified 3D space ? Hope this helps a bit, sorry for my english, it was hard to explain all this in english but I did my best ! No time now to add pointers on reference websites... Best regards Yann Renard _______________________________________________ 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 Send instant messages to your online friends http://uk.messenger.yahoo.com From steve.lhomme at free.fr Thu Jan 11 14:19:23 2007 From: steve.lhomme at free.fr (Steve Lhomme) Date: Thu, 11 Jan 2007 14:19:23 +0100 Subject: [Matroska-devel] CoreMake & UTF-8 In-Reply-To: <200701081726.33566.moritz@bunkus.org> References: <45A23A76.9090603@free.fr> <200701081726.33566.moritz@bunkus.org> Message-ID: <45A6395B.5070101@free.fr> Moritz Bunkus wrote: > Hey, > > On Monday 08 January 2007 13:35, Steve Lhomme wrote: > >> There are a lot of dependencies but I have most of them >> covered. There's iconv that I'm not sure I should add on Windows. We >> used it in DrDivX but later realised the code would be much >> smaller&easier if we used the native Win32 conversions. So is it OK >> generate code to use the Windows conversion functions instead of iconv >> on windows ? > > Sure, why not? Is it possible to get a list of supported charsets from > Windows? That's how the drop-down boxes in mmg are filled: mmg gets the > list from iconv and puts it into the drop-down-box. Yes, I found it: EnumSystemCodePages() http://msdn.microsoft.com/library/en-us/intl/nls_65rn.asp Steve From moritz at bunkus.org Sun Jan 14 00:12:42 2007 From: moritz at bunkus.org (Moritz Bunkus) Date: Sun, 14 Jan 2007 00:12:42 +0100 Subject: [Matroska-devel] CodecState and CueCodecState Message-ID: <200701140012.45627.moritz@bunkus.org> Hey, Mike (Haali) pointed out to me that keeping the sequence headers in the bitstream for MPEG-1/-2 video poses a problem when seeking. He proposed that we switch to using CodecState which has been created for just such a case. Now I started working on it and noticed a couple of things. 1. KaxCodecState does not exist yet in libmatroska. I've added it and will commit the code soon. 2. CodecState is a child of BlockGroup. However, the specs don't say clearly when exactly CodecState is supposed to take effect. I propose that it must be processed by the codec _before_ the data in the same BlockGroup is processed, even if the Block element is located before the CodecState element in the same BlockGroup. 3. CueCodecState is supposed to point to a CodecState element. However, the CodecState element itself does not contain a track number it applies to; only the Block in the same BlockGroup does. I propose to change the spec so that CueCodecState points to the _BlockGroup_ containing this CodecState element. Otherwise the demuxer would have to do some real, real bad seeking backwards in order to find the BlockGroup. Comments? 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: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From spyder482 at gmail.com Sun Jan 14 00:44:04 2007 From: spyder482 at gmail.com (John Cannon) Date: Sat, 13 Jan 2007 17:44:04 -0600 Subject: [Matroska-devel] CodecState and CueCodecState In-Reply-To: <200701140012.45627.moritz@bunkus.org> References: <200701140012.45627.moritz@bunkus.org> Message-ID: <98513bea0701131544j3c1da04eocbc3da3f38b0d413@mail.gmail.com> Hey, I know it's been a LONG time since I've popped my head in here. :) The original reasoning behind removing the sequence headers was to put them in the codec state elements. Since they didn't exist we just never bothered with them. In my mind, it shouldn't matter if the headers do remain in the stream since they are part of the data the decoder expects. However, removing them entirely obviously creates playback issues. John On 1/13/07, Moritz Bunkus wrote: > > Hey, > > Mike (Haali) pointed out to me that keeping the sequence headers in the > bitstream for MPEG-1/-2 video poses a problem when seeking. He proposed > that we switch to using CodecState which has been created for just such > a case. > > Now I started working on it and noticed a couple of things. > > 1. KaxCodecState does not exist yet in libmatroska. I've added it and > will commit the code soon. > > 2. CodecState is a child of BlockGroup. However, the specs don't say > clearly when exactly CodecState is supposed to take effect. I propose > that it must be processed by the codec _before_ the data in the same > BlockGroup is processed, even if the Block element is located before > the CodecState element in the same BlockGroup. > > 3. CueCodecState is supposed to point to a CodecState element. However, > the CodecState element itself does not contain a track number it > applies to; only the Block in the same BlockGroup does. I propose to > change the spec so that CueCodecState points to the _BlockGroup_ > containing this CodecState element. Otherwise the demuxer would have > to do some real, real bad seeking backwards in order to find the > BlockGroup. > > Comments? > > 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 > > > -- John Cannon -------------- next part -------------- An HTML attachment was scrubbed... URL: From moritz at bunkus.org Sun Jan 14 01:09:03 2007 From: moritz at bunkus.org (Moritz Bunkus) Date: Sun, 14 Jan 2007 01:09:03 +0100 Subject: [Matroska-devel] CodecState and CueCodecState In-Reply-To: <200701140012.45627.moritz@bunkus.org> References: <200701140012.45627.moritz@bunkus.org> Message-ID: <200701140109.05736.moritz@bunkus.org> Hey, On Sunday 14 January 2007 00:12, Moritz Bunkus wrote: > 3. CueCodecState is supposed to point to a CodecState element. However, > the CodecState element itself does not contain a track number it > applies to; only the Block in the same BlockGroup does. I propose to > change the spec so that CueCodecState points to the _BlockGroup_ > containing this CodecState element. Otherwise the demuxer would have > to do some real, real bad seeking backwards in order to find the > BlockGroup. This is bullshit ;) We do have the CueTrack elements, so we don't need the Block in the BlockGroup if we just want to find the previous CodecState element after seeking. So let CueCodecState continue pointing directly at the CodecState element. 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: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From chris at matroska.org Sun Jan 14 08:16:35 2007 From: chris at matroska.org (Christian HJ Wiesner) Date: Sun, 14 Jan 2007 08:16:35 +0100 Subject: [Matroska-devel] CodecState and CueCodecState In-Reply-To: <200701140012.45627.moritz@bunkus.org> References: <200701140012.45627.moritz@bunkus.org> Message-ID: <45A9D8D3.8080802@matroska.org> Moritz Bunkus schrieb: > Hey, > > Mike (Haali) pointed out to me that keeping the sequence headers in the > bitstream for MPEG-1/-2 video poses a problem when seeking. He proposed > that we switch to using CodecState which has been created for just such > a case. > > Now I started working on it and noticed a couple of things. > > 1. KaxCodecState does not exist yet in libmatroska. I've added it and > will commit the code soon. > > 2. CodecState is a child of BlockGroup. However, the specs don't say > clearly when exactly CodecState is supposed to take effect. I propose > that it must be processed by the codec _before_ the data in the same > BlockGroup is processed, even if the Block element is located before > the CodecState element in the same BlockGroup. > > 3. CueCodecState is supposed to point to a CodecState element. However, > the CodecState element itself does not contain a track number it > applies to; only the Block in the same BlockGroup does. I propose to > change the spec so that CueCodecState points to the _BlockGroup_ > containing this CodecState element. Otherwise the demuxer would have > to do some real, real bad seeking backwards in order to find the > BlockGroup. > > Comments? > > Mosu > Do i understand correctly that 'CodecState' will allow to change picture resolution in the same video stream, once it is implemented ? What about changing number of audio channels in the same audio stream ? Possible ? Regards Christian From moritz at bunkus.org Sun Jan 14 10:27:44 2007 From: moritz at bunkus.org (Moritz Bunkus) Date: Sun, 14 Jan 2007 10:27:44 +0100 Subject: [Matroska-devel] CodecState and CueCodecState In-Reply-To: <45A9D8D3.8080802@matroska.org> References: <200701140012.45627.moritz@bunkus.org> <45A9D8D3.8080802@matroska.org> Message-ID: <200701141027.52355.moritz@bunkus.org> Hey Chris, On Sunday 14 January 2007 08:16, Christian HJ Wiesner wrote: > Do i understand correctly that 'CodecState' will allow to change > picture resolution in the same video stream, once it is implemented ? > What about changing number of audio channels in the same audio stream > ? Possible ? No. CodecState only overrides CodecPrivate. 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: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From steve.lhomme at free.fr Mon Jan 15 19:31:51 2007 From: steve.lhomme at free.fr (Steve Lhomme) Date: Mon, 15 Jan 2007 19:31:51 +0100 Subject: [Matroska-devel] CodecState and CueCodecState In-Reply-To: <200701141027.52355.moritz@bunkus.org> References: <200701140012.45627.moritz@bunkus.org> <45A9D8D3.8080802@matroska.org> <200701141027.52355.moritz@bunkus.org> Message-ID: <45ABC897.9010600@free.fr> Moritz Bunkus wrote: > Hey Chris, > > On Sunday 14 January 2007 08:16, Christian HJ Wiesner wrote: > >> Do i understand correctly that 'CodecState' will allow to change >> picture resolution in the same video stream, once it is implemented ? >> What about changing number of audio channels in the same audio stream >> ? Possible ? > > No. CodecState only overrides CodecPrivate. Indeed. From steve.lhomme at free.fr Mon Jan 15 19:32:57 2007 From: steve.lhomme at free.fr (Steve Lhomme) Date: Mon, 15 Jan 2007 19:32:57 +0100 Subject: [Matroska-devel] CodecState and CueCodecState In-Reply-To: <200701140012.45627.moritz@bunkus.org> References: <200701140012.45627.moritz@bunkus.org> Message-ID: <45ABC8D9.6050000@free.fr> Moritz Bunkus wrote: > Hey, > > Mike (Haali) pointed out to me that keeping the sequence headers in the > bitstream for MPEG-1/-2 video poses a problem when seeking. He proposed > that we switch to using CodecState which has been created for just such > a case. > > Now I started working on it and noticed a couple of things. > > 1. KaxCodecState does not exist yet in libmatroska. I've added it and > will commit the code soon. > > 2. CodecState is a child of BlockGroup. However, the specs don't say > clearly when exactly CodecState is supposed to take effect. I propose > that it must be processed by the codec _before_ the data in the same > BlockGroup is processed, even if the Block element is located before > the CodecState element in the same BlockGroup. > > Comments? I'm OK with all that, but doesn't it raise compatibility issues with the older files ? Since we expect something in CodecPrivate that is not there anymore ? Steve From moritz at bunkus.org Mon Jan 15 19:51:55 2007 From: moritz at bunkus.org (Moritz Bunkus) Date: Mon, 15 Jan 2007 19:51:55 +0100 Subject: [Matroska-devel] CodecState and CueCodecState In-Reply-To: <45ABC8D9.6050000@free.fr> References: <200701140012.45627.moritz@bunkus.org> <45ABC8D9.6050000@free.fr> Message-ID: <200701151951.57950.moritz@bunkus.org> Hey, On Monday 15 January 2007 19:32, Steve Lhomme wrote: > I'm OK with all that, but doesn't it raise compatibility issues with > the older files ? Since we expect something in CodecPrivate that is > not there anymore ? The idea is that CodecState is only used if the CodecPrivate changes in time. So far this will only be used for MPEG-1/-2 in which the sequence headers may change. Of course it destroys compatibility. That's why it will only be an option that the user has to "--engage" in mkvmerge. A couple of months later I'll make it the default. 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: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mike at po.cs.msu.su Mon Jan 15 20:09:43 2007 From: mike at po.cs.msu.su (Mike Matsnev) Date: Mon, 15 Jan 2007 22:09:43 +0300 Subject: [Matroska-devel] CodecState and CueCodecState In-Reply-To: <200701151951.57950.moritz@bunkus.org> References: <200701140012.45627.moritz@bunkus.org> <45ABC8D9.6050000@free.fr> <200701151951.57950.moritz@bunkus.org> Message-ID: <45ABD177.6010504@po.cs.msu.su> Moritz Bunkus wrote: >> I'm OK with all that, but doesn't it raise compatibility issues with >> the older files ? Since we expect something in CodecPrivate that is >> not there anymore ? > > The idea is that CodecState is only used if the CodecPrivate changes in > time. So far this will only be used for MPEG-1/-2 in which the sequence > headers may change. Of course it destroys compatibility. That's why it > will only be an option that the user has to "--engage" in mkvmerge. A > couple of months later I'll make it the default. I think initial seq header should be placed into CodecPrivate like it is now. Additional headers should go to CueCodecState. Also a copy of seq header can be left in video stream, this way sequential playback should work with existing splitters, and seeking should work with newer code. From moritz at bunkus.org Mon Jan 15 21:12:41 2007 From: moritz at bunkus.org (Moritz Bunkus) Date: Mon, 15 Jan 2007 21:12:41 +0100 Subject: [Matroska-devel] CodecState and CueCodecState In-Reply-To: <45ABD177.6010504@po.cs.msu.su> References: <200701140012.45627.moritz@bunkus.org> <200701151951.57950.moritz@bunkus.org> <45ABD177.6010504@po.cs.msu.su> Message-ID: <200701152112.44112.moritz@bunkus.org> Hey, On Monday 15 January 2007 20:09, Mike Matsnev wrote: > I think initial seq header should be placed into CodecPrivate like it > is now. Additional headers should go to CueCodecState. Also a copy of > seq header can be left in video stream, this way sequential playback > should work with existing splitters, and seeking should work with > newer code. (the following applies to "--engage use_codec_state") At the moment mkvmerge ONLY puts sequence headers into CodecState, and only when they change. mkvmerge also does not handle splitting correctly yet. I can change mkvmerge to work the way you proposed though, no problem at all. Your way is easily the the more backwards compatible way. 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: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From steve.lhomme at free.fr Fri Jan 19 10:51:12 2007 From: steve.lhomme at free.fr (Steve Lhomme) Date: Fri, 19 Jan 2007 10:51:12 +0100 Subject: [Matroska-devel] Coremake (part 1) Message-ID: <45B09490.8050705@free.fr> Hi Moritz, Here is the first part of the coremake'ing of mkvtoolnix. One patch is to include coremake in the source package so that it can be compiled on any platform and then used to generate the makefiles. The other patch describes mkvtoolnix to coremake to have all the packages, libs, etc. It's not finished because on windows all the dependencies are referencing an "import" directory that you don't have yet. That directory is supposed to be used as an SVN import directory. Each dependency lib having its own svn:externals directory. It may not be needed to have these libs on some platforms, but on windows it will be needed in the source package (maybe as a separate download). Some of the externals can be found on Sourceforge in the DrDivX SVN. But I'm thinking about creating a project somewhere (SourceForge, CoreForge, etc) that will have a dir for each of these dependencies. Maybe other people will use it too. To use coremake you need: - build coremake (gcc coremake/coremake.c -o coremake) - generate the config.h (./configure) - generate the makefiles you want (./coremake gcc_linux) (./coremake kdevelop) (./coremake vs_express) (./coremake vc6) (./coremake xcode) For the moment everything is statically linked in each exe (even wxWidgets). It's smaller than all separated and avoid dependency hell. It can be changed by changing the LIB command in .proj files into DLL. Steve -- robUx4 on blog -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: coremake-proj.patch URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: external-coremake.patch URL: From bzdvinea at yahoo.com Wed Jan 24 23:22:07 2007 From: bzdvinea at yahoo.com (Sbiera Ciprian) Date: Wed, 24 Jan 2007 14:22:07 -0800 (PST) Subject: [Matroska-devel] dts problem in mkv (modifies samplerate?) Message-ID: <201617.30609.qm@web52904.mail.yahoo.com> I was redirected from irc channel to this adress. The problem is as follows: A dts track from hddvd (riddick) when muxed in mkv becomes 4 seconds longer (the movie 154 mins) and goes out of sync. The xpl form disk sais it's DTS-HD (which from the specs I could find allows lots of channels and 96khz/24 bit). However ffdhsow, ac3 filter and foobar see it as a normal dts (and play it fine). I attach a small sample to look at it, maybe it helps improve some compatibility with this type of audio. I'll be on the channel as "sapiens" these days if you need me. ____________________________________________________________________________________ Do you Yahoo!? Everyone is raving about the all-new Yahoo! Mail beta. http://new.mail.yahoo.com -------------- next part -------------- A non-text attachment was scrubbed... Name: sample1 problem.dts Type: application/octet-stream Size: 5661768 bytes Desc: 1138820012-sample1 problem.dts URL: From steve.lhomme at free.fr Sun Jan 28 18:05:43 2007 From: steve.lhomme at free.fr (Steve Lhomme) Date: Sun, 28 Jan 2007 18:05:43 +0100 Subject: [Matroska-devel] Re: DMX In-Reply-To: <45BCD640.3090404@corecodec.com> References: <1d491811.18111d49@viragelogic.com> <45B35B59.2010107@corecodec.com> <45B4AB06.8030808@viragelogic.com> <45B4B29B.7010103@corecodec.com> <45B85D24.4010704@viragelogic.com> <45BCD640.3090404@corecodec.com> Message-ID: <45BCD7E7.8020107@free.fr> Steve Lhomme wrote: > Sergey Hakobyan wrote: >> Hi Steve! > > Hi Sergey, > >> I've finished changing DMX. >> Please review the changes so we could finalize the changes. I've also >> made small modification to coremake VS proj file so it defines >> QT_NO_DEBUG_OUTPUT with QT_NO_DEBUG. > > OK, I added the change to the official coremake (in vsproj for now). > >> After you review it please let me know, so that we could talk about >> the future of DMX (features/design/coding, etc...) > > I added the code in SVN so that hopefully other people will test it. I > also fixed the coremake project that wouldn't work here. Please have a > look and see if it works on your side. > > https://svn.matroska.org/svn/matroska/trunk/DvdMenuXtractor > > coremake is automatically imported from the "official" repository (on > matroska.org until it moves back to coreforge). You'll need to rebuild > it from this to make sure you're up to date. > > I only loaded the app, I didn't try any export and I'm running out of > space right now. But I'll give it a try soon. > > One of the things that we may change is do 2 exe, one for the > command-line and one for the GUI. Dunno if they should both be all > static or use a shared DLL. I usually prefer no DLL though. > > Among the things removed I noticed there is base64 that was used for the > DVD commands, are you using the Qt code for that ? I also noticed the > A52 decoder was removed but I think it wasn't used so it's not a big > problem. > > On the next steps there's compilation of the SVN on Linux and on OSX (I > will work on the OS X as I have added XCode support to coremake this week). PS: One of the things that should be fixed is Unicode support in libdvdread. Right now CONFIG_UNICODE is disabled in the config.h but it should be added ASAP. If anyone tries to use folders with accents or other fun things like that the problem will not for correctly. It probably involves hacking the code dirent.c to transform 8bit local names to wide chars. Steve From slhomme at corecodec.com Sun Jan 28 17:58:40 2007 From: slhomme at corecodec.com (Steve Lhomme) Date: Sun, 28 Jan 2007 17:58:40 +0100 Subject: [Matroska-devel] Re: DMX In-Reply-To: <45B85D24.4010704@viragelogic.com> References: <1d491811.18111d49@viragelogic.com> <45B35B59.2010107@corecodec.com> <45B4AB06.8030808@viragelogic.com> <45B4B29B.7010103@corecodec.com> <45B85D24.4010704@viragelogic.com> Message-ID: <45BCD640.3090404@corecodec.com> Sergey Hakobyan wrote: > Hi Steve! Hi Sergey, > I've finished changing DMX. > Please review the changes so we could finalize the changes. I've also > made small modification to coremake VS proj file so it defines > QT_NO_DEBUG_OUTPUT with QT_NO_DEBUG. OK, I added the change to the official coremake (in vsproj for now). > After you review it please let me know, so that we could talk about the > future of DMX (features/design/coding, etc...) I added the code in SVN so that hopefully other people will test it. I also fixed the coremake project that wouldn't work here. Please have a look and see if it works on your side. https://svn.matroska.org/svn/matroska/trunk/DvdMenuXtractor coremake is automatically imported from the "official" repository (on matroska.org until it moves back to coreforge). You'll need to rebuild it from this to make sure you're up to date. I only loaded the app, I didn't try any export and I'm running out of space right now. But I'll give it a try soon. One of the things that we may change is do 2 exe, one for the command-line and one for the GUI. Dunno if they should both be all static or use a shared DLL. I usually prefer no DLL though. Among the things removed I noticed there is base64 that was used for the DVD commands, are you using the Qt code for that ? I also noticed the A52 decoder was removed but I think it wasn't used so it's not a big problem. On the next steps there's compilation of the SVN on Linux and on OSX (I will work on the OS X as I have added XCode support to coremake this week). Steve -------------- next part -------------- A non-text attachment was scrubbed... Name: slhomme.vcf Type: text/x-vcard Size: 124 bytes Desc: not available URL: From sergey.hakobyan at viragelogic.com Tue Jan 30 10:02:43 2007 From: sergey.hakobyan at viragelogic.com (Sergey Hakobyan) Date: Tue, 30 Jan 2007 13:02:43 +0400 Subject: [Matroska-devel] Re: DMX In-Reply-To: <45BCD7E7.8020107@free.fr> References: <1d491811.18111d49@viragelogic.com> <45B35B59.2010107@corecodec.com> <45B4AB06.8030808@viragelogic.com> <45B4B29B.7010103@corecodec.com> <45B85D24.4010704@viragelogic.com> <45BCD640.3090404@corecodec.com> <45BCD7E7.8020107@free.fr> Message-ID: <45BF09B3.9070405@viragelogic.com> Hi Steve! Steve Lhomme wrote: > Steve Lhomme wrote: >> I added the code in SVN so that hopefully other people will test it. >> I also fixed the coremake project that wouldn't work here. Please >> have a look and see if it works on your side. >> https://svn.matroska.org/svn/matroska/trunk/DvdMenuXtractor >> coremake is automatically imported from the "official" repository (on >> matroska.org until it moves back to coreforge). You'll need to >> rebuild it from this to make sure you're up to date. >> I only loaded the app, I didn't try any export and I'm running out of >> space right now. But I'll give it a try soon. OK, I'll also checkout and work on SVN version. >> One of the things that we may change is do 2 exe, one for the >> command-line and one for the GUI. Dunno if they should both be all >> static or use a shared DLL. I usually prefer no DLL though. This should not be a problem to do. You can already specify command-line arguments, and extraction will run without GUI. >> Among the things removed I noticed there is base64 that was used for >> the DVD commands, are you using the Qt code for that ? I'll check this ASAP. >> I also noticed the A52 decoder was removed but I think it wasn't used >> so it's not a big problem. I remember A52 decoder to be there. Maybe I forgot to copy/move it. Anyway, I don't remember removing it intentionally, so I'll try to move it back. >> On the next steps there's compilation of the SVN on Linux and on OSX >> (I will work on the OS X as I have added XCode support to coremake >> this week). OK, I'll try to comply on Linux as well. > PS: One of the things that should be fixed is Unicode support in > libdvdread. Right now CONFIG_UNICODE is disabled in the config.h but > it should be added ASAP. If anyone tries to use folders with accents > or other fun things like that the problem will not for correctly. It > probably involves hacking the code dirent.c to transform 8bit local > names to wide chars. Added to TODO list :) Thanks, Sergey