From oleg.estekhin at mail.ru Tue Jul 1 11:09:30 2008 From: oleg.estekhin at mail.ru (Oleg Estekhin) Date: Tue, 01 Jul 2008 13:09:30 +0400 Subject: [Matroska-devel] ebml viewer with a small analysis capabilities Message-ID: Hi everybody. As a part of research of different ways to store binary data i created the EBML viewer-analyser application, written in Java. Initially i just wanted to check how much more space the real-world data will take if the storage format supports only signed integers compared to the format with both signed and unsigned integers. It turned out that the EBML in general and Matroska in particular is the only format that has both of the following properties: 1) the format has signed and unsigned integers; 2) i have a big collection of data in that format (mkv video in this case). In the end instead of writing simple analyser i wrote a program which can view the contents of the EBML files and calculate some statistics on the number of used elements and so on. The source code and executable Java jar file is available from http://code.google.com/p/ebml-viewer/. To start the program double-click the ebml-viewer-1.0.jar inside the unpacked /lib of ebml-viewer-1.0-bin.zip. The manual is absent, so just a couple of comments on available menu commands: 1) "open file" will both parse the file and open a tree with the file contents. 2) "parse file" will only parse the file for the sake of collecting statistics. 3) "edit/element list" allows to configure whether the content of some container element should be displayed in the tree view. Regardless of these settings all containers will be parsed, so this is just the filter for a file structure tree. Creating the complete tree view of a 250mb file requires 20 to 30 mb of memory, which leads to the fact that the viewer can display only a limited number of files before throwing OutOfMemoryError. Deselecting Cluster (0x1f43b675), Cues (0x1c53bb6b) and SeekHead (0x113d9b74) greatly diminishes the amount of memory required to display the file structure if you are not interested in the contents of these containers. 4) "view/file list" shows the list of processed files 5) "analyse/type statistics" shows the statistics for EBML data types. 6) "analyse/element statistics" shows the statistics for EBML elements that were present at least once in some file. 7) "analyse/inspections" shows a limited number of inspections. "Inefficient encoding" is when the value can be encoded with a smaller number of bytes. "Signed integer encoding" is what happens if the value is encoded as a signed integer. Below is a summary of one of my experiments: The input is 338 MKV files with a total size of about 85 Gb. The type statistics sorted by the number of instances: CONTAINER: 17261279 (24 different elements) BINARY: 16757498 (7 different elements) SIGNED_INTEGER: 12605228 (only 1 element of the signed integer type, ReferenceBlock to be exact) UNSIGNED_INTEGER: 1605713 (37 different elements) ASCII_STRING: 5521 (6 different elements) UTF_8_STRING: 4607 (8 different elements) FLOAT: 1965 (4 different elements) DATE: 338 (1 element of the Date type) and 31 instances of unknown elements (2 different unknown identifiers). It seems that http://www.matroska.org/technical/specs/index.html does not fully reflect the latest ebml/matroska versions. The type statistics table is rather big, with BlockGroup and Block elements at the top with about 16 millions of instances each. The inspections: 1) 339 instances of the inefficient element size encodings (most of the cases are encoding of the Cluster size, which is almost always 8 bytes long). Approximately 1 Kb can be saved, which is 0,0000013% of the total size of the processed files. 2) 106 instances of inefficient signed integer encoding and 7321 instance of inefficient unsigned integer encoding. Most of the cases are encoding of the zero value as a one byte, which, at least according to EBML RFC, can be encoded as zero bytes. Approximately 7 Kb can be saved, which is 0,0000082% of the total size of the processed files. 3) there are 109738 instances of unsigned integers which will take more space if encoded as a signed integer. For example, 0x80..0xFF will take 1 byte as unsigned and 2 bytes as a signed. If all these values will be encoded as a signed integers, then the total size of processed files will increase by 109738 bytes, which is 0,00012% of the total size of the processed files. 4) all encountered string values can be encoded in the UTF-8 without any changes in the file size. Leaving only one kind of strings (Unicode) in the specification will not affect the files i used for this experiment. 5) the Date type is a small waste of file size and a big waste of specification, as there is only one element of that type in the specification and there is at most one instance of that element in each processed file. Encoding all date elements as signed seconds could save 4 bytes per file and removing the Date type from the specification could simplify the specification a little. The main result is the fact, that the size of this particular set of files will grow only 0,00012% if all unsigned integers will be encoded as a signed integers. Not that it matters for the current versions of EBML and Matroska, but it could be taken into account when developing new versions or completely new data encoding formats not related to Matroska (which is one of the goals of the original research that led me to study ebml and write that program). Oleg From sebastian.droege at collabora.co.uk Tue Jul 1 14:44:19 2008 From: sebastian.droege at collabora.co.uk (Sebastian =?ISO-8859-1?Q?Dr=F6ge?=) Date: Tue, 01 Jul 2008 14:44:19 +0200 Subject: [Matroska-devel] [Fwd: Re: Dirac mapping for Matroska] In-Reply-To: <1214333308.3084.22.camel@asgard.lan> References: <1214313083.3084.9.camel@asgard.lan> <1214333308.3084.22.camel@asgard.lan> Message-ID: <1214916259.2998.14.camel@asgard.lan> Ok, thanks for all your comments, I'm answering some below. The current draft can be found on http://diracvideo.org/wiki/index.php/DiracInMatroska Steve Lhomme wrote: > Sebastian Dr?ge wrote: > > Ok, after talking to one of the Dirac developers I'd like to change the > > previous proposal completely ;) > > > > The plan would now be: > > - CodecID is "V_DIRAC" > > - No CodecPrivate, no changing of the stream > > - A Matroska block/lace contains all Dirac packets up to and > > including a picture. This means, all padding, maybe a sequence > > header and maybe auxiliary data and then the picture for which > > all this previous data was. This makes demuxing much easier > > and prevents broken streams created by a muxer or demuxer. > > I liked the previous proposal better. Is there a reason why you to store > metadata in the "playback blocks" ? Only data needed for decoding should > be put in a cluster. There is room for plenty of metadata elsewhere > (tracks, tags, chapters and more can be added if necessary). Does it > also include padding ??? Dirac frames can contain abitrary metadata in auxiliary packets and of course the padding packets. But as you and David have agreed later on the elementary Dirac stream should not be changed. > > - A block is a keyframe whenever it contains a sequence header. > > Sequence headers are added to the stream by the encoder at > > places that are meant as "seek points" and on which decoding > > could start. There's no easy way of detecting whether a picture > > can be decoded on it's own in any other way. > > That means only those frames with a sequence header should be marked as > keyframes in SimpleBlock. I'm not use using the other "reference system" > is necessary. There's only one "reference frame" system now in the above draft. Either by using SimpleBlocks which are marked as keyframe whenever they contain a sequence header or by using normal Blocks and the ReferenceFrame pointing backwards to the previous frame until the frame having the sequence header. Does this sound good to you? David Flynn wrote: > There is no carraige of 'nonessential' metadata in a dirac elementary > stream. A sequence header is essential. >From what I understood padding and auxiliary data is not essential for decoding and could in theory be dropped. But I agree that this should not be done for the reasons you mention later. > > You mean it's as close to the original as possible. Except it doesn't > > take of matroska to store the data in the appropriate place. Using VfW > > will give the same (bad) result. > > Please could you elaborate on 'appropriate place' and what the bad > result is? A Matroska block can contain additional data in a separate place (BlockAdditional) but for the above reasons this should not be used for auxiliary data packets, etc. So to summarize, is the above draft fine for the Dirac and Matroska developers? Is there anything that should be clarified or corrected or can this be added to the Matroska spec already? From jcsston at jory.info Thu Jul 3 01:15:34 2008 From: jcsston at jory.info (Jory Stone) Date: Wed, 02 Jul 2008 18:15:34 -0500 Subject: [Matroska-devel] ebml viewer with a small analysis capabilities In-Reply-To: References: Message-ID: <486C0C16.3020000@jory.info> Impressive research :) Thank you for sharing Jory Oleg Estekhin wrote: > Hi everybody. > > As a part of research of different ways to store binary data i created the EBML viewer-analyser application, written in Java. > > Initially i just wanted to check how much more space the real-world data will take if the storage format supports only signed integers compared to the format with both signed and unsigned integers. > > It turned out that the EBML in general and Matroska in particular is the only format that has both of the following properties: > 1) the format has signed and unsigned integers; > 2) i have a big collection of data in that format (mkv video in this case). > > In the end instead of writing simple analyser i wrote a program which can view the contents of the EBML files and calculate some statistics on the number of used elements and so on. > > The source code and executable Java jar file is available from http://code.google.com/p/ebml-viewer/. > To start the program double-click the ebml-viewer-1.0.jar inside the unpacked /lib of ebml-viewer-1.0-bin.zip. > > The manual is absent, so just a couple of comments on available menu commands: > 1) "open file" will both parse the file and open a tree with the file contents. > 2) "parse file" will only parse the file for the sake of collecting statistics. > 3) "edit/element list" allows to configure whether the content of some container element should be displayed in the tree view. Regardless of these settings all containers will be parsed, so this is just the filter for a file structure tree. > Creating the complete tree view of a 250mb file requires 20 to 30 mb of memory, which leads to the fact that the viewer can display only a limited number of files before throwing OutOfMemoryError. Deselecting Cluster (0x1f43b675), Cues (0x1c53bb6b) and SeekHead (0x113d9b74) greatly diminishes the amount of memory required to display the file structure if you are not interested in the contents of these containers. > 4) "view/file list" shows the list of processed files > 5) "analyse/type statistics" shows the statistics for EBML data types. > 6) "analyse/element statistics" shows the statistics for EBML elements that were present at least once in some file. > 7) "analyse/inspections" shows a limited number of inspections. > "Inefficient encoding" is when the value can be encoded with a smaller number of bytes. > "Signed integer encoding" is what happens if the value is encoded as a signed integer. > > Below is a summary of one of my experiments: > The input is 338 MKV files with a total size of about 85 Gb. > > The type statistics sorted by the number of instances: > CONTAINER: 17261279 (24 different elements) > BINARY: 16757498 (7 different elements) > SIGNED_INTEGER: 12605228 (only 1 element of the signed integer type, ReferenceBlock to be exact) > UNSIGNED_INTEGER: 1605713 (37 different elements) > ASCII_STRING: 5521 (6 different elements) > UTF_8_STRING: 4607 (8 different elements) > FLOAT: 1965 (4 different elements) > DATE: 338 (1 element of the Date type) > and 31 instances of unknown elements (2 different unknown identifiers). It seems that http://www.matroska.org/technical/specs/index.html does not fully reflect the latest ebml/matroska versions. > > The type statistics table is rather big, with BlockGroup and Block elements at the top with about 16 millions of instances each. > > The inspections: > 1) 339 instances of the inefficient element size encodings (most of the cases are encoding of the Cluster size, which is almost always 8 bytes long). Approximately 1 Kb can be saved, which is 0,0000013% of the total size of the processed files. > 2) 106 instances of inefficient signed integer encoding and 7321 instance of inefficient unsigned integer encoding. Most of the cases are encoding of the zero value as a one byte, which, at least according to EBML RFC, can be encoded as zero bytes. Approximately 7 Kb can be saved, which is 0,0000082% of the total size of the processed files. > 3) there are 109738 instances of unsigned integers which will take more space if encoded as a signed integer. For example, 0x80..0xFF will take 1 byte as unsigned and 2 bytes as a signed. If all these values will be encoded as a signed integers, then the total size of processed files will increase by 109738 bytes, which is 0,00012% of the total size of the processed files. > 4) all encountered string values can be encoded in the UTF-8 without any changes in the file size. Leaving only one kind of strings (Unicode) in the specification will not affect the files i used for this experiment. > 5) the Date type is a small waste of file size and a big waste of specification, as there is only one element of that type in the specification and there is at most one instance of that element in each processed file. Encoding all date elements as signed seconds could save 4 bytes per file and removing the Date type from the specification could simplify the specification a little. > > The main result is the fact, that the size of this particular set of files will grow only 0,00012% if all unsigned integers will be encoded as a signed integers. Not that it matters for the current versions of EBML and Matroska, but it could be taken into account when developing new versions or completely new data encoding formats not related to Matroska (which is one of the goals of the original research that led me to study ebml and write that program). > > > Oleg > > _______________________________________________ > 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 zhao.yu at excelpoint.com.cn Thu Jul 3 15:59:31 2008 From: zhao.yu at excelpoint.com.cn (zhao.yu) Date: Thu, 3 Jul 2008 21:59:31 +0800 Subject: [Matroska-devel] help for the design on sigma design Message-ID: <000201c8dd15$09d4eca0$b000a8c0@zhaoyu> Hi Sir, Could I get help from you,in order to add the MKV support on sigma design EM8623 platform? Pls,sincerely. Thanks and best regards Zhao Yu -------------- next part -------------- An HTML attachment was scrubbed... URL: From safety at hush.ai Sat Jul 5 14:49:50 2008 From: safety at hush.ai (safety at hush.ai) Date: Sat, 05 Jul 2008 14:49:50 +0200 Subject: [Matroska-devel] No subject Message-ID: <20080705124951.8C88E158041@mailserver6.hushmail.com> Good day! Need to know how to convert .mkv in any DVD Player/Recorder playable DVD format? Software's name, please? And also .avi and etc. in any DVD Player/Recorder playable DVD format? Hope you can help me with last one! Best regards Johan Orwell -- Beauty Product Reviews Read Unbiased Beauty Product Reviews and Join Our Product Review Team! http://tagline.hushmail.com/fc/JKFkuIjyaMH0MQCDFPxyz2wBbD2btq7fdVY4pDZNVJUjObVFL5KAbq/ From slhomme at matroska.org Mon Jul 7 19:26:34 2008 From: slhomme at matroska.org (Steve Lhomme) Date: Mon, 07 Jul 2008 11:26:34 -0600 Subject: [Matroska-devel] help for the design on sigma design In-Reply-To: <000201c8dd15$09d4eca0$b000a8c0@zhaoyu> References: <000201c8dd15$09d4eca0$b000a8c0@zhaoyu> Message-ID: <487251CA.70006@matroska.org> zhao.yu wrote: > Hi Sir, > > Could I get help from you,in order to add the MKV support on sigma > design EM8623 platform? Sure, what kind of help do you need ? Steve From agebosma at gmail.com Mon Jul 7 19:44:04 2008 From: agebosma at gmail.com (Age Bosma) Date: Mon, 07 Jul 2008 19:44:04 +0200 Subject: [Matroska-devel] No subject In-Reply-To: <20080705124951.8C88E158041@mailserver6.hushmail.com> References: <20080705124951.8C88E158041@mailserver6.hushmail.com> Message-ID: <487255E4.4020003@gmail.com> safety at hush.ai wrote: > Good day! > > Need to know how to convert .mkv in any DVD Player/Recorder > playable DVD format? Software's name, please? > > And also .avi and etc. in any DVD Player/Recorder playable DVD > format? Hope you can help me with last one! > Make google your best friend: http://www.google.nl/search?q=mkv+to+dvd&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:en-GB:official&client=firefox-a Yours, Age From marnyczarny at gmail.com Wed Jul 9 12:48:49 2008 From: marnyczarny at gmail.com (czarny marny) Date: Wed, 9 Jul 2008 12:48:49 +0200 Subject: [Matroska-devel] subtitle tracks... Message-ID: <8f4b568d0807090348q1775bb06u7a89775738ecdcbf@mail.gmail.com> Hi, I've a problem with haali's splitter (newest v1.8.122.18). My MKV movie have 33 tracks (1 video, 1 audio, 31 subtitles). In haali's tray I can see only 30 subtitle tracks. Is it any limitation? Is it posible to fix it? BTW if I disable haali's splitter and turn on internal MPC mkv splitter, I can see all 31 subtitle tracks (in MPC subtitles submenu) Regards /crt -------------- next part -------------- An HTML attachment was scrubbed... URL: From florent.viguier at wanadoo.fr Mon Jul 14 01:33:22 2008 From: florent.viguier at wanadoo.fr (Florent Viguier) Date: Sun, 13 Jul 2008 23:33:22 +0000 (UTC) Subject: [Matroska-devel] No audio using Haali splitter for TS files with MPEG4-AVC (h264) + AAC data Message-ID: Hello. I'm writing this post because I have trouble reading TS files recorded from the digital televion service provided by my ISP (Free : http://www.free.fr/). I had no problem before because they used standard MPEG2 (I think it was PS files, at least that's what I can see in VLC's messages when I open them with it) that Media Player Classic can parse by itself. But now they have switched to another format that I can correctly open with VLC (video + sound), but with any DirectShow-based program I have video but no audio. In VLC's messages, it says that it uses the 'ts' module to open the file, that the video codec is h264, and that the audio is AAC. I'd like to use Media Player Classic instead of VLC since it can make use of CoreAVC instead of the slow h264 decoder bundled with VLC (ffmpeg ?). Currently the video does play using CoreAVC, but as I said, no audio... When I try to render one of these TS files in GraphEdit, I can see that Haali splitter is being used, but it has only a video out pin, but no audio pin. So I guess it cannot read the audio part of the file. Since these files come from "live" recording this may have something to do with the lack of header or something... (I dont know how these TS files work) By the way, if I use Media Player Classic's internal "MPEG PS/TS/PVA" splitter, the exact same problem happens. I also tried changing the file extension to mpg and mp4 but with no luck. You can find a short sample file here : http://thetreehouse.free.fr/images_stockees/ts_file_sample.ts (328 kilobytes only : SD version, so this one works perfectly in VLC, but my ISP also provides an HD version that I can't read smoothly with VLC) The file itself was recorded using a program called adslTV which I think makes use of VLC to receive the video stream (RTSP protocol) and save it to a file. I hope this post isn't irrelevant or in the wrong place. Tell me if there is a known workaround to this problem. You can ask me for other sample files if you want. PS: If someone here knows a DirectShow filter to open RTSP streams, tell me. I tried Morgan RTP DShow filter, but when I start it, it just continuously fills up the memory and nothing plays... And I have to use the task manager to shut down MPC. Thanks in advance. \Florent\ From florent.viguier at wanadoo.fr Thu Jul 24 20:54:53 2008 From: florent.viguier at wanadoo.fr (Florent Viguier) Date: Thu, 24 Jul 2008 20:54:53 +0200 Subject: [Matroska-devel] No audio using Haali splitter for TS files with MPEG4-AVC (h264) + AAC data In-Reply-To: References: Message-ID: Nevermind I found a convenient way to read these files... And I also found out that I should have posted this on doom9.org's forums instead. Sorry for bothering the Matroska developers ! :p My method is the following : 1- Demux the audio part of the stream using DGAVCDec, keeping the default name for the aac file that is generated. 2- Open the TS file with MPC. The AAC file is magically detected by MPC that will read the audio file in sync with the video automatically ! (seeking works too !) Gabest is the best ! It would still be great if Haali's splitter could extract the audio too, so I could use one single DirectShowSource() in AviSynth to use any AviSynth compatible program to re-encode the stream. And I still found no way to directly read the live TV streamed over RTSP using MPC and not VLC. /Florent/ Florent Viguier a ?crit : > Hello. > > I'm writing this post because I have trouble reading > TS files recorded from the digital televion service > provided by my ISP (Free : http://www.free.fr/). > I had no problem before because they used standard > MPEG2 (I think it was PS files, at least that's what > I can see in VLC's messages when I open them with it) > that Media Player Classic can parse by itself. > > But now they have switched to another format that I can correctly > open with VLC (video + sound), but with any DirectShow-based > program I have video but no audio. In VLC's messages, it says that > it uses the 'ts' module to open the file, that the video codec is > h264, and that the audio is AAC. I'd like to use Media Player > Classic instead of VLC since it can make use of CoreAVC instead > of the slow h264 decoder bundled with VLC (ffmpeg ?). Currently the > video does play using CoreAVC, but as I said, no audio... > > When I try to render one of these TS files in GraphEdit, I can > see that Haali splitter is being used, but it has only a video > out pin, but no audio pin. So I guess it cannot read the audio > part of the file. Since these files come from "live" recording > this may have something to do with the lack of header or > something... (I dont know how these TS files work) > > By the way, if I use Media Player Classic's internal > "MPEG PS/TS/PVA" splitter, the exact same problem happens. > I also tried changing the file extension to mpg and mp4 but > with no luck. > > You can find a short sample file here : > http://thetreehouse.free.fr/images_stockees/ts_file_sample.ts > (328 kilobytes only : SD version, so this one works perfectly > in VLC, but my ISP also provides an HD version that I can't read > smoothly with VLC) > > The file itself was recorded using a program called > adslTV which I think makes use of VLC to receive the > video stream (RTSP protocol) and save it to a file. > > I hope this post isn't irrelevant or in the wrong place. > Tell me if there is a known workaround to this problem. > You can ask me for other sample files if you want. > > PS: If someone here knows a DirectShow filter to open RTSP streams, > tell me. I tried Morgan RTP DShow filter, but when I start it, > it just continuously fills up the memory and nothing plays... > And I have to use the task manager to shut down MPC. > > Thanks in advance. > > \Florent\ > > _______________________________________________ > 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 Martin.Bode at cycos.com Wed Jul 23 17:43:37 2008 From: Martin.Bode at cycos.com (Bode, Martin) Date: Wed, 23 Jul 2008 17:43:37 +0200 Subject: [Matroska-devel] H.264(x264) in mkv Message-ID: <6792A05F23291C4F8B2CD869E0023E2202A24B5E@mx01.alsdorf.cycos.com> Hi, I am trying to write routines to read matroska H.264 videofiles. I created an example mkv-file via x264. The file can be played by vlc and others, but I have problems reading the content of the matroska block elements in the examplefile myself. I expected each block to contain one H.264 NAL-unit or multiple nal-units ordered by a lacing method. The matroskafile created by x264 seems (by a look at the code) to write a 32-bit length and a NAL unit of this length. There are very short sections of 5 or 6 byte, which cannot be decoded. Can you give me a hint, where this data structure is documented ? Are there special documents for putting H.264 NAL-units into matroska-blocks ? I had a look at http://www.matroska.org/technical/specs/index.html, but the lacing methods do not seem to fit... Thanks in advance Martin Martin Bode Software Developer/Research?& Development Phone:?? +49-2404-901-483 Fax:?????? +49-2404-901-283 Martin.Bode at cycos.com www.cycos.de ? ? ? Cycos AG Joseph-von-Fraunhofer Str. 7 D-52477 Alsdorf ? Cycos Aktiengesellschaft: Vorsitzender des Aufsichtsrats: Dr. Michael Tigges Vorstand: J?rgen Diller (Vorsitzender),Rudolf Seeber Sitz der Gesellschaft: Alsdorf Registergericht: Aachen, HRB 7658 From Martin.Bode at cycos.com Fri Jul 25 10:29:05 2008 From: Martin.Bode at cycos.com (Bode, Martin) Date: Fri, 25 Jul 2008 10:29:05 +0200 Subject: [Matroska-devel] H.264(x264) in mkv Message-ID: <6792A05F23291C4F8B2CD869E0023E2202A24D58@mx01.alsdorf.cycos.com> Hi, I am trying to write routines to read matroska H.264 videofiles. I created an example mkv-file via x264. The file can be played by vlc and others, but I have problems reading the content of the matroska block elements in the examplefile myself. I expected each block to contain one H.264 NAL-unit or multiple nal-units ordered by a lacing method. The matroskafile created by x264 seems (by a look at the code) to write a 32-bit length and a NAL unit of this length. There are very short sections of 5 or 6 byte, which cannot be decoded. Can you give me a hint, where this data structure is documented ? Are there special documents for putting H.264 NAL-units into matroska-blocks ? I had a look at http://www.matroska.org/technical/specs/index.html, but the lacing methods do not seem to fit... Thanks in advance Martin Martin Bode Software Developer/Research?& Development Phone:?? +49-2404-901-483 Fax:?????? +49-2404-901-283 Martin.Bode at cycos.com www.cycos.de ? ? ? Cycos AG Joseph-von-Fraunhofer Str. 7 D-52477 Alsdorf ? Cycos Aktiengesellschaft: Vorsitzender des Aufsichtsrats: Dr. Michael Tigges Vorstand: J?rgen Diller (Vorsitzender),Rudolf Seeber Sitz der Gesellschaft: Alsdorf Registergericht: Aachen, HRB 7658 From victorctk at gmail.com Wed Jul 30 09:47:39 2008 From: victorctk at gmail.com (victor chia) Date: Wed, 30 Jul 2008 07:47:39 -0000 Subject: [Matroska-devel] Severe Lag in MacOSX Message-ID: Hi i'm facing severe video lag when i play .mkv file using both vlc and mplayer. How do i fix this problem? Please note my machine details below: MacOSX Version 10.4.11 Processor 1.2 GHz PowerPC G4 Memory 768 MB DDR SDRAM I do not encounter such lag when playing avi or even divx type file. Please help. Thanx -- x. victor -------------- next part -------------- An HTML attachment was scrubbed... URL: