From spyder482 at yahoo.com  Thu Mar  6 03:23:31 2003
From: spyder482 at yahoo.com (John Cannon)
Date: Wed, 5 Mar 2003 20:23:31 -0600
Subject: [matroska-devel] Re: MPEG in Matroska
References: <b3jnt4$5gk$1@main.gmane.org> <3E5DCB94.5000404@matroska.org> <b3mqgq$qr3$1@main.gmane.org> <3E5F0CC4.7060300@matroska.org>
Message-ID: <b46bce$oi9$1@main.gmane.org>

I have my code finding syncwords now.  It only took a minute to find the
problem.  I wasn't opening the file in binary mode :)

Anyway, I can correctly identify packets from separate streams now.  It
shouldn't take me too long to have it demuxing the streams to elementary
streams and then splitting them into frames for Matroska.  MPEG is a really
difficult container.  All of this 1 marker bit +14bits+1 marker bit is
really annoying to parse.  I think we should simply package the MPEG
audio/video frames directly into Matroska.  There would be little overhead
and this way the frames are easily compatible with decoders that will play
an elementary stream.  Elementary streams are simply frames stuck together
one after the other as in MP3 files.  They have no containing elements like
packs or pages so it should be easlily done.  You should be able to dump the
output of the Matroska DShow filter into a file (with Dump.ax) and get the
elementary stream for that track.  Any thoughts?

John



http://www.matroska.org


From Paul at msn.com  Thu Mar  6 06:07:10 2003
From: Paul at msn.com (Pamel)
Date: Wed, 5 Mar 2003 23:07:10 -0600
Subject: [matroska-devel] Re: MPEG in Matroska
References: <b3jnt4$5gk$1@main.gmane.org> <3E5DCB94.5000404@matroska.org> <b3mqgq$qr3$1@main.gmane.org> <3E5F0CC4.7060300@matroska.org> <b46bce$oi9$1@main.gmane.org>
Message-ID: <b46l0l$jgu$1@main.gmane.org>

"John Cannon" <spyder482 at yahoo.com> wrote
> I think we should simply package the MPEG
> audio/video frames directly into Matroska.  There would be little overhead
> and this way the frames are easily compatible with decoders that will play
> an elementary stream.

I thought that was how we were intending to do it all along?  Hopefully
someone will make it able to automatically carry extra information over into
Matroska, like the AR info.


Pamel



http://www.matroska.org


From steve.lhomme at free.fr  Sun Mar  2 17:07:08 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Sun, 02 Mar 2003 17:07:08 +0100
Subject: [matroska-devel] Matroska IDs
Message-ID: <b3ta5h$jqo$1@main.gmane.org>


A quick email to inform you that, on Pamel's request, I've reduced the 
size of some elements in the Cluster (all 1 octet now) and in the Cue 
(nearly all 1 octet now).

The move should be sensitive for the Cues, where the size is reduced 
from 1 to several octets depending on references. That should keep our 
size advantage over AVI and OGM based on existing tests.


http://www.matroska.org


From Paul at msn.com  Sun Mar  2 17:14:09 2003
From: Paul at msn.com (Pamel)
Date: Sun, 2 Mar 2003 10:14:09 -0600
Subject: [matroska-devel] Changed Class-ID's
Message-ID: <b3tain$llf$1@main.gmane.org>

Just a quick note to let everyone know that some of the major Class-ID's
have been changed in the Matroska specs to single byte ID's, namely Position
and PrevSize, which should decrease the size of each cluster 2-3 bytes.
Unfortunately, this means that any existing *.mkv files are no longer valid.
Fortunately, this means that you will probably see a 15-22KB decrease in
filesize for a 2 hour video clip.

Also, some of the elements under Cues where changed to single byte IDs to
save space, but as these haven't been implemented yet, it won't have an
effect on existing codebase.

Welcome to the alpha status of Matroska.


Pamel



http://www.matroska.org


From steve.lhomme at free.fr  Sun Mar  2 17:31:59 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Sun, 02 Mar 2003 17:31:59 +0100
Subject: [matroska-devel] Re: Changed Class-ID's
In-Reply-To: <b3tain$llf$1@main.gmane.org>
References: <b3tain$llf$1@main.gmane.org>
Message-ID: <3E6231FF.9000305@free.fr>


Pamel wrote:
> Just a quick note to let everyone know that some of the major Class-ID's
> have been changed in the Matroska specs to single byte ID's, namely Position
> and PrevSize, which should decrease the size of each cluster 2-3 bytes.
> Unfortunately, this means that any existing *.mkv files are no longer valid.

No, they were never used so far (so the size is neither reduced).

> Fortunately, this means that you will probably see a 15-22KB decrease in
> filesize for a 2 hour video clip.

Not for now :)

> Also, some of the elements under Cues where changed to single byte IDs to
> save space, but as these haven't been implemented yet, it won't have an
> effect on existing codebase.
> 
> Welcome to the alpha status of Matroska.

Nop. There shouldn't be any problem, except for the ones who have 
anticipated Cue support (now reading is possible too).

http://www.matroska.org


From Paul at msn.com  Mon Mar  3 07:31:59 2003
From: Paul at msn.com (Pamel)
Date: Mon, 3 Mar 2003 00:31:59 -0600
Subject: [matroska-devel] Re: Changed Class-ID's
References: <b3tain$llf$1@main.gmane.org> <3E6231FF.9000305@free.fr>
Message-ID: <b3usqv$osr$1@main.gmane.org>

"Steve Lhomme" <steve.lhomme at free.fr> wrote
> Pamel wrote:
> > Fortunately, this means that you will probably see a 15-22KB decrease in
> > filesize for a 2 hour video clip.
>
> Not for now :)
Errr.... yeah.  At least in cases where these elements are used, there is
one cluster per keyframe, and a keyframe occured about once a second, you
would see savings around 15-22KB.  The idea was that any element that would
be used repeatedly throughout a file would have a single byte ID to help
reduce file overhead.  And it looks like thats been done now.  :-)   I'm
pretty sure thats as efficient as its going to get while keeping flexibility
and integrity.


Pamel



http://www.matroska.org


From moritz at bunkus.org  Mon Mar  3 08:44:43 2003
From: moritz at bunkus.org (Moritz Bunkus)
Date: Mon, 3 Mar 2003 08:44:43 +0100
Subject: [matroska-devel] Re: Changed Class-ID's
In-Reply-To: <b3usqv$osr$1@main.gmane.org>
References: <b3tain$llf$1@main.gmane.org> <3E6231FF.9000305@free.fr> <b3usqv$osr$1@main.gmane.org>
Message-ID: <20030303074443.GB25362@bunkus.org>

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

From Paul at msn.com  Mon Mar  3 16:41:04 2003
From: Paul at msn.com (Pamel)
Date: Mon, 3 Mar 2003 09:41:04 -0600
Subject: [matroska-devel] Re: Changed Class-ID's
References: <b3tain$llf$1@main.gmane.org> <3E6231FF.9000305@free.fr> <b3usqv$osr$1@main.gmane.org> <20030303074443.GB25362@bunkus.org>
Message-ID: <b3vt0d$don$1@main.gmane.org>

"Moritz Bunkus" <moritz at bunkus.org> wrote
> Why is there one cluster per keyframe? Why should there be exactly one
> cluster per keyframe? Or do you mean a special case?

I just used it as an example, but for lossy codecs, it seems to be the most
convienient.  It just makes it so that a keyframe, and all dependant frames
are stored in a single cluster.  It would be nice to group things like that
for error resiliancy.  IE, the cluster is damaged beyond repair, so only one
group of frames is lost, and it won't affect any other group of frames.  Oh
course, it doesn't really matter, and you could store however many frames
you want, wherever you want.


Pamel



http://www.matroska.org


From spyder482 at yahoo.com  Wed Mar  5 15:35:55 2003
From: spyder482 at yahoo.com (John Cannon)
Date: Wed, 5 Mar 2003 08:35:55 -0600
Subject: [matroska-devel] Re: Changed Class-ID's
References: <b3tain$llf$1@main.gmane.org>
Message-ID: <b451tp$iqd$1@main.gmane.org>

I am not sure I agree here but it doesn't really bother me.  The only
problem I see is that this decreases our expansion capabilities for new
elements.  Saving a few bytes per cluster is no big deal.  If it were per
block, yeah that would be a good idea.  But this is just useless IMO.  If
you still want it this way, I'm OK with it.

PS: I just got back last night from Mardi Gras. :)

John



http://www.matroska.org


From steve.lhomme at free.fr  Wed Mar  5 16:10:53 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Wed, 05 Mar 2003 16:10:53 +0100 (CET)
Subject: [matroska-devel] Re: Changed Class-ID's
In-Reply-To: <b451tp$iqd$1@main.gmane.org>
References: <b3tain$llf$1@main.gmane.org> <b451tp$iqd$1@main.gmane.org>
Message-ID: <1046877053.3e66137d30aab@imp.free.fr>


En r?ponse ? John Cannon <spyder482 at yahoo.com>:

> I am not sure I agree here but it doesn't really bother me.  The only
> problem I see is that this decreases our expansion capabilities for
> new
> elements.  Saving a few bytes per cluster is no big deal.  If it were
> per
> block, yeah that would be a good idea.  But this is just useless IMO. 
> If
> you still want it this way, I'm OK with it.

Well, there is still plenty of room of 1 byte IDs (not even half of them are
used I think).

> PS: I just got back last night from Mardi Gras. :)

So mardi gras is more important in the USA than in France ?!!!
I hope you ate some crepes !
http://www.matroska.org


From steve.lhomme at free.fr  Mon Mar  3 16:09:26 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Mon, 03 Mar 2003 16:09:26 +0100 (CET)
Subject: [matroska-devel] CoreCodec track
Message-ID: <1046704166.3e63702692a57@imp.free.fr>


I just wanted to let you know that I'm already using the Tracker system at
corecodec.org to put some ideas of stuff that needs to be done and with what
priority. It is an additional system (and a better one) to the \todo I put
everywhere in the code.

https://corecodec.org/tracker/index.php?group_id=20&atid=129

The next alpha code will be released (like a freeze of the CVS) when items with
priority 5 and 6 will be done. From that point, any basic Matroska file could be
produced and read in a decent manner.

Then will start the beta phase. With corrections in the code, improving the
speed/reliability, adding features (there are plenty of them !) and implementing
FileKax for easy/lazy handling of Matroska files. This phase will end when all
the features/elements of Matroska will be handled (even basically) by the code.

Feel free to add more items to this Tracker if you have any idea on what's
missing and what should be done.
http://www.matroska.org


From animesh.srivastava at blr.techspan.com  Tue Mar  4 11:26:31 2003
From: animesh.srivastava at blr.techspan.com (Animesh Srivastava)
Date: Tue, 4 Mar 2003 15:56:31 +0530 
Subject: [matroska-devel] doubts.
Message-ID: <09079F636BE1D611BC1600B0D0FCAC6601EFA3@BLR>


Hi, 
	Not able to understand a few things.. Related with the EMBL specs
itself. (had mailed about it earlier) I was under the impression that EBML
defines a set of data types - integer, string etc and so on. Now since
everything is coded in binary there should be some codes (global IDs) to
denote wether the value is to be interpreted as a sting or an integer. 

For ex, Lets say we define Integer datatype as ID=[42 F3],.. and suppose the
semantics say that each element is followed by its size (in 1 byte) and then
its value - then a sequence of bytes 42 F3 01 0A 3C 8A would mean that its
an integer (42 F3) of size 1 byte (01) and the value is 0A, so that gives us
the integer 10 (decimal).

Similarily if Strings had global ID of say, 45 BC then an input sequence 45
BC 02 D1 AF would mean that the parser should attempt to decode D1 AF as a
string.. 

And this global ID should have been there for each of the datatypes.. Date,
Integer, String etc.. And by global I mean that they dont change,.. as in
they are a part of specs themselves.

Going through the sources and the specs however I am getting the impression
that we dont have Global IDs for datatypes (or maybe i am missing them, if
that is the case let me know where to find it). 

So my question is when the parser is asked to read the next element how does
it figures out wether the sequnce of bytes it is reading should be
interpreted as an EBMLInteger or a EBMLDate.. 

Animesh.
http://www.matroska.org


From steve.lhomme at free.fr  Tue Mar  4 11:53:18 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Tue, 04 Mar 2003 11:53:18 +0100 (CET)
Subject: [matroska-devel] Re: doubts.
In-Reply-To: <09079F636BE1D611BC1600B0D0FCAC6601EFA3@BLR>
References: <09079F636BE1D611BC1600B0D0FCAC6601EFA3@BLR>
Message-ID: <1046775198.3e64859ece8ba@imp.free.fr>


En r?ponse ? Animesh Srivastava <animesh.srivastava at blr.techspan.com>:

> Hi, 

Hi Animesh,

> 	Not able to understand a few things.. Related with the EMBL specs
> itself. (had mailed about it earlier) I was under the impression that
> EBML
> defines a set of data types - integer, string etc and so on. Now since
> everything is coded in binary there should be some codes (global IDs)
> to
> denote wether the value is to be interpreted as a sting or an integer.

It's simple, there is not. It's like in XML, the semantic is separated from the
content/coding. If you have :

<my_tag value="8.223"/>

Is it a string, a float number, an IP address ?

> For ex, Lets say we define Integer datatype as ID=[42 F3],.. and suppose
> the
> semantics say that each element is followed by its size (in 1 byte) and
> then
> its value - then a sequence of bytes 42 F3 01 0A 3C 8A would mean that
> its
> an integer (42 F3) of size 1 byte (01) and the value is 0A, so that
> gives us
> the integer 10 (decimal).
> 
> Similarily if Strings had global ID of say, 45 BC then an input sequence
> 45
> BC 02 D1 AF would mean that the parser should attempt to decode D1 AF as
> a
> string.. 

The size coded on one octet is actually (0x80 | size), that means the most
significant bit is set. So in your examples the sizes would be 81 and 82
respectively.

This is to avoid "false alarm" when trying to find an ID in a file and you
encounter UTF8 data.
 
> And this global ID should have been there for each of the datatypes..
> Date,
> Integer, String etc.. And by global I mean that they dont change,.. as
> in
> they are a part of specs themselves.
>
> Going through the sources and the specs however I am getting the
> impression
> that we dont have Global IDs for datatypes (or maybe i am missing them,
> if
> that is the case let me know where to find it). 

That's right.
An ID represent : EBML type + interpretation of the data.
 
> So my question is when the parser is asked to read the next element how
> does
> it figures out wether the sequnce of bytes it is reading should be
> interpreted as an EBMLInteger or a EBMLDate.. 

If the element ID is known to you, the semantic will tell you what type it is.
If this element is not part of the semantic it is either :
- an error and should try finding an element you know
- an unknown element and you should just discard the content, as you don't know
how to handle the data anyway. You can choose to keep it in memory if you want
to put it in another file withougt changing the content you don't know.

I hope it's clearer now :)
http://www.matroska.org


From animesh.srivastava at blr.techspan.com  Tue Mar  4 12:23:00 2003
From: animesh.srivastava at blr.techspan.com (Animesh Srivastava)
Date: Tue, 4 Mar 2003 16:53:00 +0530 
Subject: [matroska-devel] Re: doubts.
Message-ID: <09079F636BE1D611BC1600B0D0FCAC6601EFA4@BLR>


-----Original Message-----
From: Steve Lhomme

> It's simple, there is not. It's like in XML, the semantic is separated
from the
> content/coding. If you have :
> <my_tag value="8.223"/>
> Is it a string, a float number, an IP address ?

Oh cool, I was missing this *very* important but subtle point. Thnx.

That means at any point of time, I am in some level (0,1,2 etc.. ) and
depending upon my current Level I am in, I would have a set of valid
Class-ID (http://ebml.sourceforge.net/specs/) which I can expect to
encounter. So whenever a find_next_ebml_element() call is made, I should
start reading the bytes,.. and see if the byte sequence matches any of the
Class-ID that I expect.. rite?

Also, since the ClassID can maximum be 4 bytes long (can be less too), so by
reading a maximum of 4 bytes I should have a valid classID (many times i
will get a valid Class-ID just by reading a single byte). If by the time I
read 4 bytes and still dont get a valid ClassID then that means there is an
error. Rite.?

If I get a valid Class-ID, then depending upon the class-id I would
construct either a EBMLDate or an EBMLInteger or something else. Rite? 

Btw, on the given specs page, I could not find any classid which should be
interpreted as a EBMLDate or EBMLFloat. For ex, the semantics for class-id
[4286] (EBMLVersion) means the I should interpret the data as an u-integer..
do we currently have any classid's which are interpreted as Dates or
Floats..

> I hope it's clearer now :)
Yups, very much.. esp the first one - that semantic is separate from
content. :) Thnx for that.

http://www.matroska.org


From steve.lhomme at free.fr  Tue Mar  4 12:56:29 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Tue, 04 Mar 2003 12:56:29 +0100 (CET)
Subject: [matroska-devel] Re: doubts.
In-Reply-To: <09079F636BE1D611BC1600B0D0FCAC6601EFA4@BLR>
References: <09079F636BE1D611BC1600B0D0FCAC6601EFA4@BLR>
Message-ID: <1046778989.3e64946d055a0@imp.free.fr>


En r?ponse ? Animesh Srivastava <animesh.srivastava at blr.techspan.com>:

> That means at any point of time, I am in some level (0,1,2 etc.. ) and
> depending upon my current Level I am in, I would have a set of valid
> Class-ID (http://ebml.sourceforge.net/specs/) which I can expect to
> encounter. So whenever a find_next_ebml_element() call is made, I
> should
> start reading the bytes,.. and see if the byte sequence matches any of
> the Class-ID that I expect.. rite?

Yes. Also your code shoul be able to detect IDs at the "current" level but also
at upper levels. That's what makes the code a bit complex (at least in my code).

> Also, since the ClassID can maximum be 4 bytes long (can be less too),
> so by
> reading a maximum of 4 bytes I should have a valid classID (many times
> i
> will get a valid Class-ID just by reading a single byte). If by the time
> I
> read 4 bytes and still dont get a valid ClassID then that means there is
> an error. Rite.?

Yes. Since having IDs up to 4 bytes gives a *LOT* of possibilities. I don't
think we'll see systems that require more than 4 in the coming years. It's fair
to decide that if the element found is bigger, there is an error.

> If I get a valid Class-ID, then depending upon the class-id I would
> construct either a EBMLDate or an EBMLInteger or something else. Rite?

Yes, that's what I use in the C++ code (object oriented). There should probably
be something similar in C too.

> Btw, on the given specs page, I could not find any classid which should
> be
> interpreted as a EBMLDate or EBMLFloat. For ex, the semantics for
> class-id
> [4286] (EBMLVersion) means the I should interpret the data as an
> u-integer..
> do we currently have any classid's which are interpreted as Dates or
> Floats..

Yes. You need to look at the Matroska specs which uses EBML. All kinds of
elements can be found there.
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/matroska/doc/website/specs/index.html?rev=HEAD&content-type=text/html
http://www.matroska.org


From moritz at bunkus.org  Wed Mar  5 17:44:34 2003
From: moritz at bunkus.org (Moritz Bunkus)
Date: Wed, 5 Mar 2003 17:44:34 +0100
Subject: [matroska-devel] a subtitle format
Message-ID: <20030305164434.GR17028@bunkus.org>

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

From chris at matroska.org  Thu Mar  6 10:31:07 2003
From: chris at matroska.org (Christian HJ Wiesner)
Date: Thu, 06 Mar 2003 10:31:07 +0100
Subject: [matroska-devel] Re: a subtitle format
In-Reply-To: <20030305164434.GR17028@bunkus.org>
References: <20030305164434.GR17028@bunkus.org>
Message-ID: <3E67155B.1060605@matroska.org>


Moritz Bunkus wrote:

>Hi everyone.
>- KaxCodecID is set to either 'S_TEXT' or 'S_TEXT/SIMPLE' (I prefer the
>  latter case).
>

What about the following subtitle IDs  :

'S_TEXT/ASCII'

'S_TEXT/UTF8'

'S_IMAGE/PNG'

'S_IMAGE/BMP'

'S_USF'

'S_SSA'

S_ASS'

'S_SRT'

Did i forget any ? Am i correct in my assumption that SRT = VobSub ?

Regards

Christian

http://www.matroska.org


From Liisachan at faireal.net  Thu Mar  6 11:08:32 2003
From: Liisachan at faireal.net (Liisachan)
Date: Thu, 06 Mar 2003 19:08:32 +0900
Subject: [matroska-devel] Re: a subtitle format
In-Reply-To: <3E67155B.1060605@matroska.org>
References: <20030305164434.GR17028@bunkus.org> <3E67155B.1060605@matroska.org>
Message-ID: <3E671E20.2060809@faireal.net>


Christian HJ Wiesner wrote:

>Moritz Bunkus wrote:
>
>  
>
>>Hi everyone.
>>- KaxCodecID is set to either 'S_TEXT' or 'S_TEXT/SIMPLE' (I prefer the
>> latter case).
>>
>>    
>>
>
>What about the following subtitle IDs  :
>
>'S_TEXT/ASCII'
>
>'S_TEXT/UTF8'
>
>'S_IMAGE/PNG'
>
>'S_IMAGE/BMP'
>
>'S_USF'
>
>'S_SSA'
>
>S_ASS'
>
>'S_SRT'
>
>Did i forget any ? Am i correct in my assumption that SRT = VobSub ?
>  
>
i believe "vobsub" should mean SUB+IDX too.

I m not sure whether or not this is technically possible,
but there are strong requests In CJK areas for soft-muxing a subtitle 
file in SUB Format (.SUB) ripped by VobSub,
in order to backup DVDs;
because the OCR of SubRip works only for Latin Alphabet etc. and not for 
CJK characters
(in short, if the sub in a dvd is in Chinese, Japanese or in Korean, you 
cannot get an SRT for it unless you type everything manually by yourself;
instead, you will get a file with extension .SUB (this is sub data) and 
.IDX (this is for timing if i remember correctly)

The fact that you cannot mux subs in .SUB is one of the main reasons why 
ppl in CJK areas are unhappy
 with sub supports in today's OGM.

Liisachan


http://www.matroska.org


From chris at matroska.org  Thu Mar  6 11:19:37 2003
From: chris at matroska.org (Christian HJ Wiesner)
Date: Thu, 06 Mar 2003 11:19:37 +0100
Subject: [matroska-devel] Re: a subtitle format
In-Reply-To: <3E671E20.2060809@faireal.net>
References: <20030305164434.GR17028@bunkus.org> <3E67155B.1060605@matroska.org> <3E671E20.2060809@faireal.net>
Message-ID: <3E6720B9.5080906@matroska.org>


TO : matroska-devel at freelists.org
TO : usf-devel at freelists.org

Liisachan wrote:

>Christian HJ Wiesner wrote:
>  
>
>>What about the following subtitle IDs  :
>>
>>'S_TEXT/ASCII'
>>
>>'S_TEXT/UTF8'
>>
>>'S_IMAGE/PNG'
>>
>>'S_IMAGE/BMP'
>>
>>'S_USF'
>>
>>'S_SSA'
>>
>>S_ASS'
>>
>>'S_SRT'
>>
>>Did i forget any ? Am i correct in my assumption that SRT = VobSub ?
>>
>>    
>>
>i believe "vobsub" should mean SUB+IDX too.
>
>I m not sure whether or not this is technically possible,
>but there are strong requests In CJK areas for soft-muxing a subtitle 
>file in SUB Format (.SUB) ripped by VobSub,
>in order to backup DVDs;
>because the OCR of SubRip works only for Latin Alphabet etc. and not for 
>CJK characters
>(in short, if the sub in a dvd is in Chinese, Japanese or in Korean, you 
>cannot get an SRT for it unless you type everything manually by yourself;
>instead, you will get a file with extension .SUB (this is sub data) and 
>.IDX (this is for timing if i remember correctly)
>
>The fact that you cannot mux subs in .SUB is one of the main reasons why 
>ppl in CJK areas are unhappy
> with sub supports in today's OGM.
>
>Liisachan
>

Liisachan, thanks for the input. Am i correct the .SUB file contains 
simple Bitmap images for every subtitle ? In this case the

'S_IMAGE/BMP'

codec ID could be used, and the .IDX file could simply be translated 
into matroska's block time codes, so it would disappear completely. 
Probably the easiest and best way to mux .SUB subtitles into matroska, 
and we had hardware support for this also once i manage to convince KiSS 
or Neuston to support matroska in their standalones ...

@Gabest : was it possible to include libpng into VobSub, such that the 
Bitmaps could be compressed to PNG, without altering anything ? Of 
course, matroska codec ID would then be set to

'S_IMAGE/PNG'

but the timing information ( .IDX file ) was exactly the same.

What do you guys think ? 
@Mosu : was this supportable on mplayer for Linux people ?
@BBB : doable for Gstreamer also to be able to render subs over an 
overlay mixer or such ? Or do you need the subs in the same video 
stream, so the matroska plugin has to blend them over before rendering 
to video sink ?

Regards

Christian

http://www.matroska.org


From moritz at bunkus.org  Thu Mar  6 11:31:49 2003
From: moritz at bunkus.org (Moritz Bunkus)
Date: Thu, 6 Mar 2003 11:31:49 +0100
Subject: [matroska-devel] Re: a subtitle format
In-Reply-To: <3E6720B9.5080906@matroska.org>
References: <20030305164434.GR17028@bunkus.org> <3E67155B.1060605@matroska.org> <3E671E20.2060809@faireal.net> <3E6720B9.5080906@matroska.org>
Message-ID: <20030306103149.GU17028@bunkus.org>

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

From Liisachan at faireal.net  Thu Mar  6 12:24:46 2003
From: Liisachan at faireal.net (Liisachan)
Date: Thu, 06 Mar 2003 20:24:46 +0900
Subject: [matroska-devel] Re: a subtitle format
In-Reply-To: <3E6720B9.5080906@matroska.org>
References: <20030305164434.GR17028@bunkus.org> <3E67155B.1060605@matroska.org> <3E671E20.2060809@faireal.net> <3E6720B9.5080906@matroska.org>
Message-ID: <3E672FFE.10504@faireal.net>


Christian HJ Wiesner wrote:

>Liisachan, thanks for the input. Am i correct the .SUB file contains 
>simple Bitmap images for every subtitle ? In this case the
>
>'S_IMAGE/BMP'
>
>codec ID could be used, and the .IDX file could simply be translated 
>into matroska's block time codes, so it would disappear completely. 
>

True. IDX file would be handled in that way,
and .SUB files could be translated into a sequence of simple bitmaps or 
PNG images.

Liisachan


http://www.matroska.org


From suiryc at yahoo.com  Thu Mar  6 16:46:44 2003
From: suiryc at yahoo.com (Cyrius)
Date: Thu, 6 Mar 2003 07:46:44 -0800 (PST)
Subject: [matroska-devel] Re: a subtitle format
In-Reply-To: <3E6720B9.5080906@matroska.org>
Message-ID: <20030306154644.78686.qmail@web12903.mail.yahoo.com>


Hi there

--- Christian HJ Wiesner <chris at matroska.org> wrote:
> 
> Liisachan, thanks for the input. Am i correct the
> .SUB file contains 
> simple Bitmap images for every subtitle ? In this
> case the
> 
> 'S_IMAGE/BMP'
> 
> codec ID could be used, and the .IDX file could
> simply be translated 
> into matroska's block time codes, so it would
> disappear completely. 
> Probably the easiest and best way to mux .SUB
> subtitles into matroska, 
> and we had hardware support for this also once i
> manage to convince KiSS 
> or Neuston to support matroska in their standalones
> ...
> 
> @Gabest : was it possible to include libpng into
> VobSub, such that the 
> Bitmaps could be compressed to PNG, without altering
> anything ? Of 
> course, matroska codec ID would then be set to
> 
> 'S_IMAGE/PNG'
> 
> but the timing information ( .IDX file ) was exactly
> the same.
> 

Before starting to do this (using PNG images instead
of BMP ones for subtitles) someone should do a test to
see if this wouldn't be a problem for realtime
playback.
To let you know, in VirtualDubMod I can only reach
45-50fps by _only_ decompressing PNG files to BMP
24bits (and _without_ showing them, just decompress
them in memory). Doing the same thing with the
original DivX5 compressed video clip I reach 90fps !!!
And yet the size of the image is 576x400, and I have a
XP 2400+.
Of course in subtitles you only need to decode an
image once in a while (i.e. when a subtitle begins)
but what I mean is that deocmpressing a PNG image take
some time (and of course some CPU power), even more
than decompressing the same image compressed with
DivX/XviD. If decompressing the image takes too much
resources and make the clip freeze a bit (even only
for one frame) this is already too much and will be be
highly noticeable during playback.

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


From chris at matroska.org  Wed Mar  5 22:24:47 2003
From: chris at matroska.org (Christian HJ Wiesner)
Date: Wed, 05 Mar 2003 22:24:47 +0100
Subject: [matroska-devel] Questions about audio handling in matroska
Message-ID: <3E666B1F.9010800@matroska.org>


Hi,

some important questions about audio handling in matroska came up when 
reading some threads on hydrogenaudio.org recently :

1. Gapless playback : I understand this is a very important thing for 
audio freaks, to be able to play a CD full of songs without gaps between 
them. Can matroska fulfill this ?

2. Replay Gain : I know Steve had plans to have a field entry in the 
track header for this value, so that all audio codecs could use it. Has 
it been implemented ? In case of Vorbis, thats using Xiph special 
solution 'Vorbis Gain', how would we handlee it in matroska ? Would 
Vorbis Gain value override Replay Gain ?

3. One Album in one matroska file : There have been questions about 
this. I understand its no problem as long as we use the same audio codec 
and sampling rate for this, as it can be all in one big track, and each 
song is a chapter. But what about a compilation of songs into one big 
matroska file ( = the album ) when different audio codecs were used ? 
Could we use the control track to play this ?

Thanks for answering

Christian

http://www.matroska.org


From spyder482 at yahoo.com  Thu Mar  6 03:16:44 2003
From: spyder482 at yahoo.com (John Cannon)
Date: Wed, 5 Mar 2003 20:16:44 -0600
Subject: [matroska-devel] Re: Questions about audio handling in matroska
References: <3E666B1F.9010800@matroska.org>
Message-ID: <b46avn$n4f$1@main.gmane.org>


"Christian HJ Wiesner" <chris at matroska.org> wrote in message
news:3E666B1F.9010800 at matroska.org...
>
> Hi,
>
> some important questions about audio handling in matroska came up when
> reading some threads on hydrogenaudio.org recently :
>
> 1. Gapless playback : I understand this is a very important thing for
> audio freaks, to be able to play a CD full of songs without gaps between
> them. Can matroska fulfill this ?

Hmmm, I think this is a codec/player thing.  MPEG Audio adds a bit of
silence to the beginning of the tracks and it causes audible pops in the
resulting files when played back sequentially.  Some CDs have songs that
overlap from track to track(i.e. a live performance recording).  This is a
problem with MP3.  I think Vorbis and MPC don't need this "warm up padding".

> 3. One Album in one matroska file : There have been questions about
> this. I understand its no problem as long as we use the same audio codec
> and sampling rate for this, as it can be all in one big track, and each
> song is a chapter. But what about a compilation of songs into one big
> matroska file ( = the album ) when different audio codecs were used ?
> Could we use the control track to play this ?

This is an interesting question.  I think this should be handled with
multiple segments in a file.  Vorbis files can be strung together in this
manner and played back continuously.  They can use whatever settings they
want IIRC.  It should even be possible to use different codecs in Matroska
files doing this if we use multiple segments in a file.



http://www.matroska.org


From Paul at msn.com  Thu Mar  6 06:04:59 2003
From: Paul at msn.com (Pamel)
Date: Wed, 5 Mar 2003 23:04:59 -0600
Subject: [matroska-devel] Re: Questions about audio handling in matroska
References: <3E666B1F.9010800@matroska.org> <b46avn$n4f$1@main.gmane.org>
Message-ID: <b46ksi$j57$1@main.gmane.org>

"John Cannon" <spyder482 at yahoo.com> wrote
> "Christian HJ Wiesner" <chris at matroska.org> wrote in message
> > 3. One Album in one matroska file : There have been questions about
> > this. I understand its no problem as long as we use the same audio codec
> > and sampling rate for this, as it can be all in one big track, and each
> > song is a chapter. But what about a compilation of songs into one big
> > matroska file ( = the album ) when different audio codecs were used ?
> > Could we use the control track to play this ?
>
> This is an interesting question.  I think this should be handled with
> multiple segments in a file.  Vorbis files can be strung together in this
> manner and played back continuously.  They can use whatever settings they
> want IIRC.  It should even be possible to use different codecs in Matroska
> files doing this if we use multiple segments in a file.

Just put each song into a seperate track.  Album covers and such can go as
attachments, and if you wanted to be fancy, you could have an HTML file to
display all of the pictures in a pretty format.


Pamel



http://www.matroska.org


From moritz at bunkus.org  Thu Mar  6 08:59:53 2003
From: moritz at bunkus.org (Moritz Bunkus)
Date: Thu, 6 Mar 2003 08:59:53 +0100
Subject: [matroska-devel] Re: Questions about audio handling in matroska
In-Reply-To: <b46ksi$j57$1@main.gmane.org>
References: <3E666B1F.9010800@matroska.org> <b46avn$n4f$1@main.gmane.org> <b46ksi$j57$1@main.gmane.org>
Message-ID: <20030306075953.GT17028@bunkus.org>

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

From steve.lhomme at free.fr  Thu Mar  6 10:15:21 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Thu, 06 Mar 2003 10:15:21 +0100 (CET)
Subject: [matroska-devel] Re: Questions about audio handling in matroska
In-Reply-To: <20030306075953.GT17028@bunkus.org>
References: <3E666B1F.9010800@matroska.org> <b46avn$n4f$1@main.gmane.org> <b46ksi$j57$1@main.gmane.org> <20030306075953.GT17028@bunkus.org>
Message-ID: <1046942121.3e6711a934608@imp.free.fr>


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

> But isn't that what segments are for? Supporting non-interleaved
> tracks
> will be a bitch to implement for every demultiplexer, especially if
> there's no cues (for whatever reason).
> 
> So the best way would be one track with chapter entries, or several
> segments if the songs are encoded with different codecs/settings.

Yep, that's what Chapters are for. That's why the ISRC code is found there for
example. One big track and you have no gaps at all :)

You can also use segments if the source is many different files. But you may
have gaps then.
http://www.matroska.org


From chris at matroska.org  Mon Mar 10 14:15:51 2003
From: chris at matroska.org (Christian HJ Wiesner)
Date: Mon, 10 Mar 2003 14:15:51 +0100
Subject: [matroska-devel] Re: Questions about audio handling in matroska
In-Reply-To: <3E666B1F.9010800@matroska.org>
References: <3E666B1F.9010800@matroska.org>
Message-ID: <3E6C9007.10802@matroska.org>


Steve, you didnt reply to question 2. You had plans to do this once, as 
a native matroska element .. did you drop them ?

Christian HJ Wiesner wrote:

>Hi,
>
>some important questions about audio handling in matroska came up when 
>reading some threads on hydrogenaudio.org recently :
>
>1. Gapless playback : I understand this is a very important thing for 
>audio freaks, to be able to play a CD full of songs without gaps between 
>them. Can matroska fulfill this ?
>
>2. Replay Gain : I know Steve had plans to have a field entry in the 
>track header for this value, so that all audio codecs could use it. Has 
>it been implemented ? In case of Vorbis, thats using Xiph special 
>solution 'Vorbis Gain', how would we handlee it in matroska ? Would 
>Vorbis Gain value override Replay Gain ?
>
>3. One Album in one matroska file : There have been questions about 
>this. I understand its no problem as long as we use the same audio codec 
>and sampling rate for this, as it can be all in one big track, and each 
>song is a chapter. But what about a compilation of songs into one big 
>matroska file ( = the album ) when different audio codecs were used ? 
>Could we use the control track to play this ?
>
>Thanks for answering
>
>Christian
>
>http://www.matroska.org
>
>  
>

http://www.matroska.org


From steve.lhomme at free.fr  Mon Mar 10 14:25:52 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Mon, 10 Mar 2003 14:25:52 +0100 (CET)
Subject: [matroska-devel] Re: Questions about audio handling in matroska
In-Reply-To: <3E6C9007.10802@matroska.org>
References: <3E666B1F.9010800@matroska.org> <3E6C9007.10802@matroska.org>
Message-ID: <1047302752.3e6c926012fa6@imp.free.fr>


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

No need to put me in the CC, I'm subscribed to all the lists :D
 
> Steve, you didnt reply to question 2. You had plans to do this once, as
> a native matroska element .. did you drop them ?
>
> >2. Replay Gain : I know Steve had plans to have a field entry in the 
> >track header for this value, so that all audio codecs could use it. Has
> >it been implemented ? In case of Vorbis, thats using Xiph special 
> >solution 'Vorbis Gain', how would we handlee it in matroska ? Would 
> >Vorbis Gain value override Replay Gain ?

Nop, I didn't drop it. I just totally forgot.
I think the replay gain depends on the track *and* on the album. But I'm not
sure. I'll try to find some documentation about it to handle it properly. Any
suggestion ?

I think I could add a ReplayGain float element, probably in the (audio) Track
entry. I'm not sure there is a need for an album tag. But I'll need confirmation
about that.

BTW, that make me thinks, that I've never tested to floating class on different
endianess machines ! I'll try to do that ASAP.
http://www.matroska.org


From chris at matroska.org  Mon Mar 10 14:51:52 2003
From: chris at matroska.org (Christian HJ Wiesner)
Date: Mon, 10 Mar 2003 14:51:52 +0100
Subject: [matroska-devel] Re: Questions about audio handling in matroska
In-Reply-To: <1047302752.3e6c926012fa6@imp.free.fr>
References: <3E666B1F.9010800@matroska.org> <3E6C9007.10802@matroska.org> <1047302752.3e6c926012fa6@imp.free.fr>
Message-ID: <3E6C9878.6020709@matroska.org>




Steve Lhomme wrote:

>Nop, I didn't drop it. I just totally forgot.
>
ehehehe .... consider me being your extended memory if it comes to 
matroska features .. lol

>I think the replay gain depends on the track *and* on the album. But I'm not
>sure. I'll try to find some documentation about it to handle it properly. Any
>suggestion ?
>  
>
http://www.replaygain.org

>I think I could add a ReplayGain float element, probably in the (audio) Track
>entry. I'm not sure there is a need for an album tag. But I'll need confirmation
>about that.
>  
>
Best thing was to drop a posting on hydrogenaudio.org i guess, all the 
replaygain fanatics are there and the creator ( 2Bdecided ) is reading 
there also

Christian

http://www.matroska.org


From chris at matroska.org  Thu Mar  6 12:26:01 2003
From: chris at matroska.org (Christian HJ Wiesner)
Date: Thu, 06 Mar 2003 12:26:01 +0100
Subject: [matroska-devel] Matroska : 1. Work list update 2. New job proposal 3. New team members
Message-ID: <3E673049.4050800@matroska.org>


Hi there,

a couple of things :

1. Work list update

Attached please find the listing of who is working on what, so we have a 
better overview :

- Steve 'robux4' LHomme : finishing main libmatroska C++ library

- Julien 'Cyrius' Coloos : matroskadub ; porting to Vdub 1.5.x , bug fixes

- Moritz 'Mosu' Bunkus : mkvtoolnix ; adding Vorbi support and frame 
referencing to mkvmerger, improving mplayer patch to support seeking in 
the file

- Jan 'myFUN/Kromyx' Schlenker : DirectShow parser ( soon )

- John 'spyder' Cannon : MPEG1 video muxing into matroska ; finishing 
SRT2USF.exe ( port to Linux )

- Animesh Shrivastava, Shailesh 'Shelly' Mistry : Porting libmatroska to 
C, updating C API

- Ronald 'BBB' Bultje : matroska Gstreamer plugin ( waiting in C lib )

- 'mmu_man' : Porting mkvmerger and mplayer patch to BeOS

- How ' How Man' Tam, Henry Poon : matroska streaming server, based on 
icecast ( not started yet )

- Jory Jcsston' : GUI in GTK for mkvmerger.exe ( learning phase )

- thana : file repair tool ( not started yet )

- David E. 'DaveEL' Leatherdale : avs2matroska.exe

- Marlena, RathO, David, Nupur Sarpal, Anshuman 'Golddragongt' 
Bhairavbhat : website creation, logo

- Raghavendran 'raghav' : MPC2matroska.exe

- ChristianHJW : clarifying legal status of matroska association


2. New job proposal :

Anybody volunteering to port Mosu's mkvmerger to Windows ? While 
matroskadub is a great tool to create ( mux ) and edit matroska files on 
Windows, i see problems coming along us with respect to muxing all the 
different subtitle formats we are going to support, as well as new audio 
formats such as
- MPC
- AAC
- FLAC
- Speex
Support muxing of those should be much easier to do from a command line 
based tool like Mosu's mkvmerger, so its essential for us we have it 
ported to Windows.

Anybody on the job ? Henry ( until we hear from How Tam ) ? Thana ? Shelly ?


3. New Team members

Please allow me to welcome

Marlena Deren , as new member of the design team ( our first female team 
member !! :-) )

Henry Poon, as new development team member. Welcome Henry, we hope 
working with our team will be big fun for you

Anshuman 'Golddragongt' Bhairavbhat , joining the design team also

Best regards

Christian



http://www.matroska.org


From moritz at bunkus.org  Thu Mar  6 13:36:24 2003
From: moritz at bunkus.org (Moritz Bunkus)
Date: Thu, 6 Mar 2003 13:36:24 +0100
Subject: [matroska-devel] Re: Matroska : 1. Work list update 2. New job proposal 3. New team members
In-Reply-To: <3E673049.4050800@matroska.org>
References: <3E673049.4050800@matroska.org>
Message-ID: <20030306123623.GV17028@bunkus.org>

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

From spyder482 at yahoo.com  Thu Mar  6 15:24:45 2003
From: spyder482 at yahoo.com (John Cannon)
Date: Thu, 6 Mar 2003 08:24:45 -0600
Subject: [matroska-devel] Re: Matroska : 1. Work list update 2. New job proposal 3. New team members
References: <3E673049.4050800@matroska.org> <20030306123623.GV17028@bunkus.org>
Message-ID: <b47lko$37n$1@main.gmane.org>

> > - John 'spyder' Cannon : MPEG1 video muxing into matroska ; finishing
> > SRT2USF.exe ( port to Linux )
>
> Hadn't he tested it already under Linux? If you need someone to test it
> feel free to ask me.

Yes, it works fine in Linux :)



http://www.matroska.org


From shailesh.mistry at milan.eclipse.co.uk  Fri Mar  7 00:30:10 2003
From: shailesh.mistry at milan.eclipse.co.uk (Shailesh L Mistry)
Date: Thu, 6 Mar 2003 23:30:10 -0000
Subject: [matroska-devel] Re: Matroska : 1. Work list update 2. New job proposal 3. New team members
References: <3E673049.4050800@matroska.org>
Message-ID: <009801c2e438$54ac1360$0200a8c0@desktop>


Hi All,

> Anybody volunteering to port Mosu's mkvmerger to Windows ? While
> matroskadub is a great tool to create ( mux ) and edit matroska files on
> Windows,
>
> Anybody on the job ? Henry ( until we hear from How Tam ) ? Thana ? Shelly
?

sure. Can someone please tell me where I can find the original mkvmerger
code?

Shelly.

http://www.matroska.org


From moritz at bunkus.org  Fri Mar  7 00:41:18 2003
From: moritz at bunkus.org (Moritz Bunkus)
Date: Fri, 7 Mar 2003 00:41:18 +0100
Subject: [matroska-devel] Re: Matroska : 1. Work list update 2. New job proposal 3. New team members
In-Reply-To: <009801c2e438$54ac1360$0200a8c0@desktop>
References: <3E673049.4050800@matroska.org> <009801c2e438$54ac1360$0200a8c0@desktop>
Message-ID: <20030306234117.GA17028@bunkus.org>

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

From shailesh.mistry at milan.eclipse.co.uk  Fri Mar  7 11:49:45 2003
From: shailesh.mistry at milan.eclipse.co.uk (Shailesh L Mistry)
Date: Fri, 7 Mar 2003 10:49:45 -0000
Subject: [matroska-devel] mkvtoolnix
References: <3E673049.4050800@matroska.org> <009801c2e438$54ac1360$0200a8c0@desktop> <20030306234117.GA17028@bunkus.org>
Message-ID: <003201c2e497$448bea50$0200a8c0@desktop>


Hi Mosu,


> http://www.bunkus.org/videotools/mkvtoolnix/
> 
> Obviously still under heavy development ;) I happily accept patches that
> make my tools compile/work under different operating systems.

I tried to pick up the files via cvs but I get the following message :-

Fatal error, aborting
cvs [login aborted]: anonymous: no such user

can someone else please have a go and confirm this.

Shelly.
http://www.matroska.org


From moritz at bunkus.org  Fri Mar  7 12:47:06 2003
From: moritz at bunkus.org (Moritz Bunkus)
Date: Fri, 7 Mar 2003 12:47:06 +0100
Subject: [matroska-devel] Re: mkvtoolnix
In-Reply-To: <003201c2e497$448bea50$0200a8c0@desktop>
References: <3E673049.4050800@matroska.org> <009801c2e438$54ac1360$0200a8c0@desktop> <20030306234117.GA17028@bunkus.org> <003201c2e497$448bea50$0200a8c0@desktop>
Message-ID: <20030307114705.GD17028@bunkus.org>

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

From shailesh.mistry at milan.eclipse.co.uk  Fri Mar  7 19:53:53 2003
From: shailesh.mistry at milan.eclipse.co.uk (Shailesh L Mistry)
Date: Fri, 7 Mar 2003 18:53:53 -0000
Subject: [matroska-devel] Re: mkvtoolnix
References: <3E673049.4050800@matroska.org> <009801c2e438$54ac1360$0200a8c0@desktop> <20030306234117.GA17028@bunkus.org> <003201c2e497$448bea50$0200a8c0@desktop> <20030307114705.GD17028@bunkus.org>
Message-ID: <00f501c2e4da$e6251ab0$0200a8c0@desktop>


Hi Mosu,


> Sorry... during a small cleanup I accidentally deleted the anonymous
> user. I've readded him, and now checking out works.

cvs is ok now.
for the NT the configure script won't work.
can you send me your config.h file and later we can save it in cvs as
config.h.nt


Shelly.

http://www.matroska.org


From chris at matroska.org  Thu Mar  6 13:21:25 2003
From: chris at matroska.org (Christian HJ Wiesner)
Date: Thu, 06 Mar 2003 13:21:25 +0100
Subject: [matroska-devel] Re: [usf-devel] Re: Re: a subtitle format
In-Reply-To: <018b01c2e3d4$1f846f20$0100a8c0@i2400p4>
References: <20030305164434.GR17028@bunkus.org> <3E67155B.1060605@matroska.org> <3E671E20.2060809@faireal.net> <3E6720B9.5080906@matroska.org> <018b01c2e3d4$1f846f20$0100a8c0@i2400p4>
Message-ID: <3E673D45.6000807@matroska.org>


TO : usf-devel at freelists.org
TO : matroska-devel at freelists.org

Hi Gabest,

Gabest wrote:

>>@Gabest : was it possible to include libpng into VobSub, such that the
>>Bitmaps could be compressed to PNG, without altering anything ? Of
>>course, matroska codec ID would then be set to
>>    
>>
>
>I did not follow this discussion but if this is about muxing bitmaps as
>subtitles then I don't understand why vobsub or any other future
>filter/renderer doing the painting needed to know about the storage format
>of the pictures.
>
Well, my idea was that maybe VobSub could do the PNG compression of the 
Bitmaps for the user, and output to a file with another extension, like  
.SPN  ( or whatever ).

The matroska muxer that would mux the subtitle stream into a matroska 
file would then recognize that this is NOT a bitmap substream, but that 
PNG compression was used, and would set the corresponding codec ID in 
the matroska track header. For playback, the matroska DirectShow demuxer 
( splitter ) could either

- call DVobSub for playback ( means libpng had to be implemented in 
DVobSub also )
- decode the PNG sub stream to Bitmap and handle to the player
- decode the PNG to Bitmap and call the overlay mixer ( tricky )
- handle the subs stream unaltered to the player, and this cares about 
the PNG decompression ( works only with special matroska adapted player 
like TCMP )

My preferred solution was Nr. 1, but i understand if you dont want to 
introduce a new subs format to VobSub, just for matroska.

> Multiplex every kind of subpictures like idx/sub or bmps as
>png and the demuxer will output it as an uncompressed subtitle image towards
>the renderer.
>

IMHO there should be a way to differentiate if a .SUB file contained PNG 
compressed images or uncompressed bitmaps. Either you do this with a 
flag in the .SUB file header ( i dont know the structure of your format 
i hate to admit ) or by choosing another extension ( see above ).
In any case, as you are the author of VobSub and an expert in this 
field, we will closely listen to your advice in this respect :-) !!

@spyder : John, could you consider updating your existing proggie 
SRT2USF to a more universal tool like SUB2matroska ? So it would accept 
.SRT, .SUB, .ASS and .SSA on the input, and would allow the user to 
define what the output sub stream was ( PNG or BMP, USF or TEXT/ASCII , 
TEXT/UTF8  ), but already muxed into a matroska file, with the correct 
codec ID set, so it is ready for muxing by mkvmerger ?

Regards

Christian

http://www.matroska.org


From moritz at bunkus.org  Thu Mar  6 13:44:19 2003
From: moritz at bunkus.org (Moritz Bunkus)
Date: Thu, 6 Mar 2003 13:44:19 +0100
Subject: [matroska-devel] Re: [usf-devel] Re: Re: a subtitle format
In-Reply-To: <3E673D45.6000807@matroska.org>
References: <20030305164434.GR17028@bunkus.org> <3E67155B.1060605@matroska.org> <3E671E20.2060809@faireal.net> <3E6720B9.5080906@matroska.org> <018b01c2e3d4$1f846f20$0100a8c0@i2400p4> <3E673D45.6000807@matroska.org>
Message-ID: <20030306124419.GW17028@bunkus.org>

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

From chris at matroska.org  Thu Mar  6 13:58:41 2003
From: chris at matroska.org (Christian HJ Wiesner)
Date: Thu, 06 Mar 2003 13:58:41 +0100
Subject: [matroska-devel] [usf-devel] Re: Re: a subtitle format
Message-ID: <3E674601.2030105@matroska.org>




Gabest wrote :

Christian: I think choosing png as the "communication" media type between
the source->muxer and demuxer->renderer is not a very good idea, if you want
to make more source (for different inputs not just idx/sub) or renderer (not
just dvobsub) they all needed to support png. It would be better to use
uncompressed memory bitmaps (24bpp truecolor or 1/2/4/8bpp palettized) and
let the muxer/demuxer do the png conversion internally.





http://www.matroska.org


From moritz at bunkus.org  Thu Mar  6 14:02:08 2003
From: moritz at bunkus.org (Moritz Bunkus)
Date: Thu, 6 Mar 2003 14:02:08 +0100
Subject: [matroska-devel] Re: [usf-devel] Re: Re: a subtitle format
In-Reply-To: <3E674601.2030105@matroska.org>
References: <3E674601.2030105@matroska.org>
Message-ID: <20030306130208.GY17028@bunkus.org>

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

From steve.lhomme at free.fr  Thu Mar  6 17:48:23 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Thu, 06 Mar 2003 17:48:23 +0100 (CET)
Subject: [matroska-devel] libmatoska progress
Message-ID: <1046969303.3e677bd761b0e@imp.free.fr>


I was checking the list of important TODOs pending on libmatroska on this page :
https://corecodec.org/tracker/?group_id=20&atid=129

I am planning to release a public version of the code soon. As soon as the
priority 7 and priority 6 items are done. And I think it should be OK for this
week-end.

The version of the code will be released as alpha1 in a zip file. There will
also be a TAG in CVS to mark/freeze that code release.

Any developper will be able to get it and start working with it to produce
matroska files. So maybe it will boost matroska support in various application,
faster than it is now. It will also mark the first step in letting the people
know that Matroska is not vapourware, and that you can really create/parse files
according to the specs.

The code is still alpha because there is still problems to be solved (maybe some
more memory licks and misc bugs we haven't spotted so far). I'll try to make a
list of what is supported when I'll publicly release it.

Until then, if you feel an important feature or a problem should be fixed before
this release, let me know. Or add a Tracker item :)

The beta cycle will start when all Matroska elements exist in the code and are
somehow supported. Then we'll (I ?) have to implement all possibilities with
these items. Once we can produce full featured Matroska files and all the major
\todo left in the code are done, we'll reach the Release Candidate stage for
version 1.0. I have absolutely no idea of how long it will take until we reach
the beta and RC stages. It should be counted in months...
http://www.matroska.org


From steve.lhomme at free.fr  Thu Mar  6 18:11:36 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Thu, 06 Mar 2003 18:11:36 +0100 (CET)
Subject: [matroska-devel] Original Track
Message-ID: <1046970696.3e6781481c39b@imp.free.fr>


Live From IRC :
 <Toff> ? QUESTION ? Does matroska has a flag to identify if a track is in it's
original version ?
 <Toff> example : I would like to play a movie in it's original version
 <SomeDood> original version ? you mean the original audio track ?
 <MosuAtWork> what do you call 'original version'?
 <Toff> yeah
 <SomeDood> (english for english movies etc)

Yes, there is a way. It's not an "original" flag but a "default" flag.
It's in the Track Entry :

FlagDefault	3	[88]	-	0-1	1	u-integer (1 bit)	Set if the track is the default for
its TrackType.
http://www.matroska.org


From chris at matroska.org  Fri Mar  7 12:10:32 2003
From: chris at matroska.org (Christian HJ Wiesner)
Date: Fri, 07 Mar 2003 12:10:32 +0100
Subject: [matroska-devel] XMMS and WinAmp cant handle matroska audio correctly ?
Message-ID: <3E687E28.1010002@matroska.org>



Hi,

it seems that both the big audio players, WinAmp for Windows and XMMS 
for Linux, cant handle matroska audio correctly :-( ....

In both cases it seems to be impossible to write an input plugin for 
matroska that was capable of calling other plugins, like decoder 
plugins, depending on the actual audio codec that was used in the 
matroska file.

A workaround, at least for WinAmp, could be to make a matroska handling 
plugin that would 'emulate' another winamp interface and call decoder 
plugins, connected to this interface for decoding.

Its becoming more and more obvious that matroska audio can only be 
handled fine on 'hardcoded' players, such as VLC, mplayer and Xine; or 
on powerful and compley media frameworks such as GStreamer and DirectShow.

Any additional input, like another possible workaround, was much 
appreciated.

Regards


Christian

http://www.matroska.org


From steve.lhomme at free.fr  Fri Mar  7 12:18:45 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Fri, 07 Mar 2003 12:18:45 +0100 (CET)
Subject: [matroska-devel] Re: XMMS and WinAmp cant handle matroska audio correctly ?
In-Reply-To: <3E687E28.1010002@matroska.org>
References: <3E687E28.1010002@matroska.org>
Message-ID: <1047035925.3e688015f06c4@imp.free.fr>


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

> Hi,
> 
> it seems that both the big audio players, WinAmp for Windows and XMMS 
> for Linux, cant handle matroska audio correctly :-( ....
> 
> In both cases it seems to be impossible to write an input plugin for 
> matroska that was capable of calling other plugins, like decoder 
> plugins, depending on the actual audio codec that was used in the 
> matroska file.
> 
> A workaround, at least for WinAmp, could be to make a matroska handling
> 
> plugin that would 'emulate' another winamp interface and call decoder 
> plugins, connected to this interface for decoding.
> 
> Its becoming more and more obvious that matroska audio can only be 
> handled fine on 'hardcoded' players, such as VLC, mplayer and Xine; or
> 
> on powerful and compley media frameworks such as GStreamer and
> DirectShow.
> 
> Any additional input, like another possible workaround, was much 
> appreciated.

We can handle every codec easily with UCI....
I know it's a bad joke.
http://www.matroska.org


From spyder482 at yahoo.com  Fri Mar  7 15:23:15 2003
From: spyder482 at yahoo.com (John Cannon)
Date: Fri, 7 Mar 2003 08:23:15 -0600
Subject: [matroska-devel] Re: XMMS and WinAmp cant handle matroska audio correctly ?
References: <3E687E28.1010002@matroska.org>
Message-ID: <b4a9tr$mg8$1@main.gmane.org>

Use ACM and hardcide support for more difficult codecs like Vorbis and MPC.
:)



http://www.matroska.org


From rbultje at ronald.bitfreak.net  Sun Mar  9 16:40:12 2003
From: rbultje at ronald.bitfreak.net (Ronald Bultje)
Date: 09 Mar 2003 16:40:12 +0100
Subject: [matroska-devel] Re: XMMS and WinAmp cant handle matroska audio
	correctly ?
In-Reply-To: <3E687E28.1010002@matroska.org>
References: <3E687E28.1010002@matroska.org>
Message-ID: <1047224411.3475.4.camel@localhost.localdomain>


Hey Chris,

On Fri, 2003-03-07 at 12:10, Christian HJ Wiesner wrote:
> A workaround, at least for WinAmp, could be to make a matroska handling 
> plugin that would 'emulate' another winamp interface and call decoder 
> plugins, connected to this interface for decoding.
> 
> Its becoming more and more obvious that matroska audio can only be 
> handled fine on 'hardcoded' players, such as VLC, mplayer and Xine; or 
> on powerful and compley media frameworks such as GStreamer and DirectShow.

I'd disagree with that. GStreamer and directshow (assuming matroska
won't only do vfw-style codec packing) would need hardcoded
from-interface-to-interface wrappers/convertors. GStreamer would just do
a switch (interface-id) {case matroska-vorbis: gst-interface="vorbis";
break;} etc.

XMMS/WinAmp should do the same thing.

Ronald

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

http://www.matroska.org


From chris at matroska.org  Fri Mar  7 14:32:32 2003
From: chris at matroska.org (Christian HJ Wiesner)
Date: Fri, 07 Mar 2003 14:32:32 +0100
Subject: [matroska-devel] MPC encoder DLL
Message-ID: <3E689F70.9010507@matroska.org>


To.: mpc-devel at freelists.org
To.: matroska-devel at freelists.org


Hi all,

again i am turning to the matroska Development list with a request for 
help, copied to the mpc-devel list.

As you are all aware we are trying to push the MPC ( musepack ) 
hi-quality lossy audio compression format for use in videos, together 
with Matroska. There is a wide field of applications for MPC in movies, 
like for musicals, video clips, short movies or simply those people who 
only accept the best sound quality in their movies, but dont want to use 
the original AC3 audio from the DVD ( for whatever reasons ).

Most DVDRippers encode their audio using either

HeadAC3he ( http://everwicked.com )

or

BeSweet ( with BeSweet GUI ) ( http://doom9.org )

both programs are complete audio conversion tool accepting many input 
formats such as AC3, WAV PCM, MP3, etc, and being capable to

- downsample ( 48 -> 44,1 )
- downmix ( 5.1 -> 2.0 )
- normalize ( 2 pass or 1 pass )
- encode

to the desired output compression format and bitrate.

Both authors, DA and DG, are prepared to include MPC as output 
compression format, but both want the MPC encoder as a Windows DLL, 
while mppencoder is only availalbe as an exe file ( stable, 1.1 : 
.http://www.personal.uni-jena.de/~pfk/MPP/bin/mppenc-windows-1.1.zip ; 
experimental : 
http://www.personal.uni-jena.de/~pfk/MPP/bin/mpp-windows-1.93a.zip ).

Was anybody interested maybe to take the current encoder exe ( SV7 ) and 
make a nice DLL from that, maybe by doing a wrapper ? Forgive me if i'm 
talking rubbish and this is not easy to do at all. After all, we could 
simply wait until MPC will go opensource and the encoder sources are 
available, but this may take some more weeks if i understand Frank 
correctly. Is it a lot of work to make a DLL wrapper for an .exe ?

Comments welcome

Thanks

Christian

BTW : Its maybe a good start to have a look at Frank's  
http://www.musepack.tk/ and Case' s site http://www.ca5e.tk/

http://www.matroska.org


From steve.lhomme at free.fr  Sat Mar  8 14:28:17 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Sat, 08 Mar 2003 14:28:17 +0100
Subject: [matroska-devel] First public release of libmatroska
Message-ID: <3E69EFF1.4050001@free.fr>


Hi,

As promised we have reach an important step in the developement of matroska.

Today is the day where we can release the current library to the public 
(developpers). It can be used to produce valid matroska files in 
various/flexible form. And it also allows a flexible way to retrieve 
information from the file for playback.

You can download the file on Sourceforge from now on at :
http://prdownloads.sourceforge.net/matroska/libmatroska.v0.2.0-alpha1.zip?download


-------------

Here are the release notes:

This is the first release that is usable to make valid matroska files.

You can currently read/write segments, segment info, tracks 
informations, cluster with frames and references.

You can also void some elements you don't want to keep, overwrite a void 
element (to be able to write elements like the cue entry at the 
beggining of the file).

And you can jump to any location in the find and find the next known 
element (Segment, Cluster, etc)


-------------

There are many improvement and additions pending. But with this code you 
can already read/write any movie with all important needed features. 
More matroska features will be introduced with time, as well as bug 
corrections.

PS: It's official now, matroska is no vapourware :D

http://www.matroska.org


From chris at matroska.org  Mon Mar 10 17:25:53 2003
From: chris at matroska.org (Christian HJ Wiesner)
Date: Mon, 10 Mar 2003 17:25:53 +0100
Subject: [matroska-devel] WMV2matroska ??
Message-ID: <3E6CBC91.9020202@matroska.org>


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

I have no idea how usable the sample code was and if a command line 
proggie was a good way of doing it, but we had for sure good interest 
from some of the more important devs on Doom9, like Nic and trbarry, for 
matroska if someone could write such an app ??

spyder, this is the right challenge for you ?

I even give you allowance to interrupt your work on MPEG2matroska if you 
wanted to look into that ... LOL :-D !!

Regards

Christian

http://www.matroska.org


From steve.lhomme at free.fr  Mon Mar 10 17:34:56 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Mon, 10 Mar 2003 17:34:56 +0100 (CET)
Subject: [matroska-devel] Re: WMV2matroska ??
In-Reply-To: <3E6CBC91.9020202@matroska.org>
References: <3E6CBC91.9020202@matroska.org>
Message-ID: <1047314096.3e6cbeb035b7f@imp.free.fr>


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

> I have no idea how usable the sample code was and if a command line 
> proggie was a good way of doing it, but we had for sure good interest 
> from some of the more important devs on Doom9, like Nic and trbarry, for
> matroska if someone could write such an app ??
> 
> spyder, this is the right challenge for you ?
> 
> I even give you allowance to interrupt your work on MPEG2matroska if you
> wanted to look into that ... LOL :-D !!

Especially if you're close to having some working code :(
/me cries
http://www.matroska.org


From shailesh.mistry at milan.eclipse.co.uk  Tue Mar 11 13:04:43 2003
From: shailesh.mistry at milan.eclipse.co.uk (Shailesh L Mistry)
Date: Tue, 11 Mar 2003 12:04:43 -0000
Subject: [matroska-devel] Re: mkvtoolnix
References: <3E673049.4050800@matroska.org> <009801c2e438$54ac1360$0200a8c0@desktop> <20030306234117.GA17028@bunkus.org> <003201c2e497$448bea50$0200a8c0@desktop> <20030307114705.GD17028@bunkus.org> <00f501c2e4da$e6251ab0$0200a8c0@desktop> <20030307204905.GE17028@bunkus.org>
Message-ID: <008101c2e7c6$67351c70$0200a8c0@desktop>


Hi All,

I have sent the first set of updates for avilib to Mosu, still have to
finish porting the other tools.

I have some questions though :-

1) I could not find PACKAGE and VERSION, I assume these are done during the
configure script. Is this correct? For the windows we could just set these
values manually in config.h.nt.

2) in avi_close_output_file, I have not figured out how to port ftruncate. I
suggest we change the existing code to call AVI_ftruncate which can be
defined as

int AVI_ftruncate (a, b)
{
#ifdef WIN32
//win32 code goes here
#else
return ftruncate(a,b);
#endif
}

3) I need a procedure for testing the ports. What files/methods are
currently used to test mkvtoolnix?


Shelly.

http://www.matroska.org


From moritz at bunkus.org  Tue Mar 11 13:22:34 2003
From: moritz at bunkus.org (Moritz Bunkus)
Date: Tue, 11 Mar 2003 13:22:34 +0100
Subject: [matroska-devel] Re: mkvtoolnix
In-Reply-To: <008101c2e7c6$67351c70$0200a8c0@desktop>
References: <3E673049.4050800@matroska.org> <009801c2e438$54ac1360$0200a8c0@desktop> <20030306234117.GA17028@bunkus.org> <003201c2e497$448bea50$0200a8c0@desktop> <20030307114705.GD17028@bunkus.org> <00f501c2e4da$e6251ab0$0200a8c0@desktop> <20030307204905.GE17028@bunkus.org> <008101c2e7c6$67351c70$0200a8c0@desktop>
Message-ID: <20030311122234.GF2679@bunkus.org>

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

From chris at matroska.org  Tue Mar 11 13:36:33 2003
From: chris at matroska.org (Christian HJ Wiesner)
Date: Tue, 11 Mar 2003 13:36:33 +0100
Subject: [matroska-devel] Re: mkvtoolnix
In-Reply-To: <20030311122234.GF2679@bunkus.org>
References: <3E673049.4050800@matroska.org> <009801c2e438$54ac1360$0200a8c0@desktop> <20030306234117.GA17028@bunkus.org> <003201c2e497$448bea50$0200a8c0@desktop> <20030307114705.GD17028@bunkus.org> <00f501c2e4da$e6251ab0$0200a8c0@desktop> <2003030720490 <20030311122234.GF2679@bunkus.org>
Message-ID: <3E6DD851.8050206@matroska.org>




Moritz Bunkus wrote:

>>Shelly wrote : 3) I need a procedure for testing the ports. What files/methods are
>>currently used to test mkvtoolnix?
>>    
>>
>
>Have a look at http://www.bunkus.org/videotools/mkvtoolnix/samples/ I've
>put up some sample files - both their sources and the resulting
>files. They are updated whenever there's a major change in mkvmerge
>(e.g. when I really implement cues).
>

Hey guys, thats really great that Shelly is actively working on the port 
of mkvmerger to win32 already !!! Thanks for all the support Mosu, 
you're a star and meanwhile an irreplacable backbone of the whole 
project  :-) !! Shelly, did animesh give you any updates on the porting 
of the C library recently ? His last message to me was like he could 
read EBML already soon ?

Thanks for all the hard work guys, its big fun to know you all and to 
develop matroska with you, i know in the end matroska will become a big 
success !!

Regards

Christian

http://www.matroska.org


From shailesh.mistry at milan.eclipse.co.uk  Tue Mar 11 13:58:56 2003
From: shailesh.mistry at milan.eclipse.co.uk (Shailesh L Mistry)
Date: Tue, 11 Mar 2003 12:58:56 -0000
Subject: [matroska-devel] Re: mkvtoolnix
References: <3E673049.4050800@matroska.org> <009801c2e438$54ac1360$0200a8c0@desktop> <20030306234117.GA17028@bunkus.org> <003201c2e497$448bea50$0200a8c0@desktop> <20030307114705.GD17028@bunkus.org> <00f501c2e4da$e6251ab0$0200a8c0@desktop> <2003030720490 <20030311122234.GF2679@bunkus.org> <3E6DD851.8050206@matroska.org>
Message-ID: <00a101c2e7cd$fa2fbe20$0200a8c0@desktop>


Hi Christian,

> Shelly, did animesh give you any updates on the porting
> of the C library recently ? His last message to me was like he could
> read EBML already soon ?

not yet, he had started looking into the porting first so we agreed that he
would continue it while I looked into any possible changes that were needed
for the api.

Shelly.

http://www.matroska.org


From shailesh.mistry at milan.eclipse.co.uk  Thu Mar 13 14:35:26 2003
From: shailesh.mistry at milan.eclipse.co.uk (Shailesh L Mistry)
Date: Thu, 13 Mar 2003 13:35:26 -0000
Subject: [matroska-devel] Re: mkvtoolnix
References: <3E673049.4050800@matroska.org> <009801c2e438$54ac1360$0200a8c0@desktop> <20030306234117.GA17028@bunkus.org> <003201c2e497$448bea50$0200a8c0@desktop> <20030307114705.GD17028@bunkus.org> <00f501c2e4da$e6251ab0$0200a8c0@desktop> <20030307204905.GE17028@bunkus.org> <008101c2e7c6$67351c70$0200a8c0@desktop> <20030311122234.GF2679@bunkus.org>
Message-ID: <010501c2e965$67f5b5c0$0200a8c0@desktop>


Hi Mosu,

In r_ogm.h there is a direct reference to ogg.h.

#include <ogg/ogg.h>

I do not have ogg anywhere on my machine.
Will the existing configure script check for this or does we assume the file
does exist?

Where can I get the necessary files?

Shelly.

http://www.matroska.org


From moritz at bunkus.org  Thu Mar 13 14:38:41 2003
From: moritz at bunkus.org (Moritz Bunkus)
Date: Thu, 13 Mar 2003 14:38:41 +0100
Subject: [matroska-devel] Re: mkvtoolnix
In-Reply-To: <010501c2e965$67f5b5c0$0200a8c0@desktop>
References: <3E673049.4050800@matroska.org> <009801c2e438$54ac1360$0200a8c0@desktop> <20030306234117.GA17028@bunkus.org> <003201c2e497$448bea50$0200a8c0@desktop> <20030307114705.GD17028@bunkus.org> <00f501c2e4da$e6251ab0$0200a8c0@desktop> <20030307204905.GE17028@bunkus.org> <008101c2e7c6$67351c70$0200a8c0@desktop> <20030311122234.GF2679@bunkus.org> <010501c2e965$67f5b5c0$0200a8c0@desktop>
Message-ID: <20030313133841.GC17841@bunkus.org>

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

From shailesh.mistry at milan.eclipse.co.uk  Thu Mar 13 18:26:25 2003
From: shailesh.mistry at milan.eclipse.co.uk (Shailesh L Mistry)
Date: Thu, 13 Mar 2003 17:26:25 -0000
Subject: [matroska-devel] Re: mkvtoolnix
References: <3E673049.4050800@matroska.org> <009801c2e438$54ac1360$0200a8c0@desktop> <20030306234117.GA17028@bunkus.org> <003201c2e497$448bea50$0200a8c0@desktop> <20030307114705.GD17028@bunkus.org> <00f501c2e4da$e6251ab0$0200a8c0@desktop> <20030307204905.GE17028@bunkus.org> <008101c2e7c6$67351c70$0200a8c0@desktop> <20030311122234.GF2679@bunkus.org> <010501c2e965$67f5b5c0$0200a8c0@desktop> <20030313133841.GC17841@bunkus.org>
Message-ID: <012e01c2e985$acda3920$0200a8c0@desktop>


Hi Mosu,

Can you tell me where r_matroska.h lives?
I can not find it anywhere in the mkvtoolnix source code but it is
referenced in mkvmerge.cpp.

Shelly.

http://www.matroska.org


From moritz at bunkus.org  Thu Mar 13 18:32:10 2003
From: moritz at bunkus.org (Moritz Bunkus)
Date: Thu, 13 Mar 2003 18:32:10 +0100
Subject: [matroska-devel] Re: mkvtoolnix
In-Reply-To: <012e01c2e985$acda3920$0200a8c0@desktop>
References: <20030306234117.GA17028@bunkus.org> <003201c2e497$448bea50$0200a8c0@desktop> <20030307114705.GD17028@bunkus.org> <00f501c2e4da$e6251ab0$0200a8c0@desktop> <20030307204905.GE17028@bunkus.org> <008101c2e7c6$67351c70$0200a8c0@desktop> <20030311122234.GF2679@bunkus.org> <010501c2e965$67f5b5c0$0200a8c0@desktop> <20030313133841.GC17841@bunkus.org> <012e01c2e985$acda3920$0200a8c0@desktop>
Message-ID: <20030313173210.GD17841@bunkus.org>

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

From shailesh.mistry at milan.eclipse.co.uk  Fri Mar 21 15:59:24 2003
From: shailesh.mistry at milan.eclipse.co.uk (Shailesh L Mistry)
Date: Fri, 21 Mar 2003 14:59:24 -0000
Subject: [matroska-devel] Re: mkvtoolnix
References: <3E673049.4050800@matroska.org> <009801c2e438$54ac1360$0200a8c0@desktop> <20030306234117.GA17028@bunkus.org> <003201c2e497$448bea50$0200a8c0@desktop> <20030307114705.GD17028@bunkus.org> <00f501c2e4da$e6251ab0$0200a8c0@desktop> <20030307204905.GE17028@bunkus.org> <008101c2e7c6$67351c70$0200a8c0@desktop> <20030311122234.GF2679@bunkus.org> <010501c2e965$67f5b5c0$0200a8c0@desktop> <20030313133841.GC17841@bunkus.org>
Message-ID: <001f01c2efba$76beb380$0200a8c0@desktop>


Hi Mosu,

I have hit a snag with the mkvmerge build.
I get the following errors  :-

queue.cpp(118) : error C2520: conversion from unsigned __int64 to double not
implemented, use signed __int64
p_mp3.cpp(210) : error C2520: conversion from unsigned __int64 to double not
implemented, use signed __int64
p_ac3.cpp(213) : error C2520: conversion from unsigned __int64 to double not
implemented, use signed __int64
p_pcm.cpp(153) : error C2520: conversion from unsigned __int64 to double not
implemented, use signed __int64
p_pcm.cpp(159) : error C2520: conversion from unsigned __int64 to double not
implemented, use signed __int64

Is it possible to use signed __int64 instead of unsigned __int64 in these 5
places?

Shelly.

http://www.matroska.org


From steve.lhomme at free.fr  Fri Mar 21 16:30:20 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Fri, 21 Mar 2003 16:30:20 +0100 (CET)
Subject: [matroska-devel] Re: mkvtoolnix
In-Reply-To: <001f01c2efba$76beb380$0200a8c0@desktop>
References: <3E673049.4050800@matroska.org> <009801c2e438$54ac1360$0200a8c0@desktop> <20030306234117.GA17028@bunkus.org> <003201c2e497$448bea50$0200a8c0@desktop> <20030307114705.GD17028@bunkus.org> <00f501c2e4da$e6251ab0$0200a8c0@desktop> <20030307204905.GE17028@bunkus.org> <008101c2e7c6$67351c70$0200a8c0@desktop> <20030311122234.GF2679@bunkus.org> <010501c2e965$67f5b5c0$0200a8c0@desktop> <20030313133841.GC17841@bunkus.org> <001f01c2efba$76beb380$0200a8c0@desktop>
Message-ID: <1048260620.3e7b300c37ec9@imp.free.fr>


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

> 
> Hi Mosu,
> 
> I have hit a snag with the mkvmerge build.
> I get the following errors  :-
> 
> queue.cpp(118) : error C2520: conversion from unsigned __int64 to double
> not
> implemented, use signed __int64
> p_mp3.cpp(210) : error C2520: conversion from unsigned __int64 to double
> not
> implemented, use signed __int64
> p_ac3.cpp(213) : error C2520: conversion from unsigned __int64 to double
> not
> implemented, use signed __int64
> p_pcm.cpp(153) : error C2520: conversion from unsigned __int64 to double
> not
> implemented, use signed __int64
> p_pcm.cpp(159) : error C2520: conversion from unsigned __int64 to double
> not
> implemented, use signed __int64
> 
> Is it possible to use signed __int64 instead of unsigned __int64 in
> these 5 places?

I don't have the code here but the problem seem to be the conversion from
integer (64 bits) to float (double). So your solution couldn't work. As long as
the 64 bits coded value can hold in a 32 bits coded one, you can try this
conversion first (64 -> 32 -> float).
http://www.matroska.org


From pfk at fuchs.offl.uni-jena.de  Fri Mar 21 19:34:55 2003
From: pfk at fuchs.offl.uni-jena.de (Frank Klemm)
Date: Fri, 21 Mar 2003 19:34:55 +0100
Subject: [matroska-devel] Re: =[SPAM?]= Re: mkvtoolnix
In-Reply-To: <1048260620.3e7b300c37ec9@imp.free.fr>; from steve.lhomme@free.fr on Fri, Mar 21, 2003 at 04:30:20PM +0100
References: <003201c2e497$448bea50$0200a8c0@desktop> <20030307114705.GD17028@bunkus.org> <00f501c2e4da$e6251ab0$0200a8c0@desktop> <20030307204905.GE17028@bunkus.org> <008101c2e7c6$67351c70$0200a8c0@desktop> <20030311122234.GF2679@bunkus.org> <010501c2e965$67f5b5c0$0200a8c0@desktop> <20030313133841.GC17841@bunkus.org> <001f01c2efba$76beb380$0200a8c0@desktop> <1048260620.3e7b300c37ec9@imp.free.fr>
Message-ID: <20030321193455.A9946@fuchs.offl.uni-jena.de>


On Fri, Mar 21, 2003 at 04:30:20PM +0100, Steve Lhomme wrote:
> 
> > I have hit a snag with the mkvmerge build.
> > I get the following errors  :-
> > 
> > queue.cpp(118) : error C2520: conversion from unsigned __int64 to double
> > not
> > implemented, use signed __int64
> > p_mp3.cpp(210) : error C2520: conversion from unsigned __int64 to double
> > not
> > implemented, use signed __int64
> > p_ac3.cpp(213) : error C2520: conversion from unsigned __int64 to double
> > not
> > implemented, use signed __int64
> > p_pcm.cpp(153) : error C2520: conversion from unsigned __int64 to double
> > not
> > implemented, use signed __int64
> > p_pcm.cpp(159) : error C2520: conversion from unsigned __int64 to double
> > not
> > implemented, use signed __int64
> > 
> > Is it possible to use signed __int64 instead of unsigned __int64 in
> > these 5 places?
> 
> I don't have the code here but the problem seem to be the conversion from
> integer (64 bits) to float (double). So your solution couldn't work. As long as
> the 64 bits coded value can hold in a 32 bits coded one, you can try this
> conversion first (64 -> 32 -> float).
> 
It's a nearly 10 year old bug in the MSC and MSC++ compiler.

There is still no code to convert an unsigned 64 bit integer to any floating
point type. The IA32 architecture supports to convert signed 16, 32 and 64
bit integers to be converted to one of the floating point types.
These are the commands:

   ; signed __int16
   fild word ptr [src]		; load integer to the TOS of the CPU
   fstp  ...			; do anything with this value

   ; signed __int32
   fild dword ptr [src]		; load integer to the TOS of the CPU
   fstp  ...			; do anything with this value

   ; signed __int64
   fild qword ptr [src]		; load integer to the TOS of the CPU
   fstp  ...			; do anything with this value


For 8 bit integers these values must be converted to any of these types.
Mostly 32 bit is used, because some architecture (Pentium Pro) don't like 16
bit code:

   ; signed __int8
   movsx eax, byte ptr [src]
   mov  dword ptr [tmp], eax	; signed __int8 => signed __int32
   fild dword ptr [tmp]		; load integer to the TOS of the CPU
   fstp  ...			; do anything with this value

   ; unsigned __int8
   movzx eax, byte ptr [src]
   mov  dword ptr [tmp], eax	; unsigned __int8 => signed __int32
   fild dword ptr [tmp]		; load integer to the TOS of the CPU
   fstp  ...			; do anything with this value


For unsigned types the base type must be converted to any of the 3 supported
signed types.

   ; unsigned __int16
   movzx eax, word ptr [src]
   mov  dword ptr [tmp], eax	; unsigned __int16 => signed __int32
   fild dword ptr [tmp]		; load integer to the TOS of the CPU
   fstp  ...			; do anything with this value

   ; unsigned __int32
   mov  eax, dword ptr [src]
   cdq
   mov  dword ptr [tmp+0], eax	
   mov  dword ptr [tmp+4], edx	; unsigned __int32 => signed __int64
   fild qword ptr [tmp]		; load integer to the TOS of the CPU
   fstp  ...			; do anything with this value

And for 64 bit unsigned ints this method do not work. And that's the
reason why MS didn't implement this 10 years ago. And they forget
to fix this until today.


The fastest code to do this is:

   ; unsigned __int64
   test byte ptr [src+7], 80h
   fild qword ptr [tmp]		; load integer to the TOS of the CPU
   jz lbl			; for number 0...2^63-1 this is okay
   fadd dword ptr __const_pow2_64	; correct the wrong result for number >= 2^63
lbl:

May be this is patented?

-- 
Frank Klemm


Solution:

- Write a function for MSC which converts a 64 bit int to a float:

_int64_to_float  proc near
	fild  qword ptr [esp + 4]
        test  byte ptr [esp + 11], 80h
	jz    _ret
        fadd  dword ptr __pow_2_64
_ret:	ret

__pow_2_64:	db 0, 0, 0x80, 0x5F

	endproc

- prototype this function:

   long double  _int64_to_float ( unsigned __int64 x );

- Use a macro to convert 64 unsigned int to a float:

#define UINT64_TO_FLOAT(x)	((float)(x))
#define UINT64_TO_DOUBLE(x)	((double)(x))
#define UINT64_TO_LDOUBLE(x)	((long double)(x))

or:

#define UINT64_TO_FLOAT(x)	((float)_int64_to_float(x))
#define UINT64_TO_DOUBLE(x)	((double)_int64_to_float(x))
#define UINT64_TO_LDOUBLE(x)	((long double)_int64_to_float(x))

- add the assembler module to your project.


http://www.matroska.org


From moritz at bunkus.org  Sun Mar 23 21:32:18 2003
From: moritz at bunkus.org (Moritz Bunkus)
Date: Sun, 23 Mar 2003 21:32:18 +0100
Subject: [matroska-devel] Re: =[SPAM?]= Re: mkvtoolnix
In-Reply-To: <20030321193455.A9946@fuchs.offl.uni-jena.de>
References: <20030307114705.GD17028@bunkus.org> <00f501c2e4da$e6251ab0$0200a8c0@desktop> <20030307204905.GE17028@bunkus.org> <008101c2e7c6$67351c70$0200a8c0@desktop> <20030311122234.GF2679@bunkus.org> <010501c2e965$67f5b5c0$0200a8c0@desktop> <20030313133841.GC17841@bunkus.org> <001f01c2efba$76beb380$0200a8c0@desktop> <1048260620.3e7b300c37ec9@imp.free.fr> <20030321193455.A9946@fuchs.offl.uni-jena.de>
Message-ID: <20030323203217.GB20608@bunkus.org>

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

From shailesh.mistry at milan.eclipse.co.uk  Sun Mar 23 23:11:48 2003
From: shailesh.mistry at milan.eclipse.co.uk (Shailesh L Mistry)
Date: Sun, 23 Mar 2003 22:11:48 -0000
Subject: [matroska-devel] Re: mkvtoolnix
References: <3E673049.4050800@matroska.org> <009801c2e438$54ac1360$0200a8c0@desktop> <20030306234117.GA17028@bunkus.org> <003201c2e497$448bea50$0200a8c0@desktop> <20030307114705.GD17028@bunkus.org> <00f501c2e4da$e6251ab0$0200a8c0@desktop> <20030307204905.GE17028@bunkus.org> <008101c2e7c6$67351c70$0200a8c0@desktop> <20030311122234.GF2679@bunkus.org> <010501c2e965$67f5b5c0$0200a8c0@desktop> <20030313133841.GC17841@bunkus.org> <001f01c2efba$76beb380$0200a8c0@desktop> <1048260620.3e7b300c37ec9@imp.free.fr>
Message-ID: <003f01c2f189$333610b0$0200a8c0@desktop>


Hi All,

Apologies for not replying earlier but things are slow here.


> I don't have the code here but the problem seem to be the conversion from
> integer (64 bits) to float (double). So your solution couldn't work. As
long as
> the 64 bits coded value can hold in a 32 bits coded one, you can try this
> conversion first (64 -> 32 -> float).

I suggested changing the uint64 to int64 because it will compile.
Given the last response from Mosu we may as well go with changing these to
int64.

Shelly.

http://www.matroska.org


From pfk at fuchs.offl.uni-jena.de  Mon Mar 24 02:08:11 2003
From: pfk at fuchs.offl.uni-jena.de (Frank Klemm)
Date: Mon, 24 Mar 2003 02:08:11 +0100
Subject: [matroska-devel] Re: =[SPAM?]= Re: mkvtoolnix
In-Reply-To: <003f01c2f189$333610b0$0200a8c0@desktop>; from shailesh.mistry@milan.eclipse.co.uk on Sun, Mar 23, 2003 at 10:11:48PM -0000
References: <20030307114705.GD17028@bunkus.org> <00f501c2e4da$e6251ab0$0200a8c0@desktop> <20030307204905.GE17028@bunkus.org> <008101c2e7c6$67351c70$0200a8c0@desktop> <20030311122234.GF2679@bunkus.org> <010501c2e965$67f5b5c0$0200a8c0@desktop> <20030313133841.GC17841@bunkus.org> <001f01c2efba$76beb380$0200a8c0@desktop> <1048260620.3e7b300c37ec9@imp.free.fr> <003f01c2f189$333610b0$0200a8c0@desktop>
Message-ID: <20030324020811.D24194@fuchs.offl.uni-jena.de>


On Sun, Mar 23, 2003 at 10:11:48PM -0000, Shailesh L Mistry wrote:
> 
> Hi All,
> 
> Apologies for not replying earlier but things are slow here.
> 
> 
> > I don't have the code here but the problem seem to be the conversion from
> > integer (64 bits) to float (double). So your solution couldn't work. As
> long as
> > the 64 bits coded value can hold in a 32 bits coded one, you can try this
> > conversion first (64 -> 32 -> float).
> 
> I suggested changing the uint64 to int64 because it will compile.
> Given the last response from Mosu we may as well go with changing these to
> int64.
> 
And other compiler may not support int64 to float.

I don't think this is a real solution.

There are enough programs which do not support valid WAV/RIFF files with
sizes between 2 and 4 GByte.

-- 
Frank Klemm

http://www.matroska.org


From christophe.paris at free.fr  Tue Mar 11 19:13:56 2003
From: christophe.paris at free.fr (Christophe PARIS)
Date: Tue, 11 Mar 2003 19:13:56 +0100
Subject: [matroska-devel] Re: mkvtoolnix
In-Reply-To: <008101c2e7c6$67351c70$0200a8c0@desktop>
References: <3E673049.4050800@matroska.org> <009801c2e438$54ac1360$0200a8c0@desktop> <20030306234117.GA17028@bunkus.org> <003201c2e497$448bea50$0200a8c0@desktop> <20030307114705.GD17028@bunkus.org> <00f501c2e4da$e6251ab0$0200a8c0@desktop> <20030307204905.GE17028@bunkus.org> <008101c2e7c6$67351c70$0200a8c0@desktop>
Message-ID: <b4l8rm$gp9$1@main.gmane.org>


Shailesh L Mistry wrote:
> int AVI_ftruncate (a, b)
> {
> #ifdef WIN32
> //win32 code goes here
> #else
> return ftruncate(a,b);
> #endif
> }

On windows you can use the _chsize function.
Here's the description for _chsize from its msdn page :
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccore98/html/_crt__chsize.asp

_chsize

Changes the file size.

int _chsize( int handle, long size );

Routine    Required Header   Optional Headers    Compatibility
_chsize    <io.h>            <errno.h>           Win 95, Win NT

For additional compatibility information, see Compatibility in the 
Introduction.

Libraries
LIBC.LIB 	Single thread static library, retail version
LIBCMT.LIB 	Multithread static library, retail version
MSVCRT.LIB 	Import library for MSVCRT.DLL, retail version

Return Value :

_chsize returns the value 0 if the file size is successfully changed. A 
return value of ?1 indicates an error: errno is set to EACCES if the 
specified file is locked against access, to EBADF if the specified file 
is read-only or the handle is invalid, or to ENOSPC if no space is left 
on the device.

Parameters :

- handle Handle referring to open file
- size New length of file in bytes

Remarks :

The _chsize function extends or truncates the file associated with 
handle to the length specified by size. The file must be open in a mode 
that permits writing. Null characters ('\0') are appended if the file is 
extended. If the file is truncated, all data from the end of the 
shortened file to the original length of the file is lost.


http://www.matroska.org


From pfk at fuchs.offl.uni-jena.de  Wed Mar 12 02:00:40 2003
From: pfk at fuchs.offl.uni-jena.de (Frank Klemm)
Date: Wed, 12 Mar 2003 02:00:40 +0100
Subject: [matroska-devel] Re: =[SPAM?]= Re: mkvtoolnix
In-Reply-To: <b4l8rm$gp9$1@main.gmane.org>; from christophe.paris@free.fr on Tue, Mar 11, 2003 at 07:13:56PM +0100
References: <3E673049.4050800@matroska.org> <009801c2e438$54ac1360$0200a8c0@desktop> <20030306234117.GA17028@bunkus.org> <003201c2e497$448bea50$0200a8c0@desktop> <20030307114705.GD17028@bunkus.org> <00f501c2e4da$e6251ab0$0200a8c0@desktop> <20030307204905.GE17028@bunkus.org> <008101c2e7c6$67351c70$0200a8c0@desktop> <b4l8rm$gp9$1@main.gmane.org>
Message-ID: <20030312020040.E929@fuchs.offl.uni-jena.de>


On Tue, Mar 11, 2003 at 07:13:56PM +0100, Christophe PARIS wrote:
> 
> Shailesh L Mistry wrote:
> > int AVI_ftruncate (a, b)
> > {
> > #ifdef WIN32
> > //win32 code goes here
> > #else
> > return ftruncate(a,b);
> > #endif
> > }
> 
BTW avoid such stuff. #ifdef's make a source unreadable.
Write a lib to hide such stuff.

-- 
Frank Klemm

http://www.matroska.org


From steve.lhomme at free.fr  Wed Mar 12 10:26:50 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Wed, 12 Mar 2003 10:26:50 +0100 (CET)
Subject: [matroska-devel] Re: =[SPAM?]= Re: mkvtoolnix
In-Reply-To: <20030312020040.E929@fuchs.offl.uni-jena.de>
References: <3E673049.4050800@matroska.org> <009801c2e438$54ac1360$0200a8c0@desktop> <20030306234117.GA17028@bunkus.org> <003201c2e497$448bea50$0200a8c0@desktop> <20030307114705.GD17028@bunkus.org> <00f501c2e4da$e6251ab0$0200a8c0@desktop> <20030307204905.GE17028@bunkus.org> <008101c2e7c6$67351c70$0200a8c0@desktop> <b4l8rm$gp9$1@main.gmane.org> <20030312020040.E929@fuchs.offl.uni-jena.de>
Message-ID: <1047461210.3e6efd5ac9d4e@imp.free.fr>


En r?ponse ? Frank Klemm <pfk at fuchs.offl.uni-jena.de>:

> 
> On Tue, Mar 11, 2003 at 07:13:56PM +0100, Christophe PARIS wrote:
> > 
> > Shailesh L Mistry wrote:
> > > int AVI_ftruncate (a, b)
> > > {
> > > #ifdef WIN32
> > > //win32 code goes here
> > > #else
> > > return ftruncate(a,b);
> > > #endif
> > > }
> > 
> BTW avoid such stuff. #ifdef's make a source unreadable.
> Write a lib to hide such stuff.

Good idea.

Or as long as the API is very similar, you can have a platform.h
Each with a define :
#define file_truncate(f,s) _chsize(f,s)
or
#define file_truncate(f,s) ftruncate(f,s)

The code is then readable (but not great to debug).
http://www.matroska.org


From moritz at bunkus.org  Wed Mar 12 11:50:32 2003
From: moritz at bunkus.org (Moritz Bunkus)
Date: Wed, 12 Mar 2003 11:50:32 +0100
Subject: [matroska-devel] Re: mkvtoolnix
In-Reply-To: <20030312020040.E929@fuchs.offl.uni-jena.de>
References: <3E673049.4050800@matroska.org> <009801c2e438$54ac1360$0200a8c0@desktop> <20030306234117.GA17028@bunkus.org> <003201c2e497$448bea50$0200a8c0@desktop> <20030307114705.GD17028@bunkus.org> <00f501c2e4da$e6251ab0$0200a8c0@desktop> <20030307204905.GE17028@bunkus.org> <008101c2e7c6$67351c70$0200a8c0@desktop> <b4l8rm$gp9$1@main.gmane.org> <20030312020040.E929@fuchs.offl.uni-jena.de>
Message-ID: <20030312105032.GK2679@bunkus.org>

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

From shailesh.mistry at milan.eclipse.co.uk  Wed Mar 12 12:17:36 2003
From: shailesh.mistry at milan.eclipse.co.uk (Shailesh L Mistry)
Date: Wed, 12 Mar 2003 11:17:36 -0000
Subject: [matroska-devel] Re: =[SPAM?]= Re: mkvtoolnix
References: <3E673049.4050800@matroska.org> <009801c2e438$54ac1360$0200a8c0@desktop> <20030306234117.GA17028@bunkus.org> <003201c2e497$448bea50$0200a8c0@desktop> <20030307114705.GD17028@bunkus.org> <00f501c2e4da$e6251ab0$0200a8c0@desktop> <20030307204905.GE17028@bunkus.org> <008101c2e7c6$67351c70$0200a8c0@desktop> <b4l8rm$gp9$1@main.gmane.org> <20030312020040.E929@fuchs.offl.uni-jena.de>
Message-ID: <000401c2e888$fc7afcb0$0200a8c0@desktop>






>> Shailesh L Mistry wrote:
>>> int AVI_ftruncate (a, b)
>>> {
>>> #ifdef WIN32
>>> //win32 code goes here
>>> #else
>>> return ftruncate(a,b);
>>> #endif
>>> }


> Frank Klemm wrote:
>>BTW avoid such stuff. #ifdef's make a source unreadable.
>>Write a lib to hide such stuff.

I only used the #ifdef because it looked like I would need more than two
lines of code, but the snippet from Christope shows a one liner we can use
so I will go back to my usual method of using #defines.

Shelly.

http://www.matroska.org


From chris at matroska.org  Tue Mar 11 17:21:45 2003
From: chris at matroska.org (Christian HJ Wiesner)
Date: Tue, 11 Mar 2003 17:21:45 +0100
Subject: [matroska-devel] Implement support for mplayer's MPCF container format into matroska
 parser ?
Message-ID: <3E6E0D19.7020902@matroska.org>



Gentlemen,

this has been discussed on the IRC channel a couple of minutes ago, and 
i put it for discussion :

As you may have heard our specification was put under severe critizism 
from some core developers of the mplayer player for Linux environments. 
They were calling our project 'crap' and 'bloated' and us, the 
developers and people behind it, are 'stupid DirectShow kiddies' . When 
i was pointed to these threads on their mailing list ( 
http://mplayerhq.hu/pipermail/mplayer-dev-eng/ ) i completely 
overreacted and sent some pretty harsh and unnecessary comments back to 
their list. I apologized for that later, and it also turned out as if 
they changed their minds a little bit about our project, while still 
considering it much to bloated and poweful for a container format.

Recently it became silent about their own container, named 'MPCF' ( 
MPlayer Container Format ), but now discussion was raised again and they 
are starting implementation. In fact, their basic structure seems so 
much similar to ours in some points, but simply stripped from all the 
more powerful stuff like chapters, menues, etc , i still have to ask 
myself where the big need is to make it at all, but this is a free world 
and of course they are completely free to do whatever they want to do. 
We dont like Xiph people questioning matroska, and so we should question 
their goals.

Now, as a result of this it may happen that a certain 'polarisation' may 
occur between Linux and Windows users, and this is pretty bad for the 
whole opensource movement IMHO. They needed a DirectShow parser to make 
sure their container could be played on Windows, and probably would even 
find someone doing it for them in the end, but they themselves dont see 
this being a necessity. Again, this is very dangerous for the opensource 
world IMHO. Until recently everbody was using good old AVI, QT or MP4. 
Now we could see a fork between the two worlds, leading to 
incompatibility and frustration for the users.

So i was asking myself if we should maybe consider to give them the 
'hand of peace' , trying to smooth out the raging waves , for example by 
offering them to support their format in our DirectShow parser ?

You may think this is a completely stupid thing to do, but here are my 
reasons :

1. Our first and only motivation, in any case, should be the users of 
any of the new containers. They dont know about the 'rumbling' behind 
the scenes, and they dont deserve to be the victims of that anyway. By 
supporting MPCF in our parser we could make their life much easier, by 
ensuring the container can be played fine on Windows.

2. By offering help to the mplayer people for the DirectShow playback we 
would gain sympathy from some of the MPFC developers ( not all of them 
for sure ), but especially from the mplayer/mencoder users. This would 
also help a lot to break down 'mental barriers' and to avoid a 'drifting 
apart' from Windows and Linux world

3. As a sideeffect we could hopefully convince them to reuse at least a 
few of the things we introduce together with matroska, such as our codec 
ID list, ( 16 bytes wont hurt them i hope ), the UCI ( or whatever it 
will be called ) codec interface, our chapters/control tracks ( their 
users surely will request this ) and maybe even our menuing and tagging 
system.

@ myFUN, do you think this was feasible, to have our parser handle 2 
different formats ? Please note we will NOT want to make this a separate 
filter, as we certainly dont want to pay for the hosting of the parser 
of another container, and also nobody can ask us to create their parser 
filter without some advantage for us. I sincerely hope it should be 
possible to implement MPCF playback ( given the really simple structure 
they have ) into our parser filter with only a very small file size 
increase. Of course, they could always take our sources, strip all the 
matroska content of and compile their own filter ... thats the nature of 
opensource, and fine with me.

What is your opinion on this ?

Regards

Christian

http://www.matroska.org


From chris at matroska.org  Wed Mar 12 16:16:17 2003
From: chris at matroska.org (Christian HJ Wiesner)
Date: Wed, 12 Mar 2003 16:16:17 +0100
Subject: [matroska-devel] Brainstorming : menue structure - have a close look at the work done
 for XCD already ?
Message-ID: <3E6F4F41.6000209@matroska.org>


Brainstorming ( not high priority ) :

Hi guys,

i am copying avih and DexT from the XCD team on this email.

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

In this mega thread there was some preliminary description of how a
menuing system for XCDs could work, mainly by raistlinK ( BTW, he doesnt
like to use matroska he said in another thread, even if its ready. Seems
he is a real OGM addict ). The idea was to use the same menue system as
the microDVD tools, have a look at his brief description ( not very
detailled ) here :

http://forum.doom9.org/showthread.php?s=&threadid=24288&perpage=20&highlight=xcd%20menue&pagenumber=6

If i understand this correctly, than the microDVD code is closed source
( avih didnt like this too much i guess ;) )  and supporting the DVD
menue playback system of M$ DirectShow ? Anybody to confirm that ?

@myFUN : IIRC it was you mentioning that there is the possibility to
support the matroska menu system via DirectShow, so that most players,
even WMP 7/8/9 could use it ?

What do you guys think about the acceptance of our menu system if we
took the DShow stucture as a basis ? Would Linux users refuse to support
it ( well, they support DVD menues also, and its nearly the same ) ? Is
the system powerful enough ? Could it be implemented into matroska
without major hassle ?

Thanks for any feedback

Christian



http://www.matroska.org


From steve.lhomme at free.fr  Wed Mar 12 16:38:07 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Wed, 12 Mar 2003 16:38:07 +0100 (CET)
Subject: [matroska-devel] Re: Brainstorming : menue structure - have a close look at the work done for XCD already ?
In-Reply-To: <3E6F4F41.6000209@matroska.org>
References: <3E6F4F41.6000209@matroska.org>
Message-ID: <1047483487.3e6f545f19c69@imp.free.fr>


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

> Brainstorming ( not high priority ) :

Brainstormed questions :

- do we allow one menu system or many menu system in matroska ?

- is the menu system a stream in a track ? a stream not in a track (level 1
element) ? an "file" attachement ? a combination of some of these ?

I think we can't progress much if we don't have answers to these questions.
http://www.matroska.org


From steve.lhomme at free.fr  Wed Mar 12 17:10:42 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Wed, 12 Mar 2003 17:10:42 +0100 (CET)
Subject: [matroska-devel] Re: Brainstorming : menue structure - have a close look at the work done for XCD already ?
In-Reply-To: <1047483487.3e6f545f19c69@imp.free.fr>
References: <3E6F4F41.6000209@matroska.org> <1047483487.3e6f545f19c69@imp.free.fr>
Message-ID: <1047485442.3e6f5c0258ff0@imp.free.fr>


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

I forgot to mention that this subject has already been discussed (as some of you
may remember).

I started to write the specs to handle the menu system, but didn't "keep" it
because it was not finished at all. Meanwhile it is *still* in the current
specs, but just commented in the HTML code. You can read what was already
settled (tentatively) by uncommenting the HTML code in the current specs :

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

Search for lines like this :
<!--
<tr><th colspan="8">Playback Control / Menu</th></tr>

and remove the <!-- and --> tags
http://www.matroska.org


From chris at matroska.org  Wed Mar 12 16:16:24 2003
From: chris at matroska.org (Christian HJ Wiesner)
Date: Wed, 12 Mar 2003 16:16:24 +0100
Subject: [matroska-devel] matroska HTTP/RTP streaming server solution based on videolan.org
 instead of icecast ?
Message-ID: <3E6F4F48.6090207@matroska.org>



Hi folks, lo How Tam, lo Henry,

robux4 and myself were on irc.freenode.net , #videolan yesterday evening
and had a pretty good conversation with some of the devs there. One of
the core developers, a guy called Sam, was even loading libmatroska and
had a first look, so maybe he will surprise us one day with a matroska
playback patch, we'll see.

Now, we got some pretty interesting news while being there. The counter
part to VLC, the player ( VideoLan Client ) is a streaming server for
multimedia called VLS ( VideoLan Server ). VLS is capable of making
multicast streaming via WAN or LAN, but what was originally designed to
allow media content streaming on a LAN only, and is maybe a bit more
complex to setup now, with respect to the WAN capability.
Now it seems that, to make things easier for people who only wnat to
stream in a LAN, they added streaming server capability to VLC, the
client, to allow easy hadnling of this for normal users ( i am still not
100% certain here, trying to investigate further ).

In any case, it was maybe worth having a close look at some of their
stuff ( www.videolan.org ) and get 'inspired' by some of their
solutions, so we can come up with a working streaming server solution
for matroska one day. This should be the priority order to make it, step
by step ( pls. correct me if i'm wrong, which is very likely the case as
i am not at all an expert in this field ) :

1. TCP based streaming on a LAN
2. UDP based streaming on a LAN ( maybe with enhanced, EBML based
ECC/FEC elements on the matroska file level to be prepared later )
3. HTTP streaming on a WAN ( TCP )
4. RTP streaming on a WAN ( UDP ; ECC/FEC is a must at this stage ?? )

Please note that our preferred player developers is of course the
CoreCodec team, means BlackSun and Betaboy, so every solution we present
should be made that way that in the end the matroska files can be played
on a DShow based player. I guess that, at least for 1. and 3., maybe
even 2. , Microsoft has existing Playback source filters already, so we
have to make sure to be compatible with them from the server side.

BlackSun is a great resource here, he knows DirectShow very good, at
least from the player side, and meanwhile they have a team member who
can make his own DirectShow filters, thats Christophe 'Toff' Paris, and
i am sure our team mate Jan 'myFUN' Schlenker, who is currently working
hard on the matroska DShow parser, could assist if there was an urgent
question pending.

@ How Tam : mate, you care to give us a short statement when you think
your real life will allow you to have a first look at the task ?

@ Henry : still motivated to help ?

Thanks for a quick answer

Christian



http://www.matroska.org


From Paul at msn.com  Thu Mar 13 06:48:32 2003
From: Paul at msn.com (Pamel)
Date: Wed, 12 Mar 2003 23:48:32 -0600
Subject: [matroska-devel] Menu Structure
Message-ID: <b4p61o$hmi$1@main.gmane.org>

I originally posted this in the Corecodec.com forums because that is where I
could get to, but I really meant to post it to the ML, so here it is.

There are four things that I want to say about Menu's in Matroska.

1. We need them. This is a pretty simple fact given all of the features
within Matroska.

2. Defining the menu specs should be outside of the scope of the Matroska
specs. It just isn't a part of the container, and defining it in the specs
is akin to saying MP3 is the official audio type of Matroska. If we define a
menu system outside of the Matroska specs, then it has the possibility to be
used in other containers too, such as OGM, MCF, MPCF, etc.

3. We need a way to mirror the way that DVD menus work. There are two
reasons for this, first it would be very convenient to be able to duplicate
the menu of a DVD and would make a full DVD to Matroska backup possible.
Second, there are already several DVD menu authoring tools, and it would
greatly increase the speed that people could start using the menus if we
could use the output of already existing programs.

4. We need a control track with at least some simple scripting. DVD menus
are great, and a lot can be done with them. However, to increase the
abilities of Matroska, we need a control track capable of some simple
scripting.



http://www.matroska.org


From Paul at msn.com  Thu Mar 13 06:57:49 2003
From: Paul at msn.com (Pamel)
Date: Wed, 12 Mar 2003 23:57:49 -0600
Subject: [matroska-devel] Re: Menu Structure
References: <b4p61o$hmi$1@main.gmane.org>
Message-ID: <b4p6j4$j11$1@main.gmane.org>

Here are some ideas I've had about how to mirror the DVD menu system, but
first a description of how they work on a DVD.

A menu on a DVD is composed of 4 parts.

  Video track
  Audio track
  Subtitle track
  IFO file
The video track is the background to the menu.
The audio track is what you hear when the menu is up.

The subtitle track doesn't contain subtitles, instead it contains a single
picture for the menu. Buttons that are displayed on the video track have
there alternate, "highlighted version" on this picture. A small portion of
the picture is selected and overlayed over the video to form the highlighted
button.

The IFO file contains several things, all in text. First it tells what file,
streams, and stream segments to use for a menu. Next, it lists the
coordinates of the "highlighted buttons" on the overlay mask contained in
the menus subtitle track. Finally, it contains all of the instructions. Like
pressing Left from this button highlights which other button. Or selecting
this button plays the movie starting at this timecode, or takes you to this
menu.

******************************
Now, how do we fit this into the Matroska?

The first two are easy, you just have video and audio track encoded to your
codecs of choice.

The third would require a subtitle track. You could store the picture as a
bitmap, but a PNG would take up much less space. It might be useful to
define a subtitle codec-id for just putting a PNG in a block at whatever
timecode.

The fourth part is where it gets a little tricky. The hardest part would be
changing all of the settings for VOBID and CELLID to instead tell the
segment, tracks, and chapters of the Matroska file containing the necessary
streams. Next, any video that was resized from the original would need the
coordinates changed for where the buttons are located on the subtitle track.
Other than that, everything could be left the same, or custom changed for
anyone that was doing a custom project.


Pamel



http://www.matroska.org


From Paul at msn.com  Thu Mar 13 07:09:32 2003
From: Paul at msn.com (Pamel)
Date: Thu, 13 Mar 2003 00:09:32 -0600
Subject: [matroska-devel] Re: Menu Structure
References: <b4p61o$hmi$1@main.gmane.org>
Message-ID: <b4p793$kt6$1@main.gmane.org>

I had a few ideas about requirements for a scripting language.

1. The control track needs to allow for some simple scripting such as:
GotoTimecode xx:xx.xxx
GotoChapter x
SetAudioTrack x

2. The control track might allow for some more complicated scripting such
as:
if
then
while
for

3. And possible some player controls such as:
Play
Pause
Mute/unMute
Next Chapter/Track
SkipToTimecode xx:xx.xxx


And some ideas about how this could be implemented.

1. Use XML to store the commands so that multiple scripts can be stored in
parallel, and they could all be aligned by timecodes.

2. If the scripts can be stored in parallel, and are activated by timcodes,
then you could store a portion of the scripts, that should run at a
timecode, in a regular block (ala USF).

3. Store the XML as EBML. You would save a few bytes, and we're using
EBML/XML for everything else so its not like anything extra would need to be
coded.

4. Again, this should be outside of the container specs. And really, it
should be outside of the menu specs too. The menu and control track should
be able to operate completely independantly of each other, however, there
should be a few instructions in both to activate some portions of the other.



http://www.matroska.org


From steve.lhomme at free.fr  Thu Mar 13 15:45:58 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Thu, 13 Mar 2003 15:45:58 +0100 (CET)
Subject: [matroska-devel] Re: Menu Structure
In-Reply-To: <b4p61o$hmi$1@main.gmane.org>
References: <b4p61o$hmi$1@main.gmane.org>
Message-ID: <1047566758.3e7099a6bf229@imp.free.fr>


En r?ponse ? Pamel <Paul at msn.com>:

> I originally posted this in the Corecodec.com forums because that is
> where I could get to, but I really meant to post it to the ML, so here it is.

I replied on CC. (it's easier for me)
http://www.matroska.org


From steve.lhomme at free.fr  Fri Mar 14 12:44:06 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Fri, 14 Mar 2003 12:44:06 +0100 (CET)
Subject: [matroska-devel] Display frames in coding order
Message-ID: <1047642246.3e71c0868b37f@imp.free.fr>


We have had a brainstorming yesterday on when a frame read in matroska can be
rendered/displayed.

As you know there is a "powerful" reference system in matroska that allows
infinite references of past and future frames. The frames are then saved in
coding order in matroska. The drawback is that it is harder to know with such a
system when a frame should be rendered or if there are some pending "future"
frames that should be rendered before.

There are 2 matroska elements that *have to* be used to solve this problem :
MinCache (store in the Track properties) and ReferencePriority (stored in the
BlockGroup). 

MinCache specifies the number of frames that have to be kept in cache for the
rendering to work.

ReferencePriority specifies that the frame can replace a frame of the same or
lower priority in cache.

The typical MPEG example is I/B/P frames. In this case MinCache = 2 (a backward
and a forward reference for a B frame). I and P frames can both be references
for a B frame so they have the same priority (2) and B frames have a priority of 0.

Let's explain the algo we have found to handle a simple case. Let's assume we
have an MPEG-like sequence IPPBBBPPI. That makes I0, P1, P2, B3, B4, B5, P6, P7,
I8,P9,P10 in display order. It will give in coding order (the way it is stored
in matroska) I0, P1, P2, P6, B3, B4, B5, P7, I8, P9, P10. (the cache is a FIFO
stack)

Now the pseudo algo :
- read I0 and put it in cache (,I0)
- read P1 and put it in cache (I0,P1)
- read P2 and put it in cache (P1,P2) I0 has not been rendered so display it
{I0} (it is out of cache because it has the same priority as P1 and P2)
- read P6 and put it in cache (P2,P6) P1 has not been rendered so display it {P1}
- read B3 it doesn't go in cache (Ref = 0 < 2 which is set on P2 and P6) and
therefore should be rendered. So we should also render the frames in cache that
has a lower timecode, ie P2. render {P2} {B3}/ cache (P2-,P6) (P2- means it has
already been rendered)
- read B4 it doesn't go in cache (P2-,P6) and should be rendered, nothing in
cache to render {B4}
- read B5 it doesn't go in cache (P2-,P6) and should be rendered, nothing in
cache to render {B5}
- read P7 and put it in cache (P6,P7) P2- is already rendered
- read I8 and put it in cache (P7,I8) P6 is rendered {P6}
- read P9 and put it in cache (I8,P9) P7 is rendered {P7}
- read P10 and put it in cache (P9,P10) I8 is rendered {I8}
etc

You see that the frames are rendered in display order. Hopefully !

This example shouldn't be too hard to translate into actual code.

Conclusion : MinCache an ReferencePriority should always be present ! They are
vital for normal matroska playback. 

There is one exception to this rule : when MinCache = 0, ie only I frames used
(the case for audio). This is the default MinCache value so doesn't need to be
set, and the ReferencePriority should be 0 too, and that's also the default
value. So it doesn't need to be set, and will be transparent to references.
http://www.matroska.org


From chris at matroska.org  Sat Mar 15 07:46:45 2003
From: chris at matroska.org (Christian HJ Wiesner)
Date: Sat, 15 Mar 2003 07:46:45 +0100
Subject: [matroska-devel] SEGA FILM Format , was : Ogg Vorbis tracks in QT files
In-Reply-To: <Pine.SOL.4.05.10303141819220.21717-100000@babu.pcisys.net>
References: <20030315010751.GF180@brightrain.aerifal.cx> <Pine.SOL.4.05.10303141819220.21717-100000@babu.pcisys.net>
Message-ID: <3E72CC55.9000708@matroska.org>


to: Mike Melanson ( Xine Chief Format Guru )
cc: matroska-devel at freelists.org

Hi Mike,

i am copying this email to our dev list so the devs could have a look at 
the specs if they felt like doing so. Would you care telling us very 
briefly what you do like in particular of this format ? What are the 
main advantages ?

Thanks

Christian
http://www.matroska.org

BTW : Our stuff is compiling fine now on different GCC versions and even 
on BeOS and OSX ;) .... and i guess Mosu should soon have the seek 
tables done also in his muxer tool, means the basic functionality of the 
container was fully implemented ...

Mike Melanson wrote:
> On Fri, 14 Mar 2003, D Richard Felker III wrote:
> 	To that end, I nominate the FILM format (my all-time favorite
> multimedia container format):
> 
>   http://www.pcisys.net/~melanson/codecs/film-format.txt
> 
> Please no one throw things at me, but I like the format...:)
> 	-Mike Melanson


http://www.matroska.org


From melanson at pcisys.net  Sat Mar 15 14:21:01 2003
From: melanson at pcisys.net (Mike Melanson)
Date: Sat, 15 Mar 2003 06:21:01 -0700 (MST)
Subject: [matroska-devel] Re: SEGA FILM Format , was : Ogg Vorbis tracks in QT files
In-Reply-To: <3E72CC55.9000708@matroska.org>
Message-ID: <Pine.LNX.4.44.0303150608250.17627-100000@x-wing.tmmm.home>


On Sat, 15 Mar 2003, Christian HJ Wiesner wrote:

> i am copying this email to our dev list so the devs could have a look at
> the specs if they felt like doing so. Would you care telling us very
> briefly what you do like in particular of this format ? What are the
> main advantages ?

	Certainly. I like the FILM format because it provides so much
information about playing the file up front. It always has an index that
includes the offset, length, timestamp, and duration of each frame. It
also carries keyframe data which makes it possible to seek very easily
through the file. The header chunk carries just enough pertinent
information to play back the file (video fourcc, width, height, audio
parameters).

	To be honest, the FILM format has a few shortcomings that I would
like to see remedied. Fortunately, there is a version field in the header
that could be bumped up to '2.00'. First, the format could use an audio
fourcc. Plus, it may need a field to describe the number of samples in a
VBR audio chunk. Fortunately, there still seem to be some reserved bytes
in the info header chunk that could be filled in. Further, the format
could use a textual information chunk. Again, easy to add if the version
number was bumped.

	Note that network streaming has never been a high priority for me
and my 56K modem but I realize that other people care deeply about it. I
have not thought much about how FILM would fit into a streaming model.

	BTW, I am a big fan of the Quicktime format for many of the same
reasons as FILM. I appreciate that there is always a master index that
describes everything needed to know in order to play the file. I think a
big shortcoming is that the index chunk (a.k.a. moov atom) is not always
guaranteed to be at the front of the file.

> BTW : Our stuff is compiling fine now on different GCC versions and even
> on BeOS and OSX ;) .... and i guess Mosu should soon have the seek
> tables done also in his muxer tool, means the basic functionality of the
> container was fully implemented ...

	I did get the Matroska tools compiled from CVS last week and
contrived some sample files. The format is making sense and I should be
able to demux it. However, I am still very busy right now implementing the
VP3/Theora video codec for ffmpeg.

	Thanks...
--
	-Mike Melanson

http://www.matroska.org


From chris at matroska.org  Sun Mar 16 15:57:57 2003
From: chris at matroska.org (Christian HJ Wiesner)
Date: Sun, 16 Mar 2003 15:57:57 +0100
Subject: [matroska-devel] Re: SEGA FILM Format , was : Ogg Vorbis tracks
 in QT files
In-Reply-To: <Pine.LNX.4.44.0303150608250.17627-100000@x-wing.tmmm.home>
References: <Pine.LNX.4.44.0303150608250.17627-100000@x-wing.tmmm.home>
Message-ID: <3E7490F5.5050508@matroska.org>


Mike Melanson wrote:

> I did get the Matroska tools compiled from CVS last week and contrived some sample files. The format is making sense and I should be able to demux it. However, I am still very busy right now implementing the VP3/Theora video codec for ffmpeg.
>	Thanks...	-Mike Melanson
>  
>

Mike,

its a pleasure to hear our little project had your attention already, 
ppls. believe me we are as excited as you are about the Theora project, 
and are looking forward to see Theora decoding in FFMPEG soon. No doubt 
Xiph people will contact you about joining the Theora core dev team once 
you're finished, so if you have a young Padawan who is running through 
the process of learning how to add format demuxing to Xine, we could 
also think of teaching him through the process of creating a Xine 
demuxer, if he is prepared to dive into the Xine sourcecode more deeply 
as we will be able to do right now.

About the SEGA FILM container, Steve 'robux4' Lhomme was reading through 
the specs very briefly, and is convinced now that everything that was 
being mentioned in there can be found in matroska also. Please dont 
hesitate to drop an email to our list if you have any more questions or 
find a misconception in our specs.

Best regards

Christian

http://www.matroska.org


From melanson at pcisys.net  Sun Mar 16 16:57:08 2003
From: melanson at pcisys.net (Mike Melanson)
Date: Sun, 16 Mar 2003 08:57:08 -0700 (MST)
Subject: [matroska-devel] Re: SEGA FILM Format , was : Ogg Vorbis tracks
 in QT files
In-Reply-To: <3E7490F5.5050508@matroska.org>
Message-ID: <Pine.LNX.4.44.0303160843040.20530-100000@x-wing.tmmm.home>


On Sun, 16 Mar 2003, Christian HJ Wiesner wrote:

> its a pleasure to hear our little project had your attention already,
> ppls. believe me we are as excited as you are about the Theora project,
> and are looking forward to see Theora decoding in FFMPEG soon. No doubt

	Believe me, it is more painful than exciting: Write a small
component, exhaustively validate the numerical output against the official
source, repeat...I have keyframes decoding but interframes are the real
challenge.

> Xiph people will contact you about joining the Theora core dev team once
> you're finished, so if you have a young Padawan who is running through

	Once I am finished with decoding VP3, I will proceed to the
documentation phase in order to help anyone else who wants to understand
the format. I will try to help with encoding VP3 via ffmpeg. But ffmpeg
and xine are my adopted projects and I have no intention of actively
contributing to the Theora effort.

> the process of learning how to add format demuxing to Xine, we could
> also think of teaching him through the process of creating a Xine
> demuxer, if he is prepared to dive into the Xine sourcecode more deeply
> as we will be able to do right now.

	With 23 format demuxers under my belt, I understand some patterns.
Matroska is not too complicated (famous last words). I already have a
strategy in mind for taking the format apart. I just have to get down to
writing it.

> About the SEGA FILM container, Steve 'robux4' Lhomme was reading through
> the specs very briefly, and is convinced now that everything that was
> being mentioned in there can be found in matroska also. Please dont
> hesitate to drop an email to our list if you have any more questions or
> find a misconception in our specs.

	I do not doubt that Matroska can do everything that FILM can do,
and more. What I appreciate about FILM is that is does (almost) everything
that I perceive a multimedia file format should be able to do and no more,
really.

	But as you probably know from my multimedia site and related
activities, I am committed to understanding every multimedia format out
there...

	Actually, one thing that is confusing me about the Matroska format
is the way that the examples show you how to merge, e.g., an AC3 and AVI
file into one Matroska file. What exactly is that going to result in? An
AC3 stream followed by the audio and video from the AVI file?

	Thanks...
--
	-Mike Melanson

http://www.matroska.org


From steve.lhomme at free.fr  Sun Mar 16 16:07:35 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Sun, 16 Mar 2003 17:07:35 +0200
Subject: [matroska-devel] Re: SEGA FILM Format , was : Ogg Vorbis tracks
 in QT files
In-Reply-To: <Pine.LNX.4.44.0303160843040.20530-100000@x-wing.tmmm.home>
References: <Pine.LNX.4.44.0303160843040.20530-100000@x-wing.tmmm.home>
Message-ID: <3E749337.1000208@free.fr>


Mike Melanson wrote:
> 	Actually, one thing that is confusing me about the Matroska format
> is the way that the examples show you how to merge, e.g., an AC3 and AVI
> file into one Matroska file. What exactly is that going to result in? An
> AC3 stream followed by the audio and video from the AVI file?

I'm not aware of any such example :(
Or maybe Mosu's mkvmerge ?

Anyway merging different media files would probably result in muxing 
them together, as if a Track (or more) was added.

Anyway since you know a lot about existing container (which we hardly 
do), any comment is very appreciated :)

http://www.matroska.org


From melanson at pcisys.net  Sun Mar 16 17:11:57 2003
From: melanson at pcisys.net (Mike Melanson)
Date: Sun, 16 Mar 2003 09:11:57 -0700 (MST)
Subject: [matroska-devel] Re: SEGA FILM Format , was : Ogg Vorbis tracks
 in QT files
In-Reply-To: <3E749337.1000208@free.fr>
Message-ID: <Pine.LNX.4.44.0303160910530.20530-100000@x-wing.tmmm.home>


On Sun, 16 Mar 2003, Steve Lhomme wrote:

> I'm not aware of any such example :(
> Or maybe Mosu's mkvmerge ?

	Here is the example that Mosu gives on his page:

  mkvmerge -o output.mkv input1.avi input2.ac3 input3.ogg

What kind of file would that result in? Thanks...
--
	-Mike Melanson

http://www.matroska.org


From suiryc at yahoo.com  Sun Mar 16 17:32:28 2003
From: suiryc at yahoo.com (Cyrius)
Date: Sun, 16 Mar 2003 08:32:28 -0800 (PST)
Subject: [matroska-devel] Re: SEGA FILM Format , was : Ogg Vorbis tracks in QT files
In-Reply-To: <Pine.LNX.4.44.0303160910530.20530-100000@x-wing.tmmm.home>
Message-ID: <20030316163228.39191.qmail@web12901.mail.yahoo.com>


Hi

--- Mike Melanson <melanson at pcisys.net> wrote:
> 
> On Sun, 16 Mar 2003, Steve Lhomme wrote:
> 
> > I'm not aware of any such example :(
> > Or maybe Mosu's mkvmerge ?
> 
> 	Here is the example that Mosu gives on his page:
> 
>   mkvmerge -o output.mkv input1.avi input2.ac3
> input3.ogg
> 
> What kind of file would that result in? Thanks...
> --
> 	-Mike Melanson
> 
> http://www.matroska.org

Well Mosu has the bad habit :p to use the term 'merge'
in his muxers (see ogmmerge and mkvmerge) but those
are real muxers (and not mergers that append
video/audio tracks).

So the resulting file will of course be the input1.avi
video with the input2.ac3 and input3.ogg audio tracks :)

__________________________________________________
Do you Yahoo!?
Yahoo! Web Hosting - establish your business online
http://webhosting.yahoo.com
http://www.matroska.org


From moritz at bunkus.org  Sun Mar 16 18:09:16 2003
From: moritz at bunkus.org (Moritz Bunkus)
Date: Sun, 16 Mar 2003 18:09:16 +0100
Subject: [matroska-devel] Re: SEGA FILM Format , was : Ogg Vorbis tracks in QT files
In-Reply-To: <20030316163228.39191.qmail@web12901.mail.yahoo.com>
References: <Pine.LNX.4.44.0303160910530.20530-100000@x-wing.tmmm.home> <20030316163228.39191.qmail@web12901.mail.yahoo.com>
Message-ID: <20030316170916.GE1374@bunkus.org>

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

From chris at matroska.org  Sun Mar 16 18:42:38 2003
From: chris at matroska.org (Christian HJ Wiesner)
Date: Sun, 16 Mar 2003 18:42:38 +0100
Subject: [matroska-devel] Re: SEGA FILM Format , was : Ogg Vorbis tracks
 in QT files
In-Reply-To: <20030316163228.39191.qmail@web12901.mail.yahoo.com>
References: <20030316163228.39191.qmail@web12901.mail.yahoo.com>
Message-ID: <3E74B78E.50108@matroska.org>


Cyrius wrote:

>Hi
>
>--- Mike Melanson <melanson at pcisys.net> wrote:
>  
>
>Well Mosu has the bad habit :p to use the term 'merge'
>in his muxers (see ogmmerge and mkvmerge) but those
>are real muxers (and not mergers that append
>video/audio tracks).
>  
>

Guys, make sure to copy Mike directly on the emails, he is not 
subscribed here ;) ....

http://www.matroska.org


From chris at matroska.org  Sun Mar 16 03:41:26 2003
From: chris at matroska.org (Christian HJ Wiesner)
Date: Sun, 16 Mar 2003 03:41:26 +0100
Subject: [matroska-devel] My conversation with GomGom about MPEG4frame order
Message-ID: <3E73E456.9030208@matroska.org>


<GomGom> there i am
<ChrisHJW> lo
<GomGom> ok
<ChrisHJW> you know why we are asking, right ?
<GomGom> let me explain you how the encoding works
<GomGom> else you won't get the point
<GomGom> we receive frames in the so called decoding order
<GomGom> or natural order
<GomGom> 1 2 3 4 5 6 7
<ChrisHJW> we are planning to make tools to convert AVIs into matroska 
files, where we will NOT use our VfW compatibility mode, but will write 
'native' MPEG4 matroska files
<ChrisHJW> ok
<GomGom> but the encoder will process them like that
<GomGom> it receives 1
<ChrisHJW> puts them in buffer
<GomGom> it forces an IFrame becuase there is no refernce frame
<GomGom> so 1 = IFrame
<ChrisHJW> and puts it in buffer
<GomGom> then it receives frame 2
<ChrisHJW> k
<GomGom> performs Motion Estimation
<GomGom> against reference frame  (ie. Frame 1)
<ChrisHJW> k
<GomGom> (i consider bframes are active)
<GomGom> most of the time
<ChrisHJW> decides what frame type to use for this frame, based on ME 
results, right ?
<GomGom> this 2nd frame is close enough to the first one so the encoder 
decides to encode it as a bframe
<ChrisHJW> k
<GomGom> BUT
<GomGom> BFrames are predicted against 2 refernces frames
<ChrisHJW> yes
<GomGom> so encoder has to wait or another reference frame
<GomGom> it returns a dummy frame to make VFWAPI likes happy
<GomGom> so Frame 2 is queued in the encoder, waiting for a second ref frame
<GomGom> external program received a dummy frame, but it does not know
<GomGom> then
<GomGom> frame 3 comes into enoder
<GomGom> let's say that encoder decides it will not be a bframe... thus 
a PFrame
<GomGom> PFrames are predicted thanks to only 1 frame
<GomGom> so the encoder encodes it against Frame1
<GomGom> and returns "a PFrame == frame 3
<GomGom> so the exteral program received at this moement
<GomGom> IFrame(1) PFrame(3)
<GomGom> no
<GomGom> sorry
<GomGom> IFrame(1) Dummy(PFrame(3)
<GomGom>  arf
<GomGom> IFrame(1) Dummy PFrame(3)
<GomGom> next frame is given to the encoder
<GomGom> Encoder decides what to with frame 4
<GomGom> BUT
<GomGom> it will not enocode this one
<GomGom> it flushes a BFrame between 1 and 3
<GomGom> thus frame 2
<GomGom> and returns the Frame 2 == BFrame
<GomGom> external programs has I(1) Dummy P(3) B(2)
<GomGom> encoder has in its queue ?(4)
<GomGom> and its refernce frames P(3)
<GomGom> I(1) is not part of its refernces anymore
<GomGom> because it is in a new "wait for another reference" phase
<GomGom> got it ?
<GomGom> basic algorithm is
<GomGom> Encode reference
<GomGom> Queue until 2nd reference
<GomGom> Encode 2nd reference
<ChrisHJW> ok
<GomGom> Flush all bframes && queue input frames during this flush sequence
<GomGom> begin again
<GomGom> so
<GomGom> now during decoding
<GomGom> the decoder receives the frames
<GomGom> in the right decoding order (from the algorithm point of view)
<GomGom> I mean
<GomGom> it receives I(1)
<GomGom> that's ok because it can decode it
<GomGom> returns frame 1
<GomGom> then it receives dummy
<GomGom> returns previous frame
<ChrisHJW> with you on that
<GomGom> (that operation is the one that introduces a/v delays)
<GomGom> then it receives P(3)
<GomGom> decodes it, but returns frame 1 again
<GomGom> then it receives B(2)
<GomGom> decode it thanks to I(1) and P(3)
<GomGom> returns Frame 2
<GomGom> then it receives P(5)
<GomGom> returns P(3)
<GomGom> etc etc
<GomGom> the important point here again is that decoder has always to 
have 2 refernce frames
<GomGom> was i clear enough ?
<ChrisHJW> so this is where we have the frame delay, but thats just at 
the start of the movie, right ?
<GomGom> or when last bframe sequence length is shorter than the one 
being constructed
<ChrisHJW> from then on, what does it do ... even if it receives 5 I 
frames in a row, it will always output them with a 2 frames dealy ?
<GomGom> yep, the delay introduced once is preserved
<ChrisHJW> because it will always keep 2 frames in buffer ?
<ChrisHJW> ok
<GomGom> still because of the "one frame in one frame out" rule
<ChrisHJW> now, we wont have dummy frames in matroska in the native modes
<GomGom> else we could flush all bframes when we receive the second 
reference
<GomGom> hmmw
<ChrisHJW> this doesnt change much, because we will have the very same 
frame order
<GomGom> i'm wrong in my last sequence
<GomGom> sequence=sentence
<GomGom> we could return a packet of frames if the container can return 
a group of encoded frames
<ChrisHJW> yes, we cant flush them all, or we would break the fps ?
<GomGom> that's what we simulate with packed stream
<GomGom> look
<GomGom> i showed you that
<ChrisHJW> well, my problem with what we are trying to do it, will your 
decoders be able to handle that ?
<GomGom> I N N P B B ...
<GomGom> now imagine that we pack things
<GomGom> I N N (PBB)
<ChrisHJW> gives I P B B in matroska
<GomGom> now imagine a good API that is able to wait for valid frames
<GomGom> we would have I (PBB)
<GomGom> so no more delays
<GomGom> because
<GomGom> I is decoded immediately
<GomGom> then the decoder receives the grouped frames
<GomGom> It decodes in one run, the P and the 2 Bframes
<GomGom> and returns the first bframe as expected in a simple world :)
<GomGom> so my conclusion for matroska is:
<GomGom> your parser has to know that it should fill until the next ref 
frame
<GomGom> in one run
<ChrisHJW> oh !
<ChrisHJW> our parser has to insert dummy frames ?
<GomGom> ie: it has to concatenate the stream until the next ref frame
<GomGom> NO
<GomGom> I mean you have this:
<GomGom> I P B B B B P
<GomGom> in your file
<GomGom> your parser
<ChrisHJW> yes
<GomGom> has to feed the enocoder like that
<GomGom> first "getFrame"
<ChrisHJW> decoder
<GomGom> would output the I stream
<GomGom> then your parser
<GomGom> should return the group (P B B B)
<GomGom> even if in your format they are not in the same segment
<ChrisHJW> we call them blocks
<GomGom> ie: parse until the next ref frame is reached
<ChrisHJW> one frame = one block
<ChrisHJW> k
<GomGom> so your format can pack them in one block (so parsing would be 
trivial)
<GomGom> OR
<GomGom> your format could store them one frame per block
<GomGom> but then it would have to parse until next ref block is reached
<GomGom> 
<GomGom> both solutions are viable
<ChrisHJW> we wont break the one = one block rule, but better tell the 
DShow parser to read all blocks until a valid reference frame is reached
<GomGom> ok
<GomGom> i hope i've been clear enough
<ChrisHJW> and then render them all
<ChrisHJW> sure !!
<ChrisHJW> thanks so much
<GomGom> if any doubt, post this discussion on the maiiling list and 
spot your doubts
<ChrisHJW> i had no idea your decoder would allow we give them all the 
frames at once
<GomGom> i think it is interesting for lot of readers
<ChrisHJW> at least until a next reference is coming
<ChrisHJW> what i am still mising is
<ChrisHJW> how does your decoder know when it receives a b-frame ?
<ChrisHJW> is there a flag or so in the bitstream ?
<GomGom> it's a bit in the bistream
<GomGom> read the file xvidcore/src/bitstream/bitstream.c
<GomGom> if you want precise bitstream syntax
<ChrisHJW> not necessary
<ChrisHJW> its just for my understanding
<ChrisHJW> now, one last question please :-)
<ChrisHJW> what would happen if we would render the frames to the 
decoder just as we read them
<ChrisHJW> means
<ChrisHJW> I P B B P
<ChrisHJW> would it KNOW there was a b-frame between I and P ?
<ChrisHJW> or simply decode the P frame as it receives it
<ChrisHJW> and have no clue what frames to use to decode the following 
b-frames
<ChrisHJW> i mean, instaed of rrendering them like I (PBB)
<ChrisHJW> sorry
<ChrisHJW> I (PBB) P
<ChrisHJW> GomGom ?
<GomGom> yes
<ChrisHJW> thats really the last question ;)
<GomGom> it knows
<GomGom> because of a VOL flag called low_delay
<GomGom> iif low_delay is set
<GomGom> then decoder does not wait for a second ref frame
<GomGom> if it is unset (when bframes are active)
<GomGom> then decoder waits until 2 ref frames are in its buffer
<ChrisHJW> so .. its maybe even easier for us :) .. we just send the 
frames to the decoder as we receive them
<GomGom> and one is received
<GomGom> one more is received
<GomGom> nop
<GomGom> you can't
<GomGom> while decoder is filling buffers
<GomGom> it sends copies of past frames
<GomGom> that's not good for A/V delays
<ChrisHJW> oh ! shit ...
<GomGom> the only solution is to give all gourp of frames at once
<ChrisHJW> fully with you know
<ChrisHJW> fully with you now
<GomGom> have you logged that ?
<ChrisHJW> sure :)
<ChrisHJW> uh !
<ChrisHJW> nope, wrong PC, sorry
<ChrisHJW> have to copy it manually i guess
<ChrisHJW> but it wont be lost Edouard, i promise ;)
<GomGom> it's just if other matroska devs ask for details
<GomGom> don't want to answer this question again, i'm too lazy
<GomGom> :>
<ChrisHJW> lol
<ChrisHJW> you read M. Niedermayers reply on xvid-devel ?
<ChrisHJW> he proves you wrong
<GomGom> nope
<ChrisHJW> he says mencoder with FFMPEG writes in coding order, no dummy 
frames
<GomGom> he proves me mencoder skips NFrames whenduring the encoding session
<GomGom> but mencoder does not solve the delay problem i guess
<ChrisHJW> lol
<ChrisHJW> i maybe started a big flamewar how to do it correctly now .. lol
<GomGom> no
<GomGom> we already know what is the good way
<GomGom> group frames
<ChrisHJW> for AVI ;)
<GomGom> so decoder does not introduces delays
<GomGom> not only for AVI
<GomGom>  i meant
<ChrisHJW> i understand now
<GomGom> grouping frames in two possible ways
<GomGom> at encoding time or at parsing time
<GomGom> but the decoder must be presented grouped frames
<GomGom> if you don't want delays
<ChrisHJW> sure
<ChrisHJW> unless you always buffer max nr. of allowed b-frames by default
<GomGom> hmmm
<GomGom> that's exactly what my queuer idea is
<GomGom> have an encoding chain like that
<GomGom> <file> -- <parser> -- <decoder> -- <encoder> -- <queuer> -- 
<bitstream wiriter>
<GomGom> the queuer would be told by the encoder module to flush its frames
<GomGom> but until it receives that order, the queuer queues frames
<GomGom> nowadays we have a kind of chain like this one
<GomGom> but because of the "one frame in one frame out" rule
<GomGom> the queuer is inside XviD
<GomGom> and XviD has to send Dummy frames
<ChrisHJW> :(



http://www.matroska.org


From steve.lhomme at free.fr  Sun Mar 16 09:17:00 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Sun, 16 Mar 2003 10:17:00 +0200
Subject: [matroska-devel] Re: My conversation with GomGom about MPEG4frame
 order
In-Reply-To: <3E73E456.9030208@matroska.org>
References: <3E73E456.9030208@matroska.org>
Message-ID: <3E7432FC.1050905@free.fr>


Christian HJ Wiesner wrote:
> <GomGom> i showed you that
> <ChrisHJW> well, my problem with what we are trying to do it, will your 
> decoders be able to handle that ?
> <GomGom> I N N P B B ...
> <GomGom> now imagine that we pack things
> <GomGom> I N N (PBB)
> <ChrisHJW> gives I P B B in matroska
> <GomGom> now imagine a good API that is able to wait for valid frames
> <GomGom> we would have I (PBB)
> <GomGom> so no more delays
> <GomGom> because
> <GomGom> I is decoded immediately
> <GomGom> then the decoder receives the grouped frames
> <GomGom> It decodes in one run, the P and the 2 Bframes
> <GomGom> and returns the first bframe as expected in a simple world :)
> <GomGom> so my conclusion for matroska is:
> <GomGom> your parser has to know that it should fill until the next ref 
> frame
> <GomGom> in one run
> <ChrisHJW> oh !
> <ChrisHJW> our parser has to insert dummy frames ?
> <GomGom> ie: it has to concatenate the stream until the next ref frame
> <GomGom> NO
> <GomGom> I mean you have this:
> <GomGom> I P B B B B 
> <GomGom> in your file
> <GomGom> your parser

Yes, that's why what he asked {I (PBB)} can already be done. Because in 
the end that's the equivalent of {I P B B}.

The 2 frame delay is inevitable when using B frames. That's also what we 
get in the decoding system I emailed the other day.

BTW, that decoding could be in libmatroska (taking care internally of 
MinCache & ReferencePriority). Probably something to put in FileKax or 
something like that.

> <ChrisHJW> yes
> <GomGom> has to feed the enocoder like that
> <GomGom> first "getFrame"
> <ChrisHJW> decoder
> <GomGom> would output the I stream
> <GomGom> then your parser
> <GomGom> should return the group (P B B B)
> <GomGom> even if in your format they are not in the same segment
> <ChrisHJW> we call them blocks
> <GomGom> ie: parse until the next ref frame is reached
> <ChrisHJW> one frame = one block
> <ChrisHJW> k
> <GomGom> so your format can pack them in one block (so parsing would be 
> trivial)
> <GomGom> OR
> <GomGom> your format could store them one frame per block
> <GomGom> but then it would have to parse until next ref block is reached
> <GomGom> 
> <GomGom> both solutions are viable

Second option. And with no dummy frames.

> <ChrisHJW> we wont break the one = one block rule, but better tell the 
> DShow parser to read all blocks until a valid reference frame is reached

We do ! Unless we use the algo I was mentioning earlier internally.

This is another level to libmatroska that will be introduced later.

> <GomGom> ok
> <GomGom> i hope i've been clear enough
> <ChrisHJW> and then render them all
> <ChrisHJW> sure !!
> <ChrisHJW> thanks so much
> <GomGom> if any doubt, post this discussion on the maiiling list and 
> spot your doubts
> <ChrisHJW> i had no idea your decoder would allow we give them all the 
> frames at once

There is no need for that in matroska. Otherwise you would lose the 
timecode information. But anyway that's not a problem to separate 
frames. As long as the codec give us the correct references.

If the codec cannot give us such an information, then we have to use the 
packing method he was talking about. But we lose the timecode 
information he was talking about. It is possible to use it with a 
similar system to what we want to do with H.264 (data parts with 
different priorities).

> <GomGom> the only solution is to give all gourp of frames at once
> <ChrisHJW> fully with you know
> <ChrisHJW> fully with you now
> <GomGom> have you logged that ?
> <ChrisHJW> sure :)
> <ChrisHJW> uh !
> <ChrisHJW> nope, wrong PC, sorry
> <ChrisHJW> have to copy it manually i guess
> <ChrisHJW> but it wont be lost Edouard, i promise ;)
> <GomGom> it's just if other matroska devs ask for details
> <GomGom> don't want to answer this question again, i'm too lazy
> <GomGom> :>
> <ChrisHJW> lol
> <ChrisHJW> you read M. Niedermayers reply on xvid-devel ?
> <ChrisHJW> he proves you wrong
> <GomGom> nope
> <ChrisHJW> he says mencoder with FFMPEG writes in coding order, no dummy 
> frames
> <GomGom> he proves me mencoder skips NFrames whenduring the encoding session
> <GomGom> but mencoder does not solve the delay problem i guess
> <ChrisHJW> lol
> <ChrisHJW> i maybe started a big flamewar how to do it correctly now .. lol
> <GomGom> no
> <GomGom> we already know what is the good way
> <GomGom> group frames

Mmm. That's only good at the codec level, not at the container level 
(think of blind cutting of files when you have 100 B frames). Our 
solution (simply store in the coding order) is equivalent to their 
group, but makes more sense at the container level.

> <ChrisHJW> for AVI ;)
> <GomGom> so decoder does not introduces delays
> <GomGom> not only for AVI
> <GomGom>  i meant
> <ChrisHJW> i understand now
> <GomGom> grouping frames in two possible ways
> <GomGom> at encoding time or at parsing time
> <GomGom> but the decoder must be presented grouped frames
> <GomGom> if you don't want delays
> <ChrisHJW> sure
> <ChrisHJW> unless you always buffer max nr. of allowed b-frames by default
> <GomGom> hmmm
> <GomGom> that's exactly what my queuer idea is
> <GomGom> have an encoding chain like that
> <GomGom> <file> -- <parser> -- <decoder> -- <encoder> -- <queuer> -- 
> <bitstream wiriter>
> <GomGom> the queuer would be told by the encoder module to flush its frames
> <GomGom> but until it receives that order, the queuer queues frames
> <GomGom> nowadays we have a kind of chain like this one
> <GomGom> but because of the "one frame in one frame out" rule
> <GomGom> the queuer is inside XviD
> <GomGom> and XviD has to send Dummy frames
> <ChrisHJW> :(

Typically why we need a new API *and* matroska is good to codec 
developpers. As I already said, we allow them not to care much about the 
reference issues. They only need to be able to know which frame depend 
on which one, and get the possibility to access these references.

http://www.matroska.org


From chris at matroska.org  Sun Mar 16 04:51:27 2003
From: chris at matroska.org (Christian HJ Wiesner)
Date: Sun, 16 Mar 2003 04:51:27 +0100
Subject: [matroska-devel] Hello to the h.264 devs from the matroska team
Message-ID: <3E73F4BF.5050104@matroska.org>



Hi all,

pls. allow me to introduce the matroska Team to you guys, in case you 
dont know us yet : We're a couple of people from all OSes making a new 
opensource and open standard container format. We are claining our 
container has a very flexible and extensible design, as its based on a 
binary form of XML called EBML ( http://ebml.sf.net ).

Just to test our design approaches we were currently brainstorming how 
we could support h.264 standard best in our container, and that was big 
fun because never heard of NALU's and all the other stuff before :-D ! 
We were pointed to your project and the h.264 draft specs ( they were 
fixed now i heard ? ) from a guy calling himself 'shlezman', maybe you 
know him. Part of the discussion ( not all ) can be found here : 
http://corecodec.com/modules.php?op=modload&name=PNphpBB2&file=viewtopic&t=291 
, the rest is to be found on our ML archive on matroska-general and 
matroska-devel at freelists.org .

Dont be afraid, i dont plan to spam your mailinglist with matroska 
related posts now, this is just to say hello.

I will read your MLs now via the gmane.org NNTP interface , 
gmane.comp.video.hdot264.devel , and hopefully be able to contribute a 
little bit to the development of this great project.

Best regards

Christian
http://www.matroska.org
 

http://www.matroska.org


From post at com.freelists.org  Sun Mar 16 17:42:38 2003
From: post at com.freelists.org (postr)
Date: Mon, 17 Mar 2003 04:42:38 +1200
Subject: [matroska-devel] Overture Account / PPC Account
Message-ID: <a8f3d8c5bd8a$f40cf202$b3d28304@rrohmxbl.em>



http://www.matroska.org


From steve.lhomme at free.fr  Tue Mar 18 12:54:29 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Tue, 18 Mar 2003 12:54:29 +0100 (CET)
Subject: [matroska-devel] GCC compilation
Message-ID: <1047988469.3e7708f5e74bb@imp.free.fr>


Hi,

This question goes out to whoever managed to build libmatroska with GCC (Mosu ?).

I've tried some days ago on OSX without much success because of the lack of
support for std::basic_string<wchar_t>... I thought it was a problem with OSX...

Now I've been trying to compile it with Dev-C++ & MinGW32 GCC 3.2 and I get the
same error at the link level :
undefined reference to `std::basic_string<wchar_t, std::char_traits<wchar_t>,
std::allocator<wchar_t> >::~basic_string()'

So my question is :
How did you build libmatroska under GCC ? Was the Unicode support disabled ?
:(

PS: Dev-C++ is a really+free development environment. I hope to be able to
switch to that ASAP (as soon as I can compile libmatroska with GCC).
http://www.matroska.org


From moritz at bunkus.org  Tue Mar 18 13:14:06 2003
From: moritz at bunkus.org (Moritz Bunkus)
Date: Tue, 18 Mar 2003 13:14:06 +0100
Subject: [matroska-devel] Re: GCC compilation
In-Reply-To: <1047988469.3e7708f5e74bb@imp.free.fr>
References: <1047988469.3e7708f5e74bb@imp.free.fr>
Message-ID: <20030318121406.GA2356@bunkus.org>

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

From steve.lhomme at free.fr  Tue Mar 18 13:21:58 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Tue, 18 Mar 2003 13:21:58 +0100 (CET)
Subject: [matroska-devel] Re: GCC compilation
In-Reply-To: <20030318121406.GA2356@bunkus.org>
References: <1047988469.3e7708f5e74bb@imp.free.fr> <20030318121406.GA2356@bunkus.org>
Message-ID: <1047990118.3e770f6612081@imp.free.fr>


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

> > This question goes out to whoever managed to build libmatroska with
> > GCC (Mosu ?).
> 
> Someone called my name? :)

Sort of :)
 
> > So my question is :
> > How did you build libmatroska under GCC ? Was the Unicode support
> disabled ?
> > :(
> 
> Uh... I don't think so. Here's an example command line for gcc 2.95.4:
> 
> g++ -c -g -DDEBUG -Wall -Wno-unknown-pragmas -DGCC2 \
>   -DWRITE_EVEN_UNSET_DATA -I../../src/ -o ../../src/KaxTrackVideo.o \
>   ../../src/KaxTrackVideo.cpp
> 
> and for gcc 3.2.2:
> 
> g++-3.2 -c -g -DDEBUG -Wall -Wno-unknown-pragmas \
>   -DWRITE_EVEN_UNSET_DATA -I../../src/ -o ../../src/EbmlBinary.o \
>   ../../src/EbmlBinary.cpp
> 
> It works just fine with both of them. Linking against mkvmerge/mkvinfo
> also works fine obviously ;)

Mmmm, so the problem is both in OSX and MinGW32...
Could you locate the library that has basic_string<wchar_t> ?

The basic_string<char_t> is defined in both compilers, but not the wchar_t
counterpart. I wonder wether it's because the underlying OS does support this
type natively...

Otherwise we'll have to find another way to support Unicode on all platforms.
http://www.matroska.org


From steve.lhomme at free.fr  Tue Mar 18 14:15:13 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Tue, 18 Mar 2003 14:15:13 +0100 (CET)
Subject: [matroska-devel] Re: GCC compilation
In-Reply-To: <1047990118.3e770f6612081@imp.free.fr>
References: <1047988469.3e7708f5e74bb@imp.free.fr> <20030318121406.GA2356@bunkus.org> <1047990118.3e770f6612081@imp.free.fr>
Message-ID: <1047993313.3e771be13d1d6@imp.free.fr>


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

> > Uh... I don't think so. Here's an example command line for gcc
> 2.95.4:
> > 
> > g++ -c -g -DDEBUG -Wall -Wno-unknown-pragmas -DGCC2 \
> >   -DWRITE_EVEN_UNSET_DATA -I../../src/ -o ../../src/KaxTrackVideo.o
> \
> >   ../../src/KaxTrackVideo.cpp
> > 
> > and for gcc 3.2.2:
> > 
> > g++-3.2 -c -g -DDEBUG -Wall -Wno-unknown-pragmas \
> >   -DWRITE_EVEN_UNSET_DATA -I../../src/ -o ../../src/EbmlBinary.o \
> >   ../../src/EbmlBinary.cpp
> > 
> > It works just fine with both of them. Linking against
> mkvmerge/mkvinfo
> > also works fine obviously ;)
> 
> Mmmm, so the problem is both in OSX and MinGW32...
> Could you locate the library that has basic_string<wchar_t> ?

Nevermind, I just tried under Mandrake 9.0 (the one I use at work) and it
compiled perfectly.
 
> The basic_string<char_t> is defined in both compilers, but not the
> wchar_t
> counterpart. I wonder wether it's because the underlying OS does support
> this type natively...
> 
> Otherwise we'll have to find another way to support Unicode on all
> platforms.

In the other hand, that doesn't help find why it only works on Linux...
I think I'll try to contact the MinGW32 people.
http://www.matroska.org


From steve.lhomme at free.fr  Tue Mar 18 14:38:41 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Tue, 18 Mar 2003 14:38:41 +0100 (CET)
Subject: [matroska-devel] Re: GCC compilation
In-Reply-To: <1047993313.3e771be13d1d6@imp.free.fr>
References: <1047988469.3e7708f5e74bb@imp.free.fr> <20030318121406.GA2356@bunkus.org> <1047990118.3e770f6612081@imp.free.fr> <1047993313.3e771be13d1d6@imp.free.fr>
Message-ID: <1047994721.3e7721619ef86@imp.free.fr>


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

> In the other hand, that doesn't help find why it only works on
> Linux...
> I think I'll try to contact the MinGW32 people.

OK, first clue found :
https://sourceforge.net/tracker/index.php?func=detail&aid=664369&group_id=2435&atid=102435

This is a bug in the bug list of MinGW32.
http://www.matroska.org


From steve.lhomme at free.fr  Tue Mar 18 15:45:35 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Tue, 18 Mar 2003 15:45:35 +0100 (CET)
Subject: [matroska-devel] Re: GCC compilation
In-Reply-To: <1047990118.3e770f6612081@imp.free.fr>
References: <1047988469.3e7708f5e74bb@imp.free.fr> <20030318121406.GA2356@bunkus.org> <1047990118.3e770f6612081@imp.free.fr>
Message-ID: <1047998735.3e77310f38270@imp.free.fr>


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

> Otherwise we'll have to find another way to support Unicode on all
> platforms.

I've found the beggining of an answer :
http://sourceforge.net/mailarchive/message.php?msg_id=1991233

ie use STLPort...
http://www.matroska.org


From chris at matroska.org  Tue Mar 18 13:17:45 2003
From: chris at matroska.org (Christian HJ Wiesner)
Date: Tue, 18 Mar 2003 13:17:45 +0100
Subject: [matroska-devel] Re: GCC compilation
In-Reply-To: <1047988469.3e7708f5e74bb@imp.free.fr>
References: <1047988469.3e7708f5e74bb@imp.free.fr>
Message-ID: <3E770E69.1040501@matroska.org>


Steve,

bill_baroud had the very same problems, and with DevCPP also :( .... he 
gave up trying to compile libmatroska, believing it was his fault. 
Please talk to him about these problems, me might feel better then ;) ....

Christian

Steve Lhomme wrote:

>Hi,
>
>This question goes out to whoever managed to build libmatroska with GCC (Mosu ?).
>
>I've tried some days ago on OSX without much success because of the lack of
>support for std::basic_string<wchar_t>... I thought it was a problem with OSX...
>
>Now I've been trying to compile it with Dev-C++ & MinGW32 GCC 3.2 and I get the
>same error at the link level :
>undefined reference to `std::basic_string<wchar_t, std::char_traits<wchar_t>,
>std::allocator<wchar_t> >::~basic_string()'
>
>So my question is :
>How did you build libmatroska under GCC ? Was the Unicode support disabled ?
>:(
>
>PS: Dev-C++ is a really+free development environment. I hope to be able to
>switch to that ASAP (as soon as I can compile libmatroska with GCC).
>http://www.matroska.org
>
>  
>

http://www.matroska.org


From jcsston at ToughGuy.net  Sat Mar 22 02:41:01 2003
From: jcsston at ToughGuy.net (Jory)
Date: Fri, 21 Mar 2003 19:41:01 -0600
Subject: [matroska-devel] Re: GCC compilation
References: <1047988469.3e7708f5e74bb@imp.free.fr> <3E770E69.1040501@matroska.org>
Message-ID: <000801c2f014$4cbcf7e0$0200a8c0@jcsston>


I am also having the same trouble as bill_baroud trying to compile spyder's
mpa2mka with Dev-CPP GCC 2.95.

The first error is:
g++.exe -c -g -DDEBUG -Wall -Wno-unknown-pragmas -DGCC2 \
  -DWRITE_EVEN_UNSET_DATA mpa2mka.cpp -o
mpa2mka.o -I"C:/Dev-Cpp/include" -I"D:/Visual Studio
Projects/matroska/libmatroska_sf/src" -pg -g3 -mwindows
In file included from D:/Visual Studio
Projects/matroska/libmatroska_sf/src/EbmlTypes.h:43,
                 from D:/Visual Studio
Projects/matroska/libmatroska_sf/src/IOCallback.h:39,
                 from D:/Visual Studio
Projects/matroska/libmatroska_sf/src/StdIOCallback.h:38,
                 from mpa2mka.cpp:26:
D:/Visual Studio
Projects/matroska/libmatroska_sf/src/api/c/libmatroska_t.h:106: syntax error
before `;'

which is the following line

106    typedef int64_t int64;
The lines following 106 also create syntax errors.

Any hints on which options to use compiling?

----- Original Message -----
From: "Christian HJ Wiesner" <chris at matroska.org>
To: <matroska-devel at freelists.org>
Sent: Tuesday, March 18, 2003 6:17 AM
Subject: [matroska-devel] Re: GCC compilation


>
> Steve,
>
> bill_baroud had the very same problems, and with DevCPP also :( .... he
> gave up trying to compile libmatroska, believing it was his fault.
> Please talk to him about these problems, me might feel better then ;) ....
>
> Christian
>
> Steve Lhomme wrote:
>
> >Hi,
> >
> >This question goes out to whoever managed to build libmatroska with GCC
(Mosu ?).
> >
> >I've tried some days ago on OSX without much success because of the lack
of
> >support for std::basic_string<wchar_t>... I thought it was a problem with
OSX...
> >
> >Now I've been trying to compile it with Dev-C++ & MinGW32 GCC 3.2 and I
get the
> >same error at the link level :
> >undefined reference to `std::basic_string<wchar_t,
std::char_traits<wchar_t>,
> >std::allocator<wchar_t> >::~basic_string()'
> >
> >So my question is :
> >How did you build libmatroska under GCC ? Was the Unicode support
disabled ?
> >:(
> >
> >PS: Dev-C++ is a really+free development environment. I hope to be able
to
> >switch to that ASAP (as soon as I can compile libmatroska with GCC).
> >http://www.matroska.org
> >
> >
> >
>
> http://www.matroska.org


http://www.matroska.org


From theo_brendel at hotmail.com  Tue Mar 18 16:23:52 2003
From: theo_brendel at hotmail.com (Steven Mingam)
Date: Tue, 18 Mar 2003 16:23:52 +0100
Subject: [matroska-devel] Anamorphic Content
Message-ID: <b57dps$dar$1@main.gmane.org>


(ah, it's my first post !)

i'm just reading this thread on Doom9 :

http://forum.doom9.org/showthread.php?s=&threadid=40572&perpage=20&pagenumber=1

it's talking about anamorphic support in RV9 and it's looks like it's a container feature (a flag to add ...)
so my question is : is this case already in the specs ( to be honest, i haven't really read them ;) or no ?

because it's quite interesting and a pity to have that only with RV9 and nothing else.


bill_baroud



http://www.matroska.org


From steve.lhomme at free.fr  Tue Mar 18 17:02:31 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Tue, 18 Mar 2003 17:02:31 +0100 (CET)
Subject: [matroska-devel] Re: Anamorphic Content
In-Reply-To: <b57dps$dar$1@main.gmane.org>
References: <b57dps$dar$1@main.gmane.org>
Message-ID: <1048003351.3e774317144d3@imp.free.fr>


En r?ponse ? Steven Mingam <theo_brendel at hotmail.com>:

> (ah, it's my first post !)

Hey Steven Theo Bill ! :D
 
> i'm just reading this thread on Doom9 :
> 
> http://forum.doom9.org/showthread.php?s=&threadid=40572&perpage=20&pagenumber=1
> 
> it's talking about anamorphic support in RV9 and it's looks like it's a
> container feature (a flag to add ...)
> so my question is : is this case already in the specs ( to be honest, i
> haven't really read them ;) or no ?
> 
> because it's quite interesting and a pity to have that only with RV9 and
> nothing else.
> 
> 
> bill_baroud

The guy from RealNetworks says :
" The upsize feature in producer is not well documented, but what happens if you
specify a resize size that is larger than your input video size, producer will
not actually resize the video, but add a flag to the bitstream, such that the
player will stretch the video to the desired size. This stretching is a high
quality interpolation done by the video card without extra CPU overhead."

We support that already. We have the pixel size of the encoded data and the
display size. For example you could have a picture of 400x200 that would render
on the screen with 200x200. So I think it is supported (with something more
elaborate than a flag). As long as you have the display area (not the pixel) you
can fit it best on a screen.

thx for the tip
http://www.matroska.org


From theo_brendel at hotmail.com  Tue Mar 18 17:08:44 2003
From: theo_brendel at hotmail.com (Steven Mingam)
Date: Tue, 18 Mar 2003 17:08:44 +0100
Subject: [matroska-devel] Re: Anamorphic Content
References: <b57dps$dar$1@main.gmane.org> <1048003351.3e774317144d3@imp.free.fr>
Message-ID: <b57ge0$p1e$1@main.gmane.org>

Ok, it's doing the same then .....

another pro for matroska !


thanks for the quick answer,
bill_baroud

"Steve Lhomme" <steve.lhomme at free.fr> a ?crit dans le message news:
1048003351.3e774317144d3 at imp.free.fr...
>
> En r?ponse   Steven Mingam <theo_brendel at hotmail.com>:
>
> > (ah, it's my first post !)
>
> Hey Steven Theo Bill ! :D
>
> > i'm just reading this thread on Doom9 :
> >
> >
http://forum.doom9.org/showthread.php?s=&threadid=40572&perpage=20&pagenumbe
r=1
> >
> > it's talking about anamorphic support in RV9 and it's looks like it's a
> > container feature (a flag to add ...)
> > so my question is : is this case already in the specs ( to be honest, i
> > haven't really read them ;) or no ?
> >
> > because it's quite interesting and a pity to have that only with RV9 and
> > nothing else.
> >
> >
> > bill_baroud
>
> The guy from RealNetworks says :
> " The upsize feature in producer is not well documented, but what happens
if you
> specify a resize size that is larger than your input video size, producer
will
> not actually resize the video, but add a flag to the bitstream, such that
the
> player will stretch the video to the desired size. This stretching is a
high
> quality interpolation done by the video card without extra CPU overhead."
>
> We support that already. We have the pixel size of the encoded data and
the
> display size. For example you could have a picture of 400x200 that would
render
> on the screen with 200x200. So I think it is supported (with something
more
> elaborate than a flag). As long as you have the display area (not the
pixel) you
> can fit it best on a screen.
>
> thx for the tip
> http://www.matroska.org
>



http://www.matroska.org


From chris at matroska.org  Wed Mar 19 06:36:22 2003
From: chris at matroska.org (Christian HJ Wiesner)
Date: Wed, 19 Mar 2003 06:36:22 +0100
Subject: [matroska-devel] I finally created my 1st MKA file ;) ..
Message-ID: <3E7801D6.2040300@matroska.org>


Hi all,

I can confirm now thar spyder's MPA2MKA is working correctly :) .... 
well done John !!

Shall i upload it somewhere so you guys can test ? Mosu, can you test it 
on your Windows box and see if you can play the files in mplayer ?

Christian

http://www.matroska.org


From moritz at bunkus.org  Wed Mar 19 09:24:33 2003
From: moritz at bunkus.org (Moritz Bunkus)
Date: Wed, 19 Mar 2003 09:24:33 +0100
Subject: [matroska-devel] Re: I finally created my 1st MKA file ;) ..
In-Reply-To: <3E7801D6.2040300@matroska.org>
References: <3E7801D6.2040300@matroska.org>
Message-ID: <20030319082433.GB2356@bunkus.org>

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

From spyder482 at yahoo.com  Wed Mar 19 15:09:09 2003
From: spyder482 at yahoo.com (John Cannon)
Date: Wed, 19 Mar 2003 08:09:09 -0600
Subject: [matroska-devel] Re: I finally created my 1st MKA file ;) ..
References: <3E7801D6.2040300@matroska.org>
Message-ID: <b59tjt$6vs$1@main.gmane.org>

> Shall i upload it somewhere so you guys can test ? Mosu, can you test it
> on your Windows box and see if you can play the files in mplayer ?

 If you meant Linux, me and jcsston have tried under linux already.  Even
his flower linux (Lycoris) made it work :)

John



http://www.matroska.org


From chris at matroska.org  Thu Mar 20 20:27:51 2003
From: chris at matroska.org (Christian HJ Wiesner)
Date: Thu, 20 Mar 2003 20:27:51 +0100
Subject: [matroska-devel] Re: matroska : MPEG1/2 video streams muxing
In-Reply-To: <E18vyKX-0001xO-00@sc8-sf-web3.sourceforge.net>
References: <E18vyKX-0001xO-00@sc8-sf-web3.sourceforge.net>
Message-ID: <3E7A1637.5070009@matroska.org>


Hi Siriam !

Sorry about my late reply, i was on a short bussiness trip ( Real Life, 
not matroska :D ) and couldnt reply earlier.

As always, if a new team member is writing to us if he could help, i am 
using this email to find out the status of the current jobs, so we know 
what you could look at :

@animesh : mate, if time allows, could you please give us a short update 
of the porting of the main lib to C ? Is EBML reading working already ? 
Could you pls. send me the code you already have, or upload it to CVS ?

@shelly : any news regarding porting mkvmerger to win32 ? Anything for 
the CVS tree yet ? Phear the evil HDD crashes folks, better upload it so 
its safe  :-D !!

@ Aymen : Did libmatroska and mkvmerger finally compile for you on Linux ?

@ Henry : are you still interested to help or are other things taking 
your time right now ?

@ Amit : did you finally find the time to dive into the code a little bit ?

@ raghav : mate, i havent heard from you since months, i guess i can 
remove you from the list of developers now ?

@ thana : exams over ? still interested in helping ? Sorry there is no 
working java code yet, spyder has decided to code in C/C++ now

Guys, please give me a short update, its ok if you cant contribute any 
longer to our project, but please drop me a short message at least, so 
that we are aware and can react accordingly.

Regards

Christian

Sriram wrote:

>Hi
>
>I am Sriram. I am presently between jobs. I have some 
>amount of experience in device drivers under windows and 
>linux and have also developed a task scheduler for a coldfire 
>based board. Now as a stop gap I am looking at possible 
>Open Source Projects where i can be helpful. I found urs 
>interesting. I have least idea about video codecs. I have some 
>basic knowledge of Signal Processing that I picked up at 
>college. I am willing to learn. If u are interested I am read to 
>team up. 
>
>User ID:  363165 
>Login Name:  sriramsrini  
>
>regards
>Sriram
>
>  
>


http://www.matroska.org


From shailesh.mistry at milan.eclipse.co.uk  Thu Mar 20 20:36:11 2003
From: shailesh.mistry at milan.eclipse.co.uk (Shailesh L Mistry)
Date: Thu, 20 Mar 2003 19:36:11 -0000
Subject: [matroska-devel] Re: matroska : MPEG1/2 video streams muxing
References: <E18vyKX-0001xO-00@sc8-sf-web3.sourceforge.net> <3E7A1637.5070009@matroska.org>
Message-ID: <00d401c2ef17$f6a83420$0200a8c0@desktop>


Hi Christian,

> @shelly : any news regarding porting mkvmerger to win32 ? Anything for
> the CVS tree yet ? Phear the evil HDD crashes folks, better upload it so
> its safe  :-D !!

Real Life is seriously eating into my contribution time at the moment.
I sent Mosu some updates a while back which he has merged in already.
I have a few questions I need to post to the group but this may not be
possible today.

I am still on the case but at a much slower pace right now.

Shelly

http://www.matroska.org


From amitlimaye at gmx.co.uk  Fri Mar 21 04:57:02 2003
From: amitlimaye at gmx.co.uk (amit limaye)
Date: Fri, 21 Mar 2003 04:57:02 +0100 (MET)
Subject: [matroska-devel] Re: matroska : MPEG1/2 video streams muxing
References: <3E7A1637.5070009@matroska.org>
Message-ID: <8990.1048219022@www62.gmx.net>


Hello Chris
         i havent looked much at the code. but i have been following ur
discusions on the list. u people seem to talk a lot abt MPEG and A/V compression
and streaming which i know preciously little abt.
Shud i first try and understand the MPEG standards or do u think i can dive
into code and understand it 
        
-SIGTERM
amit
> @ Amit : did you finally find the time to dive into the code a little bit
> ?


-- 
+++ GMX - Mail, Messaging & more  http://www.gmx.net +++
Bitte l?cheln! Fotogalerie online mit GMX ohne eigene Homepage!

http://www.matroska.org


From Paul at msn.com  Fri Mar 21 05:22:26 2003
From: Paul at msn.com (Pamel)
Date: Thu, 20 Mar 2003 22:22:26 -0600
Subject: [matroska-devel] Re: matroska : MPEG1/2 video streams muxing
References: <3E7A1637.5070009@matroska.org> <8990.1048219022@www62.gmx.net>
Message-ID: <b5e418$bhb$1@main.gmane.org>

"amit limaye" <amitlimaye at gmx.co.uk> wrote
>  u people seem to talk a lot abt MPEG and A/V compression
> and streaming which i know preciously little abt.
> Shud i first try and understand the MPEG standards or do u think i can
dive
> into code and understand it

Most of those discussions aren't related at all to the project itself.  The
only code that has anything to do with MPEG is mpa2mka, which was made by
spyder482.  It is a stand alone program that puts MPEG-Audio into a Matroska
file.  There isn't any current need to get to know this program any better,
I would recommend ignoring all of the MPEG and compression discussions right
now and just get a little familiar with libmatroska.


Pamel



http://www.matroska.org


From chris at matroska.org  Sat Mar 22 14:01:55 2003
From: chris at matroska.org (Christian HJ Wiesner)
Date: Sat, 22 Mar 2003 14:01:55 +0100
Subject: [matroska-devel] Re: matroska : MPEG1/2 video streams muxing
In-Reply-To: <8990.1048219022@www62.gmx.net>
References: <3E7A1637.5070009@matroska.org> <8990.1048219022@www62.gmx.net>
Message-ID: <3E7C5EC3.1030704@matroska.org>


Hi Amit,

sorry for my late reply, although i've seen Pamel was giving you a first 
reply to your question already.

Well, muxing MPEG video streams into the matroska container is just one 
aspect of what our project is about, its just mere coincidence that the 
subject was discussed recently, as our team member John 'spyder' Cannon 
is working on MPA2MKA ( MP2/3  muxing into matroska audio files ) and 
MPEG2MKV ( Mpeg 1/2 video muxing ) currently.

If you browse through the archives of the lists you will find a couple 
of other subjects we are discussing :

 http://news.gmane.org/thread.php?group=gmane.comp.multimedia.matroska.devel
http://news.gmane.org/thread.php?group=gmane.comp.multimedia.matroska.general

Amit, do you have any personal interests in the audio/video field, like 
compressing music, archiving DVDs or the like ? Please tell us a bit 
more about where your interests are, and i am sure we could find a task 
for you that will catch your interest. If you havent been much into this 
field yet, join us on irc.corecodec.com #matroska , and we can guide you 
through the process of making your first DVD backup or to compress your 
favourite CD . There are also a couple of pretty 'boring' tasks ( :-) ) 
that will not necessarily require any background information about audio 
and video compression, such as porting the main library ( libmatroska ) 
from C++ to C ( animesh and Shelly are on this huge task now, with first 
promising results ) or to port a Linux tool called mkvmerger to Windows 
( Shelly has started with this also and its compiling fine on VC6 already ).

Please tell me where you could think of helping out first :-) !! After 
all, this is not bussiness, but should be fun for all of us ;-) ....

Christian

amit limaye wrote:

>Hello Chris
>         i havent looked much at the code. but i have been following ur
>discusions on the list. u people seem to talk a lot abt MPEG and A/V compression
>and streaming which i know preciously little abt.
>Shud i first try and understand the MPEG standards or do u think i can dive
>into code and understand it 
>        
>-SIGTERM
>amit
>  
>
>>@ Amit : did you finally find the time to dive into the code a little bit
>>?
>>    
>>
>
>
>  
>


http://www.matroska.org


From chris at matroska.org  Fri Mar 21 16:05:33 2003
From: chris at matroska.org (Christian HJ Wiesner)
Date: Fri, 21 Mar 2003 16:05:33 +0100
Subject: [matroska-devel] Re: Working matroska dshow filter
In-Reply-To: <3E7B1E7A.70800@corecodec.com>
References: <200303101444.h2AEiP832087@mailgate5.cinetic.de> <3E6F6AE4.8070706@corecodec.com> <3E71D69D.6060805@matroska.org> <3E7B1E7A.70800@corecodec.com>
Message-ID: <3E7B2A3D.5020104@matroska.org>


Jan,

thank you so much !! This is in fact one of the greatest b-day presents 
i ever received in my whole Life !! What a coincidence, really, but this 
makes me feel REAL good today, despite the fact i am one year older now  
;) ...

My other great thanks goes of course to Cyrius and Mosu, who are the 
biggest support for us we could have ever wished for, developing all 
those great tools for matroska so that it can be used nicely on Windows 
and Linux. You guys are just great, and we hope to have you in our team 
for a very very long time !!

And while i am already in the process of saying thank you, please allow 
me to express my admiration to the people who have made this possible 
with us :

John 'spyder' Cannon, who is with the team now since the very beginning, 
mate, i know there are big things to come from you, MPA2MKA and MPEG2MKV 
are just the very beginning !

Blacksun and Betaboy, who always believed in our small project, and are 
hosting us on Corecodec for free ! Folks you're advice, both technical ( 
Ludovic ) and with respect to organisation matters ( Dan ) helped us 
soooo much ! Dont know if we ever did it without you ....

Frank Klemm, your input was soo importnat for us, it was coming exactly 
at the right time, when we were a bit clueless in what direction we 
should move with matroska .... a very warm 'Danke Sch?n' to you !

Toff, Ciler and Oxy, the core devs and the heart of TCMP, you were 
always friends to our project, we know we can always count on you guys !

Pamel and Milkman_Dan, the one jumped into the project when the other 
had to lean back a bit for real life reasons, but what would we be 
without your support folks !

The new developers, designers and contributors coming to our help, 
Marlena, Ronald, Mike, Rath0, animesh, bill_baroud, amit, shelly, 
Liisachan, Ayaka, Henry, How Man, Thana, Sriram, Golddragongt, David, 
maliqua, Santiago, DaveEL, Matthew, Nupur, Kimmo, and all the other 
matroska fans i couldn't think of now, in the very short notice ( and 
will hopefully accept my apologies for that ) : Your help and interest 
in our small project is pushing us forward, motivating us to give the 
best day by day, and we hope we will succeed in the end, with your help, 
to establish matroska as a nice, well designed open standard alternative 
to all existing audio and video containers !! Thanks Marlena, thanks 
guys for all you help and contribution !


And Finally : Steve, its just one more step of many steps we both were 
going together to get this project moving, but for me it has a special 
meaning, and its even more important now as it is my b-day when the 
filter first worked. I hope we will make many many steps like that in 
the future, together, and as friends  ..... thank you Steve, thank you 
for making this great day possible for me !!

/me said enough now and goes off to celebrate the birth of the matroska 
DShow filter   :-) ....

Christian

P.S. I hope nobody here got the impression now that we are a Windows 
centric project .. LOL

Ludovic 'BlackSun' Vialle wrote:

> MyFUN did it :)
>
>

http://www.matroska.org


From steve.lhomme at free.fr  Fri Mar 21 16:37:29 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Fri, 21 Mar 2003 16:37:29 +0100 (CET)
Subject: [matroska-devel] Re: Working matroska dshow filter
In-Reply-To: <3E7B2A3D.5020104@matroska.org>
References: <200303101444.h2AEiP832087@mailgate5.cinetic.de> <3E6F6AE4.8070706@corecodec.com> <3E71D69D.6060805@matroska.org> <3E7B1E7A.70800@corecodec.com> <3E7B2A3D.5020104@matroska.org>
Message-ID: <1048261049.3e7b31b9a0430@imp.free.fr>


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

> And Finally : Steve, its just one more step of many steps we both were
> going together to get this project moving, but for me it has a special
> meaning, and its even more important now as it is my b-day when the 
> filter first worked. I hope we will make many many steps like that in 
> the future, together, and as friends  ..... thank you Steve, thank you
> for making this great day possible for me !!

Ah, I thought you were going to forget about me ;)

Yeah, I'm very happy that we finally reach this huge step. matroska without a
working DirectShow parser is not really worth. At least on 90% of desktop
computers... So this is the biggest step in the project since we left from MCF.

BTW, the best present I had in my life was a song a girl wrote for/about me :)

Happy birthday. I hope the party will be worth the event !
http://www.matroska.org


From Paul at msn.com  Sun Mar 23 18:32:23 2003
From: Paul at msn.com (Pamel)
Date: Sun, 23 Mar 2003 11:32:23 -0600
Subject: [matroska-devel] Pamel's problem list for Matroska
Message-ID: <b5kr24$pgo$1@main.gmane.org>

Here is a list of issues with Matroska that are highest priority in my book.
These are only limited to the specs of Matroska, they have nothing to do
with program support for it.

1.  There is not a defined way to store multiple audio files in a MKA.
Steve has already said that when transcoding a whole CD, it is best to put
it in one long track and then divide the songs by chapters.  But for all of
those people that already have a bunch of MP3s, and other files, this isn't
an option.  We need to define how this SHOULD be done so that we can start
working with audio players to make sure they handle it properly.

2.  We need an element in Matroska that coresponds to every single tag in
ID3v2.4.0 to ensure maximum compatability when storing MP3s in Matroska.
There are many that could be gouped together in a sub-element as they are
less common, but there needs to be a way to store those.  A full list can be
found here: http://www.id3.org/id3v2.4.0-frames.txt

3.  There is no menu track defined in the specs.  (Menu can be different
than Control)  Even though neither are implemented yet, they need to be
defined now because we know both will be used.

4.  There is only a way defined to get up to 255 tracks.  Regardless of
whether or not you think anyone will use it, this is a glaring limitation.
It would be easy to fix in one of two ways with a variable field.
4a.  Use the 1xxx xxxx method to define the track number.  This would allow
126 tracks with blocks the same size as we have now, and 16000 tracks with
blocks 1 byte larger.  It would also be using the same VLC that we've been
using everywhere else.
4b.  Use the opposite approach of 0xxx xxxx to define the track number.  It
offers the exact same numbers, and is backwards compatible with what we use
now.  Unfortunately it is also the opposite VLC method that we use
everywhere else.


Pamel



http://www.matroska.org


From spyder482 at yahoo.com  Mon Mar 24 00:06:26 2003
From: spyder482 at yahoo.com (John Cannon)
Date: Sun, 23 Mar 2003 17:06:26 -0600
Subject: [matroska-devel] Re: Pamel's problem list for Matroska
References: <b5kr24$pgo$1@main.gmane.org>
Message-ID: <b5leja$hvc$1@main.gmane.org>


"Pamel" <Paul at msn.com> wrote in message news:b5kr24$pgo$1 at main.gmane.org...

> 4.  There is only a way defined to get up to 255 tracks.  Regardless of
> whether or not you think anyone will use it, this is a glaring limitation.
> It would be easy to fix in one of two ways with a variable field.
> 4a.  Use the 1xxx xxxx method to define the track number.  This would
allow
> 126 tracks with blocks the same size as we have now, and 16000 tracks with
> blocks 1 byte larger.  It would also be using the same VLC that we've been
> using everywhere else.
> 4b.  Use the opposite approach of 0xxx xxxx to define the track number.
It
> offers the exact same numbers, and is backwards compatible with what we
use
> now.  Unfortunately it is also the opposite VLC method that we use
> everywhere else.

Hmmm, nice idea.  I wonder where it came from. ;)
I vote for option b but if you are scared of breaking consistency we can go
with a.  But we will break current files. :(

Also, I would like to see a key/value comment element so we can support
those vorbis-style tags, allowing a user to set any specific info about a
file/track/chapter they want.  So if I wanted to remember how much money i
had at the time of the encoding/muxing i could make a "MONEY_AT_TIME" =
"$0.00" tag int his area.  It should be incredibly easy for any player/muxer
to read or create this comments.  We could possibly make them a certain size
also, like a 2KB chunk or 4KB etc..  Then with a defined syntax for coding
the values we could allow after creation editing of the comments (as long as
they don't go over the boundary of course) :)

John




http://www.matroska.org


From steve.lhomme at free.fr  Sun Mar 23 20:25:22 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Sun, 23 Mar 2003 21:25:22 +0200
Subject: [matroska-devel] Re: =[SPAM?]= Re: mkvtoolnix
In-Reply-To: <20030323210602.A24194@fuchs.offl.uni-jena.de>
References: <003201c2e497$448bea50$0200a8c0@desktop> <20030307114705.GD17028@bunkus.org> <00f501c2e4da$e6251ab0$0200a8c0@desktop> <20030307204905.GE17028@bunkus.org> <008101c2e7c6$67351c70$0200a8c0@desktop> <20030311122234.GF2679@bunkus.org> <010501c2e965$67f5b5c0$0200a8c0@desktop> <20030313133841.GC17841@bunkus.org> <001f01c2efba$76beb380$0200a8c0@desktop> <1048260620.3e7b300c37ec9@imp.free.fr> <20030323210602.A24194@fuchs.offl.uni-jena.de>
Message-ID: <3E7E0A22.3020505@free.fr>


Frank Klemm wrote:
> On Fri, Mar 21, 2003 at 04:30:20PM +0100, Steve Lhomme wrote:
> 
>>En r?ponse ? Shailesh L Mistry <shailesh.mistry at milan.eclipse.co.uk>:
>>
>>
>>>Hi Mosu,
>>>
>>>I have hit a snag with the mkvmerge build.
>>>I get the following errors  :-
>>>
>>>queue.cpp(118) : error C2520: conversion from unsigned __int64 to double
>>>not
>>>implemented, use signed __int64
>>>p_mp3.cpp(210) : error C2520: conversion from unsigned __int64 to double
>>>not
>>>implemented, use signed __int64
>>>p_ac3.cpp(213) : error C2520: conversion from unsigned __int64 to double
>>>not
>>>implemented, use signed __int64
>>>p_pcm.cpp(153) : error C2520: conversion from unsigned __int64 to double
>>>not
>>>implemented, use signed __int64
>>>p_pcm.cpp(159) : error C2520: conversion from unsigned __int64 to double
>>>not
>>>implemented, use signed __int64
>>>
>>>Is it possible to use signed __int64 instead of unsigned __int64 in
>>>these 5 places?
>>
>>I don't have the code here but the problem seem to be the conversion from
>>integer (64 bits) to float (double). So your solution couldn't work. As long as
>>the 64 bits coded value can hold in a 32 bits coded one, you can try this
>>conversion first (64 -> 32 -> float).
>>http://www.matroska.org
>>
> 
> I sent background of the problem and a solution to the ML.
> Do noone read this?

I did !!!!

I just didn't have time to reply (not sure it needed a reply).

No time to code (especially since your ASM code seemed to be missing 
some lines, which I don't have the time to create). I still didn't find 
time to compile the DirectShow Filter...

Maybe an easier (maybe dirty but working) would be to convert the uint64 
to a int64 (as long as it's smaller than 2^63). It avoids adding 
assembly lines to the code which I don't feel comfortable with.

Anyway, be sure your help is very appreciated and listened to !!!

bye

http://www.matroska.org


From steve.lhomme at free.fr  Sun Mar 23 20:27:55 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Sun, 23 Mar 2003 21:27:55 +0200
Subject: [matroska-devel] Re: =[SPAM?]= Re: mkvtoolnix
In-Reply-To: <3E7E0A22.3020505@free.fr>
References: <003201c2e497$448bea50$0200a8c0@desktop> <20030307114705.GD17028@bunkus.org> <00f501c2e4da$e6251ab0$0200a8c0@desktop> <20030307204905.GE17028@bunkus.org> <008101c2e7c6$67351c70$0200a8c0@desktop> <20030311122234.GF2679@bunkus.org> <010501c2e965$67f5b5c0$0200a8c0@desktop> <20030313133841.GC17841@bunkus.org> <001f01c2efba$76beb380$0200a8c0@desktop> <1048260620.3e7b300c37ec9@imp.free.fr> <20030323210602.A24194@fuchs.offl.uni-jena.de> <3E7E0A22.3020505@free.fr>
Message-ID: <3E7E0ABB.6060509@free.fr>


Steve Lhomme wrote:
>>I sent background of the problem and a solution to the ML.
>>Do noone read this?
> 
> 
> I did !!!!
> 
> I just didn't have time to reply (not sure it needed a reply).
> 
> No time to code (especially since your ASM code seemed to be missing 
> some lines, which I don't have the time to create). I still didn't find 
> time to compile the DirectShow Filter...
> 
> Maybe an easier (maybe dirty but working) would be to convert the uint64 
> to a int64 (as long as it's smaller than 2^63). It avoids adding 
> assembly lines to the code which I don't feel comfortable with.

BTW, there are other important issues regarding the code : the Unicode 
support of GCC is not fully working for g++ under MingW32 and OS X.2. 
I'm putting a lot of attention there too !

http://www.matroska.org


From steve.lhomme at free.fr  Tue Mar 25 20:04:55 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Tue, 25 Mar 2003 21:04:55 +0200
Subject: [matroska-devel] [Fwd: Re: =[SPAM?]= Re: mkvtoolnix]
Message-ID: <3E80A857.80308@free.fr>


-------- Original Message --------
Subject: Re: =[SPAM?]= [matroska-devel] Re: mkvtoolnix
Date: Mon, 24 Mar 2003 10:50:29 +0100
From: Frank Klemm <pfk at fuchs.offl.uni-jena.de>
To: Steve Lhomme <steve.lhomme at free.fr>

On Sun, Mar 23, 2003 at 09:25:22PM +0200, Steve Lhomme wrote:
> 
> I did !!!!
> 
> I just didn't have time to reply (not sure it needed a reply).
> 
> No time to code (especially since your ASM code seemed to be missing 
> some lines, which I don't have the time to create). I still didn't find 
> time to compile the DirectShow Filter...
> 
> Maybe an easier (maybe dirty but working) would be to convert the uint64 
> to a int64 (as long as it's smaller than 2^63). It avoids adding 
> assembly lines to the code which I don't feel comfortable with.
> 
> Anyway, be sure your help is very appreciated and listened to !!!
> 
Most important is to move the problem to a single point in the source code,
not to multiple points.


Convertion function can also be written in C/C++:

/* untested code, show of principle */
long double
uint64_to_longdouble ( uint64_t value )
{
     if ( value & 0x8000000000000000 )
         return (long double) ((int64_t) value) + (long 
double)18446744073709551616.;
     else
         return (long double) ((int64_t) value);
}


Types with a given size of bits are named in ISO 9899:1999 (also called C99)

   uint8_t
   uint16_t
   uint32_t
   uint64_t
   uintmax_t
   int8_t
   int16_t
   int32_t
   int64_t
   intmax_t

This standard was introduced at least 10 years too late. Nearly all bigger
projects had invented their own types long long before 1999, and so the
problem is, that this new standard is fine, but the goal is to prevent name
collisions. So we have UINT32, Uint32, uint32, uint32_t, flac_uint32,
ogg_uint32, ...

Note that you can't as a C compiler about the presence of a type:

No

#if !typedefed uint32_t
...

-- 
Frank Klemm

http://www.matroska.org


From chris at matroska.org  Mon Mar 31 00:19:51 2003
From: chris at matroska.org (Christian HJ Wiesner)
Date: Mon, 31 Mar 2003 00:19:51 +0200
Subject: [matroska-devel] WMV 9 VCM working in matroska, but not in OGM
Message-ID: <3E876D87.5040909@matroska.org>


http://forum.doom9.org/showthread.php?s=&postid=287106#post287106


Hi,

i have made a couple of testencodes with the new WMV9 VCM codec, and my 
first superb impression has now been calmed down a bit, although there 
can be no doubt its
 a good codec. S_O from the Doom9 forums has made a test i didnt think 
of, he tried to mux the video into OGM first in VdubMod, then also into 
matroska using matroskadub ( he is alpha tester ).

Now guess what, WMV9 would mux fine into matroka ( a pitty we cant play 
it yet :D ) with matroskadub, but not into OGM in VirtualdubMod ;-) .....

Excellent job Cyrius !!!!

Christian


http://www.matroska.org


From steve.lhomme at free.fr  Mon Mar 31 17:10:39 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Mon, 31 Mar 2003 17:10:39 +0200 (CEST)
Subject: [matroska-devel] On legality
Message-ID: <1049123439.3e885a6fef9da@imp.free.fr>


Hi,

I was just browsing the code of mpa2mka on the cvsweb of Corecodec.org...
And I was pleased to see that spyder used my MPA classes to parse the MPA files :)

Unfortunately the copyright notice has been removed !

I just took my sources from http://mukoli.free.fr/mpa2wav/ to verify that I
placed a copyright notice. And there was one.

Guys, I know that open source sounds like you can take anybody's code and use it
for everything you want. But that's not the case. There are rules. So if you
want to take someone's code you have to make sure you have the rights to do so,
and make sure you follow your obligations when doing so. In this case, the first
basic thing that you are *never* allowed to do on any license is change or
remove the copyright of a file. And that was the only line removed from the
(GPL) license I put on this code...

So please, correct that and be carefull next time. It's only me so it's not a
problem but if it was someone else's code you might be in legal troubles.

We have a reputation !
http://www.matroska.org


From spyder482 at yahoo.com  Mon Mar 31 23:31:10 2003
From: spyder482 at yahoo.com (John Cannon)
Date: Mon, 31 Mar 2003 15:31:10 -0600
Subject: [matroska-devel] Re: On legality
References: <1049123439.3e885a6fef9da@imp.free.fr>
Message-ID: <b6ac08$6d2$1@main.gmane.org>

> I was just browsing the code of mpa2mka on the cvsweb of Corecodec.org...
> And I was pleased to see that spyder used my MPA classes to parse the MPA
files :)

They are great pieces of code.  Be proud :)


> Unfortunately the copyright notice has been removed !
Actually they were never there to begin with so I didn't do anything wrong.

>
> I just took my sources from http://mukoli.free.fr/mpa2wav/ to verify that
I
> placed a copyright notice. And there was one.
>

My version was from MCF CVS and to date it still has no copyright notice.

> Guys, I know that open source sounds like you can take anybody's code and
use it
> for everything you want. But that's not the case. There are rules. So if
you
> want to take someone's code you have to make sure you have the rights to
do so,
> and make sure you follow your obligations when doing so. In this case, the
first
> basic thing that you are *never* allowed to do on any license is change or
> remove the copyright of a file. And that was the only line removed from
the
> (GPL) license I put on this code...
>

I know this, but there was no notice !

> So please, correct that and be carefull next time. It's only me so it's
not a
> problem but if it was someone else's code you might be in legal troubles.

I will merge the new code immediately but I am completely innocent here.
You told me to get the code from the MCF CVS and I did.    I wish you had
told me where to get the new version when I asked because the long time it
took me to clean up my code was because of your classes not working without
libmcf which you obviously removed for the mpa2wav sources.  :)

I just wished you could have asked me before posting this, this is a bit
humiliating and had me worried for a minute ;)

John Cannon
Matroska Developer
spyder482 at matroska.org



http://www.matroska.org


From steve.lhomme at free.fr  Mon Mar 31 22:52:51 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Mon, 31 Mar 2003 23:52:51 +0300
Subject: [matroska-devel] Re: On legality
In-Reply-To: <b6ac08$6d2$1@main.gmane.org>
References: <1049123439.3e885a6fef9da@imp.free.fr> <b6ac08$6d2$1@main.gmane.org>
Message-ID: <3E88AAA3.10802@free.fr>


John Cannon wrote:
> I will merge the new code immediately but I am completely innocent here.
> You told me to get the code from the MCF CVS and I did.    I wish you had
> told me where to get the new version when I asked because the long time it
> took me to clean up my code was because of your classes not working without
> libmcf which you obviously removed for the mpa2wav sources.  :)

Yeah sorry. You got the wrong source.

> I just wished you could have asked me before posting this, this is a bit
> humiliating and had me worried for a minute ;)

Well, this is also a reminder for any other people. As usual I try to 
make things clear (in advance). I know some people have troubles with 
licenses and how to use them.

Sorry if I offensed you.

> John Cannon
> Matroska Developer
> spyder482 at matroska.org

http://www.matroska.org