From moritz at bunkus.org Mon Dec 5 14:52:07 2005 From: moritz at bunkus.org (Moritz Bunkus) Date: Mon, 5 Dec 2005 14:52:07 +0100 Subject: [Matroska-devel] ISO 3166-1 Country Codes Instead of ccTLDs? In-Reply-To: <438BA255.5070709@pipian.com> References: <438BA255.5070709@pipian.com> Message-ID: <200512051452.10286.moritz@bunkus.org> Hey, On Tuesday 29 November 2005 01:35, Pipian wrote: > It seems to me that it would be thus more appropriate to use ISO 3166-1 > for the purposes of country codes, given that it is an accepted > international standard (ccTLDs are vaguer in that regard) and is > identical to the ccTLD with the exception of: I wouldn't have too big of a problem with us using ISO 3166-1 instead of ccTLDs. One problem is that we would again be changing specs and possibly making some files invalid (those which use some of the "transitional" or "exceptional" ccTLDs). On the other hand we like to rely on well-established standards, and ISO certainly is one. Any other 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 astafford at whenu.com Tue Dec 6 21:40:11 2005 From: astafford at whenu.com (Adrienne Stafford) Date: Tue, 6 Dec 2005 15:40:11 -0500 Subject: [Matroska-devel] WhenU Inquiry Message-ID: <20051206204521.29D18440017@p15097576.pureserver.info> Dear Christian Wiesner, I represent WhenU. I am trying to reach you or the appropriate person to present our revenue proposal. Has Matroska considered drawing revenue to your codec product by monetizing downloads? WhenU is the leader in permission-based, client-side desktop advertising. We help software developers monetize (make money on) download volume through behaviorally targeted and contextually relevant ads and coupons. We think we can serve you as well. We have helped several prominent developers in the audio/video space to increase their revenue. Some current audio/video partners include but are not limited to Cliprex, One Stop Soft, Rad Light, M3 Development's Mp3 to WAV Decoder and NPS Software's 2 Find MP3. We are interested in partnering Matroska Pack Full with WhenU desktop software. I would like to have the opportunity to present our proposal in more detail. Could the appropriate person for this matter please contact me? Sincerely, Adrienne Stafford Adrienne Stafford Business Development 1 Penn Plaza Suite 4532 Tel: 212.631.2104 Fax: 212.268.7489 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature_logo2.gif Type: image/gif Size: 2179 bytes Desc: not available URL: From paul at msn.com Thu Dec 8 09:41:39 2005 From: paul at msn.com (Paul Bryson) Date: Thu, 8 Dec 2005 02:41:39 -0600 Subject: [Matroska-devel] EBML Reference Message-ID: I ran across this reference that EBML can be done over AJAX. http://en.wikipedia.org/wiki/AJAX Has anyone ever heard of this or what the purpose would be? I am curious why it is mentioned specifically. Atamido From steve.lhomme at free.fr Sun Dec 18 18:50:00 2005 From: steve.lhomme at free.fr (Steve Lhomme) Date: Sun, 18 Dec 2005 07:50:00 -1000 Subject: [Matroska-devel] Question In-Reply-To: <20051023052820.1CD3933C23@mailserver5.hushmail.com> References: <20051023052820.1CD3933C23@mailserver5.hushmail.com> Message-ID: <43A5A148.6090302@free.fr> Hi, Sorry for the late reply, but I've been very busy moving to a new place (and working on CoreTheque) for the last months. ivanburnin at hushmail.com wrote: > I haven't seen these in anything yet, but I admit I haven't looked > all that deeply. > > I know Matroska is capable of having multiple audio channels, and > multiple video channels. Is there currently any way to create a > scripting mixing board for them (this allows overriding, and can > handle multiple scripts for multiple purposes), as well as > hopefully a 3D sound positioning mechanism (again scriptable). For the scripting you can add a Chapter Codec of your own to do whatever you want. But you'll need to do the support in the player too. Only VLC can support the DVD chapter codec that was made as an example. It's GPL so if you want something closed-source you'll need to find other solutions. > I'm thinking about something like a Karaoke situation, where > storing both the background only and full audio versions would > require nearly double the space of background only & speex > compressed voice. Alternately a situational performance where for > example in a Jazz combo at may be desirable to bring out the > trumpet, but not lose the original data, allowing a great deal of > flexibility in playback. With a suitable amplification/speaker > environment it would be possible to do a great many very > interesting things with this, and with live recordings the > flexibility could open many more possibilities. This was supposed to be handled by Control Tracks, but what remains of control tracks are the DVD button track. The rest is done with chapters. The good side of it is that it can be managed in an easier way (just write the XML manually or with a custom made software). I don't remember if the part for enabling/disabling tracks for the DVD Chapter codec but it could be done. There is already a feature to map DVD tracks to Matroska track IDs. > So my question is: Is there a positioning and mixing script > facility available? And assuming there isn't, is there any other > interest in seeing one? Interrest is only if someone needs it. DVDs have such capatibilities and it's almost completely supported in Matroska. It's through a specific codec. Now any other codec could be created. From steve.lhomme at free.fr Sun Dec 18 19:00:23 2005 From: steve.lhomme at free.fr (Steve Lhomme) Date: Sun, 18 Dec 2005 08:00:23 -1000 Subject: [Matroska-devel] Encryption In-Reply-To: <200511191130.jAJBUTxg075800@mailserver3.hushmail.com> References: <200511191130.jAJBUTxg075800@mailserver3.hushmail.com> Message-ID: <43A5A3B7.8090803@free.fr> ivanburnin at hushmail.com wrote: > I've got some spare cycles now so I'm looking into the encryption. > I've got a few questions though. A link was poste before without > much information, is there a document with deeper information? Has > anyone ever implemented encryption for Matroska files? (if so > everything should be compatible) And lastly, would anyone mind if I > changed things radically? Jory has a DirectShow encryption filter, I'm not sure if it uses the built-in Matroska one. The encryption works on par with the compression system. And that compression systems is used a lot already. You can even chain compression and encryption. So if you want to change something (because the compression part is mostly unused there might not even be ways to use it right now in a muxer). > At this point I'm considering something along the lines of an > encryption header that contains > {integer identifier, UTF-8 String name, blob of bits to pass to the > initializer} this would occur once per encrypter per file and only > for the encryptor(s) that are used in that file, the name would be > the name of the method (used for universal identification), > identifier would be an in file identification number to allow for > multiple encryptors per file. I don't see a radical change with what we have now. > Then each encrypted segment (for some paring specific definition of > segment that does not necessarily have anything to do with segment > in the video sense) is composed of > > {integer identifier, blob of bits to pass to the decryptor} Where would you store this ? With each frame/block ? Or in the encryption private data of the track ? > I would also propose that 0x00000000 be defined as the null > encryptor, allowing it to be used for the sake of sanity when > writing certain processors. It is also important to note that the > identifier for a given encryptor/decryptor can change across files > and that the per file header is the only dependable source for this > information. A smaller sized integer would be acceptable, I simply > chose 32-bits because it is commonly and quickly available. That's definitely something to store in one of the binary fields of ContentEncryption. > This moves an enormous quantity of the cryptography decision out of > the core Matroska document, creating small supplimental documents > for each type. I would of course be writing a number of these in > order to build a baseline that people could depend on. Yes, that's how codec works (track or chapters). The same can be done for encryption with many different ones just defined by their ContentEncAlgo. > This format allows me to work very quickly, for other competing > designers to work quickly, and security. There are a lot of > implementation details that I haven't covered, for example there > should be a version number embedded in there, and a definition for > the signature that is mentioned briefly in the current spec, I > haven't addressed either of these. Actually binary format is > relatively unimportant from a security standpoint, and can be > addressed by someone more familiar with the inner workings than I > am. We can add an encryption page the same way there is a codec page and a chapter codec page. From ashwood at msn.com Tue Dec 20 01:55:56 2005 From: ashwood at msn.com (Joseph Ashwood) Date: Mon, 19 Dec 2005 16:55:56 -0800 Subject: [Matroska-devel] Re: Encryption Message-ID: I guess I should point out first that I am dropping the nym ivanburnin, at this point the design will be easily identifiable by anyone that has seen my previous work, and all questionable stuff is gone from the plan. "Steve Lhomme" wrote in message news:43A5A3B7.8090803 at free.fr... > ivanburnin at hushmail.com wrote: >> I've got some spare cycles now so I'm looking into the encryption. >> I've got a few questions though. A link was poste before without >> much information, is there a document with deeper information? Has >> anyone ever implemented encryption for Matroska files? (if so >> everything should be compatible) And lastly, would anyone mind if I >> changed things radically? > > Jory has a DirectShow encryption filter, I'm not sure if it uses the > built-in Matroska one. I'll take a look at it, because honestly I couldn't find enough specification to actually make a final product, so I was asking for any complete implementations to see if anyone had actually done it yet. >> At this point I'm considering something along the lines of an >> encryption header that contains >> {integer identifier, UTF-8 String name, blob of bits to pass to the >> initializer} this would occur once per encrypter per file and only >> for the encryptor(s) that are used in that file, the name would be >> the name of the method (used for universal identification), >> identifier would be an in file identification number to allow for >> multiple encryptors per file. > > I don't see a radical change with what we have now. There shouldn't be any radical change there, it was just to establish a dynamic naming system so that encryption/DRM methods don't have to be registered, and the core specification can safely ignore them. >> Then each encrypted segment (for some paring specific definition of >> segment that does not necessarily have anything to do with segment >> in the video sense) is composed of >> >> {integer identifier, blob of bits to pass to the decryptor} > > Where would you store this ? With each frame/block ? Or in the > encryption private data of the track ? I was thinking that this should actually be a wrapper around a block. Since it will only add a few bytes the overhead is minimal, and it will prevent a lot of mistakes that are very easy and very subtle. In fact I had hoped to make this a generic wrapper, so that each level and each track can be encrypted seperately if desired. The reason for this is that in some instances the various taggings/tracks/etc will leak information, and the encryption should be able to prevent this. >> I would also propose that 0x00000000 be defined as the null >> encryptor, allowing it to be used for the sake of sanity when >> writing certain processors. It is also important to note that the >> identifier for a given encryptor/decryptor can change across files >> and that the per file header is the only dependable source for this >> information. A smaller sized integer would be acceptable, I simply >> chose 32-bits because it is commonly and quickly available. > > That's definitely something to store in one of the binary fields of > ContentEncryption. The binary field identifier (I see no reason it needs to be an int actually) and the blob of bits are the only necessary field for the encryption, by dropping all others it'll save space in the worst case. > >> This moves an enormous quantity of the cryptography decision out of >> the core Matroska document, creating small supplimental documents >> for each type. I would of course be writing a number of these in >> order to build a baseline that people could depend on. > > Yes, that's how codec works (track or chapters). The same can be done > for encryption with many different ones just defined by their > ContentEncAlgo. I was hoping to avoid this. By forcing all encryptors to register it'll only slow down the abilities of encryption designers, this is exactly what the dynamic naming was designed to get rid of. Instead of having what amounts to an authorized list the list would self-create and self-manage, and the Matroska group could generally completely ignore their presence. >> This format allows me to work very quickly, for other competing >> designers to work quickly, and security. There are a lot of >> implementation details that I haven't covered, for example there >> should be a version number embedded in there, and a definition for >> the signature that is mentioned briefly in the current spec, I >> haven't addressed either of these. Actually binary format is >> relatively unimportant from a security standpoint, and can be >> addressed by someone more familiar with the inner workings than I >> am. > > We can add an encryption page the same way there is a codec page and a > chapter codec page. Sounds good. If the design seems reasonable what I'd like to see is the addition of an EncryptionInformation or EncryptionHeader (we could also call it TranfsormInformation or TransformHeader to allow for compressors as well) which would represent it's own grouping section (looking at the diagram page) alongside Meta Seek Information, Segment Information, Track, etc. This would contain the dynamic naming that I began with. The creating a Transformed/Encrypted chunk tag, would force processing of the encryption before containing information would be read. So I guess the proposed format would be (following the format layout in the spec doc given for SimpleBlock): EncryptedData 0x00-0x1F Indentifier for Handler 0x20-0x3F contained Type identifier 0x40-? Blob of bits to be handled by Handler Contained type is a convenience data, I can see no information that it would leak. Post-transform data will be parsable exactly as the original data (e.g. bit-for-bit identical)*, (exclusive) or the Handler will return an error code. In the case of nested encryptions Type Identifier contains the Type Identifier of the encryption transform. It is the Handler's responsability to notify the user of the nature of the error if any notification is necessary. For the Encryption Header: 0x00-0x1F Identifier 0x20-? Dynamically sized UTF-8 string Handler Indentifier ?-?? blob of bits passed to identifier initializer I'm open to changing the format to one using tags for each field, which would probably be preferrable, but as I've said before format doesn't really matter that much to security in this. Handler Identifier is case sensitive, except for the Null Encryptor discussed later. Initializer only needs to return success or failure. It is the Initializers responsability to notify the user of the nature of the error if any notification is to take place. Duplicate hander identifier strings MUST be allowed. Each track may have it's own identifier, for finer grained access control, even if they use the same handler. In the case of an Initializer error playback should be attempted with any available information, specifically if a track fails to be decodable other tracks should be used. 0x00000000 is defined as the null encryption transform, the specific transform from the blob of bits is: output[k] = blob[k] for all valid k. Where blob is the blob of bits from the EncryptedData, and output is the output to be generated. Any attempts to use a duplicate identifier (e.g. assigning 0x00000000 to anything other than "NullTransform" or "NullEncryption" case insensitive) is a parsing error, recovery is up to the application, a suggested process is to attempt decryption of a portion encrypted with the identifier and check for errors, first one to not return an error is used (note: this will not work in all cases, it is possible that a given transform will only decrypt something once, and as such the test should be stored decrypted in memory until it is used). I know a lot of this information goes beyond the formatting that is typical for Matroska, and in fact much of it can be moved to seperate locations, but there are a huge number of considerations. Any comments are Joe * A short note on why this is written so convolutedly. I was going to say "bit-for-bit" identical to the original, but then I realized that with encryption algorithms like Chameleon available, this will not necessarily be the case, and the only assurance is that it MUST be parsable exactly as if it was the data before encryption. From paul at msn.com Tue Dec 20 07:07:57 2005 From: paul at msn.com (Paul Bryson) Date: Tue, 20 Dec 2005 00:07:57 -0600 Subject: [Matroska-devel] Re: Encryption References: Message-ID: "Joseph Ashwood" wrote... > I was thinking that this should actually be a wrapper around a block. > Since it will only add a few bytes the overhead is minimal, and it will > prevent a lot of mistakes that are very easy and very subtle. In fact I > had hoped to make this a generic wrapper, so that each level and each > track can be encrypted seperately if desired. The reason for this is that > in some instances the various taggings/tracks/etc will leak information, > and the encryption should be able to prevent this. The current system was designed to have the encryption only encrypt the data portion of the Block, not the entire thing. I'm guessing that any extra data that needed to be passed to the decrypter could be stored in that same Block, aware only to the decrypter itself. One reason for doing this is it allows the file to be manipulated, without requiring any sort of decryption to occur. For instance, the file could be remuxed if it were damaged. Note that while I helped on the design of this particular portion, I was focused on allowing the ContentCompression and ContentEncryption to operate through the same layer so they could be interchangeable, and allow for stacking. I know nothing about encryption methodologies, nor what would result in a weakness. I'm not particularly attached to the current system, especially as it hasn't been implemented by anyone, but there are certain technical benefits (not related to encryption) that it offers. So if it were possible to use some method that resulted in the same benefits, that would be wonderful. Atamido From ashwood at msn.com Tue Dec 20 08:25:11 2005 From: ashwood at msn.com (Joseph Ashwood) Date: Mon, 19 Dec 2005 23:25:11 -0800 Subject: [Matroska-devel] Re: Encryption References: Message-ID: ----- Original Message ----- From: "Paul Bryson" Subject: [Matroska-devel] Re: Encryption > "Joseph Ashwood" wrote... >> I was thinking that this should actually be a wrapper around a block. >> Since it will only add a few bytes the overhead is minimal, and it will >> prevent a lot of mistakes that are very easy and very subtle. In fact I >> had hoped to make this a generic wrapper, so that each level and each >> track can be encrypted seperately if desired. The reason for this is that >> in some instances the various taggings/tracks/etc will leak information, >> and the encryption should be able to prevent this. > > The current system was designed to have the encryption only encrypt the > data portion of the Block, not the entire thing. I'm guessing that any > extra data that needed to be passed to the decrypter could be stored in > that same Block, aware only to the decrypter itself. Actually this presents a potential weakness, although admittedly a small leakage. By only encrypting the payload a surprising amount of information can be derived, allowing highly selective attacking. I see no problem with my proposal actually being embedded inside a block, or with placing some extra necessary information in an additional subheader. > > One reason for doing this is it allows the file to be manipulated, without > requiring any sort of decryption to occur. For instance, the file could > be remuxed if it were damaged. And one reason for not doing it is because anyone can remux it, creating an unauthorized variation of the file, without requiring any sort of decryption to occur (for example removing a "sold-to" track). That's why I'm pushing for a generic tool that can be placed at any level of the file, if unauthorized remuxes are to be prevented, then the encryption can be placed higher up. If unauthorized remuxes are to be allowed, the encryption can be placed lower. Like I said before there are a lot of very easy, and very subtle holes that can be introduced. > [C]urrent system. . . hasn't been implemented by anyone Thanx, I was very interested in information about whether or not it had been implemented, which would prevent a big rip and replace. > So if it were possible to use some method that resulted in the same > benefits, that would be wonderful. I think the system I have proposed offers such benefits, even if it is in a very subtle way. By using a design that stands in the parsing pipeline it is possible to create a design that works at any level, even within the block itself, and can make use of different handlers for different tracks and different parts of the file. Joe From paul at msn.com Tue Dec 20 20:47:11 2005 From: paul at msn.com (Paul Bryson) Date: Tue, 20 Dec 2005 13:47:11 -0600 Subject: [Matroska-devel] Re: Re: Encryption References: Message-ID: "Joseph Ashwood" wrote... > And one reason for not doing it is because anyone can remux it, creating > an unauthorized variation of the file, without requiring any sort of > decryption to occur (for example removing a "sold-to" track). You may want to look at the SignatureSlot element. It allows contents to be signed for authenticity, so if the content is changed, then the signing would no longer match. I assume that if a DRM system is good enough to safely exchange keys, then it is good enough to be able to check that the file contains all required elements. In the end, there is no way to 100% prevent unauthorized altering of files. No matter how DRM'd a file is, I can always capture video being sent to the overlay and audio being sent to the sound card. But DRM decoders requiring certain signed elements should work for any 'reasonable expectations' for file protection. Of course this does not at all address any weaknesses introduced by being able to determine timecode and frame type. Atamido From ashwood at msn.com Wed Dec 21 09:41:04 2005 From: ashwood at msn.com (Joseph Ashwood) Date: Wed, 21 Dec 2005 00:41:04 -0800 Subject: [Matroska-devel] Re: Re: Encryption References: Message-ID: "Paul Bryson" wrote in message news:do9mvd$s44$1 at sea.gmane.org... > "Joseph Ashwood" wrote... >> And one reason for not doing it is because anyone can remux it, creating >> an unauthorized variation of the file, without requiring any sort of >> decryption to occur (for example removing a "sold-to" track). > > You may want to look at the SignatureSlot element. It allows contents to > be signed for authenticity, so if the content is changed, then the signing > would no longer match. I have looked at it, the specification is enormously incomplete, and begins by creating a security hole. "Signature of some (coming) elements" is inviting the attacker to play games with your signature, invalidating the meaning of it, without invalidating the signature itself. The signature has to be across everything that isn't purely static (i.e. the EBML header can be excluded) otherwise you're inviting tampering. This is why I specified a tool to be capable across levels. In my design it is entirely possible to wrap Segment. The failing of my design is that if there is more than one Segment the tamper-proofing crumbles, each Segment would be signed seperately, making tampering potentially possible. The solution is to create a super-format to deal with this, or specify that the encrypted area contains one-or-more of the claimed element, and that the element should only be taken as guidance, the actual internal data may be different. This is how hard cryptography is, even with a decade of experience, there was a subtle, but correctable, problem with my design, there is no gaurentee that the single element design works, instead it needs to be one-or-more, and that it is only a hint for the processor there is not guarantee as to what it contains, it may contain nothing. These changes may seem insignificant, but actually they substantially improve the security behaviors. Joe From betaboy at corecodec.com Wed Dec 21 18:27:08 2005 From: betaboy at corecodec.com (Dan Marlin) Date: Wed, 21 Dec 2005 17:27:08 +0000 (UTC) Subject: [Matroska-devel] Re: a new icon design References: <20051106063815.70987.qmail@web51606.mail.yahoo.com> <43730142.10402@free.fr> Message-ID: > Hey, > > It looks good. If you're good at graphics can you try to do an icon for > most of the regular sizes (16x16 / 32x32 / 64x64) ? The one we use so > far in most of our softwares (and on the website) is kinda plain and now > very explanative. > > thx Kyle... can you do what Steve asked or post the PSD files for us to do it? Thanx Danny From ashwood at msn.com Thu Dec 22 19:10:12 2005 From: ashwood at msn.com (Joseph Ashwood) Date: Thu, 22 Dec 2005 10:10:12 -0800 Subject: [Matroska-devel] Compromise Encryption Proposal Message-ID: I think this compromise accomplishes the desires of both sides. I'm having trouble locating the correct terminology, so I'm just going to go all the way back to C-structs (Segment is in this case an example of a struct). Keep the initializer proposal I made. With some changes though. In addition to sitting alonog side Segment at the highest level, any struct can contain them, effectively defining local variables. Local definitions supercede those that are global to them. For duplicate definitions at the same level, behavior is not defined. Each struct contains a single, optional field called Transform (name can and should be changed as needed). Transform is a 32-bit bitfield, defining the (previously initialized) transform to be used. The inverse transform is free to make any changes to the struct, so for example, it is free to change timecodes. An inverse transform may return a single struct, multiple structs, or no structs, each of which can be of any type, and may contain an additional Transform requirement. The inverse transform SHOULD avoid changing the information except where security trumps this requirement. This allows the parser to perform look-ahead processing, as Paul desired, but also allows the inverse transform to force non-malleability in cases where it is warranted. 99+% of the time, the biggest change will be if the transform results in multiple SimpleBlocks. Is this a worthwhile compromise? Joe From jcsston at jory.info Thu Dec 22 19:21:13 2005 From: jcsston at jory.info (Jory Stone) Date: Thu, 22 Dec 2005 12:21:13 -0600 Subject: [Matroska-devel] Re: [Matroska-users] Windows me problem (similar to win98) In-Reply-To: <20051222164831.65219.qmail@web53504.mail.yahoo.com> References: <20051222164831.65219.qmail@web53504.mail.yahoo.com> Message-ID: <43AAEE99.7090202@jory.info> Why is Win9X no longer supported? The only major issue dependent on Matroska is Unicode, which is easily fixed for most programs via the Unicows wrapper. Andres Taveras wrote: > Hello, I know you've seen this before, but > Quote: > > a_a, > > i am sorry to say but Windows 98 is an obsolete OS, > and not supported by > most of our stuff. You also have to be aware that most > of the video > compression methods used in MKV files today will > require at least an > Athlon XP > 1GHz for smooth playback, so you maybe > wont be able to play > the MKV file you got at all on your old PC. > > Last thing i can recommend to you is to try VLC 0.8.4 > player from > http://videolan.org . Its not based on DirectShow, so > you don't need any > matroska packs installed. Also its reported to work > fine on Win9X. > > Christian > matroska project admin > > > a a schrieb: > > >>hello I went to the site: >> >>http://packs.matroska.org/ >> >>Matroska Pack Full v1.1.2 (2005-10-15) doesnt work > > because I'm using > >>Windows 98 >> >> >>Matroska Pack Lite v1.1.2 (2005-10-15) *does not > > install completely* > >>there is an error associated with this pack I > > donwload and try to > >>install. >> >>*it says "Runtime Error. this application has > > requested the > >>Runtime to terminate in an unusual way. please > > contact the > >>application's support team for more information."* >> >>why is this happening?? I try earlier lite packs > > but they fail to > >>play the video I want to play, which is a mastroka > > file. > >> >>I use windows media player classic version 6.4.7.7. >> >>and I have another windows media player classic > > version 6.4.8.2. but > >>it doesnt work there either. >> >>please help > > > > I have checked the other email about the same problem > I'm having with the installation of the matroska pack > lite 1.1.2 and you said earlier that there was no > support for win98, but I've have the same problem with > windows me, any way to get around it? I've tryed the > newest vlc player, but in some (or most old) MKV files > I play won't play right or it freezes up the image and > I get frusterated with it, if played in windows media > classic, it plays fine with the older versions of > matroska packs, but it messes up with other codecs > installed no matter what I try whether it's the lite > or the full version of 1.1.1 1.0.3 or older... Help... Thanks > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > > > ------------------------------------------------------------------------ > > > ------------------------------------------------------------------------ > > _______________________________________________ > Matroska-users mailing list > Matroska-users at lists.matroska.org > http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-users > Read Matroska-Users on GMane: http://dir.gmane.org/gmane.comp.multimedia.matroska.user From matej.jordan at siol.net Mon Dec 26 14:37:11 2005 From: matej.jordan at siol.net (Matej) Date: Mon, 26 Dec 2005 14:37:11 +0100 Subject: [Matroska-devel] new codec for video Message-ID: <000001c60a21$86f5ebe0$0132a8c0@mjwinxp> I've get film, and I saw that it could not play in my BSplayer, so I looked at file extension and I saw .mkv, so I went to www.filext.com , and there I figured out it is new kind of format. Why the fuck do you have to contaminate net, why the fuck do I have to download fucking codec for films, could me mpg, avi, wmv no it must be new, huh. Then maybe more crazy morons try to convert films into your format, why, why?. Stop contaminating; there was no need for you format, just waste of time, besides who would use codec with such ugly name like 'Matroska' damn it west don't like fuckin' communist names (even if it is now 'Russia'), youp the name Hollywood would love to use. I can think of better name, say .mmf (markup language media format - that should be tha name for everything). Thank, you. I couldn enjoy more than downloading your codec. Die bitches. -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul at msn.com Mon Dec 26 22:43:49 2005 From: paul at msn.com (Paul Bryson) Date: Mon, 26 Dec 2005 15:43:49 -0600 Subject: [Matroska-devel] Re: new codec for video References: <000001c60a21$86f5ebe0$0132a8c0@mjwinxp> Message-ID: And thus we see comprehensive proof of The Greater Internet F*wad Theory. http://www.penny-arcade.com/comic/2004/03/19 "Matej" wrote in message news:000001c60a21$86f5ebe0$0132a8c0 at mjwinxp... I've get film, and I saw that it could not play in my BSplayer, so I looked at file extension and I saw .mkv, so I went to www.filext.com, and there I figured out it is new kind of format. Why the fuck do you have to contaminate net, why the fuck do I have to download fucking codec for films, could me mpg, avi, wmv no it must be new, huh. Then maybe more crazy morons try to convert films into your format, why, why?. Stop contaminating; there was no need for you format, just waste of time, besides who would use codec with such ugly name like 'Matroska' damn it west don't like fuckin' communist names (even if it is now 'Russia'), youp the name Hollywood would love to use. I can think of better name, say .mmf (markup language media format - that should be tha name for everything). Thank, you. I couldn enjoy more than downloading your codec. Die bitches. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivanburnin at hushmail.com Tue Dec 27 07:06:14 2005 From: ivanburnin at hushmail.com (ivanburnin at hushmail.com) Date: Mon, 26 Dec 2005 22:06:14 -0800 Subject: [Matroska-devel] new codec for video Message-ID: <200512270606.jBR66HCL001787@mailserver2.hushmail.com> On Mon, 26 Dec 2005 05:37:11 -0800 Matej wrote: We love you too. Concerned about your privacy? Instantly send FREE secure email, no account required http://www.hushmail.com/send?l=480 Get the best prices on SSL certificates from Hushmail https://www.hushssl.com?l=485 From chris at matroska.org Tue Dec 27 17:20:59 2005 From: chris at matroska.org (Christian HJ Wiesner) Date: Tue, 27 Dec 2005 17:20:59 +0100 Subject: [Matroska-devel] new codec for video In-Reply-To: <000001c60a21$86f5ebe0$0132a8c0@mjwinxp> References: <000001c60a21$86f5ebe0$0132a8c0@mjwinxp> Message-ID: <43B169EB.7090609@matroska.org> Matej schrieb: > I've get film, and I saw that it could not play in my BSplayer, so I > looked at file extension and I saw .mkv, so I went to www.filext.com > , and there I figured out it is new kind of > format? Why the fuck do you have to contaminate net, why the fuck do I > have to download fucking codec for films, could me mpg, avi, wmv no it > must be new, huh. Then maybe more crazy morons try to convert films > into your format, why, why?. Stop contaminating; there was no need for > you format, just waste of time, besides who would use codec with such > ugly name like ?Matroska? damn it west don?t like fuckin? communist > names (even if it is now ?Russia?), youp the name Hollywood would love > to use. I can think of better name, say .mmf (markup language media > format ? that should be tha name for everything). > > Thank, you? I couldn enjoy more than downloading your codec. Die bitches. > You have no clue what you are talking about. matroska is a container, not a codec or a format. matroska can contain MPEG1/2/4, DivX, MP3, etc.. How can you DARE to insult other people without having any kind of knowledge about what they are actually doing, or trying to achieve ? After all, it's the choice of the people making and distributing the movie to go for MKV, and to not use any of the other known containers, like AVI or ASF. You got something for free from the internet, you didn't pay a penny for it. How can you actually even CONSIDER to complain about the container it is distributed in ? I bet you are nothing but a stupid leecher, one of the guys who always download but never upload, and then even complain how the author of the movie could dare to use a container they are not familiar with. You Sir, suck ! Christian matroska project admin From sporks5000 at gmail.com Tue Dec 27 18:53:27 2005 From: sporks5000 at gmail.com (=?WINDOWS-1252?Q?Ausitn_Cot=E9_Williams?=) Date: Tue, 27 Dec 2005 12:53:27 -0500 Subject: [Matroska-devel] new codec for video In-Reply-To: <000001c60a21$86f5ebe0$0132a8c0@mjwinxp> References: <000001c60a21$86f5ebe0$0132a8c0@mjwinxp> Message-ID: <658f9a740512270953rbfedf3ey932d5849e8f3154a@mail.gmail.com> Dear MateJ, Glad to hear that you've taken the time to download the software necessary to play Matroska files! I hope that you're able to warm up to them more in the future. Judging by your post here, though, I'm under the impression that you're having a bit of confusion as to exactly what Matroska is. You see, rather than a codec, Matroska is a container file, much like Audio Video Interleave (AVI) or MPG. It's a file format designed to take other data - be it audio, video, subtitles, etc. - and bundle it together so that your computer is better able to process it. More off, Matroska isn't just any container format, Matroska is the *best* container format! Matroska is designed so that it can handle any audio or video format without trouble. Unlike MPG or AVI files, it's streamable ? you don't have to have the whole file downloaded before you can begin playing it - and unlike WMV files, it can contain audio and video formats other than just the ones that Microsoft wants to push, some of which can achieve far better compression ratios! Matroska is also typically smaller. When compared to AVI files containing the same video and audio data, MKV files are typically 0.5% to 1% smaller! I've had enough downloads peter out at the last minute to know that that can make a world of difference! A more comprehensive comparison of Matroska to various other container formats is available at http://en.wikipedia.org/wiki/Comparison_of_container_formats . You took the time to find this list and mail us your complaint, now take the time to do the research and discover why Matroska is the best container format for your audio and video needs! > I've get film, and I saw that it could not play in my BSplayer, so I looked > at file extension and I saw .mkv, so I went to www.filext.com, and there I > figured out it is new kind of format? Why the fuck do you have to > contaminate net, why the fuck do I have to download fucking codec for films, > could me mpg, avi, wmv no it must be new, huh. Then maybe more crazy morons > try to convert films into your format, why, why?. Stop contaminating; there > was no need for you format, just waste of time, besides who would use codec > with such ugly name like 'Matroska' damn it west don't like fuckin' > communist names (even if it is now 'Russia'), youp the name Hollywood would > love to use. I can think of better name, say .mmf (markup language media > format ? that should be tha name for everything). > > Thank, you? I couldn enjoy more than downloading your codec. Die bitches. From steve.lhomme at free.fr Tue Dec 27 22:23:44 2005 From: steve.lhomme at free.fr (Steve Lhomme) Date: Tue, 27 Dec 2005 11:23:44 -1000 Subject: [Matroska-devel] DivX XSUB subtitle format Message-ID: <43B1B0E0.8020908@free.fr> Hi all, As the source of the XSUB encoder are public and in DrFFMPEG here is the format of the XSUB subtitle in .divx/DMF files : typedef struct Color { uint8_t red; uint8_t green; uint8_t blue; } Color; // DivX Subpicture Packet header typedef struct DivxSubPictPackHdr { // Duration in the following format // [HH:MM:SS.XXX-hh:mm:ss.xxx] // Note: There is no NUL at the end char duration[27]; // Subpicture dimensions & coordinates uint16_t width; uint16_t height; uint16_t left; uint16_t top; uint16_t right; uint16_t bottom; uint16_t fieldOffset; // Background, pattern, emphasis1, emphasis2 colors Color background; Color pattern; Color emphasis1; Color emphasis2; } DivxSubPictPackHdr; #define SIZEOF_XSUB_PACKET 53 This is stored in little-endian with the exact size for each field. I think Gabest shouldn't have a hard time supporting the format too. -- robUx4 on blog -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: xsub.c URL: