From jcsston at ToughGuy.net Fri Aug 1 22:30:30 2003 From: jcsston at ToughGuy.net (Jory) Date: Fri, 1 Aug 2003 15:30:30 -0500 Subject: [Matroska-devel] Matroska Tag Mappings to other tagging systems Message-ID: <001301c3586b$ee742580$0200a8c0@jcsston> Since I have tagging working almost perfectly in the Shell Ext/CDL and Cyrius has Matroska Tags in VDubMOD. I think we need to define how other tagging systems would map to ours before doing a public release. So that each tool would call a tag the same thing ;) @Pamel: I know you have made a comparsion table. So could you update it to match the current specs? I also think the table needs to be split up into smaller bits to make it easier to read. http://cvs.corecodec.org/cgi-bin/viewcvs.cgi/*checkout*/matroska/doc/website /technical/specs/tagging/othertagsystems/comparetable.html Thanks, Jory Stone jcsston at toughguy.net Matroska, the new, extensible open standard A/V container format http://www.matroska.org/ From paul at msn.com Sat Aug 2 17:52:27 2003 From: paul at msn.com (Pamel) Date: Sat, 2 Aug 2003 10:52:27 -0500 Subject: [Matroska-devel] Track offset Message-ID: I am working on an encode with an offset for the audio, and I was wondering if this was ever going to be implemented. http://www.corecodec.com/modules.php?op=modload&name=PNphpBB2&file=viewtopic&p=1127#1127 I realize everyone is busy right now getting ready for the release, but this would make life much easier for some situations. Pamel From chris at matroska.org Mon Aug 4 10:47:52 2003 From: chris at matroska.org (Christian HJ Wiesner) Date: Mon, 04 Aug 2003 10:47:52 +0200 Subject: [Matroska-devel] Urgent !!!! Matroska Installation pack for the CHIP PC magazine release ! In-Reply-To: <3ECA1BB3.1010508@optusnet.com.au> References: <3EC9B566.4030102@matroska.org> <3ECA1BB3.1010508@optusnet.com.au> Message-ID: <3F2E1DB8.9090403@matroska.org> Guys, i urgently need a volunteer for the NSIS installation pack with the latest filters. I am not sure if insolit's pack is maybe exactly what we need, but this is pretty urgent and i cant get hold of him on IRC as he seems to be away, we want to give the installer to the CHIP guys this afternoon. It should include 1. matroskasplitter.ax from gabest ; http://sf.net/projects/guliverkli 2. matroskamuxer.ax from gabest ; dto. 3. CoreVorbis ; http://corecodec.org/projects/corevorbis 4. Matrix mixer ; http://sf.net/projects/matrixmixer 5. DVobSub ( vsfilter ) 6. DaveEL's timestamp manager ( for the future, that way all people installing the pack have it already on their machines, and it doesnt hurt them either as it wont interfere with matroskasplitter.ax : http://www.wiesneronline.net/downloads/matroska/tm.rar , ver. 26th July ) Its important that the installer has a deinstall function also, and even more that the version of the OS is checked during installation, and the non-unicode version of matroskaspliter, matroskamuxer and vsfilter are installed for Win9x/ME. Anybody up to the job quickly? Need that until this afternoon Thanks Christian From chris at matroska.org Mon Aug 4 11:16:20 2003 From: chris at matroska.org (Christian HJ Wiesner) Date: Mon, 04 Aug 2003 11:16:20 +0200 Subject: [Matroska-devel] Urgent !!!! Matroska Installation pack for the CHIP PC magazine release ! In-Reply-To: <3F2E1DB8.9090403@matroska.org> References: <3EC9B566.4030102@matroska.org> <3ECA1BB3.1010508@optusnet.com.au> <3F2E1DB8.9090403@matroska.org> Message-ID: <3F2E2464.9090008@matroska.org> Christian HJ Wiesner wrote: > 6. DaveEL's timestamp manager ( for the future, that way all people > installing the pack have it already on their machines, and it doesnt > hurt them either as it wont interfere with matroskasplitter.ax : > http://www.wiesneronline.net/downloads/matroska/tm.rar , ver. 26th July ) Dave made a newer version with lower merit to exclude interference with matroskasplitter.ax in any case, and gave it a new GUID also : http://daveel.dnsalias.com/tm.rar Christian From steve.lhomme at free.fr Thu Aug 7 10:32:35 2003 From: steve.lhomme at free.fr (Steve Lhomme) Date: Thu, 7 Aug 2003 10:32:35 +0200 Subject: [Matroska-devel] ICC & libebml Message-ID: <003201c35cbe$73e2c950$0c7ba8c0@ing12> I just saw this here : http://forum.doom9.org/showthread.php?s=&threadid=58814 - Fixed P4 build. LibEBML doesn't work with the Intel compiler, so its compiled with the normal M$ one. We need to fix that ! What is wrong with it, and what version ? From jcsston at ToughGuy.net Fri Aug 8 08:52:27 2003 From: jcsston at ToughGuy.net (Jory) Date: Fri, 8 Aug 2003 01:52:27 -0500 Subject: [Matroska-devel] Matroska Tag Mappings to other tagging systems References: <001301c3586b$ee742580$0200a8c0@jcsston> Message-ID: <000001c35d7b$ae2d49b0$0200a8c0@jcsston> This is the tag mapping I'm using in the Matroska TCMP CDL. Artist = MultiEntity, Type = LeadPerformerSoloist, Title = MultiTitle, Type = TrackTitle Album = MultiTitle, Type = AlbumMovieShowTitle Track = DiscTrack Genre = AudioGenre (reads Tag_SunGenre if Tag_AudioGenre is empty) Year =MultiDate, Type = ReleaseDate Comment = Multi-Comment ----- Original Message ----- From: "Jory" To: "Discussion about the current and future development of Matroska" Sent: Friday, August 01, 2003 3:30 PM Subject: [Matroska-devel] Matroska Tag Mappings to other tagging systems > Since I have tagging working almost perfectly in the Shell Ext/CDL and > Cyrius has Matroska Tags in VDubMOD. I think we need to define how other > tagging systems would map to ours before doing a public release. So that > each tool would call a tag the same thing ;) > > @Pamel: I know you have made a comparsion table. So could you update it to > match the current specs? I also think the table needs to be split up into > smaller bits to make it easier to read. > http://cvs.corecodec.org/cgi-bin/viewcvs.cgi/*checkout*/matroska/doc/website > /technical/specs/tagging/othertagsystems/comparetable.html > > Thanks, > Jory Stone > jcsston at toughguy.net > Matroska, the new, extensible open standard A/V container format > http://www.matroska.org/ > > > _______________________________________________ > Matroska-devel mailing list > Matroska-devel at lists.matroska.org > http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel From chris at matroska.org Fri Aug 8 13:05:59 2003 From: chris at matroska.org (Christian HJ Wiesner) Date: Fri, 08 Aug 2003 13:05:59 +0200 Subject: [Matroska-devel] Replacing MPC SV8 framing with a stripped down matroska 'elementary' file ? Message-ID: <3F338417.2030805@matroska.org> Hi devs, http://www.personal.uni-jena.de/~pfk/mpp/sv8/components.html It appears to me that Frank Klemm might have got the hang of working on SV8, and IMHO the main reasons for this could be - although many people are using MPC, he didnt get any valuable input from other devs ( apart from Case ) about his proposed specs changes for the SV8 framing. I guess robux4 can confirm, nothing is more demotivating for a developer who invested quite a lot of time into making a clear, readable specs page ( me is reminded about transor API ), and getting no feedback at all. - he sees that this is a LOT of work to do, and also the encoder needs to be improved same time to keep up with the development speed of other 'competing' formats ( Frank's strong side ). On the other hand, the limitations of SV7 are such that he doesnt want to go on with development of MPC, using this old framing ( no 5.1/7.1 defined, no DRC fields, high overhead, low error resilience, etc. ) I am turning to you guys, and i know you have all hands full of work, to take a short timeout from current matroska development and have a look at the SV8 specs as linked above. matroska gets a lot of motivating cheers from all sides currently and its fun to work under these conditions, but we should not forget that it was Frank who helped a lot to define the basic EBML structure these days, by brainstorming together with Steve about how a good container should look alike. Your comments, and even only technical questions about the current draft, should go to mpc-devel at freelists.org, the official MPC Development ML ( Frank is subscribed still ... at least i hope so ) . Best regards Christian From moritz at bunkus.org Fri Aug 8 18:41:21 2003 From: moritz at bunkus.org (Moritz Bunkus) Date: Fri, 8 Aug 2003 18:41:21 +0200 Subject: [Matroska-devel] AAC+ Message-ID: <20030808164121.GG25655@bunkus.org> Heya. I'd just like to know what the final decision on AAC+ was. The muxer tries to detect the type, and then it sets... ... the CodecID to A_AAC/MPEG2/SBR or A_AAC/MPEG4/SBR ... ... and does not put anything into CodecPrivate ... ... and sets the KaxSampleRate to the sample rate decoded from the ADTS headers (which is the lower one, not the output sample rate)? Or what was the consensus? -- ==> Ciao, Mosu (Moritz Bunkus) From steve.lhomme at free.fr Fri Aug 8 19:27:45 2003 From: steve.lhomme at free.fr (Steve Lhomme) Date: Fri, 08 Aug 2003 19:27:45 +0200 Subject: [Matroska-devel] AAC+ In-Reply-To: <20030808164121.GG25655@bunkus.org> References: <20030808164121.GG25655@bunkus.org> Message-ID: <3F33DD91.1060700@free.fr> Moritz Bunkus wrote: > Heya. > > I'd just like to know what the final decision on AAC+ was. The muxer > tries to detect the type, and then it sets... > > ... the CodecID to A_AAC/MPEG2/SBR or A_AAC/MPEG4/SBR ... > ... and does not put anything into CodecPrivate ... > ... and sets the KaxSampleRate to the sample rate decoded from the ADTS > headers (which is the lower one, not the output sample rate)? > > Or what was the consensus? I'm going to add an additional element for the extended sampling frequency this week-end. For the rest, do as you wish :) From steve.lhomme at free.fr Fri Aug 8 19:43:05 2003 From: steve.lhomme at free.fr (Steve Lhomme) Date: Fri, 08 Aug 2003 19:43:05 +0200 Subject: [Matroska-devel] AAC+ In-Reply-To: <3F33DD91.1060700@free.fr> References: <20030808164121.GG25655@bunkus.org> <3F33DD91.1060700@free.fr> Message-ID: <3F33E129.7080108@free.fr> Steve Lhomme wrote: > Moritz Bunkus wrote: > >> Heya. >> >> I'd just like to know what the final decision on AAC+ was. The muxer >> tries to detect the type, and then it sets... >> >> ... the CodecID to A_AAC/MPEG2/SBR or A_AAC/MPEG4/SBR ... >> ... and does not put anything into CodecPrivate ... >> ... and sets the KaxSampleRate to the sample rate decoded from the ADTS >> headers (which is the lower one, not the output sample rate)? >> >> Or what was the consensus? > > > I'm going to add an additional element for the extended sampling > frequency this week-end. For the rest, do as you wish :) I just added it. please verify that the new ID is unique (KaxAudioOutputSamplingFrequency) From moritz at bunkus.org Fri Aug 8 20:00:15 2003 From: moritz at bunkus.org (Moritz Bunkus) Date: Fri, 8 Aug 2003 20:00:15 +0200 Subject: [Matroska-devel] AAC+ detection Message-ID: <20030808180014.GH25655@bunkus.org> Hi. Bad news from the AAC+ detection front. I've tried menno's suggestion which basically was... there may be another way that could work though 1. search for a 3 bit value 6 (ID_FIL) (ok this is not an uncommon bit field, but there should be a pttaren after that) 2. read the 4 bits after that, if it is the value 15 read 8 more bits 3. read 4 more bits, if it is value 13 or 14 you may have detected SBR 4. repeat this for every 3 bit value 6 until you find that value of 13 or 14 5. stop when you handled more data then 1 SBR frame, if you didn't find the value 13 or 14 you don't have SBR ChrisHJW: once for every channel element but detecting it once should be ok I think this pattern is unlikely to occur randomly but it's not fail safe So my detection code looks like this: for (old_pos = 0; old_pos < (size - 3) * 8; old_pos++) { bc.set_bit_position(old_pos); if (bc.get_bits(3, value)) return false; if (value != 6) continue; if (bc.get_bits(4, value)) return false; if ((value == 15) && bc.get_bits(8, value)) return false; if (bc.get_bits(4, value)) return false; if ((value == 13) || (value == 14)) num_found++; } For the two AAC+ sample files that I do have (castanets.aac, sample_44-2-16_HE_AAC.aac) I find exactly two places with this pattern. For some other files I have (vsshort.aac encoded with faac, some other file someone sent me encoded with Nero 5) i get varying number of occurences - 0 times, 4 times, 26 times. Could someone with menno's email address please forward this email to him and ask him for advice? Maybe I didn't get the code right, maybe the same is not as rare as we'd hope it would be, maybe maybe... And could someone please encode http://www.bunkus.org/videotools/mkvtoolnix/samples/vsshort.wav with Nero 6 to AAC+ and send that file to me? Chris? :) Thanks. -- ==> Ciao, Mosu (Moritz Bunkus) From chris at matroska.org Mon Aug 11 10:35:15 2003 From: chris at matroska.org (Christian HJ Wiesner) Date: Mon, 11 Aug 2003 10:35:15 +0200 Subject: [Matroska-devel] Starting point for MKV menu system ? --> CDA ? Message-ID: <3F375543.7060909@matroska.org> Hi, those with interest in the menu system ( Pamel ? ), can you please have a look here : http://www.utdallas.edu/~jeremy.bryan.smith/software/cda.html Usable in any form ? Could we talk to the guy to move the project as opensource to corecodec.org, and to create the opensource menu system we wanted to have for matroska ? Christian From chris at matroska.org Mon Aug 11 13:14:03 2003 From: chris at matroska.org (Christian HJ Wiesner) Date: Mon, 11 Aug 2003 13:14:03 +0200 Subject: [Matroska-devel] Request for a hi-speed bitmap compression format standard Message-ID: <3F377A7B.3040501@matroska.org> Hi, please allow me to introduce myself, my name is Christian HJ Wiesner and i am one of the project administrators for an openstandard / opensource audio/video container format called matroska ( http://www.matroska.org ). Our project has a couple of goals, of which the most important are : - Fully replace the old, updated AVI container as the most used video container ( still ! ) - Creat a number of matroska file creation/editing/repairing/playback tools for all OSes, also Windows ( DirectShow parser filter, etc. ) - Prepare a good and valid set of documents, to make sure matroska can be implemented by closed source applications also ( matroska specs are public domaine, but libraries are GPL/QPL ) One of our major group of users for matroska files ( .MKV ) are doing so because it is offering very good support for most of the existing text based subtitles standards already, such as - SRT - SSA - ASS - USF ( soon ) Typical filesize for a subs stream of a complete movie is about 20 - 60 KB, so normally its no problem to include several subtitles streams into one file ( see here for a sample file with subs in 18 languages : http://matroska.free.fr/samples/mewmew ) . However, in many cases the subtitles sources are not text, but RLE compressed bitmaps. In one of our next tool releases we will offer the users the possibility to mux these bitmap subtitles ( also commonly called VOBSUBs ) into matroska files, like for DVDs . However, due to the weak compression that the RLE standard will offer, they are still like 4 - 8 MB in size. For this reason we were planning to compress them down further, and did a couple of tests how to do that in best case. PNG was our first bet ( of course ), but unfortunately the results were proving that its unusable for our purpose, at least in its current form, as the necessary CPU power to decode a PNG compressed subtitle bitmap is simply too high. Imaging that we will play the movies on normal PCs ( min standard should be a PIII 800 MHz as per our recommendation ), and the CPU has to - decode the video, mainly MPEG4 or RealVideo9 ( very CPU intensive, especially for higher resolutions ) - decode the audio, very often 5.1 AC3 or 5.1 AAC tracks - decode the compressed subtitle bitmap More tests were done, and the best solution we currently have is to use lzo on the original RLE precompressed subtitles, with a 1:7 compression ratio. Here the results when comparing those general use compression libs, the code for this comparison as well as the sample file it was performed on is attached : ------------------------------------------------------------------------------------------------ Reading VOBSUB chunk... done Compressing data... 1) lzo1x_1... 2) lzo1x_999... 3) zlib1g l1... 4) zlib1g l9... 5) bzlib1g l1... 6) bzlib1g l9... Decompressing data... 1) lzo1x_1... 2) lzo1x_999... 3) zlib1g l1... 4) zlib1g l9... 5) bzlib1g l1... 6) bzlib1g l9... Results - size: 1) lzo1x_1 compressed size: 587, ratio: 14.33% 2) lzo1x_999 compressed size: 542, ratio: 13.23% 3) zlib l1 compressed size: 561, ratio: 13.70% 4) zlib l9 compressed size: 535, ratio: 13.06% 5) bzlib l1 compressed size: 658, ratio: 16.06% 6) bzlib l9 compressed size: 658, ratio: 16.06% Results - speed: 1) lzo1x_1 decompression time: 1111.283ms, 89986.1 blocks/s 2) lzo1x_999 decompression time: 1504.558ms, 66464.7 blocks/s 3) zlib l1 decompression time: 13653.456ms, 7324.2 blocks/s 4) zlib l9 decompression time: 13660.727ms, 7320.3 blocks/s 3) bzlib l1 decompression time: 40515.699ms, 2468.2 blocks/s 4) bzlib l9 decompression time: 39775.623ms, 2514.1 blocks/s ------------------------------------------------------------------------------------------------ As you can see, lzo clearly compressed best for us in this case and its the fastest by almost factor 40 compared to bzlib, while the compression ratio is even higher. The typical block size of a bitmap in a vobsub subtitle is 4 - 6 KB, thats maybe why. Of course, these results are not 100% usable for our purposes, as we cant compress the complete subtitles stream and put this into the container, instead we have to compress every single bitmap in its own and pack it into a frame block in the matroska container, else the file could not be edited in a video editing tool. When using this form of compression, we could shrink down a complete bitmap subtitle stream from about 4 - 8 MB to about 500 - 1000 KB, which is much more acceptable compared to the 700 or 800 MB you have on a CD. However, after thinking a while we dont like the original approach of simply using lzo on the RLE compressed vobsub too much, for a couple of reasons : - this solution would be a very specific matroska solution, not compliant to any existing picture compression standard - hardware support for this may be impossible, or at least highly unlikely to happen ( yes, we have plans to approach hardware manufacturers for matroska support also ) - there is a big questionmark behind us implementing RLE decompressor algorithms in our playback decoder filters, which is still necessary after the first lzo decompressor stage Now, after this long explanation, here my questions to you guys : 1. Is there any chance to make PNG much faster than it currently is, even with the disadvantage of a much lower compression ratio than what you guys normally achieve, but still be PNG spec compliant ? To be more precise, the PNGs created with our 'special' compressor should be decodable by any existing PNG decompressor lib, even when being slow. Of course, we know we have to use a special modified lib for decompressing at the desired high speed in real time, to gain the speed advantage, but thats ok with us. 2. If 1. is not possible, how big are the chances to think of an extention to the format, lets call it F-PNG ( Fast PNG ), and add this to the official PNG specs ? I am pretty sure, there is other use for such a format also. 3. We get a lot of requests from people creating their own subtitles for movies, but who make those with special ( even grafical ) tools to achieve fancy features, like highlighting words or syllables for karaoke, etc. . It is possible to include special scripting languages into our container to display those tracks that way, but as the text is UTF8 or UF 16 in most cases there is still a big problem to display those correctly on any computer ( font problem, etc. ). Using picture subs would help here a lot, but with normal BMPs, even RLE compressed, the size will become HUGE in the end, as every single change of the subtitle requires a new bitmap, so the size of such an 'enhanced' track can easily be 10x the one of a normal, and 50 - 80 MB for a subtitle track with RLE compression, or even 7 - 10 MB with lzo is absolutely unacceptable in most cases. Could a fast version of MNG ( call it F-MNG ) be used to bring this size down significantly ? Sorry about the long email, and thanks in advance for some answers. Best regards Christian -------------- next part -------------- A non-text attachment was scrubbed... Name: dst.c Type: text/x-csrc Size: 9586 bytes Desc: not available URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: Makefile URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: vobsubsample.sub Type: application/octet-stream Size: 40960 bytes Desc: not available URL: From chris at matroska.org Mon Aug 11 14:10:58 2003 From: chris at matroska.org (Christian HJ Wiesner) Date: Mon, 11 Aug 2003 14:10:58 +0200 Subject: [Matroska-devel] Request for a hi-speed bitmap compression format standard In-Reply-To: <3F377A7B.3040501@matroska.org> References: <3F377A7B.3040501@matroska.org> Message-ID: <3F3787D2.8000608@matroska.org> Christian HJ Wiesner wrote: > PNG was our first bet ( of course ), but unfortunately the results > were proving that its unusable for our purpose, at least in its > current form, as the necessary CPU power to decode a PNG compressed > subtitle bitmap is simply too high. Imaging that we will play the > movies on normal PCs ( min standard should be a PIII 800 MHz as per > our recommendation ), and the CPU has to > > - decode the video, mainly MPEG4 or RealVideo9 ( very CPU intensive, > especially for higher resolutions ) > - decode the audio, very often 5.1 AC3 or 5.1 AAC tracks > - decode the compressed subtitle bitmap Something weird came to my mind, and for very good reason i won't copy the PNG and MNG lists on this email : What do you think, how big would a MPEG1 compressed picture subtitle be ? MPEG1 has P/B frames already, so for a typical 720 x 574 ( numbers by Gabest ) *DECODED* RLE VOBSUB bitmap with 4 bits per pixel ( 16 colours in the main palette, 4 colours selected for every subpicture, equals 2 bits per pixel, but when decoded the bitmap can be shown as 4 bits per pixel in full resolution ). MPEG normally performs pretty well on single coloured ( black ) backgrounds already, and we could maybe bring the overhead down significantly by using lacing ? MPEG1 encoding is free, and MPEG1 decoding is fast Crazy idea ? Christian From rbultje at ronald.bitfreak.net Mon Aug 11 14:46:24 2003 From: rbultje at ronald.bitfreak.net (Ronald Bultje) Date: Mon, 11 Aug 2003 14:46:24 +0200 Subject: [Matroska-devel] Request for a hi-speed bitmap compression format standard In-Reply-To: <3F3787D2.8000608@matroska.org> References: <3F377A7B.3040501@matroska.org> <3F3787D2.8000608@matroska.org> Message-ID: <1060605984.4234.102.camel@shrek.bitfreak.net> Hey Chris/guys, On Mon, 2003-08-11 at 14:10, Christian HJ Wiesner wrote: > MPEG1 encoding is free No it's not. Not free as in beer, and not free as in speach either. > and MPEG1 decoding is fast Doubtful... :-p. Subtitles are effectively just UTF8 strings. Use XML or xhtml for mark-up if really you want to, and you're there. Indeed, this will cause a new text string each single second for karaoke songs, but that's not a container issue, that's something that user interfaces should work out. Most user interfaces don't show raw HTML code, but show a good-looking website. ;). A user interface can easily show a text string and let it be highlighted in several stages (all shows as one single action), while in the back-end, each of these is actually a different action. However, the user doesn't need to know. Still, this will take only 1% of the storage size and CPU cycles needed for MPEG1, and it'll take less CPU, and additionally, it'll be free, too. MPEG1 is heavily troublesome because of the nasty MPEG LA license. Go read it if you want to. ;). It's not that nice and open as you'd think at first sight. Additionally, the subtitles will also be stored in a text-like form, which makes them usable for accessibility-purposes (braille and so on) for people who need this. :). Ronald -- Ronald Bultje From chris at matroska.org Mon Aug 11 15:12:52 2003 From: chris at matroska.org (Christian HJ Wiesner) Date: Mon, 11 Aug 2003 15:12:52 +0200 Subject: [Matroska-devel] Request for a hi-speed bitmap compression format standard In-Reply-To: <1060605984.4234.102.camel@shrek.bitfreak.net> References: <3F377A7B.3040501@matroska.org> <3F3787D2.8000608@matroska.org> <1060605984.4234.102.camel@shrek.bitfreak.net> Message-ID: <3F379654.90500@matroska.org> Ronald Bultje wrote: >Hey Chris/guys, >Subtitles are effectively just UTF8 strings. > nope BBB, on DVDs, subs are special bitmap type pictures, with a special bitmap sheme, Gabest can explain it in more detail if you want, but basically what i understand from him you have - a 16 colour general palette for the complete .sub VOBSUB subtitles stream - a 4 colour subpalette for every single subtitle - resolution is typically same width as DVD, but height is 2 lines smaller, so you have 720 x 574 for PAL and 720 x 478 for NTSC - every pixel has 2 bits only, as you basically choose one of the 4 colours from the colour subpalette for the subtitle - empty lines are marked with a special 4 bit code, same is valid for the rest of a line after the last set bit ( this will save A LOT of space of course, as most lines of the complete picture are inactive ) The final result is RLE compressed, gaining in best case a 1:2 ratio. If you demux it form the DVD VOB files, you get a .idx file : timing information .sub file : RLE compressed 'bitmaps' ( the arent really bitmaps, look at the 'void line' code above, bitmaps dont have those ) and the size is tpically 4 - 8 MB per language. To make confusion perfect, there is another TEXT based subtitles format, called the 'MicroDVD' format, using the same extension, .SUB . Back on subject, the MPEG1 compressed subs would be very interesting for fansubbers, as they wouldnt have to give their SSA scripts away with the file, they could transform them to compressed picture subs, and the idea to use lzo on the already existing VOBSUB type files is no good option for them, as they use a lot of fancy features like highlighting and the like, and you need a new bitmap for every single change of the subs, like only changing the colour of a character, etc . MNG is one option for those 'moving' picture subs, but again much too slow ( like PNG ), so MPEG1 is an option, at least if the fansubbers dont want to hardcode the subs into the picture. About hardcoding of subs : I guess the fansubbers would be scared if they knew how much MPEG4 does fuck up in terms of necessary bitrate for the encoding of hardcoded subs, as the sharp contrast between picture and the subs is a pain in the ass for the ME/MP of any MPEG4 codec. A simple test was to use a constant quantizer of, say, 4, and to encode the same movie with and without hardcoded subs. I estimate that for a typical 600 MB video stream in a 700 MB movie, the difference in using subs with constant quantizer is about 30 - 40 MB, if not more. >Use XML or xhtml for >mark-up if really you want to, and you're there. >Ronald > Yes, we are :) .... ever checked http://usf.corecodec.org :) ?? Regards Christian From rbultje at ronald.bitfreak.net Mon Aug 11 16:39:10 2003 From: rbultje at ronald.bitfreak.net (Ronald Bultje) Date: Mon, 11 Aug 2003 16:39:10 +0200 Subject: [Matroska-devel] Request for a hi-speed bitmap compression format standard In-Reply-To: <3F379654.90500@matroska.org> References: <3F377A7B.3040501@matroska.org> <3F3787D2.8000608@matroska.org> <1060605984.4234.102.camel@shrek.bitfreak.net> <3F379654.90500@matroska.org> Message-ID: <1060612750.21979.107.camel@shrek.bitfreak.net> Hey Chris/all, On Mon, 2003-08-11 at 15:12, Christian HJ Wiesner wrote: > Ronald Bultje wrote: > >Subtitles are effectively just UTF8 strings. > nope BBB, on DVDs, subs are special bitmap type pictures, with a special > bitmap sheme, Gabest can explain it in more detail if you want, but > basically what i understand from him you have Well, that's DVDs. ;). I'm talking about it more generally, in broader applications than just "display on TV". DVD subtitles are useless for application in braille readers and so on. Think beyond TV. ;). Text is the way to go! It's up to the viewer application (WMP and so on) to render it nicely. > >Use XML or xhtml for > >mark-up if really you want to, and you're there. > Yes, we are :) .... ever checked http://usf.corecodec.org :) ?? I'll look at that tonight. /me @ work. :). Ronald -- Ronald Bultje From steve.lhomme at free.fr Mon Aug 11 18:35:50 2003 From: steve.lhomme at free.fr (Steve Lhomme) Date: Mon, 11 Aug 2003 18:35:50 +0200 Subject: [Matroska-devel] Starting point for MKV menu system ? --> CDA ? References: <3F375543.7060909@matroska.org> Message-ID: <00b101c36026$a04de8b0$0c7ba8c0@ing12> > those with interest in the menu system ( Pamel ? ), can you please have > a look here : > > http://www.utdallas.edu/~jeremy.bryan.smith/software/cda.html > > Usable in any form ? Could we talk to the guy to move the project as > opensource to corecodec.org, and to create the opensource menu system we > wanted to have for matroska ? Yes it could be put on CC. But it's not a menu system as we plan to use it in matroska, as it's external to the file it "controls". In our case it has to be a mix of meta data and stream informations (control track). From glennrp at comcast.net Wed Aug 13 17:24:55 2003 From: glennrp at comcast.net (Glenn Randers-Pehrson) Date: Wed, 13 Aug 2003 11:24:55 -0400 Subject: [Matroska-devel] Re: [png-list] Request for a hi-speed bitmap compression format standard In-Reply-To: <3F377A7B.3040501@matroska.org> Message-ID: <3.0.6.32.20030813112455.01001d60@mail.comcast.net> At 01:14 PM 8/11/03 +0200, Christian HJ Wiesner wrote: [long explanation omitted.. see archives...] >Now, after this long explanation, here my questions to you guys : > >1. Is there any chance to make PNG much faster than it currently is, >even with the disadvantage of a much lower compression ratio than what >you guys normally achieve, but still be PNG spec compliant ? To be more >precise, the PNGs created with our 'special' compressor should be >decodable by any existing PNG decompressor lib, even when being slow. Of >course, we know we have to use a special modified lib for decompressing >at the desired high speed in real time, to gain the speed advantage, but >thats ok with us. I don't think so. >2. If 1. is not possible, how big are the chances to think of an >extention to the format, lets call it F-PNG ( Fast PNG ), and add this >to the official PNG specs ? I am pretty sure, there is other use for >such a format also. The best approach would be to go ahead and make a private extension (compression method=128) and test it in your application. After successful demo and usage, propose the extension to this group. >3. We get a lot of requests from people creating their own subtitles for >movies, but who make those with special ( even grafical ) tools to >achieve fancy features, like highlighting words or syllables for >karaoke, etc. . It is possible to include special scripting languages >into our container to display those tracks that way, but as the text is >UTF8 or UF 16 in most cases there is still a big problem to display >those correctly on any computer ( font problem, etc. ). This sounds like something that can be done in SVG. PNG doesn't offer anything like this at present, but it could be done with a special PNG/MNG chunk or chunk set. > Using picture >subs would help here a lot, but with normal BMPs, even RLE compressed, >the size will become HUGE in the end, as every single change of the >subtitle requires a new bitmap, so the size of such an 'enhanced' track >can easily be 10x the one of a normal, and 50 - 80 MB for a subtitle >track with RLE compression, or even 7 - 10 MB with lzo is absolutely >unacceptable in most cases. Could a fast version of MNG ( call it F-MNG >) be used to bring this size down significantly ? My answers about PNG also apply to MNG. It would be interesting to see speed results for LZW (GIF) compared to your other tests. LZW becomes available for free use world wide next summer. Glenn From glennrp at comcast.net Wed Aug 13 17:35:17 2003 From: glennrp at comcast.net (Glenn Randers-Pehrson) Date: Wed, 13 Aug 2003 11:35:17 -0400 Subject: [Matroska-devel] Re: [png-list] Request for a hi-speed bitmap compression format standard In-Reply-To: <20030813081531.20306.h016.c000.wm@mail.ecliptic.biz.critic alpath.net> Message-ID: <3.0.6.32.20030813113517.010185f0@mail.comcast.net> At 08:15 AM 8/13/03 -0700, willem at schaik.com wrote: >Maybe I'm missing the point, but is it really not possible, to use OCR >to transform these bitmaps into simple ASCII strings? They already have the simple strings (with formatting data) so they wouldn't need to OCR. The question is how to convey the strings+formatting efficiently as an overlay on an image (or on a stream of images). As I said before, I think SVG can do that. Glenn From png.amc+0 at nicemice.net.RemoveThisWord Thu Aug 14 05:00:10 2003 From: png.amc+0 at nicemice.net.RemoveThisWord (Adam M. Costello) Date: Thu, 14 Aug 2003 03:00:10 +0000 Subject: [Matroska-devel] Re: [png-list] Request for a hi-speed bitmap compression format standard In-Reply-To: <3F377A7B.3040501@matroska.org> References: <3F377A7B.3040501@matroska.org> Message-ID: <20030814030010.GG23031@nicemice.net> Christian HJ Wiesner wrote: > Results - speed: > 1) lzo1x_1 decompression time: 1111.283ms, 89986.1 blocks/s > 2) lzo1x_999 decompression time: 1504.558ms, 66464.7 blocks/s > 3) zlib l1 decompression time: 13653.456ms, 7324.2 blocks/s > 4) zlib l9 decompression time: 13660.727ms, 7320.3 blocks/s > 3) bzlib l1 decompression time: 40515.699ms, 2468.2 blocks/s > 4) bzlib l9 decompression time: 39775.623ms, 2514.1 blocks/s Note that this is a comparison of various decompressors, not a comparison of the potential decompression speed of the corresponding stream formats. The zlib decompressor always checks the compressed stream for syntactic validity, and always computes a checksum of the decompressed data. The lzo decompressor that you used never checks the compressed stream for syntactic validity, and can crash the program if fed an invalid stream. Furthermore, it does not compute a checksum. If you want to get closer to the truth about the speed limitations inherent in the formats, you might try using lzo1x_decompress_safe() instead of lzo1x_decompress(), and try hacking the zlib decompressor to omit the checksum calculation. AMC From steve.lhomme at free.fr Thu Aug 14 14:01:57 2003 From: steve.lhomme at free.fr (Steve Lhomme) Date: Thu, 14 Aug 2003 14:01:57 +0200 Subject: [Matroska-devel] Is GCC safe ? Message-ID: <001101c3625b$dc6246c0$0c7ba8c0@ing12> http://news.zdnet.co.uk/internet/security/0,39020375,39115701,00.htm The GNU servers have been compromised for 4 months... From rbultje at ronald.bitfreak.net Thu Aug 14 14:43:04 2003 From: rbultje at ronald.bitfreak.net (Ronald Bultje) Date: Thu, 14 Aug 2003 14:43:04 +0200 Subject: [Matroska-devel] Is GCC safe ? In-Reply-To: <001101c3625b$dc6246c0$0c7ba8c0@ing12> References: <001101c3625b$dc6246c0$0c7ba8c0@ing12> Message-ID: <1060864984.4235.136.camel@shrek.bitfreak.net> Hey Steve, On Thu, 2003-08-14 at 14:01, Steve Lhomme wrote: > http://news.zdnet.co.uk/internet/security/0,39020375,39115701,00.htm > The GNU servers have been compromised for 4 months... Depends. Most people use linux distributions (redhat, suse), and these companies triple check such hashes. So for 99,999% of the people (including most of us), there's probably no issue. For the people who do everything themselves (LFS people), there might be issues. That's their problem. ;). And even if GCC wasn't safe, what would it do? Make it crash my computers (didn't notice a thing)? Create binaries that "rm -fr /" daily (didn't notice any such thing until now, and even if it did - it doesn't have root permission...)? Create malicious binaries so that they can take over the world (yeah, right...)? So is there an issue? Probably not... :). (My installation is older than four months, btw, so there's no issue locally. ;). ) Ronald -- Ronald Bultje From steve.lhomme at free.fr Thu Aug 14 15:11:57 2003 From: steve.lhomme at free.fr (Steve Lhomme) Date: Thu, 14 Aug 2003 15:11:57 +0200 Subject: [Matroska-devel] Is GCC safe ? References: <001101c3625b$dc6246c0$0c7ba8c0@ing12> <1060864984.4235.136.camel@shrek.bitfreak.net> Message-ID: <002901c36265$a41d04d0$0c7ba8c0@ing12> > Hey Steve, Yo > On Thu, 2003-08-14 at 14:01, Steve Lhomme wrote: > > http://news.zdnet.co.uk/internet/security/0,39020375,39115701,00.htm > > The GNU servers have been compromised for 4 months... > > Depends. Most people use linux distributions (redhat, suse), and these > companies triple check such hashes. So for 99,999% of the people > (including most of us), there's probably no issue. For the people who do > everything themselves (LFS people), there might be issues. That's their > problem. ;). > > And even if GCC wasn't safe, what would it do? Make it crash my > computers (didn't notice a thing)? Create binaries that "rm -fr /" daily > (didn't notice any such thing until now, and even if it did - it doesn't > have root permission...)? Create malicious binaries so that they can > take over the world (yeah, right...)? There's no big deal right now. But that proves that even open source code may contain some backdoors. The Linux kernel is so big (and other projects) and complex that it's simply impossible to check every line of code for what it really does. BTW I think some months ago a backdoor was found on a GCC release and they promptly removed it. (the download location had been corrupted). Just to make sure everyone is concerned about security at every stages :) From cosmin at cs.toronto.edu Thu Aug 14 21:22:27 2003 From: cosmin at cs.toronto.edu (Cosmin Truta) Date: Thu, 14 Aug 2003 15:22:27 -0400 Subject: [Matroska-devel] Re: [png-list] Request for a hi-speed bitmap compression format standard In-Reply-To: <3F377A7B.3040501@matroska.org> Message-ID: > 1. Is there any chance to make PNG much faster than it currently is, > even with the disadvantage of a much lower compression ratio than what > you guys normally achieve, but still be PNG spec compliant ? To be > more precise, the PNGs created with our 'special' compressor should be > decodable by any existing PNG decompressor lib, even when being slow. > Of course, we know we have to use a special modified lib for > decompressing at the desired high speed in real time, to gain the > speed advantage, but thats ok with us. You might want to try a beta version of the upcoming zlib-1.2: http://www.alumni.caltech.edu/~madler/zlib-1.2.0.3.tar.gz It has a faster decompression and a faster CRC. I admit the differences are not so spectacular. But, as Adam suggested, you could try to remove the Adler32 and CRC32 checks completely. Furthermore, if you are using Intel x86, there is an ASM version of inflate at http://www.charm.net/~christop/zlib/ The new zlib release should appear within a few weeks. > More tests were done, and the best solution we currently have is to > use lzo on the original RLE precompressed subtitles, with a 1:7 > compression ratio. Be careful about this one! According to comp.compression FAQ, there is a patent (4,988,998) that covers RLE followed by Ziv-Lempel 77. Ridiculous? Yes, but that still prevents you from using the method. http://www.faqs.org/faqs/compression-faq/part1/section-7.html On the other hand, you could try RLE followed by LZW, if you can wait one more year, until the LZW patent expires worldwide. Best regards, Cosmin From chris at matroska.org Mon Aug 18 03:11:31 2003 From: chris at matroska.org (Christian HJ Wiesner) Date: Mon, 18 Aug 2003 03:11:31 +0200 Subject: [Matroska-devel] Strange matroskamuxer behaviour for PCM audio ? Message-ID: <3F4027C3.7080104@matroska.org> Hi guys, please read here, thats pretty interesting : http://www.digtv.ws/forum/index.php?s=59393a5056257ee5161423f0f7fa3c40&act=ST&f=4&t=466&st=15&#entry2300 @Gabest : what could be the problem ? @Cyrius : we need to discuss ways to circumvent file parsing for the capture guys, they get made on their multi GIG files .... Christian From steve.lhomme at free.fr Tue Aug 19 09:54:14 2003 From: steve.lhomme at free.fr (Steve Lhomme) Date: Tue, 19 Aug 2003 09:54:14 +0200 Subject: [Matroska-devel] Some questions for Jory Message-ID: <001c01c36627$15afdb30$0c7ba8c0@ing12> http://www.corecodec.com/modules.php?op=modload&name=PNphpBB2&file=viewtopic&t=359 As I'm not sure of the answers it's better if Jory answers :) From chris at matroska.org Sat Aug 23 19:13:16 2003 From: chris at matroska.org (Christian HJ Wiesner) Date: Sat, 23 Aug 2003 19:13:16 +0200 Subject: [Matroska-devel] Summer vacation Message-ID: <3F47A0AC.3080906@matroska.org> Guys, after all the stress with the CHIP release and the bug-fix releases after that, i herewith declare the following week as official matroska summer vacation week :) : Its very silent in the channel and i guess i know why, everybody needs a short timeout to get motivation back. Enjoy what you are currently doing, but dont forget to join the channel from time to time .... ;) .... and Monday, 2nd September everybody is back on duty, fresh and full of energy, ok ? :D ... LOL Christian From chris at matroska.org Sun Aug 24 04:44:07 2003 From: chris at matroska.org (Christian HJ Wiesner) Date: Sun, 24 Aug 2003 04:44:07 +0200 Subject: [Matroska-devel] Connecting XviD DirectShow Encoder filter to matroskamuxer to create native files on DirectShow Message-ID: <3F482677.4060302@matroska.org> I thought i copy you on this conversation i had with Gabest on IRC : Gabest : you read the logs from my converastion with Tim Jansen ? conversation no he has made a XviD DShow encoder filter http://home.kabelfoon.nl/~jansent/dshow_enc.rar its currently using the VfW module of XviD sources, means its inserting dummy frames for b-frames, etc. and of course will use the same MEDIATYPE as AVI, and the XviD FourCC he was thinking of adding the possibility to output clean MPEG4ES streams then probably it will be saved as any other xvid coming from avi/ogm/mkv isn't xvid already not packed? so, if you add reference priority hadnling to matroskamuxer, it could be used to make the first valid MPEG4 MKV files :) but, there were several problems : I can't calculate the references - how to tell your muxer what frame is a b-frame ? oh, you cant ? even if I knew there is no general rule to find the references then we have a serious design flaw ? no it is just matroska needing to know the references :) but even native files should be producable in a live streaming process ? ? I mean, if our frame referencing system can not be used in an app that doesnt have the complete file, its not good ? I still don't understand it * Belgabor has joined #matroska * alley_cat has joined #matroska but I could add some hacks in the muxer or did i misunderstand the reason why you cant calculate the references ? * BetaBoy has joined #matroska in the muxer I can only tell if a sample is keyframe or not because DShow doesnt give you more information, right ? but I could treat every sample as a b-frame when the timestamp goes back yea it doesn't need anymore info it is the responibility of the codec to decode and reorder the frames I always said the container should not know about it... Gabest : when people want to create MP4 files with b-frames on DirectShow, dont they have the very same problems ? Or is it no problem for them, as b-frames are only 'makred' as such in the MPEG4ES stream, while MP4 container doesnt need to know at all ? in dshow there are "sync point" flags, they flag a frame from which the decoding can be done without messing up the picture = key frame yea but if a frame is a b or p frame is not needed to be known it is internal to the codec = inside the MPEG4ES cant we use other means of DirectShow to indicate frame types ? like using a synced txt stream from the encoder to the matroska muxer ..... LOL well, even matroska doesn't need to know which frame is a b-frame, it just wants reference times true frame type is not important as there can be any type not just b or p and where to get those times from so, the problem is references this is lost when passing frames between filters but I could find it out by looking at the frame timestamps thats one way or we really connect the encoder and the muxer with a 2nd line, passing pseudo-data we should think into the future maybe one day the trick with timestamps is no satisfactory well, there is a secondary time on samples we could use that ? there is sample "time" and "media time" a reserved field ? media time is used to send info like frame number, avi uses that I think is it like display time and file time ? or sample number for audio yes, a number would be perfect the normal "time" is the presentation time the other is not used by anything I know it is just there for us :) :) lets use it this is almost perfect so, we could put refs there would be a hack but noone would notice but it requires defining a new MEDIATYPE again for MKV native input, right ? no oh ? could be a regular fourcc media type but, if we make our own little 'hack' wouldnt it be good to differentiate ? it would be just the "extension" of something to avoid problems ? that way, everybody using our MEDIATYPE knows how to use this 2nd time field nothing changes for the decoders ok well, something could tell that the media time is valid... 'something' ` ?? a flag ? yea where to put ? there is space and if this flag is set, that could mean the media time holds the back and forward references as the start and end times sounds like a very good and future proof solution only multiple references couldnt be handled that way, but until we get a codec doing that, DirectShow wont be used anymore :P ah, more than two refs? :P yes well, we could still extend sample info with fields for that someway but that would really need a new media type again, there are no codecs for that ;) on the other hand, i dont feel like any matroskamuxer tool should be able to write native files without knowing EXACTLY whats going on, and so i still feel a new MEDIATYPE would be a good idea, that way we make sure only those filters that connect to matroskamuxer using this MEDIATYPE know what stuff they had to pass to us .... in any other case, Vfw files are produced w00t my first asm code, __asm { MOV EAX, version MOV EBX, 5h ADD EAX, EBX MOV version, EAX } (it adds 5 to version) ...... From jcsston at toughguy.net Wed Aug 27 02:27:43 2003 From: jcsston at toughguy.net (Jory) Date: Tue, 26 Aug 2003 19:27:43 -0500 Subject: [Matroska-devel] Add some new Tags? Message-ID: <001501c36c32$8917aa60$0200a8c0@jcsston> Hi all, I've been working with the Shell Extension and one the most common info that I cannot provide is the bitrate. I propose we add a Bitrate tag to the Tag - General element that can be filled out by the user, filled by the muxing app, or I could write some code to go through all the clusters and blockgroups of a file at calculate the bitrate. Either way I think a Tag would be much faster and better than generating the bitrate on-the-fly. Asking in the channel about this I got a few more requests for tags. >From alexnoe: Frame Count >From Gabest: Largest Block Size, so you can allocate the output buffers exactly. See Ya, Jory From steve.lhomme at free.fr Wed Aug 27 09:42:45 2003 From: steve.lhomme at free.fr (Steve Lhomme) Date: Wed, 27 Aug 2003 09:42:45 +0200 Subject: [Matroska-devel] Add some new Tags? In-Reply-To: <001501c36c32$8917aa60$0200a8c0@jcsston> References: <001501c36c32$8917aa60$0200a8c0@jcsston> Message-ID: <3F4C60F5.4010002@free.fr> Jory wrote: > Hi all, > > I've been working with the Shell Extension and one the most common info that > I cannot provide is the bitrate. > I propose we add a Bitrate tag to the Tag - General element that can be > filled out by the user, filled by the muxing app, or I could write some code > to go through all the clusters and blockgroups of a file at calculate the > bitrate. Either way I think a Tag would be much faster and better than > generating the bitrate on-the-fly. > > Asking in the channel about this I got a few more requests for tags. >>From alexnoe: Frame Count Well, tags usually set to be editable. All these extra informations are different, because they are fixed. IMO it would be more logical to put these info in the Track field. What would be the frame count useful for ? >>From Gabest: Largest Block Size, so you can allocate the output buffers > exactly. It already exists, it's called MaxCache (very different from MinCache). From tronic2 at sci.fi Wed Aug 27 19:49:53 2003 From: tronic2 at sci.fi (=?ISO-8859-1?Q?Lasse_K=E4rkk=E4inen_/_Tronic?=) Date: Wed, 27 Aug 2003 17:49:53 +0000 Subject: [Matroska-devel] Add some new Tags? In-Reply-To: <001501c36c32$8917aa60$0200a8c0@jcsston> References: <001501c36c32$8917aa60$0200a8c0@jcsston> Message-ID: <3F4CEF41.4050008@sci.fi> > I propose we add a Bitrate tag to the Tag - General element that can be > filled out by the user, filled by the muxing app, or I could write some code > to go through all the clusters and blockgroups of a file at calculate the > bitrate. Either way I think a Tag would be much faster and better than > generating the bitrate on-the-fly. Actually the total size of the track would do better. When you know the total playing length too, this can be used for calculating per-track bitrate. For total file bitrate you can naturally use the total playback time and total file size.. The field for total size has been added to the MCF specification now, thanks for supporting us ;) >>From alexnoe: Frame Count Added to MCF. >>From Gabest: Largest Block Size, so you can allocate the output buffers > exactly. It's already there. - Tronic - From steve.lhomme at free.fr Wed Aug 27 20:06:40 2003 From: steve.lhomme at free.fr (Steve Lhomme) Date: Wed, 27 Aug 2003 20:06:40 +0200 Subject: [Matroska-devel] Add some new Tags? In-Reply-To: <3F4CEF41.4050008@sci.fi> References: <001501c36c32$8917aa60$0200a8c0@jcsston> <3F4CEF41.4050008@sci.fi> Message-ID: <3F4CF330.5040308@free.fr> Lasse K?rkk?inen / Tronic wrote: >> I propose we add a Bitrate tag to the Tag - General element that can be >> filled out by the user, filled by the muxing app, or I could write >> some code >> to go through all the clusters and blockgroups of a file at calculate the >> bitrate. Either way I think a Tag would be much faster and better than >> generating the bitrate on-the-fly. > > > Actually the total size of the track would do better. When you know the > total playing length too, this can be used for calculating per-track > bitrate. For total file bitrate you can naturally use the total playback > time and total file size.. The field for total size has been added to > the MCF specification now, thanks for supporting us ;) He He. yes, good idea ! That would make the bitrate calculation unbeatable. It's the size of the data with all extra informations ? Or including codec informations or other things ? (like codec reseting) From paul at msn.com Thu Aug 28 15:05:53 2003 From: paul at msn.com (Pamel) Date: Thu, 28 Aug 2003 08:05:53 -0500 Subject: [Matroska-devel] Re: Add some new Tags? References: <001501c36c32$8917aa60$0200a8c0@jcsston> <3F4C60F5.4010002@free.fr> Message-ID: "Steve Lhomme" wrote > Well, tags usually set to be editable. All these extra informations are > different, because they are fixed. IMO it would be more logical to put > these info in the Track field. What about a Track offset? http://www.corecodec.com/modules.php?op=modload&name=PNphpBB2&file=viewtopic&p=1127#1127 From tronic2 at sci.fi Thu Aug 28 22:50:13 2003 From: tronic2 at sci.fi (=?ISO-8859-1?Q?Lasse_K=E4rkk=E4inen_/_Tronic?=) Date: Thu, 28 Aug 2003 20:50:13 +0000 Subject: [Matroska-devel] Add some new Tags? In-Reply-To: <3F4CF330.5040308@free.fr> References: <001501c36c32$8917aa60$0200a8c0@jcsston> <3F4CEF41.4050008@sci.fi> <3F4CF330.5040308@free.fr> Message-ID: <3F4E6B05.8030906@sci.fi> > He He. yes, good idea ! That would make the bitrate calculation > unbeatable. It's the size of the data with all extra informations ? Or > including codec informations or other things ? (like codec reseting) Block contents, header not included. Still not sure if lace information should be included or not. Probably not.. - Tronic - From steve.lhomme at free.fr Thu Aug 28 23:09:57 2003 From: steve.lhomme at free.fr (Steve Lhomme) Date: Thu, 28 Aug 2003 23:09:57 +0200 Subject: [Matroska-devel] Add some new Tags? In-Reply-To: <3F4E6B05.8030906@sci.fi> References: <001501c36c32$8917aa60$0200a8c0@jcsston> <3F4CEF41.4050008@sci.fi> <3F4CF330.5040308@free.fr> <3F4E6B05.8030906@sci.fi> Message-ID: <3F4E6FA5.9080908@free.fr> Lasse K?rkk?inen / Tronic wrote: >> He He. yes, good idea ! That would make the bitrate calculation >> unbeatable. It's the size of the data with all extra informations ? Or >> including codec informations or other things ? (like codec reseting) > > > Block contents, header not included. > > Still not sure if lace information should be included or not. Probably > not.. Should not. Especially since lacing seem to be more a problem than a solution. According to Mosu, it is not that efficient in the end. Because either you use TimeSlice (which tends to be big) or you use a basic Block. Not sure it applies to MCF, but you might face the same problem if data in a lace are not time stamped. From steve.lhomme at free.fr Fri Aug 29 11:31:58 2003 From: steve.lhomme at free.fr (Steve Lhomme) Date: Fri, 29 Aug 2003 11:31:58 +0200 Subject: [Matroska-devel] Fast Block parsing Message-ID: <3F4F1D8E.1060709@free.fr> Jory was asking me yesterday for a method to only read the header of a block, not the actual data. It already exists : /*! \brief Only read the head of the Block (not internal data) \note convenient when you are parsing the file quickly */ uint64 ReadInternalHead(IOCallback & input); The you do a SkipData and you're done :) From Liisachan at faireal.net Fri Aug 29 16:09:14 2003 From: Liisachan at faireal.net (Liisachan) Date: Fri, 29 Aug 2003 23:09:14 +0900 Subject: [Matroska-devel] Small problem in Matroska_Playback_Pack_0.5 Message-ID: <3F4F5E8A.6040008@faireal.net> This is not serious at all, but I happened to find this problem in the uninstaller for Playback Pack 0.5 Could not load: C:\Program Files\Matroska Playback Pack\subtitlesource ... Delete file: C:\Program Files\Matroska Playback Pack\subtitlesource.ax It will deldete SubtitleSource.ax without unregistering it first. I guess it says "Could not load" because the command line for it is missing ".ax" Liisachan