From chrisj78 at ctvea.net Thu Dec 2 08:22:26 2004 From: chrisj78 at ctvea.net (Chris Jairrels) Date: Thu, 2 Dec 2004 02:22:26 -0500 Subject: [Matroska-devel] need a more comprehensive package Message-ID: <200412020225671.SM02328@cjuniq> I like this file format which I have suddenly ran across, I like that I have so many options with it. But I had quite a hard time finding all the files I needed to get windows to play the file the way I wanted to. My files had dual audio/subtitles and I heard two languages spoken at once(no defaults?) in WMP and there seemed to be no immediately available filter or download for it on the front pages. I'll keep looking for an all in one package(I ended up removing the audio track), but I think a better job can be done of providing a download package that covers all the bases of the different formats/features you support since so many people use various combinations of vid and audio formats. This would be good for the uninitiated or computer un-savvy. -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve.lhomme at free.fr Thu Dec 2 09:53:38 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Thu, 02 Dec 2004 09:53:38 +0100 Subject: [Matroska-devel] need a more comprehensive package In-Reply-To: <200412020225671.SM02328@cjuniq> References: <200412020225671.SM02328@cjuniq> Message-ID: <41AED812.7090308@free.fr> Hi, This list is for developpers. There is a list for users with a lot info on the problem you are talking about. We *do* have a pack with all the filters you need. A quick look at our download page will help you. http://packs.matroska.org/ For WMP, you need the matrix mixer. Maybe WMP10 allows native audio stream switching. Chris Jairrels a ?crit : > > > I like this file format which I have suddenly ran across, I like that I > have so many options with it. But I had quite a hard time finding all > the files I needed to get windows to play the file the way I wanted to. > My files had dual audio/subtitles and I heard two languages spoken at > once(no defaults?) in WMP and there seemed to be no immediately > available filter or download for it on the front pages. > > > > I?ll keep looking for an all in one package(I ended up removing the > audio track), but I think a better job can be done of providing a > download package that covers all the bases of the different > formats/features you support since so many people use various > combinations of vid and audio formats. This would be good for the > uninitiated or computer un-savvy. > > > ------------------------------------------------------------------------ > > _______________________________________________ > Matroska-devel mailing list > Matroska-devel at lists.matroska.org > http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel -- robUx4 on blog From chris at matroska.org Mon Dec 6 13:21:55 2004 From: chris at matroska.org (Christian HJ Wiesner) Date: Mon, 06 Dec 2004 13:21:55 +0100 Subject: [Matroska-devel] Final call : USF muxing in MKV, and playback on DShow and Gstreamer Message-ID: <41B44EE3.3060509@matroska.org> Hi Team, hi unmei, its definitely time to do something sensible with USF. I heard that Real Networks is about to support the native OGG subtitle standard ( based on png/mng IIRC ) in Realplayer and Realproducer, SRT is not powerful enough and SSA files are too difficult to make, at least for most normal users who dont have a background in website programming. USF and unmei's nice editor, called U96, were raising a lot of interest already, and this is even before USF can actually be used inside MKV files. For my conversation with unmei i do have the impression, that both the format and the editor are already capable of producing nice USF files, all thats missing is - muxing - playback unmei has created a so-called 'USF rasterizer' thats a kind of library as i understand it, and most of the USF features are already supported in it. Only some of the more fancy stuff isnt yet, but this should only be a problem for fansubbers doing very complicated subtitles for hardsubbing during the encoding, as most PCs wont have the necessary CPU power to render those in real time. I am asking for 2 volunteers here on this list. 1. Someone caring about the muxing problem, either by adding MKS output to U96, or by making a USF parser so that Mosu and Alex can add it to their tools 2. Another one making a nice DShow filter, and/or a gstreamer plugin Goal must be, that there is a first 'working' version of these tools until the end of january, even if limited to the features that are presently supported by unmei's rasterizer. Anybody volunteering ? Regards Christian From Liisachan at faireal.net Tue Dec 7 02:41:20 2004 From: Liisachan at faireal.net (Liisachan) Date: Tue, 07 Dec 2004 10:41:20 +0900 Subject: [Matroska-devel] Final call : USF muxing in MKV, and playback on DShow and Gstreamer In-Reply-To: <41B44EE3.3060509@matroska.org> References: <41B44EE3.3060509@matroska.org> Message-ID: <20041207104120C-Nkkt@faireal.net> Christian HJ Wiesner wrote: > SRT > is not powerful enough and SSA files are too difficult to make, at least > for most normal users who dont have a background in website programming. Yes, and my hope is, USF will be widely supported, not only on Linux/Win2k/xp etc. but also on Win98 or even on HW. Let me elaborate: SSA files are easy to _make_, you can just convert your SRT into SSA with a tool like subresync within 1 sec. The real problem is, a softsubbed MKV doesn't play on Windows 98 decently (without unchecking the "Prebuffer subpictures" chcekbox, which is not practical), while softsubbed OGM plays nicely on Windows 98. Believe it or not, there are still many ppl who are using Windows 98. Personally, I would like to just say, "Hey stop using that old stupid OS!!!" but they have their own reasons, and we cannot force them anyway. It is painful for me that they cannot play MKV if it is softsubbed. If you are not interested in subs, MKV is just fine. But _as subbers_, our general opinion was: "Despite all the promising features, Matroska is still not a practical format to use at the moment." as long as there are Windows 98 users out there. And since you devs practically had given up supporting Windows 98, even insulting Windows 98 users in a doom9 thread, now subbers do not support MKV unconditionally anymore; they have to say to themselves, "Our files dont play on Win98; the devs are not going to fix this problem either; if we release it as OGM, it will play on Win98, but then subs will not be stylish... What'll we do?" i.e. Both MKV and OGM have its own fortes and its own downsides... This problem cant be ignored especially if you have friends using win98. I do. So please dont ask me to write "MKV is a nice format which is widely supported." I also heard that the "font-embedding for subs" support is not satisfactory on Linux either atm. On the other hand, I know that supporting Unicode on Windows 98 is very complicated for many reasons. Even Windows 2000 is not fully Unicode-enabled. Only Windows XP is Ok. Windows 98 is still in use but is dying... It's only natural that devs don't want to consider about that stupid old OS now in 2004, even tho softsubbed OGMs (OGM was developed in around 2002 iirc) play fine on Win 98, because--ironically--OGM is not new nor Unicode-based. * Anyway, my hope is, USF decoder will work on Win98 too. It should be possible, because many other cool applications, such as foobar2000, do support UTF-8 even on Windows 98. Otherwise, we will keep saying to Windows users in anime fandom, "MKV is practical if, and only if, your OS is Win2k or xp; If you are using windows 98, you'll just have to give up. Most probably it wont play properly." Liisachan From steve.lhomme at free.fr Tue Dec 7 09:38:21 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Tue, 07 Dec 2004 09:38:21 +0100 Subject: [Matroska-devel] Final call : USF muxing in MKV, and playback on DShow and Gstreamer In-Reply-To: <20041207104120C-Nkkt@faireal.net> References: <41B44EE3.3060509@matroska.org> <20041207104120C-Nkkt@faireal.net> Message-ID: <41B56BFD.6040606@free.fr> Liisachan a ?crit : > Anyway, my hope is, USF decoder will work on Win98 too. > It should be possible, because many other cool applications, > such as foobar2000, do support UTF-8 even on Windows 98. > > Otherwise, we will keep saying to Windows users in anime fandom, > "MKV is practical if, and only if, your OS is Win2k or xp; > If you are using windows 98, you'll just have to give up. > Most probably it wont play properly." From what I understand it's not a USF problem (and USF will not solve such problems magically). I know there are some problems but I don't know the precise details. Does MPC for W9x work fine with subs in MKV ? Does Haali's splitter work fine in W9x ? Does it solve possible issues ? Or is the problem in vobsubs, in which case we'd have to push Gabest to try to get things fixed. As we plan to release a new pack in a few weeks, we have enough time to make sure it works in W9x too. We have good coders, it's just a matter of time and will :) Steve From moritz at bunkus.org Tue Dec 7 11:58:05 2004 From: moritz at bunkus.org (Moritz Bunkus) Date: Tue, 7 Dec 2004 11:58:05 +0100 Subject: [Matroska-devel] Final call : USF muxing in MKV, and playback on DShow and Gstreamer In-Reply-To: <20041207104120C-Nkkt@faireal.net> References: <41B44EE3.3060509@matroska.org> <20041207104120C-Nkkt@faireal.net> Message-ID: <20041207105805.GA17627@bunkus.org> Hey, > I also heard that the "font-embedding for subs" support is not > satisfactory on Linux either atm. That's true, but support for subs in general sucks on Linux. Only the text itself is displayed - no effects, no fonts, no nothing. So not handling embedded/attached fonts is only part of the problem on Linux. (That's true for SSA in general, not only if it is embedded in Matroska. Same for other effects in other text sub formats.) Mosu -- If Darl McBride was in charge, he'd probably make marriage unconstitutional too, since clearly it de-emphasizes the commercial nature of normal human interaction, and probably is a major impediment to the commercial growth of prostitution. - Linus Torvalds From moritz at bunkus.org Tue Dec 7 12:21:01 2004 From: moritz at bunkus.org (Moritz Bunkus) Date: Tue, 7 Dec 2004 12:21:01 +0100 Subject: [Matroska-devel] Final call : USF muxing in MKV, and playback on DShow and Gstreamer In-Reply-To: <41B56BFD.6040606@free.fr> References: <41B44EE3.3060509@matroska.org> <20041207104120C-Nkkt@faireal.net> <41B56BFD.6040606@free.fr> Message-ID: <20041207112101.GB17627@bunkus.org> Hey, > Does MPC for W9x work fine with subs in MKV ? > Does Haali's splitter work fine in W9x ? Does it solve possible issues ? > Or is the problem in vobsubs, in which case we'd have to push Gabest to > try to get things fixed. I think it was a problem in VSFilter, not in the splitter. Let me try to find the thread on doom9... http://forum.doom9.org/showthread.php?s=&threadid=81176&perpage=20&pagenumber=1 The post from Gooberslot is the one that started it. Quoting from his post on page 2: http://forum.doom9.org/showthread.php?s=&threadid=81176&perpage=20&pagenumber=2 > I don't think this bug would be very hard to track down. AFAIK, 2.23 > is the last version that works right under Win98 so just go back and > see what changes happened between 2.23 and 2.24 that could cause this > type of bug. There's probably not that much to look at. Of course I'm > not a programmer so I could be wrong. If someone were serious about > fixing it though I'd be glad to go back and try each version and find > out exactly where it breaks. So if someone (Haali? :)) wants to get his hands dirty... Mosu -- If Darl McBride was in charge, he'd probably make marriage unconstitutional too, since clearly it de-emphasizes the commercial nature of normal human interaction, and probably is a major impediment to the commercial growth of prostitution. - Linus Torvalds From mike at po.cs.msu.su Tue Dec 7 12:35:26 2004 From: mike at po.cs.msu.su (Mike Matsnev) Date: Tue, 07 Dec 2004 14:35:26 +0300 Subject: [Matroska-devel] Final call : USF muxing in MKV, and playback on DShow and Gstreamer In-Reply-To: <20041207112101.GB17627@bunkus.org> References: <41B44EE3.3060509@matroska.org> <20041207104120C-Nkkt@faireal.net> <41B56BFD.6040606@free.fr> <20041207112101.GB17627@bunkus.org> Message-ID: <41B5957E.10205@po.cs.msu.su> Moritz Bunkus wrote: >>I don't think this bug would be very hard to track down. AFAIK, 2.23 >>is the last version that works right under Win98 so just go back and >>see what changes happened between 2.23 and 2.24 that could cause this >>type of bug. There's probably not that much to look at. Of course I'm >>not a programmer so I could be wrong. If someone were serious about >>fixing it though I'd be glad to go back and try each version and find >>out exactly where it breaks. > > > So if someone (Haali? :)) wants to get his hands dirty... I have no win98 machines around, don't even have win98 setup CDs anymore. /Mike From steve.lhomme at free.fr Tue Dec 7 12:39:52 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Tue, 07 Dec 2004 12:39:52 +0100 Subject: [Matroska-devel] Final call : USF muxing in MKV, and playback on DShow and Gstreamer In-Reply-To: <41B5957E.10205@po.cs.msu.su> References: <41B44EE3.3060509@matroska.org> <20041207104120C-Nkkt@faireal.net> <41B56BFD.6040606@free.fr> <20041207112101.GB17627@bunkus.org> <41B5957E.10205@po.cs.msu.su> Message-ID: <41B59688.4000106@free.fr> Mike Matsnev a ?crit : > Moritz Bunkus wrote: > >>> I don't think this bug would be very hard to track down. AFAIK, 2.23 >>> is the last version that works right under Win98 so just go back and >>> see what changes happened between 2.23 and 2.24 that could cause this >>> type of bug. There's probably not that much to look at. Of course I'm >>> not a programmer so I could be wrong. If someone were serious about >>> fixing it though I'd be glad to go back and try each version and find >>> out exactly where it breaks. >> >> >> >> So if someone (Haali? :)) wants to get his hands dirty... > > I have no win98 machines around, don't even have win98 setup CDs anymore. I think Mosu uses Win98 under VMWare. I remember installing it this way too (and finally didn't use it). If you miss the CD it's easy to find ;) From mike at po.cs.msu.su Tue Dec 7 12:44:48 2004 From: mike at po.cs.msu.su (Mike Matsnev) Date: Tue, 07 Dec 2004 14:44:48 +0300 Subject: [Matroska-devel] Final call : USF muxing in MKV, and playback on DShow and Gstreamer In-Reply-To: <41B5957E.10205@po.cs.msu.su> References: <41B44EE3.3060509@matroska.org> <20041207104120C-Nkkt@faireal.net> <41B56BFD.6040606@free.fr> <20041207112101.GB17627@bunkus.org> <41B5957E.10205@po.cs.msu.su> Message-ID: <41B597B0.4070600@po.cs.msu.su> Mike Matsnev wrote: >>> I don't think this bug would be very hard to track down. AFAIK, 2.23 >>> is the last version that works right under Win98 so just go back and >>> see what changes happened between 2.23 and 2.24 that could cause this >>> type of bug. There's probably not that much to look at. Of course I'm >>> not a programmer so I could be wrong. If someone were serious about >>> fixing it though I'd be glad to go back and try each version and find >>> out exactly where it breaks. >> So if someone (Haali? :)) wants to get his hands dirty... > > I have no win98 machines around, don't even have win98 setup CDs anymore. Besides, 2.24 is the earliest version available on SF, there are no sources for earlier versions. Looks like gabest did the import at the same time he released 2.24. /Mike From chris at matroska.org Tue Dec 7 14:05:59 2004 From: chris at matroska.org (Christian HJ Wiesner) Date: Tue, 07 Dec 2004 14:05:59 +0100 Subject: [Matroska-devel] Final call : USF muxing in MKV, and playback on DShow and Gstreamer In-Reply-To: <41B5957E.10205@po.cs.msu.su> References: <41B44EE3.3060509@matroska.org> <20041207104120C-Nkkt@faireal.net> <41B56BFD.6040606@free.fr> <20041207112101.GB17627@bunkus.org> <41B5957E.10205@po.cs.msu.su> Message-ID: <41B5AAB7.50102@matroska.org> Mike Matsnev schrieb: > I have no win98 machines around, don't even have win98 setup CDs anymore. > /Mike I do have an old K6-2 PC at home for the time being, with Win ME installed ( same DirectX version as Win 98, and no unicode AFAIK ). I guess if i do some simple encodes, using low res XviD, PCM audio and SRT subs, it should be able to play these in real time, and then i could act as a beta tester for you. Of course, only if we manage to find the old sources from vsfilter 2.23 somewhere, and can find out what bug was introduced in latest vsfilter versions, preventing it from operating correctly on Win98 machines .... Christian From paul at msn.com Tue Dec 7 18:12:03 2004 From: paul at msn.com (Paul Bryson) Date: Tue, 7 Dec 2004 11:12:03 -0600 Subject: [Matroska-devel] Re: Final call : USF muxing in MKV, and playbackon DShow and Gstreamer References: <41B44EE3.3060509@matroska.org> <20041207104120C-Nkkt@faireal.net> <41B56BFD.6040606@free.fr> <20041207112101.GB17627@bunkus.org><41B5957E.10205@po.cs.msu.su> <41B59688.4000106@free.fr> Message-ID: "Steve Lhomme" wrote in message news:41B59688.4000106 at free.fr... Mike Matsnev a ?crit : >> I have no win98 machines around, don't even have win98 setup CDs anymore. > > I think Mosu uses Win98 under VMWare. I remember installing it this way > too (and finally didn't use it). If you miss the CD it's easy to find ;) If you need help finding them, let me know. Atamido From atamido at gmail.com Tue Dec 7 16:51:07 2004 From: atamido at gmail.com (Paul Bryson) Date: Tue, 7 Dec 2004 09:51:07 -0600 Subject: [usf-devel] Re: [Matroska-devel] Final call : USF muxing in MKV, and playback on DShow and Gstreamer In-Reply-To: <41B56BFD.6040606@free.fr> References: <41B44EE3.3060509@matroska.org> <20041207104120C-Nkkt@faireal.net> <41B56BFD.6040606@free.fr> Message-ID: <1b8a3666041207075174672d4@mail.gmail.com> On Tue, 07 Dec 2004 09:38:21 +0100, Steve Lhomme wrote: > From what I understand it's not a USF problem (and USF will not solve=20 > such problems magically). I know there are some problems but I don't=20 > know the precise details. No, but if someone writes a brand new subtitle renderer for DirectShow, it could possible eliminate these issues in Windows 98. Atamido From Liisachan at faireal.net Tue Dec 7 19:23:24 2004 From: Liisachan at faireal.net (Liisachan) Date: Wed, 08 Dec 2004 03:23:24 +0900 Subject: [Matroska-devel] Final call : USF muxing in MKV, and playbackon DShow and Gstreamer In-Reply-To: <41B56BFD.6040606@free.fr> References: <20041207104120C-Nkkt@faireal.net> <41B56BFD.6040606@free.fr> Message-ID: <20041208032324'I5EM#@faireal.net> Steve Lhomme wrote: > Does MPC for W9x work fine with subs in MKV ? > Does Haali's splitter work fine in W9x ? Does it solve possible issues ? > Or is the problem in vobsubs, in which case we'd have to push Gabest to > try to get things fixed. Today we re-tested MPC 6482 and 6483CVS and WMP6.4 on Window 98se (physical machine, not virtual) Result: - MKV, if soft-subbed, will crash the OS. - MKV plays fine if not subbed. We will test Haali's filters later. One of us also suggested that we should test MPlayer for Windows (sub support is not as good as VSFilter, but still better than crash) RadLight (which can render subs by itself) might work too on win98, at least better than the filters in the official pack. So there might be a way to play subbed mkv on win98, but it would be the best if the official pack could support win98 too. > > As we plan to release a new pack in a few weeks, we have enough time to > make sure it works in W9x too. We have good coders, it's just a matter > of time and will :) Glad to hear that, especially after we heard from you devs connotate "We don't want to support Win98"...I hope this wont be too late. That anti-98 argument in the doom9 forum was more or less discouraging; when a user modestly reported a true, important, and reproducible bug, which was commonly known for win98 users, he was mistreated and some of his posts had been even deleted by the mod who insisted "As a user of an open source product you have no rights to complain about something that doesn't work on your system." Im not criticizing the mod... I guess there had been some kind of misunderstanding there. Besides, he is a very nice person considering that another mod might just have said "Stop talking about Matroska, or else!" Personally I don't mind if MKV doesn't work on Win98, as long as you make it clear, i.e. if the official page says "Matroska Pack for Windows 2000/XP (NOTE Windows 98 is not supported)"... Win 98 users were (are/will be) upset because you guys don't say beforehand that Win 98 is not fully supported. Liisachan > > Steve > _______________________________________________ > Matroska-devel mailing list > Matroska-devel at lists.matroska.org > http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel From Liisachan at faireal.net Tue Dec 7 19:33:22 2004 From: Liisachan at faireal.net (Liisachan) Date: Wed, 08 Dec 2004 03:33:22 +0900 Subject: [usf-devel] Re: [Matroska-devel] Final call : USF muxing in MKV, and playback on DShow and Gstreamer In-Reply-To: <1b8a3666041207075174672d4@mail.gmail.com> References: <41B56BFD.6040606@free.fr> <1b8a3666041207075174672d4@mail.gmail.com> Message-ID: <20041208033322LHqP$u@faireal.net> Paul Bryson wrote: > On Tue, 07 Dec 2004 09:38:21 +0100, Steve Lhomme wrote: > > From what I understand it's not a USF problem (and USF will not solve=20 > > such problems magically). I know there are some problems but I don't=20 > > know the precise details. > > No, but if someone writes a brand new subtitle renderer for > DirectShow, it could possible eliminate these issues in Windows 98. That's what I meant. Besides, altho MPC already supports USF, the USF spec has been updated heavily, like Unmei said: "VSFilter supports USF to a certain degree. IIRC it supports most of the old specs, but it borked in some weird places the normal user might not even ever use. On the other hand it does not support any of the experimental features and Gabest is unlikely to extend its functionality (i fear)." http://corecodec.com/modules.php?op=modload&name=PNphpBB2&file=viewtopic&t=237 http://corecodec.com/modules.php?op=modload&name=PNphpBB2&file=viewtopic&t=914 Unmei can explain more but the bottom line is, a new filter is needed, possibly developed from scratch, and if so, it is supposed to support Unicode etc. independently from the VSFilter's problems. For instance, USF is now supposed to support what is called RUBY, which will rock the subbers in E Asia. Unmei's rasterizer already supports it too. There might be more ppl who will praise USF than you'd expect. I mean it :) Liisachan > > > Atamido > _______________________________________________ > Matroska-devel mailing list > Matroska-devel at lists.matroska.org > http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel From mike at po.cs.msu.su Tue Dec 7 22:08:22 2004 From: mike at po.cs.msu.su (Mike Matsnev) Date: Wed, 08 Dec 2004 00:08:22 +0300 Subject: [Matroska-devel] New dshow splitter Message-ID: <41B61BC6.5030004@po.cs.msu.su> Hi! I think it's time for more public testing of my new code, the binaries are available at http://haali.cs.msu.ru/mkv/.new/ There are two mkx.dll avi.dll and slitter.ax, all of these need to be registered. I've also prepared an installer that does just that: MatroskaSplitter.exe. Since splitter IDs are hardcoded in VSFilter, there is a new build of VSFilter with new splitter support. This is a complete rewrite from scratch to have better design and better maintainability. DShow interfacing was completely separated from actual file parsing via COM interfaces, so one common DShow code can be used with many file formats. I've implemented AVI support in one weekend using that framework as a proof of concept. AVI splitter is not registered by default but the DShow filter will open avi files, so you can play with it in graphedit, or do something evil like copy /b file1.mkv + file2.avi file3.mkv Major new features: * Multisegment files support, you can produce those by running copy /b file1.mkv + file2.mkv multiseg.mkv * Files with multiple video tracks are supported, streams can be switched via tray menu. * Pre/post chapter commands, framework is in place, but only one command is implemented so far: NextSegment is executed at the end of current segment. * Internal stream switching with WMP9/10 support, can't be turned off due to the way it is implemented, so you'll need to use my tray icon or WMP :] * Probably some other stuff that I forgot about. Known issues: * Switching from a segment with sound to a soundless one doesn't work. * Switching some video stream formats results in a crash in ffdshow, e.g. mpeg4->huffyuv. I didn't try debugging this yet. I expect some minor bugs to show up, hopefully nothing major will happen. I'd appreciate it if you try this new code and report any problems and feature requests either to ML or to me privately. Thanks in advance. /Mike From steve.lhomme at free.fr Tue Dec 7 22:47:54 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Tue, 07 Dec 2004 22:47:54 +0100 Subject: [Matroska-devel] Final call : USF muxing in MKV, and playbackon DShow and Gstreamer In-Reply-To: <20041208032324'I5EM#@faireal.net> References: <20041207104120C-Nkkt@faireal.net> <41B56BFD.6040606@free.fr> <20041208032324'I5EM#@faireal.net> Message-ID: <41B6250A.70300@free.fr> Liisachan a ?crit : > Personally I don't mind if MKV doesn't work on Win98, > as long as you make it clear, i.e. if the official page says > "Matroska Pack for Windows 2000/XP (NOTE Windows 98 is not > supported)"... Win 98 users were (are/will be) upset because you > guys don't say beforehand that Win 98 is not fully supported. I do mind. But I'm not the one making DShow filters (hopefully). So I will try to motivate people where due :) From steve.lhomme at free.fr Tue Dec 7 22:50:18 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Tue, 07 Dec 2004 22:50:18 +0100 Subject: [Matroska-devel] Re: Final call : USF muxing in MKV, and playback on DShow and Gstreamer In-Reply-To: <20041208033322LHqP$u@faireal.net> References: <41B56BFD.6040606@free.fr> <1b8a3666041207075174672d4@mail.gmail.com> <20041208033322LHqP$u@faireal.net> Message-ID: <41B6259A.7020003@free.fr> Liisachan a ?crit : > For instance, USF is now supposed to support what is > called RUBY, which will rock the subbers in E Asia. > Unmei's rasterizer already supports it too. > There might be more ppl who will praise USF than you'd expect. > I mean it :) Well, maybe you should talk to Radlight about it ;) Haali has made an attempt at a vobsub filter but it didn't work in the end and was targetting WMR9, so it wouldn't work on W98 anyway... From Liisachan at faireal.net Wed Dec 8 01:47:04 2004 From: Liisachan at faireal.net (Liisachan) Date: Wed, 08 Dec 2004 09:47:04 +0900 Subject: [Matroska-devel] Re: Final call : USF muxing in MKV, and playback on DShow and Gstreamer In-Reply-To: <41B6259A.7020003@free.fr> References: <20041208033322LHqP$u@faireal.net> <41B6259A.7020003@free.fr> Message-ID: <20041208094704?CfloN@faireal.net> Steve Lhomme wrote: > Haali has made an attempt at a vobsub filter but it didn't work in the > end and was targetting WMR9, so it wouldn't work on W98 anyway... I don't think supporting Windows 98 is a 'must' Besides, if you mean VMR-9, VMR-9 does work on Windows 98 too, if you install DirectX 9 (iirc) While Vobsub is binary, USF is a text, so probably simpler; unless more than one Code Pages are mixed in one USF, you can always let Windows 98 understand the Unicode by just calling WideCharToMultiByte(). USF is supposed to have quite a few new features (even including SVG). They are all practical and very excitinig. But I'm afraid Haali is not that motivated, unless he is a subber himself, like Gabest or unmei or me. Perhaps he even doesn't understand why we need these features, just like Tobias was not very committed to Unicode-support. In the end, we would have this cool USF spec doc, like ================================================================ USF is a new, flexible sub format based on XML: - Advanced positioning support (aka nested) - 4 independent Alpha channels (Face, Karaoke, Border, Shadow) - Predefinable Effect classes - RUBY support - BIDI support (eg. Arabic, Hebrew can contain English words) ... NOTE: All these features exist only in this spec. No real program supports one. For practical purposes, use OggWrit. ================================================================ Liisachan From paul at msn.com Wed Dec 8 05:25:45 2004 From: paul at msn.com (Paul Bryson) Date: Tue, 7 Dec 2004 22:25:45 -0600 Subject: [Matroska-devel] Re: New dshow splitter References: <41B61BC6.5030004@po.cs.msu.su> Message-ID: "Mike Matsnev" wrote... > * Switching some video stream formats results in a crash in > ffdshow, e.g. mpeg4->huffyuv. I didn't try debugging this > yet. This video locked up when switching from the second to the third stream while playing. Could anyone else confirm this? (2MB) http://commo.de/3_videos.mkv Atamido From steve.lhomme at free.fr Wed Dec 8 10:37:31 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Wed, 08 Dec 2004 10:37:31 +0100 Subject: [Matroska-devel] Re: Final call : USF muxing in MKV, and playback on DShow and Gstreamer In-Reply-To: <20041208094704?CfloN@faireal.net> References: <20041208033322LHqP$u@faireal.net> <41B6259A.7020003@free.fr> <20041208094704?CfloN@faireal.net> Message-ID: <41B6CB5B.6020300@free.fr> Liisachan a ?crit : > USF is supposed to have quite a few new features (even including > SVG). They are all practical and very excitinig. > But I'm afraid Haali is not that motivated, unless he is a > subber himself, like Gabest or unmei or me. > Perhaps he even doesn't understand why we need these features, > just like Tobias was not very committed to Unicode-support. Haali/Mike is russian, so native character is probably more important for him than any western european coder. But Right now he's working on other things. Maybe later. From dos at scarff.id.au Wed Dec 8 11:06:13 2004 From: dos at scarff.id.au (Dean Scarff) Date: Wed, 08 Dec 2004 18:06:13 +0800 Subject: [Matroska-devel] [RFC] EBML Schema Message-ID: <871xe1yui2.fsf@p00ya.ath.cx> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I've put together a schema (tentatively termed "EBML Schema") for a schema for describing EBML[1] documents (whew!). A quick search of matroska.devel suggested this was under consideration but hasn't been discussed since May. Please bear with me, the rest of this message may be as confusing as the opening sentence. The EBML Schema schema is written in RELAX NG[2]. It can be easily converted into an XML Schema[3]. EBML Schema instances can be made valid RELAX NG instances by using a namespace prefix for EBML specific elements. This allows the *structure* of EBML files to be represented in an XML format, and therefore existing tools for validating XML against a schema (eg libxml2) can be leveraged. It's also nice to provide a human-readable alternative representation that stays reasonably true to the EBML format. The biggest problem that I can see is EBML's support of multiple root elements (segments) which requires an extra root element to wrap them all up. I kludged the issue by using the ebml signature (0x1a45dfa3) as a root element and nesting all segments under that. This should be fair, since a new signature really indicates a new document. The EBML Schema schema is available at: or in XML Schema: An EBML Schema instance for Matroska is available at: Just in case it's still not clear: I've discussed 3 levels of XML here. The EBML Schema schema; instances of EBML Schema; and an XML presentation-layer for EBML, which can be validated against instances of EBML Schema. As yet, I have not written a specification for EBML Schema; but the semantics of elements are inherited from [1] and [2], with behaviour as one expects. However, if I receive positive feedback, I can certainly knock up a DocBook spec. - -- References: [1] _EBML Principles_. Matroska Project. [accessed 08 Dec 2004]. [2] James CLARK, Makoto MURATA, (ed). _RELAX NG Specificiation_. OASIS, 2001. . [3] Henry THOMPSON et al., (ed). _XML Schema Part 1_, 2nd ed. W3C, 2004. . - -- Dean -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFBttIXPs40JFRfzR0RAmsFAKC6WbjMc8p3bQNEIZxVE0bgpcHh9gCeL2Dc MXwj+rHIn5k2XJ6U+9EwtMo= =cPij -----END PGP SIGNATURE----- From chris at matroska.org Wed Dec 8 14:35:15 2004 From: chris at matroska.org (Christian HJ Wiesner) Date: Wed, 08 Dec 2004 14:35:15 +0100 Subject: [Matroska-devel] Re: Final call : USF muxing in MKV, and playback on DShow and Gstreamer In-Reply-To: <20041208094704?CfloN@faireal.net> References: <20041208033322LHqP$u@faireal.net> <41B6259A.7020003@free.fr> <20041208094704?CfloN@faireal.net> Message-ID: <41B70313.2070504@matroska.org> Liisachan schrieb: >In the end, we would have this cool USF spec doc, like >================================================================ >USF is a new, flexible sub format based on XML: >- Advanced positioning support (aka nested) >- 4 independent Alpha channels (Face, Karaoke, Border, Shadow) >- Predefinable Effect classes >- RUBY support >- BIDI support (eg. Arabic, Hebrew can contain English words) >... >NOTE: All these features exist only in this spec. No real >program supports one. *For practical purposes,* *use OggWrit.* >================================================================ >Liisachan > > > :-P !!! Liisachan, you really can be mean sometimes :-D !! ..... ;-) ....... Christian matroska project admin From Liisachan at faireal.net Wed Dec 8 15:13:28 2004 From: Liisachan at faireal.net (Liisachan) Date: Wed, 08 Dec 2004 23:13:28 +0900 Subject: [Matroska-devel] Re: Final call : USF muxing in MKV, and playback on DShow and Gstreamer In-Reply-To: <41B70313.2070504@matroska.org> References: <20041208094704?CfloN@faireal.net> <41B70313.2070504@matroska.org> Message-ID: <20041208231328+#9nuD@faireal.net> Christian HJ Wiesner wrote: > Liisachan, you really can be mean sometimes :-D !! ..... ;-) ....... Ah, ofcourse i was half-joking but honestly, I really felt insecure when Steve Lhomme said: "maybe you should talk to Radlight about it" USF specs are getting brilliant, but what about real support? Unmei's rasterizer supported RUBY, but it seems that we still have a long way to "translate" it into DSFilter. I was not not trying to be mean; I really felt insecure about it. Liisachan From mike at po.cs.msu.su Wed Dec 8 16:18:04 2004 From: mike at po.cs.msu.su (Mike Matsnev) Date: Wed, 08 Dec 2004 18:18:04 +0300 Subject: [Matroska-devel] Re: Final call : USF muxing in MKV, and playback on DShow and Gstreamer In-Reply-To: <20041208231328+#9nuD@faireal.net> References: <20041208094704?CfloN@faireal.net> <41B70313.2070504@matroska.org> <20041208231328+#9nuD@faireal.net> Message-ID: <41B71B2C.3030600@po.cs.msu.su> Liisachan wrote: > USF specs are getting brilliant, but what about real support? > Unmei's rasterizer supported RUBY, but it seems that > we still have a long way to "translate" it into DSFilter. > I was not not trying to be mean; I really felt insecure about it. I think we can have an easier implementation by using bitmap subs. Not the ugly vobsubs, but real argb images compressed with smth like huffyuv. It shouldnt be too hard for Unmei to write such an avi file and then mux into matroska. But to do this we need to decide something about vsfilter. I've recently bumped into a couple other vsfilter deficiencies. Of course I'll try to contact Gabest, but I'm not sure about the results. Wouldn't it be better to roll our own subtitling filter? Unfortunately I don't know who is going to write it, as I am somewhat busy recently. Btw, did anyone try Radlight's subtitler? Is it working? /Mike From Liisachan at faireal.net Wed Dec 8 16:52:22 2004 From: Liisachan at faireal.net (Liisachan) Date: Thu, 09 Dec 2004 00:52:22 +0900 Subject: [Matroska-devel] Re: Final call : USF muxing in MKV, and playbackon DShow and Gstreamer In-Reply-To: <41B71B2C.3030600@po.cs.msu.su> References: <20041208231328+#9nuD@faireal.net> <41B71B2C.3030600@po.cs.msu.su> Message-ID: <20041209005222y&'px&@faireal.net> Mike Matsnev wrote: > Liisachan wrote: > > USF specs are getting brilliant, but what about real support? > > Unmei's rasterizer supported RUBY, but it seems that > > we still have a long way to "translate" it into DSFilter. > > I was not not trying to be mean; I really felt insecure about it. > I think we can have an easier implementation by using bitmap subs. > Not the ugly vobsubs, but real argb images compressed with smth > like huffyuv. It shouldnt be too hard for Unmei to write such an > avi file and then mux into matroska. > > But to do this we need to decide something about vsfilter. I've > recently bumped into a couple other vsfilter deficiencies. > Of course I'll try to contact Gabest, but I'm not sure about the > results. Wouldn't it be better to roll our own subtitling filter? > Unfortunately I don't know who is going to write it, as I am > somewhat busy recently. > > Btw, did anyone try Radlight's subtitler? Is it working? I did. It worked decently, on Windows 2000/XP. Not tested on Win 98. Pics: http://www.faireal.net/tmp/sub-test/ http://www.hydrogenaudio.org/forums/index.php?showtopic=24046 Liisachan From chris at matroska.org Wed Dec 8 17:01:28 2004 From: chris at matroska.org (Christian HJ Wiesner) Date: Wed, 08 Dec 2004 17:01:28 +0100 Subject: [Matroska-devel] Re: Final call : USF muxing in MKV, and playback on DShow and Gstreamer In-Reply-To: <20041208231328+#9nuD@faireal.net> References: <20041208094704?CfloN@faireal.net> <41B70313.2070504@matroska.org> <20041208231328+#9nuD@faireal.net> Message-ID: <41B72558.2030408@matroska.org> Hi Liisachan Liisachan schrieb: >Christian HJ Wiesner wrote: > >>Liisachan, you really can be mean sometimes :-D !! ..... ;-) ....... >> >> > >Ah, ofcourse i was half-joking but honestly, >I really felt insecure when Steve Lhomme said: >"maybe you should talk to Radlight about it" > >USF specs are getting brilliant, but what about real support? >Unmei's rasterizer supported RUBY, but it seems that >we still have a long way to "translate" it into DSFilter. >I was not not trying to be mean; I really felt insecure about it. >Liisachan > Received and understood. There is only one inconsistency in this : We are a small team, and do have very limited resources. One day the fansubbers will have to make up their mind if they want us to - make our stuff compliant with old, obsolete Win98 machines - code USF DShow filters for machines powerful enough to render RUBY in real time With respect to the fact that Win98 doesnt offer any kind of support for modern chipsets, and the old PCs its normally installed on are slowly dieing out, i vote for option #2. It would be a cool feature if the rasterizer would auto-set the level of subs support automatically, depending on available CPU power, means if it could skip certain features if the CPU is maxed out, but still display the main subs, i.e. the text. To support both should not be possible for us, and robux4's remark about Radlight was not so far off. These guys were making jokes about us since a long time, though admittedly more about TCMP than about matroska. On the other hand, its still good old TCMP 'earning' the money for the server we are hosted on, while they take the money they earn with Radlight player, and buy new tires for their fancy cars ( or god knows what else ). Its really time to ask them to make stuff like their new subtitles filter OSS, so that the community can gain advantage from it. But they obviously are more interested in earning money, then serving the users or the community. A free USF subtitles filter from Radlight would indeed be cool stuff, and change my mind about them completely :-) ! Lets see if they can come up with anything sensible here. Else its again the matroska team facing all the hard work, and i admit its hard and harder to find the motivation to do so. Your arguments to still prefer OGM to MKV, because of vsfilter ( a 3rd party filter we didnt even code ) crashing on Win98 when playing standard MKV files, is not too helpful either. I hope all this makes sense to you, lets see what we can come up with in future. Christian matroska project admin P.S. If you mux a MKV with a non-unicode SRT file ( like OGM does ), will it also crash ? From steve.lhomme at free.fr Wed Dec 8 17:12:43 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Wed, 08 Dec 2004 17:12:43 +0100 Subject: [Matroska-devel] [RFC] EBML Schema In-Reply-To: <871xe1yui2.fsf@p00ya.ath.cx> References: <871xe1yui2.fsf@p00ya.ath.cx> Message-ID: <41B727FB.4000009@free.fr> Hi, Dean Scarff a ?crit : > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > I've put together a schema (tentatively termed "EBML Schema") for a > schema for describing EBML[1] documents (whew!). A quick search of > matroska.devel suggested this was under consideration but hasn't been > discussed since May. > > Please bear with me, the rest of this message may be as confusing as > the opening sentence. The EBML Schema schema is written in RELAX > NG[2]. It can be easily converted into an XML Schema[3]. I heard about both, but Relax NG is still a weird thing to me. I know Schema are DTDs written in XML which gives more possibilities to describe an XML format (although XML is described as a DTD...). > EBML Schema instances can be made valid RELAX NG instances by using a > namespace prefix for EBML specific elements. This allows the > *structure* of EBML files to be represented in an XML format, and > therefore existing tools for validating XML against a schema (eg > libxml2) can be leveraged. It's also nice to provide a human-readable > alternative representation that stays reasonably true to the EBML That could be good. So far we manage to extract informations about EBML/Matroska files with basic tools that ouptut text files. But outputing XML that actually refers to a schema would be nice. > format. The biggest problem that I can see is EBML's support of > multiple root elements (segments) which requires an extra root element > to wrap them all up. I kludged the issue by using the ebml signature > (0x1a45dfa3) as a root element and nesting all segments under that. > This should be fair, since a new signature really indicates a new > document. Well the only format using EBML now is Matroska (AFAIK). And The EBML Segment is at the same level as the same level as the EBML header. You can have multiple Segments in the same file and even multiple EBML head (but in that case how to handle subsequent heads is not yet defined). I hope it fits your specs. > The EBML Schema schema is available at: > > or in XML Schema: > I had a look at both and didn't see any mention of the EBML IDs, nor the names we have given to EBML elements. Is that normal ? > An EBML Schema instance for Matroska is available at: > That one contains the IDs and names :) So does it mean you have an EBML Schema, create an instance based on this Schema ? And then you can have an XML file based on the instance ? > Just in case it's still not clear: I've discussed 3 levels of XML > here. The EBML Schema schema; instances of EBML Schema; and an XML > presentation-layer for EBML, which can be validated against instances > of EBML Schema. I hope it means the same I said above ;) > As yet, I have not written a specification for EBML Schema; but the > semantics of elements are inherited from [1] and [2], with behaviour > as one expects. However, if I receive positive feedback, I can > certainly knock up a DocBook spec. That's a good work. I can also ask some help from a friend of mine (Fabio Arciniegas) who wrote some books on XML and (IIRC) worked on Relax NG. cya From steve.lhomme at free.fr Wed Dec 8 17:26:06 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Wed, 08 Dec 2004 17:26:06 +0100 Subject: [Matroska-devel] Re: Final call : USF muxing in MKV, and playback on DShow and Gstreamer In-Reply-To: <41B71B2C.3030600@po.cs.msu.su> References: <20041208094704?CfloN@faireal.net> <41B70313.2070504@matroska.org> <20041208231328+#9nuD@faireal.net> <41B71B2C.3030600@po.cs.msu.su> Message-ID: <41B72B1E.2090506@free.fr> Mike Matsnev a ?crit : > Liisachan wrote: > >> USF specs are getting brilliant, but what about real support? >> Unmei's rasterizer supported RUBY, but it seems that >> we still have a long way to "translate" it into DSFilter. >> I was not not trying to be mean; I really felt insecure about it. > > I think we can have an easier implementation by using bitmap subs. > Not the ugly vobsubs, but real argb images compressed with smth > like huffyuv. It shouldnt be too hard for Unmei to write such an > avi file and then mux into matroska. > > But to do this we need to decide something about vsfilter. I've > recently bumped into a couple other vsfilter deficiencies. > Of course I'll try to contact Gabest, but I'm not sure about the > results. Wouldn't it be better to roll our own subtitling filter? > Unfortunately I don't know who is going to write it, as I am > somewhat busy recently. Toff is familiar with Gabest's code in general. Maybe not the subtitle part. First we should get in touch with Gabest because he's the obvious one to fix his bugs and add features. If he doesn't want to (!) or doesn't answer, we will consider options, including forking his code or restarting from scratch. From that point we'll see who can work on this... > Btw, did anyone try Radlight's subtitler? Is it working? Well, I have nothing against Radlight. It would probably be impossible for them/us to work together, but if we give them the specs and the bug reports, they would fix it ? Does their filter work in other apps ? From paul at msn.com Wed Dec 8 19:20:05 2004 From: paul at msn.com (Paul Bryson) Date: Wed, 8 Dec 2004 12:20:05 -0600 Subject: [Matroska-devel] Re: [RFC] EBML Schema References: <871xe1yui2.fsf@p00ya.ath.cx> Message-ID: For some reason my posts to the ML are disappearing. Let's try this again. "Dean Scarff" wrote... > The EBML Schema schema is available at: > > or in XML Schema: > > > An EBML Schema instance for Matroska is available at: > It'll be a bit before I can really look into these, but they look good. How did you make them? Also, a few non-relevant questions for the inquisitive mind. In a spirit of friendliness, who are you and how in the world did you get started on this? Atamido From Liisachan at faireal.net Wed Dec 8 21:29:52 2004 From: Liisachan at faireal.net (Liisachan) Date: Thu, 09 Dec 2004 05:29:52 +0900 Subject: [usf-devel] [Matroska-devel] Re: Final call : USF muxing in MKV, and playbackon DShow and Gstreamer In-Reply-To: <41B72558.2030408@matroska.org> References: <20041208231328+#9nuD@faireal.net> <41B72558.2030408@matroska.org> Message-ID: <20041209052952Dln8pb@faireal.net> Christian HJ Wiesner wrote: > We are a small team, and do have very limited resources. One day the > fansubbers will have to make up their mind if they want us to > - make our stuff compliant with old, obsolete Win98 machines > - code USF DShow filters for machines powerful enough to render RUBY in > real time this either-or is actually not very logical, because (1) is a bug fix while (2) is a new feature; besides, it is not a given that USF doesn't work on Win98. personally I don't mind whether or not mkv works on win98, because I won't use win98. personally i don't mind whetehr or not USF supports RUBY or BIDI either, because I won't sub in Japanese nor Hebrew nor Arabic. (Altho this would mean a lot for those who sub in Japanese/Hebrew/Arabic) In reality, most fansubbers are still using avi+hardsub, altho mkv and rmvb are spreading slowly but steadily. > With respect to the fact that Win98 doesnt offer any kind of support for > modern chipsets, and the old PCs its normally installed on are slowly > dieing out, i vote for option #2. You are totally right, but i guess you can try to express that without potentially insulting windows 98/me users. > To support both should not be possible for us, You mean, it is a given that USF (*Universal* Subtitle Format) will never work on win98/me? > Else its again the matroska team facing all the hard work, and i admit > its hard and harder to find the motivation to do so. Your arguments to > still prefer OGM to MKV, because of vsfilter ( a 3rd party filter we > didnt even code ) crashing on Win98 when playing standard MKV files, is > not too helpful either. I hope all this makes sense to you, lets see > what we can come up with in future. OGM has its own practical forte altho it also has a lot of downsides compared to MKV. For one thing, from the users' side, OGM has better multi-audio support...(always easy to switch: Yes, I know the same thing is easy with MKV too if you are using MPC etc.)... not only the VSFilter problems. Besides, I didn't say I prefered one to the other. Unfortunately, OGM is a practically abandoned format, which nobody continues to develop anymore. So MKV will win by defualt anyway. But that doesnt mean I should hate one format nor I should prefer the other. The cans and cannots of OGM is much clearer than cans and cannots of MKV; in other words, OGM is stable/frozen/dead while MKV is living/changeable/vivid. These have upsides and downsides: for instance, (a) when you want to softsub using SRT, - if you use OGM, you are very sure that the resulted file plays fine on Windows - if you use MKV, you are very sure that the resulted file plays fine on Win2K/XP but not sure about 98/me (b) when you want to mux RV40 - if you want to use OGM, you'll just find it's impossible - if you use MKV, it's possible but there will be a certain amount of unsureness about replayability (Like, is this OK on Mac?) (c) when you want to mux FLAC - if you want to use OGM, you'll be just doomed - if you use MKV, this should be ok, thanks to CoreFlac 0.4 etc So, from the users' side, OGM vs MKV is not that simple. Basically MKV is much more powerful, but MKV is for advanced users atm, not for lazy/ordiary/newbie users. Some parts of MKV are already very stable, but many other parts of MKV are experimental, and might have unknown bugs--not too practical for general purposes. * S_SSA to S_TEXT/SSA (And Gabest's filters still support S_SSA while Haali's version doesnt) * New Lacing System (We found that older filters couldnt play nerwer files) * new '64-bit type' (ditto) Advanced users may understand and accept these complications, but ordinary users will be confused by a little discontinuity. These things just happen in vivid development. Ironically, OGM is 'safer' in this respect because it is stalled and (most probably) will never change no matter what. So please understand that when I somehow connotate OGM is 'safer', I'm not derogating MKV. Liisachan ps. it is too bad that MKV and the doom9 forum don't mix mainly just because a certain mod prefers OGM. everything will change anyway sooner or later tho From steve.lhomme at free.fr Wed Dec 8 22:21:23 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Wed, 08 Dec 2004 22:21:23 +0100 Subject: [usf-devel] [Matroska-devel] Re: Final call : USF muxing in MKV, and playbackon DShow and Gstreamer In-Reply-To: <20041209052952Dln8pb@faireal.net> References: <20041208231328+#9nuD@faireal.net> <41B72558.2030408@matroska.org> <20041209052952Dln8pb@faireal.net> Message-ID: <41B77053.4060702@free.fr> Liisachan a ?crit : > this either-or is actually not very logical, > because (1) is a bug fix while (2) is a new feature; > besides, it is not a given that USF doesn't work on Win98. I said the same to Christian. > OGM has its own practical forte altho it also has a lot of > downsides compared to MKV. For one thing, from the users' side, > OGM has better multi-audio support...(always easy to switch: Yes, > I know the same thing is easy with MKV too if you are using > MPC etc.)... not only the VSFilter problems. That one will vanish when Haali's splitter will become the official one. > (b) when you want to mux RV40 > - if you want to use OGM, you'll just find it's impossible > - if you use MKV, it's possible but there will be a certain > amount of unsureness about replayability (Like, is this OK on > Mac?) Indeed it's a big pb. We have told Real about this problem. Not that they care about pirate stuff. But in the end ppl will hate them for being so close-minded and use competitors instead. I personally won't encode in RV until this issue is solved (if ever). > * S_SSA to S_TEXT/SSA (And Gabest's filters still support S_SSA > while Haali's version doesnt) > * New Lacing System (We found that older filters couldnt play > nerwer files) > * new '64-bit type' (ditto) Well, the problem is spreading softwares with bugs (not spec compliant) and not being able to fix them (because of Gabest). VLC or other players never had any problems with 64-bits floats. Hopefully once we have the menu done and clean Wavpack support, the specs will be frozen. And we won't be the ones to blame if a software doesn't respect them. > ps. it is too bad that MKV and the doom9 forum don't mix > mainly just because a certain mod prefers OGM. everything will > change anyway sooner or later tho Things are getting harder on this side. The OGM zealot is still mod and alexnoe and Christian are banned. So we'll probably just move somewhere else. Users with questions can reach us by so many other means than Doom9... From mike at po.cs.msu.su Wed Dec 8 23:40:55 2004 From: mike at po.cs.msu.su (Mike Matsnev) Date: Thu, 09 Dec 2004 01:40:55 +0300 Subject: [usf-devel] [Matroska-devel] Re: Final call : USF muxing in MKV, and playbackon DShow and Gstreamer In-Reply-To: <20041209052952Dln8pb@faireal.net> References: <20041208231328+#9nuD@faireal.net> <41B72558.2030408@matroska.org> <20041209052952Dln8pb@faireal.net> Message-ID: <41B782F7.4000207@po.cs.msu.su> Liisachan wrote: > * S_SSA to S_TEXT/SSA (And Gabest's filters still support S_SSA > while Haali's version doesnt) I've added this codec id right after I got your notice, i.e. a few months ago. /Mike From moritz at bunkus.org Thu Dec 9 08:48:21 2004 From: moritz at bunkus.org (Moritz Bunkus) Date: Thu, 9 Dec 2004 08:48:21 +0100 Subject: [usf-devel] [Matroska-devel] Re: Final call : USF muxing in MKV, and playbackon DShow and Gstreamer In-Reply-To: <20041209052952Dln8pb@faireal.net> References: <20041208231328+#9nuD@faireal.net> <41B72558.2030408@matroska.org> <20041209052952Dln8pb@faireal.net> Message-ID: <20041209074821.GA13053@bunkus.org> Hey, just some random thoughts. > (a) when you want to softsub using SRT, > - if you use OGM, you are very sure that the resulted file plays > fine on Windows Interesting as SRTs don't specify a charset anywhere. So I'd expect people to run into problems, e.g. with Eastern Europe charsets if your locale is not Eastern Europe. Add to that the cross platform issues... > (c) when you want to mux FLAC > - if you want to use OGM, you'll be just doomed Which I find really curious as flacenc can output to OggFLAC (FLAC embedded in Ogg). Ok, my ogmtools can't do that either, but that's more a "political" decision. > Some parts of MKV are already very stable, but many other parts > of MKV are experimental, and might have unknown bugs--not too > practical for general purposes. > > * New Lacing System (We found that older filters couldnt play > nerwer files) That one was necessary. It should have done right at the start though. > * new '64-bit type' (ditto) That one's clearly my fault. I was just happy that I had satisfied the "audio only" crowd. And as this bug didn't affect me I was simply not thinking about all the existing Matroska installations which would suddenly not be able to play new Matroska files anymore. Bad decision. Mosu -- If Darl McBride was in charge, he'd probably make marriage unconstitutional too, since clearly it de-emphasizes the commercial nature of normal human interaction, and probably is a major impediment to the commercial growth of prostitution. - Linus Torvalds From steve.lhomme at free.fr Thu Dec 9 14:35:43 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Thu, 09 Dec 2004 14:35:43 +0100 Subject: [Matroska-devel] To control track or Not To control track ? Message-ID: <41B854AF.8000607@free.fr> Hi, The last bit missing now in Matroska files for the full DVD experience (at least experimental ones) is the use of buttons in menues. Buttons in DVDs are using 3 parts of the format : - (vob) subtitles to display + highlight the buttons - MPEG2 PCI packets to store the button meta-informations (numbers, commands) - DVD commands stored in the PCI packet The first part can be handled easily by Matroska the way it is now. I'm just not sure yet if DVDs can have 2 subtitles streams at the same time. But I think so. Even if it doesn't it should be supported in Matroska. Unfortunately it's unlikely that any player can support this yet. Maybe 2 vsfilters can be loaded and running at once ? The PCI packets and DVD commands are tied together. And we need to decide how to treat them. On DVDs they are stored inside the stream. And IMO it makes sense to do the same. Especially if you consider that buttons could move/morph with a picture (even though I doubt it's used yet). So if we store it in the stream, how do we do it ? My options are : - tied to the vobsub packets - attached to vobsub packets as codec private info - using another track (Control Track) for PCI packets I have no real point of view on this. #2 is probably ugly and complicated for nothing. #1 would need changes to vsfilter and we have no idea if Gabest is willing to help. And we are not sure it will be backward compatible with older filters. So IMO #3 seems to be the cleanest way. Because for the moment we'd have a codec that uses standard PCI packets taken from a DVD and stored as is. But we could imagine other Control Track codecs much simpler and/or with more features. Such codecs could also make use of other subtitle formats than vobsub ones (even though they are usually tied together). Opinions ? -- robUx4 on blog From mike at po.cs.msu.su Thu Dec 9 14:49:24 2004 From: mike at po.cs.msu.su (Mike Matsnev) Date: Thu, 09 Dec 2004 16:49:24 +0300 Subject: [Matroska-devel] To control track or Not To control track ? In-Reply-To: <41B854AF.8000607@free.fr> References: <41B854AF.8000607@free.fr> Message-ID: <41B857E4.2060901@po.cs.msu.su> Steve Lhomme wrote: > So if we store it in the stream, how do we do it ? > My options are : > - tied to the vobsub packets > - attached to vobsub packets as codec private info > - using another track (Control Track) for PCI packets I vote for #3 /Mike From steve.lhomme at free.fr Thu Dec 9 15:08:16 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Thu, 09 Dec 2004 15:08:16 +0100 Subject: [Matroska-devel] To control track or Not To control track ? In-Reply-To: <41B857E4.2060901@po.cs.msu.su> References: <41B854AF.8000607@free.fr> <41B857E4.2060901@po.cs.msu.su> Message-ID: <41B85C50.4070601@free.fr> Mike Matsnev a ?crit : > Steve Lhomme wrote: > >> So if we store it in the stream, how do we do it ? >> My options are : >> - tied to the vobsub packets >> - attached to vobsub packets as codec private info >> - using another track (Control Track) for PCI packets > > > I vote for #3 Good. I guess Mosu should be OK and probably alex too. (if applies :) So I'm going to extract .btn files from DVDs. These file will contain the PCI packets the same way .sub files contain VobSub packets. I'll add the code to mkvmerge to mux them in Matroska. So as a /new/ Track Type (0x20), we have to check if any extra meta-information is needed in the Tracks entry. AFAIK, nothing is needed. Maybe the Subtitle track(s) it's reffering to ? From paul at msn.com Thu Dec 9 17:20:33 2004 From: paul at msn.com (Paul Bryson) Date: Thu, 9 Dec 2004 10:20:33 -0600 Subject: [Matroska-devel] Re: To control track or Not To control track ? References: <41B854AF.8000607@free.fr> <41B857E4.2060901@po.cs.msu.su> <41B85C50.4070601@free.fr> Message-ID: "Steve Lhomme" wrote... >Mike Matsnev a ?crit : >> Steve Lhomme wrote: >>> - using another track (Control Track) for PCI packets >> >> I vote for #3 > > Good. I guess Mosu should be OK and probably alex too. Control tracks will never die! Muahahaha! Atamido From unmei at matroska.org Thu Dec 9 22:30:09 2004 From: unmei at matroska.org (unmei) Date: Thu, 09 Dec 2004 22:30:09 +0100 Subject: [usf-devel] [Matroska-devel] Re: Final call : USF muxing in MKV, and playbackon DShow and Gstreamer In-Reply-To: <20041209052952Dln8pb@faireal.net> References: <20041208231328+#9nuD@faireal.net> <41B72558.2030408@matroska.org> <20041209052952Dln8pb@faireal.net> Message-ID: <41B8C3E1.5050302@matroska.org> Liisachan wrote: [snip] >You mean, it is a given that USF (*Universal* Subtitle Format) >will never work on win98/me? > > [snip] This is of course not true on a abstract level. If any program can support (decode) UTF-8 and rasterise Unicode characters on Win98, USF is theoretically possible on win98 as well. The problem is rather, how to do it (how high is the cost) ie are there special libs to include for unicode support, is there a native wide-textout function, or one that can be incorporated without too much hassle. For me it's quite clear i won't change the way my rasteriser works for legacy support. Initially the rasteriser was written for internal use in u96 wich onyl runs on w2k+ anyway. But if it is only a matter of including unicows.dll, much praying and maybe including a few lines in the code it's of course ok with me. It's just that mess-generating in my code is reserved for adding fancy stuff only :) From spyder at matroska.org Fri Dec 10 18:24:47 2004 From: spyder at matroska.org (John Cannon) Date: Fri, 10 Dec 2004 11:24:47 -0600 Subject: [Matroska-devel] Re: New dshow splitter In-Reply-To: <41B61BC6.5030004@po.cs.msu.su> References: <41B61BC6.5030004@po.cs.msu.su> Message-ID: I found a big problem... When playing an XviD+Vorbis MKV, everything is fine until you seek. After seeking the audio disappears for a bit and then the video freezes. After that they both come back but start jerking as if trying to get back in synch or somehting. This happens on all my XviD+Vorbis MKVs using this version of the splitter. The same files play fine with older filters. John From mike at po.cs.msu.su Fri Dec 10 20:38:00 2004 From: mike at po.cs.msu.su (Mike Matsnev) Date: Fri, 10 Dec 2004 22:38:00 +0300 Subject: [Matroska-devel] Re: New dshow splitter In-Reply-To: References: <41B61BC6.5030004@po.cs.msu.su> Message-ID: <41B9FB18.1080504@po.cs.msu.su> John Cannon wrote: > When playing an XviD+Vorbis MKV, everything is fine until you seek. > After seeking the audio disappears for a bit and then the video freezes. > After that they both come back but start jerking as if trying to get > back in synch or somehting. This happens on all my XviD+Vorbis MKVs > using this version of the splitter. The same files play fine with older > filters. Isn't this a known bug in old corevorbis? /Mike From spyder at matroska.org Sat Dec 11 17:15:26 2004 From: spyder at matroska.org (John Cannon) Date: Sat, 11 Dec 2004 10:15:26 -0600 Subject: [Matroska-devel] Re: New dshow splitter In-Reply-To: <41B9FB18.1080504@po.cs.msu.su> References: <41B61BC6.5030004@po.cs.msu.su> <41B9FB18.1080504@po.cs.msu.su> Message-ID: <41BB1D1E.3060708@matroska.org> Mike Matsnev wrote: > John Cannon wrote: > >> When playing an XviD+Vorbis MKV, everything is fine until you seek. >> After seeking the audio disappears for a bit and then the video >> freezes. After that they both come back but start jerking as if >> trying to get back in synch or somehting. This happens on all my >> XviD+Vorbis MKVs using this version of the splitter. The same files >> play fine with older filters. > > Isn't this a known bug in old corevorbis? > > /Mike > _______________________________________________ > Matroska-devel mailing list > Matroska-devel at lists.matroska.org > http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel > Yes changing to the newest fixed it. I was still using the one from the pack. John From cd at kalkatraz.de Tue Dec 14 21:30:46 2004 From: cd at kalkatraz.de (Lars Weitze) Date: Tue, 14 Dec 2004 21:30:46 +0100 Subject: [Matroska-devel] Simple way to read just the subtitle and audio stream info from MKV Message-ID: <20041214213046.54198a9f.cd@kalkatraz.de> Hi, Is there a simple way to just get infos about how many subtitle, audio and video streams (and maybe which language) are included? Because i like too integrate this function into my settop-box style mplayer frontend called "animecenter" (which will be GPLed). Regards Lars -- "People can't ever know they understand something. They can only hope that they understand." GITS - Innocence PGP fingerprint: 4950 8576 778F DEDF 85D1 C04D 586F 2C45 E714 E13A From moritz at bunkus.org Tue Dec 14 22:24:36 2004 From: moritz at bunkus.org (Moritz Bunkus) Date: Tue, 14 Dec 2004 22:24:36 +0100 Subject: [Matroska-devel] Simple way to read just the subtitle and audio stream info from MKV In-Reply-To: <20041214213046.54198a9f.cd@kalkatraz.de> References: <20041214213046.54198a9f.cd@kalkatraz.de> Message-ID: <20041214212436.GK13053@bunkus.org> Hey, > Is there a simple way to just get infos about how many subtitle, audio and > video streams (and maybe which language) are included? Because i like too > integrate this function into my settop-box style mplayer frontend called > "animecenter" (which will be GPLed). Basically the same advice that I've given you about the OGM question ;) You can use my mkvtoolnix package ( http://www.bunkus.org/videotools/mkvtoolnix/ ) and use mkvmerge (! not mkvinfo !) for identification like this: 0 mosu at tahiri:~/prog/video/mkvtoolnix/data$ mkvmerge --identify-verbose v.mkv File 'v.mkv': container: Matroska Track ID 1: video (V_MS/VFW/FOURCC, DIV3) [language:und ] Track ID 2: audio (A_VORBIS) [language:und ] If you need something that's more like a library then I don't know if there's some easy to use media info library that contains Matroska support. We talked about adding something like that from time to time, but we've never gotten around to doing it though. (I think the freevo project now contains some code for Matroska, lemme try to find it... Yes, as part of mmpython: http://cvs.sourceforge.net/viewcvs.py/mmpython/mmpython/video/mkvinfo.py?view=markup ) Mosu -- If Darl McBride was in charge, he'd probably make marriage unconstitutional too, since clearly it de-emphasizes the commercial nature of normal human interaction, and probably is a major impediment to the commercial growth of prostitution. - Linus Torvalds From steve.lhomme at free.fr Fri Dec 17 11:13:39 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Fri, 17 Dec 2004 11:13:39 +0100 Subject: [Matroska-devel] Re: Patch++ In-Reply-To: <20041217095807.GW13053@bunkus.org> References: <41C2A54C.6040203@free.fr> <20041217095807.GW13053@bunkus.org> Message-ID: <41C2B153.7010102@free.fr> Moritz Bunkus a ?crit : > Hey, > > A couple of comments. > > The rest looks ok (well some formatting issues, but I'll just fix those > ;)). I can fix the issues I've pointed out above if you want, or you can > fix them. I don't know when I'll be home tonight (Christmas party at our > company), but maybe I can apply it afterwards. If not then tomorrow. I'll do it and send it back to you. I'm "rushing" because I'd like an MMG build that can add button files too. This way I could make a small guide on how to use DMX + MTX. And also generate the mkvmerge command line to use in DMX. But I don't need MMG for that... Finally I'd like Haali to have a working version for him to work on the DS filter for all the new features (a lot of work to do). Did your commit from last night fix the MinGW build ? From steve.lhomme at free.fr Sat Dec 18 11:03:26 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Sat, 18 Dec 2004 11:03:26 +0100 Subject: [Matroska-devel] Re: Matroska In-Reply-To: <1103345839.41c3b8afa40c8@www.webmail.impulse.net> References: <41C2E5DF.60905@free.fr> <1103345839.41c3b8afa40c8@www.webmail.impulse.net> Message-ID: <41C4006E.60108@free.fr> dbryant at impulse.net a ?crit : > Hi Steve, > > Don't apologize for the long silence, but I was starting to wonder what you > guys were up to... ;-) Just handling "real" life and priorities ;) > I've actually been really busy myself because I got a new job up near San > Francisco, so it's been pretty hectic with commuting and, of course, > starting a new job. Cool, I hope you like it. > Unfortunately, the header for WavPack 4 is completely different than the > previous versions. I don't know what you guys are doing exactly, but you > might want to not bother with older WavPack files. They were not block > oriented at all; after the header the encoded data just ran continuously to > the end of the file. They started with the original RIFF header from the wav > file, then there was a little wavpack header with some information needed > for decoding, then the raw WavPack data. OK, so we'll support only Wavpack 4. (good I use A_WAVPACK4 as the codec ID) > I am trying to finish up version 4.2. There is not much that should concern > you, except that it will compile and work with 64-bit compilers. Also, I Hopefully I'll be concerned soon ;) > have been meaning to add a flag to the playback code so that it just > decodes whatever blocks come in; I am afraid that some of my error > detection stuff will get confused if you try to just decode from the middle > of a file (although I haven't actually tried it). I'll keep you posted on > that, and even if it is a problem it will be easy to fix. OK. In parallel to Matroska integration I think we'll need a DirectShow filter to play it. I hope to motivate our people to work on it. Toff (Christophe Paris) already have a canvas he used for CoreVorbis, CoreAAC and CoreFLAC, so CoreWavpack shouldn't be too hard. The difference is that it should handle 3 different input packets : - full Wavpack packets - lossy Wavpack packets - lossy + correction Wavpack packets But it's really not a hard issue. Then it could also play "original" Wavpack files too. One of the drawback on Wavpack in Matroska is that we can only store the packets with the same number of channels and sampling freq. Hopefully I don't think there are many sources that are different than that... > BTW, my wife keeps bugging me to take her to Paris this spring (she met her > sister there last year and enjoyed it). Maybe we can meet and have a coffee > one day... :-) Of course ! I'd be glad to meet you. > Thanks... cya Steve From steve.lhomme at free.fr Sun Dec 19 11:04:03 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Sun, 19 Dec 2004 11:04:03 +0100 Subject: [Matroska-devel] WavPack hybrid Message-ID: <41C55213.9090103@free.fr> Hi David, I can already mux basic WavPack files into Matroska. Now the interresting part is starting : hybrid mode. I almost have everything needed. Except that I don't know if I should keep the header of the correction part of if all data (except the CRC ?) are useless one you know it's a correction part. I want to keep as few useless data as possible. But still be allowed to extract data from Matroska and recover 100% of the original files. What do you think ? I already stip the header ID and packet size, and one is constant and the other is handled by Matroska. cya -- robUx4 on blog From steve.lhomme at free.fr Mon Dec 20 09:29:25 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Mon, 20 Dec 2004 09:29:25 +0100 Subject: [Matroska-devel] Re: WavPack hybrid In-Reply-To: <1103493700.41c5fa44bfbdf@www.webmail.impulse.net> References: <41C55213.9090103@free.fr> <1103493700.41c5fa44bfbdf@www.webmail.impulse.net> Message-ID: <41C68D65.1070207@free.fr> dbryant at impulse.net a ?crit : > Quoting Steve Lhomme : > > >>Hi David, >> >>I can already mux basic WavPack files into Matroska. Now the >>interresting part is starting : hybrid mode. I almost have everything >>needed. Except that I don't know if I should keep the header of the >>correction part of if all data (except the CRC ?) are useless one you >>know it's a correction part. > > > Yes, the only difference between the 32-byte headers of wv files and wvc > files is the "crc" field. This is actually a little unfortunate because it > would have been nice to have a flag bit to indicate the correction file. So > now I have to look a little further into the data to make sure I have the > right one, but it's not that big a deal. Good. So maybe I'll only keep that. Maybe in the end a .wv+.wvc will be smaller in Matroska than the original files ;) >>I want to keep as few useless data as possible. But still be allowed to >>extract data from Matroska and recover 100% of the original files. >> >>What do you think ? >> >>I already stip the header ID and packet size, and one is constant and >>the other is handled by Matroska. > > > Sounds good. I also assume that you have the "index_no" and "track_no" taken > care of in Matroska to handle complete CD images (although I do not use Yes, but I wasn't sure about these ones. Are there already Wavpack files using multiple tracks ? The index is like a seek point ? > these yet myself). I am now thinking of having a "IGNORE_BLOCK_INDEX" flag > when opening WavPack streams so you won't have to worry about that. Of > course, you will have to make sure that all of the blocks from the one > marked "INITIAL_BLOCK" to the one marked "FINAL_BLOCK" are available to the > decoder when you have more than 2 channels (or if someone encodes 2 channels > with 2 mono streams). Mh, I don't really understand. Why ? Can't you cut a Wavpack file wherever you want ? From steve.lhomme at free.fr Wed Dec 22 13:57:40 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Wed, 22 Dec 2004 13:57:40 +0100 Subject: [Matroska-devel] Re: WavPack hybrid In-Reply-To: <1103564955.41c7109b2e1bf@www.webmail.impulse.net> References: <41C55213.9090103@free.fr> <1103493700.41c5fa44bfbdf@www.webmail.impulse.net> <41C68D65.1070207@free.fr> <1103564955.41c7109b2e1bf@www.webmail.impulse.net> Message-ID: <41C96F44.2010906@free.fr> dbryant at impulse.net a ?crit : > For mono or stereo WavPack files, each block holds some number of mono or > stereo samples. You don't really need the whole block to start decoding > samples, but the standard library does suck in a whole block before it > starts decoding. The "tiny" decoder reads the data as it decodes because it > is designed to work with very little memory. The regular library could be > set up this way also, but would only work for stereo or mono audio. > > For multichannel audio the samples are split into seperate blocks. So, for > example, for 5.1 audio we use 4 blocks for each group of samples: > > block 1: front left + front right (stereo) INITIAL_BLOCK flag is set > block 2: center (mono) > block 3: subwoofer (mono) > block 4: back left + back right (stereo) FINAL_BLOCK flag is set > > This interleaving is handled by the WavPack library on encode and decode and > is transparent to the caller. The actual data that the application sends or > receives is six 32-bit words for each sample. > > However, on decode all 4 blocks must be read into memory by the decoder > because it needs to be decoding all 4 in parallel to be able to reconstruct > the original data. That's why I say that the minimum "chunk" of WavPack data > that is independently decodable is a single block for mono or stereo, or a > sequence of blocks for multichannel (from INITIIAL_BLOCK to FINAL_BLOCK). > In mono or stereo streams every WavPack blocks has both flags set. Also > note that for multichannel streams the WavPack encoder puts fewer samples > in each block so that the total size that needs to be pulled into memory is > not any larger that standard audio. OK, I think I understand. Do you have a sample 5.1 file that I could debug with ? I'm not sure how to produce one... From what I saw in the WavPack files I produced (stereo) the INITIAL_BLOCK is set on the first frame and FINAL_BLOCK is set on the last one. And so the same flags have different meanings for multichannel files ? > During encoding the application can put exactly how many sample in each > block as desired. Once encoded however, the blocks can not easily be split > up at different points (although for lossless you could easily re-encode). Yes. This is no problem for us. We check the number of samples for each block and generate the timecode & duration accordingly. Steve From chris at matroska.org Mon Dec 27 11:01:10 2004 From: chris at matroska.org (Christian HJ Wiesner) Date: Mon, 27 Dec 2004 11:01:10 +0100 Subject: [Matroska-devel] Status Quo of new features Message-ID: <41CFDD66.2040208@matroska.org> Hi, i just thought i make a short overview of what will be coming shortly, so everyone reading the list is aware : *1. Menues : * Latest Version of robux4's DVDMenuXtractor creates XML files that can be read by mkvtoolnix dev branch, files with menues can be muxed fine already. *To-Do* : Some bug fixing, the rest is mainly playback related. Haali has to update his splitter and someone ( also Haali ? ) has to make a MKV menue navigator filter ; Biggest Problem : Support on Linux players :( ..... maybe VLC could be the best option ? Or Xine ? *2. MPEG 1/2 :* spyder's code is already in mkvmerge SVN and muxing of MPEG 1/2 ES streams works. Read for releasing i would dare to say, no bugs found in my last test files. *To-Do* : MPEG PS parser *3. H.264 :* Mosu added experimental code to mkvmerge, reading AVC / h.264 from MP4 files. It worked for some members and users, who successfully muxed some MP4 AVC files created by Nero Recode. *To-Do* : Defining if this way of muxing should be the way to go ; more testing, bug fixing, also with files from other encoders ; muxing of h.264 from MPG container ( Cyberlink, Mainconcept encoders ) *4. Wavpack 4 :* robux4 wrote the first patch for this last week, he alone did test it so far. *To-Do* : Decide about the way to go for playback : Using Radlight filter ( included in our packs :O ?? ) or bug Toff about a CoreWavpack ? Is there a packet decoder for fb2k ? Who can update the fb2k plugin ? *Still Pending :* - new pack with Haali's splitter and a wavpack decoder - super chapters ( = former control tracks ) plus enhanced super chapter editor in mmg and amg - USF support - DV ( camcorder, lossy compression ) support, type 1 ( a +v = 1 stream ) and 2 ( a , a+v : 2 streams ); mainly some AVI parsing and defining how to handle the embedded audio stream ( AVI has to repeat the PCM WAV audio stream --> ENORMOUS overhead ) - native MPEG4 with correct b-frame handling ( status ? ) - menue support in TCMP5 - Gstreamer muxer update - MPC muxing ( ever ? ) - NLE video editor based on Gstreamer ( project exists ! ) - codec API, on top of Gstreamer Did i miss anything ? Guys, we have come a real long way together. It's big fun being in the team, lets hope everything will work out as we planned it. Christian From steve.lhomme at free.fr Mon Dec 27 11:25:03 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Mon, 27 Dec 2004 11:25:03 +0100 Subject: [Matroska-devel] Status Quo of new features In-Reply-To: <41CFDD66.2040208@matroska.org> References: <41CFDD66.2040208@matroska.org> Message-ID: <41CFE2FF.3040805@free.fr> > *1. Menues : * > > Latest Version of robux4's DVDMenuXtractor creates XML files that can be > read by mkvtoolnix dev branch, files with menues can be muxed fine already. > > *To-Do* : Some bug fixing, the rest is mainly playback related. Haali > has to update his splitter and someone ( also Haali ? ) has to make a > MKV menue navigator filter ; Biggest Problem : Support on Linux players > :( ..... maybe VLC could be the best option ? Or Xine ? The main problem for the moment in DMX is that the time extracted from .IFO files don't correspond to frame times when you read the raw MPEG2 stream. I have to find out why and fix that. Otherwise everything is ready. > *4. Wavpack 4 :* > > robux4 wrote the first patch for this last week, he alone did test it so > far. > > *To-Do* : Decide about the way to go for playback : Using Radlight > filter ( included in our packs :O ?? ) or bug Toff about a CoreWavpack ? > Is there a packet decoder for fb2k ? Who can update the fb2k plugin ? It would be great if Toff could do at least a canvas for CoreWavpack. I could do the rest. > *Still Pending :* > > - new pack with Haali's splitter and a wavpack decoder > - super chapters ( = former control tracks ) plus enhanced super chapter > editor in mmg and amg > - USF support > - DV ( camcorder, lossy compression ) support, type 1 ( a +v = 1 stream > ) and 2 ( a , a+v : 2 streams ); mainly some AVI parsing and defining > how to handle the embedded audio stream ( AVI has to repeat the PCM WAV > audio stream --> ENORMOUS overhead ) As I've worked on MTX a bit, I think I could be able to add DV support too. Actually we would store the audio and video in separate tracks, not using the complex type, since the DV format is known we can demux it. > - MPC muxing ( ever ? ) Mosu will accept patches from anyone who knows enough about MPC. From steve.lhomme at free.fr Mon Dec 27 11:28:43 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Mon, 27 Dec 2004 11:28:43 +0100 Subject: [Matroska-devel] Status Quo of new features In-Reply-To: <41CFE2FF.3040805@free.fr> References: <41CFDD66.2040208@matroska.org> <41CFE2FF.3040805@free.fr> Message-ID: <41CFE3DB.2030904@free.fr> Steve Lhomme a ?crit : >> *4. Wavpack 4 :* >> >> robux4 wrote the first patch for this last week, he alone did test it >> so far. >> >> *To-Do* : Decide about the way to go for playback : Using Radlight >> filter ( included in our packs :O ?? ) or bug Toff about a CoreWavpack >> ? Is there a packet decoder for fb2k ? Who can update the fb2k plugin ? > > > It would be great if Toff could do at least a canvas for CoreWavpack. I > could do the rest. PS: muxing/demuxing of normal/lossy/hybrid files already work. Now I'm adding 5.1 support. From paul at msn.com Mon Dec 27 12:08:26 2004 From: paul at msn.com (Paul Bryson) Date: Mon, 27 Dec 2004 05:08:26 -0600 Subject: [Matroska-devel] Re: Status Quo of new features References: <41CFDD66.2040208@matroska.org> <41CFE2FF.3040805@free.fr> Message-ID: "Steve Lhomme" wrote... >> - DV ( camcorder, lossy compression ) support, type 1 ( a +v = 1 stream ) >> and 2 ( a , a+v : 2 streams ); mainly some AVI parsing and defining how >> to handle the embedded audio stream ( AVI has to repeat the PCM WAV audio >> stream --> ENORMOUS overhead ) > > As I've worked on MTX a bit, I think I could be able to add DV support > too. Actually we would store the audio and video in separate tracks, not > using the complex type, since the DV format is known we can demux it. DV is strange because if you encode only video to DV, it still uses the same space for the PCM, but it marks it as no audio. It would be possible to store just the video frame data, but the splitter would need to recreate Video + Null Audio stream on playback for anything to be able to use it. If I recall correctly, it basically uses something like JPEG images for the video, very similar to MJPEG video. I know we all have visions of using DV video with Wavpack audio without having to store all of that silly PCM overhead. http://www.adamwilt.com/DV-FAQ-tech.html "DV video information is carried in a nominal 25 megabit per second (Mbits/sec) data stream. Once you add in audio, subcode (including timecode), Insert and Track Information (ITI), and error correction, the total data stream comes to about 29 Mbits/sec or 3.6 MBytes/sec." That means you could shave off about 14% overhead for video only stuff by storing only the video frames. Or about 9% for video + audio. Impressive, but sounds like a good deal of work. Atamido From steve.lhomme at free.fr Mon Dec 27 12:23:34 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Mon, 27 Dec 2004 12:23:34 +0100 Subject: [Matroska-devel] Re: Status Quo of new features In-Reply-To: References: <41CFDD66.2040208@matroska.org> <41CFE2FF.3040805@free.fr> Message-ID: <41CFF0B6.4030506@free.fr> Paul Bryson a ?crit : > "Steve Lhomme" wrote... > >>>- DV ( camcorder, lossy compression ) support, type 1 ( a +v = 1 stream ) >>>and 2 ( a , a+v : 2 streams ); mainly some AVI parsing and defining how >>>to handle the embedded audio stream ( AVI has to repeat the PCM WAV audio >>>stream --> ENORMOUS overhead ) >> >>As I've worked on MTX a bit, I think I could be able to add DV support >>too. Actually we would store the audio and video in separate tracks, not >>using the complex type, since the DV format is known we can demux it. > > > DV is strange because if you encode only video to DV, it still uses the same > space for the PCM, but it marks it as no audio. It would be possible to > store just the video frame data, but the splitter would need to recreate > Video + Null Audio stream on playback for anything to be able to use it. If > I recall correctly, it basically uses something like JPEG images for the > video, very similar to MJPEG video. I know we all have visions of using DV > video with Wavpack audio without having to store all of that silly PCM > overhead. As long as all data needed to reconstruct the video is present in Matroska, that's fine. From christophe.paris at free.fr Mon Dec 27 12:03:20 2004 From: christophe.paris at free.fr (Christophe PARIS) Date: Mon, 27 Dec 2004 12:03:20 +0100 Subject: [Matroska-devel] Status Quo of new features In-Reply-To: <41CFDD66.2040208@matroska.org> References: <41CFDD66.2040208@matroska.org> Message-ID: <41CFEBF8.2060405@free.fr> Christian HJ Wiesner wrote: > *4. Wavpack 4 :* > > robux4 wrote the first patch for this last week, he alone did test it > so far. > > *To-Do* : Decide about the way to go for playback : Using Radlight > filter ( included in our packs :O ?? ) or bug Toff about a CoreWavpack > ? Is there a packet decoder for fb2k ? Who can update the fb2k plugin ? Looks like you still doesn't get the difference between a source filter with no input and so that can't bes used with a splitter and a decoder filter. Btw, you guys can use TTA_DS filters as a canvas. I can't do any C++ work this week. Regards Toff From rbultje at ronald.bitfreak.net Mon Dec 27 12:15:01 2004 From: rbultje at ronald.bitfreak.net (Ronald S. Bultje) Date: Mon, 27 Dec 2004 12:15:01 +0100 Subject: [Matroska-devel] Status Quo of new features In-Reply-To: <41CFE2FF.3040805@free.fr> References: <41CFDD66.2040208@matroska.org> <41CFE2FF.3040805@free.fr> Message-ID: <1104146100.25472.2.camel@tux.lan> Hi, On Mon, 2004-12-27 at 11:25, Steve Lhomme wrote: > > - MPC muxing ( ever ? ) > > Mosu will accept patches from anyone who knows enough about MPC. I've played with it, what info do you need? Does it just need to be frame-boundary-cut? Or are you looking for more fancy stuff? Ronald -- Ronald S. Bultje From steve.lhomme at free.fr Mon Dec 27 13:18:41 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Mon, 27 Dec 2004 13:18:41 +0100 Subject: [Matroska-devel] Status Quo of new features In-Reply-To: <1104146100.25472.2.camel@tux.lan> References: <41CFDD66.2040208@matroska.org> <41CFE2FF.3040805@free.fr> <1104146100.25472.2.camel@tux.lan> Message-ID: <41CFFDA1.7030908@free.fr> Ronald S. Bultje a ?crit : > Hi, > > On Mon, 2004-12-27 at 11:25, Steve Lhomme wrote: > >>>- MPC muxing ( ever ? ) >> >>Mosu will accept patches from anyone who knows enough about MPC. > > > I've played with it, what info do you need? Does it just need to be > frame-boundary-cut? Or are you looking for more fancy stuff? Frame boundaries, sampling freq, number of samples in the frame. That should be enough. But AFAIK Musepack is not made to be cut this way, because some frames depend on previous frames... Are you aware of that ? Because to store it in a clean way in Matroska we need to know what frames it depends on. From jcsston at jory.info Mon Dec 27 13:19:39 2004 From: jcsston at jory.info (Jory Stone) Date: Mon, 27 Dec 2004 06:19:39 -0600 Subject: [Matroska-devel] Re: Status Quo of new features References: <41CFDD66.2040208@matroska.org> <41CFE2FF.3040805@free.fr> <41CFF0B6.4030506@free.fr> Message-ID: <004d01c4ec0e$5b9ab7a0$6b00a8c0@jcsston> Would we create a new subtitle format to store the DV timestamp/codes? That is the biggest problem I see, and the fact that splitters will need to be able to decode the audio and remux all 3 back together before outputting it to the DV decoder. Jory ----- Original Message ----- From: "Steve Lhomme" To: "Discussion about the current and future development of Matroska" Sent: Monday, December 27, 2004 5:23 AM Subject: Re: [Matroska-devel] Re: Status Quo of new features Paul Bryson a ?crit : > "Steve Lhomme" wrote... > >>>- DV ( camcorder, lossy compression ) support, type 1 ( a +v = 1 stream ) >>>and 2 ( a , a+v : 2 streams ); mainly some AVI parsing and defining how >>>to handle the embedded audio stream ( AVI has to repeat the PCM WAV audio >>>stream --> ENORMOUS overhead ) >> >>As I've worked on MTX a bit, I think I could be able to add DV support >>too. Actually we would store the audio and video in separate tracks, not >>using the complex type, since the DV format is known we can demux it. > > > DV is strange because if you encode only video to DV, it still uses the > same space for the PCM, but it marks it as no audio. It would be possible > to store just the video frame data, but the splitter would need to > recreate Video + Null Audio stream on playback for anything to be able to > use it. If I recall correctly, it basically uses something like JPEG > images for the video, very similar to MJPEG video. I know we all have > visions of using DV video with Wavpack audio without having to store all > of that silly PCM overhead. As long as all data needed to reconstruct the video is present in Matroska, that's fine. _______________________________________________ Matroska-devel mailing list Matroska-devel at lists.matroska.org http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel From steve.lhomme at free.fr Mon Dec 27 13:37:30 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Mon, 27 Dec 2004 13:37:30 +0100 Subject: [Matroska-devel] Re: Status Quo of new features In-Reply-To: <004d01c4ec0e$5b9ab7a0$6b00a8c0@jcsston> References: <41CFDD66.2040208@matroska.org> <41CFE2FF.3040805@free.fr> <41CFF0B6.4030506@free.fr> <004d01c4ec0e$5b9ab7a0$6b00a8c0@jcsston> Message-ID: <41D0020A.4020903@free.fr> Jory Stone a ?crit : > Would we create a new subtitle format to store the DV timestamp/codes? > That is the biggest problem I see, and the fact that splitters will need > to be able to decode the audio and remux all 3 back together before > outputting it to the DV decoder. Why would you want a stream to ouput the timestamp/codes ? We can keep them with the video (probably not with the raw PCM) so that it can be used elsewhere. Also the DV decoder thing is, once again, a windows centric problem. Maybe other libraries in Linux can handle raw DV-MJPEG... Maybe that could be the basis of CoreDV too ;) From moritz at bunkus.org Mon Dec 27 15:44:51 2004 From: moritz at bunkus.org (Moritz Bunkus) Date: Mon, 27 Dec 2004 15:44:51 +0100 Subject: [Matroska-devel] Status Quo of new features In-Reply-To: <41CFDD66.2040208@matroska.org> References: <41CFDD66.2040208@matroska.org> Message-ID: <20041227144451.GJ17631@bunkus.org> Hey, > Biggest Problem : Support on Linux players :( ..... maybe VLC could be > the best option ? Or Xine ? Either one of those, but definitely not mplayer ;) > *2. MPEG 1/2 :* > > *To-Do* : MPEG PS parser I wanted to work on that a bit, taking ideas from bbdemux. > *3. H.264 :* > > Mosu added experimental code to mkvmerge, reading AVC / h.264 from MP4 > files. It worked for some members and users, who successfully muxed some > MP4 AVC files created by Nero Recode. Problem is that Haali does not know why Nero's decoder frells the timestamps, and other decoders are not ready yet (if I understood him correctly). My problem is that I'm trying to get the AR information from the bitstream, and this proves to be way more difficult than it was with MPEG 4 layer 2. > *4. Wavpack 4 :* > > robux4 wrote the first patch for this last week, he alone did test it so > far. I've only tested muxing a bit, but nothing more. Steve has sent me a couple of patches, and I'm about to apply the latest one tonight. > *Still Pending :* > > - new pack with Haali's splitter and a wavpack decoder >From user feedback on doom9.org (yes, I still go there) it seems like there are still a couple of problems for which Gabest's splitter works better than Haali's: http://forum.doom9.org/showthread.php?s=&threadid=80762&perpage=20&pagenumber=4 Yong: "This matroska splitter can't "split" the FLAC audio format..." Shinobu: "any chance to get the autoloading of subtitle works ? i also have some seeking lags (not cpu problem) and strange sound bug when seek with AAC+. i've none of these bugs with gabest splitter. also your splitter doesn't seems to realy work on 98/me, do you plan to devel that ?" > - super chapters ( = former control tracks ) plus enhanced super chapter > editor in mmg and amg Hmmmm > - native MPEG4 with correct b-frame handling ( status ? ) I could start working on that again. Playback in mplayer should work now (due to my changes for MPEG 2 playback ;), but I still haven't gotten the bitstream-frame-separation done. Some things that are missing/have to be worked on in mkvtoolnix: - support for concatenating files in mmg (not mkvmerge, that part is working more or less -- here I need feedback before I continue working on it); - native MPEG 4 layer 2 (IMHO not THAT important); - finish WavPack support (should be soon with Steve's work); - MPEG 1 / 2 PS demuxing (IMHO not THAT difficult juding from bbdemux' source) My problem is that I don't have a lot of free time until the end of January at least. I'll see how much I can get done, though. Mosu -- If Darl McBride was in charge, he'd probably make marriage unconstitutional too, since clearly it de-emphasizes the commercial nature of normal human interaction, and probably is a major impediment to the commercial growth of prostitution. - Linus Torvalds From mike at po.cs.msu.su Mon Dec 27 18:00:59 2004 From: mike at po.cs.msu.su (Mike Matsnev) Date: Mon, 27 Dec 2004 20:00:59 +0300 Subject: [Matroska-devel] Status Quo of new features In-Reply-To: <20041227144451.GJ17631@bunkus.org> References: <41CFDD66.2040208@matroska.org> <20041227144451.GJ17631@bunkus.org> Message-ID: <41D03FCB.4070904@po.cs.msu.su> Moritz Bunkus wrote: >>*Still Pending :* >> >>- new pack with Haali's splitter and a wavpack decoder > > >>From user feedback on doom9.org (yes, I still go there) it seems like > there are still a couple of problems for which Gabest's splitter works > better than Haali's: > > http://forum.doom9.org/showthread.php?s=&threadid=80762&perpage=20&pagenumber=4 > > Yong: "This matroska splitter can't "split" the FLAC audio format..." fixed long ago > Shinobu: "any chance to get the autoloading of subtitle works ? depends on the hardcoded list of splitters in vsfilter, fixed in my local version > i also have some seeking lags (not cpu problem) and strange sound bug > when seek with AAC+. > i've none of these bugs with gabest splitter. I can't reproduce seeking bugs yet, but I'll try more. I suspect this is a timestamps problem like the one in CoreVorbis. > also your splitter doesn't seems to realy work on 98/me, do you plan to > devel that ?" I use TCHARs in all my code, so in theory it should work on 98/me. I can't test it though. >>- native MPEG4 with correct b-frame handling ( status ? ) > > > I could start working on that again. Playback in mplayer should work now > (due to my changes for MPEG 2 playback ;), but I still haven't gotten > the bitstream-frame-separation done. > > Some things that are missing/have to be worked on in mkvtoolnix: > > - support for concatenating files in mmg (not mkvmerge, that part is > working more or less -- here I need feedback before I continue working > on it); Here is your feedback: I've tried to join four files yesterday (avi/srt + avi/srt) in two steps: * avi/srt -> mkv * mkv+mkv mkvmerge complained about srt subs having incompatible format when trying the same with just two avi files, sound was out of sync in the second part. /Mike From moritz at bunkus.org Mon Dec 27 19:00:42 2004 From: moritz at bunkus.org (Moritz Bunkus) Date: Mon, 27 Dec 2004 19:00:42 +0100 Subject: [Matroska-devel] Status Quo of new features In-Reply-To: <41D03FCB.4070904@po.cs.msu.su> References: <41CFDD66.2040208@matroska.org> <20041227144451.GJ17631@bunkus.org> <41D03FCB.4070904@po.cs.msu.su> Message-ID: <20041227180042.GM17631@bunkus.org> Hey, > >Yong: "This matroska splitter can't "split" the FLAC audio format..." > fixed long ago Great :) > >Shinobu: "any chance to get the autoloading of subtitle works ? > depends on the hardcoded list of splitters in vsfilter, fixed in > my local version Great :) > >also your splitter doesn't seems to realy work on 98/me, do you plan to > >devel that ?" > I use TCHARs in all my code, so in theory it should work on 98/me. I can't > test it though. So we should find someone who can test it for us. > Here is your feedback: > I've tried to join four files yesterday (avi/srt + avi/srt) in two steps: > * avi/srt -> mkv > * mkv+mkv > mkvmerge complained about srt subs having incompatible format Ups, thanks for noticing. A misplaced '!' :) > when trying the same with just two avi files, sound was out of sync in > the second part. First AVI -> mkv, then mkv + mkv ? Could you also try AVI + AVI directly, please? One problem is that those AVIs are not really meant to be concatenated. I'm focusing on having good results with files splitted with mkvmerge's --split option. Mosu -- If Darl McBride was in charge, he'd probably make marriage unconstitutional too, since clearly it de-emphasizes the commercial nature of normal human interaction, and probably is a major impediment to the commercial growth of prostitution. - Linus Torvalds From mike at po.cs.msu.su Mon Dec 27 20:07:49 2004 From: mike at po.cs.msu.su (Mike Matsnev) Date: Mon, 27 Dec 2004 22:07:49 +0300 Subject: [Matroska-devel] Status Quo of new features In-Reply-To: <20041227180042.GM17631@bunkus.org> References: <41CFDD66.2040208@matroska.org> <20041227144451.GJ17631@bunkus.org> <41D03FCB.4070904@po.cs.msu.su> <20041227180042.GM17631@bunkus.org> Message-ID: <41D05D85.6050909@po.cs.msu.su> Moritz Bunkus wrote: >>when trying the same with just two avi files, sound was out of sync in >>the second part. > > > First AVI -> mkv, then mkv + mkv ? Could you also try AVI + AVI > directly, please? That was with two avi files directly. /Mike From moritz at bunkus.org Mon Dec 27 20:17:30 2004 From: moritz at bunkus.org (Moritz Bunkus) Date: Mon, 27 Dec 2004 20:17:30 +0100 Subject: [Matroska-devel] Status Quo of new features In-Reply-To: <41D05D85.6050909@po.cs.msu.su> References: <41CFDD66.2040208@matroska.org> <20041227144451.GJ17631@bunkus.org> <41D03FCB.4070904@po.cs.msu.su> <20041227180042.GM17631@bunkus.org> <41D05D85.6050909@po.cs.msu.su> Message-ID: <20041227191730.GN17631@bunkus.org> Hey, > That was with two avi files directly. Ok. It works reasonably well here with two different movies I have downloaded. So I guess (!) that the video and audio tracks in your AVIs have slightly different lengths. How much off is A/V sync in the second part? Mosu -- If Darl McBride was in charge, he'd probably make marriage unconstitutional too, since clearly it de-emphasizes the commercial nature of normal human interaction, and probably is a major impediment to the commercial growth of prostitution. - Linus Torvalds From steve.lhomme at free.fr Mon Dec 27 22:59:59 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Mon, 27 Dec 2004 22:59:59 +0100 Subject: [Matroska-devel] Re: WavPack hybrid In-Reply-To: <1103787890.41ca77723876f@webmail.impulse.net> References: <41C55213.9090103@free.fr> <1103493700.41c5fa44bfbdf@www.webmail.impulse.net> <41C68D65.1070207@free.fr> <1103564955.41c7109b2e1bf@www.webmail.impulse.net> <41C96F44.2010906@free.fr> <1103787890.41ca77723876f@webmail.impulse.net> Message-ID: <41D085DF.8060701@free.fr> Hi David, dbryant at impulse.net a ?crit : > Hi Steve, > > >>OK, I think I understand. Do you have a sample 5.1 file that I could >>debug with ? I'm not sure how to produce one... > > > Yes, I am attaching a 5.1 wav file. It's about 3 meg uncompressed, WavPack > does pretty good on it because it's mostly silence. :-) Thanx, it worked fine. I have now coded the muxing and demuxing of all kinds of Wavpack files in mkvmerge, our main tool. That means mono/stereo/multi-track lossless/lossy/hybrid files. If you want to give it a try, you can download it here : http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/HEAD/mkvtoolnix-head-20041227-1.rar You might need the Windows runtime too: http://www.bunkus.org/videotools/mkvtoolnix/win32/mkvtoolnix-runtime.rar There are HTML documentation files on how to use the tools (mkvmerge and mkvextract). And also a GUI for mkvmerge. In mkvextract there is an option to strip the correction part of an hybrid-based file. Unfortunately it's only the beggining, we have the files. Now we need players ;) Maybe if I find the time I'll work on a DirectShow filter based on CoreTTA. Have fun with your Wavpack-Matroska files :) (fun includes chapters, attach covers, lyrics, etc) mkvmerge can also generate Tags from cuesheet files (.cue) From chris at matroska.org Tue Dec 28 22:26:40 2004 From: chris at matroska.org (Christian HJ Wiesner) Date: Tue, 28 Dec 2004 22:26:40 +0100 Subject: [Matroska-devel] Lossless audio codecs for video editing Message-ID: <41D1CF90.2020403@matroska.org> Hi, this email is sent to flac-dev AT xiph DOT org, copied to matroska-devel AT lists DOT matroska DOT org, and David Bryant, the author of Wavpack4. We are about to implement the DV ( Digital Video ) video compression standard into matroska, to be able to offer an intelligent alternative to AVI for DV handling in editor tools. DV is using a high quality, high bitrate lossy video compression similar to MJPEG, so there are no I/P/B frames, you can cut the DV AVI wherever you like. The sound is typically PCM, and in a type 1 DV AVI the video and audio will form a single stream ( like in the DV format itself ). As most AVI editors cant handle a stream containing audio and video, there is also type 2 DV AVI, where the PCM audio stream is repeated in a second track, to make it accessible. I heard Virtualdub has recently added support for type 1 DV AVI, but i couldnt verify this. Our goal is to allow the use of lossless audio with a single DV video ( PCM audio stripped ), to save HDD space during the editing process. MKV has perfect support for FLAC since more than a year, and we are about to add Wavpack4 support right now. I was wondering how suitable both are with respect to video editing, especially if it comes to sample precise cutting. What is the absolute minimal number of samples per frame in a FLAC stream ? Can we change the number of samples in the same track ? Hopefully you understand where my question is coming from, we normally cant cut audio streams in between frames during the video editing process, but its not given in any case that frame boundaries of the DV video stream will match those of the audio stream, and this could lead to problems. For this reason we will concentrate on the one lossless audio format for the DV editing that will allow us the finest sample size, for precise editing. I know we could try to dig this all up from your docs, but maybe you have an idea how we could best use your codecs for this purpose ? Christian matroska project admin http://www.matroska.org From steve.lhomme at free.fr Tue Dec 28 22:31:16 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Tue, 28 Dec 2004 22:31:16 +0100 Subject: [Matroska-devel] Lossless audio codecs for video editing In-Reply-To: <41D1CF90.2020403@matroska.org> References: <41D1CF90.2020403@matroska.org> Message-ID: <41D1D0A4.2050806@free.fr> Christian HJ Wiesner a ?crit : > I was wondering how suitable both are with respect to video editing, > especially if it comes to sample precise cutting. What is the absolute > minimal number of samples per frame in a FLAC stream ? Can we change the > number of samples in the same track ? > > Hopefully you understand where my question is coming from, we normally > cant cut audio streams in between frames during the video editing > process, but its not given in any case that frame boundaries of the DV > video stream will match those of the audio stream, and this could lead > to problems. For this reason we will concentrate on the one lossless > audio format for the DV editing that will allow us the finest sample > size, for precise editing. Wavpack4 can do that fine. From Liisachan at faireal.net Wed Dec 29 04:14:37 2004 From: Liisachan at faireal.net (Liisachan) Date: Wed, 29 Dec 2004 12:14:37 +0900 Subject: [Matroska-devel] mmg.exe 2 Bugs Related to Charset Message-ID: <20041229121437Kxo&gY@faireal.net> Testing MMG 1.0.1, I found that [Copy to Clipboard] doesnt work in some situations for 2 reasons: (1) MMG produces this: "mkvmerge" -o "C:\FILENAME.mkv" --command-line-charset UTF-8 It won't work. Because MMG is trying to handle FILENAME as UTF-8, we should declare --command-line-charset BEFORE -o That is, "mkvmerge" --command-line-charset UTF-8 -o "C:\FILENAME.mkv" (2) Even you fixes that, you can still not make a valid .bat file via Clipbaord, because handling UTF-8 as CF_TEXT is sometimes lossy, especially for MBCS. # UTF-8 is "ASCII-transparent", but not MBCS-translaprent. Example: 1. Let's think about the 5 first Japanese 'alphabet' (Hiragana), [U+3042][U+3044][U+3046][U+3048][U+304A].mkv 2. In UTF8, this will be: E3 81 82 E3 81 84 E3 81 86 E3 81 88 E3 81 8A 2E 6D 6B 76 -------- -------- -------- -------- -------- . m k v 3. When copied to Clipboard as CF_TEXT, (3-1) If the locale is US_ASCII, they might be interpreted simply as E3 81 82 E3... which should be ok (3-1) However, if the locale is a DBCS, such as SHIFT_JIS, CF_TEXT must be valid as SHIFT_JIS. The problem is, you didnt consider about this limitation. Which means, E3 81 82 E3 81 84 E3 81 86 E3 81 88 E3 81 8A 2E ----- ----- ----- ----- ===== ----- ----- ===== [E3 81][82 E3][81 84][E3 81] are valid code points as SHIFT_JIS, so they are basically OK. Then SHIFT_JIS parser gets [86 E3] which is an illegal Code point as SHIFT_JIS, and will be converted to the DefaultChar (probably the one defined in the CPINFO structure), which is in this case [81 45]. Now, [81 88] and [E3 81] are OK, but again [8A 2E] is illegal and converted to [81 45]. As a result, what you paste from ClipBoard is very lossy. E3 81 82 E3 81 84 E3 81 81 45 81 88 E3 81 81 45 ----- ----- ----- ----- xxxxx ----- ----- xxxxx no way we could correctly re-convert this back into UTF-8. So, the bottom line is, MMG's [Copy to Clipboard] doesn't work. Because of the same reason (DOS-BOX is lossy for WCHAR to MBCS), even if you make a .bat file manually, using correct UTF-8, that won't work. It may work in lucky situations, but generally, it doesn't work. (3) Solution... A. First, like older versions, MMG should customize/disable "--command-line-charset" When uncheck --command-line-charset, it uses the default charset defined by the user's locale. B. More fundamentally, MMG can stop relying on stdin (dos-box), and aggressively tell Windows to give it everything in Unicode from the begining, by calling LPWSTR GetCommandLineW( VOID ) But this has downsides...again, Win98 users will get angry. So, C. Something like this might be the best: mkvmerge -j job.utf8 job.utf8 is a text file in UTF8. It says, for instance, -o [U+3042][U+3044][U+3046][U+3048][U+304A].mkv mkvmerge just can open the file and read it and parse the text as UTF8, so no one can mess with that. Liisachan From steve.lhomme at free.fr Wed Dec 29 09:45:12 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Wed, 29 Dec 2004 09:45:12 +0100 Subject: [Matroska-devel] mmg.exe 2 Bugs Related to Charset In-Reply-To: <20041229121437Kxo&gY@faireal.net> References: <20041229121437Kxo&gY@faireal.net> Message-ID: <41D26E98.7010301@free.fr> Liisachan a ?crit : > (3) Solution... > A. First, like older versions, MMG should customize/disable > "--command-line-charset" > When uncheck --command-line-charset, it uses the default charset > defined by the user's locale. > > B. More fundamentally, MMG can stop relying on stdin (dos-box), > and aggressively tell Windows to give it everything in > Unicode from the begining, by calling > LPWSTR GetCommandLineW( VOID ) > But this has downsides...again, Win98 users will get angry. So, But MMG is not a Windows program but a cross-platform one. Introducing OS specific code is usually not the wisest thing. And that whole i18n stuff is a PITA to handle on most platforms... > C. Something like this might be the best: > > mkvmerge -j job.utf8 > > job.utf8 is a text file in UTF8. It says, for instance, > -o [U+3042][U+3044][U+3046][U+3048][U+304A].mkv > > mkvmerge just can open the file and read it and parse the text > as UTF8, so no one can mess with that. Actually MMG can produce saved files that describe the job done in MMG. Maybe mkvmerge could support that file format. I was thinking about doing such a file too from DMX (DvdMenuXtractor), but the format looked.... From moritz at bunkus.org Wed Dec 29 09:51:49 2004 From: moritz at bunkus.org (Moritz Bunkus) Date: Wed, 29 Dec 2004 09:51:49 +0100 Subject: [Matroska-devel] mmg.exe 2 Bugs Related to Charset In-Reply-To: <20041229121437Kxo&gY@faireal.net> References: <20041229121437Kxo&gY@faireal.net> Message-ID: <20041229085149.GA2411@bunkus.org> Hey, > (1) MMG produces this: > > "mkvmerge" -o "C:\FILENAME.mkv" --command-line-charset UTF-8 > > It won't work. Because MMG is trying to handle FILENAME as UTF-8, > we should declare --command-line-charset BEFORE -o > That is, > > "mkvmerge" --command-line-charset UTF-8 -o "C:\FILENAME.mkv" True. > (3) Solution... > A. First, like older versions, MMG should customize/disable > "--command-line-charset" > When uncheck --command-line-charset, it uses the default charset > defined by the user's locale. That caused very uncool problems, too. > B. More fundamentally, MMG can stop relying on stdin (dos-box), > and aggressively tell Windows to give it everything in > Unicode from the begining, by calling > LPWSTR GetCommandLineW( VOID ) > But this has downsides...again, Win98 users will get angry. So, Neither mmg nor mkvmerge uses Unicode internally. > C. Something like this might be the best: > > mkvmerge -j job.utf8 This is what mkvmerge does. The correct syntax is mkvmerge @job.utf8 Maybe I should just disable the "copy to clipboard" function and only keep the "create option file" option. Mosu -- If Darl McBride was in charge, he'd probably make marriage unconstitutional too, since clearly it de-emphasizes the commercial nature of normal human interaction, and probably is a major impediment to the commercial growth of prostitution. - Linus Torvalds From moritz at bunkus.org Wed Dec 29 09:53:51 2004 From: moritz at bunkus.org (Moritz Bunkus) Date: Wed, 29 Dec 2004 09:53:51 +0100 Subject: [Matroska-devel] mmg.exe 2 Bugs Related to Charset In-Reply-To: <41D26E98.7010301@free.fr> References: <20041229121437Kxo&gY@faireal.net> <41D26E98.7010301@free.fr> Message-ID: <20041229085351.GB2411@bunkus.org> Hey, > Actually MMG can produce saved files that describe the job done in MMG. > Maybe mkvmerge could support that file format. I was thinking about > doing such a file too from DMX (DvdMenuXtractor), but the format > looked.... Such files are trivial regarding the format. Each line contains exactly one argument. Nothing is escaped. Example: mkvmerge -o whatever.mkv "One input file.avi" --chapters "Gimme some more.cue" would look like this: ---------------cut--------------- -o whatever.mkv One input file.avi --chapters Gimme some more.cue ---------------cut--------------- as an option file. Then you can call "mkvmerge @thatfile". If the file has a proper BOM then multibyte/UTF-8 encoded file names etc should be working. Mosu -- If Darl McBride was in charge, he'd probably make marriage unconstitutional too, since clearly it de-emphasizes the commercial nature of normal human interaction, and probably is a major impediment to the commercial growth of prostitution. - Linus Torvalds From Liisachan at faireal.net Wed Dec 29 11:04:27 2004 From: Liisachan at faireal.net (Liisachan) Date: Wed, 29 Dec 2004 19:04:27 +0900 Subject: [Matroska-devel] mmg.exe 2 Bugs Related to Charset In-Reply-To: <20041229085149.GA2411@bunkus.org> References: <20041229121437Kxo&gY@faireal.net> <20041229085149.GA2411@bunkus.org> Message-ID: <20041229190427174!Wv@faireal.net> Hi, Ok, I'll talk about what's happening on Windows: mkvmerge works fine with the default charset, and it works fine ONLY with the default charset, it doesnt work with the commandline in UTF-8. The only charset mkvmerge can use as commandline is the default charset. I don't see any reasons MMG doesnt do the same. Actually, --comannd-line-charset is almost meaningless for Windows users, especially if the default charset is a MBCS. similarly, you cannot copy-and-paste Unicode strings to MMG's editboxes. (You cannot copy-and-paste Arabic and French mix, for instance) So, in this sense, it's meaningless for MMG to use UTF-8. The only charset that you can use on MMG is the default charset. Converting the default charset to/from UTF-8 won't increase what you can do. However, in total, using UTF-8 is meaningful, for instance for the chapter data, cue sheet, etc etc. > > (3) Solution... > > A. First, like older versions, MMG should customize/disable > > "--command-line-charset" > > When uncheck --command-line-charset, it uses the default charset > > defined by the user's locale. > > That caused very uncool problems, too. I don't think so. Like I said, the only charset that really works is the defualt charset. So there should be at least the "Use the default charset for commandline" checkbox. Probably no Windows users will be in trouble even if MMG/MKVMerge can't handle commandlines in UTF-8 (rather, they don't need that) Some Windows users will be happier, if MMG can handle the default charset as commandline (because, then, they can copy and paste it) Here I'm thinking only about Windows. So you may be right, to make this x-platform. > Maybe I should just disable the "copy to clipboard" function and only > keep the "create option file" option. In that case, you should also remove the "command line" editbox. users think they can copy and paste from there, but like i said, they can't if the locale is MBCS and the edit box is in UTF-8. Again, is there any reason that you don't want to copy data to Clipboard using the default charset? If it does not use Unicode-- > Neither mmg nor mkvmerge uses Unicode internally. --then, it should pass the data to Clipboard without using Unicode. On Windows, no one will be happy if the data in Clipboard is in UTF-8. (UTF-16 would be another story tho) Liisachan From moritz at bunkus.org Wed Dec 29 11:15:42 2004 From: moritz at bunkus.org (Moritz Bunkus) Date: Wed, 29 Dec 2004 11:15:42 +0100 Subject: [Matroska-devel] mmg.exe 2 Bugs Related to Charset In-Reply-To: <20041229190427174!Wv@faireal.net> References: <20041229121437Kxo&gY@faireal.net> <20041229085149.GA2411@bunkus.org> <20041229190427174!Wv@faireal.net> Message-ID: <20041229101542.GC2411@bunkus.org> Hey, ... > Actually, --comannd-line-charset is almost meaningless for > Windows users, especially if the default charset is a MBCS. Then I should make that OS dependant: don't mess with the default charset in Windows and use UTF-8 on Linux. > similarly, you cannot copy-and-paste Unicode strings to MMG's > editboxes. (You cannot copy-and-paste Arabic and French mix, for > instance) That's because of two things: a) mmg does not use Unicode internally and b) the wxWidgets version I use is not compiled with Unicode support. > However, in total, using UTF-8 is meaningful, for instance for > the chapter data, cue sheet, etc etc. UTF-8 is always useful as long as its stored in a file -- it just becomes useless once we have to copy & paste it and/or use it on the command line in Windows. > > That caused very uncool problems, too. > > I don't think so. Maybe that was only on Linux, I'm not sure. > Here I'm thinking only about Windows. So you may be right, to > make this x-platform. I don't think I'll find a "one size fits all" solution here (meaning: I will have to code differently depending on the OS). I don't mind that, I just have to do it ;) > > Maybe I should just disable the "copy to clipboard" function and only > > keep the "create option file" option. > > In that case, you should also remove the "command line" editbox. True, but then again I think I'll keep with the default charset instead of UTF-8. > Again, is there any reason that you don't want to copy data to > Clipboard using the default charset? The primary reason was that users that do use the command line (and here I thought of Linux users) could simply copy&paste that text into their terminal and let mkvmerge do its job. > On Windows, no one will be happy if the data in Clipboard is in > UTF-8. (UTF-16 would be another story tho) That's one of the big differences between Linux & Windows ;) On Linux you often use UTF-8 for Unicode support. Mosu -- If Darl McBride was in charge, he'd probably make marriage unconstitutional too, since clearly it de-emphasizes the commercial nature of normal human interaction, and probably is a major impediment to the commercial growth of prostitution. - Linus Torvalds From Liisachan at faireal.net Wed Dec 29 11:19:45 2004 From: Liisachan at faireal.net (Liisachan) Date: Wed, 29 Dec 2004 19:19:45 +0900 Subject: [Matroska-devel] mmg.exe 2 Bugs Related to Charset In-Reply-To: <41D26E98.7010301@free.fr> References: <20041229121437Kxo&gY@faireal.net> <41D26E98.7010301@free.fr> Message-ID: <200412291919459yIabS@faireal.net> > Actually MMG can produce saved files that describe the job done in MMG. Oh... :D If Im not wrong, .mmg file IS in the default charset, not in utf-8. So why should it use utf-8 when you cannot use Unicode even in the job file? Actually, there is a psychological reason too: A string in a W. European langauge is roughly readable even if it is in UTF-8 but is interpreted as WinLatin; while a Japanese-language string is completely foobared if it is in UTF-8 but is interpreted as WinCP (SHIFT_JIS). And a typical user in Japan is like, "Come on, not again, the kanji is broken again. This is why I hate those non-Unicode programs made in a foreign country." As for MMG, the above-mentioned impression is incorrect; it can handle Japanese. However, it's impossible to deny the 'impression' when he sees broken kanji. As a side note, as I poseted in HA, CoreFLAC can't even open a file if the filename is in Chinese/Japanese/Korean etc. illiminable's filters have the same problem... CoreVorbis and CoreAAC have the same problem... (Hope CoreWavpack wont) That's why the typical user would be like "Not again..." to see broken kanji in MMG, even tho MMG does work with Japanese actually. =) Liisachan From moritz at bunkus.org Wed Dec 29 11:29:57 2004 From: moritz at bunkus.org (Moritz Bunkus) Date: Wed, 29 Dec 2004 11:29:57 +0100 Subject: [Matroska-devel] mmg.exe 2 Bugs Related to Charset In-Reply-To: <200412291919459yIabS@faireal.net> References: <20041229121437Kxo&gY@faireal.net> <41D26E98.7010301@free.fr> <200412291919459yIabS@faireal.net> Message-ID: <20041229102957.GD2411@bunkus.org> Hey, I'm not talking about _job_ files. For those I simply use wxWidgets own functions. This will stay as it is as long as I use wxWidgets without Unicode support. What I am talking about is the files created directly for the communication with mkvmerge itself when it is started for muxing. These files are in fact in UTF-8. You just never see them because they're deleted right after muxing ;) All this i18n stuff is giving me several headaches. I don't think I will get it right in 1.2.0. But after that I think I will make a drastic change and convert mmg (and mkvmerge too, I fear) to use Unicode internally. This will make Windows 9x users unhappy I guess, but there's always Unicows, isn't there? On Linux this move will also have some drawbacks: gcc 2.95's C++ implementation has a serious bug in the wstring class implementation which makes it impossible to use. Well, gcc 2.95 is old, but I know a lot of people who still use it. > Actually, there is a psychological reason too: > A string in a W. European langauge is roughly readable even if > it is in UTF-8 but is interpreted as WinLatin; > while a Japanese-language string is completely foobared if it is > in UTF-8 but is interpreted as WinCP (SHIFT_JIS). ... I could write those files in UTF-16, of course, but again that would require some drastic changes. None of my routines are able to handle wide char strings -- they all assume that a string ends once a 0 byte is encountered. Mosu -- If Darl McBride was in charge, he'd probably make marriage unconstitutional too, since clearly it de-emphasizes the commercial nature of normal human interaction, and probably is a major impediment to the commercial growth of prostitution. - Linus Torvalds From Liisachan at faireal.net Wed Dec 29 11:48:03 2004 From: Liisachan at faireal.net (Liisachan) Date: Wed, 29 Dec 2004 19:48:03 +0900 Subject: [Matroska-devel] mmg.exe 2 Bugs Related to Charset In-Reply-To: <20041229101542.GC2411@bunkus.org> References: <20041229190427174!Wv@faireal.net> <20041229101542.GC2411@bunkus.org> Message-ID: <200412291948039i1_8A@faireal.net> Hi, Moritz Bunkus wrote: > > Actually, --comannd-line-charset is almost meaningless for > > Windows users, especially if the default charset is a MBCS. > > Then I should make that OS dependant: don't mess with the default > charset in Windows and use UTF-8 on Linux. Maybe that's the best practical solution for now. Liisachan From Liisachan at faireal.net Wed Dec 29 11:54:48 2004 From: Liisachan at faireal.net (Liisachan) Date: Wed, 29 Dec 2004 19:54:48 +0900 Subject: [Matroska-devel] mmg.exe 2 Bugs Related to Charset In-Reply-To: <20041229102957.GD2411@bunkus.org> References: <200412291919459yIabS@faireal.net> <20041229102957.GD2411@bunkus.org> Message-ID: <20041229195448lxuh!J@faireal.net> Hi, Moritz Bunkus wrote: > Hey, > > I'm not talking about _job_ files. For those I simply use wxWidgets own > functions. This will stay as it is as long as I use wxWidgets without > Unicode support. Ok, I have nothing against UTF-8, nor the Default charset. > What I am talking about is the files created directly for the > communication with mkvmerge itself when it is started for muxing. These > files are in fact in UTF-8. You just never see them because they're > deleted right after muxing ;) I see, I see. > All this i18n stuff is giving me several headaches. I don't think I will > get it right in 1.2.0. But after that I think I will make a drastic Perhaps that was the part of the reasons too why OGM had stopped at 0.9.9.5 > change and convert mmg (and mkvmerge too, I fear) to use Unicode > internally. This will make Windows 9x users unhappy I guess, but there's > always Unicows, isn't there? Hmmmm, in theory you don't have to change mkvmerge, if mmg can order mkvmerge via a file in UTF-8. Of course it would be great if mkvmerge supported Unicode directly, but in reality, it is almost impossible to type in Unicode in the dos-box. Win98/me would be the real headache. Creating a Unicode-enabled program is not that difficult... but that is only if the OS supports Unicode. foobar2000 is kinda miraculous. IMHO you'd need a lot of feedback from all over the world to be successuful in i18n m17n because there are a ton of language-specific problems. Maybe I should have posted the first report in doom9 not in this list, but you devs don't like doom9 now ;_; > > Actually, there is a psychological reason too: > ... > > I could write those files in UTF-16, of course, but again that would > require some drastic changes. This 'cosmetic' problem will be gone, if you use the default charset for the commandline on Windows platform. The real problem here is, not cosmetic nor psychological, but that you cannot copy from the clipboard now, even tho MMG can copy to Clipboard. Seems Windows is not so UTF-8-friendly, like Linux... Windows' clipboard usually uses the defualt Charset or UTF-16. Liisachan From moritz at bunkus.org Wed Dec 29 12:06:44 2004 From: moritz at bunkus.org (Moritz Bunkus) Date: Wed, 29 Dec 2004 12:06:44 +0100 Subject: [Matroska-devel] mmg.exe 2 Bugs Related to Charset In-Reply-To: <20041229195448lxuh!J@faireal.net> References: <200412291919459yIabS@faireal.net> <20041229102957.GD2411@bunkus.org> <20041229195448lxuh!J@faireal.net> Message-ID: <20041229110644.GF2411@bunkus.org> Hey, > Hmmmm, in theory you don't have to change mkvmerge, > if mmg can order mkvmerge via a file in UTF-8. True, but mmg uses the same framework that mkvmerge uses. So I have to at least extend that framework for wide char strings. Ok, that does not mean that I have to rewrite the rest of mkvmerge to use wide strings, too. Converting mmg to Unicode would be much less of a problem than converting mkvmerge. Another "problem" is that I started with mmg over half a year after I started mkvmerge. Therefore I already had at least half a framework of self-written functions. Instead I could have based everything on wxWidgets. So at the moment I even have code duplication in mmg for wxString based stuff while the same exists in mkvmerge for the "normal" C++ "string" class... This design still allows for building mkvmerge without wxWidgets (which is good for e.g. MacOS X because wxWidgets has some serious issues on that platform), but it also makes for a lot of duplicated work / strange conversions etc. > Of course it would be great if mkvmerge supported Unicode > directly, but in reality, it is almost impossible to type in > Unicode in the dos-box. :) > Maybe I should have posted the first report in doom9 not in this > list, but you devs don't like doom9 now ;_; I do :) > This 'cosmetic' problem will be gone, if you use the default > charset for the commandline on Windows platform. Only as long as users don't take a look at those 'option' files I create. Those are in UTF-8; maybe I can add an option to create those in UTF-16, too. Mosu -- If Darl McBride was in charge, he'd probably make marriage unconstitutional too, since clearly it de-emphasizes the commercial nature of normal human interaction, and probably is a major impediment to the commercial growth of prostitution. - Linus Torvalds From christophe.paris at free.fr Wed Dec 29 12:55:19 2004 From: christophe.paris at free.fr (Christophe PARIS) Date: Wed, 29 Dec 2004 12:55:19 +0100 Subject: [Matroska-devel] mmg.exe 2 Bugs Related to Charset In-Reply-To: <200412291919459yIabS@faireal.net> References: <20041229121437Kxo&gY@faireal.net> <41D26E98.7010301@free.fr> <200412291919459yIabS@faireal.net> Message-ID: <41D29B27.5040006@free.fr> Liisachan wrote: >As a side note, as I poseted in HA, CoreFLAC can't even open a >file if the filename is in Chinese/Japanese/Korean etc. >illiminable's filters have the same problem... >CoreVorbis and CoreAAC have the same problem... >(Hope CoreWavpack wont) > > CoreVorbis and CoreAAC don't know anything about the filename, it's handled by filters connected before them. For example TTA DS shouldn't have any problems when playing .tta file because it use : File Source -> TTA Splitter -> TTA Decoder ... As long as Windows File Source filter handle the filename correctly of course. For CoreFLAC reading .flac files, I think it's a bit different as it is used as a source filter in this case. So it's the job of CoreFLAC to handle the filename, and it should be fixed. Regards, Toff From Liisachan at faireal.net Wed Dec 29 13:54:41 2004 From: Liisachan at faireal.net (Liisachan) Date: Wed, 29 Dec 2004 21:54:41 +0900 Subject: [Matroska-devel] mmg.exe 2 Bugs Related to Charset In-Reply-To: <41D29B27.5040006@free.fr> References: <200412291919459yIabS@faireal.net> <41D29B27.5040006@free.fr> Message-ID: <200412292154414PhUXT@faireal.net> Christophe PARIS wrote: > Liisachan wrote: > > >As a side note, as I poseted in HA, CoreFLAC can't even open a > >file if the filename is in Chinese/Japanese/Korean etc. > >illiminable's filters have the same problem... > >CoreVorbis and CoreAAC have the same problem... > >(Hope CoreWavpack wont) > > > > > > CoreVorbis and CoreAAC don't know anything about the filename, it's > handled by filters connected before them. > > For example TTA DS shouldn't have any problems when playing .tta file > because it use : > File Source -> TTA Splitter -> TTA Decoder ... > As long as Windows File Source filter handle the filename correctly of > course. > > For CoreFLAC reading .flac files, I think it's a bit different as it is > used as a source filter in this case. > So it's the job of CoreFLAC to handle the filename, and it should be fixed. Sorry, my mistake. Besides, OggDS (both 0995 and 0996) and aac_parser.ax are ok with MBCS via GraphEdit, and ok with Unicode via Media Player Classic. Unicode.ogg/aac/tta plays via DS. Like you said, CoreFLAC is problematic: Not only that it cannot handle Unicode filenames, but it cannot handle MBCS filenames even if its the default charset. Liisachan > > Regards, Toff > > _______________________________________________ > Matroska-devel mailing list > Matroska-devel at lists.matroska.org > http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel From jcsston at jory.info Wed Dec 29 14:18:01 2004 From: jcsston at jory.info (Jory Stone) Date: Wed, 29 Dec 2004 07:18:01 -0600 Subject: [Matroska-devel] mmg.exe 2 Bugs Related to Charset References: <200412291919459yIabS@faireal.net><41D29B27.5040006@free.fr> <200412292154414PhUXT@faireal.net> Message-ID: <003401c4eda8$d57db310$6b00a8c0@jcsston> The official CoreFLAC doesn't support Unicode filenames simply due to the fact the libflac doesn't. I did create a version of CoreFLAC that did support Unicode, by using the File Source filter, but libflac randomly would crash for no apparent reason. One of the first steps mmg/mkvmerge would need to take in order to support Unicode would be to compile and link with a Unicode build of wxWidgets and Unicows. Then just toss all these character set problems away :) Jory ----- Original Message ----- From: "Liisachan" To: "Discussion about the current and future development of Matroska" Sent: Wednesday, December 29, 2004 6:54 AM Subject: Re: [Matroska-devel] mmg.exe 2 Bugs Related to Charset > Christophe PARIS wrote: > >> Liisachan wrote: >> >> >As a side note, as I poseted in HA, CoreFLAC can't even open a >> >file if the filename is in Chinese/Japanese/Korean etc. >> >illiminable's filters have the same problem... >> >CoreVorbis and CoreAAC have the same problem... >> >(Hope CoreWavpack wont) >> > >> > >> >> CoreVorbis and CoreAAC don't know anything about the filename, it's >> handled by filters connected before them. >> >> For example TTA DS shouldn't have any problems when playing .tta file >> because it use : >> File Source -> TTA Splitter -> TTA Decoder ... >> As long as Windows File Source filter handle the filename correctly of >> course. >> >> For CoreFLAC reading .flac files, I think it's a bit different as it is >> used as a source filter in this case. >> So it's the job of CoreFLAC to handle the filename, and it should be >> fixed. > > Sorry, my mistake. Besides, OggDS (both 0995 and 0996) and > aac_parser.ax are ok with MBCS via GraphEdit, > and ok with Unicode via Media Player Classic. > > Unicode.ogg/aac/tta plays via DS. > > Like you said, CoreFLAC is problematic: > Not only that it cannot handle Unicode filenames, but > it cannot handle MBCS filenames even if its the default charset. > > Liisachan > >> >> Regards, Toff >> >> _______________________________________________ >> Matroska-devel mailing list >> Matroska-devel at lists.matroska.org >> http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel > > _______________________________________________ > Matroska-devel mailing list > Matroska-devel at lists.matroska.org > http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel > From Liisachan at faireal.net Wed Dec 29 15:16:11 2004 From: Liisachan at faireal.net (Liisachan) Date: Wed, 29 Dec 2004 23:16:11 +0900 Subject: [Matroska-devel] mmg.exe 2 Bugs Related to Charset In-Reply-To: <003401c4eda8$d57db310$6b00a8c0@jcsston> References: <200412292154414PhUXT@faireal.net> <003401c4eda8$d57db310$6b00a8c0@jcsston> Message-ID: <20041229231611'OuLc_@faireal.net> "Jory Stone" wrote: Hi, thanks for your great work. With CoreFLAC 0.3 I was always having trouble that I was not able to rewind the file when it is finished, but 0.4 has fixed my problem. I like it very much. > The official CoreFLAC doesn't support Unicode filenames simply due to the > fact the libflac doesn't. I did create a version of CoreFLAC that did > support Unicode, by using the File Source filter, but libflac randomly would > crash for no apparent reason. Well, let me make one thing clear, just in case. I'm reporting 2 different problems: one is Unicode-related and the other is not: (1) Not being able to open Unicode filename is, not a VERY big problem. Many apps can't either. (2) CoreFLAC does not support 'usual' non-unicode filenames, either (i.e. Windows Codepage; MS-DOS compatible, old thing) Most apps can handle SHIFT_JIS filenames if the system default code page is SHIFT_JIS. But CoreFLAC can't. So if libflac is problematic, it has 2 different problems: (1) It doesnt support Unicode. (2) It doesnt support Multibyte charcter sets. To solve (1) basically everything should be in WCHAR, and as you know much better than I, even an ascii alphabet 'a' will be 2-byte in WCHAR. (2) can be solved without supporting Unicode, by just seeing a MB char = 2 Ascii chars. In that case ascii 'a' is 'a' There are some tricks like sometimes the 2nd half of the MB char is '\\', but solving (2) should be easier than solving (1). Because there's no need for a radical change. Liisachan From chris at matroska.org Wed Dec 29 23:08:07 2004 From: chris at matroska.org (Christian HJ Wiesner) Date: Wed, 29 Dec 2004 23:08:07 +0100 Subject: [Matroska-devel] Flaws with chapter handling in current foobar2000 MKA plugin Message-ID: <41D32AC7.4020102@matroska.org> Hi, I did some testing with current Foobar2000 version ( 0.8.3 ) and MKA files with chapters ( made from a CUE sheet ) , muxed with different versions of mkvmerge/mmg.exe . Here the result : 0.7.8 : works fine 0.8.3 : works fine ; screenshot : http://wiesneronline.net/video/Musik/Metallica%20-%20Black%20Album/Screenshot_mkvmerge_083.JPG 0.9.0 : works fine ; screenshot : http://wiesneronline.net/video/Musik/Metallica%20-%20Black%20Album/Screenshot_mkvmerge_090.JPG 0.9.3 : some tracks/chapters are correct, some show only INDEX0 or INDEX1 ; screenshot : http://wiesneronline.net/video/Musik/Metallica%20-%20Black%20Album/Screenshot_mkvmerge_093.JPG 1.0.1 : doesnt work at all, all tracks show as the file name ; screenshot : http://wiesneronline.net/video/Musik/Metallica%20-%20Black%20Album/Screenshot_mkvmerge_101.JPG I have no idea what can be the problem, Mosu mentioned that he expects that maybe the current fb2k plugin expects a certain order for chapter elements, or cant skip unknown ( new ) chapter elements. Needless to say, all files play perfect in TCMP, with correct chapter indication in the Media Stream list. Hope this is helpful for the person that will ( one day ) look at the plugin, to update it so it can play current files correctly. Christian From steve.lhomme at free.fr Wed Dec 29 23:33:35 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Wed, 29 Dec 2004 23:33:35 +0100 Subject: [Matroska-devel] WavPack muxing Message-ID: <41D330BF.9000601@free.fr> I've made a small document that explains how WavPack is muxed in Matroska. I hope it's clear enough for everyone. The way it's stored allows bit-identical extracting of WavPack data from Matroska. So I think the muxing is OK. http://www.matroska.org/technical/specs/codecid/wavpack.html (linked from the CodecIDs page) I also encourage anyone who has worked on a complex codec to make such a page. It's very important that people can actually use the data when they are put into Matroska in various forms... -- robUx4 on blog From steve.lhomme at free.fr Wed Dec 29 23:48:33 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Wed, 29 Dec 2004 23:48:33 +0100 Subject: [Matroska-devel] WavPack header Message-ID: <41D33441.7040704@free.fr> Hi David, I was wondering if block_index and total_samples can be removed from each frame and be set to 0 when recovering the "original" file. Will it impact playback ? Using your libraries. If needed we can try to regenerate them when extracting the data from Matroska. Even when the data has been cut/edited... -- robUx4 on blog From jcsston at jory.info Thu Dec 30 01:10:42 2004 From: jcsston at jory.info (Jory Stone) Date: Wed, 29 Dec 2004 18:10:42 -0600 Subject: [Matroska-devel] mmg.exe 2 Bugs Related to Charset References: <200412292154414PhUXT@faireal.net><003401c4eda8$d57db310$6b00a8c0@jcsston> <20041229231611'OuLc_@faireal.net> Message-ID: <008f01c4ee04$fcbcd490$6b00a8c0@jcsston> Actually the last version of CoreFLAC I did work on was 0.3, I think Toff did the 0.4 release. Which BTW The filter was his work originally. Jory ----- Original Message ----- From: "Liisachan" To: "Discussion about the current and future development of Matroska" Sent: Wednesday, December 29, 2004 8:16 AM Subject: Re: [Matroska-devel] mmg.exe 2 Bugs Related to Charset > "Jory Stone" wrote: > > Hi, thanks for your great work. > With CoreFLAC 0.3 I was always having trouble that I was not > able to rewind the file when it is finished, but 0.4 has fixed > my problem. I like it very much. > >> The official CoreFLAC doesn't support Unicode filenames simply due to the >> fact the libflac doesn't. I did create a version of CoreFLAC that did >> support Unicode, by using the File Source filter, but libflac randomly >> would >> crash for no apparent reason. > > Well, let me make one thing clear, just in case. > I'm reporting 2 different problems: > one is Unicode-related and the other is not: > > (1) Not being able to open Unicode filename is, not a VERY big > problem. Many apps can't either. > > (2) CoreFLAC does not support 'usual' non-unicode filenames, > either (i.e. Windows Codepage; MS-DOS compatible, old thing) > > Most apps can handle SHIFT_JIS filenames if the system default > code page is SHIFT_JIS. But CoreFLAC can't. > > So if libflac is problematic, it has 2 different problems: > (1) It doesnt support Unicode. > (2) It doesnt support Multibyte charcter sets. > > To solve (1) basically everything should be in WCHAR, > and as you know much better than I, even an ascii alphabet 'a' > will be 2-byte in WCHAR. > > (2) can be solved without supporting Unicode, > by just seeing a MB char = 2 Ascii chars. > In that case ascii 'a' is 'a' > There are some tricks like sometimes the 2nd half of the MB char > is '\\', but solving (2) should be easier than solving (1). > Because there's no need for a radical change. > > Liisachan > > _______________________________________________ > Matroska-devel mailing list > Matroska-devel at lists.matroska.org > http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel > From dbryant at impulse.net Thu Dec 30 07:53:22 2004 From: dbryant at impulse.net (David Bryant) Date: Wed, 29 Dec 2004 22:53:22 -0800 Subject: [Matroska-devel] Re: Lossless audio codecs for video editing In-Reply-To: <41D1CF90.2020403@matroska.org> References: <41D1CF90.2020403@matroska.org> Message-ID: <1104389602.41d3a5e2601bc@webmail.impulse.net> WavPack blocks can contain any number of samples, from 1 to several hundred thousand (either mono or stereo). If samples are inserted or deleted at a certain spot in a stream, then only that block needs to be re-encoded; all others are unaffected. In a real WavPack stream the block headers would have to be rewritten, although this goes very quickly. In Matroska the WavPack blocks are being used in a "raw" mode so I think that no modifications would be needed. Quoting Christian HJ Wiesner : > > Hi, > > this email is sent to flac-dev AT xiph DOT org, copied to matroska-devel > > AT lists DOT matroska DOT org, and David Bryant, the author of Wavpack4. > > We are about to implement the DV ( Digital Video ) video compression > standard into matroska, to be able to offer an intelligent alternative > to AVI for DV handling in editor tools. DV is using a high quality, high > > bitrate lossy video compression similar to MJPEG, so there are no I/P/B > frames, you can cut the DV AVI wherever you like. The sound is typically > > PCM, and in a type 1 DV AVI the video and audio will form a single > stream ( like in the DV format itself ). As most AVI editors cant handle > > a stream containing audio and video, there is also type 2 DV AVI, where > > the PCM audio stream is repeated in a second track, to make it > accessible. I heard Virtualdub has recently added support for type 1 DV > AVI, but i couldnt verify this. > > Our goal is to allow the use of lossless audio with a single DV video ( > PCM audio stripped ), to save HDD space during the editing process. MKV > has perfect support for FLAC since more than a year, and we are about to > > add Wavpack4 support right now. > > I was wondering how suitable both are with respect to video editing, > especially if it comes to sample precise cutting. What is the absolute > minimal number of samples per frame in a FLAC stream ? Can we change the > > number of samples in the same track ? > > Hopefully you understand where my question is coming from, we normally > cant cut audio streams in between frames during the video editing > process, but its not given in any case that frame boundaries of the DV > video stream will match those of the audio stream, and this could lead > to problems. For this reason we will concentrate on the one lossless > audio format for the DV editing that will allow us the finest sample > size, for precise editing. > > I know we could try to dig this all up from your docs, but maybe you > have an idea how we could best use your codecs for this purpose ? > > Christian > matroska project admin > http://www.matroska.org > From christian at matroska.org Thu Dec 30 16:56:21 2004 From: christian at matroska.org (ChristianHJW) Date: Thu, 30 Dec 2004 16:56:21 +0100 Subject: [Matroska-devel] Re: snow/vorbis/nut? In-Reply-To: <20041230021423.GA232892@math.utoronto.ca> References: <20041230021423.GA232892@math.utoronto.ca> Message-ID: <41D42525.500@matroska.org> marco schrieb: > Hi, > The latest changelog mentions: > > - Vorbis in NUT fixed > - NUT updated to latest specification > > but I can't seem to find any documentation. How would > I go about creating a snow video and stuffing that into > the nut container? My sources would be a series of images > (say, PNG), and a sound file (could be wav, or ogg vorbis). > Any and all hints are appreciated! > Cheers, Marco, what exactly is 'snow' ? Are there any docs, so we can start adding support for it in matroska container ? Could you consider using matroska instead of NUT for your purpose, or is it too 'Windows-centric' for you ? Please note that we have perfect Vorbis in MKV support on all platforms, including Windows, Linux and Mac OSX. Christian matroska project admin http://www.matroska.org From chris at matroska.org Thu Dec 30 20:39:39 2004 From: chris at matroska.org (Christian HJ Wiesner) Date: Thu, 30 Dec 2004 20:39:39 +0100 Subject: [Matroska-devel] Re: snow/vorbis/nut? Message-ID: <41D4597B.8060300@matroska.org> FYI -------- Original-Nachricht -------- Betreff: Re: snow/vorbis/nut? Datum: Thu, 30 Dec 2004 13:12:28 -0500 Von: marco Antwort an: marco at reimeika.ca An: ChristianHJW Referenzen: <20041230021423.GA232892 at math.utoronto.ca> <41D42525.500 at matroska.org> Hi, > what exactly is 'snow' ? Are there any docs, so we can start adding > support for it in matroska container ? Apparently it's a new codec: http://ffmpeg.sourceforge.net/ffmpeg-doc.html#SEC19 but I simply cannot find any documentation. > Could you consider using matroska > instead of NUT for your purpose, or is it too 'Windows-centric' for you ? I know there's a lot of competition between OGM/MKV/OGG/NUT/etc, but I'm an agnostic, I want to give people choice :) I'm writing plugins for the LiVES video editor, and I have written plugins using various codecs and containers, including dixv/xvid+vorbis stuffed in a Matroska container: http://www.reimeika.ca/amv/lives/lives_guide.html#mkv_encoder I really do like Matroska, although I do sometimes have problems with a/v sync and I have to manually specify the delay (using the "--sync" option in mkvmerge, or the "-D" option in my plugin). I've noticed that OGM also has some a/v issues (using ogmmerge), but it's more noticeable when using mkvmerge (admittedly, this is probably more an issue of mkvmerge than Matroska itself). On the other hand, I've found that mjpegtools (creates MPG files) and the theora encoder (OGG container) have better a/v sync. That's just my experience so far, though. > Please note that we have perfect Vorbis in MKV support on all platforms, > including Windows, Linux and Mac OSX. I know, the plugin I wrote for it works very well (LiVES only seems to work on unix flavours, though). BTW, LiVES might make it into Debian with an appropriate 100% free subset of the encoders. Since patents are also an issue that pretty much narrows it down to Theora/Vorbis/OGG. However, if Matroska can contain Theora/Vorbis streams I would definately consider making a plugin and suggesting that it be included into the Debian package. Cheers! -- marco at reimeika.ca Gunnm: Broken Angel http://amv.reimeika.ca http://reimeika.ca/ http://photo.reimeika.ca From steve.lhomme at free.fr Fri Dec 31 17:19:57 2004 From: steve.lhomme at free.fr (Steve Lhomme) Date: Fri, 31 Dec 2004 17:19:57 +0100 Subject: [Matroska-devel] New muxing scheme Message-ID: <41D57C2D.5090902@free.fr> Hi David, Using the information you gave us, I modified mkvmerge/mkvextract to save less data from the header in our Blocks. The only data that is not recovered on extracting is the total number of samples which is set to -1. As you said it doesn't matter, it's safer for us and for editing purposes... You can get the latest tools here : http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/HEAD/ -- robUx4 on blog