From chris at matroska.org  Sat Nov  1 01:19:15 2003
From: chris at matroska.org (Christian HJ Wiesner)
Date: Sat, 01 Nov 2003 01:19:15 +0100
Subject: [Matroska-devel] Re: [Matroska-general] The near future of
	matroska - where do we go now?
In-Reply-To: <001c01c39fd1$cd23c2c0$0200a8c0@jcsston>
References: <3FA2825A.9020009@matroska.org>
	<001c01c39fd1$cd23c2c0$0200a8c0@jcsston>
Message-ID: <3FA2FC03.7040309@matroska.org>

Jory wrote:

>>- FLAC support
>>
>>    
>>
>
>FLAC is already supported via the FLAC DShow En/Decoder filters.
>http://www.hydrogenaudio.org/index.php?showtopic=13921
>
>Jory
>  
>
Jesusu, Jory,

you are faster than a flash lightning .... i didnt find this thread 
because i cant access Hydrognaudio.org from home for the time being, 
their internal firewall will block me for some strange reason.

Now, do i understand this correctly :

The FLAC encoder filter will

- write valid FLAC files when connecting to a file writer
- wriate valid FLAC in MKV files when connected to matroska muxer

Toff's FLAC decoder filter will

- only be able to decode FLAC from MKV ( or Ogg )

??

Ok, so i tried to download the binaries according to the Goecities link 
you gave, and had to realize that Chinese ISPs are obviously blocked 
from accessing Geocities. However, using my tunnel via my server in 
Germany it worked and i could download both binaries. I uploaded them to 
matroska.free.fr, but will talk to Toff about releasing them officially 
in the CoreFLAC project on corecodec.org, where they belong IMHO.

Here the new links :

Http://downloads.matroska.org/downloads/CoreFLACEncoder-v0.1.zip

Http://downloads.matroska.org/downloads/CoreFLACDecoder.zip

I will test this as soon as i can. Some questions :

1. Will the files be written as native FLAC files from matroskamuxer, or 
use the A_MS/ACM mode ? If so, i hate to say i dont like it. In this 
case we have to contact Gabest and talk to him about defining a new 
MEDIASUBTYPE for connection from the encoder to the muxer, and make it 
write native FLAC codec IDs

2. You didnt update the codec ID page, adding a native FLAC ID ?

3. Can MKV files with FLAC be edited on VdubMod already ?

Thanks for some answers

Christian




From alexander.noe at s2001.tu-chemnitz.de  Sat Nov  1 10:57:04 2003
From: alexander.noe at s2001.tu-chemnitz.de (=?ISO-8859-1?Q?Alexander_No=E9?=)
Date: Sat, 01 Nov 2003 10:57:04 +0100
Subject: [Matroska-devel] Reference and the disc space they waste
In-Reply-To: <3FA25D8B.2010606@free.fr>
References: <20031030114022.GQ13719@bunkus.org>	<3FA0FA7F.2040604@free.fr>	<20031030173914.GC13719@bunkus.org>	<3FA19C3B.3070109@free.fr>	<20031031085105.GF13719@bunkus.org>	<20031031124218.GI13719@bunkus.org>	<3FA25A09.3090706@free.fr>
	<20031031125303.GJ13719@bunkus.org> <3FA25D8B.2010606@free.fr>
Message-ID: <3FA38370.7010109@hrz.tu-chemnitz.de>

The current way you store references wastes space:
  { <reference> <size> <timecode> }

This means at least 3 bytes per references = 6 bytes for a b-frame. With 
an average block overhead of 10 bytes, those are 16 bytes of overhead 
per frame, equal to an AVI file.

2 Bytes could be saved if you allowed several references inside one 
<reference> element, like
{ <reference> <total size> { <timecodes xiph-lacing encoded }}

This gain is not too much, but you know, the goal is to make OGM have 
10x more overhead than Matroska for my testfile #3 :p

Someone just needs to find a good way to encode signed ints with 
xiph-encoding.
(EBML encoding would often waste one byte). Maybe the first byte of each
reference should be signed.

Example:
0x7E      =  126
0x7F 0x00 =  127
0x7F 0x01 =  128
0x7F 0x02 =  129
...

0x01      =    1
0x00      =    0
0xFF      =   -1
0xFE      =   -2
...
0x81      = -127
0x80 0x00 = -128
0x80 0x01 = -129

If you put 2 B-frames between 2 P-frames, which is not unusual, you 
won't leave the range between 126 and -127, meaning that the timecodes 
of 2 refered frames could be encoded with
<reference = 1 byte> <size = 1 byte> <timecodes = 1 byte each> = 4 bytes 
instead of 6

What do you think?


Alex



From moritz at bunkus.org  Sat Nov  1 14:52:24 2003
From: moritz at bunkus.org (Moritz Bunkus)
Date: Sat, 1 Nov 2003 14:52:24 +0100
Subject: [Matroska-devel] DVDtoOGM with Matroska support
Message-ID: <20031101135224.GL13719@bunkus.org>

Hi.

This conversation took place today:

.12:21:42.< DVDtoOgm> Hi...
.12:23:52.< DVDtoOgm> ChristianHJW available?
.12:24:28.< alex_here> wake him up :p
.12:24:43.< DVDtoOgm> oh... sleeping :-)
.12:25:06.< DVDtoOgm> do you know when he's usually here?
.12:25:14.< alex_here> what do you need him for?
.12:25:33.< DVDtoOgm> talking about DVDtoOgm and Matroska...
.12:25:49.< alex_here> you don't need him for that :)
.12:25:51.<@Mosu> he's in china at the moment,
.12:26:09.< DVDtoOgm> wow... seems to be far away from talking with me :-)
.12:26:13.<@Mosu> but he's online from time to time
.12:26:32.< DVDtoOgm> well might be hard to catch this time 
.12:26:56.< DVDtoOgm> when will he return from there? do you know?
.12:27:21.< alex_here> another question: what does he know what we don't?
.12:27:32.< DVDtoOgm> well, let me tell you:
.12:28:09.< DVDtoOgm> He asked me, if I'm interested in making DVDtoOgm (maybe with another name) to the official Matroska support tool...
.12:28:25.< DVDtoOgm> and he invited me to come here...
.12:28:31.< alex_here> The tool as in 'the one and only'?
.12:29:07.< DVDtoOgm> well, somethink like this...
.12:29:39.< alex_here> omg
.12:29:57.<@Mosu> oyg? :)
.12:30:09.< DVDtoOgm> we had a german conversation via eMail and he posted some requests in the official german DVDtoOgm-Frounm
.12:30:14.< DVDtoOgm> Forum, sorry
.12:30:20.< alex_here> what does he always need such things for :(
.12:30:30.< DVDtoOgm> for what?
.12:30:34.< alex_here> can you give a link?
.12:30:50.< DVDtoOgm> forum or DVDtoOgm-Homepage?
.12:30:54.<@Mosu> the latter
.12:30:57.< alex_here> forum
.12:31:02.<@Mosu> doh :)
.12:31:06.<@Mosu> for both, then ;)
.12:31:08.< alex_here> better just the corresponding thread
.12:31:17.< DVDtoOgm> second..
.12:31:31.< DVDtoOgm> (its german, remember) :-)
.12:31:42.-!- P0l1m0rph1c [~Dcoder at CC-3BB7AC4E.telepac.pt] has joined #matroska
.12:31:49.< alex_here> solange es nicht chinesisch ist...
.12:32:19.<@Mosu> genau
.12:32:20.< DVDtoOgm> http://www.flaskmpeg.info/board/thread.php?threadid=3885&sid=
.12:32:24.<@Mosu> solange is uns das schon recht ;)
.12:32:26.< DVDtoOgm> na also...
.12:32:44.< DVDtoOgm> das klingt doch gut... und ich brech mir hier einen in englisch ab...
.12:33:08.< DVDtoOgm> naja, es kommen auch noch ein paar eMail dazu, die er geschrieben hat.
.12:33:23.<@Mosu> offizielle sprache des channels is auch englisch ;)
.12:33:25.-!- jcsston_zZz [jcsston at 207534E3.F8ECB96B.1AF242AD.IP] has joined #matroska
.12:33:35.< alex_here> "das klingt doch gut... und ich brech mir hier einen in englisch ab..." <= liegt daran, da? es unfreundlich ist, deutsch zu reden, weil das hier net jeder kann
.12:33:42.-!- jcsston_zZz is now known as jcsston
.12:33:42.< alex_here> franz?sisch ginge also notfalls auch noch ;)
.12:33:46.<@Mosu> wir haben zu viele franzosen, die kein deutsch koennen (und zu viele amis, die ebenfals kein deutsch koennen ;))
.12:33:47.< DVDtoOgm> Homepage von DVDtoOgm ist http://DVDtoOgm.DivX-Digest.com
.12:33:56.< DVDtoOgm> ok, then back to english...
.12:34:02.< DVDtoOgm> I'll try...
.12:34:22.< alex_here> ?????? :)
.12:34:35.<@Mosu> ah. well something like dvdtoogm is still missing for matroska, that's true
.12:34:55.<@Mosu> as gknot won't have matroska support soon
.12:35:22.< DVDtoOgm> yes... I'm very close to a new release, which will try to come close to the features that are offered by GKnot...
.12:35:36.< alex_here> yeah...this guy does not get the fact the matroska overhead prediction is not done using a simple formula :(
.12:35:47.< alex_here> the=that
.12:35:52.< DVDtoOgm> Then I would be very interested in a full MKV support, which is atm not very good...
.12:36:01.<@Mosu> great to hear :)
.12:36:12.< DVDtoOgm> BUT:
.12:36:21.<@Mosu> everything you've listed on the 'was ist dvdtoogm?' page is definitely possible with matroska
.12:36:46.< DVDtoOgm> Christian told me DVDtoOgm have to be open-source for that...
.12:36:50.<@Mosu> hmm
.12:36:53.<@Mosu> depends
.12:37:00.* alex_here has read that thread :o
.12:37:17.< DVDtoOgm> and thats not really what i want it to be... :-)
.12:37:21.<@Mosu> if you 'only' use other open source tools, e.g. my mkvmerge, then it's not required, i think
.12:37:33.<@Mosu> but if you re-use our code then your code has to be gpl'ed as well
.12:38:03.< DVDtoOgm> all, used in Code used in DVDtoOgm is self coded...
.12:38:13.< alex_here> really?
.12:38:13.< DVDtoOgm> or I asked for permission...
.12:38:13.<@Mosu> judging from the 'was ist dvdtoogm' page i'd say that calling an external app would suffice for all those tasks
.12:38:23.< alex_here> you don't use libvorbis and such crap?
.12:39:02.< DVDtoOgm> well just a Mpeg2Dec.dll and some external Tools like VDubMod...
.12:39:09.< DVDtoOgm> no libvorbis so far...
.12:39:21.< DVDtoOgm> (MKV support is just about to start)
.12:39:32.< alex_here> without libmatroska, right? :D
.12:39:55.< DVDtoOgm> you just can choose mkv output...
.12:39:56.<@Mosu> i think dvdtoogm does not write ogm files itself but haves other apps do that for it
.12:40:03.<@Mosu> haves !?
.12:40:04.<@Mosu> omg
.12:40:09.<@Mosu> am i totally brain damaged now?
.12:40:11.< DVDtoOgm> VirtualDubMod 
.12:40:12.< alex_here> ah
.12:40:31.< alex_here> "Mosu	am i totally brain damaged now?" <= :)
.12:40:35.<@Mosu> so yes, matroska could be realized in the same way then without your code having to be open source
.12:40:46.< alex_here> "DVDtoOgm	VirtualDubMod " <= i hope you don't use those builds which write b0rked files
.12:41:06.<@Mosu> alex_here: i'm fighting with/against automake at the moment, so every mistake i make here is already excused ;)
.12:41:10.< alex_here> http://www.flaskmpeg.info/board/thread.php?threadid=3875&sid=50423e391c98b3367dac176cba742902 <= lol
.12:41:11.< DVDtoOgm> The new DVDtoOgm Release 1.40 (out soon)
.12:42:04.< DVDtoOgm> uses VDubMod 1.5.4
.12:42:12.< alex_here> which one?
.12:42:18.< alex_here> builds 2092 and earlier are b0rked
.12:42:18.< DVDtoOgm> after I requestsd the spli feature...
.12:42:38.< DVDtoOgm> it is 2092
.12:42:45.< alex_here> :-)
.12:42:53.< DVDtoOgm> but a update is no problem...
.12:42:57.< alex_here> this one suffers from a b0rk in libebml :D
.12:43:01.< alex_here> good
.12:43:15.< DVDtoOgm> its not released yet...
.12:43:20.<@Mosu> ah yes, after having read the thread i know why christian insisted on opensource software
.12:43:31.<@Mosu> well i personally don't think it's THAT bad
.12:43:38.<@Mosu> because you're not one of our core members
.12:43:46.< alex_here> he's a bit paranoid
.12:44:06.<@Mosu> so if you write some closed-source app no one can say that we (as in 'the core matroska devels') want world domination and a shitload of money
.12:44:06.< DVDtoOgm> I can understand him, but I'm not really interested in doing so out of 2 reasons...
.12:44:10.< alex_here> he even protested when i added possibilities to intentionally write b0rked files for testing purposes in avi-mux gui
.12:44:51.-!- Toff_eating is now known as Toff
.12:45:18.< DVDtoOgm> well so I'll be glad to help Matroska with DVDtoOgm, but I dislike to go open source for this...
.12:45:40.<@Mosu> i think we can come to   an agreement here
.12:45:42.< DVDtoOgm> if a closed source tool is ok, I would be VERY happy to help...
.12:45:54.<@Mosu> i'd say 'yes'
.12:46:02.<@Mosu> and we'll convince chris, too
.12:46:10.< DVDtoOgm> yes to closed sourse?
.12:46:13.< DVDtoOgm> source
.12:46:21.<@Mosu> yes
.12:46:26.< DVDtoOgm> that sounds nice...
.12:46:30.<@Mosu> but lemme get this straight
.12:46:38.< DVDtoOgm> yes?
.12:46:50.<@Mosu> your app calls external apsp for most of the work, e.g. muxing, extracting etc?
.12:47:00.< DVDtoOgm> yepp....
.12:47:07.<@Mosu> ok, then closed source ain't a problem for me
.12:47:16.< DVDtoOgm> you can easily compare DVDtoOgm to Gordian Knot...
.12:47:24.<@Mosu> that's what i thought
.12:47:27.< DVDtoOgm> just for Ogm...
.12:47:31.<@Mosu> i just wanted to make sure
.12:47:58.< DVDtoOgm> maybe you should download DVDtoOgm and have a look at it...
.12:48:06.< DVDtoOgm> (a older release)
.12:48:07.<@Mosu> i usually don't use windows ;)
.12:48:15.< DVDtoOgm> oh :-)
.12:48:31.< DVDtoOgm> but very much people do so :-)
.12:48:42.<@Mosu> i know :)
.12:48:48.< DVDtoOgm> ok...
.12:48:50.< DVDtoOgm> so:
.12:49:37.< DVDtoOgm> I'll release DVDtoOgm 1.40 (which is almost finished...) and after this we'll work on Matroska support...
.12:49:40.< DVDtoOgm> :-)
.12:49:45.<@Mosu> sounds great
.12:49:50.< DVDtoOgm> Hust an important note:
.12:49:55.< DVDtoOgm> Hust -> Just
.12:50:19.< DVDtoOgm> My knowledge about coding is not sooo good...
.12:50:38.< alex_here> that's more than Christian :)
.12:50:42.< DVDtoOgm> I learned in school and the rest I thought myself..
.12:51:04.< alex_here> the only thing I was *taught* is Haskell
.12:51:16.< alex_here> you can't be taught coding 
.12:51:22.< DVDtoOgm> slowly I'm rewriting parts of DVDtoOgm to make them better, but I'm still not a hero on coding...
.12:51:29.<@Mosu> hey, if you've gotten so far with dvdtoogm then the rest won't be much harder
.12:51:43.< DVDtoOgm> Hehe, nice to hear :-)
.12:51:56.<@Mosu> don't worry, not everyone here is the Superhero of Effective Coding either ;)
.12:52:01.< DVDtoOgm> DVDtoOgm is in Delphi (like you might guessed)
.12:52:09.< alex_here> omg :p
.12:52:32.< DVDtoOgm> ok, this sounds all very good...
.12:52:59.< DVDtoOgm> So, next problem:
.12:53:12.< DVDtoOgm> Never worked with Mkv bevore :-(
.12:53:29.< DVDtoOgm> I just concentrated on ogm, so what are the current features?
.12:53:33.< Rounin> Anyone wanna come up with a name for my text editor? (Sorry to interrupt, btw)
.12:54:53.< DVDtoOgm> ???
.12:55:18.< Rounin> Yeah, that could work
.12:55:24.<@Mosu> Rounin: how about 'puke'? :)
.12:56:02.< jcsston> or 'Runny' ?
.12:56:05.< DVDtoOgm> ?h?!?
.12:56:05.< Rounin> T_T Beautiful...
.12:56:19.<@Mosu> DVDtoOgm: well basically it can do everything ogm can do and then some. implemented in various tools are e.g. realvideo, usual mpeg4 video, ac3/aac/mp3/dts/vorbis/realaudio, srt subs, ssa subs, vobsubs, chapters, tags
.12:56:21.< DVDtoOgm> So what about the features of Mkv for now...
.12:56:21.< Rounin> Hahaha... I'm actively considering that last one
.12:56:34.< DVDtoOgm> ah...
.12:56:35.< DVDtoOgm> THX
.12:57:03.< DVDtoOgm> That sounds good...
.12:57:04.<@Mosu> vdubmod can handle most of them, mkvmerge can handle all of those
.12:57:25.<@Mosu> mkvmerge is a command line program for creating matroska files
.12:57:38.<@Mosu> alex_here's avi-mux gui is a gui app for the same purpose
.12:57:46.< DVDtoOgm> Ok, so the handling of Ogm and MKV in VDubMod ist the same=
.12:57:47.< Rounin> ?h is go... I wonder if I could find some Swedish phrase to make it into an acronym
.12:57:48.< DVDtoOgm> ?
.12:58:10.<@Mosu> basically yes, but i'm no expert on this topic
.12:58:16.<@Mosu> you'd have to ask cyrius when he's here
.12:58:26.<@Mosu> which is usually afternoon/evenings
.12:58:33.< DVDtoOgm> ok, got to chat with Cyruis again, he :-))
.12:58:59.< alex_here> "Ok, so the handling of Ogm and MKV in VDubMod ist the same=" <= not really. You should not even dream about joining several mkv files into one file using vdm
.12:59:09.< DVDtoOgm> we had a lot a conversation already...
.12:59:39.< DVDtoOgm> so no muxing with VirtualDubMod?
.12:59:44.< DVDtoOgm> for Mkv?
.12:59:58.<@Mosu> hehehe
.12:59:59.< alex_here> muxing ey
.13:00:02.< alex_here> yes
.13:00:09.< alex_here> but don't use MKV as input
.13:00:24.< DVDtoOgm> well, input would be avi...
.13:00:27.<@Mosu> that wouldn't be necessary, i think
.13:00:32.<@Mosu> so yes, vdubmod can be used
.13:00:33.< alex_here> good
.13:00:34.<@Mosu> but
.13:00:37.<@Mosu> talk to cyrius ;)
.13:00:56.< DVDtoOgm> jepp, I'll do so, after DVDtoOgm 1.40 is out...
.13:01:30.< DVDtoOgm> This sounds all very nice... we just need a Name :-))))
.13:02:00.< DVDtoOgm> DVDto -> OGM <- wouldn't be best!
.13:02:34.< alex_here> DVDtoAVI :)
.13:02:45.< DVDtoOgm> why that?
.13:02:53.-!- bond [~bond at CC-E4F8D42.adsl.univie.ac.at] has quit []
.13:02:56.< DVDtoOgm> DVDto???
.13:03:03.< alex_here> because I like AVI :)
.13:03:22.-!- superdump [~Robert at 213FF3BD.86FDEB6A.1A13A32B.IP] has quit [Connection reset by peer]
.13:03:31.< DVDtoOgm> yeah well, the name should not be of what you like and what you don't ;-)
.13:03:48.< DVDtoOgm> ok... so lets stop here... i got work to do...
.13:03:49.<@Mosu> DVDtoSomethingBetter ;)
.13:03:51.<@Mosu> me too
.13:03:59.<@Mosu> have to go to minimal
.13:04:09.< DVDtoOgm> well check that all in about 2-3 weeks :-9
.13:04:58.< DVDtoOgm> Thank you, for this information... and habe a chat to christian about this open source stuff :-)
.13:05:11.<@Mosu> i'll write an email, too, with this conversation
.13:05:15.-!- Insolit [~81.84.13. at 3402A868.16EA7345.340977B5.IP] has quit [Ping timeout]
.13:05:19.< DVDtoOgm> Good bye... Thx for help!
.13:05:24.<@Mosu> anyway, be back later
.13:05:26.<@Mosu> you're welcome
.13:05:27.< DVDtoOgm> @ Mosu: THX
.13:05:27.-!- You're now known as MosuAway
.13:05:35.< DVDtoOgm> CU

I've expressed my thoughts already during the conversation, but I really
don't see that DVDtoOGM going OpenSource should be a neccessity. He'll
just use our _apps_, not our _code_. This project could be a good
replacement for GKnot's Matroska support which is not coming. And no one
can really accuse us in this case 'cause it's a totally different
project/person who will use our tools. We (as in 'the core Matroska
devels') are all OpenSource. A ClosedSource app is going to use our
tools. So what?

My vote is 'go for it!'.

-- 
 ==> Ciao, Mosu (Moritz Bunkus)


From chris at matroska.org  Sat Nov  1 15:50:28 2003
From: chris at matroska.org (Christian HJ Wiesner)
Date: Sat, 01 Nov 2003 15:50:28 +0100
Subject: [Matroska-devel] DVDtoOGM with Matroska support
In-Reply-To: <20031101135224.GL13719@bunkus.org>
References: <20031101135224.GL13719@bunkus.org>
Message-ID: <3FA3C834.400@matroska.org>

Hi Mosu,

first of all, let me say that this email, IMHO, should go to 
matroska-general and not to matroska-devel, as its not really 
development related. I copy matroska-general on it, and i recommend to 
reply to there insted. My answer can be found below.

Moritz Bunkus wrote:

>Hi.
>
>This conversation took place today:
>
>.12:21:42.< DVDtoOgm> Hi...
>.12:23:52.< DVDtoOgm> ChristianHJW available?
>.12:24:28.< alex_here> wake him up :p
>.12:24:43.< DVDtoOgm> oh... sleeping :-)
>.12:25:06.< DVDtoOgm> do you know when he's usually here?
>.12:25:14.< alex_here> what do you need him for?
>.12:25:33.< DVDtoOgm> talking about DVDtoOgm and Matroska...
>.12:25:49.< alex_here> you don't need him for that :)
>.12:25:51.<@Mosu> he's in china at the moment,
>.12:26:09.< DVDtoOgm> wow... seems to be far away from talking with me :-)
>.12:26:13.<@Mosu> but he's online from time to time
>.12:26:32.< DVDtoOgm> well might be hard to catch this time 
>.12:26:56.< DVDtoOgm> when will he return from there? do you know?
>.12:27:21.< alex_here> another question: what does he know what we don't?
>.12:27:32.< DVDtoOgm> well, let me tell you:
>.12:28:09.< DVDtoOgm> He asked me, if I'm interested in making DVDtoOgm (maybe with another name) to the official Matroska support tool...
>.12:28:25.< DVDtoOgm> and he invited me to come here...
>.12:28:31.< alex_here> The tool as in 'the one and only'?
>.12:29:07.< DVDtoOgm> well, somethink like this...
>.12:29:39.< alex_here> omg
>.12:29:57.<@Mosu> oyg? :)
>.12:30:09.< DVDtoOgm> we had a german conversation via eMail and he posted some requests in the official german DVDtoOgm-Frounm
>.12:30:14.< DVDtoOgm> Forum, sorry
>.12:30:20.< alex_here> what does he always need such things for :(
>.12:30:30.< DVDtoOgm> for what?
>.12:30:34.< alex_here> can you give a link?
>.12:30:50.< DVDtoOgm> forum or DVDtoOgm-Homepage?
>.12:30:54.<@Mosu> the latter
>.12:30:57.< alex_here> forum
>.12:31:02.<@Mosu> doh :)
>.12:31:06.<@Mosu> for both, then ;)
>.12:31:08.< alex_here> better just the corresponding thread
>.12:31:17.< DVDtoOgm> second..
>.12:31:31.< DVDtoOgm> (its german, remember) :-)
>.12:31:42.-!- P0l1m0rph1c [~Dcoder at CC-3BB7AC4E.telepac.pt] has joined #matroska
>.12:31:49.< alex_here> solange es nicht chinesisch ist...
>.12:32:19.<@Mosu> genau
>.12:32:20.< DVDtoOgm> http://www.flaskmpeg.info/board/thread.php?threadid=3885&sid=
>.12:32:24.<@Mosu> solange is uns das schon recht ;)
>.12:32:26.< DVDtoOgm> na also...
>.12:32:44.< DVDtoOgm> das klingt doch gut... und ich brech mir hier einen in englisch ab...
>.12:33:08.< DVDtoOgm> naja, es kommen auch noch ein paar eMail dazu, die er geschrieben hat.
>.12:33:23.<@Mosu> offizielle sprache des channels is auch englisch ;)
>.12:33:25.-!- jcsston_zZz [jcsston at 207534E3.F8ECB96B.1AF242AD.IP] has joined #matroska
>.12:33:35.< alex_here> "das klingt doch gut... und ich brech mir hier einen in englisch ab..." <= liegt daran, da? es unfreundlich ist, deutsch zu reden, weil das hier net jeder kann
>.12:33:42.-!- jcsston_zZz is now known as jcsston
>.12:33:42.< alex_here> franz?sisch ginge also notfalls auch noch ;)
>.12:33:46.<@Mosu> wir haben zu viele franzosen, die kein deutsch koennen (und zu viele amis, die ebenfals kein deutsch koennen ;))
>.12:33:47.< DVDtoOgm> Homepage von DVDtoOgm ist http://DVDtoOgm.DivX-Digest.com
>.12:33:56.< DVDtoOgm> ok, then back to english...
>.12:34:02.< DVDtoOgm> I'll try...
>.12:34:22.< alex_here> ?????? :)
>.12:34:35.<@Mosu> ah. well something like dvdtoogm is still missing for matroska, that's true
>.12:34:55.<@Mosu> as gknot won't have matroska support soon
>.12:35:22.< DVDtoOgm> yes... I'm very close to a new release, which will try to come close to the features that are offered by GKnot...
>.12:35:36.< alex_here> yeah...this guy does not get the fact the matroska overhead prediction is not done using a simple formula :(
>.12:35:47.< alex_here> the=that
>.12:35:52.< DVDtoOgm> Then I would be very interested in a full MKV support, which is atm not very good...
>.12:36:01.<@Mosu> great to hear :)
>.12:36:12.< DVDtoOgm> BUT:
>.12:36:21.<@Mosu> everything you've listed on the 'was ist dvdtoogm?' page is definitely possible with matroska
>.12:36:46.< DVDtoOgm> Christian told me DVDtoOgm have to be open-source for that...
>.12:36:50.<@Mosu> hmm
>.12:36:53.<@Mosu> depends
>.12:37:00.* alex_here has read that thread :o
>.12:37:17.< DVDtoOgm> and thats not really what i want it to be... :-)
>.12:37:21.<@Mosu> if you 'only' use other open source tools, e.g. my mkvmerge, then it's not required, i think
>.12:37:33.<@Mosu> but if you re-use our code then your code has to be gpl'ed as well
>.12:38:03.< DVDtoOgm> all, used in Code used in DVDtoOgm is self coded...
>.12:38:13.< alex_here> really?
>.12:38:13.< DVDtoOgm> or I asked for permission...
>.12:38:13.<@Mosu> judging from the 'was ist dvdtoogm' page i'd say that calling an external app would suffice for all those tasks
>.12:38:23.< alex_here> you don't use libvorbis and such crap?
>.12:39:02.< DVDtoOgm> well just a Mpeg2Dec.dll and some external Tools like VDubMod...
>.12:39:09.< DVDtoOgm> no libvorbis so far...
>.12:39:21.< DVDtoOgm> (MKV support is just about to start)
>.12:39:32.< alex_here> without libmatroska, right? :D
>.12:39:55.< DVDtoOgm> you just can choose mkv output...
>.12:39:56.<@Mosu> i think dvdtoogm does not write ogm files itself but haves other apps do that for it
>.12:40:03.<@Mosu> haves !?
>.12:40:04.<@Mosu> omg
>.12:40:09.<@Mosu> am i totally brain damaged now?
>.12:40:11.< DVDtoOgm> VirtualDubMod 
>.12:40:12.< alex_here> ah
>.12:40:31.< alex_here> "Mosu	am i totally brain damaged now?" <= :)
>.12:40:35.<@Mosu> so yes, matroska could be realized in the same way then without your code having to be open source
>.12:40:46.< alex_here> "DVDtoOgm	VirtualDubMod " <= i hope you don't use those builds which write b0rked files
>.12:41:06.<@Mosu> alex_here: i'm fighting with/against automake at the moment, so every mistake i make here is already excused ;)
>.12:41:10.< alex_here> http://www.flaskmpeg.info/board/thread.php?threadid=3875&sid=50423e391c98b3367dac176cba742902 <= lol
>.12:41:11.< DVDtoOgm> The new DVDtoOgm Release 1.40 (out soon)
>.12:42:04.< DVDtoOgm> uses VDubMod 1.5.4
>.12:42:12.< alex_here> which one?
>.12:42:18.< alex_here> builds 2092 and earlier are b0rked
>.12:42:18.< DVDtoOgm> after I requestsd the spli feature...
>.12:42:38.< DVDtoOgm> it is 2092
>.12:42:45.< alex_here> :-)
>.12:42:53.< DVDtoOgm> but a update is no problem...
>.12:42:57.< alex_here> this one suffers from a b0rk in libebml :D
>.12:43:01.< alex_here> good
>.12:43:15.< DVDtoOgm> its not released yet...
>.12:43:20.<@Mosu> ah yes, after having read the thread i know why christian insisted on opensource software
>.12:43:31.<@Mosu> well i personally don't think it's THAT bad
>.12:43:38.<@Mosu> because you're not one of our core members
>.12:43:46.< alex_here> he's a bit paranoid
>.12:44:06.<@Mosu> so if you write some closed-source app no one can say that we (as in 'the core matroska devels') want world domination and a shitload of money
>.12:44:06.< DVDtoOgm> I can understand him, but I'm not really interested in doing so out of 2 reasons...
>.12:44:10.< alex_here> he even protested when i added possibilities to intentionally write b0rked files for testing purposes in avi-mux gui
>.12:44:51.-!- Toff_eating is now known as Toff
>.12:45:18.< DVDtoOgm> well so I'll be glad to help Matroska with DVDtoOgm, but I dislike to go open source for this...
>.12:45:40.<@Mosu> i think we can come to   an agreement here
>.12:45:42.< DVDtoOgm> if a closed source tool is ok, I would be VERY happy to help...
>.12:45:54.<@Mosu> i'd say 'yes'
>.12:46:02.<@Mosu> and we'll convince chris, too
>.12:46:10.< DVDtoOgm> yes to closed sourse?
>.12:46:13.< DVDtoOgm> source
>.12:46:21.<@Mosu> yes
>.12:46:26.< DVDtoOgm> that sounds nice...
>.12:46:30.<@Mosu> but lemme get this straight
>.12:46:38.< DVDtoOgm> yes?
>.12:46:50.<@Mosu> your app calls external apsp for most of the work, e.g. muxing, extracting etc?
>.12:47:00.< DVDtoOgm> yepp....
>.12:47:07.<@Mosu> ok, then closed source ain't a problem for me
>.12:47:16.< DVDtoOgm> you can easily compare DVDtoOgm to Gordian Knot...
>.12:47:24.<@Mosu> that's what i thought
>.12:47:27.< DVDtoOgm> just for Ogm...
>.12:47:31.<@Mosu> i just wanted to make sure
>.12:47:58.< DVDtoOgm> maybe you should download DVDtoOgm and have a look at it...
>.12:48:06.< DVDtoOgm> (a older release)
>.12:48:07.<@Mosu> i usually don't use windows ;)
>.12:48:15.< DVDtoOgm> oh :-)
>.12:48:31.< DVDtoOgm> but very much people do so :-)
>.12:48:42.<@Mosu> i know :)
>.12:48:48.< DVDtoOgm> ok...
>.12:48:50.< DVDtoOgm> so:
>.12:49:37.< DVDtoOgm> I'll release DVDtoOgm 1.40 (which is almost finished...) and after this we'll work on Matroska support...
>.12:49:40.< DVDtoOgm> :-)
>.12:49:45.<@Mosu> sounds great
>.12:49:50.< DVDtoOgm> Hust an important note:
>.12:49:55.< DVDtoOgm> Hust -> Just
>.12:50:19.< DVDtoOgm> My knowledge about coding is not sooo good...
>.12:50:38.< alex_here> that's more than Christian :)
>.12:50:42.< DVDtoOgm> I learned in school and the rest I thought myself..
>.12:51:04.< alex_here> the only thing I was *taught* is Haskell
>.12:51:16.< alex_here> you can't be taught coding 
>.12:51:22.< DVDtoOgm> slowly I'm rewriting parts of DVDtoOgm to make them better, but I'm still not a hero on coding...
>.12:51:29.<@Mosu> hey, if you've gotten so far with dvdtoogm then the rest won't be much harder
>.12:51:43.< DVDtoOgm> Hehe, nice to hear :-)
>.12:51:56.<@Mosu> don't worry, not everyone here is the Superhero of Effective Coding either ;)
>.12:52:01.< DVDtoOgm> DVDtoOgm is in Delphi (like you might guessed)
>.12:52:09.< alex_here> omg :p
>.12:52:32.< DVDtoOgm> ok, this sounds all very good...
>.12:52:59.< DVDtoOgm> So, next problem:
>.12:53:12.< DVDtoOgm> Never worked with Mkv bevore :-(
>.12:53:29.< DVDtoOgm> I just concentrated on ogm, so what are the current features?
>.12:53:33.< Rounin> Anyone wanna come up with a name for my text editor? (Sorry to interrupt, btw)
>.12:54:53.< DVDtoOgm> ???
>.12:55:18.< Rounin> Yeah, that could work
>.12:55:24.<@Mosu> Rounin: how about 'puke'? :)
>.12:56:02.< jcsston> or 'Runny' ?
>.12:56:05.< DVDtoOgm> ?h?!?
>.12:56:05.< Rounin> T_T Beautiful...
>.12:56:19.<@Mosu> DVDtoOgm: well basically it can do everything ogm can do and then some. implemented in various tools are e.g. realvideo, usual mpeg4 video, ac3/aac/mp3/dts/vorbis/realaudio, srt subs, ssa subs, vobsubs, chapters, tags
>.12:56:21.< DVDtoOgm> So what about the features of Mkv for now...
>.12:56:21.< Rounin> Hahaha... I'm actively considering that last one
>.12:56:34.< DVDtoOgm> ah...
>.12:56:35.< DVDtoOgm> THX
>.12:57:03.< DVDtoOgm> That sounds good...
>.12:57:04.<@Mosu> vdubmod can handle most of them, mkvmerge can handle all of those
>.12:57:25.<@Mosu> mkvmerge is a command line program for creating matroska files
>.12:57:38.<@Mosu> alex_here's avi-mux gui is a gui app for the same purpose
>.12:57:46.< DVDtoOgm> Ok, so the handling of Ogm and MKV in VDubMod ist the same=
>.12:57:47.< Rounin> ?h is go... I wonder if I could find some Swedish phrase to make it into an acronym
>.12:57:48.< DVDtoOgm> ?
>.12:58:10.<@Mosu> basically yes, but i'm no expert on this topic
>.12:58:16.<@Mosu> you'd have to ask cyrius when he's here
>.12:58:26.<@Mosu> which is usually afternoon/evenings
>.12:58:33.< DVDtoOgm> ok, got to chat with Cyruis again, he :-))
>.12:58:59.< alex_here> "Ok, so the handling of Ogm and MKV in VDubMod ist the same=" <= not really. You should not even dream about joining several mkv files into one file using vdm
>.12:59:09.< DVDtoOgm> we had a lot a conversation already...
>.12:59:39.< DVDtoOgm> so no muxing with VirtualDubMod?
>.12:59:44.< DVDtoOgm> for Mkv?
>.12:59:58.<@Mosu> hehehe
>.12:59:59.< alex_here> muxing ey
>.13:00:02.< alex_here> yes
>.13:00:09.< alex_here> but don't use MKV as input
>.13:00:24.< DVDtoOgm> well, input would be avi...
>.13:00:27.<@Mosu> that wouldn't be necessary, i think
>.13:00:32.<@Mosu> so yes, vdubmod can be used
>.13:00:33.< alex_here> good
>.13:00:34.<@Mosu> but
>.13:00:37.<@Mosu> talk to cyrius ;)
>.13:00:56.< DVDtoOgm> jepp, I'll do so, after DVDtoOgm 1.40 is out...
>.13:01:30.< DVDtoOgm> This sounds all very nice... we just need a Name :-))))
>.13:02:00.< DVDtoOgm> DVDto -> OGM <- wouldn't be best!
>.13:02:34.< alex_here> DVDtoAVI :)
>.13:02:45.< DVDtoOgm> why that?
>.13:02:53.-!- bond [~bond at CC-E4F8D42.adsl.univie.ac.at] has quit []
>.13:02:56.< DVDtoOgm> DVDto???
>.13:03:03.< alex_here> because I like AVI :)
>.13:03:22.-!- superdump [~Robert at 213FF3BD.86FDEB6A.1A13A32B.IP] has quit [Connection reset by peer]
>.13:03:31.< DVDtoOgm> yeah well, the name should not be of what you like and what you don't ;-)
>.13:03:48.< DVDtoOgm> ok... so lets stop here... i got work to do...
>.13:03:49.<@Mosu> DVDtoSomethingBetter ;)
>.13:03:51.<@Mosu> me too
>.13:03:59.<@Mosu> have to go to minimal
>.13:04:09.< DVDtoOgm> well check that all in about 2-3 weeks :-9
>.13:04:58.< DVDtoOgm> Thank you, for this information... and habe a chat to christian about this open source stuff :-)
>.13:05:11.<@Mosu> i'll write an email, too, with this conversation
>.13:05:15.-!- Insolit [~81.84.13. at 3402A868.16EA7345.340977B5.IP] has quit [Ping timeout]
>.13:05:19.< DVDtoOgm> Good bye... Thx for help!
>.13:05:24.<@Mosu> anyway, be back later
>.13:05:26.<@Mosu> you're welcome
>.13:05:27.< DVDtoOgm> @ Mosu: THX
>.13:05:27.-!- You're now known as MosuAway
>.13:05:35.< DVDtoOgm> CU
>
>I've expressed my thoughts already during the conversation, but I really
>don't see that DVDtoOGM going OpenSource should be a neccessity. He'll
>just use our _apps_, not our _code_. This project could be a good
>replacement for GKnot's Matroska support which is not coming. And no one
>can really accuse us in this case 'cause it's a totally different
>project/person who will use our tools. We (as in 'the core Matroska
>devels') are all OpenSource. A ClosedSource app is going to use our
>tools. So what?
>My vote is 'go for it!'.
>  
>
To understand why i am so paranoid about going opensource with such a 
tool is founded on a couple of reasons :

1. I was planning to make this program a fixed part of the complete 
matroska project, not just an app that will output MKV files, like many 
others. As such, it HAS to be opensource, as a nobody will understadn 
that an opensource team is promoting a closed source app as main 
creation program. Our 'enemies', if we have such, would love to get such 
an argument from us, to use it against us. In short, if DVDtoMKV would 
not go opensource, we can list it as an app supporting MKV creation, but 
i wont push it as the official tool then. Sorry, but i am not willing to 
negotiate here. Of course, any other project admin can do whatever he 
likes in this respect, but then he will have to invest his time.

2. DVD, like so many other coders, is simply freightened to publish his 
code because he feels to be critized for his coding style, of which he 
is uncertain, thats all. Apart from that, there is no sensible reason 
not to go opensource with it. Even worse, if he went opensource with it, 
and if we made sure that new devs wanting to join the team are not 
treated like in other, similar projects, means there is one developer 
playing Mr. Big Boss, blocking new code best he can if its not coming 
from him, etc. , then DVDtoMKV could become an excellent program and 
opensource project. Furthermore, corecodec.org needs a tool such as 
DVDtoMKV, and opensource, as such a tool can lead a lot of attraction to 
the whole community.

3.  DVDtoMKV, the offiicial MKV DVD backup tool, has to use mkvmerge for 
MKV creation, and nothing else. VdubMod, although being an excellent 
tool and a great basis for the usability of MKV ( pls. dont get me wrong 
here ), simply doesnt support enough of MKVs extraordinary features such 
as aspect ratio correction, SSA subs muxing, vobsub muxing, etc. More 
specifically, all features VdubMod supports in MKV are usable for OGM 
also, so we arent any better than it if it is used.

@ DVD : stop sobbing around, go to corecodec.org and create a new 
project called DVDtoMKV there :P !!! There is no reason to be afraid 
about your coding style and such shit, just do it, and you will see that 
going opensource and hearing what other people do different than you, is 
the ONLY real possibility to learn a better coding style ! As long as 
your proggie is closed, it will give you more experience, but only more 
experience in using your very own coding style, you will never be able 
to open your horizon that way ! See the difference ??

As soon as DVD agrees to do that and to use mkvmerge ( he will :D ) and 
the project is created on corecodec.org, i will write a detailled 
feature list the program should be able to handle. Of course, not 
tomorrow, i meanwhile know how opensource stuff is wroking out .... you 
need to be very very patient  ;-) .....

Christian
 







From gabest at freemail.hu  Sat Nov  1 23:18:34 2003
From: gabest at freemail.hu (Gabest)
Date: Sat, 1 Nov 2003 23:18:34 +0100
Subject: [Matroska-devel] Re: MPEG2 in MKV!
References: <02b101c39f07$c3970e30$0100a8c0@i2400p4><bnrhib$hg5$1@sea.gmane.org>
	<20031030173209.GB13719@bunkus.org>
Message-ID: <0b5801c3a0c6$17e331c0$0100a8c0@i2400p4>

> This one's outdated. It still contains the MPEG PS around the SPUs which
> we now discard. Updated samples are available at...
> http://www.bunkus.org/videotools/mkvtoolnix/vobsubs-uncomp2.mkv
> http://www.bunkus.org/videotools/mkvtoolnix/vobsubs-zlibcomp2.mkv

I'm just testing these mkvs with vobsub, and already found two probs :)

The first is about the duration, it just doesn't seem to be correct. (How
does it get calculated by the muxer?) Here for example it should be around
2355ms:

| + Block group
|  + Block (track number 4, 1 frame(s), timecode 19.280s)
|   + Frame with size 1576
|  + Block duration: 4400.000ms

The second problem:

| + Block group
|  + Block (track number 3, 1 frame(s), timecode 23.840s)
|   + Frame with size 2019
|  + Block duration: 4400.000ms
| + Block group
|  + Block (track number 3, 1 frame(s), timecode 23.840s)
|   + Frame with size 109
|  + Block duration: 4400.000ms

I think we should really put all data into one block for one subtitle...
Just like in the case of realmedia, when I tried to store fragments of a
frame into multiple blocks, but then was corrected.

(3rd little problem: where do I find zlib for vc7? I know I could probably
convert the sources at www.gzip.org/zlib, but I though it was easier to ask
first :)

Other.

I'm also updating the splitter and vsfilter now. For the splitter I've
created a new vobsub media subtype, and derived a new format struct from
SUBTITLEINFO for the new fields from CodecPrivate. I don't think anybody
cares about these but me, but I thought I'd mention it.
(/guliverkli/guliverkli/include/matroska/matroska.h was updated in the cvs)



From moritz at bunkus.org  Sun Nov  2 00:28:44 2003
From: moritz at bunkus.org (Moritz Bunkus)
Date: Sun, 2 Nov 2003 00:28:44 +0100
Subject: [Matroska-devel] Re: MPEG2 in MKV!
In-Reply-To: <0b5801c3a0c6$17e331c0$0100a8c0@i2400p4>
References: <20031030173209.GB13719@bunkus.org>
	<0b5801c3a0c6$17e331c0$0100a8c0@i2400p4>
Message-ID: <20031101232844.GP13719@bunkus.org>

Hi.

> I'm just testing these mkvs with vobsub, and already found two probs
> :)

Good :) I knew why I waited with the next mkvtoolnix release :)

> The first is about the duration, it just doesn't seem to be correct. (How
> does it get calculated by the muxer?) Here for example it should be around
> 2355ms:

Yeah yeah, I was lazy (no, I was ignorant). First I didn't know that the
SPU packets were inside a MPEG stream, and I just used the difference
between two entries in the .idx file as the duration.

How do I extract the duration from the SPU packets? I should probably
look at mplayer's sources, but maybe you have a quick explanation ;)

> I think we should really put all data into one block for one subtitle...
> Just like in the case of realmedia, when I tried to store fragments of a
> frame into multiple blocks, but then was corrected.

Ok, sounds reasonable. One entry corresponds to one line in the .idx
file, or should we just ignore those lines and parse the MPEG stream and
use those timestamps?

> (3rd little problem: where do I find zlib for vc7? I know I could probably
> convert the sources at www.gzip.org/zlib, but I though it was easier to ask
> first :)

I have no idea :)

Great you're working on it :)


-- 
 ==> Ciao, Mosu (Moritz Bunkus)


From gabest at freemail.hu  Sun Nov  2 02:03:11 2003
From: gabest at freemail.hu (Gabest)
Date: Sun, 2 Nov 2003 02:03:11 +0100
Subject: [Matroska-devel] Re: MPEG2 in MKV!
References: <20031030173209.GB13719@bunkus.org><0b5801c3a0c6$17e331c0$0100a8c0@i2400p4>
	<20031101232844.GP13719@bunkus.org>
Message-ID: <0bc301c3a0dd$16d7bdc0$0100a8c0@i2400p4>

> Yeah yeah, I was lazy (no, I was ignorant). First I didn't know that the
> SPU packets were inside a MPEG stream, and I just used the difference
> between two entries in the .idx file as the duration.
>
> How do I extract the duration from the SPU packets? I should probably
> look at mplayer's sources, but maybe you have a quick explanation ;)

Here is my stripped down function getting the properties of the subpic. The
two int args are the first two WORDs in the data. A bit redundant though,
since it could be extracted from lpData, but this function doesn't have to
know about the full subpic format :) Anyway, the "delay" variable will hold
the duration at the end.

void CVobSubImage::GetPacketInfo(BYTE* lpData, int packetsize, int datasize)
{
    int i, nextctrlblk = datasize;
    WORD pal, tr;
    do
    {
        i = nextctrlblk;
        int t = (lpData[i] << 8) | lpData[i+1]; i += 2;
        nextctrlblk = (lpData[i] << 8) | lpData[i+1]; i += 2;
        if(nextctrlblk > packetsize || nextctrlblk < datasize)
        {
            ASSERT(0);
            return;
        }
        bool fBreak = false;
        while(!fBreak)
        {
            int len = 0;
            switch(lpData[i])
            {
                case 0x00: len = 0; break;
                case 0x01: len = 0; break;
                case 0x02: len = 0; break;
                case 0x03: len = 2; break;
                case 0x04: len = 2; break;
                case 0x05: len = 6; break;
                case 0x06: len = 4; break;
                default: len = 0; break;
            }
            if(i+len >= packetsize)
            {
                TRACE(_T("Warning: Wrong subpicture parameter block
ending\n"));
                break;
            }
            switch(lpData[i++])
            {
                case 0x00: // forced start displaying
                    fForced = true;
                    break;
                case 0x01: // start displaying
                    fForced = false;
                    break;
                case 0x02: // stop displaying
                    delay = 1024 * t / 90;
                    break;
                // ...
                case 0xff: // end of ctrlblk
                    fBreak = true;
                    continue;
                default: // skip this ctrlblk
                    fBreak = true;
                    break;
                }
            }
        }
        while(i <= nextctrlblk && i < packetsize);
}

> > I think we should really put all data into one block for one subtitle...
> > Just like in the case of realmedia, when I tried to store fragments of a
> > frame into multiple blocks, but then was corrected.
>
> Ok, sounds reasonable. One entry corresponds to one line in the .idx
> file, or should we just ignore those lines and parse the MPEG stream and
> use those timestamps?

No. The additional 2k blocks will follow the entry point given in the idx,
but not right after, just in the order they were extracted from the dvd. You
can tell which by the stream id and where it ends by looking at the PES
packet length or the subpic's own packet length.

> > (3rd little problem: where do I find zlib for vc7? I know I could
probably
> > convert the sources at www.gzip.org/zlib, but I though it was easier to
ask
> > first :)
>
> I have no idea :)

Hm... anyone else?



From jcsston at toughguy.net  Sun Nov  2 02:25:14 2003
From: jcsston at toughguy.net (Jory)
Date: Sat, 1 Nov 2003 19:25:14 -0600
Subject: [Matroska-devel] Re: MPEG2 in MKV!
References: <20031030173209.GB13719@bunkus.org><0b5801c3a0c6$17e331c0$0100a8c0@i2400p4><20031101232844.GP13719@bunkus.org>
	<0bc301c3a0dd$16d7bdc0$0100a8c0@i2400p4>
Message-ID: <000401c3a0e0$61843a80$0200a8c0@jcsston>


----- Original Message -----
From: "Gabest" <gabest at freemail.hu>
To: "Discussion about the current and future development of Matroska"
<matroska-devel at lists.matroska.org>
Sent: Saturday, November 01, 2003 7:03 PM
Subject: Re: [Matroska-devel] Re: MPEG2 in MKV!


> > > (3rd little problem: where do I find zlib for vc7? I know I could
> probably
> > > convert the sources at www.gzip.org/zlib, but I though it was easier
to
> ask
> > > first :)
> >
> > I have no idea :)
>
> Hm... anyone else?
I've had no problem using the zlib version off the offical site. VC7
converts the VC6 project files without any fuss, or are you looking for an
asm version?

>
> _______________________________________________
> Matroska-devel mailing list
> Matroska-devel at lists.matroska.org
> http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel




From gabest at freemail.hu  Sun Nov  2 03:14:30 2003
From: gabest at freemail.hu (Gabest)
Date: Sun, 2 Nov 2003 03:14:30 +0100
Subject: [Matroska-devel] Re: MPEG2 in MKV!
References: <20031030173209.GB13719@bunkus.org><0b5801c3a0c6$17e331c0$0100a8c0@i2400p4><20031101232844.GP13719@bunkus.org><0bc301c3a0dd$16d7bdc0$0100a8c0@i2400p4>
	<000401c3a0e0$61843a80$0200a8c0@jcsston>
Message-ID: <0be901c3a0e7$0cc8ed90$0100a8c0@i2400p4>

> I've had no problem using the zlib version off the offical site. VC7
> converts the VC6 project files without any fuss, or are you looking for an
> asm version?

Which vc6 project files do you mean? The only two I found in the archive
(zlib-1.1.4.tar.gz) were at contrib/minizip and contrib/asm386, and when I
tried to open them, vc7 told me they were corrupted.




From jcsston at toughguy.net  Sun Nov  2 03:55:09 2003
From: jcsston at toughguy.net (Jory)
Date: Sat, 1 Nov 2003 20:55:09 -0600
Subject: [Matroska-devel] Re: MPEG2 in MKV!
References: <20031030173209.GB13719@bunkus.org><0b5801c3a0c6$17e331c0$0100a8c0@i2400p4><20031101232844.GP13719@bunkus.org><0bc301c3a0dd$16d7bdc0$0100a8c0@i2400p4><000401c3a0e0$61843a80$0200a8c0@jcsston>
	<0be901c3a0e7$0cc8ed90$0100a8c0@i2400p4>
Message-ID: <001001c3a0ec$bc6e5820$0200a8c0@jcsston>


----- Original Message -----
From: "Gabest" <gabest at freemail.hu>
To: "Discussion about the current and future development of Matroska"
<matroska-devel at lists.matroska.org>
Sent: Saturday, November 01, 2003 8:14 PM
Subject: Re: [Matroska-devel] Re: MPEG2 in MKV!


> > I've had no problem using the zlib version off the offical site. VC7
> > converts the VC6 project files without any fuss, or are you looking for
an
> > asm version?
>
> Which vc6 project files do you mean? The only two I found in the archive
> (zlib-1.1.4.tar.gz) were at contrib/minizip and contrib/asm386, and when I
> tried to open them, vc7 told me they were corrupted.
>
Now that I downloaded them again I see that it is a hassle to use them
(copying files to the correct folder, Unix line breaks).
Here's a .zip of the zlib copy I've been using
http://corepng.corecodec.org/zlib-1.1.4.zip

Sorry about not double-checking if I had the same .zip as one the site,
Jory
>
> _______________________________________________
> Matroska-devel mailing list
> Matroska-devel at lists.matroska.org
> http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel




From gabest at freemail.hu  Sun Nov  2 04:10:55 2003
From: gabest at freemail.hu (Gabest)
Date: Sun, 2 Nov 2003 04:10:55 +0100
Subject: [Matroska-devel] Re: MPEG2 in MKV!
References: <20031030173209.GB13719@bunkus.org><0b5801c3a0c6$17e331c0$0100a8c0@i2400p4><20031101232844.GP13719@bunkus.org><0bc301c3a0dd$16d7bdc0$0100a8c0@i2400p4><000401c3a0e0$61843a80$0200a8c0@jcsston><0be901c3a0e7$0cc8ed90$0100a8c0@i2400p4>
	<001001c3a0ec$bc6e5820$0200a8c0@jcsston>
Message-ID: <0c0f01c3a0ee$ee9dde90$0100a8c0@i2400p4>

> Now that I downloaded them again I see that it is a hassle to use them
> (copying files to the correct folder, Unix line breaks).
> Here's a .zip of the zlib copy I've been using
> http://corepng.corecodec.org/zlib-1.1.4.zip
> 
> Sorry about not double-checking if I had the same .zip as one the site,
> Jory

Thanks! I knew someone had a prepared version :D



From moritz at bunkus.org  Sun Nov  2 16:49:49 2003
From: moritz at bunkus.org (Moritz Bunkus)
Date: Sun, 2 Nov 2003 16:49:49 +0100
Subject: [Matroska-devel] Re: MPEG2 in MKV!
In-Reply-To: <0bc301c3a0dd$16d7bdc0$0100a8c0@i2400p4>
References: <20031101232844.GP13719@bunkus.org>
	<0bc301c3a0dd$16d7bdc0$0100a8c0@i2400p4>
Message-ID: <20031102154949.GR13719@bunkus.org>

Hi.

Updated my code and my samples. The new ones can be found at
http://www.bunkus.org/videotools/mkvtoolnix/vobsub-samples/

Please check them ;)

-- 
 ==> Ciao, Mosu (Moritz Bunkus)


From moritz at bunkus.org  Mon Nov  3 17:26:33 2003
From: moritz at bunkus.org (Moritz Bunkus)
Date: Mon, 3 Nov 2003 17:26:33 +0100
Subject: [Matroska-devel] Re: MPEG2 in MKV!
In-Reply-To: <20031102154949.GR13719@bunkus.org>
References: <20031101232844.GP13719@bunkus.org>
	<0bc301c3a0dd$16d7bdc0$0100a8c0@i2400p4>
	<20031102154949.GR13719@bunkus.org>
Message-ID: <20031103162633.GH17861@bunkus.org>

Hi.

Gabest? Any word on the updated samples? Are they packaged the way tou
want them to?

-- 
 ==> Ciao, Mosu (Moritz Bunkus)


From gabest at freemail.hu  Mon Nov  3 17:45:15 2003
From: gabest at freemail.hu (Gabest)
Date: Mon, 3 Nov 2003 17:45:15 +0100
Subject: [Matroska-devel] Re: MPEG2 in MKV!
References: <20031101232844.GP13719@bunkus.org><0bc301c3a0dd$16d7bdc0$0100a8c0@i2400p4><20031102154949.GR13719@bunkus.org>
	<20031103162633.GH17861@bunkus.org>
Message-ID: <016001c3a229$dbb11400$0100a8c0@i2400p4>

> Hi.
>
> Gabest? Any word on the updated samples? Are they packaged the way tou
> want them to?

Yep, the upcompressed sample was alright, but I couldn't test the zlib
version yet. Matroska splitter and dvobsub got their upgrade too, I'm only
having a little trouble with mpc's subtitle gtrabber filter now... :)



From gabest at freemail.hu  Mon Nov  3 21:43:29 2003
From: gabest at freemail.hu (Gabest)
Date: Mon, 03 Nov 2003 20:43:29 -0000
Subject: [Matroska-devel] Re: MPEG2 in MKV!
References: <20031101232844.GP13719@bunkus.org><0bc301c3a0dd$16d7bdc0$0100a8c0@i2400p4><20031102154949.GR13719@bunkus.org>
	<20031103162633.GH17861@bunkus.org>
Message-ID: <029201c389e6$9af97930$0100a8c0@i2400p4>

Anyone knows how to use zlib to decompress codecprivate/block without
knowing the uncompressed length? Or is stored somewhere perhaps?



From steve.lhomme at free.fr  Mon Nov  3 23:18:16 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Mon, 03 Nov 2003 23:18:16 +0100
Subject: [Matroska-devel] libmatroska - AddFrame lacks default lacing type
In-Reply-To: <3FA25EB5.7080708@free.fr>
References: <20031030114022.GQ13719@bunkus.org>	<3FA0FA7F.2040604@free.fr>	<20031030173914.GC13719@bunkus.org>	<3FA19C3B.3070109@free.fr>	<20031031085105.GF13719@bunkus.org>	<20031031124218.GI13719@bunkus.org>	<3FA25A09.3090706@free.fr>	<20031031125303.GJ13719@bunkus.org>
	<3FA25D8B.2010606@free.fr> <3FA25EB5.7080708@free.fr>
Message-ID: <3FA6D428.9050404@free.fr>

Steve Lhomme wrote:
>> BTW, not that I think of it, it *does* make sense to have 
> 
> 
> s/not/now/
> 
>> ReadFully=false for an integer. Because in EbmlMaster::Read() it would 
>> read the ID+length and leave the value behind. Which is nice if you 
>> really don't want to read values and just the data structure.
>>
>> But that also means in your case (reading a Cluster without the Block 
>> data only) using ReadFully=false would read nothing, just the 
>> structure. So IMO ReadFully should be moved from an integer to a 
>> bitfield. With values like :
>>
>> 0 Read no data (no integer content)
>> 1 Read all data
>> 2 Read partial data (ie integers OK, but not Block data)
>>
>> Only the handling of the '2' value needs to be added (in 
>> libebml+libmatroska), the rest is backward compatible.
> 
> 
> Should be :
> 0 Read partial data (ie integers OK, but not Block data)
> 1 Read all data
> 2 Read no data (no integer content)
> 
> As 0 and 1 are the current implementation.

This is now committed in libebml and libmatroska.
(I haven't updated the library versions)



From moritz at bunkus.org  Tue Nov  4 00:51:01 2003
From: moritz at bunkus.org (Moritz Bunkus)
Date: Tue, 4 Nov 2003 00:51:01 +0100
Subject: [Matroska-devel] Re: MPEG2 in MKV!
In-Reply-To: <029201c389e6$9af97930$0100a8c0@i2400p4>
References: <20031103162633.GH17861@bunkus.org>
	<029201c389e6$9af97930$0100a8c0@i2400p4>
Message-ID: <20031103235101.GI17861@bunkus.org>

Hi.

> Anyone knows how to use zlib to decompress codecprivate/block without
> knowing the uncompressed length? Or is stored somewhere perhaps?

The uncompressed length is not stored anywhere, same for the other
blocks. I've attached a sample file for zlib usage.

-- 
 ==> Ciao, Mosu (Moritz Bunkus)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: zlibtest.c
Type: text/x-csrc
Size: 2771 bytes
Desc: not available
URL: <http://lists.matroska.org/pipermail/matroska-devel/attachments/20031104/7b873c31/attachment.c>

From chris at matroska.org  Mon Nov 10 15:50:50 2003
From: chris at matroska.org (Christian HJ Wiesner)
Date: Mon, 10 Nov 2003 15:50:50 +0100
Subject: [Matroska-devel] Overhead comparison FLAC in MKA,
 created with jcsston's FLAC encoder filter
Message-ID: <3FAFA5CA.5050909@matroska.org>


Hi,

here a few overhead comparisons on a MKA file made with Jory's FLAC 
encoder filter and matroskamuxer filter on Graphedit :

Source file :                    682 MB

FLAC ( level 5 ) :           409 MB
OggFLAC ( level 5 ) :    413 MB
MKA Flac ( level ? ) :    438 MB

Any explanations why overhead is so much worse than for OggFLAC ? Do we 
use lacing in matroskamuxer on DirectShow ? Any news from Gabest about 
using the new lacing sheme in an updated version of matroska muxer filter ?

I still wonder if its a wise thing to treat FLAC as a normal ACM codec 
in conjunction with A_MS/ACM .

@jcsston, gabest : any chances of uniting efforts to define a new 
MEDIASUBTYPE for connecting FLAC encoder filter to matroskamuxer, so 
that a native codec ID was used and an efficient lacing sheme ?

Christian



From jcsston at toughguy.net  Mon Nov 10 17:21:17 2003
From: jcsston at toughguy.net (Jory)
Date: Mon, 10 Nov 2003 10:21:17 -0600
Subject: [Matroska-devel] Overhead comparison FLAC in MKA,
	created with jcsston's FLAC encoder filter
References: <3FAFA5CA.5050909@matroska.org>
Message-ID: <001801c3a7a6$b03970b0$0200a8c0@jcsston>


----- Original Message -----
From: "Christian HJ Wiesner" <chris at matroska.org>
To: "Discussion about the current and future development of Matroska"
<matroska-devel at lists.matroska.org>; <jcsston at matroska.org>;
<gabest at matroska.org>
Sent: Monday, November 10, 2003 8:50 AM
Subject: [Matroska-devel] Overhead comparison FLAC in MKA, created with
jcsston's FLAC encoder filter


>
> Hi,
>
> here a few overhead comparisons on a MKA file made with Jory's FLAC
> encoder filter and matroskamuxer filter on Graphedit :
>
> Source file :                    682 MB
>
> FLAC ( level 5 ) :           409 MB
> OggFLAC ( level 5 ) :    413 MB
> MKA Flac ( level ? ) :    438 MB
The DShow encoder currently defaults to a compression level of 5.

>
> Any explanations why overhead is so much worse than for OggFLAC ? Do we
> use lacing in matroskamuxer on DirectShow ? Any news from Gabest about
> using the new lacing sheme in an updated version of matroska muxer filter
?
>

If you remux the file with mkvmerge with lacing enabled you shold get much
lower overhead. The DShow filter wisely does not use any lacing. It could
also have a larger overhead because for some reason each frame has a
reference to it's self.

|+ Cluster
| + Cluster timecode: 0.000s
| + Block group
|  + Block (track number 1, 1 frame(s), timecode 0.000s)
|   + Frame with size 14
| + Block group
|  + Reference block: 0.000ms
|  + Block (track number 1, 1 frame(s), timecode 0.000s)
|   + Frame with size 14
| + Block group
|  + Reference block: 0.000ms
|  + Block (track number 1, 1 frame(s), timecode 0.000s)
|   + Frame with size 14

I think it maybe that the syncpoint flag on the sample in DShow is not being
set.

Later,
Jory




From chris at wiesneronline.net  Tue Nov 11 11:00:34 2003
From: chris at wiesneronline.net (Christian HJ Wiesner)
Date: Tue, 11 Nov 2003 11:00:34 +0100
Subject: [Matroska-devel] Re: email adress of David Bryant for wavpack
	4 integration into matroskatools ?
In-Reply-To: <3F78571D.7070202@matroska.org>
References: <01c385f3$ba879260$0100007f@default>
	<3F78571D.7070202@matroska.org>
Message-ID: <3FB0B342.1060202@wiesneronline.net>

Hi guys,

any news here we could forward to David Bryant, the Wavpack author, 
about how he would have to write his lib for easy integration into our 
tools ? I guess the recent work we have been doing with FLAC and libflac 
should have resulted in some usable experience here ? jccston just said 
on IRC :

jcsston <irc://127.0.0.1/jcsston,isnick> 	<ChrisHJW> why oh why cant 
these compression format devs not separate framing and codec <-- anytime 
you put something inside another thing you are going to get overhead. If 
you zip a zip the second zip will be larger.
jcsston <irc://127.0.0.1/jcsston,isnick> 	an ideal lib interface would 
work in a frame-by-frame basis
jcsston <irc://127.0.0.1/jcsston,isnick> 	don't require the use of 
callbacks. I had to design the FLAC encoder filter in a way so that if 
you drop some audio samples your audio will go out of sync. (blame libflac)



jcsston told me that we currently put FLAC into MKA including its own 
framing, because its more or less impossible to separate the two, the 
FLAC decoder will always expect the frames embedded in FLACs native 
framing ( not sure how this is handled in OggFLAC ? ), means that if we 
wanted to mux the raw FLAC frames into matroska, we either had to 
reconstruct the FLAC framing on demuxing, or rewrite all existing FLAC 
decoders so they can handle raw frames also :( ....

A summary comparison between Wavpack4 and FLAC

                                      Wavpack4                           
FLAC

CPU - encodining :            minimal                              medium
CPU - decoding :              small                                  minimal
Compression :                   good                                  good
5.1                                      yes                           
         yes
x-platform                           yes                                 
   yes
hardware support                  no                                    yes
lossless - lossy mode            yes                                    no

I recommend that, if David could give us a library where codec and 
framing are clearly separated, and as its using lower CPU for encoding 
that FLAC, this would make Wavpack4 the ideal lossless format for video 
capturing and video editing, means for integration into VdubMod and 
making a DirectShow encodee and ecoder filter.

are encoded lossless, but silent scenes are encodedA crazy feature that 
FLAC cant do is the possibility to switch from lossless to lossy mode 
and back from one block to the next. This could save enormous file size, 
if we can enable a mode where comples scenes during capturing using 
lossly mode. An intelligent encoder could even detect if the spare CPU 
power is enough to encode in lossly mode, during a capturing process, 
just a crazy idea of mine ;) ....

@ David Bryant ( pls. use 'reply all' if you answer to this email ) : 
Did you ever consider to look at matroska as your native framing anyhow 
? Please dont make the false assumption that doing so will result in a 
huge overhead in any case, because thats not true. As an example, we can 
store Vorbis more effectively in matroska than it is stored in Ogg, 
thanks to our very efficient lacing system called 'EBML lacing' . 
matroska has a variable header length, so for an audio track many things 
in the headers are simply non-existant, and that way Wavpack4 could 
enjoy a huge fan community meanwhile, also libmatroska/libebml are a 
fixed part of most Linux distro's now already, including GNOME / 
Gstreamer plugins. Making DirectShow filters for Wavpack would be a 
breeze then, as our existing source filters for matroska streams could 
be used fine. We have a powerful tagging system already, and apps to 
write/read them, there is a native replay gain field, fields to tell the 
decoder how many channels the file has, etc. . Just a thought of mine ;) 
.....

Christian

Christian HJ Wiesner wrote:

> David Bryant wrote:
>
>>> One thing that could give you a real advantage IMHO, was to alllow
>>> transition from lossless to lossy mode in one file. Dont know if 
>>> this is
>>> possible, but pls. think about it :-) !
>>
>> Actually, this will be easy in WavPack 4.0 because every block of 
>> compressed
>> audio is completely independent. It will also be possible to store
>> multichannel material with different compression modes for the various
>> streams.
>
> :O !!! You mean this is possible already ? Using lossless for complex 
> sound parts, and lossy for say silence and the like, similar to a 
> mixed mode ? Wow !!!
>
>>> I will ask my devs to email you and send a short description of what is
>>> technically necessary for good matroska implementation. And i know 
>>> Linux
>>> support will be on the very top of their list, amongst other things ;-)
>>
>> I am planning for the code to be easily portable to Linux and even to 
>> the
>> Mac. I may even try the linux port myself as soon as I get that Linux 
>> system
>> going that I have been planning for years...  ;-)
>> David
>
> Looking forward to be able to tell our devs that Wavpack 4 code can be 
> used to start adding it to our muxing tools David :) ! About the 
> requirements of your libs for easy implementation, i hope at least one 
> of the lazy matroska devs now takes the ball and writes something 
> sensible back to you :) ....
>
> Christian 





From moritz at bunkus.org  Fri Nov 14 22:47:40 2003
From: moritz at bunkus.org (Moritz Bunkus)
Date: Fri, 14 Nov 2003 22:47:40 +0100
Subject: [Matroska-devel] broken libebml/libmatroska
Message-ID: <20031114214740.GG2058@bunkus.org>

Heya,

Steve your new scope code has seriously broken libebml/libmatroska. I'm
VERY sure it's your changes that have done this as a) the latest
releases do work and b) I've only committed a two line endian handling fix which,
applied to libebml 0.6.2, still works.

For the current CVS versions writing works perfectly but reading blocks
does not. I get output like this from mkvinfo (which uses Read() on a
complete cluster):

| + Block group
|  + Block (track number 22648, 0 frame(s), timecode 581895569.560s)
| + Block group
|  + Block (track number 97, 0 frame(s), timecode 18446744073.710s)
|  + Reference block: -42.000ms
| + Block group
|  + Block (track number 0, 0 frame(s), timecode 18446744073.710s)
|  + Reference block: -42.000ms
| + Block group
|  + Block (track number 0, 0 frame(s), timecode 18446744073.710s)
|  + Reference block: -41.000ms
| + Block group
|  + Block (track number 0, 0 frame(s), timecode 18446744073.710s)
|  + Reference block: -42.000ms
| + Block group
|  + Block (track number 22648, 0 frame(s), timecode 581895775.718s)
| + Block group
|  + Block (track number 97, 0 frame(s), timecode 18446744073.710s)

etc.pp.

Sorry, I'm too tired to hunt bugs now. Please, PLEASE do something about
this...

Thanks ;)

-- 
 ==> Ciao, Mosu (Moritz Bunkus)


From steve.lhomme at free.fr  Sat Nov 15 18:45:30 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Sat, 15 Nov 2003 18:45:30 +0100
Subject: [Matroska-devel] broken libebml/libmatroska
In-Reply-To: <20031114214740.GG2058@bunkus.org>
References: <20031114214740.GG2058@bunkus.org>
Message-ID: <3FB6663A.6060806@free.fr>

Moritz Bunkus wrote:

> Heya,
> 
> Steve your new scope code has seriously broken libebml/libmatroska. I'm
> VERY sure it's your changes that have done this as a) the latest
> releases do work and b) I've only committed a two line endian handling fix which,
> applied to libebml 0.6.2, still works.
> 
> For the current CVS versions writing works perfectly but reading blocks
> does not. I get output like this from mkvinfo (which uses Read() on a
> complete cluster):
> 
> | + Block group
> |  + Block (track number 22648, 0 frame(s), timecode 581895569.560s)
> | + Block group
> |  + Block (track number 97, 0 frame(s), timecode 18446744073.710s)
> |  + Reference block: -42.000ms
> | + Block group
> |  + Block (track number 0, 0 frame(s), timecode 18446744073.710s)
> |  + Reference block: -42.000ms
> | + Block group
> |  + Block (track number 0, 0 frame(s), timecode 18446744073.710s)
> |  + Reference block: -41.000ms
> | + Block group
> |  + Block (track number 0, 0 frame(s), timecode 18446744073.710s)
> |  + Reference block: -42.000ms
> | + Block group
> |  + Block (track number 22648, 0 frame(s), timecode 581895775.718s)
> | + Block group
> |  + Block (track number 97, 0 frame(s), timecode 18446744073.710s)
> 
> etc.pp.
> 
> Sorry, I'm too tired to hunt bugs now. Please, PLEASE do something about
> this...
> 
> Thanks ;)

OK, I'll hunt that tomorrow.
Is it hard to compile mkvinfo on Windows ? Where do I get it (I mean, is 
it only available through SVN) ?



From moritz at bunkus.org  Sat Nov 15 22:59:49 2003
From: moritz at bunkus.org (Moritz Bunkus)
Date: Sat, 15 Nov 2003 22:59:49 +0100
Subject: [Matroska-devel] broken libebml/libmatroska
In-Reply-To: <3FB6663A.6060806@free.fr>
References: <20031114214740.GG2058@bunkus.org> <3FB6663A.6060806@free.fr>
Message-ID: <20031115215949.GQ2058@bunkus.org>

Hi,

> OK, I'll hunt that tomorrow.
> Is it hard to compile mkvinfo on Windows ? Where do I get it (I mean, is 
> it only available through SVN) ?

Yes, it's pretty hard because you need a couple of libs (Vorbis, Ogg,
zlib), and all that depends on mingw with a cygwin development
environment.

So it's probably easier to produce any Matroska file and then write you
own test case. Just call Read(...) on a KaxCluster and iterate through
its children. The timecodes that you get should be broken, the number of
frames as well. Extending test8.cpp for this should be easy enough.

-- 
 ==> Ciao, Mosu (Moritz Bunkus)


From steve.lhomme at free.fr  Sun Nov 16 10:37:38 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Sun, 16 Nov 2003 10:37:38 +0100
Subject: [Matroska-devel] broken libebml/libmatroska
In-Reply-To: <20031115215949.GQ2058@bunkus.org>
References: <20031114214740.GG2058@bunkus.org> <3FB6663A.6060806@free.fr>
	<20031115215949.GQ2058@bunkus.org>
Message-ID: <3FB74562.4010309@free.fr>

Moritz Bunkus wrote:

> Hi,
> 
> 
>>OK, I'll hunt that tomorrow.
>>Is it hard to compile mkvinfo on Windows ? Where do I get it (I mean, is 
>>it only available through SVN) ?
> 
> 
> Yes, it's pretty hard because you need a couple of libs (Vorbis, Ogg,
> zlib), and all that depends on mingw with a cygwin development
> environment.
> 
> So it's probably easier to produce any Matroska file and then write you
> own test case. Just call Read(...) on a KaxCluster and iterate through
> its children. The timecodes that you get should be broken, the number of
> frames as well. Extending test8.cpp for this should be easy enough.

This is now fixed in CVS. It was a problem with the KaxBlock reading. 
The scope was not used correctly.



From chris at matroska.org  Sun Nov 16 11:19:18 2003
From: chris at matroska.org (Christian HJ Wiesner)
Date: Sun, 16 Nov 2003 11:19:18 +0100
Subject: [Matroska-devel] Protocol of my 2+ hrs telephone conversation with
	Frank Klemm
Message-ID: <3FB74F26.7060700@matroska.org>


I want to give a short summary of this long telephone conversation, here 
the topics we discussed :


1. Subband coding vs. Transformation coding
2. Future of MPC
3. MPC in matroska
4. DVD players and their problems


1. I was very surprised to understand that Frank doesnt see any benefit 
in musepack's subband coding, compared to modern transformation codecs 
like AAC or even Vorbis. He told me that musepack's results in the 128 
kbps listening test are a slap in the face of the other codecs, as 
normally musepack should have performed worst at this bitrate. He is of 
the opinion that musepack's only advantage is the psy model he made, or 
the lack of there-of in the other codecs.
Not even in the decoding speed does he see a big advantage in subband 
coding, he is convinced all of the other decoders could be optimized a 
lot, especially with improvements in the lookup of the huffman tables, 
with a proper indexing system as he has done with musepack once, gaining 
a speed advantage of factor 9 compared to buschel's code.
He mentioned more than one time that MP3, from his point of view, is not 
at all well specified and implemented and can even lead to drop-outs 
during playback under certain conditions. He sees AC3 as a very good 
standard for his needs, because of well existing hardware decoders in 
external receivers, a proper and well done specification and 
implementation, and because with DVD burners beoming more and more 
popular, low bitrates for audio compression will be only interesting for 
streaming in future, and he doesnt see the big market for streaming at 
all. He told me he is maybe interested in making a proper AC3 encoder, 
using his own psy model, that in principal can be transferred from one 
encoder to another.


2. It seems that Frank is more and more into video, especially DVD 
video, and my personal opinion is that musepack is not in the center of 
his interest anymore. His opinion on 1. surprised me a lot, i didnt 
understand why he had invested so much time into musepack when subband 
coding has no advantages compared to other coding technologies, but as 
so many other technicians i guess it was more like a prrof of concept 
for him, after the LAME people had more or less pushed him out of the 
team because of the many radical changes he had in mind.
After learning that, i honestly question the future of musepack in its 
current form. It was maybe a better idea to make a good, free and 
opensource AAC encoder, or to fork from Vorbis and making a new 
compression format, if Frank ever finds the motivation again to invest 
serious work into making a new audio codec. The other alternative is, 
and that is what Frank obviously had in mind for musepack also, make a 
clear cut with subband coding for the future and make SV8 a 
transformation codec also. Frank told me that in his opinion the AAC 
standard has a couple of quirks in it, and we could maybe make a new 
compression format, still call it musepack and MPC, overcoming those 
problems, but on the other hand staying decoder compatible with AAC ??

It appears to me that Frank alone can not invest the time necessary to 
realize MPC SV8. On the other hand he could very well make the specs, 
and invest time into his main area of excellence, the psy model. He 
mentioned to me that he had invested too much time already into 
explaining what has to be done to other people, but without any real 
feedback from them after that. I offered to him to try to use the 
existing GForge/Alexandria facilities on the corecodec.org server for 
that,  allowing you to assign tasks, explain them one time,  and then 
let me search for a developer who wanted to care about that. I am not 
sure if i could convince him that this is a sensible thing to do, but he 
promised to make a last attempt here and compile a list of things where 
he could use help from outside. I will take this list and define taks on 
corecodec.org for each of them. Hopefully that way we can organize 
things a bit better in future.


3. Frank has doubts if our developers, mainly Toff, have really found a 
way to read a complete block of data from a SV7 file for muxing into 
matroska. He says the current bitstream is weired, there are sometimes 
bits from one block attached to the next or to the preceding block, so 
without calling the decoder on the blocks there is no way of finding 
out. Even then, proper seeking might be impossible because in worst case 
the decoding of a block can depend on up to 32 blocks before this block.
He promised to look into a repacking app, reading SV7, unpack the data 
and repack them into SV8 bitstream, forming a kind of SV 7.5 version if 
you want, as i convinced him there is no use of allowing subband coding 
in SV8 at all, if he feels it doesnt have any advantages to 
transformation encoding. With this app we could pack SV7 files into 
matroska fine, just a new decoder is necessary that can handle the new 
byte order as specified for SV8 ( big endian ).


4. Frank has a lot of ideas about improving currently existing DVD 
playback chains, like by implementing the video decoder chip into the 
TV, transferring the compressed video data from the DVD player to the TV 
via firewire IEE 1394 . He also believes it should be possible to delay 
the picture by several milliseconds, to allow the use of digitally phase 
corrected speakers, introducing a delay by deafult.


Conclusion :

MPC is not dead, not at all. Even in its current form, its a great 
encoder for movie soundtracks if highest quality for Stereo tracks is 
the aim, and Frank promised to look into a way to be able to get clear 
block boundaries for SV7 streams. The huge fangroup on HA.org, all music 
lovers compressing their music albums with it, are a good prrof for 
that. However, it seems that MPC only has a future in a complete new 
form, and the man who could bring the format there doesnt have the time 
to make this alone. IMHO its time to bring the project to corecodec.org 
now and use the existing opensource facilities more evident. The way 
things did work out until today, one man doing all the core things and 
the other devs implementing these core elements into several apps, will 
not work out for the 'new' MPC SV8 anymore.

Its time for us to ask ourselves if we want musepack to evolve further, 
or if we are happy with what it is today. Whilst it is usable for music 
compression already, its not for use with video. If we want musepack to 
progress, we all have to work together to improve it. Looking forward to 
hear your comments.

Christian
MPC and matroska project admin



From steve.lhomme at free.fr  Sun Nov 16 12:18:01 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Sun, 16 Nov 2003 12:18:01 +0100
Subject: [Matroska-devel] Protocol of my 2+ hrs telephone conversation
	with	Frank Klemm
In-Reply-To: <3FB74F26.7060700@matroska.org>
References: <3FB74F26.7060700@matroska.org>
Message-ID: <3FB75CE9.6010404@free.fr>

Christian HJ Wiesner wrote:

> He mentioned more than one time that MP3, from his point of view, is not 
> at all well specified and implemented and can even lead to drop-outs 
> during playback under certain conditions. He sees AC3 as a very good 
> standard for his needs, because of well existing hardware decoders in 
> external receivers, a proper and well done specification and 
> implementation, and because with DVD burners beoming more and more 
> popular, low bitrates for audio compression will be only interesting for 
> streaming in future, and he doesnt see the big market for streaming at 
> all. He told me he is maybe interested in making a proper AC3 encoder, 
> using his own psy model, that in principal can be transferred from one 
> encoder to another.

Mmm, low bitrates are good for exchanging or publishing music too (and 
still forcing people to buy the music). I use it a lot ! Not to mention 
that you gain some extra bandwidth when muxed with video (which is less 
used for legal stuff). Anyway, the net distribution of content with 
sound/music has a great future. And that's where compression matters a lot.

> After learning that, i honestly question the future of musepack in its 
> current form. It was maybe a better idea to make a good, free and 

Mmm, you'd better have good proof of what you say. If that's the case, 
that means we can drop the "plans" for SV8. Anyway, I personally also 
give AAC a lot of credit, even with the license restrictions. (after all 
you have encoders/players for free on Windows and OSX)

> opensource AAC encoder, or to fork from Vorbis and making a new 
> compression format, if Frank ever finds the motivation again to invest 
> serious work into making a new audio codec. The other alternative is, 
> and that is what Frank obviously had in mind for musepack also, make a 
> clear cut with subband coding for the future and make SV8 a 
> transformation codec also. Frank told me that in his opinion the AAC 
> standard has a couple of quirks in it, and we could maybe make a new 
> compression format, still call it musepack and MPC, overcoming those 
> problems, but on the other hand staying decoder compatible with AAC ??

I suggest not using MPC for the name, as it would confuse many people.

> 3. Frank has doubts if our developers, mainly Toff, have really found a 
> way to read a complete block of data from a SV7 file for muxing into 
> matroska. He says the current bitstream is weired, there are sometimes 
> bits from one block attached to the next or to the preceding block, so 
> without calling the decoder on the blocks there is no way of finding 
> out. Even then, proper seeking might be impossible because in worst case 
> the decoding of a block can depend on up to 32 blocks before this block.
> He promised to look into a repacking app, reading SV7, unpack the data 
> and repack them into SV8 bitstream, forming a kind of SV 7.5 version if 
> you want, as i convinced him there is no use of allowing subband coding 
> in SV8 at all, if he feels it doesnt have any advantages to 
> transformation encoding. With this app we could pack SV7 files into 
> matroska fine, just a new decoder is necessary that can handle the new 
> byte order as specified for SV8 ( big endian ).

Sure ! That's all we need from MPC SV7 !

> Its time for us to ask ourselves if we want musepack to evolve further, 
> or if we are happy with what it is today. Whilst it is usable for music 
> compression already, its not for use with video. If we want musepack to 
> progress, we all have to work together to improve it. Looking forward to 
> hear your comments.

Let me explain why I use compressed audio :

1) publish my mixes on the net (mp3PRO for any dumb user to be able to 
read it)
2) DJing with TraktorDJ. It only supports MP3 but I want to make an 
equivalent software that could read much more formats
3) Storing tagged music on my machines instead of having to switch of 
CD/vynil all the time
4) Storing TV captures (currently using Vorbis in Matroska)

I think MPC could go in 2/3/4 but I use mostly MP3 because I know it 
will work in all other cases. So as long as MPC (or Vorbis) doesn't work 
in 2 I will use MP3 for almost everything... That's why I want to make a 
good DJing software ASAP. Then I'll see if MPC is worth... If there is 
SV7 in Matroska, it should cover all my needs !



From chris at matroska.org  Sun Nov 16 23:30:18 2003
From: chris at matroska.org (Christian HJ Wiesner)
Date: Sun, 16 Nov 2003 23:30:18 +0100
Subject: [Matroska-devel] SV7 to SV 8 conversion for matroska integration :
	call for opinions
Message-ID: <3FB7FA7A.90102@matroska.org>



Hi,

please use the 'reply all' button of your mail client when replying, so 
all lists get copied.

Frank convinced us that using SV7 in matroska is maybe not a good idea. 
Therefore the matroska team was discussing a couple of options today 
about MPC integration into matroska :

1. Wait for Frank to write a SV7 to SV8 'repacker' tool. This would 
slightly increa'se overhead, but this way old existing SV7 files could 
be packed into matroska, and all existing encoders could be used for 
movie soundtrack encoding

2. Make an encoder filter for DirectShow or a little CLI app with 
libmatroska based on Frank's 'alpha' SV8 encoder, which seems to be 
quite usable and according to Frank was tuned to overcome some reported 
sound limitations in the existing SV7 encoder. We could tag the current, 
'alpha SV8 bitstream' as SV 7.2 , SV 7.5 or even SV8, and write the 
blocks directly into matroska files, stripping even the block size from 
the SV8 alpha bitstream to become as independant as possible from future 
bitstream changes. The chances are good that these files would be 100% 
SV8 compatible. If not, we could tag them differently, or convince Frank 
to make SV9 instead of SV8 ;-) ....

3. matroska has a very powerful and complex lacing and frame handling 
system, allowing us to even mux SV7 streams into matroska files, without 
breaking the specs. For this case we could put 32 MPC frames into a 
single matroska block and use either the enhanced EBML lacing or the 
so-called time-slices, allowing us to group a complete 'self-decodable' 
group of blocks into one matroska block. That way we even dont care if 
single bits of one frame are attached to other frames, as they form an 
entity in the matroska file.

I would like to hear your opinions on that. Everybody is clearly invited 
to tell us his personal opinion about this, even if its not technically 
founded.

Best regards

Christian



From numlock at freesurf.ch  Sun Nov 16 23:47:24 2003
From: numlock at freesurf.ch (=?ISO-8859-1?Q?Jo=EBl?= Bourquard)
Date: Sun, 16 Nov 2003 23:47:24 +0100
Subject: [Matroska-devel] Re: [mpc-general] Protocol of my 2+ hrs telephone
	conversation with Frank Klemm
In-Reply-To: <3FB74F26.7060700@matroska.org>
References: <3FB74F26.7060700@matroska.org>
Message-ID: <1069022843.17677.16.camel@localhost.localdomain>

Thank you Christian for making this "meeting minutes".

Here's some personal thoughts:

I trust Frank when he says Musepack's strength is in the psymodel, but
regardless of quality concerns, I still think it would be preferable to
include the current subband format in SV8.

Some reasons:
- Speed (ok, Huffman codes take some effort to decode, but MDCT is by
far the most expensive process). Optimizations to Huffman decoding can
be done, while MDCT is kind of irreductible.
- Flexibility (just imagine a single bitstream with an "efficiency" MDCT
and a "speed" subband mode..  both produced using the same psymodel
!)..  so all devices can be targeted.
- Compatibility (the cleanest way to re-use our current SV7 files, will
be to make them SV8-convertible !)

Since the framing structure is cleaner in SV8, complexity should not be
a problem (the only additional work is in a lossless SV7->SV8
converter). I guess the inter-frame limitations can be sorted out during
SV7->SV8 conversion.

Sincerely I don't see the point in SV7.5. Creating yet another
fileformat isn't going to help, I think. Plus it would slow down the
development of stream processing tools, wouldn't it ?

So why not create a simple, straightforward, flexible standard which
handles both subband (for compatibility and speed) and future MDCT data
?

I don't know much about AC3, but it looks like a very interesting idea.
Well, if the psymodel is good and open, almost anything can be done with
it !

I hope my statements are not too messy (I'm a bit tired..)

Cheers !
Jo?l


On Sun, 2003-11-16 at 11:19, Christian HJ Wiesner wrote:
> I want to give a short summary of this long telephone conversation, here 
> the topics we discussed :
> 
> 
> 1. Subband coding vs. Transformation coding
> 2. Future of MPC
> 3. MPC in matroska
> 4. DVD players and their problems
> 
> 
> 1. I was very surprised to understand that Frank doesnt see any benefit 
> in musepack's subband coding, compared to modern transformation codecs 
> like AAC or even Vorbis. He told me that musepack's results in the 128 
> kbps listening test are a slap in the face of the other codecs, as 
> normally musepack should have performed worst at this bitrate. He is of 
> the opinion that musepack's only advantage is the psy model he made, or 
> the lack of there-of in the other codecs.
> Not even in the decoding speed does he see a big advantage in subband 
> coding, he is convinced all of the other decoders could be optimized a 
> lot, especially with improvements in the lookup of the huffman tables, 
> with a proper indexing system as he has done with musepack once, gaining 
> a speed advantage of factor 9 compared to buschel's code.
> He mentioned more than one time that MP3, from his point of view, is not 
> at all well specified and implemented and can even lead to drop-outs 
> during playback under certain conditions. He sees AC3 as a very good 
> standard for his needs, because of well existing hardware decoders in 
> external receivers, a proper and well done specification and 
> implementation, and because with DVD burners beoming more and more 
> popular, low bitrates for audio compression will be only interesting for 
> streaming in future, and he doesnt see the big market for streaming at 
> all. He told me he is maybe interested in making a proper AC3 encoder, 
> using his own psy model, that in principal can be transferred from one 
> encoder to another.
> 
> 
> 2. It seems that Frank is more and more into video, especially DVD 
> video, and my personal opinion is that musepack is not in the center of 
> his interest anymore. His opinion on 1. surprised me a lot, i didnt 
> understand why he had invested so much time into musepack when subband 
> coding has no advantages compared to other coding technologies, but as 
> so many other technicians i guess it was more like a prrof of concept 
> for him, after the LAME people had more or less pushed him out of the 
> team because of the many radical changes he had in mind.
> After learning that, i honestly question the future of musepack in its 
> current form. It was maybe a better idea to make a good, free and 
> opensource AAC encoder, or to fork from Vorbis and making a new 
> compression format, if Frank ever finds the motivation again to invest 
> serious work into making a new audio codec. The other alternative is, 
> and that is what Frank obviously had in mind for musepack also, make a 
> clear cut with subband coding for the future and make SV8 a 
> transformation codec also. Frank told me that in his opinion the AAC 
> standard has a couple of quirks in it, and we could maybe make a new 
> compression format, still call it musepack and MPC, overcoming those 
> problems, but on the other hand staying decoder compatible with AAC ??
> 
> It appears to me that Frank alone can not invest the time necessary to 
> realize MPC SV8. On the other hand he could very well make the specs, 
> and invest time into his main area of excellence, the psy model. He 
> mentioned to me that he had invested too much time already into 
> explaining what has to be done to other people, but without any real 
> feedback from them after that. I offered to him to try to use the 
> existing GForge/Alexandria facilities on the corecodec.org server for 
> that,  allowing you to assign tasks, explain them one time,  and then 
> let me search for a developer who wanted to care about that. I am not 
> sure if i could convince him that this is a sensible thing to do, but he 
> promised to make a last attempt here and compile a list of things where 
> he could use help from outside. I will take this list and define taks on 
> corecodec.org for each of them. Hopefully that way we can organize 
> things a bit better in future.
> 
> 
> 3. Frank has doubts if our developers, mainly Toff, have really found a 
> way to read a complete block of data from a SV7 file for muxing into 
> matroska. He says the current bitstream is weired, there are sometimes 
> bits from one block attached to the next or to the preceding block, so 
> without calling the decoder on the blocks there is no way of finding 
> out. Even then, proper seeking might be impossible because in worst case 
> the decoding of a block can depend on up to 32 blocks before this block.
> He promised to look into a repacking app, reading SV7, unpack the data 
> and repack them into SV8 bitstream, forming a kind of SV 7.5 version if 
> you want, as i convinced him there is no use of allowing subband coding 
> in SV8 at all, if he feels it doesnt have any advantages to 
> transformation encoding. With this app we could pack SV7 files into 
> matroska fine, just a new decoder is necessary that can handle the new 
> byte order as specified for SV8 ( big endian ).
> 
> 
> 4. Frank has a lot of ideas about improving currently existing DVD 
> playback chains, like by implementing the video decoder chip into the 
> TV, transferring the compressed video data from the DVD player to the TV 
> via firewire IEE 1394 . He also believes it should be possible to delay 
> the picture by several milliseconds, to allow the use of digitally phase 
> corrected speakers, introducing a delay by deafult.
> 
> 
> Conclusion :
> 
> MPC is not dead, not at all. Even in its current form, its a great 
> encoder for movie soundtracks if highest quality for Stereo tracks is 
> the aim, and Frank promised to look into a way to be able to get clear 
> block boundaries for SV7 streams. The huge fangroup on HA.org, all music 
> lovers compressing their music albums with it, are a good prrof for 
> that. However, it seems that MPC only has a future in a complete new 
> form, and the man who could bring the format there doesnt have the time 
> to make this alone. IMHO its time to bring the project to corecodec.org 
> now and use the existing opensource facilities more evident. The way 
> things did work out until today, one man doing all the core things and 
> the other devs implementing these core elements into several apps, will 
> not work out for the 'new' MPC SV8 anymore.
> 
> Its time for us to ask ourselves if we want musepack to evolve further, 
> or if we are happy with what it is today. Whilst it is usable for music 
> compression already, its not for use with video. If we want musepack to 
> progress, we all have to work together to improve it. Looking forward to 
> hear your comments.
> 
> Christian
> MPC and matroska project admin
> 
> http://mpc.corecodec.org
> 



From numlock at freesurf.ch  Mon Nov 17 00:02:21 2003
From: numlock at freesurf.ch (=?ISO-8859-1?Q?Jo=EBl?= Bourquard)
Date: Mon, 17 Nov 2003 00:02:21 +0100
Subject: [Matroska-devel] Re: [mpc-devel] SV7 to SV 8 conversion for
	matroska integration : call for opinions
In-Reply-To: <3FB7FA7A.90102@matroska.org>
References: <3FB7FA7A.90102@matroska.org>
Message-ID: <1069023740.18928.9.camel@localhost.localdomain>

On Sun, 2003-11-16 at 23:30, Christian HJ Wiesner wrote:
> Hi,
> 
> please use the 'reply all' button of your mail client when replying, so 
> all lists get copied.
> 
> Frank convinced us that using SV7 in matroska is maybe not a good idea. 
> Therefore the matroska team was discussing a couple of options today 
> about MPC integration into matroska :

> 2. Make an encoder filter for DirectShow or a little CLI app with 
> libmatroska based on Frank's 'alpha' SV8 encoder, which seems to be 
> quite usable and according to Frank was tuned to overcome some reported 
> sound limitations in the existing SV7 encoder. We could tag the current, 
> 'alpha SV8 bitstream' as SV 7.2 , SV 7.5 or even SV8, and write the 
> blocks directly into matroska files, stripping even the block size from 
> the SV8 alpha bitstream to become as independant as possible from future 
> bitstream changes. The chances are good that these files would be 100% 
> SV8 compatible. If not, we could tag them differently, or convince Frank 
> to make SV9 instead of SV8 ;-) ....

Ah, I didn't know the pre-SV8 streams were *that* close to a final
stage. That's good news !

However, please consider the following:
- do these pre-SV8 streams support multichannel audio ?
- can SV7 streams easily be ported to pre-SV8 ?

Then, if pre-SV8 supports the above two points:
- why not extending/generalizing it to also support MDCT-domain audio ?
Hopefully this would only require a few additional bits ;-)

Regards
Jo?l



From moritz at bunkus.org  Mon Nov 17 00:03:33 2003
From: moritz at bunkus.org (Moritz Bunkus)
Date: Mon, 17 Nov 2003 00:03:33 +0100
Subject: [Matroska-devel] FLAC in Matroska
Message-ID: <20031116230333.GA2058@bunkus.org>

Hi,

I've finished my FLAC-in-Matroska support and updated the Codec specs
page. Gabest and Toff, could you please update your filter accordingly?
Thanks.

The format is pretty straight forward:
- All header packets (INCLUDING the packet containing the word "fLaC")
are put into CodecPrivate. Unlike Vorbis no lacing structure is used.
- Each FLAC frame is put into one Matroska block.
- Data is being sent to the codec in that order as well without any
modification neccessary (first hand over the CodecPrivate data, then the
following block data).
- CodecId is A_FLAC.

We've chosen to INCLUDE the "fLaC" as it is an integral part of the FLAC
bitstream ( = the decoder needs this packet to be present and won't work
otherwise). Also it's only 4 bytes once in CodecPrivate.

jcsston: I noticed two things about the file created with your encoding
filter that are strange:
1) Each block carries a reference block pointing to itself (timestamp of
0s). This is clearly a bug and should be removed; my guess is that it's
easy to do (probably a problem with 'key frames'?).
2) The timecodes look strange - several packets get the same
timecode. The first eight packets or so have 0.000s, the next eight
packets 0.250s, the following eight 0.500s and so on. Is this something
that can be improved?

If 2) can be changed then I don't see the need to use the A_MS/ACM
compatibility mode - you should them aim for A_FLAC. But I don't know
anything about these DShow matters ( = who has to change what...).

Happy end of the weekend.

-- 
 ==> Ciao, Mosu (Moritz Bunkus)


From numlock at freesurf.ch  Mon Nov 17 00:05:58 2003
From: numlock at freesurf.ch (=?ISO-8859-1?Q?Jo=EBl?= Bourquard)
Date: Mon, 17 Nov 2003 00:05:58 +0100
Subject: [Matroska-devel] Re: [mpc-devel] Re: SV7 to SV 8 conversion for
	matroska integration : call for opinions
In-Reply-To: <1069023740.18928.9.camel@localhost.localdomain>
References: <3FB7FA7A.90102@matroska.org>
	<1069023740.18928.9.camel@localhost.localdomain>
Message-ID: <1069023958.19887.1.camel@localhost.localdomain>

On Mon, 2003-11-17 at 00:02, Jo?l Bourquard wrote:
> Then, if pre-SV8 supports the above two points:
> - why not extending/generalizing it to also support MDCT-domain audio ?
> Hopefully this would only require a few additional bits ;-)
                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
                |
                |
                hoping to specify it the EMBL way...


> Regards
> Jo?l
> 
> http://mpc.corecodec.org
> 



From jcsston at wiesneronline.net  Mon Nov 17 02:16:26 2003
From: jcsston at wiesneronline.net (Jory)
Date: Sun, 16 Nov 2003 19:16:26 -0600
Subject: [Matroska-devel] FLAC in Matroska
References: <20031116230333.GA2058@bunkus.org>
Message-ID: <001e01c3aca8$6f7fde40$0200a8c0@jcsston>


----- Original Message ----- 
From: "Moritz Bunkus" <moritz at bunkus.org>
To: "Matroska devel" <matroska-devel at lists.matroska.org>
Sent: Sunday, November 16, 2003 5:03 PM
Subject: [Matroska-devel] FLAC in Matroska

> jcsston: I noticed two things about the file created with your encoding
> filter that are strange:
> 1) Each block carries a reference block pointing to itself (timestamp of
> 0s). This is clearly a bug and should be removed; my guess is that it's
> easy to do (probably a problem with 'key frames'?).
> 2) The timecodes look strange - several packets get the same
> timecode. The first eight packets or so have 0.000s, the next eight
> packets 0.250s, the following eight 0.500s and so on. Is this something
> that can be improved?
> 
> If 2) can be changed then I don't see the need to use the A_MS/ACM
> compatibility mode - you should them aim for A_FLAC. But I don't know
> anything about these DShow matters ( = who has to change what...).

1) Fixed. A flag wasn't being properly set.
2) I will look into that. I may be splitting the frames into pieces.

Jory



From walken at zoy.org  Mon Nov 17 07:42:10 2003
From: walken at zoy.org (Michel Lespinasse)
Date: Sun, 16 Nov 2003 22:42:10 -0800
Subject: [Matroska-devel] Re: [mpc-devel] Protocol of my 2+ hrs telephone
	conversation with Frank Klemm
In-Reply-To: <3FB74F26.7060700@matroska.org>
References: <3FB74F26.7060700@matroska.org>
Message-ID: <20031117064210.GA24513@zoy.org>

As it's my first post here, I thought I should introduce myself. I'm
the main developper on a few projects, most notably liba52 (AC-3
decoding library) and libmpeg2 (mpeg2 decoding). I've not used mpc
much to date, but I did look at the SV8 stream format description and
found it quite clean. I also implemented some mpeg audio layer 1-2
decoder in the past, but I never touched layer 3 (because I think the
spec is so ugly). Just letting people know so they see where I'm
coming from.

On Sun, Nov 16, 2003 at 11:19:18AM +0100, Christian HJ Wiesner wrote:
> 1. Subband coding vs. Transformation coding
> 2. Future of MPC
> 3. MPC in matroska
> 4. DVD players and their problems
>
> 1. I was very surprised to understand that Frank doesnt see any
> benefit in musepack's subband coding, compared to modern
> transformation codecs like AAC or even Vorbis. He told me that
> musepack's results in the 128 kbps listening test are a slap in the
> face of the other codecs, as normally musepack should have performed
> worst at this bitrate. He is of the opinion that musepack's only
> advantage is the psy model he made, or the lack of there-of in the
> other codecs.
>
> Not even in the decoding speed does he see a big advantage in subband 
> coding, he is convinced all of the other decoders could be optimized a 
> lot, especially with improvements in the lookup of the huffman tables, 
> with a proper indexing system as he has done with musepack once, gaining 
> a speed advantage of factor 9 compared to buschel's code.
> He mentioned more than one time that MP3, from his point of view, is not 
> at all well specified and implemented and can even lead to drop-outs 
> during playback under certain conditions. He sees AC3 as a very good 
> standard for his needs, because of well existing hardware decoders in 
> external receivers, a proper and well done specification and 
> implementation, and because with DVD burners beoming more and more 
> popular, low bitrates for audio compression will be only interesting for 
> streaming in future, and he doesnt see the big market for streaming at 
> all. He told me he is maybe interested in making a proper AC3 encoder, 
> using his own psy model, that in principal can be transferred from one 
> encoder to another.

I have to say I was quite surprised to see mpc, using subband
transforms so similar to mpeg audio layer 2, can perform so well. MPC
stream format has a lot of improvements over mpeg audio layer 2
though, with a bunch of different huffman tables you can select from,
some including various amouts of shaping as well. So I was wondering
how much of the improvement is due to the stream format enhancements,
and how much is due to the psy model.

I think the AC3 format has a lot of potential too, but currently the
free encoders for it kinda suck. One of the interesting features of
AC3 is that the decoder performs a bit allocation using a default
standardized psy model - if the encoder has a better psy model, it can
transmit deltas to apply to that bit allocation, but the idea is that
in the end it should be cheaper to transmit these deltas than to
transmit a whole bit allocation information. However, all free
encoders are crappy in the respect that they dont even have their own
psy model - they just use whatever is the result of the default psy
model in the AC3 decoder.

Anyway. I believe a mdct based format such as AC3 would have a lot of
potential if combined with a smart encoder using a good psy
model. Regarding what frank told you, I'd be curious if he was
considering a straight AC3 format encoder, or doing an AC3-derived
format with stream format improvements similar to what he's done in
mpc (i.e. the various shaped tables etc)

> It appears to me that Frank alone can not invest the time necessary to 
> realize MPC SV8. On the other hand he could very well make the specs, 
> and invest time into his main area of excellence, the psy model. He 
> mentioned to me that he had invested too much time already into 
> explaining what has to be done to other people, but without any real 
> feedback from them after that.

Huh, I *really* know that feeling.

> Its time for us to ask ourselves if we want musepack to evolve
> further, or if we are happy with what it is today. Whilst it is
> usable for music compression already, its not for use with video. If
> we want musepack to progress, we all have to work together to
> improve it. Looking forward to hear your comments.

OK so this is maybe a naive question from an outsider, but I'll ask it
anyway.

What's wrong with mpc for use with video ?

>From my point of view, the main thing holding mpc back nowadays is the
lack of a free encoder source code.

Cheers,

-- 
Michel "Walken" Lespinasse
"In this time of war against Osama bin Laden and the oppressive
Taliban regime, we are thankful that OUR leader isn't the spoiled son
of a powerful politician from a wealthy oil family who is supported by
religious fundamentalists, operates through clandestine organizations,
has no respect for the democratic electoral process, bombs innocents,
and uses war to deny people their civil liberties." --The Boondocks


From walken at zoy.org  Mon Nov 17 07:54:57 2003
From: walken at zoy.org (Michel Lespinasse)
Date: Sun, 16 Nov 2003 22:54:57 -0800
Subject: [Matroska-devel] Re: [mpc-devel] Re: [mpc-general] Protocol of my
	2+ hrs telephone conversation with Frank Klemm
In-Reply-To: <1069022843.17677.16.camel@localhost.localdomain>
References: <3FB74F26.7060700@matroska.org>
	<1069022843.17677.16.camel@localhost.localdomain>
Message-ID: <20031117065457.GB24513@zoy.org>

On Sun, Nov 16, 2003 at 11:47:24PM +0100, Jo?l Bourquard wrote:
> Some reasons:
> - Speed (ok, Huffman codes take some effort to decode, but MDCT is
> by far the most expensive process). Optimizations to Huffman
> decoding can be done, while MDCT is kind of irreductible.

MDCT can be quite fast too. Maybe not as fast as subband coding, but
still. A god implementation can go quite faster than a naive one.

Look at my AC3 decoding library at http://liba52.sf.net. Right now
decoding performance is that for a stream coded as 5.1 channels, 384
kbit/s, decoding on a 400 mhz celeron (mendocino) takes about 5.3% of
CPU time, or if we downmix to 2 channels (which can be done before the
imdct stage), 3.2%.

> Since the framing structure is cleaner in SV8, complexity should not be
> a problem (the only additional work is in a lossless SV7->SV8
> converter). I guess the inter-frame limitations can be sorted out during
> SV7->SV8 conversion.

I have to say the SV8 bitstream format is quite neat.

This kind of consideration is the main reason why I never implemented
an mp3 decoder - their bit format is just way too ugly. Layers 1 and 2
are nice and simple (even if suboptimal).

Cheers,

-- 
Michel "Walken" Lespinasse
"In this time of war against Osama bin Laden and the oppressive
Taliban regime, we are thankful that OUR leader isn't the spoiled son
of a powerful politician from a wealthy oil family who is supported by
religious fundamentalists, operates through clandestine organizations,
has no respect for the democratic electoral process, bombs innocents,
and uses war to deny people their civil liberties." --The Boondocks


From paul at msn.com  Mon Nov 17 09:12:14 2003
From: paul at msn.com (Pamel)
Date: Mon, 17 Nov 2003 02:12:14 -0600
Subject: [Matroska-devel] Re: Protocol of my 2+ hrs telephone conversation
	with Frank Klemm
References: <3FB74F26.7060700@matroska.org> <20031117064210.GA24513@zoy.org>
Message-ID: <bp9vss$gaq$1@sea.gmane.org>

"Michel Lespinasse" wrote...
> As it's my first post here, I thought I should introduce myself. I'm
> the main developper on a few projects, most notably liba52 (AC-3
> decoding library) and libmpeg2 (mpeg2 decoding).

This is a completely different topic, but I was wondering if you might be able
to help the Matroska team in its efforts to put MPEG-2 into Matroska.  The basic
spec has already been decided on, but there are lots of troubles trying to get
it to play back.    You can read the discussion about the spec here:
http://article.gmane.org/gmane.comp.multimedia.matroska.devel/1216
Apparently MPEG-2 decoders can be pretty picky about the way that they receive
data.  Any assistance from you would be most appreciated.


Pamel

P.S. Outlook Express's Reply All is screwed so I'm sorry if you don't get this
message.





From christophe.paris at free.fr  Mon Nov 17 15:13:02 2003
From: christophe.paris at free.fr (Christophe PARIS)
Date: Mon, 17 Nov 2003 15:13:02 +0100
Subject: [Matroska-devel] FLAC in Matroska
In-Reply-To: <20031116230333.GA2058@bunkus.org>
References: <20031116230333.GA2058@bunkus.org>
Message-ID: <3FB8D76E.6040403@free.fr>

Moritz Bunkus wrote:

>Hi,
>
>I've finished my FLAC-in-Matroska support and updated the Codec specs
>page. Gabest and Toff, could you please update your filter accordingly?
>Thanks.
>
I've updated CoreFLACDecoder.

MatroskaSplitter need this code to be updated :

else if(CodecID == "A_FLAC")
{
  mt.subtype = FOURCCMap(pwfe->wFormatTag = WAVE_FORMAT_FLAC);
  pwfe->cbSize = pTE->CodecPrivate.GetCount();
  BYTE* pExtra = mt.ReallocFormatBuffer(sizeof(WAVEFORMATEX)+ 
pTE->CodecPrivate.GetCount()) +
    sizeof(WAVEFORMATEX);
  memcpy(pExtra, pTE->CodecPrivate.GetData(), pTE->CodecPrivate.GetCount());
  mts.Add(mt);
}

MatroskaMuxer also need to be updated.

Regrads
Toff



From rjamorim at yahoo.com  Mon Nov 17 19:28:34 2003
From: rjamorim at yahoo.com (=?iso-8859-1?q?Roberto=20Jos=E9=20de=20Amorim?=)
Date: Mon, 17 Nov 2003 15:28:34 -0300 (ART)
Subject: [Matroska-devel] Re: [mpc-devel] Protocol of my 2+ hrs telephone
	conversation with Frank Klemm
In-Reply-To: <20031117064210.GA24513@zoy.org>
Message-ID: <20031117182834.40490.qmail@web11201.mail.yahoo.com>

 --- Michel Lespinasse <walken at zoy.org> escreveu:  
> I think the AC3 format has a lot of potential too, but currently the
> free encoders for it kinda suck. One of the interesting features of
> AC3 is that the decoder performs a bit allocation using a default
> standardized psy model - if the encoder has a better psy model, it can
> transmit deltas to apply to that bit allocation, but the idea is that
> in the end it should be cheaper to transmit these deltas than to
> transmit a whole bit allocation information. However, all free
> encoders are crappy in the respect that they dont even have their own
> psy model - they just use whatever is the result of the default psy
> model in the AC3 decoder.
> 
> Anyway. I believe a mdct based format such as AC3 would have a lot of
> potential if combined with a smart encoder using a good psy
> model. Regarding what frank told you, I'd be curious if he was
> considering a straight AC3 format encoder, or doing an AC3-derived
> format with stream format improvements similar to what he's done in
> mpc (i.e. the various shaped tables etc)

It's worth mentioning that AC3 doesn't cope well with VBR. Even though
it might be accepted by the standard, several decoders (most 
notably the ones from Dolby) choke on VBR streams.

I did a test once at doom9. A friend "hacked" the ffmpeg AC3 encoder
so to provide a silly VBR mode (he just randomized bitrates). Then,
I tried to feed this VBR streams to decoders.

Decoders based on liba52 worked well (valex' in_ac3, ac3filter...)
AC3dec worked well
Azid didn't work well. I don't remember now what was the error.
Encoders based on Dolby libraries (PowerDVD, WinDVD) choked, with
weird noises coming from the speakers and eventual crashes

I couldn't get anyone to test it through S/PDIF on receivers, but 
I'm not very hopeful of it working there either.


Also, AFAIK AC3 is as unoptimal as MP3 on VBR. The bitrates are fixed, 
and you can't increment bitrate in small steps like you can do with 
MPC, Vorbis and AAC. That usually leads to waste of bytes.

Just my 2 cents...

Best regards;

Roberto.


From chris at wiesneronline.net  Mon Nov 17 23:02:02 2003
From: chris at wiesneronline.net (Christian HJ Wiesner)
Date: Mon, 17 Nov 2003 23:02:02 +0100
Subject: [Matroska-devel] Re: [mpc-devel] Re: Protocol of my 2+ hrs
 telephone conversation with Frank Klemm
In-Reply-To: <20031117182834.40490.qmail@web11201.mail.yahoo.com>
References: <20031117182834.40490.qmail@web11201.mail.yahoo.com>
Message-ID: <3FB9455A.1090308@wiesneronline.net>

Roberto Jos? de Amorim wrote:

>It's worth mentioning that AC3 doesn't cope well with VBR. Even though
>it might be accepted by the standard, several decoders (most 
>notably the ones from Dolby) choke on VBR streams.
>Roberto.
>  
>
Roberto has a point here. It could be a wise decision to test especially 
hardware AC3 decoders on their VBR performance before actually investing 
work into a better tuned AC3 encoder. Apart from the better hardware 
decoder support in existing DVD players and Surround receivers, i 
personally cant see any reason to not use AAC for a new encoder format. 
I guess Frank has made tests already, i hope he is capable of sending a 
reply on this matter sooner or later.

Christian



From chris at wiesneronline.net  Mon Nov 17 23:26:17 2003
From: chris at wiesneronline.net (Christian HJ Wiesner)
Date: Mon, 17 Nov 2003 23:26:17 +0100
Subject: [Matroska-devel] Re: [mpc-devel] Re: Protocol of my 2+ hrs
 telephone conversation with Frank Klemm
In-Reply-To: <20031117064210.GA24513@zoy.org>
References: <3FB74F26.7060700@matroska.org> <20031117064210.GA24513@zoy.org>
Message-ID: <3FB94B09.7030003@wiesneronline.net>

Michel Lespinasse wrote:

>As it's my first post here, I thought I should introduce myself. I'm
>the main developper on a few projects, most notably liba52 (AC-3
>decoding library) and libmpeg2 (mpeg2 decoding). 
>
Welcome to the list Michel. Its good to see other developers are reading 
this list.

>I've not used mpc
>much to date, but I did look at the SV8 stream format description and
>found it quite clean. I also implemented some mpeg audio layer 1-2
>decoder in the past, but I never touched layer 3 (because I think the
>spec is so ugly). Just letting people know so they see where I'm
>coming from.
>
It appears to me you have a very good background in what we are talking 
here about .... much much better than my background ;) .

>I have to say I was quite surprised to see mpc, using subband
>  
>
>transforms so similar to mpeg audio layer 2, can perform so well. MPC
>stream format has a lot of improvements over mpeg audio layer 2
>though, with a bunch of different huffman tables you can select from,
>some including various amouts of shaping as well. So I was wondering
>how much of the improvement is due to the stream format enhancements,
>and how much is due to the psy model.
>  
>
Frank says that the psy model seems to be the key here.

>I think the AC3 format has a lot of potential too, but currently the
>free encoders for it kinda suck. One of the interesting features of
>AC3 is that the decoder performs a bit allocation using a default
>standardized psy model - if the encoder has a better psy model, it can
>transmit deltas to apply to that bit allocation, but the idea is that
>in the end it should be cheaper to transmit these deltas than to
>transmit a whole bit allocation information. However, all free
>encoders are crappy in the respect that they dont even have their own
>psy model - they just use whatever is the result of the default psy
>model in the AC3 decoder.
>  
>
Now i remember Frank told me about this one also during the 2 hours :O 
.... but i forgot to mention it in the report.

>Anyway. I believe a mdct based format such as AC3 would have a lot of
>potential if combined with a smart encoder using a good psy
>model. Regarding what frank told you, I'd be curious if he was
>considering a straight AC3 format encoder, or doing an AC3-derived
>format with stream format improvements similar to what he's done in
>mpc (i.e. the various shaped tables etc)
>  
>
Why would you chose AC3 over AAC ? Frank told me about some 'quirks' the 
AAC format has, like a missing latency time description and the like, 
but are you aware of any more limitations, or advantages of AC3 compared 
to AAC ?

>>It appears to me that Frank alone can not invest the time necessary to 
>>realize MPC SV8. On the other hand he could very well make the specs, 
>>and invest time into his main area of excellence, the psy model. He 
>>mentioned to me that he had invested too much time already into 
>>explaining what has to be done to other people, but without any real 
>>feedback from them after that.
>>    
>>
>
>Huh, I *really* know that feeling.
>  
>
;) ...... if you ever feel like working in a team, and wnat to try 
something new, give us a shout :) !

>>Its time for us to ask ourselves if we want musepack to evolve
>>further, or if we are happy with what it is today. Whilst it is
>>usable for music compression already, its not for use with video. If
>>we want musepack to progress, we all have to work together to
>>improve it. Looking forward to hear your comments.
>>    
>>
>
>OK so this is maybe a naive question from an outsider, but I'll ask it
>anyway.
>
>What's wrong with mpc for use with video ?
>
The current bitstream ( SV7 ) makes it impossible to clearly find out 
where a block/frame starts and ends. Sometimes bit from one block are 
stored with bits from another block, etc. This may not be a problem for 
'simpler' video containers, but the matroska container requests some 
very clear rules here to be respected, like the 'one block/frame in one 
matroska block' rule. Also, the MPC decoder may require up to 32 blocks 
before the actual block to be able to decode it, making seeking in the 
file generally a problem, not only for video, but for video seeking is 
maybe much more vital than for audio sometimes.

>>From my point of view, the main thing holding mpc back nowadays is the
>lack of a free encoder source code.
>Cheers,
>  
>
This will not be an issue anymore once the encoder goes final, as Frank 
promised to make it OSS then. The host and CVS for this is already up, 
http://corecodec.org/projects/mpc

Regards

Christian






From rjamorim at yahoo.com  Tue Nov 18 00:40:59 2003
From: rjamorim at yahoo.com (=?iso-8859-1?q?Roberto=20Jos=E9=20de=20Amorim?=)
Date: Mon, 17 Nov 2003 20:40:59 -0300 (ART)
Subject: [Matroska-devel] Re: [mpc-devel] Re: Protocol of my 2+ hrs
	telephone conversation with Frank Klemm
In-Reply-To: <3FB9455A.1090308@wiesneronline.net>
Message-ID: <20031117234059.89272.qmail@web11207.mail.yahoo.com>

 --- Christian HJ Wiesner <chris at wiesneronline.net> escreveu: 
> Apart from the better hardware 
> decoder support in existing DVD players and Surround receivers, i 
> personally cant see any reason to not use AAC for a new encoder format.

There is a rumour going around (and I stress this is only a rumour)
that you can detect by reading the mpegif mailing lists, about Sony
and Philips pushing AAC as the standard audio codec for Blu-Ray DVDs.

It makes sense, if you consider Philips and Sony have licensing 
interests in the AAC format, while AC3 is only of interest for Dolby.
Besides, AAC is more efficient - you need about 300kbps to store
a 5.1 stream with good quality, while AC3 is usually encoded at
448kbps for 5.1 - a 50% increase in size.

Another hint of this tendency is the receiver Sony recently released
that supports multichannel AAC LC decoding. It has been mentioned at 
Hydrogenaudio:
http://www.hydrogenaudio.org/index.php?showtopic=10222&

Anyway, just some rumours...

Regards;

Roberto.


From steve.lhomme at free.fr  Tue Nov 18 21:10:30 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Tue, 18 Nov 2003 21:10:30 +0100
Subject: [Matroska-devel] Re: [mpc-devel] Re: Protocol of my 2+
	hrs	telephone conversation with Frank Klemm
In-Reply-To: <20031117234059.89272.qmail@web11207.mail.yahoo.com>
References: <20031117234059.89272.qmail@web11207.mail.yahoo.com>
Message-ID: <3FBA7CB6.3000305@free.fr>

Roberto Jos? de Amorim wrote:

>  --- Christian HJ Wiesner <chris at wiesneronline.net> escreveu: 
> 
>>Apart from the better hardware 
>>decoder support in existing DVD players and Surround receivers, i 
>>personally cant see any reason to not use AAC for a new encoder format.
> 
> 
> There is a rumour going around (and I stress this is only a rumour)
> that you can detect by reading the mpegif mailing lists, about Sony
> and Philips pushing AAC as the standard audio codec for Blu-Ray DVDs.
> 
> It makes sense, if you consider Philips and Sony have licensing 
> interests in the AAC format, while AC3 is only of interest for Dolby.
> Besides, AAC is more efficient - you need about 300kbps to store
> a 5.1 stream with good quality, while AC3 is usually encoded at
> 448kbps for 5.1 - a 50% increase in size.
> 
> Another hint of this tendency is the receiver Sony recently released
> that supports multichannel AAC LC decoding. It has been mentioned at 
> Hydrogenaudio:
> http://www.hydrogenaudio.org/index.php?showtopic=10222&
> 
> Anyway, just some rumours...

It also makes sense to me as AAC seem to be the one format for 
low/medium/high bitrates. It's very good (compared to the past) at all 
levels. So IMO it makes sense to try to push it everywhere.



From gabest at freemail.hu  Mon Nov 17 23:23:40 2003
From: gabest at freemail.hu (Gabest)
Date: Mon, 17 Nov 2003 23:23:40 +0100
Subject: [Matroska-devel] Re: [mpc-devel] Re: Protocol of my 2+ hrs
	telephone conversation with Frank Klemm
References: <20031117182834.40490.qmail@web11201.mail.yahoo.com>
	<3FB9455A.1090308@wiesneronline.net>
Message-ID: <044a01c3ad59$748936f0$0100a8c0@i2400p4>

> >It's worth mentioning that AC3 doesn't cope well with VBR. Even though
> >it might be accepted by the standard, several decoders (most
> >notably the ones from Dolby) choke on VBR streams.
> >Roberto.
> >
> >
> Roberto has a point here. It could be a wise decision to test especially
> hardware AC3 decoders on their VBR performance before actually investing
> work into a better tuned AC3 encoder. Apart from the better hardware
> decoder support in existing DVD players and Surround receivers, i
> personally cant see any reason to not use AAC for a new encoder format.
> I guess Frank has made tests already, i hope he is capable of sending a
> reply on this matter sooner or later.
>
> Christian

Maybe I'm wrong now, but I think I read somewhere that dvds must only have
cbr ac3 streams.

(Btw, I just discovered I can capture streamed windows media into matroska
in graphedit. It would be worth turning this into a little util ;)



From gabest at freemail.hu  Mon Nov 17 08:07:27 2003
From: gabest at freemail.hu (Gabest)
Date: Mon, 17 Nov 2003 08:07:27 +0100
Subject: [Matroska-devel] FLAC in Matroska
References: <20031116230333.GA2058@bunkus.org>
Message-ID: <01f101c3acd9$7623e350$0100a8c0@i2400p4>


> I've finished my FLAC-in-Matroska support and updated the Codec specs
> page. Gabest and Toff, could you please update your filter accordingly?
> Thanks.

I could do it today, but I need to test it then. Could you upload a sample
to your web site?

> If 2) can be changed then I don't see the need to use the A_MS/ACM
> compatibility mode - you should them aim for A_FLAC. But I don't know
> anything about these DShow matters ( = who has to change what...).

Hehe, yea, dshow matters. A question to jcsston: What does the splitter have
to send the decoder in the media type and in the samples exactly? I haven't
tried your decoder yet, actually I've just found out one existed made by you
:)

> Happy end of the weekend.

Doh, it's moday 8:06, I'm already late :)




From gabest at freemail.hu  Tue Nov 18 21:22:58 2003
From: gabest at freemail.hu (Gabest)
Date: Tue, 18 Nov 2003 21:22:58 +0100
Subject: [Matroska-devel] FLAC in Matroska
References: <20031116230333.GA2058@bunkus.org>
	<01f101c3acd9$7623e350$0100a8c0@i2400p4>
Message-ID: <06c801c3ae11$c1d73750$0100a8c0@i2400p4>

Sorry about my two previous emails being late. I didn't notice my smtp was
down, and now that I've just reinstalled it, it sent all my queued up mails
out at once :)

FLAC was already tested and working, no need for samples.

----- Original Message ----- 
From: "Gabest" <gabest at freemail.hu>
To: "Discussion about the current and future development of Matroska"
<matroska-devel at lists.matroska.org>
Sent: Monday, November 17, 2003 8:07 AM
Subject: Re: [Matroska-devel] FLAC in Matroska


>
> > I've finished my FLAC-in-Matroska support and updated the Codec specs
> > page. Gabest and Toff, could you please update your filter accordingly?
> > Thanks.
>
> I could do it today, but I need to test it then. Could you upload a sample
> to your web site?
>
> > If 2) can be changed then I don't see the need to use the A_MS/ACM
> > compatibility mode - you should them aim for A_FLAC. But I don't know
> > anything about these DShow matters ( = who has to change what...).
>
> Hehe, yea, dshow matters. A question to jcsston: What does the splitter
have
> to send the decoder in the media type and in the samples exactly? I
haven't
> tried your decoder yet, actually I've just found out one existed made by
you
> :)
>
> > Happy end of the weekend.
>
> Doh, it's moday 8:06, I'm already late :)
>
>
> _______________________________________________
> Matroska-devel mailing list
> Matroska-devel at lists.matroska.org
> http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel
>
>
>



From chris at matroska.org  Thu Nov 20 20:20:30 2003
From: chris at matroska.org (Christian HJ Wiesner)
Date: Thu, 20 Nov 2003 20:20:30 +0100
Subject: [Matroska-devel] [Fwd: a FLAC frame decoder]
Message-ID: <3FBD13FE.90304@matroska.org>

Can we use this lib better than libflac for what we are trying to do ?

Christian

-------- Original Message --------
Subject: a FLAC frame decoder
Date: Thu, 20 Nov 2003 18:26:36 +0100
From: Miroslav Lichvar <lichvarm at phoenix.inf.upol.cz>
Newsgroups: gmane.comp.audio.compression.flac.devel

I have written a FLAC frame decoder, it doesn't know anything about
stream or metadata blocks, only frames. It is a C library (well, one C
file with one public function) and it aims to be a high performance
decoder with minimum memory usage for slow CPUs (e.g. old Pentium w/o
MMX), but that doesn't mean it isn't fast on a fast CPU :).

In the package there is also a example decoder/recovery tool for
native FLAC files using affd. It has passed test_stream.sh from the
extensive FLAC testing suite, therefore i think affd is able to manage
every frame.

Ok, don't expect too much, it's first version, it has almost no
documentation, no reasonable build system, etc...

download:
http://phoenix.inf.upol.cz/~lichvarm/affd/affd-0.1.0.tar.gz

I hope someone find it useful, at least the recovery tool.

Thanks for any comments,



From moritz at bunkus.org  Thu Nov 20 21:09:28 2003
From: moritz at bunkus.org (Moritz Bunkus)
Date: Thu, 20 Nov 2003 21:09:28 +0100
Subject: [Matroska-devel] [Fwd: a FLAC frame decoder]
In-Reply-To: <3FBD13FE.90304@matroska.org>
References: <3FBD13FE.90304@matroska.org>
Message-ID: <20031120200928.GU2058@bunkus.org>

Heya,

> Can we use this lib better than libflac for what we are trying to do ?

Well, not really. It can't handle metadata packets so we still need
libFLAC. And from looking at the code I think that the complete raw FLAC
has to be decoded in order to find packet boundaries. So yes,
integration into mkvmerge would have been easier with it (hmm not really
because I still need libFLAC for the metadata...), but it doesn't make
things easier for me at the moment.

-- 
 ==> Ciao, Mosu (Moritz Bunkus)


From chris at wiesneronline.net  Thu Nov 20 23:02:24 2003
From: chris at wiesneronline.net (Hydrogenaudio Forums)
Date: 20 Nov 2003 22:02:24 -0000
Subject: [Matroska-devel] Improving ReplayGain ( From Hydrogenaudio Forums )
Message-ID: <20031120220224.17738.qmail@animus-facticius.org>



matroska Devel


I thought you might be interested in reading this web page:

http://www.hydrogenaudio.org/index.php?act=ST&f=1&t=15445

From, ChristianHJW


---------------------------------------------------
Please note that Hydrogenaudio Forums has no control over the
contents of this message.
---------------------------------------------------

Regards,

The Hydrogenaudio Forums team.
http://www.hydrogenaudio.org/index.php



From chris at matroska.org  Thu Nov 20 23:16:38 2003
From: chris at matroska.org (Christian HJ Wiesner)
Date: Thu, 20 Nov 2003 23:16:38 +0100
Subject: [Matroska-devel] [Fwd: Antwort: Re: Erste Datei]
Message-ID: <3FBD3D46.1040202@matroska.org>

Frank replying about my question how we could repack SV7 into SV8, so we 
can start using it in matroska ... and in english even :) !!!! ..... 
sorry that my original email was in German, but i guess you can think 
what my questions were when looking at his answers ....

Christian

-------- Original Message --------
Subject: 	Antwort: Re: Erste Datei
Date: 	Tue, 18 Nov 2003 12:15:53 +0100
From: 	Frank Klemm <f.klemm at zeiss.de>
To: 	chris at matroska.org, rjamorim at yahoo.com



Christian wrote:

>Frank Klemm wrote:
>> So, die erste Datei angefangen.
>> Die wird wahrscheinlich 30 bis 40 Kbyte lang.
>> Hier soll gekl?rt werden
>> - prinzipieller Aufbau
>> - Kurzbeschreibung Arbeitspakete
> Ganz hydrogenaudio und alle MPC fans haben sich riesig gefreut ?bder 
> diese email von Dir. Es scheint da? es immer noch sehr viele treue MPC 
> fans gibt, und da? viele hoffen da? sich MPC weiterentwickelt.
> Die Idee f?r SV8 einen radikalen Bruch zu machen und von subband coding 
> auf einen tranfromations codec zu wechseln wurde allen Ortens sehr 
> begr?sst. Einige habe sich gewundert ob es tats?chlich m?glich ist einen 
> AC3 oder AAC encoder zu machen der besser als MPC klingt, aber im 
> Endeffekt glaubt wohl jeder da? es wohl m?glich ist, wenn nur Du es bist 
> der es durchzieht ;) ...


The implementation of AAC and AC3 needs two modules which must be
replaced. Most of the coder can be reused. Most important is that
the psychomodel can be reused.


> ?brigens : Kannst Du schon absch?tzen ob der SV8 bitstream so bleiben 
> kann wie er jetzt ist ? DRC wird ja wohl nicht im bitstream definiert 
> werden, oder ? Wenn der SV8 bitstream so bleiben kann, kannst Du f?r 
> mich versuchen abzusch?tzen wie lange es wohl dauern w?rde ein kleines 
> Programm zu schreiben mit dem SV7 files in SV8 umgepackt werden k?nnen ? 
> Wenn wir das h?tten k?nnten wir n?mlich wirklich loslegen und MPC in 
> matroska realisieren, mit den alten SV7 enkodern. Alternative k?nnten 
> wir versuchen Deinen 'alpha' SV8 encoder zu verwenden und direkt von ihm 
> ?ber libmatroska in MKA files zu schreiben, die Variante mit einem 
> 'Umpack' Programm w?re uns aber lieber, da wir ja nicht wissen was sich 
> in SV8 tats?chlich noch von der encoder Seite alles ?ndern wird.


First goal of "transpacked SV7" SV8 is to make the blocks independent from 
others.
SV7 uses differential encoding acrossing block boundaries.
This (the removal of this cross block differential coding) need some 
additional bitrate, 
but it makes software design much more simple and makes it easier to write 
addtional tools.

First we should discuss about the size of these independent blocks.
AC3 calls this blocks audioblocks.

* Basic block size of SV7 is 1152 samples. I would use a multiple of this
  for "transpacked SV7" SV8. Examples:

        a) 2 blocks  => 2304 samples ( 52 ms for 44.1 kHz,  48 ms for 48 
kHz)
        b) 4 blocks  => 4608 samples (104 ms for 44.1 kHz,  96 ms for 48 
kHz)
        c) 8 blocks  => 9216 samples (209 ms for 44.1 kHz, 192 ms for 48 
kHz)

        Samples should be stored in a way so it is possible to decode 
block by 
        block to minimize memory consumption, even when this is not done 
in the 
        reference implementation.

* Native SV8 for 32 kHz...64 kHz sample frequency.
        a) 4096 samples ( 93 ms for 44.1 kHz,  85 for 48 kHz)
        b) 8192 samples (186 ms for 44.1 kHz, 171 for 48 kHz)

For 8...16 kHz this is quartered, for 16...32 kHz it is halved, for 
64...128 kHz doubled
and for 128...256 kHz four times larger. But this only as remark.

Frank Klemm





From chris at matroska.org  Mon Nov 24 10:34:37 2003
From: chris at matroska.org (Christian HJ Wiesner)
Date: Mon, 24 Nov 2003 10:34:37 +0100
Subject: [Matroska-devel] Re: [mpc-devel] [Fwd: Antwort: Re: Erste Datei]
In-Reply-To: <3FBD3D46.1040202@matroska.org>
References: <3FBD3D46.1040202@matroska.org>
Message-ID: <3FC1D0AD.8050108@matroska.org>

Christian HJ Wiesner wrote:

>First goal of "transpacked SV7" SV8 is to make the blocks independent from 
>others.
>SV7 uses differential encoding acrossing block boundaries.
>This (the removal of this cross block differential coding) need some 
>additional bitrate, 
>but it makes software design much more simple and makes it easier to write 
>addtional tools.
>
Forgive me if i am talking complete rubbish, but i have more and more 
problems understanding what you are trying to do here :

 From my understanding the SV8 framing should not only bring a new 
framing, but also introduce serious changes to the blocks itself ? If 
you make an app that simply 're-packs' SV7 files into a SV8 framing, 
will the old blocks be converted also, so they are SV8 compliant, or do 
you plan to introduce a 'SV7 compatibility mode' in SV8, so that SV7 
blocks can be put into the new framing ?

For the changes to the blocks itself, i do understand that the follwoing 
new features require a new block design :

- multichannel ( 5.1 )
- more flexible sampling rate support
- DRC
etc.

Now with respect to what you told me on the phone, i mean your ideas 
about leaving the subband encoder design completely for next musepack, 
how about considering tow steps for this :

1. SV8 : subband encoder like SV7, but adding all the new features 
listed above

2. SV9 / new codec name : new encoder based on tranformation encoding, 
or a new OSS AAC encoder

Christian

>First we should discuss about the size of these independent blocks.
>AC3 calls this blocks audioblocks.
>
>* Basic block size of SV7 is 1152 samples. I would use a multiple of this
>  for "transpacked SV7" SV8. Examples:
>
>        a) 2 blocks  => 2304 samples ( 52 ms for 44.1 kHz,  48 ms for 48 
>kHz)
>        b) 4 blocks  => 4608 samples (104 ms for 44.1 kHz,  96 ms for 48 
>kHz)
>        c) 8 blocks  => 9216 samples (209 ms for 44.1 kHz, 192 ms for 48 
>kHz)
>
>        Samples should be stored in a way so it is possible to decode 
>block by 
>        block to minimize memory consumption, even when this is not done 
>in the 
>        reference implementation.
>
>* Native SV8 for 32 kHz...64 kHz sample frequency.
>        a) 4096 samples ( 93 ms for 44.1 kHz,  85 for 48 kHz)
>        b) 8192 samples (186 ms for 44.1 kHz, 171 for 48 kHz)
>
>For 8...16 kHz this is quartered, for 16...32 kHz it is halved, for 
>64...128 kHz doubled
>and for 128...256 kHz four times larger. But this only as remark.
>Frank Klemm
>  
>




From chojin22 at dodo.com.au  Tue Nov 25 17:10:24 2003
From: chojin22 at dodo.com.au (Rob Saunders)
Date: Wed, 26 Nov 2003 02:10:24 +1000
Subject: [Matroska-devel] MKV menus
Message-ID: <bpvutf$20b$1@sea.gmane.org>

Hi,
    I am new to this list/group so I deeply appologise if this is an
exhausted topic or anything, but I was wondering if there's been any work
done in the spec about menus in matroska?
    I know it's far too much to expect any implementations to have been
attempted so far - but I'd like to read any documentation that has been
done? I tried looking through the spec but couldn't find much. My
understanding is that they will be similar to how dvd menus work? I assume
there will be some kind of subsystem independant from the matroska container
itself? (SVG perhaps?) Any pointers in the right direction would be
appreciated.

Anyway thanks for your time.
rob





From paul at msn.com  Tue Nov 25 21:58:56 2003
From: paul at msn.com (Pamel)
Date: Tue, 25 Nov 2003 14:58:56 -0600
Subject: [Matroska-devel] Re: MKV menus
References: <bpvutf$20b$1@sea.gmane.org>
Message-ID: <bq0fp1$7e7$1@sea.gmane.org>

"Rob Saunders" wrote...
> Hi,

Hello.

>     I am new to this list/group so I deeply appologise if this is an
> exhausted topic or anything, but I was wondering if there's been any work
> done in the spec about menus in matroska?

All that has been done so far is discussion of possible methods.  Nothing
concrete has been decided on.  Well, nothing even like jello has been decided
on.  Just discussion.

>     I know it's far too much to expect any implementations to have been
> attempted so far - but I'd like to read any documentation that has been
> done?

The only documentation is the messages posted in this mailing list.  Feel free
to browse here:
http://news.gmane.org/gmane.comp.multimedia.matroska.devel

> I tried looking through the spec but couldn't find much. My
> understanding is that they will be similar to how dvd menus work?

Thats what we hope.  Before the project was split from MCF, there was a menu
system defined.  It was pretty effective, but didn't allow for any of the
fancier stuff defined in DVD menus.  Really, it would be nice to have a simple
menu system that was easy to design and use that didn't require so much
developement to bring it into a useable state.  But everyone wants the fancy
stuff used with DVD menus so that is what was being discussed more.

> I assume
> there will be some kind of subsystem independant from the matroska container
> itself?

That is what I was pushing for.  If the menu system can be portable and used in
other formats then it has a greater chance of taking off.

> (SVG perhaps?)

SVG has been mentioned.  Also Flash, HTML, MNG, the MP4 Menuing system, and
others.  There are many different options to be looked at and all of them have
Pros and Cons.  Using an existing system makes the most sense because it reduces
development time by providing already made libraries.  Also, you want something
that can't require any licensing fees as that would defeat one of the purposes
of Matroska.

There are two stages for making the Menus:

1. Design the spec.  This isn't really that hard once a format is chosen and
somebody has the time to write it all down.

2. Coding a library.  This is where it grinds to a halt.  Noone even wants to
design the spec because noone in their right mind would volunteer to code a
complex menuing library.  It would have to work in DirectShow as that is the
most common userbase, and WMP9 can't even get decent DVD menu support in
DirectShow.  And the more complex the menu system, the more difficult the coding
of the libraries would be.

If you are feeling so inclined, you could write up a spec and send it to the ML
for comment.  And if you are even more daring you could code an interface
library.  Any help or ideas here would be greatly appreciated.


Pamel





From suiryc at yahoo.com  Wed Nov 26 20:28:57 2003
From: suiryc at yahoo.com (Cyrius)
Date: Wed, 26 Nov 2003 11:28:57 -0800 (PST)
Subject: [Matroska-devel] KaxBlock is b0rked
In-Reply-To: <bpvutf$20b$1@sea.gmane.org>
Message-ID: <20031126192857.22397.qmail@web12902.mail.yahoo.com>

Some new code has been added recently to read data
fully or partially.

But now KaxBlock is b0rked.

Here are the problems I spotted so far :

1. Previously the Frames found in a KaxBlock were
stored in a vector of DataBuffer elements. One would
then get a DataBuffer in this vector and have the
associated data (size of the frame).
A vector of uint32 data (a vector of frame sizes) has
been added so that the KaxBlock can hold the size of
each frame when data are read partially. But this
vector is not sized correctly (by default it has a
size of 0 elements), and yet the current code tries to
assign data in this vector (resulting in an access
violation).

A possible solution : add

SizeList.resize(FrameNum + 1);

when reading fully or partially the KaxBlock, just
before getting the sizes of the frames.


2. A new function (GetFrameSize) has been added for us
to retrieve the size of the frames (instead of getting
the DataBuffer - which aren't available when reading
partially). 2 problems here :

* when no lacing has been used (i.e. there is only one
frame) the size of the frame isn't stored anywhere
(except in the DataBuffer when reading fully) !!
A solution : add

SizeList.resize(1);
SizeList[0] = Size - BlockHeadSize;

in this case (LACING_NONE).

* when reading partially the bValueIsSet flag is set
to false. But the GetFrameSize function test it and
returns -1 if it is false !!!
Even if the value isn't set frame sizes have been
stored, so there is no need to test bValueIsSet here.


3. There is a function (NumberFrames) to get the
number of frames in the KaxBlock. But this function
returns the number of DataBuffer elements. So it is
only correct when reading fully the KaxBlock, and
returns 0 when reading partially (which is bad !!).
A solution : return the number of frame sizes we
retrieved in our vector (SizeList.size()).


I don't know who added those b0rks :p and if there was
something planned next, but let us know if we can fix
those b0rks now.

__________________________________
Do you Yahoo!?
Free Pop-Up Blocker - Get it now
http://companion.yahoo.com/


From steve.lhomme at free.fr  Wed Nov 26 23:31:10 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Wed, 26 Nov 2003 23:31:10 +0100
Subject: [Matroska-devel] KaxBlock is b0rked
In-Reply-To: <20031126192857.22397.qmail@web12902.mail.yahoo.com>
References: <20031126192857.22397.qmail@web12902.mail.yahoo.com>
Message-ID: <3FC529AE.1000002@free.fr>

Cyrius wrote:
> I don't know who added those b0rks :p and if there was
> something planned next, but let us know if we can fix
> those b0rks now.

Can it wait until next week ? Because it will be impossible for me to 
work on it until monday or tuesday next week...



From suiryc at yahoo.com  Wed Nov 26 23:36:50 2003
From: suiryc at yahoo.com (Cyrius)
Date: Wed, 26 Nov 2003 14:36:50 -0800 (PST)
Subject: [Matroska-devel] KaxBlock is b0rked
In-Reply-To: <3FC529AE.1000002@free.fr>
Message-ID: <20031126223650.45509.qmail@web12904.mail.yahoo.com>

> Can it wait until next week ? Because it will be
> impossible for me to 
> work on it until monday or tuesday next week...

Yes I can wait.
I used the fixes I mentionned for my VDM local copy so
I can wait :p

__________________________________
Do you Yahoo!?
Free Pop-Up Blocker - Get it now
http://companion.yahoo.com/


From steve.lhomme at free.fr  Wed Nov 26 23:46:58 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Wed, 26 Nov 2003 23:46:58 +0100
Subject: [Matroska-devel] KaxBlock is b0rked
In-Reply-To: <20031126223650.45509.qmail@web12904.mail.yahoo.com>
References: <20031126223650.45509.qmail@web12904.mail.yahoo.com>
Message-ID: <3FC52D62.6030303@free.fr>

Cyrius wrote:
>>Can it wait until next week ? Because it will be
>>impossible for me to 
>>work on it until monday or tuesday next week...
> 
> 
> Yes I can wait.
> I used the fixes I mentionned for my VDM local copy so
> I can wait :p

Did something change on matroska-devel ? I don't receive the messages I 
post. (I sent one yesterday about menus and didn't see it too)



From paul at msn.com  Thu Nov 27 09:13:51 2003
From: paul at msn.com (Pamel)
Date: Thu, 27 Nov 2003 02:13:51 -0600
Subject: [Matroska-devel] Re: KaxBlock is b0rked
References: <20031126223650.45509.qmail@web12904.mail.yahoo.com>
	<3FC52D62.6030303@free.fr>
Message-ID: <bq4bm7$aol$1@sea.gmane.org>

"Steve Lhomme"  wrote...
> Did something change on matroska-devel ? I don't receive the messages I
> post. (I sent one yesterday about menus and didn't see it too)

I don't know if anything changed, but I don't see a message from you about
menus.


Pamel





From rbultje at ronald.bitfreak.net  Thu Nov 27 23:45:54 2003
From: rbultje at ronald.bitfreak.net (Ronald Bultje)
Date: Thu, 27 Nov 2003 23:45:54 +0100
Subject: [Matroska-devel] seekhead/info
Message-ID: <1069973112.11303.238.camel@shrek.bitfreak.net>

Hi,

is seekhead mandatory in a stream? And is order of these elements in an
EBML stream fixed (i.e., is seekhead + info always the first two masters
in an matroska segment)?

Thie is for demuxing, not muxing, don't worry. My muxer will be simple.
;).

Ronald

-- 
Ronald Bultje <rbultje at ronald.bitfreak.net>
Linux Video/Multimedia developer



From paul at msn.com  Fri Nov 28 03:01:01 2003
From: paul at msn.com (Pamel)
Date: Thu, 27 Nov 2003 20:01:01 -0600
Subject: [Matroska-devel] Re: seekhead/info
References: <1069973112.11303.238.camel@shrek.bitfreak.net>
Message-ID: <bq6a70$dup$1@sea.gmane.org>

"Ronald Bultje" wrote...
> is seekhead mandatory in a stream?

Yes.  Although a good demuxer should be able to locate all of the needed level 1
elements without the Seekhead using brute force in case the file is damaged.

> And is order of these elements in an
> EBML stream fixed (i.e., is seekhead + info always the first two masters
> in an matroska segment)?

I think that it was recently decided that certain elements are, IE: "The
seekhead should always be the first level 1 element."  However, I can not find
this in the specs currently.


Pamel





From paul at msn.com  Fri Nov 28 03:41:57 2003
From: paul at msn.com (Pamel)
Date: Thu, 27 Nov 2003 20:41:57 -0600
Subject: [Matroska-devel] Matroska Specs Notes
Message-ID: <bq6cjp$gn5$1@sea.gmane.org>

In the Notes section of the Matroska specs I noticed a few odd things.

1. On the first line the word "Octet" is spelled wrong.

2. This line, "A Matroska file contains one or more segments. It can optionally
be safely started with the old 160-octets type header without the EOF char."
And it has a link to the old MCF header page.  Is there really any reason to
support this?

3.  This line, "There is currently no encryption defined. It will be defined
when an open DRM system will exist. It should work at Block level and/or Cluster
level and/or Track level and/or Segment level."  Encryption was just defined, so
shouldn't this be removed?

4.  This line, "The position in some elements refers to the position, in octets,
from the beginning of an element. The reference is the beginning of the first
Segment element. 0 = first level 1 element in the segment. When data is spanned
over mutiple "linked Segments" (in the same file or in different files), the
position represents the accumulated offset of each Segment. For example to
reference a position in the third segment, the position will be: the first
segment total size + second segment total size + offset of the element in the
third segment. "  Is this really used this way?  What if the first file is
damaged and missing some data, wouldn't that screw up the offsets for the other
files?  Also, "multiple" is misspelled.

5. This line, "The BlockAddition attached to the Block means that it must be
found in the same Cluster, after the Block and before the next Block. That means
that other elements like a CRC can be put in between. There is only one
BlockAddition per Block. "  Should that be "BlockAdditions" or
"BlockAdditional"?  Also, does it serve any purpose right now?

6.  The line, "Overlay tracks should be rendered in the same 'channel' as the
track it's linked to. When content is found in such a track it is play on the
rendering channel instead of the original track. The codec in this track may be
omitted if it should be rendered using the original stream."  First, is it
possible to list more than one stream that the track should be the overlay for?
Second, would the codec EVER not be identified?  That sounds a bit dangerous to
me.


Pamel





From moritz at bunkus.org  Fri Nov 28 09:26:46 2003
From: moritz at bunkus.org (Moritz Bunkus)
Date: Fri, 28 Nov 2003 09:26:46 +0100
Subject: [Matroska-devel] seekhead/info
In-Reply-To: <1069973112.11303.238.camel@shrek.bitfreak.net>
References: <1069973112.11303.238.camel@shrek.bitfreak.net>
Message-ID: <20031128082646.GG19712@bunkus.org>

Hi,

> is seekhead mandatory in a stream?

No (Pamel is not correct). However, if one is not present you're "free"
to do what you think is better: implement some imprecise seeking, try to
find all clusters and additional level 1 elements yourself, disable
seeking.

Of course you should try hard to enable seeking for such files as well
;) It's just like Ogg in this case ;)

> And is order of these elements in an EBML stream fixed (i.e., is
> seekhead + info always the first two masters in an matroska segment)?

Partially. Here's the link to the discussion we had and the current
status quo:
http://lists.matroska.org/pipermail/matroska-devel/2003-October/000982.html

Read 4). This means that a KaxInfo can come before or after a
KaxSeekHead, meaning you have to defer the calculation of timecodes
until you've found the KaxInfo (and with it the timecode scale
factor). Easy to do.

But this has to be added to the specs soon. I hope I can work on the
specs tonight or this weekend, including the issues that Pamel mentioned
in his other mail.

-- 
 ==> Ciao, Mosu (Moritz Bunkus)


From S.Lhomme at NEOPOST.FR  Fri Nov 28 09:44:04 2003
From: S.Lhomme at NEOPOST.FR (Lhomme Steve)
Date: Fri, 28 Nov 2003 09:44:04 +0100
Subject: [Matroska-devel] Re: Matroska Specs Notes
Message-ID: <B72964E1ABB3D311B92900508B8B2115037DF260@NTCOM>

(I'll try to send this from work, not sure if it will work)

> 2. This line, "A Matroska file contains one or more segments. It can
optionally
> be safely started with the old 160-octets type header without the EOF
char."
> And it has a link to the old MCF header page.  Is there really any reason
to
> support this?

The type header is not needed. But a Matroska file can have many segments...
It can actually even have more than one EBML head. That's needed if you want
to be able to use the "cat" UNIX function. But of course there are some
strict conditions for this to work. It should actually be only usable when
the 2 original files were linked. Otherwise playback is "uncertain"...
Anyway I'm not sure any player support this "cat" feature yet.

> 3.  This line, "There is currently no encryption defined. It will be
defined
> when an open DRM system will exist. It should work at Block level and/or
Cluster
> level and/or Track level and/or Segment level."  Encryption was just
defined, so
> shouldn't this be removed?

Not removed, but changed to say that one possible type of encryption is
supported under one particular OS...

> Is this really used this way?  What if the first file is
> damaged and missing some data, wouldn't that screw up the offsets for the
other
> files?  

Used, I'm not sure but IMO that's the way to do it. But right now I think
that each part of a link set only contain the seek positions of its own
data, not the entire. Am I write Mosu ?

> Also, "multiple" is misspelled.

You don't need anyone's approval to correct misspelling.

> First, is it
> possible to list more than one stream that the track should be the overlay
for?

I don't have the specs here, but I don't think so.

> Second, would the codec EVER not be identified?  That sounds a bit
dangerous to
> me.

Mmm, I'll have to check that. I don't remember how it's supposed to work.


From paul at msn.com  Fri Nov 28 18:35:06 2003
From: paul at msn.com (Pamel)
Date: Fri, 28 Nov 2003 11:35:06 -0600
Subject: [Matroska-devel] Re: seekhead/info
References: <1069973112.11303.238.camel@shrek.bitfreak.net>
	<20031128082646.GG19712@bunkus.org>
Message-ID: <bq80u9$6bq$1@sea.gmane.org>


"Moritz Bunkus" wrote...
> > is seekhead mandatory in a stream?
>
> No (Pamel is not correct).

Ah, I was going off of the profiles, which lists it as mandatory for all
profiles.


Pamel





From steve.lhomme at free.fr  Fri Nov 28 18:39:52 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Fri, 28 Nov 2003 18:39:52 +0100
Subject: [Matroska-devel] Re: seekhead/info
In-Reply-To: <bq80u9$6bq$1@sea.gmane.org>
References: <1069973112.11303.238.camel@shrek.bitfreak.net>	<20031128082646.GG19712@bunkus.org>
	<bq80u9$6bq$1@sea.gmane.org>
Message-ID: <3FC78868.9080306@free.fr>

Pamel wrote:
> "Moritz Bunkus" wrote...
> 
>>>is seekhead mandatory in a stream?
>>
>>No (Pamel is not correct).
> 
> 
> Ah, I was going off of the profiles, which lists it as mandatory for all
> profiles.

The way the profiles are done right now is not good (and not up to date 
IMO). The profiles are for readers, not muxers.



From paul at msn.com  Fri Nov 28 19:21:19 2003
From: paul at msn.com (Pamel)
Date: Fri, 28 Nov 2003 12:21:19 -0600
Subject: [Matroska-devel] Re: Matroska Specs Notes
References: <B72964E1ABB3D311B92900508B8B2115037DF260@NTCOM>
Message-ID: <bq83ku$b9p$1@sea.gmane.org>

"Lhomme Steve"  wrote...
> > 2. This line, "A Matroska file contains one or more segments. It can
> > optionally
> > be safely started with the old 160-octets type header without the EOF
> > char."
> > And it has a link to the old MCF header page.  Is there really any reason
> > to support this?
>
> The type header is not needed. But a Matroska file can have many segments...
> It can actually even have more than one EBML head. That's needed if you want
> to be able to use the "cat" UNIX function. But of course there are some
> strict conditions for this to work. It should actually be only usable when
> the 2 original files were linked. Otherwise playback is "uncertain"...
> Anyway I'm not sure any player support this "cat" feature yet.

My question was really just about the use of an MCF header at the beginning of
the next segment.  Why use an MCF header and not something EBMLish?  There isn't
even any existing code to use to create the header.  If you really want a
generic custom header to append on the front, make one specific to Matroska.

> > 3.  This line, "There is currently no encryption defined. It will be
> > defined
> > when an open DRM system will exist. It should work at Block level and/or
> > Cluster
> > level and/or Track level and/or Segment level."  Encryption was just
> > defined, so
> > shouldn't this be removed?
>
> Not removed, but changed to say that one possible type of encryption is
> supported under one particular OS...

I don't think that Jory's encryption filter yet supports this feature.  I was
just saying that the needed design has been added now so this statement isn't
accurate.  If nothing else, "DRM can be used by encrypting the stream with the
ContentEncryption elements."

BTW, noone specified in the specs that the Blocks are all encrypted individualy
or whether or not the CodecPrivate is also encrypted.

> You don't need anyone's approval to correct misspelling.

I wasn't going to fix it right then, but I also didn't want to forget.  ;)

> > First, is it
> > possible to list more than one stream that the track should be the overlay
> > for?
>
> I don't have the specs here, but I don't think so.

It isn't marked as a Multi, but what if the same sub track should be used for
more than one video track?


Pamel