From blacksun at corecodec.com  Wed Feb  5 12:04:54 2003
From: blacksun at corecodec.com (Ludovic Vialle)
Date: Wed, 05 Feb 2003 15:04:54 +0400
Subject: [matroska-devel] Re: UCI, matroska and rududu wavelet codec
In-Reply-To: <1043947273.3e395f09e3f3f@imp.free.fr>
References: <014401c2c872$bf5f3570$a70aa8c0@mahlo.de> <3E3956E8.3000809@ifrance.com> <1043947273.3e395f09e3f3f@imp.free.fr>
Message-ID: <b1qr2d$e37$1@main.gmane.org>



>>ps : pour les quelques fran?ais de cette liste, o? habitez-vous ?
>>Moi c'est vers Grenoble
> 
> 
> Moi c'est Paris :)
> Et Blacksun (le grand ma?tre de CoreCodec) la R?union (mais bient?t de retour en
> m?tropole).
> 

Ouais moi c'est la reunion :) Bientot toulouse !


http://matroska.org


From blacksun at corecodec.com  Wed Feb  5 12:08:24 2003
From: blacksun at corecodec.com (Ludovic Vialle)
Date: Wed, 05 Feb 2003 15:08:24 +0400
Subject: [matroska-devel] MPC DirectShow filter
Message-ID: <b1qr91$fuc$1@main.gmane.org>


I know I'm on the wrong list, but I wanted to talk about The Core Media 
Player. We're going to start a DirectShow filter for TCMP for MPC 
playback, and we were wondering where we can get the latest SV8 decoding 
code to read/parse/play this new file format.

Also is that possible to have some alpha/dev tools to encode to SV8 ? If 
we're fast enough we may be the first to player SV8 :)

Thanks
Ludovic


http://matroska.org


From christian at matroska.org  Wed Feb  5 12:29:47 2003
From: christian at matroska.org (ChristianHJW)
Date: Wed, 5 Feb 2003 12:29:47 +0100
Subject: [matroska-devel] Re: MPC DirectShow filter
References: <b1qr91$fuc$1@main.gmane.org>
Message-ID: <b1qsfd$kn0$1@main.gmane.org>


"Ludovic Vialle" <blacksun at corecodec.com> schrieb im Newsbeitrag
news:b1qr91$fuc$1 at main.gmane.org...
> Player. We're going to start a DirectShow filter for TCMP for MPC
> playback, and we were wondering where we can get the latest SV8 decoding
> code to read/parse/play this new file format.

Wooot !!

http://www.personal.uni-jena.de/~pfk/mpp/
http://www.saunalahti.fi/~cse/mpc/index.html
http://www.ca5e.tk/
http://www.saunalahti.fi/~cse/ ( mirror )


> Also is that possible to have some alpha/dev tools to encode to SV8 ? If
> we're fast enough we may be the first to player SV8 :)
> Thanks
> Ludovic

get your crazy CVS on corecodec.org working and you get all the latest
sources uploaded to there ;)

Christian



http://matroska.org


From steve.lhomme at free.fr  Wed Feb  5 12:35:00 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Wed, 05 Feb 2003 12:35:00 +0100 (CET)
Subject: [matroska-devel] Re: MPC DirectShow filter
In-Reply-To: <b1qsfd$kn0$1@main.gmane.org>
References: <b1qr91$fuc$1@main.gmane.org> <b1qsfd$kn0$1@main.gmane.org>
Message-ID: <1044444900.3e40f6e486e36@imp.free.fr>


En r?ponse ? ChristianHJW <christian at matroska.org>:

> 
> "Ludovic Vialle" <blacksun at corecodec.com> schrieb im Newsbeitrag
> news:b1qr91$fuc$1 at main.gmane.org...
> > Player. We're going to start a DirectShow filter for TCMP for MPC
> > playback, and we were wondering where we can get the latest SV8
> decoding
> > code to read/parse/play this new file format.

BTW, while I think about it... There is currently no SV8 files floating around.
So people will want to play their SV7 ones now. The old decoders should help for
that. A look at Case's Winamp input plugin might also be a good starting point
(dunno if the sources are available).
http://matroska.org


From steve.lhomme at free.fr  Wed Feb  5 12:46:45 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Wed, 05 Feb 2003 12:46:45 +0100 (CET)
Subject: [matroska-devel] Re: MPC DirectShow filter
In-Reply-To: <1044444900.3e40f6e486e36@imp.free.fr>
References: <b1qr91$fuc$1@main.gmane.org> <b1qsfd$kn0$1@main.gmane.org> <1044444900.3e40f6e486e36@imp.free.fr>
Message-ID: <1044445605.3e40f9a574ec0@imp.free.fr>


En r?ponse ? Steve Lhomme <steve.lhomme at free.fr>:

> BTW, while I think about it... There is currently no SV8 files floating
> around.
> So people will want to play their SV7 ones now. The old decoders should
> help for
> that. A look at Case's Winamp input plugin might also be a good starting
> point
> (dunno if the sources are available).

After a quick search I found what you need (what people are currently asking for) :
http://www.saunalahti.fi/~cse/mpc/winamp/index.html
Get the latest Winamp2 decoder source.

All the basics you need to decode are in in_mpc.cpp (see the In_Module structure
and the DecodeThread code). If you use the same code with some DShow Adaptation,
it could be very easy to make a filter (provided the coder knows DShow well, and
C/C++ too).
http://matroska.org


From blacksun at corecodec.com  Wed Feb  5 12:49:53 2003
From: blacksun at corecodec.com (Ludovic Vialle)
Date: Wed, 05 Feb 2003 15:49:53 +0400
Subject: [matroska-devel] Re: MPC DirectShow filter
In-Reply-To: <1044445605.3e40f9a574ec0@imp.free.fr>
References: <b1qr91$fuc$1@main.gmane.org> <b1qsfd$kn0$1@main.gmane.org> <1044444900.3e40f6e486e36@imp.free.fr> <1044445605.3e40f9a574ec0@imp.free.fr>
Message-ID: <b1qtmp$pcd$1@main.gmane.org>


Ah excellent :) If it don't take too much time, Matthias will certainly 
code it. He was a bit worried about the amount of C files and was 
looking for a library which sound easier.

I definitely want to support MPC as much as I can.

btw you guys are lurking there and waiting for new posts or what ? LOL



Steve Lhomme wrote:
> En r?ponse ? Steve Lhomme <steve.lhomme at free.fr>:
> 
> 
>>BTW, while I think about it... There is currently no SV8 files floating
>>around.
>>So people will want to play their SV7 ones now. The old decoders should
>>help for
>>that. A look at Case's Winamp input plugin might also be a good starting
>>point
>>(dunno if the sources are available).
> 
> 
> After a quick search I found what you need (what people are currently asking for) :
> http://www.saunalahti.fi/~cse/mpc/winamp/index.html
> Get the latest Winamp2 decoder source.
> 
> All the basics you need to decode are in in_mpc.cpp (see the In_Module structure
> and the DecodeThread code). If you use the same code with some DShow Adaptation,
> it could be very easy to make a filter (provided the coder knows DShow well, and
> C/C++ too).
> http://matroska.org
> 


http://matroska.org


From steve.lhomme at free.fr  Wed Feb  5 12:44:41 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Wed, 05 Feb 2003 12:44:41 +0100 (CET)
Subject: [matroska-devel] Re: MPC DirectShow filter
In-Reply-To: <b1qr91$fuc$1@main.gmane.org>
References: <b1qr91$fuc$1@main.gmane.org>
Message-ID: <1044445480.3e40f92902711@imp.free.fr>


En r?ponse ? Ludovic Vialle <blacksun at corecodec.com>:

> 
> I know I'm on the wrong list, but I wanted to talk about The Core Media
> 
> Player. We're going to start a DirectShow filter for TCMP for MPC 
> playback, and we were wondering where we can get the latest SV8 decoding
> code to read/parse/play this new file format.
>
> Also is that possible to have some alpha/dev tools to encode to SV8 ? If
> we're fast enough we may be the first to player SV8 :)

Well, I'll make my best to help you on this. Frank already sent me some code but
I only had a quick look so far. I'm not even sure it covers SV8...

Anyway I want to be able to build a first decoder of SV8 ASAP. But I first have
to make the first alpha/beta version of libmatroska that can be used for a DShow
Filter and in VDubMod. It is now a matter of days (muxing should be done today,
then comes demuxing). There are still many things to do in libmatroska, ending
with the C API. (I'll finally make a FileKax class to handle the
creation/reading of MKx files more easily)

Who can I send the sources I have ?

BTW to be able to mux MPC in AVI (what people are probably waiting for) that
will also require a hack similar to MP3 or AC3 in VDubMod.
http://matroska.org


From steve.lhomme at free.fr  Wed Feb  5 12:57:26 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Wed, 05 Feb 2003 12:57:26 +0100 (CET)
Subject: [matroska-devel] Re: MPC DirectShow filter
Message-ID: <1044446246.3e40fc2630415@imp.free.fr>


En r?ponse ? Ludovic Vialle <blacksun at corecodec.com>:

> 
> Ah excellent :) If it don't take too much time, Matthias will certainly
> code it. He was a bit worried about the amount of C files and was 
> looking for a library which sound easier.
> I definitely want to support MPC as much as I can.
> 
> btw you guys are lurking there and waiting for new posts or what ? LOL

Yeah, and we're are tracing people too :D
Maybe we could have #mpc on IRC and discuss there about what need to be done (at
night for me and this week-end).

" <BlackSun> lurkers"
:)
http://matroska.org


From steve.lhomme at free.fr  Wed Feb  5 16:36:36 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Wed, 05 Feb 2003 16:36:36 +0100 (CET)
Subject: [matroska-devel] Re: [UCI-Devel] Project status
In-Reply-To: <20030205145912.GO3075@foogod.com>
References: <20030204110038.GC29095@foogod.com> <1044358498.3e3fa5625156f@imp.free.fr> <20030204132728.GD29095@foogod.com> <1044367736.3e3fc978ba0a7@imp.free.fr> <20030205082143.GA3075@foogod.com> <1044437429.3e40d9b5b54b0@imp.free.fr> <20030205130353.GH3075@foogod.com> <1044452546.3e4114c28c4c4@imp.free.fr> <20030205145912.GO3075@foogod.com>
Message-ID: <1044459396.3e412f84cb0ef@imp.free.fr>


En r?ponse ? alex at foogod.com:

> > You replace these numbers with timecodes, and you have exactly what I
> p=
> ropose
> > (and what is used in matroska).

(your mutt agent does really funky cuts ;)
 
> Umm, no, you don't.  Your timecodes provide no forward-looking
> informatio=
> n,
> which this method does.  You also need to have far more complexity to
> rep=
> resent
> multiple dependencies.

So you think that a frame with timecode 100 and a reference to timecode 20 and
one to timecode 150 doesn't give the direction to look for (backward/forward) ?

Why did I chose the timecode instead of a count reference ? Because if you lose
a frame in between your counter is fucked and all P or B frames are lost. While
with the timecode only the missing frame is lost (unless the missing one is an I
frame).

> > for the memory you mention. The memory dependency (1 or 2 frames

> Umm, no, you miss the point.  The question is where _are_ the 2 (or
> whate=
> ver)
> frames that need to be buffered.  Say you have a typical MPEG sequence

I was talking _only_ about the memory requirements. An unbounded system (like in
matroska) allows very complicated things to be done. But in the other hand you
usually need to know if you're going to be able to read a file or not. This can
be done with a flexible system with a note on the limitation or analysing all
references before playing to check wether it will be possible or not to read the
file (this can be done by checking the cue/seek entries).

*Where* is the data is handled in MCf/matroska by :
- cue/seek entries checking
- know the position of a past frame
- seek frames in the file until you find the one you need.

I see one limitation, you already mentioned, to these methods. If the forward
(future) frame is far ahead, you have to cache all the data in between if the
transport layer doesn't allow seeking back. That could lead to unlimited memory
use. In a real-world example, the memory necessary would be the same as for the
encoder (which have the same frame in memory when generating the references) (at
least when you deal with real time encoding).

I see 2 solutions to this problem :
- fix some maximum buffering on a track (like "the encoder is allowed to cache
2MB of frames before outputing the data")
- store the frames in encoding order :D which would be a radical change for
matroska and MCF, in the philosophies and the possibilities.

That would be possible to use encoding order in matroska... Keeping the
(timecode) references as they are. That means you would be able to have a frame
"in the past" after every frame (considering the frames already read), as long
as it references known frames.

The problem is to know when a frame is never referenced again in the stream (a
flexible system should allow overlapping of references). I can't think of any
good system for the moment... The 
http://matroska.org


From Paul at msn.com  Wed Feb  5 18:28:20 2003
From: Paul at msn.com (Pamel)
Date: Wed, 5 Feb 2003 11:28:20 -0600
Subject: [matroska-devel] Re: [UCI-Devel] Project status
References: <20030204110038.GC29095@foogod.com> <1044358498.3e3fa5625156f@imp.free.fr> <20030204132728.GD29095@foogod.com> <1044367736.3e3fc978ba0a7@imp.free.fr> <20030205082143.GA3075@foogod.com> <1044437429.3e40d9b5b54b0@imp.free.fr> <20030205130353.GH3075@foogod.com> <1044452546.3e4114c28c4c4@imp.free.fr> <20030205145912.GO3075@foogod.com> <1044459396.3e412f84cb0ef@imp.free.fr>
Message-ID: <b1rhfj$lm9$1@main.gmane.org>

"Steve Lhomme" <steve.lhomme at free.fr> wrote in message
> Why did I chose the timecode instead of a count reference ? Because if you
lose
> a frame in between your counter is fucked and all P or B frames are lost.
While
> with the timecode only the missing frame is lost (unless the missing one
is an I
> frame).

Steve,

What do you think about leaving the P and N frame timecodes as null when the
frame being referenced is the one immediately?

Also, are the Timecodes stored absolute to the stream, or are they still
using the Clusters relative timecode?


Pamel



http://matroska.org


From steve.lhomme at free.fr  Wed Feb  5 19:33:21 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Wed, 05 Feb 2003 19:33:21 +0100
Subject: [matroska-devel] Re: Project status
In-Reply-To: <b1ri9h$ob4$1@main.gmane.org>
References: <20030204110038.GC29095@foogod.com> <1044358498.3e3fa5625156f@imp.free.fr> <20030204132728.GD29095@foogod.com> <1044367736.3e3fc978ba0a7@imp.free.fr> <20030205082143.GA3075@foogod.com> <b1rdjk$21f$1@main.gmane.org> <20030205165105.GS3075@foogod.com> <b1ri9h$ob4$1@main.gmane.org>
Message-ID: <3E4158F1.7030303@free.fr>


Pamel wrote:
> In Matroska it doesn't particularly matter, because you can use either one.
> They would both be valid ways of storing the data because there isn't a
> requirement that the elements be in a particular order.  There was even talk
> of creating a tool that could 'optimize' a matroska file by ordering the
> elements in a way that would be fastest, or most useful.  So, a tool could
> be made to organize the elements in either coding or display order.
> 
> In practical use though I prefer display order.  As the complexity of codecs
> increase, in regards to frame referencing, coding order becomes less and
> less practical.  It is a small issue to buffer a few megabytes ahead for any
> current issues.  And for a truly limited memory player, the element order
> could be reordered.

Good idea. The "hinter" could use display ordering or coding ordering on 
the fly, depending on the target. But coding order will probably always 
give the same resuls... (speed, memory)

We just need to make it as flexible as we want matroska to be..

(I reply here because it's not UCI related at all)

http://matroska.org


From christian at matroska.org  Sat Feb  8 21:49:59 2003
From: christian at matroska.org (ChristianHJW)
Date: Sat, 8 Feb 2003 21:49:59 +0100
Subject: [matroska-devel] Re: container format
References: <200302050900.h15908OR029441@mail.mplayerhq.hu><200302051044.59036.michaelni@gmx.at><20030205164446.GP192@brightrain.aerifal.cx> <20030205165731.GS7414@bunkus.org>
Message-ID: <b23qdf$bs8$1@main.gmane.org>


"Moritz Bunkus" <moritz at bunkus.org> schrieb im Newsbeitrag
news:20030205165731.GS7414 at bunkus.org...
> I'd really like to see a new container format soon. So far I've told
> the Matroska people that I'd write Linux tools and MPlayer support for
> it,

So this is not valid anymore ? Please Moritz, inform me if you are not
interested in the job anymore , so i can search for somebody else making
Linux support for matroska.

> but unfortunately the very early code they have right now will be a
> pain in the a** to implement in MPlayer (without writing C++, but
> that's only one of the problems).

We are making a C API only for the mplayer/mencoder guys, as it seems the
complete rest of the world prefers C++, for whatever reason. As we are in
the middle of writing up things please contact us if you had any wishes in
this respect.

> If you put together some specs then I'll happily write ncfdbmptools
> (new container format developped by mplayer people ;)). I have
> experience with my ogmtools, and would love to continue working on
> container formats (somehow I like that. I lack most basic knowledge
> about video issues and compression issues, so container formats and
> (de)multiplexers are something I might be good at ;)).> Consider me 'on
board' if you're seriously planning on developping such
> a format.

You might want to disagree here, but if you expect your own Linux users to
use this format at all you should make a few suggestions about support on
Windows first. I am ready to get flamed, now, no problem, just keep it
coming. It wont change the facts. Not at all.

Christian



http://matroska.org


From moritz at bunkus.org  Sat Feb  8 22:40:48 2003
From: moritz at bunkus.org (Moritz Bunkus)
Date: Sat, 8 Feb 2003 22:40:48 +0100
Subject: [matroska-devel] Re: container format
In-Reply-To: <b23qdf$bs8$1@main.gmane.org>
References: <20030205165731.GS7414@bunkus.org> <b23qdf$bs8$1@main.gmane.org>
Message-ID: <20030208214048.GI26772@bunkus.org>


Hi.

> So this is not valid anymore ? Please Moritz, inform me if you are not
> interested in the job anymore , so i can search for somebody else making
> Linux support for matroska.

(I already replied to the mplayer-dev list, so here's my reply for this
list as well.)

No, I'll still implement Linux support for Matroska. At the moment the
current source is not usable with mplayer/mencoder because of at least
two things: lacking C interface and the fact that the example programs
do their own file handling. Once libmatroska has reached a 'more useful
state' (regarding my/mplayer's needs) I'll use it.

As for the other mails: I'm not so sure that both 'formats' want to
achieve the same thing. As far as I understand matroska wants to be
extendable, rather complete and the like. What the MPlayer guys want to
have is something simpler, more in the direction of Ogg, but with some
fundamental differences.

Now to the language used. I know that A'rpi and other MPlayer
developers are not the most friendly people in the world. But simply
telling someone that 'he sucks' will only inflame the situation. Be
prepared to receive a lot of flames, especially as you wrote it on
MPlayer's devel mailing list. This sucks, too.

Perhaps both formats will find their fans, perhaps only one will
survive. Who can tell? But diversity is a good thing IMHO, so I
personally hope that both will succeed.

And as I said - I will implement both 'external tools' as well as
a MPlayer demuxing module for Matroska. Just like I will develop tools
for that 'MPlayer container format'.

-- 
 ==> Ciao, Mosu (Moritz Bunkus)
http://matroska.org


From christian at matroska.org  Sat Feb  8 23:02:22 2003
From: christian at matroska.org (ChristianHJW)
Date: Sat, 8 Feb 2003 23:02:22 +0100
Subject: [matroska-devel] Re: container format
References: <20030205165731.GS7414@bunkus.org> <b23qdf$bs8$1@main.gmane.org> <20030208214048.GI26772@bunkus.org>
Message-ID: <b23ul7$nl0$1@main.gmane.org>


"Moritz Bunkus" <moritz at bunkus.org> schrieb im Newsbeitrag
news:20030208214048.GI26772 at bunkus.org...
> No, I'll still implement Linux support for Matroska. At the moment the
> current source is not usable with mplayer/mencoder because of at least
> two things: lacking C interface and the fact that the example programs
> do their own file handling. Once libmatroska has reached a 'more useful
> state' (regarding my/mplayer's needs) I'll use it.

Thanks Moritz

> As for the other mails: I'm not so sure that both 'formats' want to
> achieve the same thing. As far as I understand matroska wants to be
> extendable, rather complete and the like. What the MPlayer guys want to
> have is something simpler, more in the direction of Ogg, but with some
> fundamental differences.

What i still dont undertstand is what the need for an 'easy' format is. Easy
to code ? Well, thats why we made libmatroska, to make it easy to be
supported from any apps. We always promised to make a C API, and there will
be one.
Easy to parse ? Well, are their PCs so weak that they fear the impacts on
their CPUs when parsing matroska ?
Anyway, they are free to do what they want.

> Now to the language used. I know that A'rpi and other MPlayer
> developers are not the most friendly people in the world. But simply
> telling someone that 'he sucks' will only inflame the situation. Be
> prepared to receive a lot of flames, especially as you wrote it on
> MPlayer's devel mailing list. This sucks, too.

This is a public list, anybody can subscribe to it. If there wasnt gmane.org
and their NNTP interface, i would be subscribed also. I guess i do have the
right to defend my project if ii gets insulted. Maybe i am wrong here, i
dont know.

> Perhaps both formats will find their fans, perhaps only one will
> survive. Who can tell? But diversity is a good thing IMHO, so I
> personally hope that both will succeed.

I dont have a problem that they decide to make their own format, for sure.
Unlike Xiph people we are not planning to take over the opensource
audio/video world. What i do mind is that they are not fair with us.

> And as I said - I will implement both 'external tools' as well as
> a MPlayer demuxing module for Matroska. Just like I will develop tools
> for that 'MPlayer container format'.
>  ==> Ciao, Mosu (Moritz Bunkus)

Thanks :)



http://matroska.org


From steve.lhomme at free.fr  Sat Feb  8 23:16:56 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Sat, 08 Feb 2003 23:16:56 +0100
Subject: [matroska-devel] Re: container format
In-Reply-To: <b23ul7$nl0$1@main.gmane.org>
References: <20030205165731.GS7414@bunkus.org> <b23qdf$bs8$1@main.gmane.org> <20030208214048.GI26772@bunkus.org> <b23ul7$nl0$1@main.gmane.org>
Message-ID: <3E4581D8.10003@free.fr>


ChristianHJW wrote:
>>As for the other mails: I'm not so sure that both 'formats' want to
>>achieve the same thing. As far as I understand matroska wants to be
>>extendable, rather complete and the like. What the MPlayer guys want to
>>have is something simpler, more in the direction of Ogg, but with some
>>fundamental differences.
> 
> 
> What i still dont undertstand is what the need for an 'easy' format is. Easy
> to code ? Well, thats why we made libmatroska, to make it easy to be
> supported from any apps. We always promised to make a C API, and there will
> be one.
> Easy to parse ? Well, are their PCs so weak that they fear the impacts on
> their CPUs when parsing matroska ?
> Anyway, they are free to do what they want.

What I don't understand is how they managed to get some code from Apple, 
Real Networks or Microsoft to support Quicktime, RealMedia, ASF, AVI, 
etc... They gave them clean sources with a C API ?

We try to make our best to please people. And here is what we get...

If MPlayer can't stand any line of C++, then they can code the parser 
for matroska in C if they want. Because it's going to be there and 
supported in popular Windows apps (VirtualDub & DirectShow). So one way 
or another they'll have to support it.

http://matroska.org


From christian at matroska.org  Sun Feb  9 10:45:19 2003
From: christian at matroska.org (ChristianHJW)
Date: Sun, 9 Feb 2003 10:45:19 +0100
Subject: [matroska-devel] Re: container format
References: <20030205165731.GS7414@bunkus.org> <b23qdf$bs8$1@main.gmane.org> <20030208214048.GI26772@bunkus.org> <b23ul7$nl0$1@main.gmane.org> <3E4581D8.10003@free.fr>
Message-ID: <b257r4$j2o$1@main.gmane.org>


"Steve Lhomme" <steve.lhomme at free.fr> schrieb im Newsbeitrag
news:3E4581D8.10003 at free.fr...
> If MPlayer can't stand any line of C++, then they can code the parser
> for matroska in C if they want.

Actually, i was posting a job proposal on sourceforge.net asking for help to
port the EBML library to C, and i received an answer that i forwarded to you
and psyder already. Did you get in contact with the guy ? Maybe we will be
able to provide them with a nice C library one day.

Regards

Christian

P.S. Tell me if you lost the email, i can forward it again



http://matroska.org


From christian at matroska.org  Sat Feb  8 22:00:32 2003
From: christian at matroska.org (ChristianHJW)
Date: Sat, 8 Feb 2003 22:00:32 +0100
Subject: [matroska-devel] Re: container format
References: <200302050900.h15908OR029441@mail.mplayerhq.hu><20030205164446.GP192@brightrain.aerifal.cx><20030205165731.GS7414@bunkus.org> <200302061648.59370.michaelni@gmx.at>
Message-ID: <b23r17$dcp$1@main.gmane.org>


"Michael Niedermayer" <michaelni at gmx.at> schrieb im Newsbeitrag
news:200302061648.59370.michaelni at gmx.at...
> anyway, first draft of the MPlayer container format is in
DOCS/tech/mpcf.txt
> comments VERY welcome :)
> Michael

Strange. Really strange. When we invited developers here to comment on MCF
specs, Arpi chased us away telling we should shut up with our 'unfinished
crap'. Nobody here felt like he wanted to comment on anything we did, except
Albeu ( and many of his suggestions were implemented ).

But all of a sudden people come up with 'their own, much better' solution.

This sucks !!!

Its completey against the nature of opensource. Well, why do i even care to
comment. Do your own thing and eat it ...

ChristianHJW
http://matroska.org



http://matroska.org


From christian at matroska.org  Sat Feb  8 22:06:52 2003
From: christian at matroska.org (ChristianHJW)
Date: Sat, 8 Feb 2003 22:06:52 +0100
Subject: [matroska-devel] Re: container format
References: <200302050900.h15908OR029441@mail.mplayerhq.hu><20030205164446.GP192@brightrain.aerifal.cx><20030205165731.GS7414@bunkus.org> <200302061648.59370.michaelni@gmx.at> <20030206163954.GW192@brightrain.aerifal.cx>
Message-ID: <b23rd4$eh1$1@main.gmane.org>


"D Richard Felker III" <dalias at aerifal.cx> schrieb im Newsbeitrag
news:20030206163954.GW192 at brightrain.aerifal.cx...
> Excellent! Glad to hear that you're taking this plan seriously. It's
> also quite amusing that the Matroska and MCF people take months to put
> together a crappy spec, and that you put together something much
> better pretty much overnight. :))
> Rich

I dont know you Sir, but please allow me to tell you that is a sign of a
very immature character to judge about other people's work without even
having made the attempt to understand it properly.

You Sir, suck !! You suck badly !!

ChristianHJW
http://matroska.org



http://matroska.org


From christian at matroska.org  Sat Feb  8 22:28:00 2003
From: christian at matroska.org (ChristianHJW)
Date: Sat, 8 Feb 2003 22:28:00 +0100
Subject: [matroska-devel] Re: MPCF Draft/Discussion (MPlayer ContainerFormat)
References: <F48p0VatC6ZUbPHiNKy00018a3f@hotmail.com>
Message-ID: <b23sko$hub$1@main.gmane.org>


"michael c" <mrcole20 at hotmail.com> schrieb im Newsbeitrag
news:F48p0VatC6ZUbPHiNKy00018a3f at hotmail.com...
> I must say, I think I agree with Fabien that the file format should not
> close the door on advanced features. The only thing that should be kept in
> mind is that those features should not make everything over-complicated.
> I propose that there could be another stream type (named "generic" or
> something), in which additional features could then be implemented. Then,
if
> some programs don't support these features, these streams could simply be
> ignored; the programs don't even need to know anything about their format.


Excellent ! You guys are reinventing EBML right now, which is the basis of
matroska. This was exactly the purpose of it all, to be capable of adding
new element types without breaking file readability to 'simpler' or older
parsers.

ChristianHJW
http://matroska.org



http://matroska.org


From christian at matroska.org  Sat Feb  8 22:36:10 2003
From: christian at matroska.org (ChristianHJW)
Date: Sat, 8 Feb 2003 22:36:10 +0100
Subject: [matroska-devel] Re: MPCF Draft/Discussion (MPlayer ContainerFormat)
References: <F28QyyMNgqsDC2AgafP000041db@hotmail.com>
Message-ID: <b23t42$j9p$1@main.gmane.org>


"michael c" <mrcole20 at hotmail.com> schrieb im Newsbeitrag
news:F28QyyMNgqsDC2AgafP000041db at hotmail.com...
> i just think it would be a mistake to close the door on that. new features
> WILL be wanted sooner or later, it's always been like that :-) the format
IS
> supposed to be extensible and flexible after all, isn't it?
> mike

Thats why we introduced the 'overly complicated' EBML structure into
matroska, to make the format extensible for the future. EBML stands for
'Extensible Binary Meta Language'.

ChristianHJW
http://matroska.org



http://matroska.org


From christian at matroska.org  Sat Feb  8 22:47:51 2003
From: christian at matroska.org (ChristianHJW)
Date: Sat, 8 Feb 2003 22:47:51 +0100
Subject: [matroska-devel] Re: MPCF Draft/Discussion (MPlayerContainerFormat)
References: <b23sq6$ie7$1@main.gmane.org> <200302082145.h18LjLYR020873@mail.mplayerhq.hu>
Message-ID: <b23tpv$l5k$1@main.gmane.org>


"Arpi" <arpi at thot.banki.hu> schrieb im Newsbeitrag
news:200302082145.h18LjLYR020873 at mail.mplayerhq.hu...
> could you please stop sending these useless mails and either be technical
> and send constructive comments, or even better: facts against what we
think,
> or stop sending mail at all.

I'd love to send constructive comments, and even better, to state facts
against what you think about matroska.

Very unfortunately the only things i read about our container was that it
'sucks' , 'is overly complicated' , ' has crappy sepcs' and 'is not what you
need' . Its hard to reply with technical arguments against such statements,
would you agree ? If one of you could point us a bit more detailled where
you dont like our specs i will make sure that the matroska developers will
reply detailled why we made things the way we did them.

Again, Albeu's suggestions were golden for us, and most of his suggestions
led to matroska being what it is today. Note that he was critizing MCF specs
these days, not matroska specs. And yes, we find MCF specs also not really
perfect. At least we can judge about them, because we know them very well.

> sending 'you sir sucks badly' to each mplayer developer has no place here.
> we know mcf/matriska well enough, don't worry. it's just far from our
needs.
> A'rpi / Astral & ESP-team

I am sorry Arpi, but i honestly have doubts here, at least with respect to
matroska. Since the specs were done i avoided to copy this list here asking
for input, for wellknown reasons.

ChristianHJW
http://matroska.org



http://matroska.org


From christian at matroska.org  Sun Feb  9 07:04:28 2003
From: christian at matroska.org (ChristianHJW)
Date: Sun, 9 Feb 2003 07:04:28 +0100
Subject: [matroska-devel] Re: [MPlayer-users] Re: lavc-Options for*BEST*
References: <200302050900.h15908OR029441@mail.mplayerhq.hu><20030208231606.29cc0eb0.alex@naxine.org> <b24042$rke$1@main.gmane.org> <200302090030.38845.michaelni@gmx.at>
Message-ID: <b24qt3$qnf$1@main.gmane.org>


"Michael Niedermayer" <michaelni at gmx.at> schrieb im Newsbeitrag
news:200302090030.38845.michaelni at gmx.at...
> 1. matroska is much too complex
> c++ lib

Steve LHomme choose to use C++ because he felt that object based programming
is much better suited to code a container library, plus we wanted something
working fast and Steve was convinced he can code and maintain the code
faster if he used C++.
However, we already were posting a job proposal on sourceforge asking for
people wanting to help with porting the existing EBML code ( matroska
backbone ) to C, and i already have an email from a volunteer, so you may
expect a C version of the library also.
In the meantime i fail to see whats wrong about a C++ library with a C API.
After all we are doing the library to allow easy support of the format, at
least for the basic functions, so why should anybody *using the library*
care what language we were using to make it, other than making a political
question out of this.

> xml whatever?!
> float types?!

EBML is a binary form of XML, and the main idea was brought up in a
discussion between Steve and Frank Klemm, the author of MPC ( musepack )
audio codec, and certainly one of the brightest people in the whole
multimedia development scene. You will maybe have to invest more than just
one minute to fully understand the beauty of using it ( as i am not a coder
i am still struggling BTW ;) ), but pls. believe that many other developers
we talked to had the very same objections in the beginning, but changed
their mind after having talked to us.

The EBML structure is offering similar possibilities than the 'atoms' in
Mp4/Mov do offer. Allthough we are lucky to have codec developers being
subscribed to our lists and we get a lot of precious input about the
requirements for a container for the needs of tomorrows codecs, we still
dont know what the future will bring. EBML gives us the extensability to add
more elements to the container, without breaking backwards compatibility.

> i even see SHA1+MD5+RSA+eliptic stuff mentioned?! why?
> i would like to know whats the advantage of using these, it would
certainly
> mean a 5-10x amount of time needed to support these in some simple
> environments (embeded cpus with limited memory & slow cpu & no fpu,
perhaps
> with no available c++ compiler)
> there are many other formats (ogg,mpeg,avi,asf,nut :) ) which dont need
these
> so what can be done so much better with them?

All this stuff is not mandatory, but optional. The MD5 hash of block headers
could be used to 'sign' a file with a unique ID number, ideal to avoid fakes
on p2p networks, if the app developers choose to support this feature ( both
encoder and p2p app ).
Please note that we invested *A LOT OF TIME* into these specs to be able to
cover all potential use for the container.

> it contains fields for forw / bakw reference frames, thats nice, but h264
uses
> more then 2 reference frames, its allso not obvious why the container
format
> needs to store these, i have the feeling that storing b frames in this
will
> be very very complex, i hope iam wrong
> Michael

There were recent changes made to the matroska specs because of excellent
input from Nicolas ( the author of the Rududu wavelet based video codec ) to
the uci-devel list. These changes were not necessary to support today's
MPEG4 implementations, but if you plan to support future codecs like Toby
'GLDM' Hudon's *WARP* codec, that will load up to 256 frames into buffer and
perform a special, biomechanic inspired, wavelet based alog on those you
sure get into trouble with todays usage.

We want this container to last for 10 years. We dont want something 'nice
and easy' as a quick temporary solution, until the next bad hackery has to
be done, like what happened to AVI. After all i still dont understand what
the benefit of having an 'easy' container is. You as a developer may be
impressed by a container being 'easy' = 'less complex' = 'elegant to code' ,
but what are the users gaining by using it ? Do they have any benefits by
using such a container, when compared to matroska ? Our container is trying
to become a replacement for

VOB ( DVD )
WAV/RIFF
AVI

And we are still convinced we did a very good job in balancing out

- compexity
- features
- overhead
- extensability for future use

Sorry if you cant agree on this idea of ours and prefer more 'simple'
containers instead. After all, when reading all the ideas and suggestions
made to this list about your new container, i cant help but get a kind of
'deja vu' effect. Many of the stuff you are talking and discussing about
right now has been talked about more than one year ago .... on the MCF and
later matroska mailing lists.

Regards

ChristianHJW
http://matroska.org



http://matroska.org


From steve.lhomme at free.fr  Sun Feb  9 09:53:33 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Sun, 09 Feb 2003 09:53:33 +0100
Subject: [matroska-devel] Re: [MPlayer-users] Re: lavc-Options for   *BEST*
In-Reply-To: <200302090030.38845.michaelni@gmx.at>
References: <200302050900.h15908OR029441@mail.mplayerhq.hu>	<20030208231606.29cc0eb0.alex@naxine.org> <b24042$rke$1@main.gmane.org> <200302090030.38845.michaelni@gmx.at>
Message-ID: <3E46170D.2090301@free.fr>


Michael Niedermayer wrote:
> Hi
> 
> On Saturday 08 February 2003 23:27, Steve Lhomme wrote:
> 
>>Alex Beregszaszi wrote:
>>
>>>if mplayer is so simple and little, why do you bother us?
>>
>>I just want to point out that I do use MPlayer (on Mac OSX)...
>>
>>Anyway we joined the discussion because :
>>- it has been brought to our attention that our work was badmouthed for
>>no apparent reason
>>- we are curious about what solutions other people can come with
>>regarding containers
>>- from what I've read I assume you're just creating something very
>>similar to matroska, so you might like to avoid reinventing the wheel
>>and contribute an existing project
> 
> 1. matroska is much too complex
> 	c++ lib

I've noticed during all the threads on your container that the first 
critic about matroska is that the core library is coded in C++. While I 
understand some people prefer their own languages for various reasons (C 
and C++ are very compatible AFAIK), I don't think that's what should be 
considered first about a container.

I remember the discussions between MCF and MPlayer some time ago where 
the conclusion was "then in MPlayer we'll code our own MCF parser". 
That's fien with me, even for matroska.

> 	xml whatever?!

Actuallt I noticed that what we called EBML seem to be close if not 
identical to what you call VLC (or TLV). And this is really a kind of 
binary XML.

> 	float types?!

What's wrong with floats ?
There are not many floats in the format. But there are where it makes 
sense !

> 	i even see SHA1+MD5+RSA+eliptic stuff mentioned?! why?

It's inside the signature element. So the use seems to be quite obvious.
We'd also like to have encryption inside the format. But we are no 
expert in that field. So it's not in the specs for the moment.

> i would like to know whats the advantage of using these, it would certainly 
> mean a 5-10x amount of time needed to support these in some simple 
> environments (embeded cpus with limited memory & slow cpu & no fpu, perhaps 
> with no available c++ compiler)

You probably skipped the Profile part of the specs then...

> there are many other formats (ogg,mpeg,avi,asf,nut :) ) which dont need these 
> so what can be done so much better with them?

ASF doesn't have DRM features ?
OGG is looking to have some too (have a look for OGGs).
VOB does have some encryption.

> it contains fields for forw / bakw reference frames, thats nice, but h264 uses 
> more then 2 reference frames,

We allow 1000 (or more) references for a frame and even overlapping of 
references, backward and forward. You probably had a wrong look at how 
it's done.

 > its allso not obvious why the container format
> needs to store these, i have the feeling that storing b frames in this will 
> be very very complex, i hope iam wrong

We would like codecs to give these informations to the container 
(although it's not currently the case anywhere). Because that allows 
some kind of check, reorganising, optimising, cutting at the container 
level without needing any codec installed. OH ! And I think some people 
mentioned fast seeking in the format.

http://matroska.org


From steve.lhomme at free.fr  Sun Feb  9 10:03:04 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Sun, 09 Feb 2003 10:03:04 +0100
Subject: [matroska-devel] Re: [MPlayer-users] Re: lavc-Options for   *BEST*
In-Reply-To: <3E46170D.2090301__42575.606928631$1044780679@free.fr>
References: <200302050900.h15908OR029441@mail.mplayerhq.hu>	<20030208231606.29cc0eb0.alex@naxine.org> <b24042$rke$1@main.gmane.org>	<200302090030.38845.michaelni@gmx.at> <3E46170D.2090301__42575.606928631$1044780679@free.fr>
Message-ID: <3E461948.6020305@free.fr>


Steve Lhomme wrote:
>> i would like to know whats the advantage of using these, it would 
>> certainly mean a 5-10x amount of time needed to support these in some 
>> simple environments (embeded cpus with limited memory & slow cpu & no 
>> fpu, perhaps with no available c++ compiler)
> 
> 
> You probably skipped the Profile part of the specs then...

2 more things to add :
- I work in the embedded world (mobile phone) so believe me, I know the 
hard requirements there. I never planned to embed C++ in very small devices.
- As Frank Klemm said once, for a format to become an ISO standard 
(which is not our goal) there has to be 2 implementations to prove ti's 
working. We chose ours because it was the fastest/cleanest path. But I 
hope there will be other implementations later.

http://matroska.org


From christian at matroska.org  Sun Feb  9 12:27:14 2003
From: christian at matroska.org (ChristianHJW)
Date: Sun, 9 Feb 2003 12:27:14 +0100
Subject: [matroska-devel] Re: [MPlayer-users] Re: lavc-Options for *BEST*
References: <200302050900.h15908OR029441@mail.mplayerhq.hu><200302051044.59036.michaelni@gmx.at><20030205164446.GP192@brightrain.aerifal.cx><b23qli$che$1@main.gmane.org> <20030208231606.29cc0eb0.alex@naxine.org>
Message-ID: <b25dq7$vmv$1@main.gmane.org>


"Alex Beregszaszi" <alex at naxine.org> schrieb im Newsbeitrag
news:20030208231606.29cc0eb0.alex at naxine.org...
> > Why are you insulting us ?? Dont you have any form of respect for the
> > work and the labour of other people ?
> and why are _you_ insulting us?

I didnt insult anybody despite here on this list, maybe with the exception
of Mr. Richard D. Felker III. I herwith apologize for the insulting tone and
the rude words i was using. I twould be nice though if Mr. Felker could
decide to apologize also, for having repeatedly called our specs and project
being 'crap', apparently without knowing much more about some basics.

> don't start to flame please!

Again my sincere apologies, i had a hard week with both kids and the wife
being ill ( flu and diarrhoe together ), and had about 2 - 4 hours sleep per
night ( in an average ). Then, on the very first occasion where i had some
time to relax a bit and check the most important mailing lists i find the
project we all have been working on for about 2 years now being named like
'crap' 'too complex' , etc. . I overreacted in this situation.

> > libmatroska is ready by today, and its working already. Cyrius will
> > have support for matroska files in VirutaldubMod pretty soon now, and
> > the DShow parser is also being worked on right now.
> good luck with your project!

Thanks. There are a couple of people waiting for it to release working
Windows tools, mainly because there was no ( or not much ) support for OGM
lately. Yes, we hope it will be accepted by the users.

> > If you dont want menues or other features of matroska, well, dont put
> > some in. EBML will allow even simple players, like mplayer, to skip
> > all the elements you dont want to support.
> if mplayer is so simple and little, why do you bother us?

Sorry, misunderstanding. I thought from reading the comments from the people
here on this list that there is no interest in supporting menues and such,
so i guessed you like to keep things simple. I am well aware that mplayer is
the most successful Mediaplayer for the Linux world, and certainly a very
successful opensource project.
I didnt mean at all to belittle your project or tell untrue things about it.
Hopefully we can find back to a level of conversation between our,
admittedly very small, project and your very successful project, that is not
based on assumptions and mutual insulting.

Best regards

Christian
http://matroska.org



http://matroska.org


From christian at matroska.org  Sun Feb  9 23:23:59 2003
From: christian at matroska.org (ChristianHJW)
Date: Sun, 9 Feb 2003 23:23:59 +0100
Subject: [matroska-devel] Important decision about codec ID handling until UCI will be here
Message-ID: <b26k9j$mpq$1@main.gmane.org>

Hi,

i am opying this post to uci-devel so that Alex could comment if he wanted
to. Other copies go to Frank Klemm ( MPC developer ) and Blacksun from the
corecodec Team, who wants to make a MPC DShow filter, and the developers
coding en/decoding support for Windows ( Cyrius, kromyx ) and Linux (
Moritz ).

We have to make a decision about how to handle the codec IDs in matroska
files until we will be able to use UCI codec plugins ( no, i am NOT putting
pressure on you Alex, just stating facts ). Libmatroska in in a usable state
from today on, and both Cyrius and myFUN/kromyx are already working on
implementing the en/decoders for Windows, while Moritz will wait until we
have a working  C API for our lib ( fine with us ).

It seems the best way for the time being, at least for video and until we
still use VfW codecs ( even on Linux most encoders use FourCC ), was to use
the

V_MS/VFW/FOURCC

tag ( as defines here in this list :
http://www.corecodec.com/modules.php?op=modload&name=PNphpBB2&file=viewtopic
&t=227 ) and store the FourCC in the codec private data, as it was always
planned for the so-called 'AVI/VfW compatibility mode'.

However, this leaves a questionmark on the correct handling for the most
important audio codecs, namely

MP3
AC3
MPC
Vorbis

For the first 2 my clear vote goes to using the

A_MS/ACM

tag and to store the GUID for the audio format ( 0x2000 = AC3, 0x0055 =
MP3 ) again in the codec private data. This way we can easily call existing
DShow filters for playback of these streams, and on Linux it shouldnt cause
big probs for Moritz to call liba52 etc. according to GUID.

For Vorbis, i still refuse to think of calling Tobias Waldvogel's DirectShow
filter for playback on Windows. Also the GUID he was using is not confirmed
officially by Xiph still. We have the follwing options :

1. Hardcode Vorbis decoder into matroska parser ( as we dont have a UCI
plugin yet ), and use the correct Vorbis ID, being 'A_VORBIS' ( preferred
way IMHO )

2. Use 'A_MS/ACM' ID and use Tobias Waldvogels GUID to call his DShow filter
( least option IMHO )

3. Use 'A_VORBIS' but hardcode a conversion routine into the current
matroska parser, so it calls the DShow filter

4. Use Ingo Ralf Blums Media XW filter, wich includes support for FLAC and
Vorbis BTW, and use his GUIDs in the conversion routine

For MPC,

i am not 100% happy with the idea of BlackSun to make a DShow filter for it.
Sure, Frank could chose a GUID and this would be the official one. But i
somehow feel by doing so we would undermine our attempts to create matroska
( and same is valid for MCF also ) on a x-platform basis. I'd prefer
hardcoding MPC decoder support into matroska parser.

Please let me know your opinion on this very important question

Christian



http://matroska.org


From kimmo at poispakkoruotsi.com  Mon Feb 10 16:44:24 2003
From: kimmo at poispakkoruotsi.com (Kimmo)
Date: Mon, 10 Feb 2003 17:44:24 +0200
Subject: [matroska-devel] Re: Important decision about codec ID handling until UCI will be here
References: <b26k9j$mpq$1@main.gmane.org>
Message-ID: <02b101c2d11b$4f6fe2d0$0100a8c0@kimmo>



----- Original Message -----
From: "ChristianHJW" <christian at matroska.org>
To: <matroska-devel at freelists.org>
Cc: <uci-devel at lists.sourceforge.net>
Sent: Monday, February 10, 2003 12:23 AM
Subject: [matroska-devel] Important decision about codec ID handling until
UCI will be here


> Hi,
>
> i am opying this post to uci-devel so that Alex could comment if he wanted
> to. Other copies go to Frank Klemm ( MPC developer ) and Blacksun from the
> corecodec Team, who wants to make a MPC DShow filter, and the developers
> coding en/decoding support for Windows ( Cyrius, kromyx ) and Linux (
> Moritz ).

Have you yet made decisions about storing uncompressed PCM audio in
Matroska? For example, TV channels would like that option. And what about
storing MPEG-1 and MPEG-2 inside Matroska? It has surely better error
correction routines for example than these formats and it makes possible
using MPEG video compression and Vorbis audio for ex.


http://matroska.org


From chris at matroska.org  Mon Feb 10 22:15:31 2003
From: chris at matroska.org (Christian HJ Wiesner)
Date: Mon, 10 Feb 2003 22:15:31 +0100
Subject: [matroska-devel] Re: Important decision about codec ID handling until UCI will be here
References: <b26k9j$mpq$1@main.gmane.org> <02b101c2d11b$4f6fe2d0$0100a8c0@kimmo>
Message-ID: <001b01c2d149$8c0cebb0$6500a8c0@mahlo.de>



----- Original Message -----
From: "Kimmo" <kimmo at poispakkoruotsi.com>
To: <matroska-devel at freelists.org>
Sent: Monday, February 10, 2003 4:44 PM
Subject: [matroska-devel] Re: Important decision about codec ID handling
until UCI will be here
> Have you yet made decisions about storing uncompressed PCM audio in
> Matroska? For example, TV channels would like that option.

Sure, the ability to do this was one of the main reasons to start with
MCF/matroska development for robux4, as he is aiming to be able to mix large
PCM audio files in matroska capable mixing software. If you check the codec
ID list, there are already IDs for that.

> And what about
> storing MPEG-1 and MPEG-2 inside Matroska? It has surely better error
> correction routines for example than these formats and it makes possible
> using MPEG video compression and Vorbis audio for ex.

Its my main goal for the moment !! Unfortunately the MPEG container is quite
complex, and the only one who knows it very well and has a certain relation
to our project is Alex Stewart, the founder of UCI. Hopefully i will be able
to motivate other people to help us with this, as its not trivial at all. In
any case, matroska does have the flexibility to make it possible ;) !

Christian



http://matroska.org


From steve.lhomme at free.fr  Mon Feb 10 21:47:58 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Mon, 10 Feb 2003 21:47:58 +0100
Subject: [matroska-devel] Re: Important decision about codec ID handling until
 UCI will be here
In-Reply-To: <b26k9j$mpq$1@main.gmane.org>
References: <b26k9j$mpq$1@main.gmane.org>
Message-ID: <3E480FFE.60908@free.fr>


For the codec IDs/private data, we should progress step by step.
First we'll need ACM/VCM compatibility and we can have MPEG Audio 
compatibility in no time.

For MPEG Audio we have :
- MPEG AUDIO LAYER 1, no private data
- MPEG AUDIO LAYER 2, no private data
- MPEG AUDIO LAYER 3, no private data

I think it's better to distinguish them, as most decoders only handle 
one of them.

For ACM based codec :
- Microsoft ACM, the whole ACM structure (don't remember the name)

For VCM based codec :
- Microsoft VCM, the whole VCM structure (don't remember the name)

For DirectShow based audio codec :
- Microsoft DirectShow Audio, the whole structure used by DShow

For DirectShow based video codec :
- Microsoft DirectShow Video, the whole structure used by DShow

That should already cover a lot of things for the moment.

http://matroska.org


From christian at matroska.org  Mon Feb 10 23:52:52 2003
From: christian at matroska.org (ChristianHJW)
Date: Mon, 10 Feb 2003 23:52:52 +0100
Subject: [matroska-devel] Re: Important decision about codec ID handling until UCI will be here
References: <b26k9j$mpq$1@main.gmane.org> <3E480FFE.60908@free.fr>
Message-ID: <b29abn$358$1@main.gmane.org>


"Steve Lhomme" <steve.lhomme at free.fr> schrieb im Newsbeitrag
news:3E480FFE.60908 at free.fr...
>
> For the codec IDs/private data, we should progress step by step.
> First we'll need ACM/VCM compatibility and we can have MPEG Audio
> compatibility in no time.
> For MPEG Audio we have :
> - MPEG AUDIO LAYER 1, no private data
> - MPEG AUDIO LAYER 2, no private data
> - MPEG AUDIO LAYER 3, no private data

Steve, i somehow feel we should differentiate between VBR/ABR and CBR for
MPEG1/2 layer 2 and 3, as some apps/decoders may be able to handle both, and
some only CBR ?

Christian



http://matroska.org


From steve.lhomme at free.fr  Tue Feb 11 21:23:30 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Tue, 11 Feb 2003 21:23:30 +0100
Subject: [matroska-devel] Re: Important decision about codec ID handling
 until UCI will be here
In-Reply-To: <b29abn$358$1@main.gmane.org>
References: <b26k9j$mpq$1@main.gmane.org> <3E480FFE.60908@free.fr> <b29abn$358$1@main.gmane.org>
Message-ID: <3E495BC2.8090203@free.fr>


ChristianHJW wrote:
> "Steve Lhomme" <steve.lhomme at free.fr> schrieb im Newsbeitrag
> news:3E480FFE.60908 at free.fr...
> 
>>For the codec IDs/private data, we should progress step by step.
>>First we'll need ACM/VCM compatibility and we can have MPEG Audio
>>compatibility in no time.
>>For MPEG Audio we have :
>>- MPEG AUDIO LAYER 1, no private data
>>- MPEG AUDIO LAYER 2, no private data
>>- MPEG AUDIO LAYER 3, no private data
> 
> 
> Steve, i somehow feel we should differentiate between VBR/ABR and CBR for
> MPEG1/2 layer 2 and 3, as some apps/decoders may be able to handle both, and
> some only CBR ?

You expect this ancient stuff to support matroska file reading ?
Also there is no way for such players to know when a real MP3 is CBR or 
not, the situation won't change much with an additional container.


http://matroska.org


From kimmo at poispakkoruotsi.com  Wed Feb 12 08:15:16 2003
From: kimmo at poispakkoruotsi.com (Kimmo)
Date: Wed, 12 Feb 2003 09:15:16 +0200
Subject: [matroska-devel] Transforming OGM->Matroska
References: <b26k9j$mpq$1@main.gmane.org> <3E480FFE.60908@free.fr> <b29abn$358$1@main.gmane.org> <3E495BC2.8090203@free.fr>
Message-ID: <003c01c2d266$8289c7c0$0100a8c0@kimmo>


Anyone got to know how to make complete Matroska file from OGM file
containing Ogg chapters, XviD video, Ogg audio and SubRip subtitles?


http://matroska.org


From chris at wiesneronline.net  Wed Feb 12 09:20:41 2003
From: chris at wiesneronline.net (ChristianHJW)
Date: Wed, 12 Feb 2003 09:20:41 +0100
Subject: [matroska-devel] Re: Transforming OGM->Matroska
References: <b26k9j$mpq$1@main.gmane.org> <3E480FFE.60908@free.fr> <b29abn$358$1@main.gmane.org> <3E495BC2.8090203@free.fr> <003c01c2d266$8289c7c0$0100a8c0@kimmo>
Message-ID: <000c01c2d26f$a5755c50$a70aa8c0@mahlo.de>



----- Original Message -----
From: "Kimmo" <kimmo at poispakkoruotsi.com>
To: <matroska-devel at freelists.org>
Sent: Wednesday, February 12, 2003 8:15 AM
Subject: [matroska-devel] Transforming OGM->Matroska
> Anyone got to know how to make complete Matroska file from OGM file
> containing Ogg chapters, XviD video, Ogg audio and SubRip subtitles?


matroskadub ( = VirtualdubMod ) will be able to do this in one go, also
spyder was looking at a very easy Ogg2Matroska.exe for these conversions,
and i hope Jory will make a nice GUI for it

Christian

http://matroska.org


From chris at wiesneronline.net  Mon Feb 10 23:55:26 2003
From: chris at wiesneronline.net (Christian HJ Wiesner)
Date: Mon, 10 Feb 2003 23:55:26 +0100
Subject: [matroska-devel] Re: Porting EBML, the extensible binary meta language,  to C
In-Reply-To: <E18iJB2-0004kH-00@sc8-sf-web3.sourceforge.net>
References: <E18iJB2-0004kH-00@sc8-sf-web3.sourceforge.net>
Message-ID: <3E482DDE.2020102@wiesneronline.net>


Hi Santiago,

the whole project of porting libmatroska to C has become a new
importance as the people from mpalyer, one of the more important
mediaplayers for Linux environments, refuse to support matroska if we
dont have a working C API or a C wrapper for libmatroska. However,
porting the complete library to C was the preferred way of course. As
current lib is written in C++, was it possible for you to understand
that code or what you prefer to work based on the specs solely ?

Please note that we got a very nice offer from animesh (
talk2ani at yahoo.com ) to start looking into this, he has already
downloaded the existing sources. I would suggest that we ask him first
before brining you into this process, as he maybe prefers to work alone.

In any case, robux4, our chief developer, is the man managing it all.

If animesh prefers to work alone on porting it, please rest assured that
there is a huge number of very interesting tasks existing for our
project, so your help is mor than appreciated !! We even have an
existing Java code for an independant EBML implementation, done by
spyder ( see cc. ).

Please tell me what you think. animesh, what is your opinion ? Would you
prefer to work alone or agree to cooperate with Santiago on the porting ??

Maybe one of you could concentrate on the C API first ( so we can ask
mplayer people to support the format ) while the other starts porting
the whole lib ? Or does this make no sense at all ?

Please enlighten me :-)

ChristianHJW

Santiago Ortega wrote:

>Hi, my name is Santiago and I'm a CPE student. I'm 
>currently taking java 2 and I have some knowledge of C. I'm 
>looking to reinforce my skills in C and your project seems 
>very interesting. Let me know if I can be of any help.
>Chaoo!!!
>Santiago
>SDOG
>
>  
>


http://matroska.org


From talk2ani at yahoo.com  Tue Feb 11 08:48:51 2003
From: talk2ani at yahoo.com (Animesh)
Date: Mon, 10 Feb 2003 23:48:51 -0800 (PST)
Subject: [matroska-devel] Re: Porting EBML, the extensible binary meta language,  to C
In-Reply-To: <3E482DDE.2020102@wiesneronline.net>
Message-ID: <20030211074851.23671.qmail@web14107.mail.yahoo.com>


I wud be glad to. :-) Santiago, welcome to the team.. and lets get in touch fast.. lemme know where you are with the code,.. and wat wud be your preferred way of going with it... 
if u wud prefer not to spam the whole grp with discussions, you can always send individual mails.. tho i personally like projects where everyone knows wat is going on in each subparts of the projects (at least the important milestones).. it helps in developing the overall picture in your mind.. and any instant of time you know what stages of completion are the various subparts in .. but yes, flooding everyone inboxes with core internal details at each level of implementation might not really be a good idea.. lets keep that in mind.. and lets get in touch.. 
- Animesh.

 Christian HJ Wiesner <chris at wiesneronline.net> wrote:Hi Santiago,

the whole project of porting libmatroska to C has become a new
importance as the people from mpalyer, one of the more important
mediaplayers for Linux environments, refuse to support matroska if we
dont have a working C API or a C wrapper for libmatroska. However,
porting the complete library to C was the preferred way of course. As
current lib is written in C++, was it possible for you to understand
that code or what you prefer to work based on the specs solely ?

Please note that we got a very nice offer from animesh (
talk2ani at yahoo.com ) to start looking into this, he has already
downloaded the existing sources. I would suggest that we ask him first
before brining you into this process, as he maybe prefers to work alone.

In any case, robux4, our chief developer, is the man managing it all.

If animesh prefers to work alone on porting it, please rest assured that
there is a huge number of very interesting tasks existing for our
project, so your help is mor than appreciated !! We even have an
existing Java code for an independant EBML implementation, done by
spyder ( see cc. ).

Please tell me what you think. animesh, what is your opinion ? Would you
prefer to work alone or agree to cooperate with Santiago on the porting ??

Maybe one of you could concentrate on the C API first ( so we can ask
mplayer people to support the format ) while the other starts porting
the whole lib ? Or does this make no sense at all ?

Please enlighten me :-)

ChristianHJW

Santiago Ortega wrote:

>Hi, my name is Santiago and I'm a CPE student. I'm 
>currently taking java 2 and I have some knowledge of C. I'm 
>looking to reinforce my skills in C and your project seems 
>very interesting. Let me know if I can be of any help.
>Chaoo!!!
>Santiago
>SDOG
>
> 
>




---------------------------------
Do you Yahoo!?
Yahoo! Shopping - Send Flowers for Valentine's Day

http://matroska.org


From christian at matroska.org  Tue Feb 11 00:37:02 2003
From: christian at matroska.org (ChristianHJW)
Date: Tue, 11 Feb 2003 00:37:02 +0100
Subject: [matroska-devel] Help from MPEG container expert needed : MPEG1/2 implementation into new open standard matroska container
Message-ID: <b29cuh$esb$1@main.gmane.org>

Hi,

i am one of the project admins of matroska container format (
http://matroska.org ) and turning to these 2 MLs ( transcode.devel and
mjpeg.user ) searching for help.

We are in the process of releasing our basic file I/O lib called
*libmatroska*, and plan to be able to release a first set of file creation
tools ( based on virtualdub ), including a DShow based parser, for Windows
within the next 4 - 5 weeks. Linux support is next on our list, we are
talking to some people from mplayer and gstreamer for playback support
already and Moritz Bunkus promised to make a muxer program for Linux
accepting AVIs, Oggs and other formats as input. Our main developer is
planning to create some Mac OsX tools also, and we have good contact with
the Open BeOS world also.

One of our major goals was and is to be able to support MPEG1 and MPEG2
video streams to be muxed into our container ( besides all existing VfW
codecs of course ), together with any possible audio stream. While some of
you may fail to see the sense in using an existing MPEG2 video stream with
an AAC or Vorbis audio stream and USF subtitles at first, please rest
assured that many potential users of the container confirmed they had good
use for that. As a side result we would like to be able to pack a complete
DVD into one, self containing matroska file, incuding chapters, menues,
AC3/MP2 audio tracks, subtitle streams and MP2 video streams.

We were looking at MPEG container already together with the admins of UCI
( http://uci.sf.net a universal codec API ) , but cant yet decide on what
levels we could drop ( and use matroska's own facilities replacing them to
contain the information ), what levels to copy together with the data and
what levels could be transformed into corresponding matroska elements.
Adding such elements is pretty simple in matroska, thanks to its EBML
backbone ( http://ebml.sf.net ), a kind of binary XML that was developed for
matroska and is a project of its own now. We choose this design ( not
everybody seems to like it ) to ensure matroska can be used for the next 10
years, without any major hacks or changes to the basic specs, just by adding
new elements if necessary ( this is a bit similar to 'atoms' in MP4
container ).

Obviously we would like to avoid to have to change the main library soon
after we released it, to be able to support MPEG1/2 video. As a result, we
would very much appreciate to get some input from the MPEG container experts
here, helping us to decide how we could best mux MPEG video into matroska,
with

- minimum overhead
- high error recovery
- fast seeking
etc.

Please, if you reply to this post make sure the matroska-devel at
freelists.org  list is copied also. Also pls. be patient if anything i said
doesnt make sense from a technical point of view, i am just an organizer and
may have expressed things technically incorrectly.

Thanks in advance for your help in any case

ChristianHJW
http://matroska.org



http://matroska.org


From vshved at logistic-systems.com  Tue Feb 11 01:17:02 2003
From: vshved at logistic-systems.com (Vladimir Shved)
Date: Mon, 10 Feb 2003 17:17:02 -0700
Subject: [matroska-devel] Re: [Mjpeg-users] Help from MPEG container expert needed : MPEG1/
	2 implementation into new open standard matroska container
Message-ID: <D56B01B8EAA2F0448C873830CB77230E0333A5D7@rearadmiral.logistics.int>

I think, someone misspelled "matroska", it should be "matreshka" or at least
would sound/look better to its true meaning . I think you guys trying to
make the name refer to russian "doll-in-the-doll" toy/souvenir but currently
the name seems to refer to sailor girl in funy way ..:) as "matros" would be
the sailor and "matroska" a sailor girl?


http://matroska.org


From christian at matroska.org  Tue Feb 11 05:48:42 2003
From: christian at matroska.org (Christian HJ Wiesner)
Date: Tue, 11 Feb 2003 05:48:42 +0100
Subject: [matroska-devel] Re: [Mjpeg-users] Help from MPEG container expert needed : MPEG1/
   2 implementation into new open standard matroska container
In-Reply-To: <D56B01B8EAA2F0448C873830CB77230E0333A5D7@rearadmiral.logistics.int>
References: <D56B01B8EAA2F0448C873830CB77230E0333A5D7@rearadmiral.logistics.int>
Message-ID: <3E4880AA.9070308@matroska.org>




Vladimir Shved wrote:
> I think, someone misspelled "matroska", it should be "matreshka" or at least
> would sound/look better to its true meaning . I think you guys trying to
> make the name refer to russian "doll-in-the-doll" toy/souvenir but currently
> the name seems to refer to sailor girl in funy way ..:) as "matros" would be
> the sailor and "matroska" a sailor girl?

Yes,

we know the right pronouncation was 'matryoshka' , but we felt this word 
was much too hard to pronounce ( especially for our English speaking 
people ;) ) so we modified the name to make it an artificial, new one, 
but ressembling the original russian dolls. We had no idea this new word 
had a 'real' meaning also, until we were told from russian speaking 
people ... lol !
If you go looking on our homepage you will find the correct russian 
spelling also :)

Christian

http://matroska.org


From Paul at msn.com  Tue Feb 11 06:43:55 2003
From: Paul at msn.com (Pamel)
Date: Mon, 10 Feb 2003 23:43:55 -0600
Subject: [matroska-devel] Re: [Mjpeg-users] Help from MPEG container expert needed : MPEG1/2 implementation into new open standard matroska container
References: <D56B01B8EAA2F0448C873830CB77230E0333A5D7@rearadmiral.logistics.int>
Message-ID: <b2a2ec$o7k$1@main.gmane.org>

"Vladimir Shved" <vshved at logistic-systems.com> wrote
> I think, someone misspelled "matroska", it should be "matreshka" or at
least
> would sound/look better to its true meaning . I think you guys trying to
> make the name refer to russian "doll-in-the-doll" toy/souvenir but
currently
> the name seems to refer to sailor girl in funy way ..:) as "matros" would
be
> the sailor and "matroska" a sailor girl?

It is indeed supposed to be the  russian "doll-in-the-doll", however the
native spelling was quite difficult to use, as were 'more correct'
translitirations.  'Matroska' was eventually settled on because of the
simplicity, however the actual russian spelling is shown at
http://www.matroska.org .  It is interesting that many people have related
similarities between the word 'matroska' and words in their native language.
While english has nothing close, many other languages have words with a
variety of meanings.


Pamel



http://matroska.org


From chris at matroska.org  Tue Feb 11 06:16:40 2003
From: chris at matroska.org (Christian HJ Wiesner)
Date: Tue, 11 Feb 2003 06:16:40 +0100
Subject: [matroska-devel] Re: matroska : HTTP/FTP streaming server 
References: <E18iP9H-0001hz-00@sc8-sf-web1.sourceforge.net>
Message-ID: <005101c2d18c$c2cf0910$6500a8c0@mahlo.de>


Hi How Tam,

can you please tell us quickly what your background in programming is (
languages, education, experiences ) ?

The task you were applying to is certainly the hardest amongst all those i
was posting on sourceforge, but i agree its also one of the most exciting
things we plan to do :-D !! Do you have any background in setting up
streaming solutions for media already ?

We would gladly welcome you in our small team in any case, there is a lot of
work to do still to be able to establish matroska as the new open standard
media container format, and even if we decided together that the streaming
server solution would not be the right thing for you to do alone, i am 100%
certain we could find a task for you that could catch your interest
immediately.

Thanks in advance for telling us a bit more about your coding background. We
are very glad you are offering to help us and become a team member !

Best regards

Christian

P.S. Please tell me your sourceforge nickname, so i could add you to the
developers list once we agreed on a task. Also, please go to
http://freelists.org and subscribe to our 3 mailing lists, all starting with
the word 'matroska'. As an alternative you may use the NNTP interface on
gmane.org , news://news.gmane.org ; gmane.comp.multimedia.matroska.xyz ,
works in both directions ( reading and posting ) and is a great archive
also.

----- Original Message -----
From: "How Tam" <howtam at users.sourceforge.net>
To: <christianhjw at users.sourceforge.net>
Cc: <howtam at users.sourceforge.net>
Sent: Tuesday, February 11, 2003 2:23 AM
Subject: RE: matroska : HTTP/FTP streaming server


>
> Hello,
>
> My name is How Tam.  My id is howtam.
>
> I am looking for something to do with open source and came
> across your help wanted ad.  I am interested in the position.
> Could you tell me more about this project ?  Thanks.
>
> How Tam

http://matroska.org


From christian at matroska.org  Tue Feb 11 16:11:41 2003
From: christian at matroska.org (Christian HJ Wiesner)
Date: Tue, 11 Feb 2003 16:11:41 +0100
Subject: [matroska-devel] New ideas for mode2 form2
Message-ID: <00b701c2d1df$e2982850$a70aa8c0@mahlo.de>

To : DeXT
To : matroska-devel at freelists.org
cc. Koepi
cc : avih ( DeXT pls forward, i guess i have no valid email addy from avi )


Hi DeXT,

we havent heard from you for a while, so im dropping you this email, copied to matroska-devel, Koepi and avih .

Our team member spyder is currently working hard on some technical docs explaining matroska for a technically interested user, not a developer capable of reading the specs. After he has finished that he told me he will get bored to death and needs a new tool to play with :D ! So, we are talking to you to find out what he could do.

You are maybe aware that libmatroska is in a usable state by now, and both Cyrius and myFUN are working hard to get the first alpha tools for Windows out of the door, of course we will test them in a very small alpha test circle first before making a public beta release. There are still some key features missing in the lib, like FileKax and MetaSeek/Cue, and this will take some more weeks probably, depending on robux4' motivation to code :D !

While this is still going on i am trying to plan the next steps already, and you know that mode2 form2 support is very high on my list, as i consider it a key feature for matroska. Hopefully you will remember our conversation on IRC lately, when we told you that we came up with a nice idea of making matroska even better for mode2 form2 than our original plans were. This idea is basically to create an intelligent tool that will add several EDC and ECC elements to the matroska file, giving special protection to the most important elements of the file like

- main header
- indexes ( MetaSeek, seek entries, spread all over the file )
- track headers
- block headers
etc.

That way a file being 785 MB in size could be 'pumped up' to 795 MB ( or any other file size the user feels he can burn safely with his burner ), adding 10 MB of additional CRC checksums of all important parts listed above. Of course, this would increase overhead significantly, but give a lof of extra protection to the file, using the available disc space in the very best way. Matroska's structure, being EBML based, allows to do so easily without breaking file compatibility with a lot of devices, including hardware units ( one day ;-) ). On playback, the matroska parser will simply ignore these extra elements normally, they could only become important once the file cant be played anymore. In this case a 'file repair' tool can be used to recreate the missing information, so the user can burn it again and enjoy it as a fully functional movie. Alternatively we could think of adding a special option to the matroskaparser, such that when you have a strong PC the existing CRCs can 
 be used on playback also.

Now, my question to you was :

- The resulting matroska file should be directly compatible with Mode2CD creator, as for you its a 'normal' file, with all the protection added to the file itself in special elements. My concerns now are, how would we handle matroska files with respect to the extra safety you will build in by writing the first 64 kb of every file into a separate mode2 form 1 track ? Is this necessary at all or could we drop that for matroska ? Would you recommend to do that in any case, to achieve extra safety ?

- Could you consider to add our code to your tool later, such that the 'conversion' from a normal matroska file to an 'extra safety' file could be done inside Mode2CD creator directly ? Note that you will need to add libmatroska to your tool to be able to do that, so this might have a serious impact on file size for distribution from your server. Alternatively we could make this ' mode2 burning preparation' process in our file repair tool ( spyder's job :D ), so the user had to use 2 different tools to create a mode2 matroska CD.

Please tell me your opinion on that, and dont forget to copy the list also ( reply-all button ;) )

ChristianHJW

http://matroska.org


From steve.lhomme at free.fr  Tue Feb 11 16:46:06 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Tue, 11 Feb 2003 16:46:06 +0100 (CET)
Subject: [matroska-devel] Re: New ideas for mode2 form2
In-Reply-To: <00b701c2d1df$e2982850$a70aa8c0@mahlo.de>
References: <00b701c2d1df$e2982850$a70aa8c0@mahlo.de>
Message-ID: <1044978366.3e491abe8562e@imp.free.fr>


En r?ponse ? Christian HJ Wiesner <christian at matroska.org>:

> You are maybe aware that libmatroska is in a usable state by now, and
> both Cyrius and myFUN are working hard to get the first alpha tools for
> Windows out of the door, of course we will test them in a very small
> alpha test circle first before making a public beta release. There are
> still some key features missing in the lib, like FileKax and
> MetaSeek/Cue, and this will take some more weeks probably, depending on
> robux4' motivation to code :D !

Could we keep a list somewhere of what needs to be done, what apps we'd like to
get developped and give some priorities ? I think we can do that in SF.
http://matroska.org


From avihpit at yahoo.com  Tue Feb 11 23:38:54 2003
From: avihpit at yahoo.com (avi h)
Date: Tue, 11 Feb 2003 14:38:54 -0800 (PST)
Subject: [matroska-devel] Re: New ideas for mode2 form2
In-Reply-To: <00b701c2d1df$e2982850$a70aa8c0@mahlo.de>
Message-ID: <20030211223854.12583.qmail@web10802.mail.yahoo.com>



--- Christian HJ Wiesner <christian at matroska.org> wrote:
> To : DeXT
> To : matroska-devel at freelists.org
> cc. Koepi
> cc : avih ( DeXT pls forward, i guess i have no valid email addy from avi )

got it ok ;)

> 
> 
> Hi DeXT,
> 
> we havent heard from you for a while, so im dropping you this email, copied
> to matroska-devel, Koepi and avih .
> 
> Our team member spyder is currently working hard on some technical docs
> explaining matroska for a technically interested user, not a developer
> capable of reading the specs. After he has finished that he told me he will
> get bored to death and needs a new tool to play with :D ! So, we are talking
> to you to find out what he could do.

great. he could carry on the backup support of xcd. shouldn't take more than a
day or two for a motivated programmer ;) no dshow or other propriatry knoledge
needed. just some common sense c++. i swear ;)


> 
> You are maybe aware that libmatroska is in a usable state by now, and both
> Cyrius and myFUN are working hard to get the first alpha tools for Windows
> out of the door, of course we will test them in a very small alpha test
> circle first before making a public beta release. There are still some key
> features missing in the lib, like FileKax and MetaSeek/Cue, and this will
> take some more weeks probably, depending on robux4' motivation to code :D !
> 
> While this is still going on i am trying to plan the next steps already, and
> you know that mode2 form2 support is very high on my list, as i consider it a
> key feature for matroska. Hopefully you will remember our conversation on IRC
> lately, when we told you that we came up with a nice idea of making matroska
> even better for mode2 form2 than our original plans were. This idea is
> basically to create an intelligent tool that will add several EDC and ECC
> elements to the matroska file, giving special protection to the most
> important elements of the file like
> 
> - main header
> - indexes ( MetaSeek, seek entries, spread all over the file )
> - track headers
> - block headers
> etc.
> 
> That way a file being 785 MB in size could be 'pumped up' to 795 MB ( or any
> other file size the user feels he can burn safely with his burner ), adding
> 10 MB of additional CRC checksums of all important parts listed above. Of
> course, this would increase overhead significantly, but give a lof of extra
> protection to the file, using the available disc space in the very best way.
> Matroska's structure, being EBML based, allows to do so easily without
> breaking file compatibility with a lot of devices, including hardware units (
> one day ;-) ). On playback, the matroska parser will simply ignore these
> extra elements normally, they could only become important once the file cant
> be played anymore. In this case a 'file repair' tool can be used to recreate
> the missing information, so the user can burn it again and enjoy it as a
> fully functional movie. Alternatively we could think of adding a special
> option to the matroskaparser, such that when you have a strong PC the
> existing CRCs can be used on playback also.

sounds fine so far.

> 
> Now, my question to you was :
> 
> - The resulting matroska file should be directly compatible with Mode2CD
> creator, as for you its a 'normal' file, with all the protection added to the
> file itself in special elements. My concerns now are, how would we handle
> matroska files with respect to the extra safety you will build in by writing
> the first 64 kb of every file into a separate mode2 form 1 track ? Is this
> necessary at all or could we drop that for matroska ? Would you recommend to
> do that in any case, to achieve extra safety ?

should pose no problem at all. only the DEFAULT protection scheme will protect
the 1st 64k of the file. but it should be a matter of hours to add support for
any file/protection scheme (for someone who KNOWS what's needed to get
protected). that what i was last working on, a general api and implementation
for adding protection in any combination.

> 
> - Could you consider to add our code to your tool later, such that the
> 'conversion' from a normal matroska file to an 'extra safety' file could be
> done inside Mode2CD creator directly ?

when the xcd back api is ready (motivated programmer...) anyone could add it. i
see no problem in moving this code to the xcd sourceforge code.

 Note that you will need to add
> libmatroska to your tool to be able to do that, so this might have a serious
> impact on file size for distribution from your server. Alternatively we could
> make this ' mode2 burning preparation' process in our file repair tool (
> spyder's job :D ), so the user had to use 2 different tools to create a mode2
> matroska CD.
> 
> Please tell me your opinion on that, and dont forget to copy the list also (
> reply-all button ;) )
> 
> ChristianHJW
> 

the general process of the backup:
two files are created:
file #1:<xyz>.dat the actual mode2form2 file (the complete file.. no ecc).
file #2:<xyz>.xch headers and backups for the file.

all the backup stuff goes into file#2, with the help of xvid api. some sort of
plugin (atm, only piece of code) should be added to tell which parts need
backup, and the xcdlib will build file#2 correctly.

just one point to take into account. according to the latest xcd spec, every
separate backup section will create an overhead of 24 bytes (iirc), so backing
up every other byte i.e. (not sequencial) will impose a HUGE overhead. i.e. for
100 separate backup sections the beackup overhead (regardless of the total
backed up bytes) will be 2.3K.

cheers ppl ;)
avih



__________________________________________________
Do you Yahoo!?
Yahoo! Shopping - Send Flowers for Valentine's Day
http://shopping.yahoo.com
http://matroska.org


From christian at matroska.org  Tue Feb 11 16:27:59 2003
From: christian at matroska.org (Christian HJ Wiesner)
Date: Tue, 11 Feb 2003 16:27:59 +0100
Subject: [matroska-devel] Awareness of matroska parser to CRC elements in the file
Message-ID: <00c201c2d1e2$297283e0$a70aa8c0@mahlo.de>

Hi myFUN,

the bashing from the mplayer people onto matroska maybe has a positive side effect as they were pointing us to something we have to clarify :

How should the matroska parser react if it detects a EDC failure ? Stop playing ? Ignore it and go on playing ? Make this decision based on the error tolerance capability of the codec ?

Same thing goes for the special protection elements we are planning to implement to support mode2 form 2 burning better. Generally spekaing i am voting to simply ignore any CRC mismatches ( if the library allows to do so of course !! ) by default in this respect, to save CPU power on playback, but we may well think about an option to enable this feature to allow watching even of heavily scratched CDs if one's PC is powerful enough to handle all the additional EDC/ECC.

What do you say ?

Christian

http://matroska.org


From christian.hj.wiesner at web.de  Wed Feb 12 00:15:34 2003
From: christian.hj.wiesner at web.de (Christian HJ Wiesner)
Date: Wed, 12 Feb 2003 00:15:34 +0100
Subject: [matroska-devel] Re: matroska : HTTP/FTP streaming server
In-Reply-To: <20030211165859.53270.qmail@web40710.mail.yahoo.com>
References: <20030211165859.53270.qmail@web40710.mail.yahoo.com>
Message-ID: <3E498416.4080801@web.de>


How Tam,

wow, your experience is impressive. If anybody can handle this task its 
you, for sure.

Can you visit us on irc.corecodec.com #matroska by time ? What timezone 
are you in ?

You have access to CVS on sf.net for libmatroska code, i will search for 
the existing threads about streaming servers in our mailing list library 
and point you to there. robux4, our chief developer, is the man to talk 
to in all aspects.

Have you ever heard of Icecast , Xiph's Http streaming server ? ( 
http://www.xiph.org ) ?? Although this is a kind of 'competing' project 
it may be worth looking at their sources first.

Best regards

Christian

How Tam wrote:
> Christian,
> 
> Thanks for your reply.  I have 6 years of C++
> experience.  I also used Perl and Java occasionally. 
> I have been working in financial industry.  My work is
> most on the server side.  Socket level and
> multithread.  Before that I worked for an internet
> provider called PSI.  So I was involved in TCP/IP very
> heavily.  I have BS degree in math and MS degree in
> computer.
> 
> Look forward to your reply.
> 
> How Tam

http://matroska.org


From chris at wiesneronline.net  Thu Feb 13 17:01:32 2003
From: chris at wiesneronline.net (ChristianHJW)
Date: Thu, 13 Feb 2003 17:01:32 +0100
Subject: [matroska-devel] Re: Porting EBML, the extensible binary meta language, to C 
References: <E18jL7C-00053s-00@sc8-sf-web2.sourceforge.net>
Message-ID: <00a101c2d379$2eec8030$a70aa8c0@mahlo.de>


Hi shailesh,

i was just posting a huge reply email to all the people that were adressing
us in the last few days, as a reaction to my job proposals. Here the email,
attached to the very end of this message :

----- Original Message -----
From: "Shailesh Mistry" <slmistry at users.sourceforge.net>
To: <christianhjw at users.sourceforge.net>
Cc: <slmistry at users.sourceforge.net>
Sent: Thursday, February 13, 2003 4:17 PM
Subject: RE: Porting EBML, the extensible binary meta language, to C
> I saw your message looking for developers to port the
> code to C.
> Please can you tell me what the aim of the project is and
> what it is you need help with.
> Thanks.  Shailesh

Thanks for your offer to help. While for a very long time we got almost no
offers from anybody for help, we are now in the happy situation to get
several replies at the same time :-) !! As this is a very new situation for
us, we first have to define how to split the work into several pieces. The
very project you have been applying to, means to port the complete existing
C++ library to plain C, is being looked at from the 2 gentlemen i copied on
this email, animesh and santiago .

The aim of this project is to create an opensource, open standard multimedia
container format. We hope that our container will replace the old, outdated
AVI format, created by Microsoft in the 80s, but abandoned for their own ASF
streaming container, developed as a closed format allowing to implement DRM
( Digital Rights Management ). We put a lot of energy into the specs to make
sure our container is a real alternative to other existing media containers,
like MP4, MOV, RM, MPEG and Ogg. More information can be found on our
homepage http://matroska.org .

I hope animesh will find the time to report to the matroska mailing list
matroska-devel at freelists.org what his first impression is after having
looked at the code, if he sees any chances to port the library in an elegant
way, or if its better to think of a C wrapper, or only to create a basic C
API for it, alowing playback ( demuxing ) and not more. In any case it
should be possible to share the workload between you guys, if you are
interested to do so. If not, then i hope you can find some other jobs that
are posted in the email below, hopefully one of those will catch your
interest.

animesh, can you please copy shailesh and santiago if you are sending such a
first statement to the list, as i dont think they are subscribed to it yet ?

Best regards

My email from this afternoon to the new team members :

.................................
Hi all,

  all of you that are copied on this email have been adressing us recently
about joining our team. Our team members are currently

  Steve 'robux4' LHomme ; chief developer and project admin
  John 'spyder' Cannon ; Java wizzard and main contributor
  Jean 'Cyrius' Colon ; VirtualdubMod and matroskadub developer
  Jan 'myFUN/kromyx' Schlenker ; matroska DShow parser developer
  Frank Klemm ; MPC ( musepack ) developer, a high quality audio codec
  Paul 'Pamel' Bryson ; XML consultant, PR assistant
  Jory 'jcsston' ; VB developer, GUI creator
  Moritz 'mosu' Bunkus ; developer of the OGM merge tools, mplayer developer
  Christian 'HJ' Wiesner ; General helper, Content writer, PR , project
admin

  Contributors are ( some more, some less :) ):

  Ludovic 'Blacksun' Vialle ; Developer of 'The Core Media Player' ,
DirectShow consultant
  Dan 'Betaboy' Marlin ; Corecodec Community Leader ( soon our host )
  Tobias 'Belgabor' Minich ; VirtualdubMod project admin
  'raghav' Ragavendran ; MPC2matroska.exe
  Radek 'sysKin' ; XviD developer
  Milan Cutka ; developer of ffdshow DShow filter
  Ronald 'BBB' Bultje ; Gstreamer developer


  Please allow me to welcome you all in the name of the matroska team
members and the administrators. We are a very small team and the last 2
years were not easy for us, as we were using another approach to making
matroska than its normally happening in
 the opensource world. Instead of just releasing some basic code and then to
evaluate from there we wanted to

  - get as many input as possible from all the wise people in multimedia out
there
  - make a proper spec and document it properly in a doxygen Format
  - start coding the library and the tools

  As you may imagine its hard to do it that way, as people are normally not
at all interested in something they cant get their hands on yet. Most
projects in multimedia opensource development are driven by making crazy
patches quickly, so that new funct
ionalities are added and can be used instantaneously. Of course, doing it
that way is a very risky thing as you may find yourself in a situation soon
where you have to make 'hacks' to achieve certain things. We wanted to avoid
this by all means, so we t
ook the long, winding road of trying to motivate people to look at what we
have, listen to their comments and suggestions and improve from there.

  The main input on the specs as you find them today have been done from
those people :

  Lasse 'Tronic' Karkainen ; Founder of TMF that evolved into MCF, our
'sister' project ( http://mcf.sf.net ) ; matroska was born in a project fork
from MCF as lasse couldnt not identify with the EBML specs Steve did
  Ingo Ralf Blum ; Developer of the MediaXW framework, DirectShow wizzard
  Frank Klemm ; see above
  Alex 'Foogod' Stewart ; project admin of UCI, the Universal Codec
Interface, one of the backbones of matroska and MCF ( http://uci.sf.net )
  Alban 'albeu' Bedel ; mplayer developer
  ( I hope i didnt miss anybody :)  )



There are a number of things on our to-do list now :

1. Move the complete project from sourceforge.net to the new corecodec.org
opensource platform, being dedicated for audio and video compression. Other
projects to be hosted there ( to start with ) will be :
- MPC ( musepack ) audio codec
- USF : Universal Subtitle Format
- WARP : a new, wavelet based video codec, offering a lossless mode also
- COREYUV : a lossless video codec project based on HuffYuv, but with a few
goodies added
and hopefully many many more

This moving is the main reason why i dont start to create specific jobs on
sourceforge.net as of now, as i would have to redo it all for the new
project on corecodec.

2. Overwork our webpage :

John 'spyder' Cannon is currently writing up a document that is aiming to
explain a few things about matroska, for the technically interested user. In
addition to that we want to add the follwoing pages :

- matroska Team ( contact details )
- supported codecs ( plans, actual status, ongoing development )
- software supporting matroska ( links, status, ongoing development )
- Codec ID list ( specs addition ? )
- technical explanation of UCI, EBML, USF, etc.
- webdesign of homepage
- link to forums and description of Corecodec and its mission
etc.


3. Create a logo :

As i was posting already on the job proposal on sourceforge, our current
idea is to bind the Russian dolls into the logo, as they ( in one way or
another ) were the name givers. It will be necessary to meet on our IRC
channel ( irc.corecodec.com #matros
ka ) soon to discuss what we might wonna do here. All the guys interested
should give me a shout, so we can find a date when to mee there


4. Start to develop tools :

- matroskadub ( VirtualdubMod ), Windows : assigned to Cyrius and Belgabor,
Cyrius told me he is pretty close to be able to mux first video and audio
streams into our container, so we could upload some test files

- matroska DShow parser, Windows : myFUN is already working on it, he said
he plans to completely rewrite it 8) !!

- file repair tool ( Windows, Linux, MacOS ) : thana wanted to look at this
in abut 2 weeks, spyder will be the project coordinator. The tool should be
able to repair and optimize matroska files, as well as prepare it for mode2
form2 burning ( adding ad
ditional EDC/ECC elements )

- port EBML and matroska code to C : animesh has already loaded the sources,
santiago wanted to help him ; lets see what they come up with

- Muxing tool for Linux : Moritz Bunkus will look at that once the lib has
either a C API or is ported to C

- mplayer playback patch : Moritz also :) !

- gstreamer plugin, Linux : I will contact Ronald BBB Bultje again on that

- HTTP/RTP streaming server : How Tam is da man ;) ; robux4 to assist

( useful links :  http://article.gmane.org/gmane.comp.video.mcf.devel/550 ;
http://article.gmane.org/gmane.comp.video.mcf.devel/556 ;
http://www.rtsp.org/ ;
http://article.gmane.org/gmane.comp.video.mcf.devel/578 ;
http://article.gmane.org/gmane.comp.vi
deo.mcf.devel/617 ; http://article.gmane.org/gmane.comp.video.mcf.devel/630
;


- porting EBML and matroska to Java : noone assigned yet ; spyder has some
existing code, but its not tested nor uploaded

- JMF parser : spyder would be the man to do it for sure, as he had the most
JMF experience, maybe assisted by thana one day ?

All these jobs will be created on the GForge interface once we have moved to
the Corecodec server, but for now please use the list as created here.


5. Alpha Testing phase on http://corecodec.com and
http://virtualdub.everwicked.com : my job ;)


6. Release Beta tools : cant wait until we will finally be there, and it
could happen pretty soon, at least for Windows ...



Some important remarks :

- team email adresses : Animesh, Santiago and How Tam have already got new
team email adresses with the  @matroska.org TLD. All the others, pls. drop
me a short email if you want this also and what email adress you want me to
use for forwarding ( we don
t have a pop3 for that, but use zonedit email forwarding ). In case you want
to send email with that adress and dont have a relay to use, tell me.

- IRC channel : please visit our IRC channel on irc.corecodec.com , during
the European evening/night hours if possible. We discuss a lot of important
stuff there, so you shouldnt miss it to be there from time to time

- Mailing lists : Its important that you follow the 3 mailing lists we have
if you wnat to be up-to-date : These are NOT on sourceforge, but on
http://freelists.org , subscribe to matroska-devel <at >freelists.org ;
matroska-general <at> freelists.org ;
 matroska-cvs <at> freelists.org ; Alternatively you may use the NNTP
interface on gmane.org ( news://news.gmane.org ) and follow the lists there
, gmane.comp.multimedia.matroska.xxx


Again, a warm and friendly welcome from the matroska team to all of you !!
We hope you still want to help us and become team members, ow as you know a
bit more about our plans and goals, as well about the way we are working.

Looking forward to meet you soon on IRC

Best regards

ChristianHJW

................................

http://matroska.org


From steve.lhomme at free.fr  Fri Feb 14 12:36:28 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Fri, 14 Feb 2003 12:36:28 +0100 (CET)
Subject: [matroska-devel] Comments needed on seeking part
Message-ID: <1045222588.3e4cd4bc21f7e@imp.free.fr>


As you know, I'm currently working on the cueing/seeking part in matroska.
I'll have to change a few things in the cueing part (more general references
introduction), but that's not my problem for the moment (it's trivial).

The problem is the Meta Seek entries. The goal of this part is to avoid reading
the whole file (or lots of heads) to quickly find some specific content (track
entries, clusters, attachements, etc). The problem is that when you write a file
(in VDub for example) you don't know the number of Clusters you'll have to deal
with, and since you want to have them all in the Meta Seek element, you have to
write it at the end. But if it's saved at the end it is completely useless (you
have to parse many headers to get to that point that gives you the position of
what you already read). This means that this feature is only available "offline"
on post processing (even VDub can't predict the number of Clusters and write
dummy ones and fill the data later).

Since we want to have very fast seeking of the file in many cases, I think this
feature should be implemented in VDub (at least in a separate menu). And the
DirectShow filter should try to find the Meta Seek element at the beggining of
the file (first element in the Segment) otherwise consider it's not present.

Also, if the Meta Seek element doesn't exist, the cue entries can still exist at
the end of the file (which contain frame-precision-seeking based on timecode),
so the DirectShow filter might be able to first parse the file to find these
entries before starting the playback (not possible from a network stream).
http://matroska.org


From chris at wiesneronline.net  Fri Feb 14 17:24:23 2003
From: chris at wiesneronline.net (ChristianHJW)
Date: Fri, 14 Feb 2003 17:24:23 +0100
Subject: [matroska-devel] Re: Comments needed on seeking part
References: <1045222588.3e4cd4bc21f7e@imp.free.fr>
Message-ID: <00bb01c2d445$8a5b5af0$a70aa8c0@mahlo.de>


Hi all,

----- Original Message -----
From: "Steve Lhomme" <steve.lhomme at free.fr>
To: "Matroska Development" <matroska-devel at freelists.org>
Sent: Friday, February 14, 2003 12:36 PM
Subject: [matroska-devel] Comments needed on seeking part
> Also, if the Meta Seek element doesn't exist, the cue entries can still
exist at
> the end of the file (which contain frame-precision-seeking based on
timecode),
> so the DirectShow filter might be able to first parse the file to find
these
> entries before starting the playback (not possible from a network stream).
> http://matroska.org


you know i am not a coder, so this may be complete rubbish now, but look at
it from a brainstoming point of view ;)  :

Instead of having one big seek table at the end of the file, why not make it
like that :

1. several seek tables at cluster 100, 200, 300, 400 ,etc.

2. Seek tabel at cluster 100 contains the entries for cluster 1 - 99 , table
at cluster 200 contains entries for 101 - 199, etc ....

3. To be able to cover different scenarios ( huge cluster sizes, etc. ) you
can define a value stating in the file header telling you after how many
clusters a new seek table would come. In my scenario above this value was
100

Regards

Christian

http://matroska.org


From steve.lhomme at free.fr  Fri Feb 14 17:31:44 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Fri, 14 Feb 2003 17:31:44 +0100 (CET)
Subject: [matroska-devel] Re: Comments needed on seeking part
In-Reply-To: <00bb01c2d445$8a5b5af0$a70aa8c0@mahlo.de>
References: <1045222588.3e4cd4bc21f7e@imp.free.fr> <00bb01c2d445$8a5b5af0$a70aa8c0@mahlo.de>
Message-ID: <1045240304.3e4d19f0571e1@imp.free.fr>


En r?ponse ? ChristianHJW <chris at wiesneronline.net>:

> you know i am not a coder, so this may be complete rubbish now, but look
> at
> it from a brainstoming point of view ;)  :
> 
> Instead of having one big seek table at the end of the file, why not
> make it
> like that :
> 
> 1. several seek tables at cluster 100, 200, 300, 400 ,etc.
> 
> 2. Seek tabel at cluster 100 contains the entries for cluster 1 - 99 ,
> table
> at cluster 200 contains entries for 101 - 199, etc ....
> 
> 3. To be able to cover different scenarios ( huge cluster sizes, etc. )
> you
> can define a value stating in the file header telling you after how
> many
> clusters a new seek table would come. In my scenario above this value
> was
> 100

As Cyrius said on IRC (yes, I'm a lurker) there's no use for a seek table or cue
entry if it's split in many parts throughout the file. If it is spread among the
file, it should always be the same one (reemission during a stream for example).

For the VDub case, I think the placeholder I just talked about should be enough.
Note that the Cue entries can still be at the end (should be much bigger than
the Meta Seek entry) and contain the position inside the Meta Seek entry. (cue
only define the position of a Cluster+Block according to a timecode, the Meta
Seek entries can be specified for any matroska element).
http://matroska.org


From steve.lhomme at free.fr  Fri Feb 14 17:29:10 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Fri, 14 Feb 2003 17:29:10 +0100 (CET)
Subject: [matroska-devel] Re: Comments needed on seeking part
In-Reply-To: <1045222588.3e4cd4bc21f7e@imp.free.fr>
References: <1045222588.3e4cd4bc21f7e@imp.free.fr>
Message-ID: <1045240150.3e4d195635c30@imp.free.fr>


There is a case I haven't mentioned which is possible in matroska (as well as in
AVI or MP4 and all IFF in general). You can write a dummy element at the
beggining with a generous size (should be tweaked later) that contains no
specific data (Void element in EBML/matroska). Then later when you want to write
the Meta Seek entries, you put it at this place and "Void" the remaining data.
When the Meta Seek is too large to fit in there, it can simply be discarded (as
explain before there's no much use of reading it at the end of the file).
http://matroska.org


From christian at matroska.org  Sun Feb 16 23:15:47 2003
From: christian at matroska.org (ChristianHJW)
Date: Sun, 16 Feb 2003 23:15:47 +0100
Subject: [matroska-devel] Re: container format MPCF ( mplayer media container format )
References: <200302050900.h15908OR029441@mail.mplayerhq.hu><200302061930.27267.michaelni@gmx.at><200302081941.59111.christof@buergi.lugs.ch> <200302081955.40434.michaelni@gmx.at>
Message-ID: <b2p2e7$je3$1@main.gmane.org>


"Michael Niedermayer" <michaelni at gmx.at> schrieb im Newsbeitrag
news:200302081955.40434.michaelni at gmx.at...
> currently the index at the end is required for normal files (realtime
streams
> are an exception) but the index can be repeated if the muxer wants to
repeat
> it, this IMHO doesnt add any complexity to either the muxer or demuxer but
> its more flexible for thouse crazy ppl who want a few copies of the index
> Michael

matroska Team came up with the very same solution. EBML allows us to repeat
the meta seek tables ( = index ) as many times as we want in the file, but
we normally write it at the end.

Christian
http://matroska.org



http://matroska.org


From chris at matroska.org  Sun Feb 16 23:52:18 2003
From: chris at matroska.org (Christian HJ Wiesner)
Date: Sun, 16 Feb 2003 23:52:18 +0100
Subject: [matroska-devel] libmatroska : get latest updates from CVS guys before wokring on it !!
Message-ID: <01de01c2d60e$0eb4c790$6500a8c0@mahlo.de>


Hi people,

please make sure to get the latest version of libmatroska before doing any
kind of work on it, there had been numerous changes over the weekend, from
Mosu, Cyrius and robux4.

Regards

Christian

http://matroska.org


From moritz at bunkus.org  Mon Feb 17 15:04:09 2003
From: moritz at bunkus.org (Moritz Bunkus)
Date: Mon, 17 Feb 2003 15:04:09 +0100
Subject: [matroska-devel] AVI compatibility mode?
Message-ID: <20030217140409.GC26772@bunkus.org>


Hi.

Sunday Cyrius and I had a rather long discussion about the 'AVI
compatibility mode'. He told me he'd save the BITMAPDONTASKMETHATNAME
and the WAVEHEADEREX and other structures in KaxCodecPrivate and didn't
set all the KaxVideo* elements.

This was the first time I actually heard about such a compatibility
mode, and I was a bit confused why anyone would want to do such a
thing. That's why I'd like some clarification on that point.

Some disadvantages that I can see right now:
 - These structures are Windows specific. Neither Unix/Linux nor MacOS
knows about them.
 - These structures are stored as they are lying around in memory which
produces the usual Endianess problems.
 - Why use separate structures that are not coded in EBML if Matroska
itself contains elements for the contents? e.g. KaxVideoPixelWidth etc.

If there are any fields in those structures that are necessary or even
only important and there's no Matroska element for storing this piece
of information, then Matroska should be changed.

Another point: I now know that there are dummy frames in AVIs if B
frames are being used. I understand that you want to store that fact in
Matroska in some way. But there's alreadly KaxCodecID...

Another question: if I use 'V_MS/VFW/FOURCC' for the CodecID (as I'm
reading an AVI) - where do I store the FourCC?
http://www.corecodec.com/modules.php?op=modload&name=PNphpBB2&file=viewtopic&t=227
says 'see codec 'private' data and use suitable decoder based on FourCC
code' but where do I then store e.g. the Huffman tables required by the
MJPEG codec? And why does the spec say that CodecID is 128bits long
with the upper half being reserved? Aaaaaaaand...

Next question. Well... I'm sure I had another question, but I can't
remember it right now ;)

-- 
 ==> Ciao, Mosu (Moritz Bunkus)
http://matroska.org


From steve.lhomme at free.fr  Mon Feb 17 15:24:29 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Mon, 17 Feb 2003 15:24:29 +0100 (CET)
Subject: [matroska-devel] Re: AVI compatibility mode?
In-Reply-To: <20030217140409.GC26772@bunkus.org>
References: <20030217140409.GC26772@bunkus.org>
Message-ID: <1045491869.3e50f09de8ea4@imp.free.fr>


En r?ponse ? Moritz Bunkus <moritz at bunkus.org>:

> 
> Hi.
> 
> Sunday Cyrius and I had a rather long discussion about the 'AVI
> compatibility mode'. He told me he'd save the BITMAPDONTASKMETHATNAME
> and the WAVEHEADEREX and other structures in KaxCodecPrivate and
> didn't set all the KaxVideo* elements.

All the matroska field should be filled when the value is known and different
that the default one.

> This was the first time I actually heard about such a compatibility
> mode, and I was a bit confused why anyone would want to do such a
> thing. That's why I'd like some clarification on that point.
> 
> Some disadvantages that I can see right now:
>  - These structures are Windows specific. Neither Unix/Linux nor MacOS
> knows about them.

As long as they don't deal with AVI. Otherwise it is handled somewhere.

>  - These structures are stored as they are lying around in memory
> which produces the usual Endianess problems.

Correct, but since it's a Microsoft compatibility mode, we can assume the
structure is little endian. It should also be aligned on 1 octet. (uint8 = 1
octet, not 4)

>  - Why use separate structures that are not coded in EBML if Matroska
> itself contains elements for the contents? e.g. KaxVideoPixelWidth
> etc.

As said above, all matroska fields should be filled when possible.

> If there are any fields in those structures that are necessary or even
> only important and there's no Matroska element for storing this piece
> of information, then Matroska should be changed.

Normally most of them should already be in matroska and general to any
(audio/video) codec. For the rest, they probably have no meaning at the
container level.

> Another point: I now know that there are dummy frames in AVIs if B
> frames are being used. I understand that you want to store that fact
> in Matroska in some way. But there's alreadly KaxCodecID...

?

> Another question: if I use 'V_MS/VFW/FOURCC' for the CodecID (as I'm
> reading an AVI) - where do I store the FourCC?

In the Microsoft structure, that takes place in the codec private data.

> http://www.corecodec.com/modules.php?op=modload&name=PNphpBB2&file=viewtopic&t=227
> says 'see codec 'private' data and use suitable decoder based on
> FourCC
> code' but where do I then store e.g. the Huffman tables required by
> the
> MJPEG codec? And why does the spec say that CodecID is 128bits long
> with the upper half being reserved? Aaaaaaaand...

That's Christian again trying to be technical ;)
There is finally no limit on the CodecID (why would there be one ?).
For MJPEG in AVI, where is the Huffman table saved ? I would assume it would be
next to the Microsoft structures we were talking about, and should be stored
next to them as in AVI. At least that's the way it works in audio. If that's
elsewhere... We need to know where :)
http://matroska.org


From moritz at bunkus.org  Mon Feb 17 15:36:47 2003
From: moritz at bunkus.org (Moritz Bunkus)
Date: Mon, 17 Feb 2003 15:36:47 +0100
Subject: [matroska-devel] Re: AVI compatibility mode?
In-Reply-To: <1045491869.3e50f09de8ea4@imp.free.fr>
References: <20030217140409.GC26772@bunkus.org> <1045491869.3e50f09de8ea4@imp.free.fr>
Message-ID: <20030217143647.GD26772@bunkus.org>


Hi.

> >  - These structures are Windows specific. Neither Unix/Linux nor MacOS
> > knows about them.
> 
> As long as they don't deal with AVI. Otherwise it is handled somewhere.

Sure, but not necessarily the complete structures. E.g. the only fields
that are used e.g. in mplayer or my ogmtools are width, height, fps,
fourcc, bits per pixel, channels, sample rate... There are a lot of
fields that I don't know what I should put into them at all. So if I
write a Matroska file and have to create such structures which fields
do I set to which values?

> Correct, but since it's a Microsoft compatibility mode, we can assume the
> structure is little endian. It should also be aligned on 1 octet. (uint8 = 1
> octet, not 4)

Ok.

What my primary question is - why is there a MS compatibility mode at
all? Is there a real need for such a mode? (Apart from being lazy and
able to reuse those structures, and apart from being able to tell that
the 'dummy frames for B frames' are still present)

> Normally most of them should already be in matroska and general to any
> (audio/video) codec. For the rest, they probably have no meaning at the
> container level.

Then why are those structures still used?

> > Another point: I now know that there are dummy frames in AVIs if B
> > frames are being used. I understand that you want to store that fact
> > in Matroska in some way. But there's alreadly KaxCodecID...
> 
> ?

Well forget that paragraph, I don't know either what I wanted to say
anymore ;)

-- 
 ==> Ciao, Mosu (Moritz Bunkus)
http://matroska.org


From steve.lhomme at free.fr  Mon Feb 17 15:49:27 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Mon, 17 Feb 2003 15:49:27 +0100 (CET)
Subject: [matroska-devel] Re: AVI compatibility mode?
In-Reply-To: <20030217143647.GD26772@bunkus.org>
References: <20030217140409.GC26772@bunkus.org> <1045491869.3e50f09de8ea4@imp.free.fr> <20030217143647.GD26772@bunkus.org>
Message-ID: <1045493367.3e50f67759f63@imp.free.fr>


En r?ponse ? Moritz Bunkus <moritz at bunkus.org>:

> > >  - These structures are Windows specific. Neither Unix/Linux nor
> MacOS
> > > knows about them.
> > 
> > As long as they don't deal with AVI. Otherwise it is handled
> somewhere.
> 
> Sure, but not necessarily the complete structures. E.g. the only
> fields
> that are used e.g. in mplayer or my ogmtools are width, height, fps,
> fourcc, bits per pixel, channels, sample rate... There are a lot of
> fields that I don't know what I should put into them at all. So if I
> write a Matroska file and have to create such structures which fields
> do I set to which values?

You mean you don't understand the fields of matroska, the fields of AVI or the
correspondance ?
 
> What my primary question is - why is there a MS compatibility mode at
> all? Is there a real need for such a mode? (Apart from being lazy and
> able to reuse those structures, and apart from being able to tell that
> the 'dummy frames for B frames' are still present)

Because an MPEG4 codec (for example) is not saved the same way in AVI than in
native matroska form (B frames for example). So the codec that should be used
has to deal with data that comes in an AVI coded way.
Why do we store the full structures ? Because we want to be able to make
transparent transmuxing with AVI. If you remove some data when you do
AVI->matroska you may be unable to read the file when you do matroska->AVI.
 
> > Normally most of them should already be in matroska and general to
> any
> > (audio/video) codec. For the rest, they probably have no meaning at
> the
> > container level.
> 
> Then why are those structures still used?

See above.
http://matroska.org


From chris at matroska.org  Mon Feb 17 15:42:02 2003
From: chris at matroska.org (Christian HJ Wiesner)
Date: Mon, 17 Feb 2003 15:42:02 +0100
Subject: [matroska-devel] Re: AVI compatibility mode?
In-Reply-To: <20030217140409.GC26772@bunkus.org>
References: <20030217140409.GC26772@bunkus.org>
Message-ID: <3E50F4BA.7090008@matroska.org>


Hi mosu !

Moritz Bunkus wrote:

>Hi.
>
>Sunday Cyrius and I had a rather long discussion about the 'AVI
>compatibility mode'. He told me he'd save the BITMAPDONTASKMETHATNAME
>and the WAVEHEADEREX and other structures in KaxCodecPrivate and didn't
>set all the KaxVideo* elements.
>
BITMAPINFOHEADER
WAVEFORMATEX

Well, than Cyrius is lazy and doesnt make things correctly :P . For AVI 
compatibility mode the plan is to

- copy the above mentioned structures into codec private data. This is 
necessary to be able to call the corresponding DShow filters on Windows
- extract all the necessary info for matroska elements from there also 
and set the elements accordingly, especially with respect to x-platform 
compatibility

>This was the first time I actually heard about such a compatibility
>mode, and I was a bit confused why anyone would want to do such a
>thing. That's why I'd like some clarification on that point.
>Some disadvantages that I can see right now:
> - These structures are Windows specific. Neither Unix/Linux nor MacOS
>knows about them.
>
Yes, thats why we always said AVI compatibility mode will behard to 
support on other platforms, and this mode should be avoided as good as 
possible ! Unfortunately we dont have UCI plugins available for the time 
being ( as UCI is not ready ), and such plugins should be used normally 
to create 'native' audio/video streams using a matroska ID

> - These structures are stored as they are lying around in memory which
>produces the usual Endianess problems.
> - Why use separate structures that are not coded in EBML if Matroska
>itself contains elements for the contents? e.g. KaxVideoPixelWidth etc.
>
See above, thats the plan. AVI compatibility mode is a fallback system 
to be able to support

- older codecs that are availlable only as VfW or have an unusual FourCC etc
- make the adressing of DShow filters for playback on Windows relatively 
easy, as there will be only a very small number of UCI decoder plugins 
during the first years, or none at all ( like for the time being :-(  )

It was always the plan to DIScourage the use of this mode, to enhance 
x-platform compatibility.

>If there are any fields in those structures that are necessary or even
>only important and there's no Matroska element for storing this piece
>of information, then Matroska should be changed.
>  
>
matroska has elements for every single piece of information that is 
stored in the AVI structures, except those we dont need for matroska ( 
dont ask me what these are though )

>Another point: I now know that there are dummy frames in AVIs if B
>frames are being used. I understand that you want to store that fact in
>Matroska in some way. But there's alreadly KaxCodecID...
>  
>
The original plan was to differentiate clearly between an MPEG4 video 
stream coming from an AVI ( including b frames ) and an MPEG4 stream 
being produced with a native MPEG4 UCI plugin, storing b frames using 
the matroska b frame elements, and not using dummy frames. First should 
be stored in AVI compatibility mode by all means, so its clear this was 
muxed from an AVI. Second could be the result of
- a native MPEG4 UCI plugin
- a demuxed AVI that is reordered in that way that the b-frames ( they 
are attached to the I/P frames in one single chunk now IIRC, Alex 
Stewart has explained that perfectly ) are released from the I/P frame 
chunks and inserted where the dummy frames are sitting right now. That 
way we wont have dummy frames in native streams with matroska codec IDs 
anymore, reducing overhead and keeping the right frame order ( coding 
order, as recommended by Alex several times and agreed by Steve ).

>Another question: if I use 'V_MS/VFW/FOURCC' for the CodecID (as I'm
>reading an AVI) - where do I store the FourCC?
>
The FourCC is stored in the BITMAPINFOHEADER structure, Cyrius should be 
able to tell you the name of the tag.

>http://www.corecodec.com/modules.php?op=modload&name=PNphpBB2&file=viewtopic&t=227
>says 'see codec 'private' data and use suitable decoder based on FourCC
>code' but where do I then store e.g. the Huffman tables required by the
>MJPEG codec? 
>
:-( .... i know that there are a couple of codecs that are clearly 
breaking the AVI specs by putting some important data into the AVI 
comment fields. HuffYuv is doing the same shit, storing huffman table 
there same way as MJPEG does. Its true, we have to define a way how to 
do that !! I would suggest they go into codec private data also, but 
Steve would be the one to ask here for final clarifying.

>And why does the spec say that CodecID is 128bits long
>with the upper half being reserved? Aaaaaaaand...
>
?? It should by 16 bytes long ? are you sure ? maybe an error in the 
spec, or is this an EBML element ?

>Next question. Well... I'm sure I had another question, but I can't
>remember it right now ;)
>  
>
Thank god !! lol .....

Regards

Christian

http://matroska.org


From moritz at bunkus.org  Mon Feb 17 15:59:17 2003
From: moritz at bunkus.org (Moritz Bunkus)
Date: Mon, 17 Feb 2003 15:59:17 +0100
Subject: [matroska-devel] Re: AVI compatibility mode?
In-Reply-To: <3E50F4BA.7090008@matroska.org>
References: <20030217140409.GC26772@bunkus.org> <3E50F4BA.7090008@matroska.org>
Message-ID: <20030217145917.GE26772@bunkus.org>


Hi.

Ok, you two have conviced me that I'll try to add the structures as
well.

Here's anoter question ;) BITMAPANDSOON for a video track, and
WAVEHEADEREX for an audio track - but what about e.g. the codec data
that Vorbis uses? (Same issue as the Huffman tables)

Those two structures should be well documented in the specs on the web
page including the reasons why there are used.

> >And why does the spec say that CodecID is 128bits long
> >with the upper half being reserved? Aaaaaaaand...
> >
> ?? It should by 16 bytes long ? are you sure ? maybe an error in the 
> spec, or is this an EBML element ?

In the specs on the web page ;) Got me confused just a little bit ;)

-- 
 ==> Ciao, Mosu (Moritz Bunkus)
http://matroska.org


From steve.lhomme at free.fr  Mon Feb 17 16:13:55 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Mon, 17 Feb 2003 16:13:55 +0100 (CET)
Subject: [matroska-devel] Re: AVI compatibility mode?
In-Reply-To: <20030217145917.GE26772@bunkus.org>
References: <20030217140409.GC26772@bunkus.org> <3E50F4BA.7090008@matroska.org> <20030217145917.GE26772@bunkus.org>
Message-ID: <1045494835.3e50fc3384244@imp.free.fr>


En r?ponse ? Moritz Bunkus <moritz at bunkus.org>:

> Hi.
> 
> Ok, you two have conviced me that I'll try to add the structures as
> well.
> 
> Here's anoter question ;) BITMAPANDSOON for a video track, and
> WAVEHEADEREX for an audio track - but what about e.g. the codec data
> that Vorbis uses? (Same issue as the Huffman tables)

Vorbis doesn't have an existing WAVEHEADEREX system. So we have to define the
way data internal to the codec are handled. You're probably the most qualified
person here to know what is needed. All this, like for AVI, should go in the
matroska fields when they correspond to a Vorbis value (like sampling
frenquency) otherwise it should go in the codec private data (in a structure
known publicly).

> Those two structures should be well documented in the specs on the web
> page including the reasons why there are used.

Definitely ! For inter operability. Maybe that's a webpage that could be added
to the website : explaining what to put in the codec private data, for each
codec we "support".
http://matroska.org


From steve.lhomme at free.fr  Mon Feb 17 15:59:28 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Mon, 17 Feb 2003 15:59:28 +0100 (CET)
Subject: [matroska-devel] Reference change
Message-ID: <1045493968.3e50f8d0a2a7e@imp.free.fr>


Hi,

I was thinking about the way I'm currently handling references in libmatroska. I
have some problems with the cueing fields, because it requires the position of
the Cluster that is not known inside the Block. For references, we also need the
position of the Cluster and the timecode of the referenced Block.

The current situation is that for cueing data I give a Block and referenced
timecodes. But I'm still missing the position of the Cluster...

What I'm planning to do is :
- add a reference/pointer to the parent Cluster for each Block
- for each reference (KaxReferenceBlock ?) a reference/pointer to the
corresponding Block should be available (to be able to recover the timecode of
the reference and the parent Cluster (see above)).

So expect some changes in the API with these changes, the old way of setting a
references might be removed, since it can lead to bugs (put a non existent
timecode as reference). It will also make mandatory the use of coding order (you
can't reference a Block that doesn't exist).

There might be a problem when references are spanned across Clusters, because we
don't want to cache all old Blocks with large data. So we have 2 options (at
least) :
- free the data after the Block has been written to the stream (on request) and
just keep the internal data (like the Block position, timecode, parent Cluster,
etc).
- copy the Block internal data (like the Block position, timecode, parent
Cluster, etc) into a special Block that doesn't contain any data, and do
whatever you want with the original Block.

Any comments on the changes ? (I'll work on that tonight)

After this part is done, I'll start working on FileKax (and maybe first fix the
known bugs in some EBML/matroska parts).
http://matroska.org


From steve.lhomme at free.fr  Mon Feb 17 17:28:19 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Mon, 17 Feb 2003 17:28:19 +0100 (CET)
Subject: [matroska-devel] AVI compatibility misunderstanding
Message-ID: <1045499299.3e510da31ab60@imp.free.fr>


As the title says, streams that are saved in compatiility mode are the ones we
don't have any other choice. That means we can change this behaviour for codec
that we know.

[17:15] <Mosu> so what do we do about those structs?
[17:16] <Mosu> easiest is for the audio... if it's mp3/ac3/pcm we include
WAVEFORMATEX in KaxCodecPrivate

This is a good example where we don't need a codec private data ! WAVEFORMATEX
is used only for streams coming from ACM/AVI, not in the general case. We are
not making matroska AVI++. We use the AVI structure only when a native matroska
format hasn't been defined (most of the times BTW). For the moment since all our
sources are AVI, we can blindly put everything in AVI structures. But later some
hacks/transformations will take place, to make real use of matroska and get rid
of these fucking structures.
http://matroska.org


From steve.lhomme at free.fr  Mon Feb 17 17:33:02 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Mon, 17 Feb 2003 17:33:02 +0100 (CET)
Subject: [matroska-devel] Re: AVI compatibility misunderstanding
In-Reply-To: <1045499299.3e510da31ab60@imp.free.fr>
References: <1045499299.3e510da31ab60@imp.free.fr>
Message-ID: <1045499582.3e510ebe7c782@imp.free.fr>


Another one :

[17:17] <Cyrius> well actually the problem is that some formats have their own
struture that goes beyond WAVEFORMATEX

Well, KaxCodecPrivate for audio != WAVEFORMATEX !!!!!!

It is only the case when the audio stream comes from an unknown (/known) an AVI
file or WAV file. For all the other cases KaxCodecPrivate for audio is something
different, sometimes nothing (like for MPEG Audio Layer I/II/III).
http://matroska.org


From steve.lhomme at free.fr  Mon Feb 17 17:39:30 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Mon, 17 Feb 2003 17:39:30 +0100 (CET)
Subject: [matroska-devel] Re: AVI compatibility misunderstanding
In-Reply-To: <1045499582.3e510ebe7c782@imp.free.fr>
References: <1045499299.3e510da31ab60@imp.free.fr> <1045499582.3e510ebe7c782@imp.free.fr>
Message-ID: <1045499970.3e511042b1a28@imp.free.fr>


Another one from the trio ;)

[17:24] <spyder482> KaxCodecPrivate - conatining subelements with codec data
[17:24] <spyder482> MSCompatibility - containing subelements for MS shit

When the stream comes from... an MP3 file for example, KaxCodecPrivate has a
special form and MSCompatibility is not used.
When the source is ACM based (AVI, WAV) MSCompatibility is filled and
KaxCodecPrivate is not filled...

SO KaxCodecPrivate and MSCompatibility are redundant. They are not used
separately. That's why they are THE SAME !

MSCompatibility is just a particular case of filling KaxCodecPrivate. In this
case the codec is A_MS/ACM (or something like that), regardless if it's PCM,
MPEG, Vorbis, My ASS, inside the ACM structure, etc...

Later (sooner as possible) we'll make hacks to transform some well known ACM
codec  into native matroska streams.
http://matroska.org


From moritz at bunkus.org  Mon Feb 17 17:48:00 2003
From: moritz at bunkus.org (Moritz Bunkus)
Date: Mon, 17 Feb 2003 17:48:00 +0100
Subject: [matroska-devel] Re: AVI compatibility misunderstanding
In-Reply-To: <1045499970.3e511042b1a28@imp.free.fr>
References: <1045499299.3e510da31ab60@imp.free.fr> <1045499582.3e510ebe7c782@imp.free.fr> <1045499970.3e511042b1a28@imp.free.fr>
Message-ID: <20030217164800.GG26772@bunkus.org>


Hi.

> Another one from the trio ;)
> 
> [17:24] <spyder482> KaxCodecPrivate - conatining subelements with codec data
> [17:24] <spyder482> MSCompatibility - containing subelements for MS shit
> 
> When the stream comes from... an MP3 file for example, KaxCodecPrivate has a
> special form and MSCompatibility is not used.
> When the source is ACM based (AVI, WAV) MSCompatibility is filled and
> KaxCodecPrivate is not filled...

Audio is the easy part. My tools will use A_PCM16IN for 'normal'
uncompressed PCM data, A_MPEGLAYER3 for MP3, A_DOL_AC3 for AC3 and
A_VORBIS for Vorbis. Obviously those formats are all well known and
shouldn't require a WAVEHEADEREX to be stored as well. Right?

So the only complicated case is Vorbis which needs three packets apart
from the data: the headers, the comments and the setup data. Those
three packets have to be stored under KaxCodecPrivate somehow.

(still no need for MSCompat...)

Video is another thing. If you use e.g. HuffYUV or MJPEG then you'll
need to store Huffman tables somewhere. Where do you store it if
KaxCodecPrivate is already filled with BITMAPINFOHEADER (or
AVIANOTHERNAMEIWILLNEVERBEABLETOREMEMBER)?

> SO KaxCodecPrivate and MSCompatibility are redundant. They are not used
> separately. That's why they are THE SAME !

Not always, I'd suppose. For audio I'd agree so far.

> Later (sooner as possible) we'll make hacks to transform some well known ACM
> codec  into native matroska streams.

Guess what, I don't understand that sentence - perhaps because I've
never done DirectShow/VfW coding. A simple question: if I use
A_MPEGLAYER3 and fill in all KaxAudio* elements, will the Windows apps
be able to handle that on their own? As in 'yes, they'll just recreate
a WAVEHEADEREX if needed and search for the corresponding codec'?

-- 
 ==> Ciao, Mosu (Moritz Bunkus)
http://matroska.org


From steve.lhomme at free.fr  Mon Feb 17 18:07:23 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Mon, 17 Feb 2003 18:07:23 +0100 (CET)
Subject: [matroska-devel] Re: AVI compatibility misunderstanding
In-Reply-To: <20030217164800.GG26772@bunkus.org>
References: <1045499299.3e510da31ab60@imp.free.fr> <1045499582.3e510ebe7c782@imp.free.fr> <1045499970.3e511042b1a28@imp.free.fr> <20030217164800.GG26772@bunkus.org>
Message-ID: <1045501643.3e5116cbc4e99@imp.free.fr>


> Audio is the easy part. My tools will use A_PCM16IN for 'normal'
> uncompressed PCM data, A_MPEGLAYER3 for MP3, A_DOL_AC3 for AC3 and
> A_VORBIS for Vorbis. Obviously those formats are all well known and
> shouldn't require a WAVEHEADEREX to be stored as well. Right?

Yup.
 
> So the only complicated case is Vorbis which needs three packets apart
> from the data: the headers, the comments and the setup data. Those
> three packets have to be stored under KaxCodecPrivate somehow.

Yup.

> (still no need for MSCompat...)
> 
> Video is another thing. If you use e.g. HuffYUV or MJPEG then you'll
> need to store Huffman tables somewhere. Where do you store it if
> KaxCodecPrivate is already filled with BITMAPINFOHEADER (or
> AVIANOTHERNAMEIWILLNEVERBEABLETOREMEMBER)?

Well, I thought it was like the cbSize in WAVEFORMATEX that tells the size of
extra data private to the codec : BITMAPINFOHEADER.biSize. That's IIRC the
conclusion of the discussion I had with Cyrius. If that's not the case, we need
even more than the 2 structures mentioned (maybe removing one or 2 of them too ;).

> > SO KaxCodecPrivate and MSCompatibility are redundant. They are not
> used
> > separately. That's why they are THE SAME !
> 
> Not always, I'd suppose. For audio I'd agree so far.

Maybe a HuffPCM would need a Huffman table initialisation too...
 
> > Later (sooner as possible) we'll make hacks to transform some well
> known ACM
> > codec  into native matroska streams.
> 
> Guess what, I don't understand that sentence - perhaps because I've
> never done DirectShow/VfW coding. A simple question: if I use
> A_MPEGLAYER3 and fill in all KaxAudio* elements, will the Windows apps
> be able to handle that on their own? As in 'yes, they'll just recreate
> a WAVEHEADEREX if needed and search for the corresponding codec'?

I think so, even though when I made the LAME ACM, I tried to fill the extra data
in the WAVEFORMATEX (MPEGL3_WAVEFORMATEX or something like that) the same way as
the Fraunhofer codec. You never know if their decoder will be able to handle
stranges cases or not.
http://matroska.org


From chris at matroska.org  Mon Feb 17 18:35:04 2003
From: chris at matroska.org (Christian HJ Wiesner)
Date: Mon, 17 Feb 2003 18:35:04 +0100
Subject: [matroska-devel] Re: AVI compatibility misunderstanding
In-Reply-To: <20030217164800.GG26772@bunkus.org>
References: <1045499299.3e510da31ab60@imp.free.fr> <1045499582.3e510ebe7c782@imp.free.fr> <1045499970.3e511042b1a28@imp.free.fr> <20030217164800.GG26772@bunkus.org>
Message-ID: <3E511D48.10006@matroska.org>


Moritz Bunkus wrote:

>Guess what, I don't understand that sentence - perhaps because I've
>never done DirectShow/VfW coding. A simple question: if I use
>A_MPEGLAYER3 and fill in all KaxAudio* elements, will the Windows apps
>be able to handle that on their own? As in 'yes, they'll just recreate
>a WAVEHEADEREX if needed and search for the corresponding codec'?
>
For the DirectShow playback it will be the parser filters job ( myFUN ) 
to either

- reconstruct all the data it needs to be able to call an audio 
DirectShow filter ( MP3, AC3 ), maybe by storing WAVEFORMATEX info from 
the most used codecs and channel setups ( AC3 2.0 , AC3 5.1 etc. ) in a 
table somewhere, and by completing that when calling the filter

- decode the audio with a built in ( hardcoded ) decoder and output PCM 
audio, like for Vorbis, FLAC and MPC

Regards

Christian

http://matroska.org


From moritz at bunkus.org  Mon Feb 17 18:43:34 2003
From: moritz at bunkus.org (Moritz Bunkus)
Date: Mon, 17 Feb 2003 18:43:34 +0100
Subject: [matroska-devel] Re: AVI compatibility misunderstanding
In-Reply-To: <3E511D48.10006@matroska.org>
References: <1045499299.3e510da31ab60@imp.free.fr> <1045499582.3e510ebe7c782@imp.free.fr> <1045499970.3e511042b1a28@imp.free.fr> <20030217164800.GG26772@bunkus.org> <3E511D48.10006@matroska.org>
Message-ID: <20030217174334.GH26772@bunkus.org>


Hi.

> - reconstruct all the data it needs to be able to call an audio 
> DirectShow filter ( MP3, AC3 ), maybe by storing WAVEFORMATEX info from 
> the most used codecs and channel setups ( AC3 2.0 , AC3 5.1 etc. ) in a 
> table somewhere, and by completing that when calling the filter

Shouldn't each and every 'filter' or demuxer or whatever you may call
it be able to do that without any WAVEFORMATEX structure stored in a
Matroska file? That's what containers are about, isn't it?

-- 
 ==> Ciao, Mosu (Moritz Bunkus)
http://matroska.org


From chris at wiesneronline.net  Mon Feb 17 18:54:47 2003
From: chris at wiesneronline.net (Christian HJ Wiesner)
Date: Mon, 17 Feb 2003 18:54:47 +0100
Subject: [matroska-devel] Re: AVI compatibility misunderstanding
In-Reply-To: <20030217174334.GH26772@bunkus.org>
References: <1045499299.3e510da31ab60@imp.free.fr> <1045499582.3e510ebe7c782@imp.free.fr> <1045499970.3e511042b1a28@imp.free.fr> <20030217164800.GG26772@bunkus.org> <3E511D48.10006@matroska.org> <20030217174334.GH26772@bunkus.org>
Message-ID: <3E5121E7.9060107@wiesneronline.net>

Moritz Bunkus wrote:

>Hi.
>
>  
>
>>- reconstruct all the data it needs to be able to call an audio 
>>DirectShow filter ( MP3, AC3 ), maybe by storing WAVEFORMATEX info from 
>>the most used codecs and channel setups ( AC3 2.0 , AC3 5.1 etc. ) in a 
>>table somewhere, and by completing that when calling the filter
>>    
>>
>
>Shouldn't each and every 'filter' or demuxer or whatever you may call
>it be able to do that without any WAVEFORMATEX structure stored in a
>Matroska file? That's what containers are about, isn't it?
>
Mosu,

once we will have UCI the matroska demuxer/parser will call UCI plugins 
for that, we wont need DShow filters than anymore .... this is just a 
contemporary solution until we have UCI or another working codec API, 
and can start coding decoder plugins

Christian




http://matroska.org


From spyder482 at yahoo.com  Tue Feb 18 00:46:02 2003
From: spyder482 at yahoo.com (John Cannon)
Date: Mon, 17 Feb 2003 17:46:02 -0600
Subject: [matroska-devel] Java EBML Parsing code uploaded to CVS
Message-ID: <b2rs1v$fi2$1@main.gmane.org>

It's not much but I was told to inform the list. :)

It now has a working class for Binary, UnsignedInteger and SignedInteger
types.  The last two are subclasses of the first.  They also can give the
binary value of the data. :)

I have not yet rewritten the parser framework so you have to read the file
manually.  :(

Spyder



http://matroska.org


From spyder482 at yahoo.com  Wed Feb 19 15:11:16 2003
From: spyder482 at yahoo.com (John Cannon)
Date: Wed, 19 Feb 2003 08:11:16 -0600
Subject: [matroska-devel] Re: Java EBML Parsing code uploaded to CVS
References: <b2rs1v$fi2$1@main.gmane.org>
Message-ID: <b3038o$oe5$1@main.gmane.org>

Hi,

This is to all developers.  I need advice.  I am not really sure how to
proceed with the framework for this parser.  I will first make my SAX-style
implementation and later build a tree structured one.  If you have any
better suggestions or requests, post them here.  I would really appreciate
input from the Java developers among us.  I have made a Input wrapper class
to make use of other methods of obtaining the data but I am not sure if it
is needed.  Please comment. :)

John Cannon
Matroska Developer
spyder482 at matroska.org



http://www.matroska.org


From chris at matroska.org  Wed Feb 19 15:52:08 2003
From: chris at matroska.org (Christian HJ Wiesner)
Date: Wed, 19 Feb 2003 15:52:08 +0100
Subject: [matroska-devel] Re: Java EBML Parsing code uploaded to CVS
In-Reply-To: <b3038o$oe5$1@main.gmane.org>
References: <b2rs1v$fi2$1@main.gmane.org> <b3038o$oe5$1@main.gmane.org>
Message-ID: <3E539A18.9090305@matroska.org>


John,

pls. make sure to copy thana and santiago on posts like this directly in 
future, i dont know if they are subscribed to the lists already.

Christian

John Cannon wrote:
> Hi,
> 
> This is to all developers.  I need advice.  I am not really sure how to
> proceed with the framework for this parser.  I will first make my SAX-style
> implementation and later build a tree structured one.  If you have any
> better suggestions or requests, post them here.  I would really appreciate
> input from the Java developers among us.  I have made a Input wrapper class
> to make use of other methods of obtaining the data but I am not sure if it
> is needed.  Please comment. :)
> John Cannon
> Matroska Developer
> spyder482 at matroska.org


http://www.matroska.org


From steve.lhomme at free.fr  Tue Feb 18 13:59:00 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Tue, 18 Feb 2003 13:59:00 +0100 (CET)
Subject: [matroska-devel] Audio ACM compatibility
Message-ID: <1045573140.3e522e14cea52@imp.free.fr>


 <ChrHJW_work> no MS compatibility mode for audio guys !
 <myFUN> but ...
 <BlackSun> or wFormatTag
 <ChrHJW_work> but ?
 <ChrHJW_work> Cyrius, misunderstanding ?
 <ChrHJW_work> the plan for audio is to use native matroska IDs from the start
 <ChrHJW_work> A_MPEGLAYER3 for Mp3
 <ChrHJW_work> A_DOL_AC3 for AC3
 <ChrHJW_work> A_VORBIS for Vorbis
 <myFUN> for usage of exsiting filters the parser needs the wFormatTag or GUID
 <ChrHJW_work> A_MUSEPACK/MPC for MPC
 <ChrHJW_work> yes Jan, here is how we do it until we dont have UCI plugins :
 <myFUN> that means i must hardcode a list into the parser for mapping those
strings to GUIDs
 <ChrHJW_work> we will backup the WAVEFORMATEX structure in KaxCodecPrivateData
[13:22] * BlackSun put his nose in the story
 <myFUN> ok
 <BlackSun> but the DSF need to provide a wFormatTag or a GUID
 <ChrHJW_work> not for the time being, as we can be sure all file creation apps
will have this backup of WAVEFORMATEX

2 reasons why it's not good :
- we will never know all the existing ACM codec. So one way or another we'll
have to support WAVEFORMATEX someday
- putting WAVEFORMATEX in KaxCodecPrivate is very bad, because some (most)
(native) codec don't require it, and encoding apps will have to create one anyway...

Remember we're not building smething for a demo and change everything after !!!
We're building something that is going to last. So please stop doing this kind
of ugly hack !
http://www.matroska.org


From moritz at bunkus.org  Tue Feb 18 14:20:13 2003
From: moritz at bunkus.org (Moritz Bunkus)
Date: Tue, 18 Feb 2003 14:20:13 +0100
Subject: [matroska-devel] Re: Audio ACM compatibility
In-Reply-To: <1045573140.3e522e14cea52@imp.free.fr>
References: <1045573140.3e522e14cea52@imp.free.fr>
Message-ID: <20030218132013.GA17832@bunkus.org>

An embedded and charset-unspecified text was scrubbed...
Name: not available
URL: <http://lists.matroska.org/pipermail/matroska-devel/attachments/20030218/f171f82c/attachment.ksh>

From steve.lhomme at free.fr  Tue Feb 18 14:34:00 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Tue, 18 Feb 2003 14:34:00 +0100 (CET)
Subject: [matroska-devel] Re: Audio ACM compatibility
In-Reply-To: <20030218132013.GA17832@bunkus.org>
References: <1045573140.3e522e14cea52@imp.free.fr> <20030218132013.GA17832@bunkus.org>
Message-ID: <1045575240.3e5236488a0cc@imp.free.fr>


En r?ponse ? Moritz Bunkus <moritz at bunkus.org>:

> Hi.
> 
> > Remember we're not building smething for a demo and change everything
> after !!!
> > We're building something that is going to last. So please stop doing
> this kind
> > of ugly hack !
> 
> So using A_MS/ACM is strongly discouraged and we should use A_* if
> there is one for the current audio codec. Then we store what private
> data the codec has in KaxCodecPrivate. This could be:

I agree with the 'if' but there is a 'else'. Else we use "A_MS/ACM" we don't
just drop an assertion saying this codec should not go in matroska...

>  - the data after the WAVEFORMATEX as given by the cbSize member

Why do you want to store a Microsoft structure in something that has *nothing*
to do with any Microsoft system (ie CodecID != A_MS/ACM) ?

>  - other data as produced by the audio codec, e.g. headers, comment
> and setup packets produced by the Vorbis encoder

Yes, native matroska IDs should define for each what to put in KaxCodecPrivate.
We need to have a list of these IDs and the description of what to put in the
KaxCodecPrivate field.

> All fields of WAVEFORMATEX can be reconstructed from the Matroska
> elements, even the wFormatTag, you just need a mapping from the
> KaxCodecID to the wFormatTags.

That's it.

> So how do we save more than one packet in KaxCodecPrivate? As
> mentioned
> Vorbis needs three packets. So we have three possibilities:
> 
>  - create sub elements for KaxCodecPrivate, insert as many as you need
> and define the order in which they have to appear (for Vorbis it's
> easy: just take the order the Vorbis headers appear in an Ogg file:
> headers, comments, setup data)
>  - insert as many KaxCodecPrivate elements as you need and define the
> order in which they appear
>  - use a well-known struct and save that in KaxCodecPrivate, e.g.
> (pseudocode) 
> int32 length1;
> char data1[length1];
> int32 length2;
> char data2[length2];
> int32 length3;
> char data3[length3];
> int32 length4; // stop when a length field is 0
> 
> What do you propose?

I really prefer the last option ! The other ones make things complicated for no
reason.
http://www.matroska.org


From moritz at bunkus.org  Tue Feb 18 14:43:32 2003
From: moritz at bunkus.org (Moritz Bunkus)
Date: Tue, 18 Feb 2003 14:43:32 +0100
Subject: [matroska-devel] Re: Audio ACM compatibility
In-Reply-To: <1045575240.3e5236488a0cc@imp.free.fr>
References: <1045573140.3e522e14cea52@imp.free.fr> <20030218132013.GA17832@bunkus.org> <1045575240.3e5236488a0cc@imp.free.fr>
Message-ID: <20030218134332.GD17832@bunkus.org>

An embedded and charset-unspecified text was scrubbed...
Name: not available
URL: <http://lists.matroska.org/pipermail/matroska-devel/attachments/20030218/8754c8f0/attachment.ksh>

From steve.lhomme at free.fr  Tue Feb 18 14:55:20 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Tue, 18 Feb 2003 14:55:20 +0100 (CET)
Subject: [matroska-devel] Re: Audio ACM compatibility
In-Reply-To: <20030218134332.GD17832@bunkus.org>
References: <1045573140.3e522e14cea52@imp.free.fr> <20030218132013.GA17832@bunkus.org> <1045575240.3e5236488a0cc@imp.free.fr> <20030218134332.GD17832@bunkus.org>
Message-ID: <1045576520.3e523b48c0412@imp.free.fr>


En r?ponse ? Moritz Bunkus <moritz at bunkus.org>:

> Hi.
> 
> > I agree with the 'if' but there is a 'else'. Else we use "A_MS/ACM" we
> don't
> > just drop an assertion saying this codec should not go in
> matroska...
> 
> if (codecid = map_codec_format_tag_to_matroska_id(format_tag) !=
>     "NOTFOUND")
>   use(codecid);
> else {
>   use("A_MS/ACM");
>   somehow_store_the_format_tag();
> }
> 
> ?

Yes !

> > >  - the data after the WAVEFORMATEX as given by the cbSize member
> > 
> > Why do you want to store a Microsoft structure in something that has
> *nothing*
> > to do with any Microsoft system (ie CodecID != A_MS/ACM) ?
> 
> I don't want to store the struct at all. But is not the data AFTER the
> structure something that the codec needs for e.g. initialisation? I'm
> not so firm in those MS structs, but it's only this private data that
> I want to keep.

I understand but is it really worth saving 10 or 20 octets in the file, when the
ACM driver (or an AVI file) gives you the structure already filled ? I
personally prefer to lose a little amount of data and be sure it will always
work without any problem (or extra code). (same idea for video)

> So we also have to specifiy the endianess. (Just popped into my mind
> ;))

No, the data for V_MS/VFW/FOURCC and A_MS/ACM are obviously in little endian.
That would not make sense to turn them into big endian, because it will not very
likely play on anything else than an IA32 CPU. It's a structure from the Windows
world, so it's little endian.
http://www.matroska.org


From moritz at bunkus.org  Tue Feb 18 15:20:53 2003
From: moritz at bunkus.org (Moritz Bunkus)
Date: Tue, 18 Feb 2003 15:20:53 +0100
Subject: [matroska-devel] Re: Audio ACM compatibility
In-Reply-To: <1045576520.3e523b48c0412@imp.free.fr>
References: <1045573140.3e522e14cea52@imp.free.fr> <20030218132013.GA17832@bunkus.org> <1045575240.3e5236488a0cc@imp.free.fr> <20030218134332.GD17832@bunkus.org> <1045576520.3e523b48c0412@imp.free.fr>
Message-ID: <20030218142053.GF17832@bunkus.org>

An embedded and charset-unspecified text was scrubbed...
Name: not available
URL: <http://lists.matroska.org/pipermail/matroska-devel/attachments/20030218/9682f5cd/attachment.ksh>

From steve.lhomme at free.fr  Tue Feb 18 15:53:05 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Tue, 18 Feb 2003 15:53:05 +0100 (CET)
Subject: [matroska-devel] Re: Audio ACM compatibility
In-Reply-To: <20030218142053.GF17832@bunkus.org>
References: <1045573140.3e522e14cea52@imp.free.fr> <20030218132013.GA17832@bunkus.org> <1045575240.3e5236488a0cc@imp.free.fr> <20030218134332.GD17832@bunkus.org> <1045576520.3e523b48c0412@imp.free.fr> <20030218142053.GF17832@bunkus.org>
Message-ID: <1045579985.3e5248d1d1f62@imp.free.fr>


En r?ponse ? Moritz Bunkus <moritz at bunkus.org>:

> So we should keep WAVEFORMATEX/BITMAPINFOHEADER for V_MS/PCM/FOURCC
> and A_MS/ACM?

Yes.
 
> No, you're mixing things up here. I was talking about Vorbis with a
> CodecID of A_VORBIS. This is not the MS compat mode, so endianess IS
> important.

OK
 
> Of course we could use this structure in both cases - in the MS compat
> case with A_MS/..., V_MS/... and for the 'native' cases like A_VORBIS.
> Then KaxCodecPrivate would have the same structure.
> 
> For A_MS/ACM the first element would be WAVEFORMATEX. No other
> elements
> needed.
> 
> For V_MS/PCM/FOURCC the first element would be BITMAPHEADERINFO. No
> other elements needed.
> 
> For A_VORBIS the first element would be the headers, the second the
> comments and the third element would be the codec setup data.

OK, that's all great :)

I'm going to make a quick webpage that sums this up (maybe with the structures),
hopefully someone will continue to update as more codec are supported ;)

For Vorbis, do we have to set the endianess ? Can these structures in Vorbis be
either big endian or little endian ? (that would be a strange format indeed)
http://www.matroska.org


From moritz at bunkus.org  Tue Feb 18 15:51:52 2003
From: moritz at bunkus.org (Moritz Bunkus)
Date: Tue, 18 Feb 2003 15:51:52 +0100
Subject: [matroska-devel] Re: Audio ACM compatibility
In-Reply-To: <1045579985.3e5248d1d1f62@imp.free.fr>
References: <1045573140.3e522e14cea52@imp.free.fr> <20030218132013.GA17832@bunkus.org> <1045575240.3e5236488a0cc@imp.free.fr> <20030218134332.GD17832@bunkus.org> <1045576520.3e523b48c0412@imp.free.fr> <20030218142053.GF17832@bunkus.org> <1045579985.3e5248d1d1f62@imp.free.fr>
Message-ID: <20030218145152.GH17832@bunkus.org>

An embedded and charset-unspecified text was scrubbed...
Name: not available
URL: <http://lists.matroska.org/pipermail/matroska-devel/attachments/20030218/e345b5cd/attachment.ksh>

From chris at wiesneronline.net  Tue Feb 18 17:33:02 2003
From: chris at wiesneronline.net (Christian HJ Wiesner)
Date: Tue, 18 Feb 2003 17:33:02 +0100
Subject: [matroska-devel] Re: Audio ACM compatibility
In-Reply-To: <20030218145152.GH17832@bunkus.org>
References: <1045573140.3e522e14cea52@imp.free.fr> <20030218132013.GA17832@bunkus.org> <1045575240.3e5236488a0cc@imp.free.fr> <20030218134332.GD17832@bunkus.org> <1045576520.3e523b48c0412@imp.free.fr> <20030218142053.GF17832@bunkus.org> <1045579985.3e52 <20030218145152.GH17832@bunkus.org>
Message-ID: <3E52603E.5040406@wiesneronline.net>

Moritz Bunkus wrote:

>Hi.
>  
>
>>I'm going to make a quick webpage that sums this up (maybe with the structures),
>>hopefully someone will continue to update as more codec are supported ;)
>>    
>>
>
>Great :) Perhaps you could also include a link to the posting on
>corecodec in which Christian listed all known CodecIDs so that the
>reader can actually see what we're talking about? It's...
>
I will attach the text of the code including the tags from the original 
thread in the post, as i think we should upload it to the website directly.

Please note that i made some changes !!!

Regards Christian :

List :

b][i]matroska[/i][/b] codec/compression format ident string : 16 Bytes 

1. 'V_RGB_24' : RGB, 24 Bit

2. V_YUV_32' : YUV, 32 Bit

3. V_YV2_32 : YV2, 32 Bit

etc. .. too lazy to list all colourspaces :D ... somebody got a list ?

11. 'V_MS/VFW/FOURCC' : Unknown codec, probably not in matroska native 
codec list, see codec 'private' data and use suitable decoder based on 
FourCC code ( former : MCF-A stream ) ; stream is transmuxed from AVI or 
OGM, muxed from DirectShow or created with an existing VfW codec from 
VdubMod or the like

12. 'V_MS/DSHOW/GUID' : Unknown codec, probably not in matroska native 
codec list, see codec 'private' data and use suitable decoder based on 
GUID  ( Formerly : MCF-A stream, also for ACM audio codecs ) ; stream is 
transmuxed from AVI ( breaking specs ) , OGM or muxed via DirectShow

13. 'V_MPEG4IS0_SP' : Video, MPEG4ISO simple profile ( DivX4 ) ; stream 
was created via UCI codec or transmuxed from MP4, not simply transmuxed 
from AVI ( but it may be possible to convert a MPEG4 video stream coming 
from an AVI, with special tools

14. 'V_MPEG4IS0_SAP' : Video, MPEG4ISO simple advanced profile ( DivX5, 
XviD ) ; stream was created ... ( see above )

15. 'V_MPEG4IS0_AP' : Video, MPEG4ISO advanced profile ; stream was 
created ... ( see above )

16. 'V_MSMPEG4' : Video, Microsoft MPEG4 V1/2/3 and derivates, means 
DivX3, Angelpotion, SMR, etc. ; stream was created using VfW codec or 
transmuxed from AVI

17. 'V_MPEG2' ; Video, MPEG 2

18. 'V_MPEG1' ; Video, MPEG 1

19. 'V_REALRV9' ; Video, Realmedia, RV 9

20. 'V_QUICKTIME/FOURCC' ; Video, Quicktime, QT FourCC ; anybody aware 
of QT codecs that dont have a FourCC ?

21. 'V_MSWMV' ; Video, Microsoft Video

22. 'V_INDEO5' ; Video, Indeo 5 ; transmuxed from AVI or created using 
VfW codec

23. 'V_MJPEGLL' ; Video, MJpeg Lossless

24. 'V_MJPEG' ; Video, MJpeg codec ( lossy mode, general )

25. 'V_MJPEG2000' ; Video, MJpeg 2000

26. 'V_DV_1' ; Video, DV Video , type 1 ( audio and video mixed )

27. 'V_DV_2' ; Video, DV Video , type 2 ( audio and video separate 
tracks, from AVI )

28. 'V_THEORA' ; Video, Ogg Theora

29. 'V_TARKIN' ; Video, Ogg Tarkin

30. 'V_ON2VP4' ; Video, ON2, VP4

31. 'V_ON2VP5' ; Video, ON2, VP5

32. 'V_3IVXD4' ; Video, 3ivX ( is D4 decoder downwards compatible ? )

33. 'V_SORENSEN' ; Video, Sorensen codec ; same here, how many versions 
are there ?

34. 'V_HUFFYUV' ; Video, HuffYuv, lossless ; auch als VfW m?glich

35. 'V_COREYUV' ; Video, CoreYuv, lossless ; auch als VfW m?glich

...... to be continued


Audio :

1. 'A_MS/ACM' ; Probably unknown audio codec, use M$ UUID to identify 
and call ACM codec or Dshow filter for decoding

2. 'A_VORBIS' ; Audio, Vorbis, created via UCI or transmuxed from OGG/OGM

3. 'A_MPEGLAYER3' ; Audio, MPEG 1, 2, 2.5 Layer 3 ( MP3 ) ; created via 
UCI or transmuxed from MP3, OGM or AVI

4. 'A_MPEGLAYER2' ; Audio, MPEG 1, 2 , 2.5 Layer 2 ( MP2 ) ; created via 
UCI ( tooLame ) or transmuxed from MPEG

5. 'A_PCM16IN' ; Audio, PCM, Integer 16 Bit

6. 'A_PCM24IN' ; Audio, PCM, Integer 24 Bit

7. 'A_PCM24FP' ; Audio, PCM, 24 Bit Floating Point

8. 'A_PCM32FP' ; Audio, PCM, 32 Bit Floating Point

9. 'A_FLAC' ; Audio, FLAC, ( lossless )

10. 'A_MPEG2_AAC' ; Audio, AAC, MPEG2 standard

11. 'A_MPEG4_AAC' ; Audio, AAC , MPEG4 standard

12. 'A_DOL_AC3' ; Audio, AC3

13. 'A_MPC' ; Audio, MPC ( musepack )

14. 'A_MSWMA' ; Audio, Microsoft Media Audio

15. 'A_MONKEY' ; Monkey lossless audio codec ( .ape )

etc. p.p.


Subtitles :

1. 'S_USF' : Universal Subtitles Format

2. 'S_SSA' : Fansubber format

3. 'S_VOBSUB' : Vobsub format

4. 'S_ASS' : Advanced Subtitles Format


http://www.matroska.org


From chris at matroska.org  Tue Feb 18 18:00:31 2003
From: chris at matroska.org (Christian HJ Wiesner)
Date: Tue, 18 Feb 2003 18:00:31 +0100
Subject: [matroska-devel] Re: Audio ACM compatibility
In-Reply-To: <3E52603E.5040406@wiesneronline.net>
References: <1045573140.3e522e14cea52@imp.free.fr> <20030218132013.GA17832@bunkus.org> <1045575240.3e5236488a0cc@imp.free.fr> <20030218134332.GD17832@bunkus.org> <1045576520.3e523b48c0412@imp.free.fr> <20030218142053.GF17832@bunkus.org> <1045579985.3e52 <20030218145152.GH17832@bunkus.org> <3E52603E.5040406@wiesneronline.net>
Message-ID: <3E5266AF.7030400@matroska.org>


Christian HJ Wiesner wrote:

>I will attach the text of the code including the tags from the original 
>thread in the post, as i think we should upload it to the website directly.
>
>Please note that i made some changes !!!
>
>Regards Christian :
>
>List :
>
>b][i]matroska[/i][/b] codec/compression format ident string : 16 Bytes 
>
>1. 'V_RGB_24' : RGB, 24 Bit
>
>2. V_YUV_32' : YUV, 32 Bit
>
>3. V_YV2_32 : YV2, 32 Bit
>  
>
An interesting question was asked by Mosu :

Why do we need the KaxVideoColourSpace element at all ? We can put the 
relevant info into the KaxCodecID element easily ? Or is the element 
used for other video codecs also, describing what colour space there 
content is ? If so then i guess we should use the existing Colour Space 
element and change the Codec ID to something simple like

'V_UNCOMPRESSED'   ? 

What do you all think ?

Christian

http://www.matroska.org


From steve.lhomme at free.fr  Tue Feb 18 18:11:53 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Tue, 18 Feb 2003 18:11:53 +0100 (CET)
Subject: [matroska-devel] Re: Audio ACM compatibility
In-Reply-To: <3E5266AF.7030400@matroska.org>
References: <1045573140.3e522e14cea52@imp.free.fr> <20030218132013.GA17832@bunkus.org> <1045575240.3e5236488a0cc@imp.free.fr> <20030218134332.GD17832@bunkus.org> <1045576520.3e523b48c0412@imp.free.fr> <20030218142053.GF17832@bunkus.org> <1045579985.3e52 <20030218145152.GH17832@bunkus.org> <3E52603E.5040406@wiesneronline.net> <3E5266AF.7030400@matroska.org>
Message-ID: <1045588313.3e52695980975@imp.free.fr>


En r?ponse ? Christian HJ Wiesner <chris at matroska.org>:

> 
> Christian HJ Wiesner wrote:
> 
> >I will attach the text of the code including the tags from the original
> 
> >thread in the post, as i think we should upload it to the website
> directly.
> >
> >Please note that i made some changes !!!
> >
> >Regards Christian :
> >
> >List :
> >
> >b][i]matroska[/i][/b] codec/compression format ident string : 16 Bytes
> 
> >
> >1. 'V_RGB_24' : RGB, 24 Bit
> >
> >2. V_YUV_32' : YUV, 32 Bit
> >
> >3. V_YV2_32 : YV2, 32 Bit
> >  
> >
> An interesting question was asked by Mosu :
> 
> Why do we need the KaxVideoColourSpace element at all ? We can put the
> 
> relevant info into the KaxCodecID element easily ? Or is the element 
> used for other video codecs also, describing what colour space there 
> content is ? If so then i guess we should use the existing Colour Space
> 
> element and change the Codec ID to something simple like
> 
> 'V_UNCOMPRESSED'   ? 
> 
> What do you all think ?

Well, I just took the field from MCF and put it in matroska...
I think we discussed than on #mcf a long time ago and I didn't understand :)
If you hae old logs, you might investigate in there.
http://www.matroska.org


From chris at wiesneronline.net  Tue Feb 18 18:35:51 2003
From: chris at wiesneronline.net (Christian HJ Wiesner)
Date: Tue, 18 Feb 2003 18:35:51 +0100
Subject: [matroska-devel] Re: Audio ACM compatibility
In-Reply-To: <1045588313.3e52695980975@imp.free.fr>
References: <1045573140.3e522e14cea52@imp.free.fr> <20030218132013.GA17832@bunkus.org> <1045575240.3e5236488a0cc@imp.free.fr> <20030218134332.GD17832@bunkus.org> <1045576520.3e523b48c0412@imp.free.fr> <20030218142053.GF17832@bunkus.org> <1045579985.3e52 <20030218145152.GH17832@bunkus.org> <3E52603E.5040406@wiesneronline.net> <3E5266AF.7030400@matroska.org> <1045588313.3e52695980975@imp.free.fr>
Message-ID: <3E526EF7.2000504@wiesneronline.net>


Steve Lhomme wrote:

>En r?ponse ? Christian HJ Wiesner <chris at matroska.org>:
>  
>
>>An interesting question was asked by Mosu :
>>
>>Why do we need the KaxVideoColourSpace element at all ? We can put the
>>
>>relevant info into the KaxCodecID element easily ? Or is the element 
>>used for other video codecs also, describing what colour space there 
>>content is ? If so then i guess we should use the existing Colour Space
>>
>>element and change the Codec ID to something simple like
>>
>>'V_UNCOMPRESSED'   ? 
>>
>>What do you all think ?
>>    
>>
>
>Well, I just took the field from MCF and put it in matroska...
>I think we discussed than on #mcf a long time ago and I didn't understand :)
>If you hae old logs, you might investigate in there.
>http://www.matroska.org
>

Well, i am not complete certain here but i guess that at least some 
codecs can work in the YUV or in the RGB colour space. Now, to be able 
to handle the content correctly you would have to know what colour space 
was used for this encoding, and if i am not completely mistaken this 
info is also to be found somewhere in the BITMAPINFOHEADER ...... can 
anybody confirm ? Cyrius ?

As we plan to replace this M$ structure with our own elements, at least 
for 'native' streams, this would mean we need such an element and use a 
simple codec ID like 'V_UNCOMPRESSED' instead, and fill the colour space 
into the matroska KaxVideoColourSpace element .... Cyrius, is that true 
what i say above ???

Christian


http://www.matroska.org


From suiryc at yahoo.com  Tue Feb 18 20:40:57 2003
From: suiryc at yahoo.com (Cyrius)
Date: Tue, 18 Feb 2003 11:40:57 -0800 (PST)
Subject: [matroska-devel] Re: Audio ACM compatibility
In-Reply-To: <3E526EF7.2000504@wiesneronline.net>
Message-ID: <20030218194057.17553.qmail@web12907.mail.yahoo.com>


--- Christian HJ Wiesner <chris at wiesneronline.net>
wrote:
> 
> Steve Lhomme wrote:
> 
> >En r?ponse ? Christian HJ Wiesner
> <chris at matroska.org>:
> >  
> >
> >>An interesting question was asked by Mosu :
> >>
> >>Why do we need the KaxVideoColourSpace element at
> all ? We can put the
> >>
> >>relevant info into the KaxCodecID element easily ?
> Or is the element 
> >>used for other video codecs also, describing what
> colour space there 
> >>content is ? If so then i guess we should use the
> existing Colour Space
> >>
> >>element and change the Codec ID to something
> simple like
> >>
> >>'V_UNCOMPRESSED'   ? 
> >>
> >>What do you all think ?
> >>    
> >>
> >
> >Well, I just took the field from MCF and put it in
> matroska...
> >I think we discussed than on #mcf a long time ago
> and I didn't understand :)
> >If you hae old logs, you might investigate in
> there.
> >http://www.matroska.org
> >
> 
> Well, i am not complete certain here but i guess
> that at least some 
> codecs can work in the YUV or in the RGB colour
> space. Now, to be able 
> to handle the content correctly you would have to
> know what colour space 
> was used for this encoding, and if i am not
> completely mistaken this 
> info is also to be found somewhere in the
> BITMAPINFOHEADER ...... can 
> anybody confirm ? Cyrius ?

Hmm if you are talking of encoded video then I don't
think the BITMAPINFOHEADER contains any information of
the colorspace used (well there is still the case of
HuffYUV that uses the biBitCount field for its own
settings), but I'm no codec video nor MS expert here
:p.
The biCompression field contains the FourCC, and
biBitCount the number of bits per pixel. I think that
biBitCount isn't really useful with compressed streams
because the data Windows will really use are somewhere
further in the process (after the codec has decoded
the frames) where there is another  BITMAPINFOHEADER
filled by the codec this time (so the codec will tell
Windows what colorspace it is  decoding the data to).
That's why HuffYUV misuse this field ;)

The other fields in the structure only give
information on the size of video etc.

> As we plan to replace this M$ structure with our own
> elements, at least 
> for 'native' streams, this would mean we need such
> an element and use a 
> simple codec ID like 'V_UNCOMPRESSED' instead, and
> fill the colour space 
> into the matroska KaxVideoColourSpace element ....
> Cyrius, is that true 
> what i say above ???

The problem is that there are a lot of colorspaces,
some having only a few differences (e.g. the order in
which it stores the data etc).
An example :
I420 and YV12 both only need 12 bits per pixel, and
IIRC the only difference between the two is the order
in which values are stored (i.e. only a value
swapping).
You can see this page to have an overview of those
formats (mainly YUV ones) :
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwmt/html/YUVFormats.asp
You will see that some formats only differs by storing
order : some store all values of a row (Chroma/Lumi)
at once, some 'interlace' the values ...

__________________________________________________
Do you Yahoo!?
Yahoo! Shopping - Send Flowers for Valentine's Day
http://shopping.yahoo.com
http://www.matroska.org


From thanatos666 at gmx.net  Tue Feb 18 16:53:24 2003
From: thanatos666 at gmx.net (thana)
Date: Tue, 18 Feb 2003 16:53:24 +0100
Subject: [matroska-devel] EDC/ECC
Message-ID: <b2tkrd$19j$1@main.gmane.org>

hi again..

i had some time to think about EDC/ECC Elements, so i've read through the
old mcf-mailing lists and the mplayer-devel mailing list and did some
research on the web.. as far as i've seen there is only EDC defined yet,
using the crc-32 algorithm. someone has mentioned the use of crc-32 for ECC
too, but i think it's not very good for that purpose and isn't used anywhere
i can think of.

so far the best FEC (forward error correction) algorithm still seems to be
the Reed-Solomon code that is used on CD for EDC and ECC (CIRC - Cross
Interleaved Reed-Solomon Code) and also on DVD (RSPC - Reed Solomon Product
Code). one advantage of RS is that it is quite good at correcting
burst-errors, and i think that's most important for our uses since single
bit errors will probably get corrected by the the lower EDC-Layers of the
CD/HDD respectively the TCP-layers on networks. (UDP is another story, but
in that case FEC could be implemented on the streaming server as an
additional layer, or the server uses only matroska files that are already
ECC-ified, and then the client has to do error checking on the fly, or.. -
i'm going off-topic :)). for the purpose of downloading the file over a p2p
network EDC-checking should be enough, so that corrupted parts gets
redownloaded, which requires support of the p2p-program - but i think this
has already been mentioned some times here.

a good thing of RS-code is the ability to scale quite well.. you can use any
arbitrary amount of parity bytes.. f.e. a 255/223 RS-code (255 bytes total /
223 bytes data / 32 bytes Parity) will give us exactly 100MB overhead on a
700MB file.. 255/251 will give only 12,5 MB overhead.. so 1 byte parity
overhead equates to 2,73-3,12MB, which should be good enough regarding
granularity to fill an XCD..

I have already found some free code (GPL) for en/decoding of RS in C.. there
is also a C++ version, but that is not optimized for speed.. and yes, speed
IS a concern in this regard, from what i've learned, encoding should be
quite fast, but decoding is highly complex and speeds could be as low as
1MB/s on a 1GHz machine for a 255/223 RS-code.. also the speed depends on
the amount of parity bytes, a 255/251 RS-code is roughly 10 times faster as
255/223.. also, because of those speed restrictions, i think EDC-elements
should be preserved in the file even when ECC-elements exist..

regarding the placing of the ECC-elements in a matroska-file: should we put
them after every block, every cluster or every n clusters (f.e. after every
complete GOP-sequence, before the next keyframe)? or any of them depending
on the size of the blocks/clusters? are there upper/lower limits on how big
a block/cluster element can be? as i think an ECC-element for less data than
223 bytes would be quite inefficient..

i had some more questions about reindexing and reordering of matroska-files,
but i will come to those later, when i have more time to think about those..

thana




http://www.matroska.org


From steve.lhomme at free.fr  Tue Feb 18 17:30:10 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Tue, 18 Feb 2003 17:30:10 +0100 (CET)
Subject: [matroska-devel] Re: EDC/ECC
In-Reply-To: <b2tkrd$19j$1@main.gmane.org>
References: <b2tkrd$19j$1@main.gmane.org>
Message-ID: <1045585810.3e525f9286d9e@imp.free.fr>


En r?ponse ? thana <thanatos666 at gmx.net>:

> hi again..

Hi thana,
 
> so far the best FEC (forward error correction) algorithm still seems to
> be
> the Reed-Solomon code that is used on CD for EDC and ECC (CIRC - Cross
> Interleaved Reed-Solomon Code) and also on DVD (RSPC - Reed Solomon
> Product

Did you check the webpages of Frank Klemm that deal with FEC ? I'm not sure he's
using the RS algorithm.

> network EDC-checking should be enough, so that corrupted parts gets
> redownloaded, which requires support of the p2p-program - but i think
> this
> has already been mentioned some times here.

Well, there are 2 things that are handled differently. The ECC inside matroska
and the ECC outside matroska.

In the case of a P2P download, for the P2P program to be able to download a
corrupted part it only needs EDC from the matroska file and the portion of data
to download. If internal ECC is used, you can reconstruct the data if they are
corrupted (that's why keeping the EDC is a good idea), but you'll never have
100% recovery. I'm not sure if ECC is necessary in this case.

The ECC outside matroska is dealt at the transport level : HD, TCP stream, UDP
stream, etc. Some of them (like UDP) are not very reliable. And they all have
different unreliability characteristics (UDP is more subject to data loss than
data corruption, unlike the other ones). That's why it's not covered by the
matroska specs.

We've started discussing about a UDP transport layer based on EBML + ECC + EDC
but we have freezed it for now because that's a huge project.
 
> a good thing of RS-code is the ability to scale quite well.. you can use
> any
> arbitrary amount of parity bytes.. f.e. a 255/223 RS-code (255 bytes
> total /
> 223 bytes data / 32 bytes Parity) will give us exactly 100MB overhead on
> a
> 700MB file.. 255/251 will give only 12,5 MB overhead.. so 1 byte
> parity
> overhead equates to 2,73-3,12MB, which should be good enough regarding
> granularity to fill an XCD..

I think the system of Frank Klemm is very flexible too.

> regarding the placing of the ECC-elements in a matroska-file: should we
> put
> them after every block, every cluster or every n clusters (f.e. after
> every
> complete GOP-sequence, before the next keyframe)? or any of them
> depending
> on the size of the blocks/clusters? are there upper/lower limits on how
> big
> a block/cluster element can be? as i think an ECC-element for less data
> than
> 223 bytes would be quite inefficient..

The CRC can be placed every where in the file and applies for all the following
data at the level where it's found.
For example if you have :
Cluster
  CRC
  Timecode
  BlockGroup
   Block
end

The CRC is computed with the EBML head+data of Timecode and Blockgroup (and
everything inside).

There are virtually no limit to a Cluster, although we advise not to make it
bigger than 2MB when possible.

For the CRC, we have 2 options (at least) :
- create it at fixed position (start of a Cluster) everywhere in the file
- post process an "unprotected" file and add CRC at all key positions in the
file to fit a specified final size

The second can apply to the first file too...
The first one probably makes sense during live capture/editing. While the second
is better to prepare a file for storing/streaming. (ECC could also be a good
addition there).
http://www.matroska.org


From Paul at msn.com  Wed Feb 19 06:08:27 2003
From: Paul at msn.com (Pamel)
Date: Tue, 18 Feb 2003 23:08:27 -0600
Subject: [matroska-devel] Re: EDC/ECC
References: <b2tkrd$19j$1@main.gmane.org>
Message-ID: <b2v3fn$80p$1@main.gmane.org>

"thana" <thanatos666 at gmx.net> wrote
> i had some time to think about EDC/ECC Elements, so i've read through the
> old mcf-mailing lists and the mplayer-devel mailing list and did some
> research on the web.. as far as i've seen there is only EDC defined yet,
> using the crc-32 algorithm. someone has mentioned the use of crc-32 for
ECC
> too, but i think it's not very good for that purpose and isn't used
anywhere
> i can think of.

I would encourage you to look at this project.
http://parchive.sourceforge.net/

While it was intended for use at the file level, it is still a good resource
for 'Reed-Soloman' error correction.  I think that they also have a
reference implementation available for variable sized data chunks (but I
can't check because sf.net is down again.)


Pamel



http://www.matroska.org


From moritz at bunkus.org  Tue Feb 18 18:46:27 2003
From: moritz at bunkus.org (Moritz Bunkus)
Date: Tue, 18 Feb 2003 18:46:27 +0100
Subject: [matroska-devel] a simple subtitle format
Message-ID: <20030218174627.GA23585@bunkus.org>

An embedded and charset-unspecified text was scrubbed...
Name: not available
URL: <http://lists.matroska.org/pipermail/matroska-devel/attachments/20030218/f66ad3d0/attachment.ksh>

From spyder482 at yahoo.com  Tue Feb 18 22:27:47 2003
From: spyder482 at yahoo.com (John Cannon)
Date: Tue, 18 Feb 2003 15:27:47 -0600
Subject: [matroska-devel] Re: a simple subtitle format
References: <20030218174627.GA23585@bunkus.org>
Message-ID: <b2u8f9$69h$1@main.gmane.org>


"Moritz Bunkus" <moritz at bunkus.org> wrote in message
news:20030218174627.GA23585 at bunkus.org...
> Hi.
>
> After some reading on USF and a bit of discussion in #matroska I still
> want a simple subtitle format like SubRip to be stored in Matroska in a
> simple manner.

I agree

> 3. Somehow store the duration.
maybe an unsigned 16/32 bit int?  If it is needed beyond that, just add
another block.

> 4. Use ONLY the text lines as the Block's data ("He wanted...").
>
> The duration must be stored somehow. Pamel proposed to store it in a
> new 'KaxDuration' element for the Block (along with the Block's
> timestamp). The duration could be used for other things as well. It can
> be optional.

Hmmm maybe a better idea :)

Spyder



http://www.matroska.org


From Paul at msn.com  Wed Feb 19 06:29:25 2003
From: Paul at msn.com (Pamel)
Date: Tue, 18 Feb 2003 23:29:25 -0600
Subject: [matroska-devel] Re: a simple subtitle format
References: <20030218174627.GA23585@bunkus.org> <b2u8f9$69h$1@main.gmane.org>
Message-ID: <b2v4n1$b90$1@main.gmane.org>

"John Cannon" <spyder482 at yahoo.com> wrote
> "Moritz Bunkus" <moritz at bunkus.org> wrote in message
> > After some reading on USF and a bit of discussion in #matroska I still
> > want a simple subtitle format like SubRip to be stored in Matroska in a
> > simple manner.
>
> I agree

I always figured that people who made the 'codecs' for subtitles would store
the subtitles in Matroska however they like.  I really think that this is
outside of the spec of the container.  However, giving a few recommendations
would be good so that things are done a little more universaly across the
board.

> > The duration must be stored somehow. Pamel proposed to store it in a
> > new 'KaxDuration' element for the Block (along with the Block's
> > timestamp). The duration could be used for other things as well. It can
> > be optional.
>
> Hmmm maybe a better idea :)

Errr.... What I said was there are three options.  But, I guess there are
four.

1.  Leave the duration time in the block as part of the text and let the
subtitle 'codec' parse it.  (Easy)

2.  Create a null block at the appropriate time to clear out the subtitle.
(Simple, yet elegant)

3.  Create a new element "BlockDuration" under "BlockAdditional" that tells
the duration of the block.  (Adding yet another element to matroska?  Well,
thats why it uses EBML.  This is the coolest method)

4.  Change the block structure for subtitles to include a Timecode AND
Duration numbers.  (Does anyone really want another revision of the basic
Block design?)

I think what Moritz is refering to is method 3.  I actually meant to mention
this to someone quite awhile ago, but forgot.  It could be useful for many
things other than subtitles.  The main problem is how do we pass this info
to the subtitle filter in Windows?  (I realize it wouldn't be a problem with
mplayer in linux)  We would probably have to hardcode it into libmatroska
until something like UCI or gstreamer supported it.


Pamel



http://www.matroska.org


From moritz at bunkus.org  Wed Feb 19 09:17:29 2003
From: moritz at bunkus.org (Moritz Bunkus)
Date: Wed, 19 Feb 2003 09:17:29 +0100
Subject: [matroska-devel] Re: a simple subtitle format
In-Reply-To: <b2v4n1$b90$1@main.gmane.org>
References: <20030218174627.GA23585@bunkus.org> <b2u8f9$69h$1@main.gmane.org> <b2v4n1$b90$1@main.gmane.org>
Message-ID: <20030219081729.GB3472@bunkus.org>

An embedded and charset-unspecified text was scrubbed...
Name: not available
URL: <http://lists.matroska.org/pipermail/matroska-devel/attachments/20030219/95edd6dc/attachment.ksh>

From steve.lhomme at free.fr  Wed Feb 19 09:39:01 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Wed, 19 Feb 2003 09:39:01 +0100 (CET)
Subject: [matroska-devel] Re: a simple subtitle format
In-Reply-To: <20030219081729.GB3472@bunkus.org>
References: <20030218174627.GA23585@bunkus.org> <b2u8f9$69h$1@main.gmane.org> <b2v4n1$b90$1@main.gmane.org> <20030219081729.GB3472@bunkus.org>
Message-ID: <1045643941.3e5342a5411da@imp.free.fr>


En r?ponse ? Moritz Bunkus <moritz at bunkus.org>:

> Hi.
> 
> > I always figured that people who made the 'codecs' for subtitles would
> store
> > the subtitles in Matroska however they like.  I really think that this
> is
> > outside of the spec of the container.  However, giving a few
> recommendations
> > would be good so that things are done a little more universaly across
> the
> > board.
> 
> Well as I am the person who creates the mplayer support for the
> complete Matroska format I'll also have to handle the subtitle formats
> it can transport ;) And so far Christian has not listed a CodecID for
> such a simple format, so I just wanted to ask if we couldn't add it
> right now and define it the way we like it (mostly how to store the
> duration and the CodecID).
> 
> > 3.  Create a new element "BlockDuration" under "BlockAdditional" that
> tells
> > the duration of the block.  (Adding yet another element to matroska? 
> Well,
> > thats why it uses EBML.  This is the coolest method)
> 
> This is fine with me. And what I meant, yes. But if you want to store
> it in the text so that the Windows subtitle filter can read it easily
> it's no problem either, just chose
> 
> -----[cut]-------------------------------
> 1200
> The quick brown fox jumped
> over the lazy dog.
> A third line is also present.
> -----[cut]------------------------------
> 
> The first line is the duration in ms, the rest are the text lines.
> Each
> line is terminated by either DOS style line breaks (\n\r?) or by UNIX
> style line breaks (only \n, so the filter would just have to ignore
> \r).
> 
> Very easy to parse, hopefully solves your Windows API problem, trivial
> to implement, no changes to the Matroska specs necessary (apart from
> the CodecID - I still suggest 'S_SIMPLE').

I'm undecided on the BlockDuration field. But it could make sense, even for
video (remember the Diaporama codec I was talking about ?). So I think it can be
added. That would allow to cut a movie (with Diaporama) at the duration
bondaries (keeping the audio in the correct area, since the image transitions
could be linked to audio transitions).

> By the way. So far there's only KaxTrackVideo and KaxTrackAudio, but
> no
> KaxTrackSubtitles. Why? I guess it's just about priorities and/or lack
> of time :)

Exactly :) The same way there was no EbmlDate until yesterday :)
http://www.matroska.org


From shailesh.mistry at milan.eclipse.co.uk  Tue Feb 18 19:03:34 2003
From: shailesh.mistry at milan.eclipse.co.uk (Shailesh L Mistry)
Date: Tue, 18 Feb 2003 18:03:34 -0000
Subject: [matroska-devel] vc6 build
Message-ID: <b2ts94$b26$1@main.gmane.org>

Hi All,

Has anyone recently used the vc6 build?
I have tried to build  libmatroska/make/vc6/vc6.dsw but I get a whole stack
of errors.
Can someone please confirm they see the same thing.

Shelly.



http://www.matroska.org


From steve.lhomme at free.fr  Tue Feb 18 19:29:59 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Tue, 18 Feb 2003 19:29:59 +0100
Subject: [matroska-devel] Re: vc6 build
In-Reply-To: <b2ts94$b26$1@main.gmane.org>
References: <b2ts94$b26$1@main.gmane.org>
Message-ID: <3E527BA7.4090209@free.fr>


Shailesh L Mistry wrote:
> Hi All,
> 
> Has anyone recently used the vc6 build?
> I have tried to build  libmatroska/make/vc6/vc6.dsw but I get a whole stack
> of errors.
> Can someone please confirm they see the same thing.

I use it everyday.
What errors do you have ?

http://www.matroska.org


From shailesh.mistry at milan.eclipse.co.uk  Tue Feb 18 20:15:41 2003
From: shailesh.mistry at milan.eclipse.co.uk (Shailesh L Mistry)
Date: Tue, 18 Feb 2003 19:15:41 -0000
Subject: [matroska-devel] Re: vc6 build
References: <b2ts94$b26$1@main.gmane.org> <3E527BA7.4090209@free.fr>
Message-ID: <b2u0g7$1h0$1@main.gmane.org>

Hi Steve,

> I use it everyday.
> What errors do you have ?

The only ones that do compile are the static lib, test00, test6 and test8.
Listed below are the partial/complete listings for the other builds.

Shelly.


--------------------Configuration: Matroska DLL - Win32
Debug--------------------
Build : warning : failed to (or don't know how to) build
'C:\OpenSource\matroska\libmatroska\make\vc6\dll\Debug\matroska_dll.pch'
...
libmatroskad.dll - 4 error(s), 1 warning(s)


--------------------Configuration: Matroska LIB Dynamic - Win32
Debug--------------------
Build : warning : failed to (or don't know how to) build
'C:\OpenSource\matroska\libmatroska\src\KaxTypes.cpp'
Build : warning : failed to (or don't know how to) build
'C:\OpenSource\matroska\libmatroska\make\vc6\lib\dynamic\Debug\matroska_lib_
dynamic.pch'
...
matroska_lib_dynamic_debug.lib - 26 error(s), 2 warning(s)


--------------------Configuration: test0 - Win32 Debug--------------------
Compiling...
test0.cpp
c:\opensource\matroska\libmatroska\test\ebml\test0.cpp(44) : fatal error
C1083: Cannot open include file: 'StdIOCallback.hpp': No such file or
directory
Error executing cl.exe.

test0.exe - 1 error(s), 0 warning(s)


--------------------Configuration: test1 - Win32 Debug--------------------
Build : warning : failed to (or don't know how to) build
'C:\OpenSource\matroska\libmatroska\test\block\test1.cpp'
Compiling...
test1.cpp
fatal error C1083: Cannot open source file:
'C:\OpenSource\matroska\libmatroska\test\block\test1.cpp': No such file or
directory
Error executing cl.exe.

test1.exe - 1 error(s), 1 warning(s)


--------------------Configuration: test6c - Win32 Debug--------------------
Build : warning : failed to (or don't know how to) build
'C:\OpenSource\matroska\libmatroska\test\mux\test6.c'
Linking...

test6c.exe - 0 error(s), 1 warning(s)


--------------------Configuration: test8c - Win32 Debug--------------------
Build : warning : failed to (or don't know how to) build
'C:\OpenSource\matroska\libmatroska\test\mux\test8.c'
Linking...

test8c.exe - 0 error(s), 1 warning(s)




http://www.matroska.org


From steve.lhomme at free.fr  Tue Feb 18 20:32:02 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Tue, 18 Feb 2003 20:32:02 +0100
Subject: [matroska-devel] Re: vc6 build
In-Reply-To: <b2u0g7$1h0$1@main.gmane.org>
References: <b2ts94$b26$1@main.gmane.org> <3E527BA7.4090209@free.fr> <b2u0g7$1h0$1@main.gmane.org>
Message-ID: <3E528A32.7080802@free.fr>


Shailesh L Mistry wrote:
> Hi Steve,
> 
> 
>>I use it everyday.
>>What errors do you have ?
> 
> 
> The only ones that do compile are the static lib, test00, test6 and test8.
> Listed below are the partial/complete listings for the other builds.

Yes, I only keep the static Debug lib up to date, but it shouldn't be 
hard getting the other DSP projects in sync with this one.

If you find the time to do that, feel free to upload the result on CVS.

PS: EbmlDate is coming today and hopefully the classes for Cue handling too.

http://www.matroska.org


From shailesh.mistry at milan.eclipse.co.uk  Tue Feb 18 23:53:55 2003
From: shailesh.mistry at milan.eclipse.co.uk (Shailesh L Mistry)
Date: Tue, 18 Feb 2003 22:53:55 -0000
Subject: [matroska-devel] Re: vc6 build
References: <b2ts94$b26$1@main.gmane.org> <3E527BA7.4090209@free.fr> <b2u0g7$1h0$1@main.gmane.org> <3E528A32.7080802@free.fr>
Message-ID: <b2uddu$u4t$1@main.gmane.org>


> Steve Lhomme wrote :
> Yes, I only keep the static Debug lib up to date, but it shouldn't be
> hard getting the other DSP projects in sync with this one.
> If you find the time to do that, feel free to upload the result on CVS.

ok, just wanted to make sure I was not treading on anyone's toes.

Shelly.



http://www.matroska.org


From a.dramomoh at caramail.com  Wed Feb 19 05:32:18 2003
From: a.dramomoh at caramail.com (Ahmed  Momoh)
Date: Wed, 19 Feb 2003 04:32:18 -0000
Subject: [matroska-devel] CONFIDENTIAL
Message-ID: <20030219032528.433033908A4@turing.freelists.org>


Dear sir,

You may be surprised to receive this letter since you do not know me
personally. I am Mr Ahmed Momoh. I got your contact 
through the South African Information Exchange (S.A.I.E) in Johannesburg
and I decided to write to you for an assistance. 
My late father, 
Dr Smith Momoh, was among the few black Zimbabwean rich farmers murdered in
cold blood by the agents of the ruling 
government of President Robert Mugabe for his alleged support and sympathy
for the Zimbabwean Opposition party 
controlled by the whites. 

As a result of sequence persecution by the government of President Robert
Mugabe, I left for Amsterdam The Nederlands, 
with the Certificate of deposit which was issued to my father when he
deposited two trunk boxes with a Security Company 
here in Amsterdam. These boxes contain the sum of US$ 10 million but were
declared to the security company officials as 
containing African art for export to a foreign partner for security
reasons. 

I have visited the security company but was told that the deposit agreement
required the presence of the foreign partner on 
whose behalf the consignment was deposited before any application for the
clearance of the boxes will be considered. 
Therefore, I am contacting you to front you as the foreign partner to my
late father on whose behalf the consignment was 
deposited. I will require urgently your name, full contact address and
telephone/fax numbers.

Afterwards, this money shall be transferred to your account for investment
purposes. As soon as I receive your return mail 
indicating your willingness to assist me in this business, we shall discuss
what shall be your percentage fee for your 
assistance. 

Thanks and God bless 

Yours sincerely, 

Mr Ahmed Momoh 







http://www.matroska.org


From spyder482 at yahoo.com  Wed Feb 19 05:00:58 2003
From: spyder482 at yahoo.com (John Cannon)
Date: Tue, 18 Feb 2003 22:00:58 -0600
Subject: [matroska-devel] Re: CONFIDENTIAL
References: <20030219032528.433033908A4@turing.freelists.org>
Message-ID: <b2uvge$tfn$1@main.gmane.org>

Sir,

I am unsure of where you got my name or the email addresses you have been
using to contact me. Please stop.  I am not interested in this.  And as far
as your confidentiality, you just posted to a public mailing list.  I have
recieved your emails before and I did not reply because I am not interested.
This is not a good idea in my opinion.  Please take your business elsewhere.
This is a public mailing list for the Matroska project.  It is not to be
used for such contacts.

John Cannon
Matroska Developer
spyder482 at matroska.org



http://www.matroska.org


From spyder482 at yahoo.com  Wed Feb 19 05:07:35 2003
From: spyder482 at yahoo.com (John Cannon)
Date: Tue, 18 Feb 2003 22:07:35 -0600
Subject: [matroska-devel] Re: CONFIDENTIAL
References: <20030219032528.433033908A4@turing.freelists.org> <b2uvge$tfn$1@main.gmane.org>
Message-ID: <b2uvsu$uj1$1@main.gmane.org>

As I have searched the web I have found out that this is a long running
scam.  Please do not mail here again.  See references below:

http://www.scamorama.com/scam104.shtml

http://www.darwinsys.com/antispam/africa2.txt

http://www.sonic.net/~geronimo/aisk/advice419.html



http://www.matroska.org


From steve.lhomme at free.fr  Wed Feb 19 10:52:37 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Wed, 19 Feb 2003 10:52:37 +0100 (CET)
Subject: [matroska-devel] Re: CONFIDENTIAL
In-Reply-To: <20030219032528.433033908A4@turing.freelists.org>
References: <20030219032528.433033908A4@turing.freelists.org>
Message-ID: <1045648357.3e5353e5c50f9@imp.free.fr>


In GMANE :

"Marking this message as spam
You have registered article 334 in gmane.comp.multimedia.matroska.devel (shown
below) as being spam. If you didn't mean to do that, click here to reverse this
action."

Is there something similar at freelists.org ?
http://www.matroska.org


From steve.lhomme at free.fr  Wed Feb 19 14:12:22 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Wed, 19 Feb 2003 14:12:22 +0100 (CET)
Subject: [matroska-devel] Codec ID page
Message-ID: <1045660342.3e5382b6d10e5@imp.free.fr>


<ChrHJW_work> i just have to wait until Steve will upload a first version of the
codec ID page

Errhhh. It uploaded yesterday.
It's in CVS right now !

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/matroska/doc/website/specs/codex.html?rev=HEAD&content-type=text/html
http://www.matroska.org


From chris at matroska.org  Wed Feb 19 14:12:41 2003
From: chris at matroska.org (Christian HJ Wiesner)
Date: Wed, 19 Feb 2003 14:12:41 +0100
Subject: [matroska-devel] AAC profiles /matroska codec IDs
Message-ID: <3E5382C9.8000605@matroska.org>


http://www.hydrogenaudio.org/index.php?act=ST&f=13&t=6447&hl=&s=dcdd20671af616b4b0c5605d65794c8b

[quote]
MPEG-2 AAC Low Complexity / LC profile
MPEG-2 AAC Main profile
MPEG-4 AAC LC profile
MPEG-4 AAC Main profile
MPEG-4 AAC Long Term Prediction / LTP
MPEG-4 AAC Scalable Sampling Rate / SSR
MPEG-4 AAC Version 2
MPEG-4 AAC Version 3 coming soon...
[/quote]

Seems i have to create a few more codec IDs than the existing 2 :-( ??

Right now we have :

10. 'A_MPEG2_AAC' ; Audio, AAC, MPEG2 standard

11. 'A_MPEG4_AAC' ; Audio, AAC , MPEG4 standard

Of course Ivan Dimkovic was the one to clarify here, but i doubt he 
would want to support matroska development with respect to AAC audio, 
maybe he proves me wrong one day :D .

I guess the interesting question for us was the compatibiity with 
existing en/decoders. For example it is said in the thread that MPEG4 
AAC LC and MPEG2 AAC LC only differ by a few bytes in the AAC header ( 
dont aks me though what the sense is behind differentiating here 8)
  ), and maybe we strip the AAC from the MP4 container in any case, so 
we dont have to care at all ?

The more i read that the more i get the intention we had to 
differentiate between

AAC LC
AAC main profile
AAC SSR
AAc V2
AAC V3

and not care at all about the differences between MPEG4 and MPEG2, as 
those seem to be onyl container related ? What do you all think ?

Roberto, would you care to clarify for our list ( cc : rjamorim ) ?

Christian

http://www.matroska.org


From steve.lhomme at free.fr  Wed Feb 19 14:34:57 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Wed, 19 Feb 2003 14:34:57 +0100 (CET)
Subject: [matroska-devel] Re: AAC profiles /matroska codec IDs
In-Reply-To: <3E5382C9.8000605@matroska.org>
References: <3E5382C9.8000605@matroska.org>
Message-ID: <1045661697.3e5388011909c@imp.free.fr>


En r?ponse ? Christian HJ Wiesner <chris at matroska.org>:

> 
>
http://www.hydrogenaudio.org/index.php?act=ST&f=13&t=6447&hl=&s=dcdd20671af616b4b0c5605d65794c8b
> 
> [quote]
> MPEG-2 AAC Low Complexity / LC profile
> MPEG-2 AAC Main profile
> MPEG-4 AAC LC profile
> MPEG-4 AAC Main profile
> MPEG-4 AAC Long Term Prediction / LTP
> MPEG-4 AAC Scalable Sampling Rate / SSR
> MPEG-4 AAC Version 2
> MPEG-4 AAC Version 3 coming soon...
> [/quote]
> 
> Seems i have to create a few more codec IDs than the existing 2 :-( ??

I suggest not taking much care of this for the moment. Let's handle the
simple/common/free codecs first. AAC is good only for low bitrates, and can
probably be equal to Vorbis in this field. And AAC is full of patents.

Let's just have the Low and Main profile IDs defined (hopefully the MP2 and MP4
versions are similar) for the moment. It won't be coded anytime soon...
http://www.matroska.org


From chris at matroska.org  Wed Feb 19 14:29:09 2003
From: chris at matroska.org (Christian HJ Wiesner)
Date: Wed, 19 Feb 2003 14:29:09 +0100
Subject: [matroska-devel] NERO Plugin SDK
Message-ID: <3E5386A5.8020901@matroska.org>


http://www.hydrogenaudio.org/index.php?act=ST&f=2&t=6670&hl=&s=dcdd20671af616b4b0c5605d65794c8b

Nero's SDK

http://www.nero.com/en/index.html#c1002825712128

could be used to create a nice mode2 form2 matroska plugin, including 
file preparation ( block reordering, ECC elements, etc. ) !

Christian


http://www.matroska.org


From chris at wiesneronline.net  Thu Feb 20 00:24:16 2003
From: chris at wiesneronline.net (Christian HJ Wiesner)
Date: Thu, 20 Feb 2003 00:24:16 +0100
Subject: [matroska-devel] Re: AAC profiles /matroska codec IDs
In-Reply-To: <20030219154223.71452.qmail@web11206.mail.yahoo.com>
References: <20030219154223.71452.qmail@web11206.mail.yahoo.com>
Message-ID: <3E541220.709@wiesneronline.net>


Roberto Jos? de Amorim wrote:

> --- Christian HJ Wiesner <chris at matroska.org> escreveu: 
>  
>
>>Seems i have to create a few more codec IDs than the existing
>>2 :-( ??
>>    
>>
>
>That would be a wise idea. :)
>
>  
>
>>Right now we have :
>>
>>10. 'A_MPEG2_AAC' ; Audio, AAC, MPEG2 standard
>>
>>11. 'A_MPEG4_AAC' ; Audio, AAC , MPEG4 standard
>>
>>Of course Ivan Dimkovic was the one to clarify here, but i
>>doubt he 
>>would want to support matroska development with respect to
>>AAC audio, 
>>maybe he proves me wrong one day :D .
>>    
>>
>
>I don't know if he would _want_, my guess is that he doesn't 
>care.
>
>  
>
>>I guess the interesting question for us was the compatibiity
>>with 
>>existing en/decoders. For example it is said in the thread
>>that MPEG4 
>>AAC LC and MPEG2 AAC LC only differ by a few bytes in the AAC
>>header ( 
>>dont aks me though what the sense is behind differentiating
>>here 8)
>>    
>>
>
>Because one is for MPEG4 systems, the other is for MPEG2 
>systems. If it wasn't for this bit, MPEG4 extensions (LTP, SBR,
>LD...) wouldn't be possible.
>
>Actually, there are some decoders that only support MPEG2
>or MPEG4 LC. That even makes sense with MPEG2 AAC, since,
>in the possibility the decoder is old, it wouldn't recognize 
>the MPEG4 bit and would interpret it as corrupt frame. But
>supporting only MPEG4 AAC is indeed stupid. 
><cough>envivio<cough>
>
>  
>
>>and maybe we strip the AAC from the MP4 container in any
>>case, so 
>>we dont have to care at all ?
>>    
>>
>
>You don't have to only if you use exclusively your own 
>homebrewn MP4 demuxer, that would, say, always output MPEG4
>AAC headers. MP4creator, the most widely (the only?) MP4
>demuxer outputs MPEG2 or MPEG4 AAC files based on the object 
>descriptors inside the MP4 stream.
>
>  
>
>>The more i read that the more i get the intention we had to 
>>differentiate between
>>
>>AAC LC
>>AAC main profile
>>AAC SSR
>>AAc V2
>>AAC V3
>>    
>>
>
>SSR is pointless. Nobody uses it.
>AAC V2 and V3 makes no sense. These versionings are only used 
>by MPEG to define what's been added/changed in the standard.
>For example, the biggest novelty in V3 will be SBR.
>MPEG4 AAC LC V2 will be bit-identical to MPEG4 AAC LC V3.
>Same thing with LTP, Main, LD...
>
>  
>
>>and not care at all about the differences between MPEG4 and
>>MPEG2, as 
>>those seem to be onyl container related ? What do you all
>>think ?
>>    
>>
>
>These are indeed container related, but, as I said, there 
>are some stupid players that make a big deal about these
>differences.
>
>This is what I suggest:
>
>10. 'A_MPEG2_AAC_LC' ; Audio, AAC LC, MPEG2 standard
>11. 'A_MPEG4_AAC_LC' ; Audio, AAC LC, MPEG4 standard
>12. 'A_MPEG4_AAC_SBR' ; Audio, AAC SBR, MPEG4 standard
>13. 'A_MPEG_AAC_Other' ; Audio, AAC other profiles, both 
>standards.
>
>The reason is that MOST players support LC only (QuickTime, 
>Envivio, Ligos, Dicas MPEGable, Expanium, Philips...)
>Besides, most encoders output LC only (Quicktime, Ligos, 
>Dicas, Philips),and the ones that don't (FAAC, Psytel) output
>LC as default.
>
>SBR has it's own personal profile because it's "The Next Big
>Thing (tm)", and it's expected to be widely supported.
>And SBR is MPEG4-only, so no need to worry about 
>A_MPEG2_AAC_SBR
>
>I put "everything else" in it's own ID because these profiles
>(Main, LTP, LD) aren't widely used and there's only one 
>available decoder for them: FAAD.
>
>  
>
>>Roberto, would you care to clarify for our list ( cc :
>>rjamorim ) ?
>>    
>>
>
>What?
>
>Hope this helped.
>
>Kind regards;
>
>Roberto.
>
>_______________________________________________________________________
>Busca Yahoo!
>O servi?o de busca mais completo da Internet. O que voc? pensar o Yahoo! encontra.
>http://br.busca.yahoo.com/
>
>  
>


http://www.matroska.org


From animesh.srivastava at blr.techspan.com  Thu Feb 20 14:17:44 2003
From: animesh.srivastava at blr.techspan.com (Animesh Srivastava)
Date: Thu, 20 Feb 2003 18:47:44 +0530
Subject: [matroska-devel] Matroska/EBML specs ??
Message-ID: <09079F636BE1D611BC1600B0D0FCAC6601EF88@BLR>


Hi,

Can anyone point to a reference where I can find the "exact" specs of ebml..
I have been through the ones given on websites but i still find that someway
they dont specify the bnf type format.. one which would specify the
grammar,.. I think that matroska specs are still being worked upon and maybe
ebml too is not in the final state (if i am wrong pls correct me).. But by
exact, i mean something as clear and precise as the WBXML on
http://www.w3.org/TR/wbxml/ or better still the Binary XML Content Format
Specification (WAP-192-WBXML-20010725-a) at
http://www.wapforum.org/what/technical.htm ?

The reason why I am asking this is basically the more clearer the exact
specs of EBML to us, the faster we can get the parser in place.. 

okay, As a first cut, the steps i have in mind is.. 
1. Successful build of the existing code.	- Done
2. Reading the headers of a dummy matroska file using the existing test
sources. - Done
3. Understand the ebml in theory and hand-code a small XML to EBML. - Almost
Done (thats why this mail)
4. Write code to parse this handcoded EBML back to the XML. - This code is
imp and will go a long way in helpin us write the ebml parser, basically i
would suspect that our further versions will stem from this basic parser
code. 
5. While writing the above parser code, we will invariably get a feel of how
to go about the bigger project.. that is in terms of code structure, apis
and function calls.

Moritz had specifically wanted that the parser code should NOT do any file
I/O,.. but for the time being we maybe using some file I/O to read some test
ebml files and see if the parser works correctly.. later we can always knock
off the I/O layer.. 

As for the parser,.. as spyder we are also weighing the difference between
sax or tree.. the tree would have worse performance than the sax for big
ebml docs,... say something around 50 MB sized files,.. but somethings can
be better acheived with a sax parser, using callbacks etc,... anyone with
any ideas.. ??

Pls take time to point us to the most recent specs of EBML and of Matroska
that the developer group currently refers too.

- Animesh.
http://www.matroska.org


From spyder at wiesneronline.net  Thu Feb 20 15:22:31 2003
From: spyder at wiesneronline.net (John Cannon)
Date: Thu, 20 Feb 2003 08:22:31 -0600
Subject: [matroska-devel] Re: Matroska/EBML specs ??
References: <09079F636BE1D611BC1600B0D0FCAC6601EF88@BLR>
Message-ID: <000901c2d8eb$8236d160$3930b141@johnc>



> As for the parser,.. as spyder we are also weighing the difference between
> sax or tree.. the tree would have worse performance than the sax for big
> ebml docs,... say something around 50 MB sized files,.. but somethings can
> be better acheived with a sax parser, using callbacks etc,... anyone with
> any ideas.. ??

I think I will do both.  Possibly making a way to mix the two if necessary.
For example, parsing a tree of small elements could be easier without SAX.
If I could mix the two in some way, it would be nice.  The SAX callback
feature will be nice in future versions where I want to quickly add a new
element type.  My current idea is to use a registry of element handlers,
adding new ones if needed to make a simple, linear parser.  The only real
drawback so far is that there is no way to easily determine the end of an
element as in XML.  This makes SAX parsing a bit more difficult.  I would
need some method of caching positions in the stream that mark the ending of
the elements based on the element size.  Some ideas on this part would be
much appreciated.  I was also thinking of making some form of parser
generator that builds classes based on an XML file describing the structure
of a specific format.  We should get together one day on IRC or some other
faster method of communication if possible. I look forward to hearing your
ideas.  I am working very slowly on this code, not because I'm just
lazy(which I am) but I also want to do this right the first time.

John Cannon
Matroska Developer
spyder482 at matroska.org

http://www.matroska.org


From steve.lhomme at free.fr  Thu Feb 20 15:24:13 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Thu, 20 Feb 2003 15:24:13 +0100 (CET)
Subject: [matroska-devel] Re: Matroska/EBML specs ??
In-Reply-To: <09079F636BE1D611BC1600B0D0FCAC6601EF88@BLR>
References: <09079F636BE1D611BC1600B0D0FCAC6601EF88@BLR>
Message-ID: <1045751053.3e54e50d4e195@imp.free.fr>


> Hi,

Hi,
 
> Can anyone point to a reference where I can find the "exact" specs of
> ebml..

For EBML :
http://ebml.sourceforge.net/specs/
Which is similar to what is in the matroska specs :
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/matroska/doc/website/specs/index.html?rev=HEAD&content-type=text/html
(read directly from the CVS).

> I have been through the ones given on websites but i still find that
> someway
> they dont specify the bnf type format.. one which would specify the

What do you call the BNF format ?

> grammar,.. I think that matroska specs are still being worked upon and
> maybe
> ebml too is not in the final state (if i am wrong pls correct me).. But

The matroska specs are modified when some problems are found or additions needed
(the lastest was about cueing handling). I would call it stable even though the
recent changes are only minor (only things not already coded).
The EBML part has changed for a long time (considering the age of matroska). And
there is no plans to change it. Only additions in the EBML head (adding
something like a DTD to describe the coming file).

> by
> exact, i mean something as clear and precise as the WBXML on
> http://www.w3.org/TR/wbxml/ or better still the Binary XML Content
> Format
> Specification (WAP-192-WBXML-20010725-a) at
> http://www.wapforum.org/what/technical.htm ?

Mmm, I see a bit what you call BNF. But I'm not sure this notation will be mush
better. EBML is a very basic/minimal format. I think the EBML specs page covers
all the technical aspect of the format. But if something is missing (an
questions ?) I'll glady add it to the specs.

> The reason why I am asking this is basically the more clearer the
> exact
> specs of EBML to us, the faster we can get the parser in place.. 
> 
> okay, As a first cut, the steps i have in mind is.. 
> 1. Successful build of the existing code.	- Done
> 2. Reading the headers of a dummy matroska file using the existing
> test sources. - Done
> 3. Understand the ebml in theory and hand-code a small XML to EBML. -
> Almost Done (thats why this mail)

Do you plan to make an EBML<->XML converter ? That could be interresting. The
problem is that XML is not suited for binary. So "binary" EBML elements will
have to be converted to MIME64 or be put in an external file. Anyway that's a
very good project we've been thinking about already. It will open a lot of doors
for EBML processing/generating. Maybe some XLST code would be the preffered
form, as it's a standard related to XML.

> 4. Write code to parse this handcoded EBML back to the XML. - This code
> is
> imp and will go a long way in helpin us write the ebml parser, basically
> i
> would suspect that our further versions will stem from this basic
> parser code. 
> 5. While writing the above parser code, we will invariably get a feel of
> how
> to go about the bigger project.. that is in terms of code structure,
> apis and function calls.
> 
> Moritz had specifically wanted that the parser code should NOT do any
> file
> I/O,.. but for the time being we maybe using some file I/O to read some
> test
> ebml files and see if the parser works correctly.. later we can always
> knock
> off the I/O layer.. 

Well, what Moritz wanted to say is that the I/O handling should be "pluggable"
so that some platform/architectures that already handle I/O internally could
plug theirs to your code. In C, a structure with function pointers with stuff
like open, read, write, close should be a good starting point.

> As for the parser,.. as spyder we are also weighing the difference
> between
> sax or tree.. the tree would have worse performance than the sax for
> big
> ebml docs,... say something around 50 MB sized files,.. but somethings
> can
> be better acheived with a sax parser, using callbacks etc,... anyone
> with any ideas.. ??

I'm no SAX expert. I just coded a parser that sounded logical to me. It contains
callbacks, so I assume it's more SAX like.

> Pls take time to point us to the most recent specs of EBML and of
> Matroska that the developer group currently refers too.

See above.
http://www.matroska.org


From steve.lhomme at free.fr  Fri Feb 21 12:52:50 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Fri, 21 Feb 2003 12:52:50 +0100 (CET)
Subject: [matroska-devel] Re: Latest Update
In-Reply-To: <003701c2d931$28b85870$0200a8c0@desktop>
References: <003701c2d931$28b85870$0200a8c0@desktop>
Message-ID: <1045828370.3e56131267d2a@imp.free.fr>


En r?ponse ? Shailesh L Mistry <shailesh.mistry at milan.eclipse.co.uk>:

> Hi Steve,
> 
> I have just taken in the latest updates and now the static lib will
> not
> build for me!
> I get the following messages :-
> 
> --------------------Configuration: Matroska LIB Static - Win32
> Debug--------------------
> Compiling...
> KaxCluster.cpp
> c:\opensource\matroska\libmatroska\src\kaxcluster.cpp(133) : error
> C2065:
> 'ElementListIdx' : undeclared identifier
> c:\opensource\matroska\libmatroska\src\kaxcluster.cpp(133) : error
> C2679:
> binary '=' : no operator defined which takes a right-hand operand of
> type
> 'class std::list<class libebml::EbmlElement *,class
> std::allocator<class
> libebml::EbmlElement *> >::iterator' (or there is no acceptable
> conversion)
> c:\opensource\matroska\libmatroska\src\kaxcluster.cpp(133) : error
> C2677:
> binary '!=' : no global operator defined which takes type 'class
> std::list<class libebml::EbmlElement *,class std::allocator<class
> libebml::EbmlElement *> >::iterator' (or there is no acceptable
> conversion)
> c:\opensource\matroska\libmatroska\src\kaxcluster.cpp(134) : error
> C2100:
> illegal indirection
> c:\opensource\matroska\libmatroska\src\kaxcluster.cpp(134) : error
> C2100:
> illegal indirection
> c:\opensource\matroska\libmatroska\src\kaxcluster.cpp(134) : error
> C2440:
> 'type cast' : cannot convert from 'int' to 'class libebml::EbmlId'
>         No constructor could take the source type, or constructor
> overload
> resolution was ambiguous
> c:\opensource\matroska\libmatroska\src\kaxcluster.cpp(135) : error
> C2228:
> left of '.ReleaseFrames' must have class/struct/union type
> Error executing cl.exe.
> 
> test8.exe - 7 error(s), 0 warning(s)
> 
> 
> Any thoughts on this?

Yes, I committed changes yesterday that I didn't try to compile (very bad idea).
I hoped it would work without any problem... I'll fix that tonight (GMT+1).

Sorry for the incovenience (you can probably comment these lines for the moment).

PS: I'm glad someone realised it :)
http://www.matroska.org


From chris at matroska.org  Fri Feb 21 23:10:30 2003
From: chris at matroska.org (Christian HJ Wiesner)
Date: Fri, 21 Feb 2003 23:10:30 +0100
Subject: [matroska-devel] Thread on Doom9 about special matroska MPEG4 DShow filters
Message-ID: <3E56A3D6.9040304@matroska.org>


http://forum.doom9.org/showthread.php?s=&threadid=46709

Regards

Christian

http://www.matroska.org


From chris at matroska.org  Sat Feb 22 15:57:34 2003
From: chris at matroska.org (Christian HJ Wiesner)
Date: Sat, 22 Feb 2003 15:57:34 +0100
Subject: [matroska-devel] Announcement : First matroska file creation and editing application,
 'matroskadub', is released for alpha testing
Message-ID: <3E578FDE.2070106@matroska.org>



Gentlemen,

i do have the pleasure to announce that Cyrius has given me a first 
alpha version of matroskadub for uploading to the alpha testing teams on 
corecodec.com and virtualdub.everwicked.com .
The file can be downloaded here : 
http://downlaods.matroska.org/VirtualDubMod-Matroska-Alpha.rar

The tool is based on VirtualdubMod, you have to exchange the EXE in a 
valid installation folder against this special version to make it work, 
get VirtualdubMod from the offical Project page here : 
http://sf.net/projects/virtualdubmod , dont forget to load the 
'necessary DLLs' also.

There is still a severe memory leak in the library, but we hope to be 
able to solve this  soon.

All eyes are on myFUN now about the DShow parser, and mosu for the Linux 
muxer :-) !!

Regards

Christian

http://www.matroska.org


From kimmo at poispakkoruotsi.com  Sat Feb 22 19:04:39 2003
From: kimmo at poispakkoruotsi.com (Kimmo)
Date: Sat, 22 Feb 2003 20:04:39 +0200
Subject: [matroska-devel] Re: [matroska-general] Announcement : First matroska file creation and editing application, 'matroskadub', is released for alpha testing
References: <3E578FDE.2070106@matroska.org>
Message-ID: <002201c2da9c$df225e00$0100a8c0@kimmo>



> Gentlemen,
>
> i do have the pleasure to announce that Cyrius has given me a first
> alpha version of matroskadub for uploading to the alpha testing teams on
> corecodec.com and virtualdub.everwicked.com .
> The file can be downloaded here :
> http://downlaods.matroska.org/VirtualDubMod-Matroska-Alpha.rar


http://downloads.matroska.org/VirtualDubMod-Matroska-Alpha.rar should work
better ;)


http://www.matroska.org


From steve.lhomme at free.fr  Sun Feb 23 18:51:44 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Sun, 23 Feb 2003 18:51:44 +0100
Subject: [matroska-devel] Re: Announcement : First matroska file creation
 and editing application, 'matroskadub', is released for alpha testing
In-Reply-To: <3E578FDE.2070106@matroska.org>
References: <3E578FDE.2070106@matroska.org>
Message-ID: <3E590A30.8090908@free.fr>


Christian HJ Wiesner wrote:

>
> Gentlemen,
>
> i do have the pleasure to announce that Cyrius has given me a first
> alpha version of matroskadub for uploading to the alpha testing teams on
> corecodec.com and virtualdub.everwicked.com .
> The file can be downloaded here :
> http://downlaods.matroska.org/VirtualDubMod-Matroska-Alpha.rar


Chris, are you aware you sent this link to a public mailing list ?
I thought the alpha would be limited to coders only and maybe a few 
other people that could have a good opinion on what needs to be done... 
And threfore the CoreCodec forum/alpha section was supposed to be the 
place to post links...

BTW, MyFUN mentioned on IRC that he would be away for 3 weeks. That 
leaves some time to improve libmatroska in many directions :) And also 
set a minimum date for a public beta (1 month) launch. Without the DShow 
filter there's no need for a public launch. If MyFUN put is code 
somewhere (CVS ?) before going in vacation, maybe someone else could 
continue the work in the meantime.


http://www.matroska.org


From chris at matroska.org  Sun Feb 23 11:09:53 2003
From: chris at matroska.org (Christian HJ Wiesner)
Date: Sun, 23 Feb 2003 11:09:53 +0100
Subject: [matroska-devel] Memory leaks in libmatroska partially fixed
Message-ID: <3E589DF1.2030903@matroska.org>



Hi,

Cyrius found the main reason for the mem leaks in libmatroska. He will 
be the better one to explain what Steve has screwed ( ;-) ), i hardly 
understand it. I hope he will upload his changes to CVS soon, in any 
case a newer version of matroskdub with an improved library was uploaded 
to here :

http://cyrius.bunkus.org/VirtualDubMod-Matroska-Alpha2.rar

Regards

Christian

http://www.matroska.org


From suiryc at yahoo.com  Sun Feb 23 14:56:24 2003
From: suiryc at yahoo.com (Cyrius)
Date: Sun, 23 Feb 2003 05:56:24 -0800 (PST)
Subject: [matroska-devel] Re: Memory leaks in libmatroska partially fixed
In-Reply-To: <3E589DF1.2030903@matroska.org>
Message-ID: <20030223135624.69459.qmail@web12904.mail.yahoo.com>


--- Christian HJ Wiesner <chris at matroska.org> wrote:
> 
> 
> Hi,
> 
> Cyrius found the main reason for the mem leaks in
> libmatroska. He will 
> be the better one to explain what Steve has screwed
> ( ;-) ), i hardly 
> understand it. I hope he will upload his changes to
> CVS soon, in any 
> case a newer version of matroskdub with an improved
> library was uploaded 
> to here :
> 
>
http://cyrius.bunkus.org/VirtualDubMod-Matroska-Alpha2.rar
> 
> Regards
> 
> Christian
> 
> http://www.matroska.org

lol
Well the problem is due to the fact that currently
almost none of the Ebml elements is freed in the
library (robUx4 will add some nice ways to do this
later).
However to try save some memory he already added a
method to free allocated frames in the KaxBlock
object. What he forgot is that when writing/reading
with this element he copies all the data in a linear
buffer (frames by themselves are stored in a list of
buffers) that is used by the EbmlBinary (base class of
KaxBlock), and of course this buffer wasn't freed ;)

Unfortunately I don't think it would be a good idea to
commit this now because I had to add some functions (a
way to free children in EbmlMaster, default destructor
in some classes to free allocated memory, ...) which
would conflict with the freeing elements that robUx4
will add.

__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, more
http://taxes.yahoo.com/
http://www.matroska.org


From steve.lhomme at free.fr  Mon Feb 24 23:28:10 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Mon, 24 Feb 2003 23:28:10 +0100
Subject: [matroska-devel] Re: Memory leaks in libmatroska partially fixed
In-Reply-To: <20030223135624.69459.qmail@web12904.mail.yahoo.com>
References: <20030223135624.69459.qmail@web12904.mail.yahoo.com>
Message-ID: <3E5A9C7A.5070200@free.fr>


Cyrius wrote:
> lol
> Well the problem is due to the fact that currently
> almost none of the Ebml elements is freed in the
> library (robUx4 will add some nice ways to do this
> later).
> However to try save some memory he already added a
> method to free allocated frames in the KaxBlock
> object. What he forgot is that when writing/reading
> with this element he copies all the data in a linear
> buffer (frames by themselves are stored in a list of
> buffers) that is used by the EbmlBinary (base class of
> KaxBlock), and of course this buffer wasn't freed ;)
> 
> Unfortunately I don't think it would be a good idea to
> commit this now because I had to add some functions (a
> way to free children in EbmlMaster, default destructor
> in some classes to free allocated memory, ...) which
> would conflict with the freeing elements that robUx4
> will add.

This is now fixed/cleaned in CVS. Tested with and without lacing :)

http://www.matroska.org


From moritz at bunkus.org  Tue Feb 25 14:41:36 2003
From: moritz at bunkus.org (Moritz Bunkus)
Date: Tue, 25 Feb 2003 14:41:36 +0100
Subject: [matroska-devel] Re: Memory leaks in libmatroska partially fixed
In-Reply-To: <3E5A9C7A.5070200@free.fr>
References: <20030223135624.69459.qmail@web12904.mail.yahoo.com> <3E5A9C7A.5070200@free.fr>
Message-ID: <20030225134136.GP30789@bunkus.org>

An embedded and charset-unspecified text was scrubbed...
Name: not available
URL: <http://lists.matroska.org/pipermail/matroska-devel/attachments/20030225/8353e70d/attachment.ksh>

From steve.lhomme at free.fr  Tue Feb 25 14:48:01 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Tue, 25 Feb 2003 14:48:01 +0100 (CET)
Subject: [matroska-devel] Re: Memory leaks in libmatroska partially fixed
In-Reply-To: <20030225134136.GP30789@bunkus.org>
References: <20030223135624.69459.qmail@web12904.mail.yahoo.com> <3E5A9C7A.5070200@free.fr> <20030225134136.GP30789@bunkus.org>
Message-ID: <1046180881.3e5b7411e48bc@imp.free.fr>


En r?ponse ? Moritz Bunkus <moritz at bunkus.org>:

> Hi.
> 
> > > Well the problem is due to the fact that currently
> > > almost none of the Ebml elements is freed in the
> > > library (robUx4 will add some nice ways to do this
> > > later).
> 
> ...
> 
> > This is now fixed/cleaned in CVS. Tested with and without lacing :)
> 
> This has not been overly fixed, has it? There's still tons of memory
> being leaked (tested my program with valgrind
> (http://developer.kde.org/~sewardj/) and it reports lots of memory
> allocated by Ebml* which is never freed).

Could you be a bit more precise and where these leaks occur ?
Are you sure it's not in your tool ?
I'm sure the one in the KaxBlock is fixed, but the library is still not clean
for freeing memory. Actually when you free any EbmlMaster, you should free its
children too (yourself). I'll add an internal system to do this automatically,
unless the element is locked (by the user, but then he has the responsibility to
free this memory later).
http://www.matroska.org


From moritz at bunkus.org  Tue Feb 25 14:58:32 2003
From: moritz at bunkus.org (Moritz Bunkus)
Date: Tue, 25 Feb 2003 14:58:32 +0100
Subject: [matroska-devel] Re: Memory leaks in libmatroska partially fixed
In-Reply-To: <1046180881.3e5b7411e48bc@imp.free.fr>
References: <20030223135624.69459.qmail@web12904.mail.yahoo.com> <3E5A9C7A.5070200@free.fr> <20030225134136.GP30789@bunkus.org> <1046180881.3e5b7411e48bc@imp.free.fr>
Message-ID: <20030225135832.GQ30789@bunkus.org>

An embedded and charset-unspecified text was scrubbed...
Name: not available
URL: <http://lists.matroska.org/pipermail/matroska-devel/attachments/20030225/c2d1d000/attachment.ksh>

From steve.lhomme at free.fr  Tue Feb 25 15:06:16 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Tue, 25 Feb 2003 15:06:16 +0100 (CET)
Subject: [matroska-devel] Re: Memory leaks in libmatroska partially fixed
In-Reply-To: <20030225135832.GQ30789@bunkus.org>
References: <20030223135624.69459.qmail@web12904.mail.yahoo.com> <3E5A9C7A.5070200@free.fr> <20030225134136.GP30789@bunkus.org> <1046180881.3e5b7411e48bc@imp.free.fr> <20030225135832.GQ30789@bunkus.org>
Message-ID: <1046181976.3e5b7858c5bec@imp.free.fr>


En r?ponse ? Moritz Bunkus <moritz at bunkus.org>:

> Hi.
> 
> > Could you be a bit more precise and where these leaks occur ?
> > Are you sure it's not in your tool ?
> 
> I'm NOW sure that I should investigate more deeply before making
> accusations ;) Yes, it's my program that is leaking memory - because
> I'm
> storing the results from GetChild and GetNextChild in pointers and not
> in reference variables I'll explicitely have to free them. I just
> didn't
> think about that.
> 
> Sorry.

No problem. Actually for this kind of technical problem a good investigation is
best. We did that with Cyrius without finding the cause of the leak :( But we
finally found the source :)

Anyway, that means your code will be even better ! ;)
(let's be optimistic)
http://www.matroska.org


From moritz at bunkus.org  Tue Feb 25 15:23:31 2003
From: moritz at bunkus.org (Moritz Bunkus)
Date: Tue, 25 Feb 2003 15:23:31 +0100
Subject: [matroska-devel] Re: Memory leaks in libmatroska partially fixed
In-Reply-To: <1046181976.3e5b7858c5bec@imp.free.fr>
References: <20030223135624.69459.qmail@web12904.mail.yahoo.com> <3E5A9C7A.5070200@free.fr> <20030225134136.GP30789@bunkus.org> <1046180881.3e5b7411e48bc@imp.free.fr> <20030225135832.GQ30789@bunkus.org> <1046181976.3e5b7858c5bec@imp.free.fr>
Message-ID: <20030225142331.GR30789@bunkus.org>

An embedded and charset-unspecified text was scrubbed...
Name: not available
URL: <http://lists.matroska.org/pipermail/matroska-devel/attachments/20030225/5922e4a5/attachment.ksh>

From steve.lhomme at free.fr  Tue Feb 25 15:52:50 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Tue, 25 Feb 2003 15:52:50 +0100 (CET)
Subject: [matroska-devel] Re: Memory leaks in libmatroska partially fixed
In-Reply-To: <20030225142331.GR30789@bunkus.org>
References: <20030223135624.69459.qmail@web12904.mail.yahoo.com> <3E5A9C7A.5070200@free.fr> <20030225134136.GP30789@bunkus.org> <1046180881.3e5b7411e48bc@imp.free.fr> <20030225135832.GQ30789@bunkus.org> <1046181976.3e5b7858c5bec@imp.free.fr> <20030225142331.GR30789@bunkus.org>
Message-ID: <1046184770.3e5b83421fbf9@imp.free.fr>


En r?ponse ? Moritz Bunkus <moritz at bunkus.org>:

> Hi.
> 
> Ok, now I'm a bit more precise than before. Most of the bytes leaked
> were definitely my fault, but there are some leaks that I'm pretty
> sure
> are NOT my fault.
> 
> The first thing happens when the following function is used to render
> the head:
> 
> static void render_head(StdIOCallback *out) {
>   EbmlHead head;
> 
>   EDocType &doc_type = GetChild<EDocType>(head);
>   *static_cast<EbmlString *>(&doc_type) = "matroska";
>   EDocTypeVersion &doc_type_ver = GetChild<EDocTypeVersion>(head);
>   *(static_cast<EbmlUInteger *>(&doc_type_ver)) = 1;
>   EDocTypeReadVersion &doc_type_read_ver =
>     GetChild<EDocTypeReadVersion>(head);
>   *(static_cast<EbmlUInteger *>(&doc_type_read_ver)) = 1;
> 
>   head.Render(static_cast<StdIOCallback &>(*out));
> }
> 
> As far as I understand the head is being destroyed when the function
> is
> done and should free all memory allocated with it. But it does
> not. Valgrind's output for it can be found at
> http://www.linet-services.de/~mbunkus/val-head.txt
> 
> Or am I doing something wrong here? 

No that's correct. The allocated memory is not freed because, as I said in the
previous email, the chidren on "head" are not freed when "head" is (which is an
EbmlMaster). I'll add something to automatically free these EbmlMaster children.

I will use a locking system so that if you really want to keep an element in
memory, you can (and you become the father will all responsabilites ;).
http://www.matroska.org


From moritz at bunkus.org  Tue Feb 25 16:03:30 2003
From: moritz at bunkus.org (Moritz Bunkus)
Date: Tue, 25 Feb 2003 16:03:30 +0100
Subject: [matroska-devel] Re: Memory leaks in libmatroska partially fixed
In-Reply-To: <1046184770.3e5b83421fbf9@imp.free.fr>
References: <20030223135624.69459.qmail@web12904.mail.yahoo.com> <3E5A9C7A.5070200@free.fr> <20030225134136.GP30789@bunkus.org> <1046180881.3e5b7411e48bc@imp.free.fr> <20030225135832.GQ30789@bunkus.org> <1046181976.3e5b7858c5bec@imp.free.fr> <20030225142331.GR30789@bunkus.org> <1046184770.3e5b83421fbf9@imp.free.fr>
Message-ID: <20030225150330.GS30789@bunkus.org>

An embedded and charset-unspecified text was scrubbed...
Name: not available
URL: <http://lists.matroska.org/pipermail/matroska-devel/attachments/20030225/4e77a18e/attachment.ksh>

From steve.lhomme at free.fr  Tue Feb 25 16:16:08 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Tue, 25 Feb 2003 16:16:08 +0100 (CET)
Subject: [matroska-devel] Re: Memory leaks in libmatroska partially fixed
In-Reply-To: <20030225150330.GS30789@bunkus.org>
References: <20030223135624.69459.qmail@web12904.mail.yahoo.com> <3E5A9C7A.5070200@free.fr> <20030225134136.GP30789@bunkus.org> <1046180881.3e5b7411e48bc@imp.free.fr> <20030225135832.GQ30789@bunkus.org> <1046181976.3e5b7858c5bec@imp.free.fr> <20030225142331.GR30789@bunkus.org> <1046184770.3e5b83421fbf9@imp.free.fr> <20030225150330.GS30789@bunkus.org>
Message-ID: <1046186168.3e5b88b82a8de@imp.free.fr>


En r?ponse ? Moritz Bunkus <moritz at bunkus.org>:

> Hi.
> 
> > I will use a locking system so that if you really want to keep an
> element in
> > memory, you can (and you become the father will all responsabilites
> ;).
> 
> Weeeeee, maternal duties - that's all I've ever wanted :)
> 
> No, seriously: no problem. The same happens with KaxCluster if I'm not
> mistaken. Just implement it sometime ;) At the moment my muxer is
> leaking approx. 19000 bytes on a 90megs input file, so it's really not
> critical ;)

For me it is !
I'll do that tonight as it's very easy to do. I would also like to have the Cue
writing finished for tonight. Then I can implement the Cue reading. Both are top
priorites right now.
http://www.matroska.org


From rbultje at ronald.bitfreak.net  Tue Feb 25 16:19:58 2003
From: rbultje at ronald.bitfreak.net (Ronald Bultje)
Date: 25 Feb 2003 16:19:58 +0100
Subject: [matroska-devel] Re: Memory leaks in libmatroska partially
	fixed
In-Reply-To: <1046184770.3e5b83421fbf9@imp.free.fr>
References: <20030223135624.69459.qmail@web12904.mail.yahoo.com>
	 <3E5A9C7A.5070200@free.fr> <20030225134136.GP30789@bunkus.org>
	 <1046180881.3e5b7411e48bc@imp.free.fr> <20030225135832.GQ30789@bunkus.org>
	 <1046181976.3e5b7858c5bec@imp.free.fr> <20030225142331.GR30789@bunkus.org>
	 <1046184770.3e5b83421fbf9@imp.free.fr>
Message-ID: <1046186397.18545.30.camel@localhost.localdomain>


Hey Steve & co,

On Tue, 2003-02-25 at 15:52, Steve Lhomme wrote:
> No that's correct. The allocated memory is not freed because, as I said in the
> previous email, the chidren on "head" are not freed when "head" is (which is an
> EbmlMaster). I'll add something to automatically free these EbmlMaster children.
> 
> I will use a locking system so that if you really want to keep an element in
> memory, you can (and you become the father will all responsabilites ;).

Shouldn't you just use refcounting here?

(short explanation:) Each user of an object ref()s it (incease refcount
with one), and if you're done using it you unref() (decrease refcount
with one) it. The one that created the object (ref() is an implicit part
of object creation) should use unref() too. If noone uses the object,
the refcount is zero (since everyone unref()ed it) and the object is
automagically free()ed (in unref(), a check is done to see whether
refcount is zero - if so, you delete the object).

Ronald

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

http://www.matroska.org


From steve.lhomme at free.fr  Tue Feb 25 16:26:09 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Tue, 25 Feb 2003 16:26:09 +0100 (CET)
Subject: [matroska-devel] Re: Memory leaks in libmatroska partially fixed
In-Reply-To: <1046186397.18545.30.camel@localhost.localdomain>
References: <20030223135624.69459.qmail@web12904.mail.yahoo.com>  <3E5A9C7A.5070200@free.fr> <20030225134136.GP30789@bunkus.org>  <1046180881.3e5b7411e48bc@imp.free.fr> <20030225135832.GQ30789@bunkus.org>  <1046181976.3e5b7858c5bec@imp.free.fr> <20030225142331.GR30789@bunkus.org>  <1046184770.3e5b83421fbf9@imp.free.fr> <1046186397.18545.30.camel@localhost.localdomain>
Message-ID: <1046186769.3e5b8b11103ca@imp.free.fr>


En r?ponse ? Ronald Bultje <rbultje at ronald.bitfreak.net>:

> 
> Hey Steve & co,
> 
> On Tue, 2003-02-25 at 15:52, Steve Lhomme wrote:
> > No that's correct. The allocated memory is not freed because, as I
> said in the
> > previous email, the chidren on "head" are not freed when "head" is
> (which is an
> > EbmlMaster). I'll add something to automatically free these EbmlMaster
> children.
> > 
> > I will use a locking system so that if you really want to keep an
> element in
> > memory, you can (and you become the father will all responsabilites
> ;).
> 
> Shouldn't you just use refcounting here?
> 
> (short explanation:) Each user of an object ref()s it (incease
> refcount
> with one), and if you're done using it you unref() (decrease refcount
> with one) it. The one that created the object (ref() is an implicit
> part
> of object creation) should use unref() too. If noone uses the object,
> the refcount is zero (since everyone unref()ed it) and the object is
> automagically free()ed (in unref(), a check is done to see whether
> refcount is zero - if so, you delete the object).

Something like a garbage collector ?
That could work if we trapped all allocation and check for unfreed but
referenced element at the end. I'm not sure it would prevent more bugs. If
someone forget to ref/unref an element for example. While locking seems more formal.
http://www.matroska.org


From rbultje at ronald.bitfreak.net  Tue Feb 25 17:03:18 2003
From: rbultje at ronald.bitfreak.net (Ronald Bultje)
Date: 25 Feb 2003 17:03:18 +0100
Subject: [matroska-devel] Re: Memory leaks in libmatroska partially
	fixed
In-Reply-To: <1046186769.3e5b8b11103ca@imp.free.fr>
References: <20030223135624.69459.qmail@web12904.mail.yahoo.com>
	 <3E5A9C7A.5070200@free.fr> <20030225134136.GP30789@bunkus.org>
	 <1046180881.3e5b7411e48bc@imp.free.fr> <20030225135832.GQ30789@bunkus.org>
	 <1046181976.3e5b7858c5bec@imp.free.fr> <20030225142331.GR30789@bunkus.org>
	 <1046184770.3e5b83421fbf9@imp.free.fr>
	 <1046186397.18545.30.camel@localhost.localdomain>
	 <1046186769.3e5b8b11103ca@imp.free.fr>
Message-ID: <1046188998.18556.34.camel@localhost.localdomain>


Hey Steve,

On Tue, 2003-02-25 at 16:26, Steve Lhomme wrote:
> Something like a garbage collector ?

Well, sort of, but much simpler.

> That could work if we trapped all allocation and check for unfreed but
> referenced element at the end. I'm not sure it would prevent more bugs. If
> someone forget to ref/unref an element for example. While locking seems more formal.

The same goes for memory allocating per se. Forgetting to free causes
mem leaks. The point is that refcounting actually allows proper sharing
of resources between elements without having the risk of using
unreferenced (already free()ed) pointers. Having "just" one owner that
free's the thing is more dangerous and limiting, imo.

Ronald

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

http://www.matroska.org


From steve.lhomme at free.fr  Tue Feb 25 17:16:10 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Tue, 25 Feb 2003 17:16:10 +0100 (CET)
Subject: [matroska-devel] Re: Memory leaks in libmatroska partially fixed
In-Reply-To: <1046188998.18556.34.camel@localhost.localdomain>
References: <20030223135624.69459.qmail@web12904.mail.yahoo.com>  <3E5A9C7A.5070200@free.fr> <20030225134136.GP30789@bunkus.org>  <1046180881.3e5b7411e48bc@imp.free.fr> <20030225135832.GQ30789@bunkus.org>  <1046181976.3e5b7858c5bec@imp.free.fr> <20030225142331.GR30789@bunkus.org>  <1046184770.3e5b83421fbf9@imp.free.fr>  <1046186397.18545.30.camel@localhost.localdomain>  <1046186769.3e5b8b11103ca@imp.free.fr> <1046188998.18556.34.camel@localhost.localdomain>
Message-ID: <1046189770.3e5b96cac1f50@imp.free.fr>


En r?ponse ? Ronald Bultje <rbultje at ronald.bitfreak.net>:

> 
> Hey Steve,
> 
> On Tue, 2003-02-25 at 16:26, Steve Lhomme wrote:
> > Something like a garbage collector ?
> 
> Well, sort of, but much simpler.
> 
> > That could work if we trapped all allocation and check for unfreed
> but
> > referenced element at the end. I'm not sure it would prevent more
> bugs. If
> > someone forget to ref/unref an element for example. While locking
> seems more formal.
> 
> The same goes for memory allocating per se. Forgetting to free causes
> mem leaks. The point is that refcounting actually allows proper
> sharing
> of resources between elements without having the risk of using
> unreferenced (already free()ed) pointers. Having "just" one owner that
> free's the thing is more dangerous and limiting, imo.

Yes, but for the moment the locking system is just to say "don't free me
automatically". It's like a refcount with only 2 values 0 and 1. And everybody
is free to free the memory but not automatically from an EbmlMaster. It serves
our needs for the moment and keep the solution easy.
http://www.matroska.org


From kimmo at poispakkoruotsi.com  Tue Feb 25 19:48:29 2003
From: kimmo at poispakkoruotsi.com (Kimmo)
Date: Tue, 25 Feb 2003 20:48:29 +0200
Subject: [matroska-devel] MatroskaDub crashes
References: <20030223135624.69459.qmail@web12904.mail.yahoo.com>  <3E5A9C7A.5070200@free.fr> <20030225134136.GP30789@bunkus.org>  <1046180881.3e5b7411e48bc@imp.free.fr> <20030225135832.GQ30789@bunkus.org>  <1046181976.3e5b7858c5bec@imp.free.fr> <20030225142331.GR30789@bunkus.org>  <1046184770.3e5b83421fbf9@imp.free.fr> <1046186397.18545.30.camel@localhost.localdomain> <1046186769.3e5b8b11103ca@imp.free.fr>
Message-ID: <001601c2dcfe$7d3870d0$0100a8c0@kimmo>


Tried to save a matroska file with uncompressed video & audio.

VirtualDub crash report -- build 14328 (release)
--------------------------------------

Disassembly:
00577f60: 6a2f            push   2f
00577f62: 6858175e00      push   005e1758
00577f67: 6a02            push   02
00577f69: e832170000      call   _CrtDbgReport (005796a0)
00577f6e: 83c414          add    esp, 14
00577f71: 83f801          cmp    eax, 01
00577f74: 7501            jnz    (special)+77 (00577f77)
00577f76: cc              int    3
00577f77: 33c9            xor    ecx, ecx
00577f79: 85c9            test   ecx, ecx
00577f7b: 75a8            jnz    (special)+25 (00577f25)
00577f7d: 8b55fc          mov    edx, [ebp-04]
00577f80: 8b4214          mov    eax, [edx+14]
00577f83: 50              push   eax
00577f84: 8b4d08          mov    ecx, [ebp+08]
00577f87: 51              push   ecx
00577f88: e873e6ffff      call   _free_dbg (00576600)
00577f8d: 83c408          add    esp, 08
00577f90: 6a09            push   09
00577f92: e8d9ac0000      call   _unlock (00582c70)
00577f97: 83c404          add    esp, 04
00577f9a: 5f              pop    edi
00577f9b: 5e              pop    esi
00577f9c: 5b              pop    ebx
00577f9d: 8be5            mov    esp, ebp
00577f9f: 5d              pop    ebp
00577fa0: c3              ret
00577fa1: cc              int    3
00577fa2: cc              int    3
00577fa3: cc              int    3
00577fa4: cc              int    3
00577fa5: cc              int    3
00577fa6: cc              int    3
00577fa7: cc              int    3
00577fa8: cc              int    3
00577fa9: cc              int    3
00577faa: cc              int    3
00577fab: cc              int    3
00577fac: cc              int    3
00577fad: cc              int    3
00577fae: cc              int    3
00577faf: cc              int    3
00577fb0: 55              push   ebp
00577fb1: 8bec            mov    ebp, esp
00577fb3: 57              push   edi
00577fb4: 56              push   esi
00577fb5: 8b750c          mov    esi, [ebp+0c]
00577fb8: 8b4d10          mov    ecx, [ebp+10]
00577fbb: 8b7d08          mov    edi, [ebp+08]
00577fbe: 8bc1            mov    eax, ecx
00577fc0: 8bd1            mov    edx, ecx
00577fc2: 03c6            add    eax, esi
00577fc4: 3bfe            cmp    edi, esi
00577fc6: 7608            jbe    opyUp (00577fd0)
00577fc8: 3bf8            cmp    edi, eax
00577fca: 0f8278010000    jc     opyDown (00578148)
00577fd0: f7c703000000    test   edi, 00000003
00577fd6: 7514            jnz    opyLeadUp (00577fec)
00577fd8: c1e902          shr    ecx, 02
00577fdb: 83e203          and    edx, 03
00577fde: 83f908          cmp    ecx, 08
00577fe1: 7229            jc     opyUnwindUp (0057800c)
00577fe3: f3a5            rep    movsd      <-- FAULT
00577fe5: ff2495f8805700  jmp    dword ptr [edx*4+nwindUp0+09 (005780f8)]
00577fec: 8bc7            mov    eax, edi
00577fee: ba03000000      mov    edx, 00000003
00577ff3: 83e904          sub    ecx, 04
00577ff6: 720c            jc     yteCopyUp (00578004)
00577ff8: 83e003          and    eax, 03
00577ffb: 03c8            add    ecx, eax
00577ffd: ff248510805700  jmp    dword ptr [eax*4+opyUnwindUp+04 (00578010)]
00578004: ff248d08815700  jmp    dword ptr [ecx*4+railUp0 (00578108)]
0057800b: 90              nop
0057800c: ff248d8c805700  jmp    dword ptr [ecx*4+eadUp3+1c (0057808c)]
00578013: 90              nop
00578014: 208057004c80    and    [eax-7fb3ffa9], al
0057801a: 57              push   edi
0057801b: 007080          add    [eax-80], dh
0057801e: 57              push   edi
0057801f: 0023            add    [ebx], ah
00578021: d18a0688078a    ror    dword ptr [edx-75f877fa], 1
00578027: 46              inc    esi
00578028: 018847018a46    add    [eax+468a0147], ecx
0057802e: 02c1            add    al, cl
00578030: e902884702      jmp    029f0837
00578035: 83c603          add    esi, 03
00578038: 83c703          add    edi, 03
0057803b: 83f908          cmp    ecx, 08
0057803e: 72cc            jc     opyUnwindUp (0057800c)
00578040: f3a5            rep    movsd
00578042: ff2495f8805700  jmp    dword ptr [edx*4+nwindUp0+09 (005780f8)]
00578049: 8d4900          lea    ecx, [ecx+00]
0057804c: 23d1            and    edx, ecx
0057804e: 8a06            mov    al, [esi]
00578050: 8807            mov    [edi], al
00578052: 8a4601          mov    al, [esi+01]
00578055: c1e902          shr    ecx, 02
00578058: 884701          mov    [edi+01], al
0057805b: 83c602          add    esi, 02
0057805e: 83              db     83
0057805f: c7              db     c7

Windows 5.1 (WinXP build 2600) [Service Pack 1]

EAX = 0121f11f
EBX = 00000000
ECX = 00003847
EDX = 00000003
EBP = 0012ec40
DS:ESI = 0023:01211000
ES:EDI = 0023:038c0d08
SS:ESP = 0023:0012ec38
CS:EIP = 001b:00577fe3
FS = 003b
GS = 0000
EFLAGS = 00010216

MM0 = ffd6d3ceffd6d3ce
MM1 = 0000000000000000
MM2 = 00fe00d500d200cd
MM3 = 00fe00d500d200cd
MM4 = ffd6d3ceffd6d3ce
MM5 = 00ff00d600d300ce
MM6 = fa00000000000000
MM7 = ac44000000000000
Crash reason: Access Violation

Thread 00000c94 (Main thread)
 C:\Dvpt\VDub_1.4.13\Matroska-MOD\Init.cpp(240)
 C:\Dvpt\VDub_1.4.13\Matroska-MOD\Init.cpp(259)
 C:\Dvpt\VDub_1.4.13\Matroska-MOD\Init.cpp(277)
 C:\Dvpt\VDub_1.4.13\Matroska-MOD\Init.cpp(339)
 C:\Dvpt\VDub_1.4.13\Matroska-MOD\Main.cpp(348)
 C:\Dvpt\VDub_1.4.13\Matroska-MOD\Main.cpp(379)
 C:\Dvpt\VDub_1.4.13\Matroska-MOD\FilterSystem.cpp(427)
 C:\Dvpt\VDub_1.4.13\Matroska-MOD\FilterSystem.cpp(561)
 C:\Dvpt\VDub_1.4.13\Matroska-MOD\FilterSystem.cpp(427)


00577fe3: opyUp()
00535301: MatroskaOutputFile::init()
004da6d7: Dubber::InitOutputFile()
0052077a: OGMDubber::Init()
004c6299: InitDubOGM()
004bfe6a: SaveMatroska()
004b680d: MenuHit()
004baae6: MainWndProc()
77d57ad7: USER32!SetWindowPlacement [77d30000+27a80+57]
77d5ccd4: USER32!DefRawInputProc [77d30000+2ca50+284]
77d34455: USER32!TranslateMessageEx [77d30000+3e30+625]
77d3414d: USER32!TranslateMessageEx [77d30000+3e30+31d]
77d35f28: USER32!GetParent [77d30000+5f06+22]
77d35f70: USER32!GetParent [77d30000+5f06+6a]
77d34d58: USER32!DispatchMessageA [77d30000+4d4d+b]
004b5035: WinMain at 16()
772c1a29: SHLWAPI!StrCpyW [772c0000+19cb+5e]
0057dd86: WinMainCRTStartup()
772c1a29: SHLWAPI!StrCpyW [772c0000+19cb+5e]
77e814c7: kernel32!GetCurrentDirectoryW [77e60000+21483+44]
772c1a29: SHLWAPI!StrCpyW [772c0000+19cb+5e]

-- End of report


http://www.matroska.org


From chris at matroska.org  Mon Feb 24 11:11:12 2003
From: chris at matroska.org (Christian HJ Wiesner)
Date: Mon, 24 Feb 2003 11:11:12 +0100
Subject: [matroska-devel] Registration of the matroska project on Corecodec.org - everybody
 go there and register !!
Message-ID: <3E59EFC0.5070103@matroska.org>



Hi all !!

A long awaited day is coming closer and closer, the official launch date 
of http://corecodec.org !! I guess most of you will now what it is and 
what its good for already, for all the others here is a short explanation :

Corecodec.org is an opensource platform and community, just like 
sourceforge.net, but dedicated for audio and video compression. The main 
goal is to offer a bit more than just hosting for the project, by 
improving the communication between the single projects hosted on 
cc.org, and by assisting the developers registering a project there, 
starting from help with webpage creation to logo's, licensing questions, 
etc.

sourceforge.net is a great institution, an uncountable number of 
projects is hosted on it and a lot of great software has been started 
there, like apache or phpBB. But due to the high number of registered 
projects its impossible for the project admins to keep an overview of 
what that individual projects are doing, leave alone to help them. 
sourceforge is great host, but thats it !

The idea behind corecodec.org is to offer much more than that, by 
forming a real community, dedicated for one specific field being audio 
and video compression. The founders will work hard to make it a real 
advantage for developers if they decide to have their projects being 
hosted on corecodec.org instead of sourceforge.

Its maybe worth mentioning that we are in steady contact with the FSF, 
the entity behind sourceforge, to win them for our ideas and maybe even 
to get a free hosting from them one day. This was already planned 
together with FSF Germany, but unfortunately was stopped by FSF USA due 
to some misinformation about Corecodec being forwarded to them by the 
project administrator of another opensource community.


Well, you may ask whats the deal for matroska ?

Steve and me have decided long ago that we will move the matroska 
project from sourceforge to Corecodec.org once they have their server up 
and running, all services are running stable and the hosting is secured. 
While the server is running stable now for quite some time already and 
Cyt0plas, the corecodec admin, has managed to install GForge on RedHat 
Linux and to implement a working user/shell handling based on mysql, we 
will slowly move the project.

I am asking all of you to register on corecodec.org now ( 
http://corecodec.org/account/register.php ) and to send me a short email 
with the nickname you have been chosen, so i can add you to the project 
developers list.

Important note !

Please be aware that we will NOT move the project to corecodec.org  over 
night ! We plan to use all CVS facilities from sourceforge for the next 
time, and to test the CVS functionality on the new server thoroughly 
before making a cut here, most probably in about 2 - 3 months from now.

On the other hand, there will be a couple of things we wont do on the 
sf.net shell anymore, like defining jobs. AS we can rely the gforge 
interface here fully i will start doing them as soon as everybody has 
registered on cc.org .

Sorry for the long email

Regards

Christian

http://www.matroska.org


From rbultje at ronald.bitfreak.net  Mon Feb 24 12:09:55 2003
From: rbultje at ronald.bitfreak.net (Ronald Bultje)
Date: 24 Feb 2003 12:09:55 +0100
Subject: [matroska-devel] Re: Registration of the matroska project on
	Corecodec.org - everybody go there and register !!
In-Reply-To: <3E59EFC0.5070103@matroska.org>
References: <3E59EFC0.5070103@matroska.org>
Message-ID: <1046084994.3740.19.camel@localhost.localdomain>


Hey Chris,

On Mon, 2003-02-24 at 11:11, Christian HJ Wiesner wrote:
> sourceforge.net is a great institution, an uncountable number of 
> projects is hosted on it and a lot of great software has been started 
> there, like apache or phpBB. But due to the high number of registered 
> projects its impossible for the project admins to keep an overview of 
> what that individual projects are doing, leave alone to help them. 
> sourceforge is great host, but thats it !

Isn't this what SF foundries are for?

> I am asking all of you to register on corecodec.org now ( 
> http://corecodec.org/account/register.php ) and to send me a short email 
> with the nickname you have been chosen, so i can add you to the project 
> developers list.

Same as on SF: rbultje. Just subscribed!

(PS I've looked through docs etc., I'll start working on a mkv demuxer
plugin for GStreamer soon).

Ronald

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

http://www.matroska.org


From chris at wiesneronline.net  Mon Feb 24 14:05:56 2003
From: chris at wiesneronline.net (Christian HJ Wiesner)
Date: Mon, 24 Feb 2003 14:05:56 +0100
Subject: [matroska-devel] Re: Registration of the matroska project on
 Corecodec.org - everybody go there and register !!
In-Reply-To: <1046084994.3740.19.camel@localhost.localdomain>
References: <3E59EFC0.5070103@matroska.org> <1046084994.3740.19.camel@localhost.localdomain>
Message-ID: <3E5A18B4.4080609@wiesneronline.net>


Ronald Bultje wrote:
> Hey Chris,
>>sourceforge.net is a great institution, an uncountable number of 
>>projects is hosted on it and a lot of great software has been started 
> 
> Isn't this what SF foundries are for?

Probably yes, but

1. There is no such thing as a Audio/Video compression foundry AFAIK
2. We are members of the Java and the Gnome Foundry ( dont aks me why :O 
?? ), and i tried to turn to the java foundry leaders to ask if they 
could help us advertising EBML and the existing EBML4java code to other 
foundry members a bit, but there are no contact adresses nor does it say 
anywhere on the foundry homepage where one could turn to ? This is not 
at all a service as i am talking about for cc.org .

>>I am asking all of you to register on corecodec.org now ( 
>>http://corecodec.org/account/register.php ) and to send me a short email 
> 
> Same as on SF: rbultje. Just subscribed!

Great ! You were added to the project as developer now. Expect to find a 
secific job assigned to you soon ;) ...

> (PS I've looked through docs etc., I'll start working on a mkv demuxer
> plugin for GStreamer soon). 
> Ronald

Wooot !! In fact, that is the job i was talking about a few lines above 
:D ! Thanks a lot Ronald !

Great things happening right now guys !!

Christian


http://www.matroska.org


From rbultje at ronald.bitfreak.net  Mon Feb 24 14:34:01 2003
From: rbultje at ronald.bitfreak.net (Ronald Bultje)
Date: 24 Feb 2003 14:34:01 +0100
Subject: [matroska-devel] Re: Registration of the matroska project on
	Corecodec.org - everybody go there and register !!
In-Reply-To: <3E5A18B4.4080609@wiesneronline.net>
References: <3E59EFC0.5070103@matroska.org>
	 <1046084994.3740.19.camel@localhost.localdomain>
	 <3E5A18B4.4080609@wiesneronline.net>
Message-ID: <1046093641.3778.33.camel@localhost.localdomain>


Hey Chris,

On Mon, 2003-02-24 at 14:05, Christian HJ Wiesner wrote:
> 1. There is no such thing as a Audio/Video compression foundry AFAIK

we could have created one. ;-). How about the codecs.org people? They'll
be interested too... So will mjpegtools, GStreamer (I suppose), ffmpeg,
etc. etc. etc.

There's a huge amount of multimedia work going on in the Linux world,
and it'll be hard to move them all away from SF to CC. I'm fairly sure
mjpegtools and GStreamer won't move over to CC, simply because we're too
much used to SF with all its limitations - so creating CC causes
fragmentation too. Anyway, I have my doubts but I'll just continue
working on CC, I don't really care anyway. ;-). As long as development
works, I'll be happy.

> Great ! You were added to the project as developer now. Expect to find a 
> secific job assigned to you soon ;) ...
> > (PS I've looked through docs etc., I'll start working on a mkv demuxer
> > plugin for GStreamer soon). 
> Wooot !! In fact, that is the job i was talking about a few lines above 
> :D ! Thanks a lot Ronald !

Uh oh. ;-).

Ronald

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

http://www.matroska.org


From animesh.srivastava at blr.techspan.com  Mon Feb 24 14:11:02 2003
From: animesh.srivastava at blr.techspan.com (Animesh Srivastava)
Date: Mon, 24 Feb 2003 18:41:02 +0530
Subject: [matroska-devel] Re: Registration of the matroska project on 
	Corecodec.org - everybody go there and register !!
Message-ID: <09079F636BE1D611BC1600B0D0FCAC6601EF8F@BLR>


username on corecodec.org: anisri

-----Original Message-----
From: Christian HJ Wiesner [mailto:chris at wiesneronline.net]
Sent: Monday, February 24, 2003 6:36 PM
To: matroska-devel at freelists.org
Cc: bbb at matroska.org
Subject: [matroska-devel] Re: Registration of the matroska project on
Corecodec.org - everybody go there and register !!



Ronald Bultje wrote:
> Hey Chris,
>>sourceforge.net is a great institution, an uncountable number of 
>>projects is hosted on it and a lot of great software has been started 
> 
> Isn't this what SF foundries are for?

Probably yes, but

1. There is no such thing as a Audio/Video compression foundry AFAIK
2. We are members of the Java and the Gnome Foundry ( dont aks me why :O 
?? ), and i tried to turn to the java foundry leaders to ask if they 
could help us advertising EBML and the existing EBML4java code to other 
foundry members a bit, but there are no contact adresses nor does it say 
anywhere on the foundry homepage where one could turn to ? This is not 
at all a service as i am talking about for cc.org .

>>I am asking all of you to register on corecodec.org now ( 
>>http://corecodec.org/account/register.php ) and to send me a short email 
> 
> Same as on SF: rbultje. Just subscribed!

Great ! You were added to the project as developer now. Expect to find a 
secific job assigned to you soon ;) ...

> (PS I've looked through docs etc., I'll start working on a mkv demuxer
> plugin for GStreamer soon). 
> Ronald

Wooot !! In fact, that is the job i was talking about a few lines above 
:D ! Thanks a lot Ronald !

Great things happening right now guys !!

Christian


http://www.matroska.org
http://www.matroska.org


From moritz at bunkus.org  Wed Feb 26 10:05:44 2003
From: moritz at bunkus.org (Moritz Bunkus)
Date: Wed, 26 Feb 2003 10:05:44 +0100
Subject: [matroska-devel] memory leaks
Message-ID: <20030226090544.GU30789@bunkus.org>

An embedded and charset-unspecified text was scrubbed...
Name: not available
URL: <http://lists.matroska.org/pipermail/matroska-devel/attachments/20030226/adac6d4a/attachment.ksh>

From moritz at bunkus.org  Wed Feb 26 10:14:09 2003
From: moritz at bunkus.org (Moritz Bunkus)
Date: Wed, 26 Feb 2003 10:14:09 +0100
Subject: [matroska-devel] Re: memory leaks
In-Reply-To: <20030226090544.GU30789@bunkus.org>
References: <20030226090544.GU30789@bunkus.org>
Message-ID: <20030226091409.GV30789@bunkus.org>

An embedded and charset-unspecified text was scrubbed...
Name: not available
URL: <http://lists.matroska.org/pipermail/matroska-devel/attachments/20030226/2c2d2e8f/attachment.ksh>

From chris at matroska.org  Wed Feb 26 17:40:17 2003
From: chris at matroska.org (Christian HJ Wiesner)
Date: Wed, 26 Feb 2003 17:40:17 +0100
Subject: [matroska-devel] MPEG2 video in matroska
Message-ID: <3E5CEDF1.5020808@matroska.org>


This seems to be a very useful resource for MPEG specs ( thanks to 
fcchandler for sharing it ) :

http://www.wotsit.org/

And no, i wont stop dreaming this dream ;) ...

Christian

http://www.matroska.org


From spyder482 at yahoo.com  Thu Feb 27 02:00:19 2003
From: spyder482 at yahoo.com (John Cannon)
Date: Wed, 26 Feb 2003 19:00:19 -0600
Subject: [matroska-devel] MPEG in Matroska
Message-ID: <b3jnt4$5gk$1@main.gmane.org>

I am coding a simple MPEG-1 parser i n hopes of making a transmuxer one day.
Anyway, I was wondering what would be the best method of storing the frames?
In MPEG-1 even, the quantizer table can change at every GOP if you want.  So
do we just chop the stream and include these headers with the I frame or
what?

Spyder

PS: an answer to the discussion earlier, B frames can reference any frame
before or after them in the same GOP as long as it's not another B frame.
And P frames can reference any single frame before them in the same GOP.
(from a very trusted source :) )



http://www.matroska.org


From chris at matroska.org  Thu Feb 27 09:25:56 2003
From: chris at matroska.org (Christian HJ Wiesner)
Date: Thu, 27 Feb 2003 09:25:56 +0100
Subject: [matroska-devel] Re: MPEG in Matroska
In-Reply-To: <b3jnt4$5gk$1@main.gmane.org>
References: <b3jnt4$5gk$1@main.gmane.org>
Message-ID: <3E5DCB94.5000404@matroska.org>


cc : virtualdubmod-devel at lists dot sf dot net
cc : pulco-citron at users dot sf dot net  ( author of the original MPEG2 
parser for VirtualdubMod )




Hi !

John Cannon wrote:
> I am coding a simple MPEG-1 parser i n hopes of making a transmuxer one day.
> Anyway, I was wondering what would be the best method of storing the frames?
> In MPEG-1 even, the quantizer table can change at every GOP if you want.  So
> do we just chop the stream and include these headers with the I frame or
> what?

John, this is making me really happy !!! If you say you are coding a 
MPEG parser, why dont you use existing code, like from fcchandlers 
Virtualdub_MPEG2 ?

In any case, i think its a good way to start with MPEG1 video, so we can 
learn how to do it, and then proceed to MPEG2 later. There is just one 
thing burning on my mind, this is a matter of priorities. Sure, 
everybody is free to work on the things he likes to do the most and as i 
see it all the *really* neccesary stuff for the launch of matroska is 
being worked on already ( there is no need for the file 
repair/optimization tool to be available on day 1 IMHO ), so you could 
jump into looking at this. Its just, i want to avoid that the other team 
members will be angry on me because i am pushing you into this now, 
while maybe there is a lot of other stuff to do right now ? Any opinions 
on this from the other team members ?

With respect to GOPs, i think we should bring the power of EBML in here 
and define a GOP EBML element ... i hope this was possible ? Alex 
'Foogod' Stewart was giving a breif overview to me what it would take to 
get this working. He was talking about several 'layers' or 'levels' of 
the MPEG container, and he himslef was not sure as to what layers could 
be dropped, as they are covered by existing matroska elements already, 
what layers would have to be copied from the MPEG without altering, like 
putting them into codec private data, and for what layers we would have 
to define new EBML elements.

> PS: an answer to the discussion earlier, B frames can reference any frame
> before or after them in the same GOP as long as it's not another B frame.
> And P frames can reference any single frame before them in the same GOP.
> (from a very trusted source :) )

Before of after them ? Does our current referencing principle allow this ?

Christian

http://www.matroska.org


From spyder482 at yahoo.com  Fri Feb 28 06:03:29 2003
From: spyder482 at yahoo.com (John Cannon)
Date: Thu, 27 Feb 2003 23:03:29 -0600
Subject: [matroska-devel] Re: MPEG in Matroska
References: <b3jnt4$5gk$1@main.gmane.org> <3E5DCB94.5000404@matroska.org>
Message-ID: <b3mqgq$qr3$1@main.gmane.org>

> John, this is making me really happy !!! If you say you are coding a
> MPEG parser, why dont you use existing code, like from fcchandlers
> Virtualdub_MPEG2 ?

Well, i think it uses the DVD2AVI approach which is not as portable as I
would like.  But correct me if I am wrong. :)

>
> In any case, i think its a good way to start with MPEG1 video, so we can
> learn how to do it, and then proceed to MPEG2 later. There is just one
> thing burning on my mind, this is a matter of priorities. Sure,
> everybody is free to work on the things he likes to do the most and as i
> see it all the *really* neccesary stuff for the launch of matroska is
> being worked on already ( there is no need for the file
> repair/optimization tool to be available on day 1 IMHO ), so you could
> jump into looking at this. Its just, i want to avoid that the other team
> members will be angry on me because i am pushing you into this now,
> while maybe there is a lot of other stuff to do right now ? Any opinions
> on this from the other team members ?
>
> With respect to GOPs, i think we should bring the power of EBML in here
> and define a GOP EBML element ... i hope this was possible ? Alex
> 'Foogod' Stewart was giving a breif overview to me what it would take to
> get this working. He was talking about several 'layers' or 'levels' of
> the MPEG container, and he himslef was not sure as to what layers could
> be dropped, as they are covered by existing matroska elements already,
> what layers would have to be copied from the MPEG without altering, like
> putting them into codec private data, and for what layers we would have
> to define new EBML elements.
>
> > PS: an answer to the discussion earlier, B frames can reference any
frame
> > before or after them in the same GOP as long as it's not another B
frame.
> > And P frames can reference any single frame before them in the same GOP.
> > (from a very trusted source :) )
>
> Before of after them ? Does our current referencing principle allow this ?
>
> Christian
>
> http://www.matroska.org
>



http://www.matroska.org


From chris at matroska.org  Fri Feb 28 08:16:20 2003
From: chris at matroska.org (Christian HJ Wiesner)
Date: Fri, 28 Feb 2003 08:16:20 +0100
Subject: [matroska-devel] Re: MPEG in Matroska
In-Reply-To: <b3mqgq$qr3$1@main.gmane.org>
References: <b3jnt4$5gk$1@main.gmane.org> <3E5DCB94.5000404@matroska.org> <b3mqgq$qr3$1@main.gmane.org>
Message-ID: <3E5F0CC4.7060300@matroska.org>


John Cannon wrote:

>>John, this is making me really happy !!! If you say you are coding a
>>MPEG parser, why dont you use existing code, like from fcchandlers
>>Virtualdub_MPEG2 ?
>>    
>>
>
>Well, i think it uses the DVD2AVI approach which is not as portable as I
>would like.  But correct me if I am wrong. :)
>
So, stand corrected !!

The original code of pulco-citron was using DVD2AVI, latest version of 
VirtualdubMod uses fcchandlers MPEG1/2 mod, he much improved the 
existing MPEG parser in Virtualdub, and it can do AC3 decoding also. 
Browse the VdubMod forum for more info

Christian

http://www.matroska.org


From steve.lhomme at free.fr  Thu Feb 27 10:01:49 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Thu, 27 Feb 2003 10:01:49 +0100 (CET)
Subject: [matroska-devel] Re: MPEG in Matroska
In-Reply-To: <b3jnt4$5gk$1@main.gmane.org>
References: <b3jnt4$5gk$1@main.gmane.org>
Message-ID: <1046336509.3e5dd3fd84b99@imp.free.fr>


En r?ponse ? John Cannon <spyder482 at yahoo.com>:

> I am coding a simple MPEG-1 parser i n hopes of making a transmuxer one
> day.

What happened to the 10 other projects you started ? :(
If you never finish anything it's never going to serve anyone. (well, at least
YOU are learning)

> Anyway, I was wondering what would be the best method of storing the
> frames?
> In MPEG-1 even, the quantizer table can change at every GOP if you want.
>  So
> do we just chop the stream and include these headers with the I frame
> or what?

There is the CodecState that is supposed to handle that. BTW, that makes me
think, that in the codec (web)page the CodecState should be defined for each
codec (along with the CodecID and the CodecPrivate).

> PS: an answer to the discussion earlier, B frames can reference any
> frame
> before or after them in the same GOP as long as it's not another B
> frame.
> And P frames can reference any single frame before them in the same
> GOP.
> (from a very trusted source :) )

OK, we also came to that conclusion. Hopefully the reference system in matroska
is flexible enough to support that :)
http://www.matroska.org


From spyder482 at yahoo.com  Fri Feb 28 05:53:05 2003
From: spyder482 at yahoo.com (John Cannon)
Date: Thu, 27 Feb 2003 22:53:05 -0600
Subject: [matroska-devel] Re: MPEG in Matroska
References: <b3jnt4$5gk$1@main.gmane.org> <1046336509.3e5dd3fd84b99@imp.free.fr>
Message-ID: <b3mptb$p7u$1@main.gmane.org>


"Steve Lhomme" <steve.lhomme at free.fr> wrote in message
news:1046336509.3e5dd3fd84b99 at imp.free.fr...
>
> En r?ponse   John Cannon <spyder482 at yahoo.com>:
>
> > I am coding a simple MPEG-1 parser i n hopes of making a transmuxer one
> > day.
>
> What happened to the 10 other projects you started ? :(
> If you never finish anything it's never going to serve anyone. (well, at
least
> YOU are learning)
>

Yes I am lerning and I am not sure of which 10 projects you speak.  I have
voiced my lack of interest in completing the Java version of Matroska.  My
AVISynth filters were pretty much lost in the HD crisis of a week ago.  As
for my SRT2USF, there is not much to be done here.  I came across a document
describing MPEG1 and began coding.  It gives me a chance to do real C coding
and something related to Matroska at least.  And also, it allows me to
learn.  I have already learned much from this project and I do not intend to
drop this one as I have some others.  I will hereby officially declare that
I am postponing my Java coding for EBML and Matroska.  My code is freely
available at the CVS for those who want it.

> > Anyway, I was wondering what would be the best method of storing the
> > frames?
> > In MPEG-1 even, the quantizer table can change at every GOP if you want.
> >  So
> > do we just chop the stream and include these headers with the I frame
> > or what?
>
> There is the CodecState that is supposed to handle that.

Ah yes.  That works nicely. :)

> OK, we also came to that conclusion. Hopefully the reference system in
matroska
> is flexible enough to support that :)

Striaght from ISO MPEG standards docs.  :)  It should support it fine as
long as it allows reverse references and two references. :) (AFAIK, this is
no issue)

Please don't think bad of me for trying new things repeatedly (I know it's
getting out of hand. :) )  Anyway, I just want to learn and one day be
skillful enought to do real coding instead of just Java or only simple C
things.  Afterall, I do have more free time than most of you I believe.

John

PS: I am writing this at 10:48 PM CST.  I will be leaving in the morning to
go South to Houma for Mardi Gras ;)  I will return once I have sobered up
Monday morning :)




http://www.matroska.org


From chris at matroska.org  Thu Feb 27 10:31:01 2003
From: chris at matroska.org (Christian HJ Wiesner)
Date: Thu, 27 Feb 2003 10:31:01 +0100
Subject: [matroska-devel] Re: MPEG in Matroska
In-Reply-To: <b3jnt4$5gk$1@main.gmane.org>
References: <b3jnt4$5gk$1@main.gmane.org>
Message-ID: <3E5DDAD5.4020609@matroska.org>


John Cannon wrote:
> I am coding a simple MPEG-1 parser i n hopes of making a transmuxer one day.
> Anyway, I was wondering what would be the best method of storing the frames?
> In MPEG-1 even, the quantizer table can change at every GOP if you want.  So
> do we just chop the stream and include these headers with the I frame or
> what?

John,

have a look here :

http://www.offeryn.de/dv.htm


MPEGanalizzatore :

tries to help you in finding the structure of an MPEG2 Program Stream.
If you are like me, always trying to find the "best" way to convert your 
videos into something your DVD-Player will grok .... you might also be 
like me in always trying out new programs. And then you wonder ... why 
is that generated MPEG PS so funny...

!!! *MPEGanalizzatore tells you about the packs, the headers, the GOPs 
and pics inside an MPEG2 Program Stream.* !!!

If you are like me, trying to handcraft your own tools, MPEGanalizzatore 
may be of even more use --- to find out, _what_ your program really 
produces. MPEGanalizzatore is freeware and may be freely downloaded, 
used and distributed.

Many thanks to Jcsston for the link !

Christian

http://www.matroska.org


From spyder482 at yahoo.com  Fri Feb 28 05:54:00 2003
From: spyder482 at yahoo.com (John Cannon)
Date: Thu, 27 Feb 2003 22:54:00 -0600
Subject: [matroska-devel] Re: MPEG in Matroska
References: <b3jnt4$5gk$1@main.gmane.org> <3E5DDAD5.4020609@matroska.org>
Message-ID: <b3mpv2$pdh$1@main.gmane.org>

Cool, i'll check it when i get back :)



http://www.matroska.org


From moritz at bunkus.org  Thu Feb 27 13:26:24 2003
From: moritz at bunkus.org (Moritz Bunkus)
Date: Thu, 27 Feb 2003 13:26:24 +0100
Subject: [matroska-devel] references, KaxCodecPrivate for Vorbis
Message-ID: <20030227122624.GZ30789@bunkus.org>

An embedded and charset-unspecified text was scrubbed...
Name: not available
URL: <http://lists.matroska.org/pipermail/matroska-devel/attachments/20030227/763f82f5/attachment.ksh>

From steve.lhomme at free.fr  Fri Feb 28 16:32:25 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Fri, 28 Feb 2003 16:32:25 +0100 (CET)
Subject: [matroska-devel] Re: references, KaxCodecPrivate for Vorbis
Message-ID: <1046446345.3e5f81093a96b@imp.free.fr>


> 1. References

> What exactly do references point to? Let's take the frame sequence "I1
> P1 P2 P3 I2". The two I frames do not have any reference of course. P1
> has a reference to I1, that's also clear. But which frame do P2 and P3
> reference? Their predecessors (e.g. P2 -> P1 and P3 -> P2) or the I
> frame they belong to (which would mean P2 -> I1, P3 -> I1)?

Well, I really don't know. Since Spyder is having a look at the MPEG specs, he's
probably the one to ask. Apparently a P frame just references the previous frame
(not a B frame BTW).

> 2. Storing the header packets for Vorbis in KaxCodecPrivate

> Just to let you all know what I'm talking about: Vorbis actually needs
> three packets in order to be able to decode everything: the headers, a
> comment packet and the codec setup data. The question is how to store
> these three independent blocks.

> Cyrius and I have discussed numerous approaches, e.g.
 
> - using more than one KaxCodecPrivate element (which is a violation of
>   the current specs),

Not good ! There must be one per Track.

> - putting only the header packet into KaxCodecPrivate and the other two
>   packets into the first two KaxBlocks as part of the normal data
>   stream,

That's possible. But actually the Codec setup need to be in the CodecPrivate
element, that's what it's made for (and probably the headers too).

> - putting all three packets into the one KaxCodecPrivate: we'd store
>   the length1 (four bytes, little endian), packet1, the length2 (again
>   four bytes, little endian), packet2, packet3 (the last packet's
>   length can be calculated by KaxCodecPrivate's length - length1 -
>   length2),

That solution is OK.

> - putting all three packets into the one KaxCodecPrivate using the
>   lacing mechanism.

That's also a good solution, but probably overkill :)

> Method three sucks because we introduce endianess dependencies that we
> don't have anywhere else (apart from BITMAPINFOHEADER/WAVEFORMATEX, but
> these only occur in MS compat mode).

Does ODD+Vorbis handle the endianess setting in ODD or in Vorbis ? If it's in
Vorbis then we don't need to care about it, it is probably part of the 3 packets.

> Method four is what we propose. Lacing is already described on the
> Matroska specs page, so we could simply point the user to them from the
> codec page.

But that won't solve the endianess problem... So it's still overkill. Maybe wit
lacing you would be able to save space... or not.

> Summary: Cyrius and I vote for using lacing. If no one objects we'd like
> to have the codec page updated with this information. I can provide the
> text for it if you'd like.

So you can update it. It's in CVS (and downloaded directly from there) ! Feel free.
http://www.matroska.org


From Paul at msn.com  Fri Feb 28 18:19:22 2003
From: Paul at msn.com (Pamel)
Date: Fri, 28 Feb 2003 11:19:22 -0600
Subject: [matroska-devel] Re: references, KaxCodecPrivate for Vorbis
References: <1046446345.3e5f81093a96b@imp.free.fr>
Message-ID: <b3o5lg$rjt$1@main.gmane.org>

"Steve Lhomme" <steve.lhomme at free.fr> wrote
> > - putting all three packets into the one KaxCodecPrivate: we'd store
> >   the length1 (four bytes, little endian), packet1, the length2 (again
> >   four bytes, little endian), packet2, packet3 (the last packet's
> >   length can be calculated by KaxCodecPrivate's length - length1 -
> >   length2),
>
> That solution is OK.
>
> > - putting all three packets into the one KaxCodecPrivate using the
> >   lacing mechanism.
>
> That's also a good solution, but probably overkill :)

What about just making KaxCodecPrivate contain subelements?  Then you could
store all sorts of wacky data that codecs already want to store under
seperate headers.


Pamel



http://www.matroska.org


From steve.lhomme at free.fr  Fri Feb 28 19:17:27 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Fri, 28 Feb 2003 19:17:27 +0100
Subject: [matroska-devel] Re: references, KaxCodecPrivate for Vorbis
In-Reply-To: <1046446345.3e5f81093a96b@imp.free.fr>
References: <1046446345.3e5f81093a96b@imp.free.fr> <b3o5lg$rjt$1@main.gmane.org>
Message-ID: <3E5FA7B7.5010107@free.fr>


Pamel wrote:

> "Steve Lhomme"  wrote
>
> >>- putting all three packets into the one KaxCodecPrivate: we'd store
> >>  the length1 (four bytes, little endian), packet1, the length2 (again
> >>  four bytes, little endian), packet2, packet3 (the last packet's
> >>  length can be calculated by KaxCodecPrivate's length - length1 -
> >>  length2),
> >
> >That solution is OK.
> >
> >
> >>- putting all three packets into the one KaxCodecPrivate using the
> >>  lacing mechanism.
> >
> >That's also a good solution, but probably overkill :)
>
>
> What about just making KaxCodecPrivate contain subelements?  Then you 
> could
> store all sorts of wacky data that codecs already want to store under
> seperate headers.

Because there is no need to define an element for each codec 
specificities. As you know the element IDs are not infinite... Well, 
they are, but less efficient then ;)

The matroska level doesn't really need to understand what's inside the 
codec.

http://www.matroska.org