From chris at matroska.org Thu May 1 00:00:18 2003 From: chris at matroska.org (Christian HJ Wiesner) Date: Thu, 01 May 2003 00:00:18 +0200 Subject: [matroska-devel] Matroska open source A/V container format officially released Message-ID: <3EB04772.5040608@matroska.org> Hi, i have the big pleasure to officially announce that the matroska multimedia container project has finally left alpha status and turned into public beta status last night. By following the links below you will be able to obtain various tools to create, edit and play matroska audio and video files on your computers. Supported Operating Systems are currently Windows and Linux, but it seems at least playback is working for Mac OSX and OpenBeOS also. The beta release of these tools is the last and maybe most important of the three initial steps to make matroska a living reality in the opensource community. After almost 18 months of development, always in contact with developers from various other opensource projects in the multimedia environment, we were able to come up with a working specification for the container end of 2002. From this spec our chief developer and project administrator, Steve 'robux4' Lhomme, could code a working basic I/O library called 'libmatroska', which was released in alpha version to interested OSS developers beginning of this year. Since then all efforts were undertaken to make file creation and playback possible, and in the meantime the main library was steadily developed further to its actual status. The matroska container is mainly aiming to replace the good old AVI , but it is also ment to be a powerful and open alternative to other, mainly proprietary, containers such as ASF, MP4, MOV, RM, MPX annd even MPEG. It uses the extensions .mkv for video and .mka for audio only files . Here the main features of matroska : - opensource, open standard, GPL and QPL licensed main library - supports arbitrary file sizes, ideal for PCM audio and prepared for HDTV - allows arbitrary number of audio, video and subtitles streams in one file - attempting to support every existing audio and video codec under the sun - extensible by using EBML as underlying framework, a binary structure based on XML - enhanced container features such as menues, chapters, tags, file attachements - perfect sync thanks to timestamps for data blocks - x-platform design approach right from the start etc. Links : The release page ( constantly updated ) : !!!! http://www.matroska.org/announce.html !!!! matroska's homepage : http://www.matroska.org The project page : http://corecodec.org/projects/matroska CVS tree : https://corecodec.org/scm/?group_id=20 Here a listing of the tools that are released today : LINUX : All existing tools, as well for matroska file creation as well as for playback, were made by Moritz 'mosu' Bunkus, the author of the well known 'Ogmtools' . He was implementing playback support into mplayer for Linux, and the matroska support code was commited to mplayer CVS a few hours ago. His file creation tools, and this includes the sources, can be found here : http://www.bunkus.org/videotools/mkvtoolnix/ . The program, in its current status, will allow you to transmux every AVI, OGM or matroska file into a new matroska file, plus to add several external audio streams from either WAV or Ogg sources ( Vorbis ) as well as AC3 and MP3 audio, and SRT subtitles. Currently Supported codecs : Video : all VfW/VCM codecs ( DivX, XviD, etc. ) ; Audio : Vorbis, MP2, MP3, AC3, PCM ; Subtitles : SRT WINDOWS : File creation : The VirtualdubMod Team around Julien 'Cyrius' Coloos and Tobias 'Belgabor' Minnich have implemented matroska reading, editing and writing support in such a professional way that Windows users will not have to suffer from any major drawbacks compared to the well established AVI format. The program is released from its usual place on http://sf.net/projects/virtualdubmod . Supported codecs are all : VfW/VCM codecs ( DivX, XviD, WMV9 VCM, ON2VP3, HuffYuf, H.264, 3ivx, MPEG4V3/2, etc. ) ; Audio : all ACM codecs , Vorbis, MP2, MP3, AC3, PCM Playback, DirectShow parser : Our core developer Jan 'myFUN' Schlenker created the basis, and the great development team from 'The Core Media Player' , mainly Ludovic 'BlackSun' Vialle and Christophe 'Toff' Paris, were pushing it to the actual release status. Please note that there is currently work done on the implementation of seeking as well as subtitle support ( to follow soon ). Occasionally the player may freeze if the pause/stop button is pressed. The file can be downloaded here : http://matroska.sourceforge.net/downloads/kaxdemux-v0.3.0.zip ; unzip it into any directory and run regsvr32 x:\path\kaxdemux.dll from a command line . Playback : The Core Media Player Team have made a special release of their feature pumped DirectShow player, the TCMP RC4 'matroska release edition' , to be downloaded here : http://www.corecoded.com . Its coming with the latest parser filter and will install it automatically, plus it can easily be registered to playback matroska files. MPA2MKA and WAV2MKA : Both programs allow the user to transmux PCM or MP2/3 audio file into matroska audio files and were developed by John 'spyder' Cannon and Jory 'jcsston' Stone . Link : http://matroska.sourceforge.net/downloads/mpa2mka.zip and http://matroska.sourceforge.net/downloads/wav2mka.zip . Future Features/Codecs ( still to come ): - Menues - Chapters - MPEG 1/2 video support - special mode 2 form 2 burning with ECC/EDC - Image Subtitles ( BMP and PNG ) - Gstreamer plugin - Vegas video plugin - Xine playback patch - AAC audio support - Theora support - streaming server ( UDP and HTTP ) - file attachements ( lyrics, cover images, etc. ) - p2p plugins including file ID - Nero plugin - winamp plugin etc. We hope you will find the container useful and are looking forward to your feedback. Please adress all feedback either to the mailing list matroska-general at freelists dot org , join us on IRC.CORECODEC.COM #matroska or turn to the forum here : http://corecodec.com/modules.php?op=modload&name=phpBB2&file=index Thank you very much for your interest and my apologies to those who may feel bothered by the long email Christian Wiesner http://www.matroska.org From chris at matroska.org Thu May 1 00:00:18 2003 From: chris at matroska.org (Christian HJ Wiesner) Date: Thu, 01 May 2003 00:00:18 +0200 Subject: [matroska-devel] [transcode-users] Matroska open source A/V container format officially released Message-ID: <3EB04772.5040608@matroska.org> Hi, i have the big pleasure to officially announce that the matroska multimedia container project has finally left alpha status and turned into public beta status last night. By following the links below you will be able to obtain various tools to create, edit and play matroska audio and video files on your computers. Supported Operating Systems are currently Windows and Linux, but it seems at least playback is working for Mac OSX and OpenBeOS also. The beta release of these tools is the last and maybe most important of the three initial steps to make matroska a living reality in the opensource community. After almost 18 months of development, always in contact with developers from various other opensource projects in the multimedia environment, we were able to come up with a working specification for the container end of 2002. From this spec our chief developer and project administrator, Steve 'robux4' Lhomme, could code a working basic I/O library called 'libmatroska', which was released in alpha version to interested OSS developers beginning of this year. Since then all efforts were undertaken to make file creation and playback possible, and in the meantime the main library was steadily developed further to its actual status. The matroska container is mainly aiming to replace the good old AVI , but it is also ment to be a powerful and open alternative to other, mainly proprietary, containers such as ASF, MP4, MOV, RM, MPX annd even MPEG. It uses the extensions .mkv for video and .mka for audio only files . Here the main features of matroska : - opensource, open standard, GPL and QPL licensed main library - supports arbitrary file sizes, ideal for PCM audio and prepared for HDTV - allows arbitrary number of audio, video and subtitles streams in one file - attempting to support every existing audio and video codec under the sun - extensible by using EBML as underlying framework, a binary structure based on XML - enhanced container features such as menues, chapters, tags, file attachements - perfect sync thanks to timestamps for data blocks - x-platform design approach right from the start etc. Links : The release page ( constantly updated ) : !!!! http://www.matroska.org/announce.html !!!! matroska's homepage : http://www.matroska.org The project page : http://corecodec.org/projects/matroska CVS tree : https://corecodec.org/scm/?group_id=20 Here a listing of the tools that are released today : LINUX : All existing tools, as well for matroska file creation as well as for playback, were made by Moritz 'mosu' Bunkus, the author of the well known 'Ogmtools' . He was implementing playback support into mplayer for Linux, and the matroska support code was commited to mplayer CVS a few hours ago. His file creation tools, and this includes the sources, can be found here : http://www.bunkus.org/videotools/mkvtoolnix/ . The program, in its current status, will allow you to transmux every AVI, OGM or matroska file into a new matroska file, plus to add several external audio streams from either WAV or Ogg sources ( Vorbis ) as well as AC3 and MP3 audio, and SRT subtitles. Currently Supported codecs : Video : all VfW/VCM codecs ( DivX, XviD, etc. ) ; Audio : Vorbis, MP2, MP3, AC3, PCM ; Subtitles : SRT WINDOWS : File creation : The VirtualdubMod Team around Julien 'Cyrius' Coloos and Tobias 'Belgabor' Minnich have implemented matroska reading, editing and writing support in such a professional way that Windows users will not have to suffer from any major drawbacks compared to the well established AVI format. The program is released from its usual place on http://sf.net/projects/virtualdubmod . Supported codecs are all : VfW/VCM codecs ( DivX, XviD, WMV9 VCM, ON2VP3, HuffYuf, H.264, 3ivx, MPEG4V3/2, etc. ) ; Audio : all ACM codecs , Vorbis, MP2, MP3, AC3, PCM Playback, DirectShow parser : Our core developer Jan 'myFUN' Schlenker created the basis, and the great development team from 'The Core Media Player' , mainly Ludovic 'BlackSun' Vialle and Christophe 'Toff' Paris, were pushing it to the actual release status. Please note that there is currently work done on the implementation of seeking as well as subtitle support ( to follow soon ). Occasionally the player may freeze if the pause/stop button is pressed. The file can be downloaded here : http://matroska.sourceforge.net/downloads/kaxdemux-v0.3.0.zip ; unzip it into any directory and run regsvr32 x:\path\kaxdemux.dll from a command line . Playback : The Core Media Player Team have made a special release of their feature pumped DirectShow player, the TCMP RC4 'matroska release edition' , to be downloaded here : http://www.corecoded.com . Its coming with the latest parser filter and will install it automatically, plus it can easily be registered to playback matroska files. MPA2MKA and WAV2MKA : Both programs allow the user to transmux PCM or MP2/3 audio file into matroska audio files and were developed by John 'spyder' Cannon and Jory 'jcsston' Stone . Link : http://matroska.sourceforge.net/downloads/mpa2mka.zip and http://matroska.sourceforge.net/downloads/wav2mka.zip . Future Features/Codecs ( still to come ): - Menues - Chapters - MPEG 1/2 video support - special mode 2 form 2 burning with ECC/EDC - Image Subtitles ( BMP and PNG ) - Gstreamer plugin - Vegas video plugin - Xine playback patch - AAC audio support - Theora support - streaming server ( UDP and HTTP ) - file attachements ( lyrics, cover images, etc. ) - p2p plugins including file ID - Nero plugin - winamp plugin etc. We hope you will find the container useful and are looking forward to your feedback. Please adress all feedback either to the mailing list matroska-general at freelists dot org , join us on IRC.CORECODEC.COM #matroska or turn to the forum here : http://corecodec.com/modules.php?op=modload&name=phpBB2&file=index Thank you very much for your interest and my apologies to those who may feel bothered by the long email Christian Wiesner _______________________________________________ transcode-users mailing list transcode-users at theorie.physik.uni-goettingen.de http://www.theorie.physik.uni-goettingen.de/mailman/listinfo/transcode-users http://www.matroska.org From Paul at msn.com Thu May 1 07:37:18 2003 From: Paul at msn.com (Pamel) Date: Thu, 1 May 2003 00:37:18 -0500 Subject: [matroska-devel] AAF Tags. Message-ID: I hadn't compared to the tags defined in AAF prior to laying out the tags I did because, after several hours of searching, I couldn't find a document that defined them. Well, I just did. "Extensive" would be the best way to define them. Look here for the document in Excel format. (RP210v4-St13-020909A.xls) http://www.smpte-ra.org/mdd/ The relevant parts are columns AM and AN, or the Name and Description. AAF has 1209 Leafs (tags) in 437 Nodes (groups) for a total of 1646 total. And, they are not done defining them. However, there are many dupes there because they define many Leafs in two different formats, "ISO/IEC 646:1991 - ISO 7-Bit Coded Character Set" and "16 bit Unicode String". I bring this up because it has become apparent to me that the AAF standard is so closely tied in with the MPEG-7 standard. Also, the MXF container is a scaled down version of AAF and hence looks to be very compatible with MPEG-7. (AAF is more for authoring, and MXF is more for distribution.) This brings to mind the question of whether or not we should look at altering the tag design of Matroska to be more compliant with this tag set. I have no desire to attempt to implement full support of this tag set as I would die a crazed death from information overload long before Steve could hunt me down. But it may be wise to expand and alter the structure we do have slightly to accomodate this. I am completely at a loss of what to do about this. Pamel P.S. Some stuff seems screwy, like the UMID which give 32 bytes for a 12 byte value. http://www.matroska.org From rududuvideocodec at ifrance.com Thu May 1 23:53:00 2003 From: rududuvideocodec at ifrance.com (nicolas) Date: Thu, 01 May 2003 23:53:00 +0200 Subject: [matroska-devel] congratulations ! Message-ID: <3EB1973C.2040603@ifrance.com> hello all, Just tested Matroska with vdubmod and the dshow filter, congratulations for all the work. I tested it with the new version of my codec (just released today too) and all works fine with vdubmod (read and write) but I have a little problem with the dshow filter : My dshow filter use IMediaSample::IsSyncPoint() to know if the frame is a key frame or not and this flag seems not to be set by kaxdemux so the first frame is decoded as a delta frame and it crash. I wonder if this is normal or not (I suppose not ...). Anyway very good job ! Nicolas PS: for those who want to try, my codec is downloadable from : http://www.ifrance.com/rududu/Rududu3.ace _____________________________________________________________________ Envie de discuter en "live" avec vos amis ? T?l?charger MSN Messenger http://www.ifrance.com/_reloc/m la 1?re messagerie instantan?e de France http://www.matroska.org From chris at matroska.org Fri May 2 04:06:01 2003 From: chris at matroska.org (Christian HJ Wiesner) Date: Fri, 02 May 2003 04:06:01 +0200 Subject: [matroska-devel] Re: congratulations ! In-Reply-To: <3EB1973C.2040603@ifrance.com> References: <3EB1973C.2040603@ifrance.com> Message-ID: <3EB1D289.5070707@matroska.org> Hi Nicolas, good to hear from you. Just recently there was a thread on Doom9 about your wavelet codec and if there is any work being done on it or not. nicolas wrote: >hello all, > >Just tested Matroska with vdubmod and the dshow filter, congratulations >for all the work. > > Thanks, from the mouth of a successful developer thats even nicer than from the users i admit :) >I tested it with the new version of my codec (just released today too) >and all works fine with vdubmod (read and write) but I have a little >problem with the dshow filter : > >My dshow filter use IMediaSample::IsSyncPoint() to know if the frame is >a key frame or not and this flag seems not to be set by kaxdemux so the >first frame is decoded as a delta frame and it crash. I wonder if this >is normal or not (I suppose not ...). >Anyway very good job ! >Nicolas > > I forward this answer to Toff, Blacksun and myFUN and hope one of them will answer your question. >PS: for those who want to try, my codec is downloadable from : >http://www.ifrance.com/rududu/Rududu3.ace > > Will do for sure .. thanks, hope to see you in the IRC channel soon. Best regards Christian http://www.matroska.org From chris at matroska.org Tue May 6 12:16:18 2003 From: chris at matroska.org (Christian HJ Wiesner) Date: Tue, 06 May 2003 12:16:18 +0200 Subject: [matroska-devel] Re: congratulations ! In-Reply-To: <3EB1973C.2040603@ifrance.com> References: <3EB1973C.2040603@ifrance.com> Message-ID: <3EB78B72.5090703@matroska.org> nicolas wrote: >My dshow filter use IMediaSample::IsSyncPoint() to know if the frame is >a key frame or not and this flag seems not to be set by kaxdemux so the >first frame is decoded as a delta frame and it crash. I wonder if this >is normal or not (I suppose not ...). >Anyway very good job ! Nicolas > Nicolas, good news ! Hopefully tonight we will be able to play Rududu from matroska, robux4 is almost finished implementing the frame reference reporting into the new, rewritten DirectShow filter :D !! To clarify : the flags are already set correctly from both VirtualdubMod and mkvmerger ( Linux ), but the last Dshow filter did not report them on the output pin. For MPEG4 codecs like XviD and DivX they were not necessary either, as they have their own frame referencing system in the MPEG4 elementary streams ( ES ). BTW : I still would like to repeat my offer about the reworking of your Rududu framing system : Spyder already did look at making Elementary streams, that time from MCF, and i am sure he would gladly help you if you could decide to build your framing on matroska. If we strip everything you dont need for your video ES stream, you will have a great framing based on matroska including EDC and ECC, and be able to use parts of libebml and libmatroska for your own code. Please rethink this once you find the time. I am convinced its actually much easier to make this way, instead of reinventing the wheel completely. Regards Christian http://www.matroska.org From rududuvideocodec at ifrance.com Tue May 6 22:02:49 2003 From: rududuvideocodec at ifrance.com (nicolas) Date: Tue, 06 May 2003 22:02:49 +0200 Subject: [matroska-devel] Re: congratulations ! In-Reply-To: <3EB78B72.5090703@matroska.org> References: <3EB1973C.2040603@ifrance.com> <3EB78B72.5090703@matroska.org> Message-ID: <3EB814E9.2080207@ifrance.com> Christian HJ Wiesner wrote: >Nicolas, good news ! > >Hopefully tonight we will be able to play Rududu from matroska, robux4 >is almost finished implementing the frame reference reporting into the >new, rewritten DirectShow filter :D !! To clarify : the flags are >already set correctly from both VirtualdubMod and mkvmerger ( Linux ), >but the last Dshow filter did not report them on the output pin. For >MPEG4 codecs like XviD and DivX they were not necessary either, as they >have their own frame referencing system in the MPEG4 elementary streams >( ES ). > I supposed it was the direct show filter as I was able to play the file in vdubmod. One bug less ... >BTW : I still would like to repeat my offer about the reworking of your >Rududu framing system : Spyder already did look at making Elementary >streams, that time from MCF, and i am sure he would gladly help you if >you could decide to build your framing on matroska. If we strip >everything you dont need for your video ES stream, you will have a great >framing based on matroska including EDC and ECC, and be able to use >parts of libebml and libmatroska for your own code. Please rethink this >once you find the time. I am convinced its actually much easier to make >this way, instead of reinventing the wheel completely. > The rududu stream is very simple : a short header and everything else output from an arithmetic coder (range coder). In fact I would like to use ECC (error correcting codes) because it's more simple : I don't have to care about what data is important, everything is protected. But it's not a good solution : the user can't select the ECC rate and you don't know the error rate. A solution could be the use of resync codes as in MPEG, but it cost a lot and I think in this case ECC could be better. That why I need to develop a codec specific solution. When something goes wrong in the stream, the decoder enters in an infinite loop, so I need to detect that the decoder is blocked without a too much important CPU load cost. But this don't add error resilience to the coder : if a frame is bad, I need to wait for the next key frame. As you can see, I hope I will not need ECC in rududu and I can do error detection without any code, so the main developpement to do is in the error resilience and this is a very codec specific part, but I have not already gived a look at this issue. So I think the ECC feature in Matroska could be a very user friendly thing, but my codec needs a more specific error resilience without an imposed ECC (and without bit rate increase !). Nicolas http://www.matroska.org From chris at matroska.org Fri May 2 12:53:45 2003 From: chris at matroska.org (Christian HJ Wiesner) Date: Fri, 02 May 2003 12:53:45 +0200 Subject: [matroska-devel] matroska support in Gordian Knot soon, via VirtualdubMod 1.5.1.1a ?? Message-ID: <3EB24E39.3070802@matroska.org> Hi, i recommend you all are reading here : http://forum.doom9.org/showthread.php?s=&threadid=52345 @spyder : John, you are the man to come up with a precise overhead calculation function for them !!! ask Cyrius about the lacing function he is using in VdubMod, it will be important i guess. Regards Christian http://www.matroska.org From steve.lhomme at free.fr Fri May 2 16:02:06 2003 From: steve.lhomme at free.fr (Steve Lhomme) Date: Fri, 02 May 2003 16:02:06 +0200 Subject: [matroska-devel] mpa2mka problems Message-ID: <3EB27A5E.3090404@free.fr> Hello, I was wondering why the timecode was not moving in DirectShow when audio-only files were used... I have found the reason : mpa2mka doesn't save any timecode information !!! This is not spec compliant... So I strongly encourage spyder or jcsston to modify this. The timecode calculation is easy, you need a global timecode, the number of samples in an MPEG frame and the sampling frequency. To see how to set the timecode properly in the file, have a look at test6. You need to set it in AddFrame and also SetPreviousTimecode (of a Cluster). On another subject, the Tags element should be saved at the end of the file (for easier editing). And you should also save a SeekHeader at the beggining of the file with (at least) the location of this Tags element (and maybe of the Clusters too). Again, there is an example in test6. And another thing, it would be a good thing if you could set a KaxBlockDuration for the last Block in the file. PS: The same may apply to wav2mka too. In this case the timecode might be estimated with the average bitrate attribute... (only accurate for strict CBR formats) http://www.matroska.org From jcsston at ToughGuy.net Fri May 2 20:20:06 2003 From: jcsston at ToughGuy.net (Jory) Date: Fri, 2 May 2003 13:20:06 -0500 Subject: [matroska-devel] Re: mpa2mka problems References: <3EB27A5E.3090404@free.fr> Message-ID: <000001c310d8$5c59b870$1300a8c0@jcsston> ----- Original Message ----- From: "Steve Lhomme" To: Sent: Friday, May 02, 2003 9:02 AM Subject: [matroska-devel] mpa2mka problems > > Hello, > > I was wondering why the timecode was not moving in DirectShow when > audio-only files were used... I have found the reason : mpa2mka doesn't > save any timecode information !!! This is not spec compliant... > > So I strongly encourage spyder or jcsston to modify this. The timecode > calculation is easy, you need a global timecode, the number of samples > in an MPEG frame and the sampling frequency. To see how to set the > timecode properly in the file, have a look at test6. You need to set it > in AddFrame and also SetPreviousTimecode (of a Cluster). This is already done in mpa2mka and wav2mka. I do not understand why the timecodes are not being reported correctly. > > On another subject, the Tags element should be saved at the end of the > file (for easier editing). And you should also save a SeekHeader at the > beggining of the file with (at least) the location of this Tags element > (and maybe of the Clusters too). Again, there is an example in test6. Ok, I moved the Tags element to the end and placed SeekHead at the beginning with the location of the Tracks elment, the first cluster, and the Tags element. I am having trouble with writing and reading back Tags. I added reading of the tags to mkvinfo and it fails after reading the Multi-Entiy element. I uploaded the mkvinfo win32 binary and source file I changed, along with a small mka test file http://webjory.tripod.com/matroska/tag_test.htm Steve could you please look at the KaxTag*.cpp&.h files and check if I defined the Multi elments correctly? I used other parts of the lib as an example so I hope I got it right. > > And another thing, it would be a good thing if you could set a > KaxBlockDuration for the last Block in the file. I'll look at the sources of the other tools, (mkvmerge, VirtualDubMOD) and see if I can add that. > > PS: The same may apply to wav2mka too. In this case the timecode might > be estimated with the average bitrate attribute... (only accurate for > strict CBR formats) Yes all of this would/does apply to wav2mka too, as wav2mka is basicly mka2mpa merged with the old kaswav sources. > > http://www.matroska.org http://www.matroska.org From spyder482 at yahoo.com Fri May 2 23:08:21 2003 From: spyder482 at yahoo.com (John Cannon) Date: Fri, 2 May 2003 16:08:21 -0500 Subject: [matroska-devel] Re: mpa2mka problems References: <3EB27A5E.3090404@free.fr> <000001c310d8$5c59b870$1300a8c0@jcsston> Message-ID: I think the problem (actually Cyrius pointed it out) is that you don't give the library the timecode in nanoseconds. The original code scaled the timecodes before giving them to the library. So you need to modify the timecode calculations. maybe this will work ;) Spyder http://www.matroska.org From spyder482 at yahoo.com Sat May 3 07:19:52 2003 From: spyder482 at yahoo.com (John Cannon) Date: Sat, 3 May 2003 00:19:52 -0500 Subject: [matroska-devel] Matroska CDL Message-ID: Hey, I added some code to the skeleton CDL Toff and BlackSun helped me make today and I now have it loading only when a matroska file is played :) Jory is helping me write some code for reading the tags out of the files and track info etc. Hopefully in a few days we'll have a working plugin. He pu the code in CVS since I seem to not even be a member of this project anymore on corecodec.org. PLEASE FIX THAT! John http://www.matroska.org From moritz at bunkus.org Sat May 3 21:17:44 2003 From: moritz at bunkus.org (Moritz Bunkus) Date: Sat, 3 May 2003 21:17:44 +0200 Subject: [matroska-devel] ownership of DataBuffer objects Message-ID: <20030503191744.GN2266@bunkus.org> An embedded and charset-unspecified text was scrubbed... Name: not available URL: From moritz at bunkus.org Sat May 3 21:57:41 2003 From: moritz at bunkus.org (Moritz Bunkus) Date: Sat, 3 May 2003 21:57:41 +0200 Subject: [matroska-devel] Re: ownership of DataBuffer objects In-Reply-To: <20030503191744.GN2266@bunkus.org> References: <20030503191744.GN2266@bunkus.org> Message-ID: <20030503195741.GO2266@bunkus.org> Hi. > DataBuffer *data = new DataBuffer(mycontents, mylength); > kax_cluster->AddFrame(track_entry, timecode, *data, new_group); Just to clarify this. The frame's contents are NOT owned by the library! Only the DataBuffer structure. Depending on the DataBuffer class you use (DataBuffer, SimpleDataBuffer, NotSoSimpleDataBuffer) the class will or will not make a copy of the data you provide. The 'mycontents' still belongs to your program and must be freed after you've rendered the cluster (for DataBuffer) or after you've called AddFrame (for NotSoSimpleDataBuffer which makes a copy of the contents). -- ==> Ciao, Mosu (Moritz Bunkus) http://www.matroska.org From christophe.paris at free.fr Mon May 5 02:08:11 2003 From: christophe.paris at free.fr (Christophe PARIS) Date: Mon, 05 May 2003 02:08:11 +0200 Subject: [matroska-devel] DSF Queue Message-ID: hi, I looked quickly at the new code and i have a little question for Steve before going to sleep :) What's the use of the min threshold in MkxQueue ? I also noticed that the queue will do more "Unlock" than "Lock" and that will probably cause problem. (see the XXX below) void MkxQueue::PushBlockBack(KaxBlock * aBlock) { Lock(); // Block the resource // check the threshold while (Blocks.size() > MaxThreshold) { // block this queue until it reaches MinThreshold Unlock(); // <------- XXX WaitForSingleObject(WriteLock, INFINITE); } Blocks.push_back(aBlock); SetEvent(ReadLock); Unlock(); } this can be easily corrected thought: void MkxQueue::PushBlockBack(KaxBlock * aBlock) { bool ThresholdReached; Lock(); ThresholdReached = Blocks.size() > MaxThreshold; Unlock(); // check the threshold while (ThresholdReached ) { // block this queue until it reaches MinThreshold WaitForSingleObject(WriteLock, INFINITE); Lock(); ThresholdReached = Blocks.size() > MaxThreshold; Unlock(); } Lock(); Blocks.push_back(aBlock); Unlock(); SetEvent(ReadLock); } (i commit that soon) Well, enough for now. We will see that tomorrow. Regards, Toff http://www.matroska.org From christophe.paris at free.fr Mon May 5 03:21:21 2003 From: christophe.paris at free.fr (Christophe PARIS) Date: Mon, 05 May 2003 03:21:21 +0200 Subject: [matroska-devel] Re: DSF Queue In-Reply-To: References: Message-ID: Hmm, i'm not sleeping yet! Now i see what the min threshold is used for, so we can get the next block and calculate duration. But we get the block (signal the read event) and don't remove it form the queue, i think it's what's causing the deadlock. I commit the queue change but it doesn't work. Regards, Toff http://www.matroska.org From steve.lhomme at free.fr Mon May 5 08:51:14 2003 From: steve.lhomme at free.fr (Steve Lhomme) Date: Mon, 05 May 2003 08:51:14 +0200 Subject: [matroska-devel] Re: DSF Queue In-Reply-To: References: Message-ID: <3EB609E2.20105@free.fr> Christophe PARIS wrote: > Hmm, i'm not sleeping yet! > > Now i see what the min threshold is used for, so we can get the next > block and calculate duration. Not only that, but with the Max threshold, it creates an histeresys for trigerring reading/writing locking. This is a good way to avoid locking/unlocking all the time, and therefore get a flawless playback. > But we get the block (signal the read event) and don't remove it form > the queue, i think it's what's causing the deadlock. > > I commit the queue change but it doesn't work. If you feel like having a look, I don't think the fixes are really big. A boolean (or checking the event) that says the other part (read when writing, write when reading) is locked, could help only unlock it once it's "time". I tried removing the Max threshold yesterday and was able to send all frames (minus the ones remaining in the queue at the end, for which we have to use a special case). I could only see the first and last frame, but I think we are on a good way :) http://www.matroska.org From steve.lhomme at free.fr Mon May 5 10:53:23 2003 From: steve.lhomme at free.fr (Steve Lhomme) Date: Mon, 05 May 2003 10:53:23 +0200 (CEST) Subject: [matroska-devel] Re: DSF Queue In-Reply-To: <3EB609E2.20105@free.fr> References: <3EB609E2.20105@free.fr> Message-ID: <1052124803.3eb62683b2961@imp.free.fr> > Christophe PARIS wrote: Could you try these (I haven't compiled or tested it) : MkxQueue::MkxQueue(unsigned int aMaxThreshold, unsigned int aMinThreshold) :MinThreshold(aMinThreshold) ,MaxThreshold(aMaxThreshold) ,Flushing(false) { WriteLock = CreateEvent(NULL, // security FALSE, // auto-reset FALSE, // set by default NULL); ReadLock = CreateEvent(NULL, // security FALSE, // auto-reset FALSE, // set by default NULL); } KaxBlock * MkxQueue::GetBlockFront() { KaxBlock *result; Lock(); // Lock the resource (to prevent other threads to access it) if (!Flushing) { // We should block ourself if the MinThreshold is not reached while (Blocks.size() < MinThreshold) { Unlock(); // possible deadlock here if PopFrontBlock is called WaitForSingleObject(ReadLock, INFINITE); ResetEvent(ReadLock); Lock(); } } if (Blocks.size()) { result = Blocks.front(); } else { result = NULL; } // deblock writing if ((Blocks.size() > MaxThreshold) && (WaitForSingleObject(WriteLock, 0) != WAIT_OBJECT_0)) { SetEvent(WriteLock); } Unlock(); return result; } I'm going to write one for PushBlockBack too. http://www.matroska.org From chris at matroska.org Tue May 6 11:01:20 2003 From: chris at matroska.org (Christian HJ Wiesner) Date: Tue, 06 May 2003 11:01:20 +0200 Subject: [matroska-devel] Non 1:1 Aspect ratios in matroska video streams : soon possible ?? Message-ID: <3EB779E0.7050608@matroska.org> Hi, while robux4 and Toff are working like crazy on the new DirectShow filter, being the highest priority right now, it seems that spyder and Blacksun made very good progress on the TCMP CDL plugin for matroska. This plugin will be a direct link between matroska files and TCMP, on top of DirectShow so to say, meaning that TCMP can read data and tags from the matroska file directly, without depending from DirectShow here. While there are a couple of different purposes in doing so, like reading all the several hundred tags that matroska will support once they are implemented ( a big thanks to poor, hard working Pamel in this respect :) ) there is one big advantage that will be a kick ass feature IMHO and that will push using of TCMP in combination with matroska : As you all know matroska supports an Aspect Ratio flag in the track header so that every video stream in it can have different DAR ( Display Aspect Ratios ) or PAR ( Pixel Aspect Ratio ). While this is relatively easy to implement from the matroska file creation side ( simply set the flag accordingly ), its not so easy for playback, especially if you talk about DirectShow based playback on Windows. The AR has to be known to the graph calling application ( the DShow player ) *before* calling the graph, thats why DirectShow is also failing to work with the embedded AR flags in the MPEG4 codec header of XviD ( it works fine on Linux in mencoder/mplayer ). DirectShow has means of setting different output Aspect Ratios player independant, some DiretctShow MPEG parsers that support this are a very good example here as they will display a PAL SVCD ( 480 * 576 for a 4:3 AR ) correctly even if being played by simple Windows Mediaplayer 6.4. . The AR flag in the MPEG header is read when building the graph and the parser itself will force the output AR to be correct, irrespective whether the player does support this or not. Unfortunately this is very limited as DShow will support only a few ARs natively ( like 16:9 anamorphic ), so we can not use this mechanism to implement support for matroska ARs in it, as we allow the AR to be any possible floating point number in a very wide range. As a result of what is said above it would need a resizing filter to be implemented into the matroska parser filter to be able to use the full AR flags from DirectShow without having a specific player supporting it. Now, after this long explanation above you may think, ' ...wow, we are lightyears away from a working AR implementation ...' , and guess what, you are completely wrong ! The TCMP CDL plugin that is in the works by spyder and Blacksunright now will make this possible in almost no time, simply because TCMP will be able to read the AR flag directly from the file *before* calling the filter graph, so everything would work perfectly as TCMP is using a so called 'semi-automatic' graph building function, and in this case its the player determining the output AR and not the parser filter. So, what do we need to get this important feature working ? First of all, its independant of the current status of the DShow parser. Whatever we have as filter, it will work with it. Second, we need a way to set the AR flag in the files from the muxing tools, means in VdubMod and Mkvmerger. @Cyrius : i know you could fix a few bugs of the current VdubMod in CVS, when are you planning a new release ? Any chance to make a small AR flag field somewhere in the GUI, so the user can set this flag using two integer numbers ( we have to calculate the float then ) ? @mosu : as mplayer and mencoder already support reading of the AR flag from MPEG4 codec header ( XviD, FFmpeg ), was it hard to implement in both mkvmerger and mplayer ? Thanks for a reply on that Christian http://www.matroska.org From spyder482 at yahoo.com Tue May 6 19:34:03 2003 From: spyder482 at yahoo.com (John Cannon) Date: Tue, 6 May 2003 12:34:03 -0500 Subject: [matroska-devel] Re: Non 1:1 Aspect ratios in matroska video streams : soon possible ?? References: <3EB779E0.7050608@matroska.org> Message-ID: "Christian HJ Wiesner" wrote in message news:3EB779E0.7050608 at matroska.org... > > Hi, > > while robux4 and Toff are working like crazy on the new DirectShow > filter, being the highest priority right now, it seems that spyder and > Blacksun made very good progress on the TCMP CDL plugin for matroska. No mention of jcsston's work??? He has come a long way with the tag reading support. I haven't really played with the CDL much in the past day or so now. I won't be contributing much for the next few days until school is over. Chris, I know you just forgot or didn't understand but please give Jory some credit here. He has worked pretty hard to get the tag system working. He also helped Pamel with the tag list AFAIK. John http://www.matroska.org From chris at matroska.org Wed May 7 05:41:09 2003 From: chris at matroska.org (Christian HJ Wiesner) Date: Wed, 07 May 2003 05:41:09 +0200 Subject: [matroska-devel] Re: Non 1:1 Aspect ratios in matroska video streams : soon possible ?? In-Reply-To: References: <3EB779E0.7050608@matroska.org> Message-ID: <3EB88055.2030507@matroska.org> John Cannon wrote: >No mention of jcsston's work??? He has come a long way with the tag reading >support. I haven't really played with the CDL much in the past day or so >now. I won't be contributing much for the next few days until school is >over. Chris, I know you just forgot or didn't understand but please give >Jory some credit here. He has worked pretty hard to get the tag system >working. He also helped Pamel with the tag list AFAIK. > You guys are confusing me totally :) ... first you start with MPA2MKA, then Jory finishes the work and makes WAV2MKA. Then you go making the CDL, and again its Jory to finish it ... who is supposed to keep an overview here :D ? Christian http://www.matroska.org From chris at matroska.org Thu May 8 21:31:56 2003 From: chris at matroska.org (Christian HJ Wiesner) Date: Thu, 08 May 2003 21:31:56 +0200 Subject: [matroska-devel] AAC DirectShow filter Message-ID: <3EBAB0AC.5040201@matroska.org> http://www.hydrogenaudio.org/index.php?s=7bf0e86effa1b0717a215f8794f87d95&act=ST&f=13&t=9180&st=0&#entry91798 http://www.matroska.org From christophe.paris at free.fr Fri May 9 01:26:40 2003 From: christophe.paris at free.fr (Christophe PARIS) Date: Fri, 09 May 2003 01:26:40 +0200 Subject: [matroska-devel] MKVToolnix win32 build Message-ID: Hi Ladies & Gentlemen, Today I've worked on the win32 port. http://christophe.paris.free.fr/temp/matroska/mkvtoolnix_win32_bin.rar http://christophe.paris.free.fr/temp/matroska/mkvtoolnix_win32_src.rar This is not extensively tested so use at your own risk ;) And don't bug Mosu for bugs that could have been created by VC6 (or me). Best regards Toff http://www.matroska.org From moritz at bunkus.org Fri May 9 07:21:23 2003 From: moritz at bunkus.org (Moritz Bunkus) Date: Fri, 9 May 2003 07:21:23 +0200 Subject: [matroska-devel] Re: MKVToolnix win32 build In-Reply-To: References: Message-ID: <20030509052123.GC24454@bunkus.org> Hi. > Today I've worked on the win32 port. Good work. Yesterday I also succeeded in building mkvtoolnix with cygwin and very little changes to the source code. I'll officially release win32 binaries from now on. -- ==> Ciao, Mosu (Moritz Bunkus) http://www.matroska.org From moritz at bunkus.org Fri May 9 17:30:56 2003 From: moritz at bunkus.org (Moritz Bunkus) Date: Fri, 9 May 2003 17:30:56 +0200 Subject: [matroska-devel] Re: MKVToolnix win32 build In-Reply-To: <20030509052123.GC24454@bunkus.org> References: <20030509052123.GC24454@bunkus.org> Message-ID: <20030509153055.GG24454@bunkus.org> Hi. Ok here we go. My binaries will always be available from http://www.bunkus.org/videotools/mkvtoolnix/index.html#dlinst_win32 and include documentation (the man pages in HTML format). -- ==> Ciao, Mosu (Moritz Bunkus) http://www.matroska.org From Liisachan at faireal.net Sat May 10 01:07:23 2003 From: Liisachan at faireal.net (Liisachan) Date: Sat, 10 May 2003 08:07:23 +0900 Subject: [matroska-devel] Re: MKVToolnix win32 build In-Reply-To: <20030509153055.GG24454@bunkus.org> References: <20030509052123.GC24454@bunkus.org> <20030509153055.GG24454@bunkus.org> Message-ID: <3EBC34AB.5080009@faireal.net> Moritz Bunkus wrote: >Hi. > >Ok here we go. My binaries will always be available from >http://www.bunkus.org/videotools/mkvtoolnix/index.html#dlinst_win32 and >include documentation (the man pages in HTML format). > > > Thank you for cool tools :D Both work fine on Win2k (ja) Especially I like -cues options in mkvmerge, which allows more Cues control than you can with VdubMod. Some samples that might be interesting: [ AVI (XviD + MP3 CBR) 124,734 KB ] --- Transmux into MKV --- (1) Using Vdubmod .... Result 124,221 KB (2) Mkvmerger default cues ....123,944 KB ( --cues iframes for V, --cues none for A) (3) Mkvmerger no cues ... 123.936 KB I suppose Vdubmod will put more cues than Mkvmerger default, probably not only on I-Frames of the video. All results play fine so far. Liisachan http://www.matroska.org From moritz at bunkus.org Sat May 10 10:25:32 2003 From: moritz at bunkus.org (Moritz Bunkus) Date: Sat, 10 May 2003 10:25:32 +0200 Subject: [matroska-devel] Re: MKVToolnix win32 build In-Reply-To: <3EBC34AB.5080009@faireal.net> References: <20030509153055.GG24454@bunkus.org> <3EBC34AB.5080009@faireal.net> Message-ID: <20030510082532.GH24454@bunkus.org> Hi. Thanks for the testing, Liisachan. I had only made a few tests here myself in order to see whether the files created by the Windows version are the same, and they were. But it's always comforting to have some confirmation :) > I suppose Vdubmod will put more cues than Mkvmerger default, probably > not only on I-Frames of the video. (technical explanation following) Yes, but if we both use the same amount of cues VDubMod's files will be smaller than mine. This is because I split the MP3 track into single MP3 frames which I put into a Matroska block, but VDubMod puts as much data into one Matroska block as it reads for one AVI chunk. This is usually 1.5 - 2 times as much as a single MP3 frame, so VDubMod creates fewer blocks and therefore fewer cue entries and smaller files. The 'right' way to do it for native Matroska streams (those with a CodecID of A_MPEG/L3) is my way, so VDubMod uses the MS compatibility mode for MP3 streams at the moment. > All results play fine so far. That is what is most important for me :) -- ==> Ciao, Mosu (Moritz Bunkus) http://www.matroska.org From chris at matroska.org Sat May 10 15:34:40 2003 From: chris at matroska.org (Christian HJ Wiesner) Date: Sat, 10 May 2003 15:34:40 +0200 Subject: [matroska-devel] Re: MKVToolnix win32 build In-Reply-To: <20030510082532.GH24454@bunkus.org> References: <20030509153055.GG24454@bunkus.org> <3EBC34AB.5080009@faireal.net> <20030510082532.GH24454@bunkus.org> Message-ID: <3EBCFFF0.2040300@matroska.org> Moritz Bunkus wrote: >>All results play fine so far. >> >> > >That is what is most important for me :) > Does the win32 version also support setting AR flag ? Can i transmux an MKV created by VdubMod ? Christian http://www.matroska.org From moritz at bunkus.org Sat May 10 15:43:24 2003 From: moritz at bunkus.org (Moritz Bunkus) Date: Sat, 10 May 2003 15:43:24 +0200 Subject: [matroska-devel] Re: MKVToolnix win32 build In-Reply-To: <3EBCFFF0.2040300@matroska.org> References: <20030509153055.GG24454@bunkus.org> <3EBC34AB.5080009@faireal.net> <20030510082532.GH24454@bunkus.org> <3EBCFFF0.2040300@matroska.org> Message-ID: <20030510134324.GA15464@bunkus.org> Hi. > Does the win32 version also support setting AR flag ? Can i transmux an > MKV created by VdubMod ? The win32 and the Linux version are the same. At the moment the win32 is newer than the Linux version (I'm talking about the 'released' versions, not the CVS version), but yes, --aspect-ratio is supported. Reading Matroska files with A_MS/ACM won't work, I'm afraid, I simply have not yet found the time to implement it. -- ==> Ciao, Mosu (Moritz Bunkus) http://www.matroska.org From Liisachan at faireal.net Sun May 11 23:49:41 2003 From: Liisachan at faireal.net (Liisachan) Date: Mon, 12 May 2003 06:49:41 +0900 Subject: [matroska-devel] Re: MKVToolnix - --sub-charset will support all encodings? In-Reply-To: <20030510082532.GH24454@bunkus.org> References: <20030509153055.GG24454@bunkus.org> <3EBC34AB.5080009@faireal.net> <20030510082532.GH24454@bunkus.org> Message-ID: <3EBEC575.1040304@faireal.net> Hi, Moritz: >Hi. > >Thanks for the testing, Liisachan. I had only made a few tests here >myself in order to see whether the files created by the Windows version >are the same, and they were. But it's always comforting to have some >confirmation :) > > I have another question: I cannot use subs in MKV on Windows atm, but i noticed your note on this param: --no-utf8-subs * wiht this option, the muxer wont do any char encoding conv for subs, and will mark it as S_TEXT/ASCII * without this, subs will be converted into UTF-8 I may be wrong, but I think I dont like this spec so much. How can I handle my subs if it is already in UTF-8? umm.. "--sub-charset UTF-8" ? Yours may work fine if you are handling only ASCII (the Code page for Western Europe and US) and UTF-8, But "---sub-charset" is a pest. Japanese users may try to use this switch variously --sub-charset JIS --sub-charset SJIS --sub-charset EUC-JP Russian users too may "abuse" this swetch: --sub-charset "Windows 1252" --sub-charset ISO-8859-5 --sub-charset KOI8-R --sub-charset KOI8-U etc. So will the Chinese users, Korean users etc. etc. ...Are you really going to implement every possible conversions? It will be much easier to internationalize the muxer by just accepting UTF-8 subs as default, than trying to convert EVERY possible char encoding into UTF-8 by itself. All subbers can convert their subs into UTF-8 _before_ muxing, they should know how. "If not specified the charset will be derived from the current locale settings." <-- this default is fine and how about these? --sub-utf8 Subtext is treated as already in UTF-8 and will be muxed as S_TEXT/UTF8 --sub-ascii Subtext is treated as already in ASCII and will be muxed as S_TEXT/ASCII (default) == as it is today Subtext is treated as written in System default Code Page, and will be converted into UTF8 to make S_TEXT/UTF8 --sub-charset FOO * possible FOO should be specified * more or less common ones include:. ISO-8859-1 (Western europe) Windows 1252 (Western europe for Windows) ISO-8859-2 (central europe) Windows 1250 (central europe for win) ISO-8859-5 (russian) Windows 1251 (russian for win) ISO-8859-7 (greek) Windows 1253 (greek for win) ISO-8859-9 (Truekey) Windows 1254 (turkey for win) EUC-KR (korean) EUC-JP (japanese for linux) SHIFT_JIS (japanese for windows/mac) GB2312 (simplified chinese) Big-5 (traditional chinese) Windows 1255 (hebrew) Windows 874 (Thai) Windows 1258 (vetnamese) Windows 1256 (Arabic) >>I suppose Vdubmod will put more cues than Mkvmerger default, probably >>not only on I-Frames of the video. >> >> > >(technical explanation following) > >Yes, but if we both use the same amount of cues VDubMod's files will be >smaller than mine. This is because I split the MP3 track into single MP3 >frames which I put into a Matroska block, but VDubMod puts as much data >into one Matroska block as it reads for one AVI chunk. This is usually >1.5 - 2 times as much as a single MP3 frame, so VDubMod creates fewer >blocks and therefore fewer cue entries and smaller files. > >The 'right' way to do it for native Matroska streams (those with a >CodecID of A_MPEG/L3) is my way, so VDubMod uses the MS compatibility >mode for MP3 streams at the moment. > > I see. Thank you for explanation. > > >>All results play fine so far. >> >> > >That is what is most important for me :) > > > I want to test how seeking ability will change depending on inserted Cues types, on Windows, when DSF is ready to seek properly :) Liisachan http://www.matroska.org From moritz at bunkus.org Mon May 12 00:00:29 2003 From: moritz at bunkus.org (Moritz Bunkus) Date: Mon, 12 May 2003 00:00:29 +0200 Subject: [matroska-devel] Re: MKVToolnix - --sub-charset will support all encodings? In-Reply-To: <3EBEC575.1040304@faireal.net> References: <20030509153055.GG24454@bunkus.org> <3EBC34AB.5080009@faireal.net> <20030510082532.GH24454@bunkus.org> <3EBEC575.1040304@faireal.net> Message-ID: <20030511220029.GH15464@bunkus.org> Hi. > --no-utf8-subs > > * wiht this option, the muxer wont do any char encoding conv for subs, > and will mark it as S_TEXT/ASCII > * without this, subs will be converted into UTF-8 > > I may be wrong, but I think I dont like this spec so much. :) At the moment there are two subtitle types, S_TEXT/UTF8 and S_TEXT/ASCII. With --no-utf8-subs mkvmerge simply assumes that the subtitles are ASCII and will use S_TEXT/ASCII. Without the switch proper conversion to UTF-8 is done. > How can I handle my subs if it is already in UTF-8? > umm.. "--sub-charset UTF-8" ? Yes. > ...Are you really going to implement every possible conversions? I don't have to. There is a library called iconv on Unix/Linux systems (and also on Windows if you use cygwin which I do for the binries) which can do all the conversions! It supports... let me check... 942 different charsets, and its man page states: The values permitted for fromcode and tocode and the supported combinations are system dependent. For the GNU C library, the permitted values are listed by the iconv --list command, and all combinations of the listed values are supported. So I don't have to worry about the conversion myself, I just have to set the charset. > "If not specified the charset will be derived from the current locale > settings." <-- this default is fine > and how about these? > > --sub-utf8 > Subtext is treated as already in UTF-8 and will be muxed as > S_TEXT/UTF8 Can be achieved with "--sub-charset UTF-8". > --sub-ascii > Subtext is treated as already in ASCII and will be muxed as > S_TEXT/ASCII That's what "--no-utf8-subs" is. But you're right, I should probably rename "--no-utf8-subs" and maybe add "--sub-utf8" as an alias for "--sub-charset UTF-8". And write proper documentation for it in the man page/HTML docs. (differences in handling MP3 packets between VDubMod/mkvmerge) > I see. Thank you for explanation. You're welcome. -- ==> Ciao, Mosu (Moritz Bunkus) http://www.matroska.org From Liisachan at faireal.net Mon May 12 00:49:28 2003 From: Liisachan at faireal.net (Liisachan) Date: Mon, 12 May 2003 07:49:28 +0900 Subject: [matroska-devel] Re: MKVToolnix - --sub-charset will support all encodings? In-Reply-To: <20030511220029.GH15464@bunkus.org> References: <20030509153055.GG24454@bunkus.org> <3EBC34AB.5080009@faireal.net> <20030510082532.GH24454@bunkus.org> <3EBEC575.1040304@faireal.net> <20030511220029.GH15464@bunkus.org> Message-ID: <3EBED378.4040007@faireal.net> Moritz Bunkus wrote: >I don't have to. There is a library called iconv on Unix/Linux systems >(and also on Windows if you use cygwin which I do for the binries) which >can do all the conversions! It supports... let me check... 942 different >charsets, and its man page states: > > The values permitted for fromcode and tocode and the > supported combinations are system dependent. For the GNU C > library, the permitted values are listed by the > iconv --list command, and all combinations of the listed values > are supported. > >So I don't have to worry about the conversion myself, I just have to set >the charset. > > Awesome... Thank you for explanation. So, all you need is to tell them all the possible param names, right? >But you're right, I should probably rename "--no-utf8-subs" and maybe >add "--sub-utf8" as an alias for "--sub-charset UTF-8". And write proper >documentation for it in the man page/HTML docs. > > Um, I dont mind how you call it, as long as I can use UTF-8 subs directly :) (being picky, "MKVmerge" should be called "MKVmux" too ;)?) But, let me make another suggestion: When you want to transmux an OGM into MKV, the OGM may have one or more than one SRT(s) in it. Those SRTs are usually typed in a Windows CP, and should be converted into S_TEXT/UTF8 in MKV The question is, From which code page? You cannot tell it from the def language of the OS (especially in a multisub ogm) For instance, I may have an OGM with Japanese subs, but that ogm happen to be multi-sub containing French subs too. in this case, Japanese and French are different code pages, and the conversation into utf8 wont be the same. So, how about cheking the language tag, instead of system default language, when SRT(s) embedded in OGM should be transumxed? Maybe this has nothing to do with MKVToolnix, but let me make a note about this idea for anyone whom it may concern. thank you Liisachan http://www.matroska.org From chris at matroska.org Fri May 9 16:12:54 2003 From: chris at matroska.org (Christian HJ Wiesner) Date: Fri, 09 May 2003 16:12:54 +0200 Subject: [matroska-devel] Re: Matroska DirectShow Filter (Part 2) In-Reply-To: <3EBBAF44.1040408@optusnet.com.au> References: <3EBBAF44.1040408@optusnet.com.au> Message-ID: <3EBBB766.6090702@matroska.org> Bill Ogier wrote: > I have posted a link to the installer here: > http://members.optusnet.com.au/~scorpeg/ > Please do not post this link anywhere, but feel free to post the file > anywhere you wish. > I will be making installers for future releases of the Filter too. > My friends are not fans of registering dll's > Cheers 1st email from Bill Ogier : Hi, after the negative tests with WMV9 VCM by some users and me, i checked another important VfW codec, being HuffYuv. It doesnt work also :( ... I assume something in the current implementation of our VfW compatibility mode isnt working. Toff has found that, when comparing the codec private data ( BITMAPINFOHEADER + ? ) from a WMV9 AVI and a WMV9 MKV file, the size of the private data differes significantly, as for AVI it was 125 bytes as opposed to 80 bytes from the MKV. He could successfully play WMV9 VCM from matroska when feeding the WMV9 decoder filter ( AVIdecompressor + VCM decoder ) with the 135 bytes from the AVI instaed of using the KaxCodecPrivateData from the MKV trackheader ( dont ask me how he did it ;) .. ). We either have a problem with - VirtualdubMod, rading/writing the codec private data incorrectly - the parser filter, reading and passing the content of the element incorrectly Christian http://www.matroska.org From moritz at bunkus.org Sun May 11 10:06:51 2003 From: moritz at bunkus.org (Moritz Bunkus) Date: Sun, 11 May 2003 10:06:51 +0200 Subject: [matroska-devel] Re: Broken VfW compatibility mode for MKV files in VdubMod ? Or DShow parser problem In-Reply-To: <3EBE0327.8070502@matroska.org> References: <3EBE0327.8070502@matroska.org> Message-ID: <20030511080651.GC15464@bunkus.org> Hi. I might have the same problem. Could someone please provide an AVI with WMV9 or HuffYUV data? I prefer WMV9 as it'll be a LOT smaller ;) -- ==> Ciao, Mosu (Moritz Bunkus) http://www.matroska.org From steve.lhomme at free.fr Sun May 11 20:46:04 2003 From: steve.lhomme at free.fr (Steve Lhomme) Date: Sun, 11 May 2003 20:46:04 +0200 Subject: [matroska-devel] New DirectShow filter out Message-ID: <3EBE9A6C.60109@free.fr> As you probably know, we have released today a stable DirectShow parser to read matroska files. It can be found on http://www.matroska.org/downloads/ There is also a TCMP plugin to retrieve more infos about a matroska file. And also new sources with additions and some bug corrections (on reading and writing). The next steps I can see in the near future : - DS: add a properties dialog box to retrieve informations from the matroska file, and maybe inspect the queues - DS: make a non UNICODE version for Win98 ? - libmatroska: change ProcessMandatory so that mandatory elements that are not unique are at least added once. Writing applications may need a few modifications (fill this first element before adding new ones to the list). Then we can work on the more important things. The DirectShow filter being in the center (and muxing apps when new features are added), like moving to an ASync reader (which is already the case but not in the DS terms) and being able to select the audio/video/subtitles tracks. http://www.matroska.org From admin at forbidden.cz Mon May 12 07:47:22 2003 From: admin at forbidden.cz (Admin AF) Date: Mon, 12 May 2003 07:47:22 +0200 Subject: [matroska-devel] Direct Show filter problems in Win98 SE Message-ID: <000f01c3184a$3a82c100$01fea8c0@server> Hello, Matroska is really good idea how to store all tracks, subtitles, etc. in one file. Perfect. But there is a small problem when I try to play it. If I install your DS filter v0.3.0, everything is OK, but if I try to use v0.4.0, my old good Win98 SE cannot use it and mplayer 6.4 (old, but works fast) says: there is no way how to play this file blah blah. Class is not registered. Hm, if I boot to Win2k (something like backup system, when Win 98 crashes too much :-) ), everything work fine and I enjoy playing The matrix movie in Matroska format using your 0.4.0 filter without any problems. What is wrong in my old good Win98 Czech? I think, I can use regedt32 yet :-)) Please try to help me. Play/Pause/Stop/Seek/Quit in DS filter is really good idea, which makes your work close to perfection. PS.: Sorry for some mistakes and misprints in this letter. English isn't my mother language. JK http://www.matroska.org From blacksun at corecodec.com Mon May 12 12:43:22 2003 From: blacksun at corecodec.com (Ludovic "BlackSun" Vialle) Date: Mon, 12 May 2003 12:43:22 +0200 Subject: [matroska-devel] Re: Direct Show filter problems in Win98 SE In-Reply-To: <000f01c3184a$3a82c100$01fea8c0@server> References: <000f01c3184a$3a82c100$01fea8c0@server> Message-ID: this is a know bug and will be fixed ASAP. thanks for the report ;) Admin AF wrote: > Hello, > > Matroska is really good idea how to store all tracks, subtitles, etc. in one file. Perfect. > > But there is a small problem when I try to play it. If I install your DS filter v0.3.0, everything is OK, but if I try to use v0.4.0, my old good Win98 SE cannot use it and mplayer 6.4 (old, but works fast) says: there is no way how to play this file blah blah. Class is not registered. Hm, if I boot to Win2k (something like backup system, when Win 98 crashes too much :-) ), everything work fine and I enjoy playing The matrix movie in Matroska format using your 0.4.0 filter without any problems. > > What is wrong in my old good Win98 Czech? I think, I can use regedt32 yet :-)) > > Please try to help me. Play/Pause/Stop/Seek/Quit in DS filter is really good idea, which makes your work close to perfection. > > PS.: Sorry for some mistakes and misprints in this letter. English isn't my mother language. > > JK > http://www.matroska.org > http://www.matroska.org From chris at matroska.org Mon May 12 12:57:25 2003 From: chris at matroska.org (Christian HJ Wiesner) Date: Mon, 12 May 2003 12:57:25 +0200 Subject: [matroska-devel] Re: Direct Show filter problems in Win98 SE In-Reply-To: References: <000f01c3184a$3a82c100$01fea8c0@server> Message-ID: <3EBF7E15.2060500@matroska.org> Ludovic "BlackSun" Vialle wrote: >this is a know bug and will be fixed ASAP. >thanks for the report ;) > > Well, its not really a bug currently, more like an unwanted feature ... LOL ! If i understood correctly than the current filter wont work on Win98 because this old OS doesnt support the unicode functions in the filter code correctly. It seems we have 2 options : - release a Win98 filter without unicode support in file names etc. ( :( ) - add unicode code support to Win98 adding a nice wrapper library called 'unicows' , as recommended by Snaar The old, ugly DOS limitations, in a more evil and modern incarnation, reaching with its cold, scary fingers for the throat of poor, virgin matroska child ..... when will the Bill Gates horror finally stop .... LOL !! Christian http://www.matroska.org From steve.lhomme at free.fr Tue May 13 10:06:01 2003 From: steve.lhomme at free.fr (Steve Lhomme) Date: Tue, 13 May 2003 10:06:01 +0200 Subject: [matroska-devel] Re: Direct Show filter problems in Win98 SE In-Reply-To: <3EBF7E15.2060500@matroska.org> References: <000f01c3184a$3a82c100$01fea8c0@server> <3EBF7E15.2060500@matroska.org> Message-ID: <3EC0A769.7020402@free.fr> Christian HJ Wiesner wrote: > Well, its not really a bug currently, more like an unwanted feature ... > LOL ! If i understood correctly than the current filter wont work on > Win98 because this old OS doesnt support the unicode functions in the > filter code correctly. It seems we have 2 options : > > - release a Win98 filter without unicode support in file names etc. ( :( ) > - add unicode code support to Win98 adding a nice wrapper library called > 'unicows' , as recommended by Snaar > > The old, ugly DOS limitations, in a more evil and modern incarnation, > reaching with its cold, scary fingers for the throat of poor, virgin > matroska child ..... when will the Bill Gates horror finally stop .... > LOL !! A filter for Win98 has been released. Check http://www.matroska.org/downloads/mkxds-0.4.0-W98.zip It has simply been built with a lesser Unicode support. http://www.matroska.org From christian at matroska.org Tue May 13 10:57:42 2003 From: christian at matroska.org (ChristianHJW) Date: Tue, 13 May 2003 10:57:42 +0200 Subject: [matroska-devel] Re: NSV/VP3 Note In-Reply-To: References: Message-ID: <3EC0B386.6090607@matroska.org> Mike Melanson wrote: > Hi, > I played around with the NSV (Nullsoft Video) format this evening, > coupled with my new ffmpeg VP3 decoder. It looks like the video in the > files is just raw VP3 data and it starts at byte 24 in each NSVs block. > Still not sure where the audio begins in the chunk or where (or if) there > are length fields in the header. > -Mike Melanson I am convinced it will be much easier to implement matroska playback into xine, given that we were actually documenting how the files are muxed, so nobody has to guess or reverse engineer that ;) ..... Christian http://www.matroska.org http://www.matroska.org From chris at matroska.org Tue May 13 14:17:52 2003 From: chris at matroska.org (Christian HJ Wiesner) Date: Tue, 13 May 2003 14:17:52 +0200 Subject: [matroska-devel] Problems with matroska parser filter output pin : its unable to call dvobsub Message-ID: <3EC0E270.5020001@matroska.org> Hi, i am turning to the subs professionals on the usf-devel list ( Gabest, Toff ), copy to tcmp-devel and matroska-devel : Why oh why do we have to set DVobSub to load always and automatically to be able to display our subs in matroska ? Why cant the parser filter call DVobSub for subs display, or better, why doesnt DShow insert DvobSub automatically ? Christian http://www.matroska.org From christophe.paris at free.fr Tue May 13 16:49:25 2003 From: christophe.paris at free.fr (Christophe PARIS) Date: Tue, 13 May 2003 16:49:25 +0200 Subject: [matroska-devel] Re: Problems with matroska parser filter output pin : its unable to call dvobsub In-Reply-To: <3EC0E270.5020001@matroska.org> References: <3EC0E270.5020001@matroska.org> Message-ID: <3EC105F5.5030107@free.fr> Hi, I think that DVobsub has by default a lower priority than the Internal Script Command Renderer filter (from Microsoft) for stream coming from unknown splitter like the matroska one. In my opinion the best way to resolve the problem would be to use a new subtitle MEDIATYPE (or SUBTYPE maybe). It will also make possible to distingish subtitles format. We must also define a way to inform dvobsub of the language used or if a subtitle stream must always be displayed (like closed caption). With the flexibility of matroska we need to re-think how subtitles are handled :) Best regards, Toff Christian HJ Wiesner wrote: > > Hi, > > i am turning to the subs professionals on the usf-devel list ( Gabest, > Toff ), copy to tcmp-devel and matroska-devel : > > Why oh why do we have to set DVobSub to load always and automatically to > be able to display our subs in matroska ? Why cant the parser filter > call DVobSub for subs display, or better, why doesnt DShow insert > DvobSub automatically ? > > Christian > > http://www.matroska.org > > http://www.matroska.org From paul at msn.com Wed May 14 00:27:36 2003 From: paul at msn.com (Pamel) Date: Tue, 13 May 2003 17:27:36 -0500 Subject: [matroska-devel] Re: Problems with matroska parser filter output pin : its unable to call dvobsub References: <3EC0E270.5020001@matroska.org> <3EC105F5.5030107@free.fr> Message-ID: "Gabest" wrote > > In my opinion the best way to resolve the problem would be to use a new > > subtitle MEDIATYPE (or SUBTYPE maybe). It will also make possible to > > distingish subtitles format. > > That's an excellent idea, needed to be done to ogm long ago > too. I suggest using a format, what I also forced into avi :), where there > is only one sample containing the whole subtitle file. To save more space it > could be compressed with some lzw coding (I have the source of an gif codec > here somewhere which I made years ago, it is quite simple and short). Or > alternatively, the format block of each sample could tell about the global > style and other info in a predefined structure (more specs to be done, > hehe), and the raw text could have some kind of style mod tags stuffed in > it, but I hate html tags.. they are a pain to parse. I think I should comment here. There is a very specific way that subtitles are supposed to be stored in Matroska. Each set of words with a timecode is supposed is supposed to be stored by itself in a block. The timecode of the block is the timecode that the subtitle is supposed to appear. The duration that the subtitle is supposed to be on the screen is stored in an element known as BlockDuration. Information that is to be applied to the subtitle track in general goes in the CodecPrivateData. To illustrate this, I will use USF as an example. Here is some example USF code: The Core Media Player subtitle format sample [Toff] christophe.paris at free.fr http://christophe.paris.free.fr English 2002-08-15 This is a sample What can be done ? In this example, the Metadata would be stripped and placed in the native Matroska tags. The Styles would be stripped and placed in the CodecPrivateData. The subtitle Start time would be stripped and placed in the Blocks timecode. The Stop time would be stripped and used to calculate the BlockDuration. When the file is loaded into a player, all of the Metadata is available as track information. The CodecPrivateData is sent to the codec so that is knows how to render all of the styles. When a subtitle block is sent to the codec, it renders the subtitle using the appropriate Style that it has already loaded. Then the subtitle is displayed at the correct time, for the correct duration. Extremely complex subtitle systems that have dependancies on other subtitles can use the ReferenceBlock element to ensure that the other subtitle is loaded first. The reason for this is that it ensures that a Matroska editor doesn't need to have a working knowledge of whatever subtitle system is being used. For instance, if you had a movie with subtitles, you could cut out a clip from the middle and it would remove the video frames, audio frames, and subtitles, and everything would stay in synch. You could even change the speed of the movie and only need to reencode the audio, the video and subtitles would just need the timecode and Blockduration of the block changed. In fact, most editing for Matroska could be done by an editor that did not have to be able to decode any video, audio, or subtitle data, as long as it was all stored in the proper manner. > > We must also define a way to inform dvobsub of the language used or if a > > subtitle stream must always be displayed (like closed caption). > > This should go into the format block. This would actually go in the Language element for the Track. > > With the flexibility of matroska we need to re-think how subtitles are > > handled :) > > "Think! Think! Think!" - Winnie The Pooh :) Most of this has already been thought out. Now it just needs to be properly implemented. Pamel http://www.matroska.org From theo_brendel at hotmail.com Wed May 14 12:28:03 2003 From: theo_brendel at hotmail.com (Steven Mingam) Date: Wed, 14 May 2003 12:28:03 +0200 Subject: [matroska-devel] Re: Problems with matroska parser filter output pin : its unable to call dvobsub References: <3EC0E270.5020001@matroska.org> <3EC105F5.5030107@free.fr> Message-ID: yay a topic for me \o/ i have some questions which are bullying me for some time now : >The Styles would be stripped and placed in the CodecPrivateData. 1) how do you put the styles infos in CodecPrivateData (and CodecState for style override) ? in plain text or something ? (it's quite dirty, imo, you have to parse it to get wanted informations) or can we define some tags ? (like for video or audio, you have resolution, sampling rate etc ...) for me, subtitles have some necessary informations like video to be know. Like playResY in ssa : it's used know how to scale font size & position , if you change it from 768 to 1024, you mess up all your edition's work. (I agree, it's stupid, but it's the way SSA work :-/) 2) it's happen very often to have more than 3 or 4 events at the same time in a subfile ... is it possible in matroska to have blocks with the same timestamp in the same track ? 3) ssa is not sorted, and it's very usefull when you do some advanced edition (example : put the translation notes in a row to not have to search them in the entire file) how is handled in matroska ? it has to be sorted ? (if sorted at mux, demux do not output the original sub ;) - not like it's really a problem but ... wait, i don't want my subs to be demuxed ! - ) So, i think we need to define the one and only way to store subs in matroska, because subtitles are all the same (with more or less informations). And afaik, there isn't something defined in the specs (or i'm blind ?? it wouldn't suprise me ;) more, Once it's done, to add a new subtitle format, you just have to write a parser, all the matroska work is done. Here my humble opinion, perhaps it has already discussed many times and the same conclusions came up, but i'm not aware of it, and wanted to say it ;) bill_baroud "Pamel" a ?crit dans le message news: b9rrdn$4lg$1 at main.gmane.org... > "Gabest" wrote > > > In my opinion the best way to resolve the problem would be to use a new > > > subtitle MEDIATYPE (or SUBTYPE maybe). It will also make possible to > > > distingish subtitles format. > > > > That's an excellent idea, needed to be done to ogm long ago > > too. I suggest using a format, what I also forced into avi :), where there > > is only one sample containing the whole subtitle file. To save more space > it > > could be compressed with some lzw coding (I have the source of an gif > codec > > here somewhere which I made years ago, it is quite simple and short). Or > > alternatively, the format block of each sample could tell about the global > > style and other info in a predefined structure (more specs to be done, > > hehe), and the raw text could have some kind of style mod tags stuffed in > > it, but I hate html tags.. they are a pain to parse. > > I think I should comment here. There is a very specific way that subtitles > are supposed to be stored in Matroska. Each set of words with a timecode is > supposed is supposed to be stored by itself in a block. The timecode of the > block is the timecode that the subtitle is supposed to appear. The duration > that the subtitle is supposed to be on the screen is stored in an element > known as BlockDuration. Information that is to be applied to the subtitle > track in general goes in the CodecPrivateData. > > To illustrate this, I will use USF as an example. Here is some example USF > code: > > > > The Core Media Player subtitle format sample > > [Toff] > christophe.paris at free.fr > http://christophe.paris.free.fr > > English > 2002-08-15 > This is a sample > > > > > > > > > What can be done ? > > > > > > In this example, the Metadata would be stripped and placed in the native > Matroska tags. The Styles would be stripped and placed in the > CodecPrivateData. The subtitle Start time would be stripped and placed in > the Blocks timecode. The Stop time would be stripped and used to calculate > the BlockDuration. > > When the file is loaded into a player, all of the Metadata is available as > track information. The CodecPrivateData is sent to the codec so that is > knows how to render all of the styles. When a subtitle block is sent to the > codec, it renders the subtitle using the appropriate Style that it has > already loaded. Then the subtitle is displayed at the correct time, for the > correct duration. Extremely complex subtitle systems that have dependancies > on other subtitles can use the ReferenceBlock element to ensure that the > other subtitle is loaded first. > > The reason for this is that it ensures that a Matroska editor doesn't need > to have a working knowledge of whatever subtitle system is being used. For > instance, if you had a movie with subtitles, you could cut out a clip from > the middle and it would remove the video frames, audio frames, and > subtitles, and everything would stay in synch. You could even change the > speed of the movie and only need to reencode the audio, the video and > subtitles would just need the timecode and Blockduration of the block > changed. In fact, most editing for Matroska could be done by an editor that > did not have to be able to decode any video, audio, or subtitle data, as > long as it was all stored in the proper manner. > > > > We must also define a way to inform dvobsub of the language used or if a > > > subtitle stream must always be displayed (like closed caption). > > > > This should go into the format block. > > This would actually go in the Language element for the Track. > > > > With the flexibility of matroska we need to re-think how subtitles are > > > handled :) > > > > "Think! Think! Think!" - Winnie The Pooh :) > > Most of this has already been thought out. Now it just needs to be properly > implemented. > > > Pamel > > > > http://www.matroska.org > http://www.matroska.org From moritz at bunkus.org Wed May 14 12:56:08 2003 From: moritz at bunkus.org (Moritz Bunkus) Date: Wed, 14 May 2003 12:56:08 +0200 Subject: [matroska-devel] Re: Problems with matroska parser filter output pin : its unable to call dvobsub In-Reply-To: References: <3EC0E270.5020001@matroska.org> <3EC105F5.5030107@free.fr> Message-ID: <20030514105607.GJ2990@bunkus.org> Hi. > 2) it's happen very often to have more than 3 or 4 events at the same time > in a subfile ... > is it possible in matroska to have blocks with the same timestamp in the > same track ? Yes, sure. > 3) ssa is not sorted, and it's very usefull when you do some advanced > edition (example : put the translation notes in a row to not have to search > them in the entire file) > how is handled in matroska ? it has to be sorted ? (if sorted at mux, demux > do not output the original sub ;) - not like it's really a problem but ... > wait, i don't want my subs to be demuxed ! - ) Yes, they should be sorted. This is not a problem as you can easily sort such a small text file on muxing. As for the demuxing part: I've stated several times on the IRC that with us being an Open Standards project and all the software being Open Source software there is NO WAY you can prohibit others from demuxing subtitles from a Matroska file. If you don't want them to be demuxed then don't mux them in the first place. Or don't distribute it. Sorry to sound harsh, but Matroska will not offer any content protection in the near future. > So, i think we need to define the one and only way to store subs in > matroska, because subtitles are all the same (with more or less > informations). > And afaik, there isn't something defined in the specs (or i'm blind ?? it > wouldn't suprise me ;) I agree. So far the system Pamel described is the one we're using: 1) store the start time as the block's timecode, 2) store the duration in the BlockDuration element, 3) put the text (and effects for enhanced subtitle formats) into the data itself. But we need some specs for how exactly to store this stuff: both the CodecPrivate stuff and the effects. Just use the remaning XML tags for USF? Don't know, I haven't thought much about it. > Here my humble opinion, perhaps it has already discussed many times and the > same conclusions came up, but i'm not aware of it, and wanted to say > it ;) Nope, so far we haven't spent much thought on subtitles. Most stuff was initiated by me, but it's only for such simple formats as srt/MicroDVD without anything special. -- ==> Ciao, Mosu (Moritz Bunkus) http://www.matroska.org From steve.lhomme at free.fr Wed May 14 15:38:04 2003 From: steve.lhomme at free.fr (Steve Lhomme) Date: Wed, 14 May 2003 15:38:04 +0200 (CEST) Subject: [matroska-devel] Re: Problems with matroska parser filter output pin : its unable to call dvobsub In-Reply-To: <20030514105607.GJ2990@bunkus.org> References: <3EC0E270.5020001@matroska.org> <3EC105F5.5030107@free.fr> <20030514105607.GJ2990@bunkus.org> Message-ID: <1052919484.3ec246bc7123a@imp.free.fr> En r?ponse ? Moritz Bunkus : > > Hi. > > > 2) it's happen very often to have more than 3 or 4 events at the same > time > > in a subfile ... > > is it possible in matroska to have blocks with the same timestamp in > the > > same track ? > > Yes, sure. I vote against this. That's not a good/logical way to do things. http://www.matroska.org From outlyer at outlyer.net Thu May 15 00:18:31 2003 From: outlyer at outlyer.net (Toni Corvera (outlyer)) Date: Thu, 15 May 2003 00:18:31 +0200 Subject: [matroska-devel] Re: Problems with matroska parser filter output pin : its unable to call dvobsub In-Reply-To: <1052919484.3ec246bc7123a@imp.free.fr> References: <3EC0E270.5020001@matroska.org> <3EC105F5.5030107@free.fr> <20030514105607.GJ2990@bunkus.org> <1052919484.3ec246bc7123a@imp.free.fr> Message-ID: Steve Lhomme wrote: >>>2) it's happen very often to have more than 3 or 4 events at the same >>>time in a subfile ... >>> is it possible in matroska to have blocks with the same timestamp in >>> the same track ? >>Yes, sure. > > I vote against this. That's not a good/logical way to do things. In the same subs can be unsorted in the input and sorted when muxhing, they could be merged at mux time as an unique entry, which seems logical to me. Am I wrong? ---Toni http://www.matroska.org From theo_brendel at hotmail.com Fri May 16 11:52:33 2003 From: theo_brendel at hotmail.com (bill_baroud) Date: Fri, 16 May 2003 11:52:33 +0200 Subject: [matroska-devel] Re: Problems with matroska parser filter output pin : its unable to call dvobsub References: <3EC0E270.5020001@matroska.org> <3EC105F5.5030107@free.fr> <20030514105607.GJ2990@bunkus.org> <1052919484.3ec246bc7123a@imp.free.fr> Message-ID: if you have more than 1 event at time, each event has logically a different position. Position should be stored in CodecState which is unique for a given block. So you have a problem here, if you create an unique block with just the text as data. It seems we need to "code" every text based subs files in a unique (binary?) format before store it in matroska and decode it afterwards. Well i need to understand what robux4 tried to explain me yesterday about duration overlapping & co ----- Original Message ----- From: "Toni Corvera (outlyer)" Newsgroups: gmane.comp.multimedia.matroska.devel Sent: Thursday, May 15, 2003 12:18 AM Subject: Re: Problems with matroska parser filter output pin : its unable to call dvobsub > > Steve Lhomme wrote: > >>>2) it's happen very often to have more than 3 or 4 events at the same > >>>time in a subfile ... > >>> is it possible in matroska to have blocks with the same timestamp in > >>> the same track ? > >>Yes, sure. > > > > I vote against this. That's not a good/logical way to do things. > > In the same subs can be unsorted in the input and sorted when muxhing, > they could be merged at mux time as an unique entry, which seems logical > to me. Am I wrong? > > ---Toni > > > http://www.matroska.org > http://www.matroska.org From moritz at bunkus.org Tue May 13 22:30:44 2003 From: moritz at bunkus.org (Moritz Bunkus) Date: Tue, 13 May 2003 22:30:44 +0200 Subject: [matroska-devel] [dvdkhlng@gmx.de: [MPlayer-dev-eng] Re: [PATCH] theora support] Message-ID: <20030513203044.GG2990@bunkus.org> An embedded and charset-unspecified text was scrubbed... Name: not available URL: From chris at matroska.org Tue May 13 23:19:40 2003 From: chris at matroska.org (Christian HJ Wiesner) Date: Tue, 13 May 2003 23:19:40 +0200 Subject: [matroska-devel] Re: [dvdkhlng@gmx.de: [MPlayer-dev-eng] Re: [PATCH] theora support] In-Reply-To: <20030513203044.GG2990@bunkus.org> References: <20030513203044.GG2990@bunkus.org> Message-ID: <3EC1616C.8020507@matroska.org> Moritz Bunkus wrote: >Hi. > >This is from the guy who implemented Ogg/Theora DEMUXING support for >mplayer. All the stuff he writes about are quite interesting, and I >share his annoyance at how closely Theora and Ogg are intertwined. > >Just for your information. > > > I read it all, and cant believe some things the guy is telling us ? Its impossible to use Theora without libogg ? That's stupid IMHO, and maybe even the death of the project in a long term. What happened to the Xiph codec API that was announced by Emmett with big words, stating that UCI is shit and his genitals are the only things on this planet being UCI compatible ? If its impossible to use Theora from an API ( like XviDs internal API ), how could the codec be used from existing video encoding apps such as mencoder or transcode, without having to break everything for this specific codec ? It seems that Xiph people have still a lot to learn about video encoding stuff :( .... Christian http://www.matroska.org From steve.lhomme at free.fr Thu May 15 11:11:30 2003 From: steve.lhomme at free.fr (Steve Lhomme) Date: Thu, 15 May 2003 11:11:30 +0200 (CEST) Subject: [matroska-devel] TimeSlice Message-ID: <1052989890.3ec359c2e32d5@imp.free.fr> Hi, I added a new system to the BlockGroup yesterday. It is an optional set of tags that can be used for different things : - specify the starting timecode of each frame in a lace (might be usefull for some codec) - specify many timecodes for the same frame (could be a frame in the lace) that means the same frame/buffer will generate many frames with the specified timecode (as for GLDM's codec). In this case, the buffer is sent only once to the decoder. It might be subject to some minor changes (default value, hierarchy) http://www.matroska.org From niemayer at isg.de Fri May 16 19:47:45 2003 From: niemayer at isg.de (Peter Niemayer) Date: Fri, 16 May 2003 19:47:45 +0200 Subject: [matroska-devel] please correct A_DTS description in the codec list Message-ID: Hi everyone, the web page http://cvs.corecodec.org/cgi-bin/cvsweb.cgi/~checkout~/matroska/doc/website/specs/codex.html has a wrong explanation of the "A_DTS" ID... this wouldn't be too much of a problem if you hadn't added insult to injury by naming the most hated competitor of the Digital Theater Systems Company under that abbreviation... :-) Have a look at how much Dolby and DTS hate each other here: http://www.dolby.com/tech/mp.in.0103.DigitalVsDTS.pdf http://www.dtstech.com/media/uploads/pdfs/dtsposition.pdf http://www.dolby.com/dvd/dtsqa.pdf http://www.dtstech.com/media/uploads/pdfs/dolbyrvu.pdf Then, please, correct the entry to avoid being drawn into that mud-fight :-) Cheers, Peter Niemayer http://www.matroska.org From moritz at bunkus.org Tue May 20 12:28:38 2003 From: moritz at bunkus.org (Moritz Bunkus) Date: Tue, 20 May 2003 12:28:38 +0200 Subject: [matroska-devel] Re: please correct A_DTS description in the codec list In-Reply-To: References: Message-ID: <20030520102838.GD9872@bunkus.org> Hi. > has a wrong explanation of the "A_DTS" ID... this wouldn't be too much of a > problem if you hadn't added insult to injury by naming the most hated > competitor of the Digital Theater Systems Company under that > abbreviation... :-) :) I've already corrected that on Sunday. -- ==> Ciao, Mosu (Moritz Bunkus) http://www.matroska.org From paul at msn.com Tue May 20 17:39:34 2003 From: paul at msn.com (Pamel) Date: Tue, 20 May 2003 10:39:34 -0500 Subject: [matroska-devel] Re: please correct A_DTS description in the codec list References: Message-ID: "Peter Niemayer" wrote... > has a wrong explanation of the "A_DTS" ID... this wouldn't be too much of a > problem if you hadn't added insult to injury by naming the most hated > competitor of the Digital Theater Systems Company under that abbreviation... :-) How strange that I never realized that DTS was not a Dolby extension. Thank you so much for pointing that out as I have always, incorrectly, said "Dolby Digital/DTS". Pamel http://www.matroska.org From moritz at bunkus.org Sat May 17 13:55:00 2003 From: moritz at bunkus.org (Moritz Bunkus) Date: Sat, 17 May 2003 13:55:00 +0200 Subject: [matroska-devel] duration elements Message-ID: <20030517115500.GP2990@bunkus.org> Hi. BBB asked why there are no duration tags along with each block and Chris and I told him how we've handled that stuff so far (only mandatory for simple subtitles), but I somehow see the benefit of having a duration for each block. So I did some tests and included KaxBlockDuration elements for ALL blocks. This made a 700megs file bigger by about 900k. This is not acceptable, of course. But we could use another approach: the one that Ogm uses (hey, take the best of it and discard the rest :)): We introduce a new element, KaxTrackDefaultDuration or something like that, which is stored along with the track headers. This element contains the default duration for each block (!) in ms, even if the block's in a lace. Next thing is we store KaxBlockDuration elements ONLY if they differ from the KaxTrackDefaultDuration. For most of the cases (fixed fps video, MP3, AC3, PCM) we will only need the KaxTrackDefaultDuration as they are all 'constant number of samplers per frame'. Last this should be made mandatory. The default value for KaxTrackDefaultDuration should be 0 (e.g. for subtitle tracks you don't really need the default duration as each entry will be shown as long as it needs to be shown). This will not enlarge the files by much, BUT it will give editors the ability to process Matroska files without knowing the contents too intimately. We would gain a lot and sacrifice little (space). I know this would be a major change, but please think about it. I also know that current Matroska files will then not be really 'spec compliant', but that should not be a problem, AND if we can do such a change it is RIGHT NOW and not in a couple of months. Knowing the duration without having to know the block's contents is a Good Thing(tm). -- ==> Ciao, Mosu (Moritz Bunkus) http://www.matroska.org From paul at msn.com Sat May 17 19:54:29 2003 From: paul at msn.com (Pamel) Date: Sat, 17 May 2003 12:54:29 -0500 Subject: [matroska-devel] Re: duration elements References: <20030517115500.GP2990@bunkus.org> Message-ID: "Moritz Bunkus" wrote > Knowing the > duration without having to know the block's contents is a Good Thing(tm). I thought the default duration was the space between the beginning of one block, and the beginning of the next, unless otherwise specified? Is there a problem with doing it that way? Pamel http://www.matroska.org From moritz at bunkus.org Sat May 17 19:58:20 2003 From: moritz at bunkus.org (Moritz Bunkus) Date: Sat, 17 May 2003 19:58:20 +0200 Subject: [matroska-devel] Re: duration elements In-Reply-To: References: <20030517115500.GP2990@bunkus.org> Message-ID: <20030517175819.GQ2990@bunkus.org> Hi. > I thought the default duration was the space between the beginning of one > block, and the beginning of the next, unless otherwise specified? Is there > a problem with doing it that way? The 'problem' is that you only know that duration as soon as you've found the next block. So if you need it 'right now' then you have to cache the current block and search the next one. If you include the duration for each block then you instantly know its duration. -- ==> Ciao, Mosu (Moritz Bunkus) http://www.matroska.org From paul at msn.com Sat May 17 20:23:37 2003 From: paul at msn.com (Pamel) Date: Sat, 17 May 2003 13:23:37 -0500 Subject: [matroska-devel] Re: duration elements References: <20030517115500.GP2990@bunkus.org> <20030517175819.GQ2990@bunkus.org> Message-ID: "Moritz Bunkus" wrote ... > The 'problem' is that you only know that duration as soon as you've > found the next block. So if you need it 'right now' then you have to > cache the current block and search the next one. I would think that caching one block could only be an issue when using an embedded device with limited ram. I'm not sure how well a default duration would work with video very well because we are already dealing with variable frame rate. VirtualDubMod already drops out dropped frames, and so captures and 120fps video end up variable. Also Ogg is "vfr" because you can have a different number of samples in each packet, correct? It doesn't sound so hot to me, but maybe with a little bit of clarification of what would happen in each situation... Pamel http://www.matroska.org From rbultje at ronald.bitfreak.net Sun May 18 16:00:21 2003 From: rbultje at ronald.bitfreak.net (Ronald Bultje) Date: 18 May 2003 16:00:21 +0200 Subject: [matroska-devel] Re: duration elements In-Reply-To: References: <20030517115500.GP2990@bunkus.org> <20030517175819.GQ2990@bunkus.org> Message-ID: <1053266421.5724.50.camel@shrek.bitfreak.net> Hey, On Sat, 2003-05-17 at 20:23, Pamel wrote: > I would think that caching one block could only be an issue when using an > embedded device with limited ram. it is conceptually wrong. Having to know information about *another* block to get full information on the *current* block doesn't make sense (well, it's the case for keyframes vs. non-keyframes, but that's by concept, too). Besides, no-one has ever said that the next frame/sample/subtitle follows directly after the current one (therefore, the duration property is already obligatory for subtitles - the same reasoning applies to audio too). Ronald http://www.matroska.org From paul at msn.com Sun May 18 19:01:05 2003 From: paul at msn.com (Pamel) Date: Sun, 18 May 2003 12:01:05 -0500 Subject: [matroska-devel] Re: duration elements References: <20030517115500.GP2990@bunkus.org> <20030517175819.GQ2990@bunkus.org> <1053266421.5724.50.camel@shrek.bitfreak.net> Message-ID: "Ronald Bultje" wrote> > it is conceptually wrong. Having to know information about *another* > block to get full information on the *current* block doesn't make sense > (well, it's the case for keyframes vs. non-keyframes, but that's by > concept, too). I don't know about conceptually, I just haven't put enough thought into it. There had originally been consideration of putting a duration of every block, but that was rejected because of the overhead. > Besides, no-one has ever said that the next frame/sample/subtitle > follows directly after the current one (therefore, the duration property > is already obligatory for subtitles - the same reasoning applies to > audio too). That is actually how it works unless otherwise specified. If there is a break in the track that starts back up later, then you MUST use a BlockDuration on the last block before the break. If there is no BlockDuration, then it is by default, not a break. A BlockDuration is not technically required for subtitles if one subtitle ends right when another begins, it would just be extra work to implement that on the muxing side so we just live with the tiny bit of extra overhead. I'm not opposed to using a different method for calculating the duration, I just don't think this idea will work the best. Anytime you do have a variable framerate, the system breaks down. And right now you get that from VirtualDubMod whenever there is a dropped frame, from 120fps Anime, and from Vorbis. If it doesn't work for Vorbis, then it should probably be rethought. Pamel http://www.matroska.org From moritz at bunkus.org Mon May 19 09:41:52 2003 From: moritz at bunkus.org (Moritz Bunkus) Date: Mon, 19 May 2003 09:41:52 +0200 Subject: [matroska-devel] Re: duration elements In-Reply-To: References: <1053266421.5724.50.camel@shrek.bitfreak.net> Message-ID: <20030519074152.GF2990@bunkus.org> Hi. > That is actually how it works unless otherwise specified. If there is a > break in the track that starts back up later, then you MUST use a > BlockDuration on the last block before the break. But what do you consider a 'break'? 1 second? So for 120fps anime you could have 119 missing frames before you'd have to add a duration element. It's not easy to define that 'break'. Relying on the programmers to implement sane values is risky ;) > I'm not opposed to using a different method for calculating the duration, I > just don't think this idea will work the best. Anytime you do have a > variable framerate, the system breaks down. No, it does not break down, why should it? You specify the default duration in the headers. If a block has a duration that's different than the default duration then you add a BlockDuration element for it which overrides the default duration. > And right now you get that from > VirtualDubMod whenever there is a dropped frame, When there's a dropped frame then the previous frame gets a BlockDuration element. > from 120fps Anime, Don't know much about it, why is this a problem? If it's 120fps fixed then the default duration is 1000/120 ms. > and from Vorbis. If it doesn't work for Vorbis, then it should probably be > rethought. Vorbis audio blocks are made of a few numbers of 'samples-per-packet'. They are not totally variable, e.g. you won't have 1234 samples in a packet! Tonight I'll make some experiments with Vorbis files to see how those 'samples-per-packet' numbers are distributed so that I can measure the overhead involved. For fixed fps video, MP3/AC3/AAC/PCM we don't even HAVE any overhead. -- ==> Ciao, Mosu (Moritz Bunkus) http://www.matroska.org From chris at matroska.org Sat May 17 21:24:02 2003 From: chris at matroska.org (Christian HJ Wiesner) Date: Sat, 17 May 2003 21:24:02 +0200 Subject: [matroska-devel] Re: [usf-devel] Re: subtitle elements In-Reply-To: <04c901c31aa6$bcbe7e80$0100a8c0@i2400p4> References: <1052895655.17140.401.camel@thocra> <1052920030.740.29.camel@spectrum.inescn.pt> <3EC31E07.90709@matroska.org> <04c901c31aa6$bcbe7e80$0100a8c0@i2400p4> Message-ID: <3EC68C52.4070506@matroska.org> Gabest wrote: > What are the new subtypes? I meant I'd be good to have 1 new subtype which > differs from MEDIASUBTYPE_Text and has some kind of format block to store > the needed global data like style declarations. Gabest, nothing was decided here yet, we loved to get your input first before fixing anything here right now. Any chance to join on irc.corecodec.com #matroska by tim ? Maybe his weekend ? Toff and Blacksun are the people to talk to about this, i hope they will be here. Christian http://www.matroska.org From steve.lhomme at free.fr Sun May 18 12:17:01 2003 From: steve.lhomme at free.fr (Steve Lhomme) Date: Sun, 18 May 2003 12:17:01 +0200 Subject: [matroska-devel] Matroska in MPlayerOSX Message-ID: <3EC75D9D.8050207@free.fr> Hi, I'm a happy user of MPlayer OSX on my Mac. I've been working for some time on a new A/V container called matroska and it already supported in MPlayer on Linux (in the development branch of the CVS). I was wondering if you could integrate its support in the next MplayerOSX release. I compiled successfully the Mplayer from CVS with matroska support, I didn't have any codec lib installed but the data in the file were recognised. The extension used for matroska is MKV (video) and MKA (audio). What you will need is to download the source of the libraries (libebml and libmatroska) from CVS or http://www.matroska.org/announce.html Then simply use the make/linux/Makefile for each library. It is a static linking library, so it just needs to be on your computer, not the user. (I encountered a pb where I had to run ranlib on both installed libraries). Then the configure script of Mplayer should detect it and use matroska support :) The advantage of MKV over AVI is smaller size, better reliability, much more features. Let me know if you plan to support it on the next release and if you encounter any problem. You can find basic example files on http://www.matroska.org/downloads/ Or the maintainer of the MPlayer port + UNIX tools : http://www.bunkus.org/videotools/mkvtoolnix/ http://www.matroska.org From toba at cro.cz Mon May 19 11:41:45 2003 From: toba at cro.cz (tonek) Date: Mon, 19 May 2003 11:41:45 +0200 Subject: [matroska-devel] matroska & text subtitles Message-ID: Hi there, is it possible to a) put subtitle text stream (for instance .srt fule) into matroska container b) play just created matroska file WITH the subtitle being displayed? I'm trying hard but in Windows system this seems not to be possible. The subtitle just won't show up... Thanks ToBa http://www.matroska.org From chris at matroska.org Mon May 19 13:54:00 2003 From: chris at matroska.org (Christian HJ Wiesner) Date: Mon, 19 May 2003 13:54:00 +0200 Subject: [matroska-devel] Re: matroska & text subtitles In-Reply-To: References: Message-ID: <3EC8C5D8.2040903@matroska.org> Hi tonek, thanks for using matroska ! Please direct requests like this to the matroska-user at freelists dot org mailing list, it was created specifically for this purpose. My apologies that we havent updated our website yet, this new ML is not mentioned there anywhere, just letting you know for future requests. I assume you have tried to add SRT subtitles into matroska using VirtualdubMod ? If so, please download 'VobSub' from www.doom9.org ( download section ) and install it on your PC. This will install the famous 'dvobsub' subtitle directshow filter also on your PC, and this is necessary to display matroska subs. Now goto 'start' 'program files' 'vobsub' 'dvobsub configuration' and find the switch to set dvobsub to 'always load automatically' .... now you should be able to view your subs from any DirectShow based player such as TCMP ( Core media Player, http://corecoded.com ), BSplayer, WMP 6.4, Zoomplayer, MPC, etc ... Please note that currently the Fonts will not be correct if you were using a foreign lannguage character set such as Czech, as our Dshow output pin will always handle subs like they were ASCII subs, and we havent defined a way yet to tell DvobSub that UTF8 was used ( VdubMod will always use UTF8 on muxing ). We are working on this issue together with Gabest, the well known author of VobSub, and the USF development team, and hope to be able to resolve it soon. Best regards Christian tonek wrote: >Hi there, > >is it possible to > > a) put subtitle text stream (for instance .srt fule) into matroska >container > b) play just created matroska file WITH the subtitle being >displayed? > >I'm trying hard but in Windows system this seems not to be possible. The >subtitle just won't show up... > >Thanks > >ToBa > >http://www.matroska.org > > > http://www.matroska.org From moritz at bunkus.org Mon May 19 23:21:31 2003 From: moritz at bunkus.org (Moritz Bunkus) Date: Mon, 19 May 2003 23:21:31 +0200 Subject: [matroska-devel] ADTS headerless AAC streams Message-ID: <20030519212131.GC17291@bunkus.org> Hi guys. I've got it working now: all ADTS headers are stripped from the AAC stream. Win32 binaries can be found at http://www.bunkus.org/videotools/mkvtoolnix/win32/mkvtoolnix-20030519-1.zip This is how the demuxer works: First it gathers all relevant Matroska elements. Then the private data for AAC (libfaad2 in this case) is reconstructed in the same way it is stored in MP4 which looks like this: // Recreate the 'private data' which faad2 uses in its initialization. // A_AAC/MPEG2/MAIN // 0123456789012345 if (!strcmp(&track->codec_id[12], "MAIN")) profile = 0; else if (!strcmp(&track->codec_id[12], "LC")) profile = 1; else if (!strcmp(&track->codec_id[12], "SSR")) profile = 2; else profile = 3; if (92017 <= sh_a->samplerate) srate_idx = 0; else if (75132 <= sh_a->samplerate) srate_idx = 1; else if (55426 <= sh_a->samplerate) srate_idx = 2; else if (46009 <= sh_a->samplerate) srate_idx = 3; else if (37566 <= sh_a->samplerate) srate_idx = 4; else if (27713 <= sh_a->samplerate) srate_idx = 5; else if (23004 <= sh_a->samplerate) srate_idx = 6; else if (18783 <= sh_a->samplerate) srate_idx = 7; else if (13856 <= sh_a->samplerate) srate_idx = 8; else if (11502 <= sh_a->samplerate) srate_idx = 9; else if (9391 <= sh_a->samplerate) srate_idx = 10; else srate_idx = 11; sh_a->codecdata = (unsigned char *)calloc(1, 2); sh_a->codecdata_len = 2; sh_a->codecdata[0] = ((profile + 1) << 3) | ((srate_idx & 0xe) >> 1); sh_a->codecdata[1] = ((srate_idx & 0x1) << 7) | (track->a_channels << 3); (Simply copied from the MPlayer demuxer.) My guess is that you'll need something similar for the DS filters. -- ==> Ciao, Mosu (Moritz Bunkus) http://www.matroska.org From chris at matroska.org Tue May 20 06:37:23 2003 From: chris at matroska.org (Christian HJ Wiesner) Date: Tue, 20 May 2003 06:37:23 +0200 Subject: [matroska-devel] Re: ADTS headerless AAC streams In-Reply-To: <20030519212131.GC17291@bunkus.org> References: <20030519212131.GC17291@bunkus.org> Message-ID: <3EC9B102.4050500@matroska.org> Mosu, Great work !! shitowax from the 3ivx Team replied to my question about how the 3ivX AAC filter has to be initialized here : http://forum.doom9.org/showthread.php?s=&threadid=53657 [quote]I just looked at the borgsoft decoder. It doesn't use any decoderSpecific initialization, it doesn't support audio chunks (only frames), and finally doesn't check errors properly... No chance it could work as is connected to the 3ivx splitter. Anyway, it wasn't written with this goal in mind ... The minimum requirements would be to call /* Init the library using a DecoderSpecificInfo */ char FAADAPI faacDecInit2(faacDecHandle hDecoder, unsigned char *pBuffer, unsigned long SizeOfDecoderSpecificInfo, unsigned long *samplerate, unsigned char *channels); with the end of the WAVEFORMATEX structure before calling the first faacDecDecode ...[/quote] I hope this is helpful for Toff to be able to initialize the 3ivX filter correctly, using wFormat tag '0x00FF' ... Christian Moritz Bunkus wrote: > Hi guys. > > I've got it working now: all ADTS headers are stripped from the AAC > stream. Win32 binaries can be found at > http://www.bunkus.org/videotools/mkvtoolnix/win32/mkvtoolnix-20030519-1.zip > > This is how the demuxer works: First it gathers all relevant Matroska > elements. Then the private data for AAC (libfaad2 in this case) is > reconstructed in the same way it is stored in MP4 which looks like this: > > // Recreate the 'private data' which faad2 uses in its > initialization. > // A_AAC/MPEG2/MAIN > // 0123456789012345 > if (!strcmp(&track->codec_id[12], "MAIN")) > profile = 0; > else if (!strcmp(&track->codec_id[12], "LC")) > profile = 1; > else if (!strcmp(&track->codec_id[12], "SSR")) > profile = 2; > else > profile = 3; > if (92017 <= sh_a->samplerate) > srate_idx = 0; > else if (75132 <= sh_a->samplerate) > srate_idx = 1; > else if (55426 <= sh_a->samplerate) > srate_idx = 2; > else if (46009 <= sh_a->samplerate) > srate_idx = 3; > else if (37566 <= sh_a->samplerate) > srate_idx = 4; > else if (27713 <= sh_a->samplerate) > srate_idx = 5; > else if (23004 <= sh_a->samplerate) > srate_idx = 6; > else if (18783 <= sh_a->samplerate) > srate_idx = 7; > else if (13856 <= sh_a->samplerate) > srate_idx = 8; > else if (11502 <= sh_a->samplerate) > srate_idx = 9; > else if (9391 <= sh_a->samplerate) > srate_idx = 10; > else > srate_idx = 11; > > sh_a->codecdata = (unsigned char *)calloc(1, 2); > sh_a->codecdata_len = 2; > sh_a->codecdata[0] = ((profile + 1) << 3) | ((srate_idx & 0xe) >> 1); > sh_a->codecdata[1] = ((srate_idx & 0x1) << 7) | (track->a_channels << 3); > > (Simply copied from the MPlayer demuxer.) > > My guess is that you'll need something similar for the DS filters. > http://www.matroska.org From moritz at bunkus.org Tue May 20 08:01:00 2003 From: moritz at bunkus.org (Moritz Bunkus) Date: Tue, 20 May 2003 08:01:00 +0200 Subject: [matroska-devel] Re: ADTS headerless AAC streams In-Reply-To: <3EC9B102.4050500@matroska.org> References: <20030519212131.GC17291@bunkus.org> <3EC9B102.4050500@matroska.org> Message-ID: <20030520060100.GD17291@bunkus.org> Hi. > The minimum requirements would be to call > > /* Init the library using a DecoderSpecificInfo */ > char FAADAPI faacDecInit2(faacDecHandle hDecoder, unsigned char > *pBuffer, unsigned long SizeOfDecoderSpecificInfo, unsigned long > *samplerate, unsigned char *channels); > > with the end of the WAVEFORMATEX structure before calling the first > faacDecDecode ...[/quote] I think that this is exactly what MPlayer does as well. I know that it calls faacDecInit2 with pBuffer set to the codecdata I calculate as shown in my last mail, so I guess that those two bytes are what is stored after the WAVEFORMATEX structure as well. -- ==> Ciao, Mosu (Moritz Bunkus) http://www.matroska.org From chris at matroska.org Fri May 23 07:49:53 2003 From: chris at matroska.org (Christian HJ Wiesner) Date: Fri, 23 May 2003 07:49:53 +0200 Subject: [matroska-devel] Jerky playback of matroska DirectShow parser filter Message-ID: <3ECDB681.1020701@matroska.org> Hi guys, it seems we really have an unpredictable, nasty problem here. Please read here : http://forum.doom9.org/showthread.php?s=&postid=317419#post317419 One of the strong matroska fans, animaniac, is reporting that jerkiness is much better with Toff's build of the filter, but unpredictlable, and Toff mentioned himself that he can confirm the very same on his PC. These are the possibilities i see : - hardware related : The people reporting jerky prlayback have hardware problems of some kind, maybe HDD/IDE drivers incompatibility with DirectShow, or soundcard drivers ( Creative, onboard ) or the like - we have to convert the filter to Async_reader to get tid of this problem, maybe csource has issues here - maybe the movies with jerky playback have all more than one audio tracks, and the fact we dont have a stream switcher yet is making probs In any case, we have to get this sorted, its preventing many users from switching from OGM to matroska Any ideas ? Christian http://www.matroska.org From chris at matroska.org Fri May 23 10:37:38 2003 From: chris at matroska.org (Christian HJ Wiesner) Date: Fri, 23 May 2003 10:37:38 +0200 Subject: [matroska-devel] Re: Jerky playback of matroska DirectShow parser filter In-Reply-To: <3ECDB681.1020701@matroska.org> References: <3ECDB681.1020701@matroska.org> Message-ID: <3ECDDDD2.2090202@matroska.org> Hi Ingo, you didnt hear from us for a very long time, sorry for that. While matroska, including creation/editing tools for Linux and Windows ) was launched to the public on May 1st, we are still struggling with our DirectShow parser. robux4 rewrote it from scratch as we couldnt find a 'deadlock' in myFUN's code, but now the new parser is causing some strange 'jerky' playback on the machines of some users. We tried to track down a pattern of hardware, video and audio codecs, OS versions etc, etc. but it doesnt make sense at all. Is there any chance to find such a problem using one of your DirectShow tools ( IIRC you have made such for error tracking ) ? Any other tips you have for us, from your experience ? Thanks in advance for a short reply Christian BTW : some links for win32 : File muxer : http://www.bunkus.org/videotools/mkvtoolnix/win32/mkvtoolnix-0.4.0.zip ; requires latest cygwin( DLL is in the package ), accepts AVI, OGM, AC3, AAC and OGG on the input DShow filter : http://matroska.sourceforge.net/downloads/mkxds_aac_multichannel_20030521-2.rar : special build of Dshow filter by Toff, shows less jerkiness on some machines ( no idea why ) http://matroska.sourceforge.net/downloads/mkxds-v0.4.1.zip : official build by robux4, showing more jerkiness, built exactly the same way as build above ( why oh why ) Linux ( working fine ) : http://www.bunkus.org/videotools/mkvtoolnix/ Christian HJ Wiesner wrote: >Hi guys, > >it seems we really have an unpredictable, nasty problem here. Please >read here : > >http://forum.doom9.org/showthread.php?s=&postid=317419#post317419 > >One of the strong matroska fans, animaniac, is reporting that jerkiness >is much better with Toff's build of the filter, but unpredictlable, and >Toff mentioned himself that he can confirm the very same on his PC. > >These are the possibilities i see : > >- hardware related : The people reporting jerky prlayback have hardware >problems of some kind, maybe HDD/IDE drivers incompatibility with >DirectShow, or soundcard drivers ( Creative, onboard ) or the like > >- we have to convert the filter to Async_reader to get tid of this >problem, maybe csource has issues here > >- maybe the movies with jerky playback have all more than one audio >tracks, and the fact we dont have a stream switcher yet is making probs > >In any case, we have to get this sorted, its preventing many users from >switching from OGM to matroska > >Any ideas ? > >Christian > >http://www.matroska.org > > > http://www.matroska.org From chris at matroska.org Fri May 23 11:45:09 2003 From: chris at matroska.org (Christian HJ Wiesner) Date: Fri, 23 May 2003 11:45:09 +0200 Subject: [matroska-devel] Re: Jerky playback of matroska DirectShow parser filter In-Reply-To: <3ECDDDD2.2090202@matroska.org> References: <3ECDB681.1020701@matroska.org> <3ECDDDD2.2090202@matroska.org> Message-ID: <3ECDEDA5.2050301@matroska.org> Hi, Short update : It seems Toff and robux4 just found a small bug that may be responsible for some of the problems, as the Dshow parser filter is calculating the duration for laced blocks incorrectly. This may not be the reason for all problems, but may at least solve some of them. robux4 will fix this tonight and a new filter will be released soon. I suggest nobody does take further action until the issue is resolved, to save everybody's time. Christian http://www.matroska.org From paul at msn.com Sat May 24 10:00:14 2003 From: paul at msn.com (Pamel) Date: Sat, 24 May 2003 03:00:14 -0500 Subject: [matroska-devel] Re: Re[2]: Re:MXF Tags Message-ID: Below is the conversation I've been having with the fellow from MXF. As you can see, there is about a 2 week turnaround on him answering my emails. But I remain confident that collaboration with them could help us refine a few points. Pamel ********************** Bruce, I am afraid that I am still unclear what exactly you are referring to. "Tags" in Matroska are pieces of information that can be linked to specific Tracks and/or Chapters. A Track is simply a stream. A Chapter is the equivalent of a chapter on a DVD, just a way to break up a group of streams to easily skip to a certain point. They were never meant to be used in a manner specific to a small group of frames, a single frame, or a portion of a frame in the way that MPEG-7 allows. They were intended to be used in a much more general sense. The way that a Tag is attached to a Track of Chapter is through the use of a unique ID that each Chapter and Track possesses. So, there is no way to attach these tags to anything else. We had considered the possibility of creating a Track type for information that could be much more point specific. In theory this would allow us to add full MPEG-7 support without changing any of the design of Matroska, but this is very low priority. We are focusing on consumer adoption initially, and then working our way up to corporate adoption. As such, we are in the midst of developing consumer grade tools to place different stream types in Matroska, and play them back. Though, there is a person, working for a Dutch broadcasting company, that is developing tools to digitally archive their broadcasting history. It is this persons intention to use Matroska for this. And, given the scope of this project, it offers an excellent proving ground for this formats usefulness. So, it is possible to have priorities change quickly on what will be supported most quickly. If you are referring to the use of this very point specific point specific tagging offered in MPEG-7, then I am afraid that is simply to far away to discuss in any usefulness. Though, as I said, support for this in the future should not be an issue at all. If you are referring to the more generalized tags that we use, then I am still unsure what exactly you are referring to. Again, I would say that the fastest way to collaborate would be to join the IRC channel where most discussion takes place. The IRC server is IRC.corecodec.com, and we use channel #matroska. Or, if you have any IRC software, or the Mozilla browser suite installed, just click on the link below. irc://irc.corecodec.com:6667/matroska Paul Bryson ----- Original Message ----- From: bruce.devlin at snellwilcox.com To: Paul Sent: Friday, May 23, 2003 9:06 AM Subject: Re[2]: Re:MXF Tags Sorry for the late reply. Maybe I should have used the term Essence Description. I could not find matroska tags for "EDL" like timeline description, transition description, Long GOP MPEG indexing, physical archive description etc. Bruce Principal R&I Engineer, Snell & Wilcox, Ltd T: +44 1730 818 714, F: +44 1730 821 199, E: bruce.devlin at snellwilcox.com NUGGETS - using MXF on IP networks, LAN, MAN, WANs. ____________________Reply Separator____________________ Subject: Re: Re:MXF Tags Author: Paul Date: 09/05/2003 16:31 Bruce, I am not sure why you would think that most of the tags are for streaming. Could you give examples? The choice of tags that we use are for a consumer level. We made sure that any tags included in MP3, AVI, WAV, WMV, APE, and a few other formats could be directly imported into the Matroska tag system. Looking over the list of 1000+ tags in your specs, it looked like all Matroska tags would have a place in your tagging system. Feel free to join us on IRC for real time discussion. There are people there almost all times of the day because of the spread accross so many time zones. irc://irc.corecodec.com:6667/matroska Paul Bryson ----- Original Message ----- From: bruce.devlin at snellwilcox.com To: Pamel Sent: Friday, May 09, 2003 8:49 AM Subject: Re:MXF Tags Hi Pamel, MXF is based on SMPTE (Society of Motion Picture and Television Engineers) KLV coding system which in turn is based on ISO ASN.1 coding. The background references and glossary can be found in the SMPTE 377M format specification on http://www.ist-nuggets.tv. Basically, MXF is trying to incorporate professional contribution, distribution and production metadata from the world's broadcasters, film makers and equipment manufactureres. As part of this work, we have being trying to get different standardisation and working groups to talk to each other to prevent wheels being re-invented when existing wheels already work. My hope, in talking to Matroska was that any work we had finalised within our International Standardisation committees would be of use to you in your design. This would mean that when users in a Matroska environment come to interact in an AAF or MXF enviornment then conversion of data is merely syntactical and not a case of converting different modelling philosophies or semantics. Specifically, the extensive tags you have found in DMS-1 come from the fact that people creating content spend a lot of money on location and the metadat information created there is of great value. Metadata about actor so they can be paid and on rights information is so vital, MXF could not survive without it. Looking at your references, many of the tags are streaming related rather than streaming and storage related. Is matroska aimed only at streaming ? best regards Bruce ____________________Reply Separator____________________ Subject: MXF Tags Author: Pamel Date: 16/04/2003 06:10 Bruce, My name is Paul and I have been put in charge of creating the list of information tags(metadata) supported by Matroska. I was curious what kind of system MXF used to see if there was anything that we could use. Because I am working specificaly on tags, I did not look to deeply into how MXF works. The list of tags I found were here: http://www.ist-nuggets.tv/mxf/parked%20for%20Trial%20Publication/S380M-mxf-D MS1-20030331.pdf starting on page 8. What I am most interested is what you seem to call "Finitely Durable Metadata". These would be akin to ID3 tags. However, the tags that I see there seem to be quite extensive, and what most people would refer to as "overkill". Is there a different place that I should refer to? Our tagging system is somewhat expansive because of a goal to support all existing tags in formats currently available. Most of the tags we support will be coming from ID3v2.4, Windows Media Player 9, and Exteneded INFO. More information about these can be found here: http://www.id3.org/develop.html http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwmt/html/ wm_metadata_usage.asp http://kibus1.narod.ru/sof/abcavi/infotags.htm I am curious if the list of metadata tags that you use are specificaly selected for compatability with already defined AAF metadata units, or if you simply selected them on your own. I glanced through some of the AAF documentation, but I was unable to find a list of tags defined specificaly in AAF, but rather some scattered tags defined, and the way to define your own metadata units. Is there a list of predefined metadata units that we could look at to see what else we NEED to support to start some AAF compliancy? That actually leads to my next question of what is required to have this compatability? Matroska doesn't have a way to support all of the possible metadata by track segments in its structure, unless we defined a track for storing that data in. It looks like that is the way that you are doing it, and we may be able to simply copy that DM Track design strait over. However, I am not sure about the compatability. The documents show a Timecode Track also, which is very different from how we align data. We simply attach a timecode to each block of data for each track individualy. Thank you for any answers you can give me. Pamel http://www.matroska.org From moritz at bunkus.org Sat May 24 21:09:17 2003 From: moritz at bunkus.org (Moritz Bunkus) Date: Sat, 24 May 2003 21:09:17 +0200 Subject: [matroska-devel] proposed storage of ssa/ass Message-ID: <20030524190916.GE17418@bunkus.org> Hi. After our talks with Gabest I propose to handle SSA/ASS subtitles like this: First here's a sample: ------------------------------ [Script Info] ; This is a Sub Station Alpha v4 script. ; For Sub Station Alpha info and downloads, ; go to http://www.eswat.demon.co.uk/ ; or email kotus at eswat.demon.co.uk ; ; Note: This file was saved by Subresync. ; ScriptType: v4.00 Collisions: Normal PlayResX: 320 PlayResY: 240 Timer: 100.0000 [V4 Styles] Format: Name, Fontname, Fontsize, PrimaryColour, SecondaryColour, TertiaryColour, BackColour, Bold, Italic, BorderStyle, Outline, Shadow, Alignment, MarginL, MarginR, MarginV, AlphaLevel, Encoding Style: MainB,Arial,14,&H00ffff,&H00ff00,&H000000,&H000000,0,-1,1,2,4,1,16,16,16,0,0 Style: Default,Arial,18,&Hffffff,&H00ffff,&H000000,&H000000,-1,0,1,2,3,2,20,20,20,0,1 Style: MainT,Arial,14,&H00ffff,&H00ff00,&H000000,&H000000,0,0,1,2,4,5,16,16,16,0,0 Style: Karaoke,Arial,14,&H40ffff,&Hff4040,&H000000,&H000000,0,0,1,2,4,5,16,16,16,0,0 Style: B4S4B,Arial,14,&He0e0e0,&H00ff00,&H804000,&H804000,0,-1,1,4,4,5,16,16,40,0,0 Style: B0S0K,Arial,14,&He0e0e0,&H00ff00,&H000000,&H000000,0,-1,1,0,0,5,16,16,40,0,0 Style: B2S2R,Arial,14,&He0e0e0,&H00ff00,&H004080,&H004080,0,-1,1,2,2,5,16,16,40,0,0 Style: B2S6G,Arial,14,&He0e0e0,&H00ff00,&H408000,&H408000,0,-1,1,2,6,5,16,16,40,0,0 Style: ShiftJIS,MS Gothic,20,&He0e0e0,&H00ff00,&H000000,&H000000,0,0,1,2,4,5,16,16,16,0,128 Style: Timer,Arial,14,&H00ffff,&H00ff00,&H000000,&H000000,0,-1,1,2,4,5,16,16,40,0,0 [Events] Format: Marked, Start, End, Style, Name, MarginL, MarginR, MarginV, Effect, Text Dialogue: Marked=0,0:00:00.00,0:00:05.00,MainB,,0000,0000,0000,!Effect,{\q1}Subtitler filter for VirtualDub\NDemonstration script\N\NAvery Lee Dialogue: Marked=0,0:00:05.00,0:00:10.00,MainB,,0000,0000,0000,!Effect,{\q1}Introduction\N\NThis script will demonstrate some of the simpler features of the subtitler. You will want to refer to the {\fnCourier New\b1}readme.txt{\r} file for a more complete reference. Dialogue: Marked=0,0:00:10.00,0:00:21.00,MainB,,0000,0000,0000,!Effect,{\q1}Dialogue lines\N\NScripts are based on dialogue lines. Each dialogue line has a start time, an end time, and text to display in between. Dialogue: Marked=0,0:00:12.00,0:00:15.00,MainT,,0000,0000,0000,!Effect,{\c&H80FF00&}Hello. Dialogue: Marked=0,0:00:16.00,0:00:19.00,MainT,,0000,0000,0000,!Effect,{\c&HE0E0E0&}Oh, hi. Dialogue: Marked=0,0:00:10.00,0:00:12.00,MainT,,0000,0000,0080,!Effect,{\c&H407F00&}[02:00-05:00] Hello. Dialogue: Marked=0,0:00:12.00,0:00:15.00,MainT,,0000,0000,0080,!Effect,{\c&H80FF00&}[02:00-05:00] Hello. Dialogue: Marked=0,0:00:15.00,0:00:21.00,MainT,,0000,0000,0080,!Effect,{\c&H407F00&}[02:00-05:00] Hello. -------------------------- We have two 'parts' in this file: The global info that is only needed once prior to rendering everything, and the lines marked with Dialogue: which are the actual content. So for Matroska the easiest way to store this stuff is: 1. Put the global stuff, and that's ALL lines but the ones with Dialogue: into CodecPrivate unmodified. 2. Take each Dialogue: line, strip off the Dialogue: , and store it in one Matroska block. Read the start time and the end time from that line. You'll have to parse the Format: line in order to know which field is which. Use the start time as the block's timecode. Use the difference between the end time and the start time as the block's duration. The duration is mandatory. Do NOT strip the start time or the end time from that line (*). SSA and ASS files may come as both ASCII and UTF-16 files. My suggestion is to use something similar to S_TEXT/ASCII vs S_TEXT/UTF8 and to introduce S_SSA/ASCII, S_SSA/UTF8, S_ASS/ASCII, S_ASS/UTF8. That way the demuxer knows what format the subs are stored as. (*) I know, for SRT I strip both the start time end the end time from the file and only keep them in the appropriate Matroska members. The reason I do not want to do that here is that for SRT the format looks like this: ---------- 00:01:00.000 --> 00:01:02.250 First line second line etc ---------- So in the SRT case a whole line was obsoleted. For SSA both the start time and the end time are integral parts of each line, so I'd say that removing and adding them again later (you'd also have to modify the Format: line) is not worth the gain of maybe 20k space. -- ==> Ciao, Mosu (Moritz Bunkus) http://www.matroska.org From paul at msn.com Sun May 25 00:44:48 2003 From: paul at msn.com (Pamel) Date: Sat, 24 May 2003 17:44:48 -0500 Subject: [matroska-devel] Re: proposed storage of ssa/ass References: <20030524190916.GE17418@bunkus.org> Message-ID: "Moritz Bunkus" wrote... > So in the SRT case a whole line was obsoleted. For SSA both the start > time and the end time are integral parts of each line, so I'd say that > removing and adding them again later (you'd also have to modify the > Format: line) is not worth the gain of maybe 20k space. I think this might be an issue if you shift, stretch, or append the subtitle stream. You would need an application that could parse SSA to correct all of the timecodes in the SSA text itself. But, if you stripped this information and added it back in on the fly, then you could use any application to do basic editing of the track without understanding SSA. My question then if you did strip timecodes out of the text, would this affect the complex affects? I know nothing about SSA or AAS, but I have heard that you can do some pretty complex effects with them. How does it perform these effects? Does it use timecodes? If so, are they timecodes that are absolute to the stream, or relative to the text you are displaying? Would it make any difference? Would someone that understands this better comment on it? Pamel http://www.matroska.org From steve.lhomme at free.fr Sun May 25 10:53:08 2003 From: steve.lhomme at free.fr (Steve Lhomme) Date: Sun, 25 May 2003 10:53:08 +0200 Subject: [matroska-devel] Queue in the DSF Message-ID: <3ED08474.6030404@free.fr> Hi, Following the long discussion of yesterday concerning subs, I'll summarize how the queue in handled in the DSF to understand how it can be compared to a preload. Inside the filter we have a queue of BlockGroups (that contain one video frame, many audio frames, one sub "frame" with its duration) for each track/output pin. The reading thread reads the Matroska file sequentially (not exactly on load because we look for the Meta Seek entries and the Cue entries) and "flood" each pins with data until one of the queue is blocking (queue full). On the other side of the queue, DirectShow the pins request samples to feed to the peer connected to the pin... So our queue system does a push on one side, and a pull (on request) on the other side. Each queue can block on writing (queue full), block on reading (queue empty), deblock writing (queue is close to be empty) and deblock reading (queue is filled). Each "event" is configurable for each queue through 4 values : - MinWriteThreshold : will deblock writing (queue close to empty) - MaxWriteThreshold : will block writing (queue full) - MinReadThreshold : will block reading (queue empty) - MaxReadThreshold : will deblock reading (queue is filled) These values can be better understood with the following double hysteresis graph (common when you deal with push/pull stuff) : Blocks In Queue ^ | | Write Blocked | | | MaxWrTH -| |>============================>| | | | | | Write Unknown | | | | MinWrTH -| |<============================<| | | | | | | | | | | | Read & Write Allowed | | | | | | | | | | MaxReTH -| |>____________________________>| | | | | | Read Unknown | | | | MinReTH -| |<____________________________<| | | | | Read Blocked | +------------------------------------------------- Write Read The "Unknown" means it can be either Blocked or Allowed. To know if Read/Write is allowed you need to follow the arrows on the Read/Write lines when the queue size grows or decreases. * The best situation would be to have Read & Write allowed all the time. But since we supposedly read faster than we decode, the writing will be blocked at some point. As blocking the Write will also block other pins writing (one thread feeding all queues), it is a good behaviour to deblock writing as quickly as possible (MinWriteThreshold close to MaxWriteThreshold). It will also result in having all queues full most of the time. * We can also see that to have a Read & Write part as large as possible, MinWriteThreshold should be much bigger than MaxReadThreshold. * The MinReadThreshold is determined by the minimum number of BlockGroups needed to decode. For audio, it must be 2 as we use the next Block to calculate the duration of the read audio block (when it's not present in the BlockGroup). For video it is nearly the same (but because of the coding order of B frames it should actually be much more). And for subs, the duration should be written for each BlockGroup, so 1 is enough. * As reading should be blocked as less often as possible, MaxReadThreshold should be as close to MinReadThreshold as possible (maybe +1 or +2). Summary : MinReTH < MaxReTH << MinWrTH < MaxWrTH Now about the default values... Let's consider we want to cache 5s of data (can be roughly seen as preload) (and we suppose reading start afterward) : - video at 25fps : 125 Frames -> 125 Blocks - audio MP3 : 1 frame every 30ms 170 Frames -> 21 Blocks (lacing) - subs : 2 frames -> 2 Blocks That gives an approximation of the MaxWriteThreshold to use : Video (100) = 4x audio (25) should be good, and 10 should be large enough for subs. PS: On a side note I just realised that because of our burst reading system, when reading from a CD drive and because the reading thread has a big priority, reading might take some valuable CPU cycles off of the decoders. When our queue values are properly tweaked, I suggest we try to decrease the priority back to normal to avoid this. http://www.matroska.org From zenprom at blueyonder.co.uk Sun May 25 11:08:11 2003 From: zenprom at blueyonder.co.uk (Keith Staerck) Date: Sun, 25 May 2003 10:08:11 +0100 Subject: [matroska-devel] in depth about matroska Message-ID: <000801c3229d$2a8fc1a0$04d9c250@Keith> i got this information from http://www.matroska.org/ and was wondering if you could please explain 1 thing to me. "It is more like the envelope around several audio, video and subtitles streams, allowing the user to store a complete movie in one single file thats easy to handle, and making sure the audio and video can be played in Mediaplayers on PCs or standalone units in your living room, in perfect sync and with all the comfort you may expect from a modern container format" what does it mean, in perfect sync and how?? Thanks for your help in advance Ben Staerck http://www.matroska.org From steve.lhomme at free.fr Sun May 25 12:33:45 2003 From: steve.lhomme at free.fr (Steve Lhomme) Date: Sun, 25 May 2003 12:33:45 +0200 Subject: [matroska-devel] Re: in depth about matroska In-Reply-To: <000801c3229d$2a8fc1a0$04d9c250@Keith> References: <000801c3229d$2a8fc1a0$04d9c250@Keith> Message-ID: <3ED09C09.9090302@free.fr> Keith Staerck wrote: > i got this information from http://www.matroska.org/ and was wondering if you could please explain 1 thing to me. > > "It is more like the envelope around several audio, video and subtitles streams, allowing the user to store a complete movie in one single file thats easy to handle, and making sure the audio and video can be played in Mediaplayers on PCs or standalone units in your living room, in perfect sync and with all the comfort you may expect from a modern container format" > > what does it mean, in perfect sync and how?? That means the audio and video streams are always synchronised. When someone talks, you would expect the picture of the lips moving to be moving accordingly to the sound you hear. How is it done in matroska ? Every piece of audio (samples) and video (frames) have a timecode. So even if you get just one part of a file, the data still know where they are in time and can be perfectly synched. I hope it's a bit clearer. http://www.matroska.org From chris at matroska.org Sun May 25 13:30:30 2003 From: chris at matroska.org (Christian HJ Wiesner) Date: Sun, 25 May 2003 13:30:30 +0200 Subject: [matroska-devel] Re: in depth about matroska In-Reply-To: <000801c3229d$2a8fc1a0$04d9c250@Keith> References: <000801c3229d$2a8fc1a0$04d9c250@Keith> Message-ID: <3ED0A956.7090102@matroska.org> Ken, whenever you play a movie on your PC, without even noticing it, you are playing a video stream and an audio stream. As it is not very practible to have to handle 2 different files for that, lets say an MP3 audio file and another file containing the video, you pack both into a single file by using a so-called container, comparable to a ZIP file. This container has a lot of functions, as there has to be some software, being called a 'splitter' or 'parser' that will care about the correct timing of the audio and video playback when the file is played ( opened ). ZIP could be a container to pack one or more audio/video streams together into one single file for distribution, but WinZIP certainly wouldnt care about the correct timing of the these streams on playback. Usual containers are the good old AVI ( most DivX movies you will get will have an .avi extension ), or the MPEG container ( .mpg. .mpeg ), Quicktime ( .mov ), Realmedia ( .rm ), MP4 ( .mp4 ), etc. . matroska is a free, opensource alternative to all of them, and aiming to be able to offer a lot of features that others dont have have ( look at our homepage again ). Christian Keith Staerck wrote: >i got this information from http://www.matroska.org/ and was wondering if you could please explain 1 thing to me. > >"It is more like the envelope around several audio, video and subtitles streams, allowing the user to store a complete movie in one single file thats easy to handle, and making sure the audio and video can be played in Mediaplayers on PCs or standalone >units in your living room, in perfect sync and with all the comfort you may expect from a modern container format" > >what does it mean, in perfect sync and how?? > >Thanks for your help in advance > >Ben Staerck >http://www.matroska.org > > > http://www.matroska.org From steve.lhomme at free.fr Sun May 25 14:01:23 2003 From: steve.lhomme at free.fr (Steve Lhomme) Date: Sun, 25 May 2003 14:01:23 +0200 Subject: [matroska-devel] Re: in depth about matroska In-Reply-To: <3ED0A956.7090102@matroska.org> References: <000801c3229d$2a8fc1a0$04d9c250@Keith> <3ED0A956.7090102@matroska.org> Message-ID: <3ED0B093.6090500@free.fr> Christian HJ Wiesner wrote: > Ken, It's either Keith or Ben, but not Ken ;) > Keith Staerck wrote: >> >>Ben Staerck >>http://www.matroska.org http://www.matroska.org From steve.lhomme at free.fr Sun May 25 16:11:40 2003 From: steve.lhomme at free.fr (Steve Lhomme) Date: Sun, 25 May 2003 16:11:40 +0200 Subject: [matroska-devel] CoreVorbis ? Message-ID: <3ED0CF1C.50205@free.fr> It seems we are now able to solve all the problems we have about jerkiness in the DirectShow filter. The version in CVS (close to the version released yesterday) can play many files without having a single blocking on the reading part. That means buffer are "instantly" given to the pin when it requests data. However, the Vorbis DirectShow filter seem to be unable to fill the audio renderer at more than 40%, while the MP3 decoder is fixed at 90%. Apparently it's a problem on this particular filter... Toff also mentioned that some samples coming from the OggDS filter have a 0 duration. Maybe this trick is needed too to make the Vorbis filter work fine. But this is not a good way of doing things. We have 2 choices : - let Xiph know about this problem and correct it. - make our own filter to decode Vorbis. I think we should go for the 1st option for the moment. And if nothing passes (than just possible promises) we can make our own filter. Christian could you contact them ? Or BlackSun ? Betaboy ? http://www.matroska.org From christophe.paris at free.fr Sun May 25 18:45:38 2003 From: christophe.paris at free.fr (Christophe PARIS) Date: Sun, 25 May 2003 18:45:38 +0200 Subject: [matroska-devel] Re: CoreVorbis ? In-Reply-To: <3ED0CF1C.50205@free.fr> References: <3ED0CF1C.50205@free.fr> Message-ID: Steve Lhomme wrote: > However, the Vorbis DirectShow filter seem to be unable to fill the > audio renderer at more than 40%, while the MP3 decoder is fixed at 90%. > Apparently it's a problem on this particular filter... I don't think this is causing the jerkiness. The buffer is at 40% but never fall under 35%. And there is the same behaviour with the OggDS splitter. > Toff also mentioned that some samples coming from the OggDS filter have > a 0 duration. Maybe this trick is needed too to make the Vorbis filter > work fine. But this is not a good way of doing things. Here is an extract of timestamps we get in different scenari : Video : 720x416 @ 25fps, Xvid (average bitrate 2533 kb/s) Audio : 2x48Khz Vorbis (96 kb/s) 1) OGM (muxed with vdubmod) =========================== a) Timestamps at the output of the OGM Splitter: TIME start: 0, end: 0 dur: 0 size: 30 <-+ vorbis TIME start: 0, end: 0 dur: 0 size: 112 <-+ | TIME start: 0, end: 0 dur: 0 size: 3796 <-+ headers TIME start: 0, end: 0 dur: 0 size: 53 TIME start: 26667, end: 26667 dur: 0 size: 62 TIME start: 146667, end: 146667 dur: 0 size: 255 TIME start: 360000, end: 360000 dur: 0 size: 238 TIME start: 573333, end: 573333 dur: 0 size: 229 TIME start: 786667, end: 786667 dur: 0 size: 237 TIME start: 1000000, end: 1000000 dur: 0 size: 242 TIME start: 1213333, end: 1213333 dur: 0 size: 224 TIME start: 1426667, end: 1426667 dur: 0 size: 227 TIME start: 1640000, end: 1640000 dur: 0 size: 220 b) Timestamps at the output of the vorbis decoder: TIME start: 0, end: 26667 dur: 26667 size: 1024 TIME start: 26667, end: 146667 dur: 120000 size: 4608 TIME start: 146667, end: 360000 dur: 213333 size: 8192 TIME start: 360000, end: 573333 dur: 213333 size: 8192 TIME start: 573333, end: 786667 dur: 213334 size: 8192 TIME start: 786667, end: 1000000 dur: 213333 size: 8192 TIME start: 1000000, end: 1213333 dur: 213333 size: 8192 TIME start: 1213333, end: 1426667 dur: 213334 size: 8192 TIME start: 1426667, end: 1640000 dur: 213333 size: 8192 TIME start: 1640000, end: 1853333 dur: 213333 size: 8192 2) MKV (muxed with vdubmod, lacing disabled) ============================================ a) Timestamps at the output of the Matroska Splitter: TIME start: 0, end: 0 dur: 0 size: 30 <-+ vorbis TIME start: 0, end: 0 dur: 0 size: 112 <-+ | TIME start: 0, end: 0 dur: 0 size: 3796 <-+ headers TIME start: 0, end: 10000 dur: 10000 size: 53 TIME start: 10000, end: 40000 dur: 30000 size: 62 TIME start: 40000, end: 160000 dur: 120000 size: 255 TIME start: 160000, end: 370000 dur: 210000 size: 238 TIME start: 370000, end: 590000 dur: 220000 size: 229 TIME start: 590000, end: 800000 dur: 210000 size: 237 TIME start: 800000, end: 1010000 dur: 210000 size: 242 TIME start: 1010000, end: 1230000 dur: 220000 size: 224 TIME start: 1230000, end: 1440000 dur: 210000 size: 227 TIME start: 1440000, end: 1650000 dur: 210000 size: 220 b) Timestamps at the output of the vorbis decoder: TIME start: 0, end: 10000 dur: 10000 size: 384 TIME start: -80000, end: 40000 dur: 120000 size: 4608 <-- ??? TIME start: -53333, end: 160000 dur: 213333 size: 8192 <-- ??? TIME start: 156667, end: 370000 dur: 213333 size: 8192 TIME start: 376667, end: 590000 dur: 213333 size: 8192 TIME start: 586667, end: 800000 dur: 213333 size: 8192 TIME start: 796667, end: 1010000 dur: 213333 size: 8192 TIME start: 1016667, end: 1230000 dur: 213333 size: 8192 TIME start: 1226667, end: 1440000 dur: 213333 size: 8192 TIME start: 1436667, end: 1650000 dur: 213333 size: 8192 TIME start: 1656667, end: 1870000 dur: 213333 size: 8192 3) MKV (muxed with vdubmod, with lacing) ======================================== a) Timestamps at the output of the Matroska Splitter: TIME start: 0, end: 0 dur: 0 size: 30 <-+ vorbis TIME start: 0, end: 0 dur: 0 size: 112 <-+ | TIME start: 0, end: 0 dur: 0 size: 3796 <-+ headers TIME start: 0, end: 153750 dur: 153750 size: 53 TIME start: 153750, end: 307500 dur: 153750 size: 62 TIME start: 307500, end: 461250 dur: 153750 size: 255 TIME start: 461250, end: 615000 dur: 153750 size: 238 TIME start: 615000, end: 768750 dur: 153750 size: 229 TIME start: 768750, end: 922500 dur: 153750 size: 237 TIME start: 922500, end: 1076250 dur: 153750 size: 242 TIME start: 1076250, end: 1230000 dur: 153750 size: 224 TIME start: 1230000, end: 1442500 dur: 212500 size: 227 TIME start: 1442500, end: 1655000 dur: 212500 size: 220 b) Timestamps at the output of the vorbis decoder: TIME start: 127083, end: 153750 dur: 26667 size: 1024 TIME start: 187500, end: 307500 dur: 120000 size: 4608 TIME start: 247917, end: 461250 dur: 213333 size: 8192 TIME start: 401667, end: 615000 dur: 213333 size: 8192 TIME start: 555417, end: 768750 dur: 213333 size: 8192 TIME start: 709167, end: 922500 dur: 213333 size: 8192 TIME start: 862917, end: 1076250 dur: 213333 size: 8192 TIME start: 1016667, end: 1230000 dur: 213333 size: 8192 TIME start: 1229167, end: 1442500 dur: 213333 size: 8192 TIME start: 1441667, end: 1655000 dur: 213333 size: 8192 TIME start: 1654167, end: 1867500 dur: 213333 size: 8192 Regards Toff http://www.matroska.org From chris at matroska.org Sun May 25 21:59:55 2003 From: chris at matroska.org (Christian HJ Wiesner) Date: Sun, 25 May 2003 21:59:55 +0200 Subject: [matroska-devel] Re: CoreVorbis ? In-Reply-To: References: <3ED0CF1C.50205@free.fr> Message-ID: <3ED120BB.4030006@matroska.org> Toff, how about making a conclusion for non-technical people like me ? Do we need a new Vorbis decoder filter ? Or can we fix it from the parser, by changing the behaviour ? After all, we should still consider looking at Ingo's filter pack, this way we had playback support for - Vorbis - FLAC - Monkey ( .ape ) - etc. We should talk to Ingo aabout that, also as it seems he is reading our list occasionally again .. Christian Christophe PARIS wrote: >Steve Lhomme wrote: > >>owever, the Vorbis DirectShow filter seem to be unable to fill the >>audio renderer at more than 40%, while the MP3 decoder is fixed at 90%. >>Apparently it's a problem on this particular filter... >> >> >I don't think this is causing the jerkiness. >The buffer is at 40% but never fall under 35%. >And there is the same behaviour with the OggDS splitter. > > > >>Toff also mentioned that some samples coming from the OggDS filter have >>a 0 duration. Maybe this trick is needed too to make the Vorbis filter >>work fine. But this is not a good way of doing things. >> >> > >Here is an extract of timestamps we get in different scenari : > >Video : 720x416 @ 25fps, Xvid (average bitrate 2533 kb/s) >Audio : 2x48Khz Vorbis (96 kb/s) > >1) OGM (muxed with vdubmod) >=========================== > > a) Timestamps at the output of the OGM Splitter: > > b) Timestamps at the output of the vorbis decoder: > > > >2) MKV (muxed with vdubmod, lacing disabled) >============================================ > > a) Timestamps at the output of the Matroska Splitter: > > b) Timestamps at the output of the vorbis decoder: > > > >3) MKV (muxed with vdubmod, with lacing) >======================================== > > a) Timestamps at the output of the Matroska Splitter: > > b) Timestamps at the output of the vorbis decoder: > >Regards Toff > > http://www.matroska.org From steve.lhomme at free.fr Sun May 25 23:10:00 2003 From: steve.lhomme at free.fr (Steve Lhomme) Date: Sun, 25 May 2003 23:10:00 +0200 Subject: [matroska-devel] Re: CoreVorbis ? In-Reply-To: <3ED120BB.4030006@matroska.org> References: <3ED0CF1C.50205@free.fr> <3ED120BB.4030006@matroska.org> Message-ID: <3ED13128.1080507@free.fr> Christian HJ Wiesner wrote: > Toff, > > how about making a conclusion for non-technical people like me ? Do we > need a new Vorbis decoder filter ? Or can we fix it from the parser, by > changing the behaviour ? Apparently, from what I see in the case of lacing we give it the correct data, the start timecodes are a bit different... And in the end the timecodes are overlapping (at least for the first 7 frames) which is really not good ! Apparently this is due to the twisted Vorbis world. As you can see OggDS gives Start=End timecodes. And the decoder uses the End timecode + duration to calculate the start timecodes... (timecodes in OGG/Vorbis represent the end timecode) But in our case (matroska), the timecode is the one of the start which is the more accurate. If we trick our DSF and put Start=End it might produce better results (just a delay removed and less overlapping when the frame size changes). But still it doesn't say why the Vorbis DSF is unable to fill the audio renderer more than 40%... http://www.matroska.org From christophe.paris at free.fr Sun May 25 23:38:16 2003 From: christophe.paris at free.fr (Christophe PARIS) Date: Sun, 25 May 2003 23:38:16 +0200 Subject: [matroska-devel] Re: CoreVorbis ? In-Reply-To: <3ED13128.1080507@free.fr> References: <3ED0CF1C.50205@free.fr> <3ED120BB.4030006@matroska.org> <3ED13128.1080507@free.fr> Message-ID: > But still it doesn't say why the Vorbis DSF is unable to fill the audio > renderer more than 40%... It's probably using a unique output buffer, so DirectShow doesn't have more space for more data. There is the same behavior with the AAC decoder. Changing the number of buffer in the decoder fix this issue. But this is not what is causing the jerkiness. But it could be usefull with the waveout renderer. Regards Toff http://www.matroska.org From chris at wiesneronline.net Sun May 25 23:41:08 2003 From: chris at wiesneronline.net (Christian HJ Wiesner) Date: Sun, 25 May 2003 23:41:08 +0200 Subject: [matroska-devel] Ogg Vorbis DirectShow decoder filter - ongoing development ? In-Reply-To: <3ED0CF1C.50205@free.fr> References: <3ED0CF1C.50205@free.fr> Message-ID: <3ED13874.6030004@wiesneronline.net> Hi, some of you may know me, i am one of the project admins of a video related opensource project. For playback of Vorbis audio tracks in movies, if being played on M$ via DirectShow, we are currently using the Vorbis decoder filter from Tobias Waldvogel. However, we found out that this decoder filter is not acting DirectShow compliant with respect to handling of timestamps. When passing the data from the Ogg/OGM parser/splitter filter this is no issue as both are probably synced very well internally, but if the filter shall be used from other splitters such as AVI/MP4/MPEG, problems will occur. The purpose of this email is to find out if there is any ongoing development for a new Vorbis decoder filter for M$ DirectShow, which will be more compliant with respect to timestamp handling. If this is the case, we would be glad to contribute. If this is not the case, we will consider writing a new decoder filter, being open source but under a GPL license ( we will reuse code from other GPL filters as basement ). Please note that due to time constraints we dont have plans to write an opensource Ogg splitter/parser also, nor do we have plans for an Ogg muxer filter. Thanks for telling us if there are any plans into this direction or not. Best regards Christian P.S. We are also talking to Ingo Ralf Blum, the developer of the MediaXW DShow filter package, the first working Vorbis decoder filter ever, to find out if his filter could be an alternative. http://www.matroska.org From steve.lhomme at free.fr Sun May 25 16:19:32 2003 From: steve.lhomme at free.fr (Steve Lhomme) Date: Sun, 25 May 2003 16:19:32 +0200 Subject: [matroska-devel] Codec API Message-ID: <3ED0D0F4.8000209@free.fr> As we know there is a need for a more portable codec API that could support more features of modern codec (like B frames, multi-in/multi-out, etc). It seems a good solution is to have one function to call with messages... But guess what ? That's what ACM and VCM support ! And these APIs are open ! We could add new messages that regular ACM/VCM could discard (like VCM_GET_FRAME_EXTRA_INFO to have a codec state or reference dependencies) ! So instead of creating a new API from the start we have to integrate, we could reuse the MS one and extend it... We can call these filter ACMex and VCMex... What do you think ? http://www.matroska.org From ingoralfblum at gmx.de Sun May 25 19:07:01 2003 From: ingoralfblum at gmx.de (Ingo Ralf Blum) Date: Sun, 25 May 2003 19:07:01 +0200 Subject: [matroska-devel] Re: Codec API References: <3ED0D0F4.8000209@free.fr> Message-ID: <58tqab.c5c.ln@server.ingoralfblum.com> > It seems a good solution is to have one function to call with > messages... But guess what ? That's what ACM and VCM support ! And these > APIs are open ! We could add new messages that regular ACM/VCM could > discard (like VCM_GET_FRAME_EXTRA_INFO to have a codec state or > reference dependencies) ! > > So instead of creating a new API from the start we have to integrate, we > could reuse the MS one and extend it... We can call these filter ACMex > and VCMex... What do you think ? Why don't you use the DirectShow interfaces instead? They have already more capabilities than thos awkward multimedia driver architecture and you can extend them simply by adding new or derived interfaces. Regards, Ingo http://www.matroska.org From steve.lhomme at free.fr Sun May 25 19:37:43 2003 From: steve.lhomme at free.fr (Steve Lhomme) Date: Sun, 25 May 2003 19:37:43 +0200 Subject: [matroska-devel] Re: Codec API In-Reply-To: <58tqab.c5c.ln@server.ingoralfblum.com> References: <3ED0D0F4.8000209@free.fr> <58tqab.c5c.ln@server.ingoralfblum.com> Message-ID: <3ED0FF67.2090507@free.fr> Ingo Ralf Blum wrote: >>It seems a good solution is to have one function to call with >>messages... But guess what ? That's what ACM and VCM support ! And these >>APIs are open ! We could add new messages that regular ACM/VCM could >>discard (like VCM_GET_FRAME_EXTRA_INFO to have a codec state or >>reference dependencies) ! >> >>So instead of creating a new API from the start we have to integrate, we >>could reuse the MS one and extend it... We can call these filter ACMex >>and VCMex... What do you think ? > > > Why don't you use the DirectShow interfaces instead? They have already more > capabilities than thos awkward multimedia driver architecture and you can > extend them simply by adding new or derived interfaces. Hey Ingo !!! Nice to see you around :) Yes, DirectShow could be an option... If it was not based on COM. COM is of course theoretically portable, but IMO it's too complicated for just a codec. Even though I worked a lot of the matroska DSF, I still haven't understood a lot about DirectShow. It's too complex for my little brain ;) http://www.matroska.org From ingoralfblum at gmx.de Sun May 25 22:47:19 2003 From: ingoralfblum at gmx.de (Ingo Ralf Blum) Date: Sun, 25 May 2003 22:47:19 +0200 Subject: [matroska-devel] Re: Codec API References: <3ED0D0F4.8000209@free.fr> <58tqab.c5c.ln@server.ingoralfblum.com> <3ED0FF67.2090507@free.fr> Message-ID: <65arab.7cc.ln@server.ingoralfblum.com> > Yes, DirectShow could be an option... If it was not based on COM. COM is > of course theoretically portable, but IMO it's too complicated for just > a codec. Even though I worked a lot of the matroska DSF, I still haven't > understood a lot about DirectShow. It's too complex for my little brain ;) Nobody said, that you need a full COM implementation. Just some means of activating an object (load DLL and create an instance) which you need anyways. If you just use DMOs you probably don't even need a single CoXXX function implemented. The greatest task is some sort of registry. Of course you could just use a file, preferably XML or, if you want, EBML. That shouldn't be much more work than two days for a working component activation and registration implementation. Regards, Ingo http://www.matroska.org From chris at wiesneronline.net Mon May 26 07:22:28 2003 From: chris at wiesneronline.net (Christian HJ Wiesner) Date: Mon, 26 May 2003 07:22:28 +0200 Subject: [matroska-devel] Re: Ogg Vorbis DirectShow decoder filter - ongoing development ? In-Reply-To: <3ED13B9F.4080007@gmx.net> References: <3ED0CF1C.50205@free.fr> <3ED13874.6030004@wiesneronline.net> <3ED13B9F.4080007@gmx.net> Message-ID: <3ED1A494.3090302@wiesneronline.net> Dark Avenger wrote: > Hmm, has Tobias stopped development of his filter or why doesn't he want > to correct this? I guess that would be the easist solution. The last thing we heard from Tobias was the announcement from Emmet that he has joined the Xiph Team as Theora developer officially, and that the sources of his DirectShow filter would be uploaded to Xiph CVS. Since then nobody, not even his personal friend Ludovic 'Blacksun' Vialle, has heard from him again, it seems he is facing some severe RLIs. And yes, developement on the filter seems to have stalled since then. Maybe about time to consider supporting the most used Multimedia OS with a general and official Vorbis/Ogg DirectShow filter from Xiph' site ? Christian http://www.matroska.org From chris at wiesneronline.net Mon May 26 12:15:19 2003 From: chris at wiesneronline.net (Christian HJ Wiesner) Date: Mon, 26 May 2003 12:15:19 +0200 Subject: [matroska-devel] Re: Ogg Vorbis DirectShow decoder filter - ongoing development ? In-Reply-To: <20030526072123.GG31237@i.cantcode.com> References: <3ED0CF1C.50205@free.fr> <3ED13874.6030004@wiesneronline.net> <3ED13B9F.4080007@gmx.net> <3ED1A494.3090302@wiesneronline.net> <20030526072123.GG31237@i.cantcode.com> Message-ID: <3ED1E937.2090508@wiesneronline.net> Hi Jack, Jack Moffitt wrote: >>The last thing we heard from Tobias was the announcement from Emmet that >>he has joined the Xiph Team as Theora developer officially, and that the >>sources of his DirectShow filter would be uploaded to Xiph CVS. > I don't remmber this. Do you have a url to a message in the archive for > this? Or was this only announced in IRC? Yes, it was announced on IRC. > Afaict, Tobias only posted _once_ on any vorbis mailing list, and has > never responded to anyone's emails. Thats correct, he replied to some of my early emails, but then never again. Maybe the success of his set of filters was not expected by him in this way, and he as simply not capable of handling the huge number of emails he must have got. >>Since then nobody, not even his personal friend Ludovic 'Blacksun' >>Vialle, has heard from him again, it seems he is facing some severe >>RLIs. And yes, developement on the filter seems to have stalled since >>then. Maybe about time to consider supporting the most used Multimedia >>OS with a general and official Vorbis/Ogg DirectShow filter from Xiph' >>site ? > This is depressing. That leaves us one half way decent closed source > set of filters, and one totally awful set of open source ones. Both > abandoned. Where are the opensource sets your are mentioning ? Maybe we can progress from there ? > Would any of you win32 nuts like to help fund an official set of > plugins? I have some pointers on reliable people to do the work. > jack. LOL ! I never knew i am a 'win32 nut' , but maybe i ever have been one without noticing :) ? Anyway, if we can help, just give us a shout. If we dont hear from you guys within the next 2 weeks, we simply start with the Vorbis decoder based on some GPL skeleton code we have done already ( for CoreAAC BTW, an opensource AAC Dshow filter ). Another thing : If you plan to make a set of filters of your own, was it possible to get CVS write access for at least one of our devs, so we can upload patches easier ? Regards Christian http://www.matroska.org From christophe.paris at free.fr Tue May 27 02:15:49 2003 From: christophe.paris at free.fr (Christophe PARIS) Date: Tue, 27 May 2003 02:15:49 +0200 Subject: [matroska-devel] A mkxds bug Message-ID: Hi, A moment ago i was trying some mkv samples and by "chance" one didn't want to render properly, i had the following graph : +---------------------+ +---------+ +----------------+ | mymovie.mkv Video 1+------>+ ffdshow +------>+ Video Renderer | | Audio 2+ +---------+ +----------------+ +---------------------+ In fact i was missing the proper codec for the audio track. But why, oh why, the video was not playing correctly ? It was only playing for few seconds at the beginning and after each seek. I came to the conclusion that there was something wrong with the matroska demuxer ;). When an output pin is not connected we are sending blocks to the queue of the pin anyway (mistake detected). But as the pin is not connected there is no blocks' consumption and when the queue is full it's blocking the reading thread and all the video track as well. Strangely i've notice the same type of behaviour with the integrated MPC stream switcher. It is probably not consuming the audio sample of the disabled stream to avoid wasting CPU use (Gabest should be able to confirm that). I haven't tested with mmswitch. That's all! :) Regards Toff http://www.matroska.org From christophe.paris at free.fr Tue May 27 18:17:36 2003 From: christophe.paris at free.fr (Christophe PARIS) Date: Tue, 27 May 2003 18:17:36 +0200 Subject: [matroska-devel] Re: A mkxds bug In-Reply-To: References: Message-ID: I've made some test with mmswitch and the problem is a bit different than with MPC. With MPC's integrated audio switcher there is no way to see if a track is "disabled". But with mmswitch the method that deliver the sample fail in this case. The problem is that the Deliver method take place in the BaseClasses (CSourceStream) and it seems there is no way to be informed of the failure. Moreover the pin worker thread doesn't terminate. So we continue to fill the queue of the pin until it's full which finally block the reader thread. We need to correct this problem to have stream switching working. Regards Toff > Strangely i've notice the same type of behaviour with the integrated MPC > stream switcher. It is probably not consuming the audio sample of the > disabled stream to avoid wasting CPU use (Gabest should be able to > confirm that). I haven't tested with mmswitch. http://www.matroska.org From chris at matroska.org Tue May 27 12:11:49 2003 From: chris at matroska.org (Christian HJ Wiesner) Date: Tue, 27 May 2003 12:11:49 +0200 Subject: [matroska-devel] Vorbis DMO decoder filter - was : Re: Bug ist jetzt gepatcht In-Reply-To: References: Message-ID: <3ED339E5.4080901@matroska.org> Guys, i have been in contact with Ingo ( in German ) about the problem we have with the Vorbis DirectShow decoder filters. Ingo says that we 2 options : - use his MediaXW filters - he will write a simply DMO decoder filter for us, which will suffice for what we want it to do. He also said he could write an ENcoder filter also, but i dont think we would really need one, as we dont have a MKV muxer filter also. When talking to Toff about this yesterday he mentioned he wants to write a general use Vorbis decoder filter in any case ( i guess he has smelled the sweetness of fame now, since Doom9 put his CoreAAC filter on the top of the news page ;) ). So, we find ourselves in the nice situation now that all of a sudden we have more options than really necessary ... LOL ! Here my questions to both Ingo and Toff : - would you make your filter code open ? Pls. note that, as we are an OSS project ourselves we would probably prefer this. - what license would you plan to use ? We discussed using GPL for that, which IMHO was a good thing to do to avoid that companies abuse the filter code for their purposes. - would the filters support multichannel decoding ( 5.1 ) also ? - what GUID/wFormat tag would you guys use ? - would be be allowed to host the filter on corecodec.org ? - with respect to the upcoming multi-language support from the matroska parser filter ( via opensource Morgan multimedia switcher ), will a DMO work here also ? Last, but maybe most important question : - is it possible that you guys work together, to save everybodie's time ? Or do you prefer to work alone ? Thanks guys for a quick answer to the matroska-devel ML. Regards Christian Ingo Ralf Blum wrote: >>Das w?rde bedeuten wir m?ssten ein neues decoder filter >>programmieren :( ....... es sei denn wir finden eine >>andere L?sung, evtl. mit Deinen Filtern ? W?re das >>m?glich ? >> >> > >Hallo Christian, > >ich w?rde vorschlagen zwei DMOs zur >Kompression/Dekompression zu schreiben. Meine existierenden >Filter funktionieren zwar auch aber DMOs sind f?r den Zweck >besser zu gebrauchen. Wenn Du willst kann ich das machen. >Zeitaufwand w?re ca. 2 Tage. Diese Woche habe ich keine >Zeit, da ich voraussichtlich von Do. bis So. am >Gro?glockner zelten bin. Ab Do. den 5.6. werde ich im Labor >messen, d.h. im Wesentlichen dem Computer beim messen >zuschauen, so da? ich dann die DMOs nebenher schreiben >k?nnte. > >Gr??e, > >Ingo > > > http://www.matroska.org From christophe.paris at free.fr Tue May 27 13:04:40 2003 From: christophe.paris at free.fr (Christophe PARIS) Date: Tue, 27 May 2003 13:04:40 +0200 Subject: [matroska-devel] Re: Vorbis DMO decoder filter - was : Re: Bug ist jetzt gepatcht In-Reply-To: <3ED339E5.4080901@matroska.org> References: <3ED339E5.4080901@matroska.org> Message-ID: Christian HJ Wiesner wrote: > When talking to Toff about this yesterday he mentioned he wants to write > a general use Vorbis decoder filter in any case ( i guess he has smelled > the sweetness of fame now, since Doom9 put his CoreAAC filter on the top > of the news page ;) ). lol, no it's just that i know how to do it, but there is no need for 2 implementation. > - would you make your filter code open ? Pls. note that, as we are an > OSS project ourselves we would probably prefer this. Open source of course. > - what license would you plan to use ? We discussed using GPL for that, > which IMHO was a good thing to do to avoid that companies abuse the > filter code for their purposes. Bah, there is not much code to abuse, it's mostly a wrapper around libvorbis. > - would the filters support multichannel decoding ( 5.1 ) also ? If libvorbis support it yes. > - what GUID/wFormat tag would you guys use ? For the format i was planning to use something very simple like that : typedef struct { WORD nChannels; DWORD nSamplesPerSec; DWORD nBitsPerSample; DWORD HeaderSize[3]; // 0: Identification, 1: Comment, 2: Setup } VORBISFORMAT2; And append the 3 vorbis headers after this struct. > - with respect to the upcoming multi-language support from the matroska > parser filter ( via opensource Morgan multimedia switcher ), will a DMO > work here also ? A DMO will use the directshow DMO wrapper so there i not much difference between a normal decoder filter, but i don't know much about DMO. > Last, but maybe most important question : > - is it possible that you guys work together, to save everybodie's time > ? Or do you prefer to work alone ? I don't know if there is enough work for 2 persons ;) I was planning to use the directshow base classes (CTransformFilter) so there is in fact less or the same amount of work compared to a DMO. Best Regards, Toff http://www.matroska.org From steve.lhomme at free.fr Tue May 27 23:26:38 2003 From: steve.lhomme at free.fr (Steve Lhomme) Date: Tue, 27 May 2003 23:26:38 +0200 Subject: [matroska-devel] Tags code update Message-ID: <3ED3D80E.8050208@free.fr> To Jory (and the rest) : I updated the Tags code with the additional layers I added in the MultiXXX elements. (I hope I didn't make anything wrong with all my copy/paste). http://www.matroska.org From chris at matroska.org Wed May 28 12:22:16 2003 From: chris at matroska.org (Christian HJ Wiesner) Date: Wed, 28 May 2003 12:22:16 +0200 Subject: [matroska-devel] Spec change proposal : deleting codec IDs for subs, adding new ones Message-ID: <3ED48DD8.5090200@matroska.org> Hi, as discussed on IRC today with robux4 , Toff and Mosu we will change the specs soon, more precisely one codec ID will be dropped, being S_TEXT/ASCII It will be fully replaced by S_TEXT/UTF8 . Cyrius was never using this codec ID from VdubMod, so there shouldnt be any files created on Windows with this ID, and for Mosu's mkvmerger it needed a special switch as he was using S_TEXT/UTF8 also by default . We know very well that we are breaking compatibillity with elder files created on LInux, where users decided to mux using this ID, but we estimate the number is very very small ( if there are any ) and we can simply help those people by remuxing the questionary files in mkvmerger, when codec ID will be changed to S_TEXT/UTF8 and char set be analyzed. In addition to that, we will add/alter 2 new codec IDs : S_SSA will become S_TEXT/SSA and S_ASS will become S_TEXT/ASS as both subtitles formats are only text based, and to match with our current terminology. We will also add S_TEXT/USF and S_IMAGE/USF If you have any objections to doing that pls. tell me, if not we will make the changes tonight and they become effective. Regards Christian http://www.matroska.org From Liisachan at faireal.net Wed May 28 12:50:53 2003 From: Liisachan at faireal.net (Liisachan) Date: Wed, 28 May 2003 19:50:53 +0900 Subject: [matroska-devel] Re: Spec change proposal : deleting codec IDs for subs, adding new ones In-Reply-To: <3ED48DD8.5090200@matroska.org> References: <3ED48DD8.5090200@matroska.org> Message-ID: <3ED4948D.5080004@faireal.net> Christian HJ Wiesner wrote: >In addition to that, we will add/alter 2 new codec IDs : > >S_SSA will become S_TEXT/SSA > >and > >S_ASS will become S_TEXT/ASS > >as both subtitles formats are only text based, and to match with our >current terminology. > > I have no objections but just in case, please let me note that SSAs can have any binary data such as font data or even images, embedded w UUEncoding. They are of course text based in SSA, as you said. If there is a way at all to store font data in Matroska for subs, it would be more efficient and reasonable to store it as binary, not as text, as it is in SSA, because encoding into ascii will make font data 30~40% bigger in SSA and Font data can be like 1MB, which means like 300KB can be meaninglessly wasted. So... maybe SSA should be stored partly as text, partly as binary (which is decoded from a part of original SSA) Liisachan http://www.matroska.org From Liisachan at faireal.net Wed May 28 12:56:59 2003 From: Liisachan at faireal.net (Liisachan) Date: Wed, 28 May 2003 19:56:59 +0900 Subject: [matroska-devel] Re: Spec change proposal : deleting codec IDs for subs, adding new ones In-Reply-To: <3ED4948D.5080004@faireal.net> References: <3ED48DD8.5090200@matroska.org> <3ED4948D.5080004@faireal.net> Message-ID: <3ED495FB.3070609@faireal.net> Liisachan wrote: >So... maybe SSA should be stored partly as text, partly as binary (which >is decoded from a part of original SSA) > > "the text part" is S_TEXT anyways, so this does not mean that anything is wrong with changing the spec as is proposed. http://www.matroska.org From steve.lhomme at free.fr Wed May 28 16:33:52 2003 From: steve.lhomme at free.fr (Steve Lhomme) Date: Wed, 28 May 2003 16:33:52 +0200 (CEST) Subject: [matroska-devel] Re: Spec change proposal : deleting codec IDs for subs, adding new ones In-Reply-To: <3ED48DD8.5090200@matroska.org> References: <3ED48DD8.5090200@matroska.org> Message-ID: <1054132432.3ed4c8d097a35@imp.free.fr> En r?ponse ? Christian HJ Wiesner : > We will also add > > S_TEXT/USF > > and > > S_IMAGE/USF As Liisachan pointed out, what is the reason for a S_TEXT/S_IMAGE split ? One is binary and the other is only text ? Maybe S_USF ans S_EBML_USF would make more sense. The S already says it's a sub... http://www.matroska.org From chris at matroska.org Wed May 28 13:48:51 2003 From: chris at matroska.org (Christian HJ Wiesner) Date: Wed, 28 May 2003 13:48:51 +0200 Subject: [matroska-devel] Bug or feature : VdubMod doesnt alllow the audio stream to be longer than the video ? Message-ID: <3ED4A223.2070508@matroska.org> Hi guys, http://forum.doom9.org/showthread.php?s=&threadid=54324 any comments on that ? For the moment i am not 100% sure here, but i guess our specs would allow different length of tracks ? Christian http://www.matroska.org From steve.lhomme at free.fr Wed May 28 16:34:47 2003 From: steve.lhomme at free.fr (Steve Lhomme) Date: Wed, 28 May 2003 16:34:47 +0200 (CEST) Subject: [matroska-devel] Re: Bug or feature : VdubMod doesnt alllow the audio stream to be longer than the video ? In-Reply-To: <3ED4A223.2070508@matroska.org> References: <3ED4A223.2070508@matroska.org> Message-ID: <1054132487.3ed4c907df998@imp.free.fr> En r?ponse ? Christian HJ Wiesner : > Hi guys, > > http://forum.doom9.org/showthread.php?s=&threadid=54324 > > any comments on that ? For the moment i am not 100% sure here, but i > guess our specs would allow different length of tracks ? For sure it's a bug in VDubMod... Now even if it was supported, the current DSF can't handle the situation ! The video pin will request data that will never come... In matroska there is an end of track flag that is probably not used anywhere... Maybe it should be mandatory to use it. At least the decoder could know something needs to be done for this track... Mosu ? Cyrius ? Ready to support it ? Mosu on splat files, only the second one has to have this flag set at the end, not at the end of the first files. BTW, it makes me think to another pb in DirectShow... What happens when the video start only after 10 minutes ? The video pin will block everything because it still hasn't have any data while the other pins are full... http://www.matroska.org