From suiryc at yahoo.com  Wed Dec  3 17:19:16 2003
From: suiryc at yahoo.com (Cyrius)
Date: Wed, 3 Dec 2003 08:19:16 -0800 (PST)
Subject: [Matroska-devel] KaxBlock is b0rked
In-Reply-To: <3FC529AE.1000002@free.fr>
Message-ID: <20031203161916.35833.qmail@web12905.mail.yahoo.com>

--- Steve Lhomme <steve.lhomme at free.fr> wrote:
> Can it wait until next week ? Because it will be
> impossible for me to 
> work on it until monday or tuesday next week...

Without any news I just comitted the fixes in the CVS,
because I think it's better than having a CVS code
that crashes (certainly segfault under Linux) when
reading a matroska file.

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


From moritz at bunkus.org  Wed Dec  3 17:29:14 2003
From: moritz at bunkus.org (Moritz Bunkus)
Date: Wed, 3 Dec 2003 17:29:14 +0100
Subject: [Matroska-devel] KaxBlock is b0rked
In-Reply-To: <20031203161916.35833.qmail@web12905.mail.yahoo.com>
References: <3FC529AE.1000002@free.fr>
	<20031203161916.35833.qmail@web12905.mail.yahoo.com>
Message-ID: <20031203162914.GS19712@bunkus.org>

Heya,

> Without any news I just comitted the fixes in the CVS,
> because I think it's better than having a CVS code
> that crashes (certainly segfault under Linux) when
> reading a matroska file.

Well, it hasn't been segfaulting for me at all...

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


From moritz at bunkus.org  Wed Dec  3 17:32:30 2003
From: moritz at bunkus.org (Moritz Bunkus)
Date: Wed, 3 Dec 2003 17:32:30 +0100
Subject: [Matroska-devel] KaxBlock is b0rked
In-Reply-To: <20031203162914.GS19712@bunkus.org>
References: <3FC529AE.1000002@free.fr>
	<20031203161916.35833.qmail@web12905.mail.yahoo.com>
	<20031203162914.GS19712@bunkus.org>
Message-ID: <20031203163230.GT19712@bunkus.org>

> Well, it hasn't been segfaulting for me at all...

...which doesn't mean I doubt that the code was indeed borked ;)

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


From steve.lhomme at free.fr  Fri Dec  5 19:43:50 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Fri, 05 Dec 2003 19:43:50 +0100
Subject: [Matroska-devel] Test
Message-ID: <3FD0D1E6.3000005@free.fr>

pls ignore...



From steve.lhomme at free.fr  Fri Dec  5 19:44:19 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Fri, 05 Dec 2003 19:44:19 +0100
Subject: [Matroska-devel] MKV menus
Message-ID: <3FD0D203.1050904@free.fr>

Well, adding menus to Matroska is not as simple as it may seem. Because
we want to have at least the capabilities of the one in DVDs, but even
more...
I think we should do a kind of survey of what people expect from their
menus. And we also have to see what part goes into the container and
what does not.
Bring on all possible ideas then we'll collect them and try to assemble
them :)







From paul at msn.com  Sat Dec  6 10:45:44 2003
From: paul at msn.com (Pamel)
Date: Sat, 6 Dec 2003 03:45:44 -0600
Subject: [Matroska-devel] Control Track
Message-ID: <bqs8g8$28l$1@sea.gmane.org>

I have mentioned the "Control Track" idea several times in the past, but I think
that in the next week I would like to make a new CC.org project devoted to it.
It won't be very big, just some simple scripting/XML specs.  I don't want it to
be tied to Matroska, but honestly I don't know what else would take it.  Perhaps
OGM, but why?

Once the specs are done then the best option is to try and get a CDL developed
for TCMP.  However, some additional APIs will need to be exposed.  For instance,
the ability for the CDL to seek to a certain position and to change the volume.
There will also be the need to be able to change the audio stream, and in the
future a video stream.  This probably means an interface with the new Matroska
compatible Morgan Stream Switcher.

There were two messages that I posted previously that I think are relevant to
this.
http://article.gmane.org/gmane.comp.multimedia.matroska.devel/149
http://article.gmane.org/gmane.comp.multimedia.matroska.devel/462

And just to clarify, this is different from the Menu spec.  Perhaps they will be
able to interface, but this is just for controlling things, not providing a menu
interface.

I'm going to be posting some ideas here soon and I would appreciate any feedback
that anyone can give.


Pamel





From paul at msn.com  Sat Dec  6 11:02:13 2003
From: paul at msn.com (Pamel)
Date: Sat, 6 Dec 2003 04:02:13 -0600
Subject: [Matroska-devel] Re: Control Track
References: <bqs8g8$28l$1@sea.gmane.org>
Message-ID: <bqs9f5$3gk$1@sea.gmane.org>

The API's that it will interface with:


1.  Audio switching
2.  Subtitle switching
3.  Video switching (Toff will make a video switcher someday...)
4.  Volume control
5.  Seeking to time.
6.  Seeking to chapters. (Maybe this isn't needed with seeking to time?)
7.  Switching to another file.  (I am nervous about this because of the
potential for abuse/virus)



Pamel





From paul at msn.com  Sat Dec  6 11:08:33 2003
From: paul at msn.com (Pamel)
Date: Sat, 6 Dec 2003 04:08:33 -0600
Subject: [Matroska-devel] Re: Control Track
References: <bqs8g8$28l$1@sea.gmane.org>
Message-ID: <bqs9r1$3tu$1@sea.gmane.org>

All of the functions in the control track are based on time, so naturally I
thought that I would store them the exact same way that subtitles are stored.

Each set of commands is stored in its own block according to the time that it
will be used.  I don't think that there is any reason to set a BlockDuration on
any of these.

In theory a command could be carried out 10ms after a previous command.  In this
case there would be two seperate blocks with timecodes 10ms apart.

Obviously lacing these would be a huge no-no.


Pamel





From paul at msn.com  Sat Dec  6 11:15:53 2003
From: paul at msn.com (Pamel)
Date: Sat, 6 Dec 2003 04:15:53 -0600
Subject: [Matroska-devel] Re: Control Track
References: <bqs8g8$28l$1@sea.gmane.org> <bqs9f5$3gk$1@sea.gmane.org>
Message-ID: <bqsa8o$4f6$1@sea.gmane.org>

"Pamel"  wrote...
> The API's that it will interface with:
> 1.  Audio switching
> 2.  Subtitle switching
> 3.  Video switching (Toff will make a video switcher someday...)

I was thinking the same set of commands could be used for switching the three
track types, but with just a little identifier.  Perhaps a <audio/> tag to
indicate that this is an audio track change?

<changetrack>
    <audio/>
    <initialtrack>3</initialtrack>
    <newtrack>4</newtrack>
</changetrack>


Pamel





From paul at msn.com  Sat Dec  6 11:30:55 2003
From: paul at msn.com (Pamel)
Date: Sat, 6 Dec 2003 04:30:55 -0600
Subject: [Matroska-devel] Re: Control Track
References: <bqs8g8$28l$1@sea.gmane.org>
Message-ID: <bqsb4u$5im$1@sea.gmane.org>

One of the ideas was that the control track could tell the player to seek
backwards to a point that has already been played.  Then the part is replayed,
but with a different setting, maybe the audio is changed or with different
subtitles or something.  There has to be a way to indicate that this is a
different run than previously.

1.  The simplest would be to have the control track to say to switch to a
different control track and seek backwards to the previous point.  The problem
with this is that if someone did some very complex seeking back and forth, you
might have 20 control tracks.  They wouldn't take up much space each, but it
would be a lot of clutter when looking at the file.

2.  The other option is to allow multiple (tracks or paths) inside of the
control track.  Say that path 1 is always the default for starting, but you
could have lots of paths in a single Block, or strewn out across several Blocks.

<path1>
    <changetrack>
        <audio/>
        <initialtrack>3</initialtrack>
        <newtrack>4</newtrack>
    </changetrack>
    <changepath>2</changepath>
</path1>

<path3>
    <seektime>33:45.257</seektime>
</path3>

In this example player would be on path1 and would change the audio track from
track 3 to track 4.  It would also change the path it is on to path2.  Path3 is
there presumably because at some point the control will be switched to path3 at
a point before it.  When it reaches this point again on path3 it would
automatically seek to the time 33:45.257.


Pamel





From alexander.noe at s2001.tu-chemnitz.de  Sat Dec  6 11:43:03 2003
From: alexander.noe at s2001.tu-chemnitz.de (=?ISO-8859-15?Q?Alexander_No=E9?=)
Date: Sat, 06 Dec 2003 11:43:03 +0100
Subject: [Matroska-devel] Re: Control Track
In-Reply-To: <bqsb4u$5im$1@sea.gmane.org>
References: <bqs8g8$28l$1@sea.gmane.org> <bqsb4u$5im$1@sea.gmane.org>
Message-ID: <3FD1B2B7.9010400@hrz.tu-chemnitz.de>

Pamel wrote:

>2.  The other option is to allow multiple (tracks or paths) inside of the
>control track.  Say that path 1 is always the default for starting, but you
>could have lots of paths in a single Block, or strewn out across several Blocks.
>
What about an interpreter language for the control track, which supports
variables, arrays, jumps, loops etc?




Alex




From chris at matroska.org  Sat Dec  6 12:33:52 2003
From: chris at matroska.org (Christian HJ Wiesner)
Date: Sat, 06 Dec 2003 12:33:52 +0100
Subject: [Matroska-devel] Control Track
In-Reply-To: <bqs8g8$28l$1@sea.gmane.org>
References: <bqs8g8$28l$1@sea.gmane.org>
Message-ID: <3FD1BEA0.7000708@matroska.org>

Pamel wrote:

>I have mentioned the "Control Track" idea several times in the past, but I think
>that in the next week I would like to make a new CC.org project devoted to it.
>It won't be very big, just some simple scripting/XML specs.  
>
Please define a way so that a control track can be used also without 
defining a specific language track for it, so that every user can use 
the same control track with his  own language

Christian



From steve.lhomme at free.fr  Sat Dec  6 14:53:12 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Sat, 06 Dec 2003 14:53:12 +0100
Subject: [Matroska-devel] KaxBlock is b0rked
In-Reply-To: <20031203163230.GT19712@bunkus.org>
References: <3FC529AE.1000002@free.fr>	<20031203161916.35833.qmail@web12905.mail.yahoo.com>	<20031203162914.GS19712@bunkus.org>
	<20031203163230.GT19712@bunkus.org>
Message-ID: <3FD1DF48.9010101@free.fr>

Moritz Bunkus wrote:

>>Well, it hasn't been segfaulting for me at all...
> 
> 
> ...which doesn't mean I doubt that the code was indeed borked ;)

I have just checked the fix and I don't understand why you use a comment 
on this code :
int64 KaxBlock::GetFrameSize(size_t FrameNumber)
{
	int64 _Result = -1;

	if (/*bValueIsSet &&*/ FrameNumber < SizeList.size())
	{
		_Result = SizeList[FrameNumber];
	}

	return _Result;
}

bValueIsSet means that the element has (never) been read or is still 
uninitialised. If you had troubles there, you were probably calling some 
code on uninitialised objects. Which means the *real* problem is 
somewhere else.



From steve.lhomme at free.fr  Sat Dec  6 15:09:22 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Sat, 06 Dec 2003 15:09:22 +0100
Subject: [Matroska-devel] Re: Control Track
In-Reply-To: <bqs9f5$3gk$1@sea.gmane.org>
References: <bqs8g8$28l$1@sea.gmane.org> <bqs9f5$3gk$1@sea.gmane.org>
Message-ID: <3FD1E312.7080903@free.fr>

Pamel wrote:

> The API's that it will interface with:
> 
> 
> 1.  Audio switching
> 2.  Subtitle switching
> 3.  Video switching (Toff will make a video switcher someday...)

OK, but each container has its own way of identifying tracks. So do you 
plan to make your API Matroska specific ? IMO we should not try to be 
too general here. After all there aren't many other containers with a 
built-in programmable/control track.

> 4.  Volume control
> 5.  Seeking to time.
> 6.  Seeking to chapters. (Maybe this isn't needed with seeking to time?)

IMO chapters are more useful for a person (editor) than time.

> 7.  Switching to another file.  (I am nervous about this because of the
> potential for abuse/virus)

As long as it's just a file to render, no real pb.



From steve.lhomme at free.fr  Sat Dec  6 15:18:29 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Sat, 06 Dec 2003 15:18:29 +0100
Subject: [Matroska-devel] Re: Control Track
In-Reply-To: <3FD1B2B7.9010400@hrz.tu-chemnitz.de>
References: <bqs8g8$28l$1@sea.gmane.org> <bqsb4u$5im$1@sea.gmane.org>
	<3FD1B2B7.9010400@hrz.tu-chemnitz.de>
Message-ID: <3FD1E535.3020705@free.fr>

Alexander No? wrote:

> Pamel wrote:
> 
>> 2.  The other option is to allow multiple (tracks or paths) inside of the
>> control track.  Say that path 1 is always the default for starting, 
>> but you
>> could have lots of paths in a single Block, or strewn out across 
>> several Blocks.
>>
> What about an interpreter language for the control track, which supports
> variables, arrays, jumps, loops etc?

I agree about the variables and some basic programming features like 
<if>, <else>, <while>... All this is getting close to the scripting in 
Flash (ActionScript). But in the case of Flash, each track (layer) have 
it's own control track.



From steve.lhomme at free.fr  Sat Dec  6 15:15:55 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Sat, 06 Dec 2003 15:15:55 +0100
Subject: [Matroska-devel] Re: Control Track
In-Reply-To: <bqsb4u$5im$1@sea.gmane.org>
References: <bqs8g8$28l$1@sea.gmane.org> <bqsb4u$5im$1@sea.gmane.org>
Message-ID: <3FD1E49B.4050400@free.fr>

Pamel wrote:

> One of the ideas was that the control track could tell the player to seek
> backwards to a point that has already been played.  Then the part is replayed,
> but with a different setting, maybe the audio is changed or with different
> subtitles or something.  There has to be a way to indicate that this is a
> different run than previously.
> 
> 1.  The simplest would be to have the control track to say to switch to a
> different control track and seek backwards to the previous point.  The problem
> with this is that if someone did some very complex seeking back and forth, you
> might have 20 control tracks.  They wouldn't take up much space each, but it
> would be a lot of clutter when looking at the file.
> 
> 2.  The other option is to allow multiple (tracks or paths) inside of the
> control track.  Say that path 1 is always the default for starting, but you
> could have lots of paths in a single Block, or strewn out across several Blocks.

That sounds like a good idea ! You should not need another track for all 
controls. Changing of control track during playback is IMO overkill and 
doesn't save anything (like a remuxing when you change a control feature).




From steve.lhomme at free.fr  Sat Dec  6 15:13:00 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Sat, 06 Dec 2003 15:13:00 +0100
Subject: [Matroska-devel] Re: Control Track
In-Reply-To: <bqs9r1$3tu$1@sea.gmane.org>
References: <bqs8g8$28l$1@sea.gmane.org> <bqs9r1$3tu$1@sea.gmane.org>
Message-ID: <3FD1E3EC.6070807@free.fr>

Pamel wrote:

> All of the functions in the control track are based on time, so naturally I
> thought that I would store them the exact same way that subtitles are stored.
> 
> Each set of commands is stored in its own block according to the time that it
> will be used.  I don't think that there is any reason to set a BlockDuration on
> any of these.
> 
> In theory a command could be carried out 10ms after a previous command.  In this
> case there would be two seperate blocks with timecodes 10ms apart.
> 
> Obviously lacing these would be a huge no-no.

BTW, if you use chapter points to seek you don't need to know whether a 
time is relative or absolute. Wherever you move the chapter you don't 
need to reencode the whole track. So IMO you should at least have the 
option of chapters referencing. If you really need access to time, why 
not (too).



From paul at msn.com  Sat Dec  6 19:32:01 2003
From: paul at msn.com (Pamel)
Date: Sat, 6 Dec 2003 12:32:01 -0600
Subject: [Matroska-devel] Re: Re: Control Track
References: <bqs8g8$28l$1@sea.gmane.org> <bqs9f5$3gk$1@sea.gmane.org>
	<3FD1E312.7080903@free.fr>
Message-ID: <bqt7av$i1c$1@sea.gmane.org>

"Steve Lhomme" wrote...
> Pamel wrote:
> > The API's that it will interface with:
> >
> > 1.  Audio switching
> > 2.  Subtitle switching
> > 3.  Video switching (Toff will make a video switcher someday...)
>
> OK, but each container has its own way of identifying tracks. So do you
> plan to make your API Matroska specific ? IMO we should not try to be
> too general here. After all there aren't many other containers with a
> built-in programmable/control track.

I figured on just using the track number.  That should be perfectly usable for
Matroska, but also general enough to be adaptable to other containers.  Is there
any issue with just using a track number?

> > 4.  Volume control
> > 5.  Seeking to time.
> > 6.  Seeking to chapters. (Maybe this isn't needed with seeking to time?)
>
> IMO chapters are more useful for a person (editor) than time.

Well, you don't want to have to force a chapter at every seek point, but I see
what you mean.

> > 7.  Switching to another file.  (I am nervous about this because of the
> > potential for abuse/virus)
>
> As long as it's just a file to render, no real pb.

What if it tries to open an EXE and a crummy player runs it?  I don't know, I
guess it would be the users fault for using a crummy player?


Pamel





From paul at msn.com  Sat Dec  6 19:46:14 2003
From: paul at msn.com (Pamel)
Date: Sat, 6 Dec 2003 12:46:14 -0600
Subject: [Matroska-devel] Re: Re: Control Track
References: <bqs8g8$28l$1@sea.gmane.org>
	<bqsb4u$5im$1@sea.gmane.org><3FD1B2B7.9010400@hrz.tu-chemnitz.de>
	<3FD1E535.3020705@free.fr>
Message-ID: <bqt85k$jce$1@sea.gmane.org>

"Steve Lhomme" wrote...
> Alexander No? wrote:
> > What about an interpreter language for the control track, which supports
> > variables, arrays, jumps, loops etc?
>
> I agree about the variables and some basic programming features like
> <if>, <else>, <while>...

I like the idea, but adding branching to the abilities greatly increases the
complexity of the interpreter.  Someone has to code it, and unless someone is
volunteering, then perhaps simpler is better.

One other point is that I was planning on just using a simple XML-type file to
do everything.  If branching is added, what type of format should I use?  C++?
Writing a JIT compiler for something like that doesn't sound fun....

> All this is getting close to the scripting in
> Flash (ActionScript). But in the case of Flash, each track (layer) have
> it's own control track.

ActionScript is much more complex than I was hoping to go.  It may be useful to
the menu system though.  I guess it depends on the type of licensing required by
Macromedia.  Is it free?

Having a control track for each media track sounds like fun, but its not
terribly useful to us since DShow synchs between all played tracks.


Pamel





From rbultje at ronald.bitfreak.net  Sat Dec  6 21:11:07 2003
From: rbultje at ronald.bitfreak.net (Ronald Bultje)
Date: Sat, 06 Dec 2003 21:11:07 +0100
Subject: [Matroska-devel] Re: Re: Control Track
In-Reply-To: <bqt85k$jce$1@sea.gmane.org>
References: <bqs8g8$28l$1@sea.gmane.org> <bqsb4u$5im$1@sea.gmane.org>
	<3FD1B2B7.9010400@hrz.tu-chemnitz.de> <3FD1E535.3020705@free.fr>
	<bqt85k$jce$1@sea.gmane.org>
Message-ID: <1070741466.28526.22.camel@shrek.bitfreak.net>

On Sat, 2003-12-06 at 19:46, Pamel wrote:
> Having a control track for each media track sounds like fun, but its not
> terribly useful to us since DShow synchs between all played tracks.

I hope you're looking beyond just DShow?

Ronald

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



From paul at msn.com  Sat Dec  6 22:23:10 2003
From: paul at msn.com (Pamel)
Date: Sat, 6 Dec 2003 15:23:10 -0600
Subject: [Matroska-devel] Re: Re: Re: Control Track
References: <bqs8g8$28l$1@sea.gmane.org>
	<bqsb4u$5im$1@sea.gmane.org><3FD1B2B7.9010400@hrz.tu-chemnitz.de>
	<3FD1E535.3020705@free.fr><bqt85k$jce$1@sea.gmane.org>
	<1070741466.28526.22.camel@shrek.bitfreak.net>
Message-ID: <bqthbr$4p8$1@sea.gmane.org>

"Ronald Bultje" wrote...
> On Sat, 2003-12-06 at 19:46, Pamel wrote:
> > Having a control track for each media track sounds like fun, but its not
> > terribly useful to us since DShow synchs between all played tracks.
>
> I hope you're looking beyond just DShow?

Yes, of course.  Does GStreamer allow you to seek the audio independently from
the video?


Pamel





From rbultje at ronald.bitfreak.net  Sat Dec  6 23:50:22 2003
From: rbultje at ronald.bitfreak.net (Ronald Bultje)
Date: Sat, 06 Dec 2003 23:50:22 +0100
Subject: [Matroska-devel] Re: Re: Re: Control Track
In-Reply-To: <bqthbr$4p8$1@sea.gmane.org>
References: <bqs8g8$28l$1@sea.gmane.org> <bqsb4u$5im$1@sea.gmane.org>
	<3FD1B2B7.9010400@hrz.tu-chemnitz.de> <3FD1E535.3020705@free.fr>
	<bqt85k$jce$1@sea.gmane.org>
	<1070741466.28526.22.camel@shrek.bitfreak.net>
	<bqthbr$4p8$1@sea.gmane.org>
Message-ID: <1070751022.28526.31.camel@shrek.bitfreak.net>

On Sat, 2003-12-06 at 22:23, Pamel wrote:
> "Ronald Bultje" wrote...
> > On Sat, 2003-12-06 at 19:46, Pamel wrote:
> > > Having a control track for each media track sounds like fun, but its not
> > > terribly useful to us since DShow synchs between all played tracks.
> >
> > I hope you're looking beyond just DShow?
> 
> Yes, of course.  Does GStreamer allow you to seek the audio independently from
> the video?

A plugin can be programmed to work that way. A plugin can also be
programmed to seek into a stream with synced A/V. So it all depends on
the plugin.

The matroska plugin seeks synced, if you were wondering. ;).

Ronald

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



From paul at msn.com  Sun Dec  7 02:38:20 2003
From: paul at msn.com (Pamel)
Date: Sat, 6 Dec 2003 19:38:20 -0600
Subject: [Matroska-devel] Re: Control Track
References: <bqs8g8$28l$1@sea.gmane.org>
Message-ID: <bqu0a9$en3$1@sea.gmane.org>

A possible syntax of the control track.

track[var].function

if(x == 1)
{
    track[1].enable(0);
    track[2].enable(1);
    track[2].seekToTime(25:42.980);
}

This would execute the commands if "x" equals 1.  It would turn off track 1 and
turn on track 2, effectively switching tracks.  Then it would seek to the time
25:42.980.


Pamel





From suiryc at yahoo.com  Sun Dec  7 16:15:59 2003
From: suiryc at yahoo.com (Cyrius)
Date: Sun, 7 Dec 2003 07:15:59 -0800 (PST)
Subject: [Matroska-devel] KaxBlock is b0rked
In-Reply-To: <3FD1DF48.9010101@free.fr>
Message-ID: <20031207151559.51730.qmail@web12904.mail.yahoo.com>


--- Steve Lhomme <steve.lhomme at free.fr> wrote:
> I have just checked the fix and I don't understand
> why you use a comment 
> on this code :
> int64 KaxBlock::GetFrameSize(size_t FrameNumber)
> {
> 	int64 _Result = -1;
> 
> 	if (/*bValueIsSet &&*/ FrameNumber <
> SizeList.size())
> 	{
> 		_Result = SizeList[FrameNumber];
> 	}
> 
> 	return _Result;
> }
> 
> bValueIsSet means that the element has (never) been
> read or is still 
> uninitialised. If you had troubles there, you were
> probably calling some 
> code on uninitialised objects. Which means the
> *real* problem is 
> somewhere else.

As you can see your code wanna get a value inside
SizeList, which is filled when reading fully or
partially the KaxBlock.
But bValueIsSet is set to true _only_ when reading
fully (I dunno what is the meaning of bValueIsSet, if
it's to tell whether the data were read or not - as it
seems to be in this case - then it's normal it's set
to false when reading partially since only the size of
the frames are read; otherwise you should set it to
true when reading partially too).
So when reading partially the GetFrameSize function
would always return -1, which is the contrary of what
it should do (this function was indeed especially
added for when reading partially, since when reading
fully you can still use - if you want - the list of
DataBuffer - or whatever may be its name).

The second (remaining) condition in the test anyways
ensure that there are enough elements in the SizeList
(so when you don't read anything in the KaxBlock the
function returns -1 as expected).

__________________________________
Do you Yahoo!?
New Yahoo! Photos - easier uploading and sharing.
http://photos.yahoo.com/


From steve.lhomme at free.fr  Sun Dec  7 18:24:08 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Sun, 07 Dec 2003 18:24:08 +0100
Subject: [Matroska-devel] KaxBlock is b0rked
In-Reply-To: <20031207151559.51730.qmail@web12904.mail.yahoo.com>
References: <20031207151559.51730.qmail@web12904.mail.yahoo.com>
Message-ID: <3FD36238.1090809@free.fr>

Cyrius wrote:
> As you can see your code wanna get a value inside
> SizeList, which is filled when reading fully or
> partially the KaxBlock.
> But bValueIsSet is set to true _only_ when reading
> fully (I dunno what is the meaning of bValueIsSet, if
> it's to tell whether the data were read or not - as it
> seems to be in this case - then it's normal it's set
> to false when reading partially since only the size of
> the frames are read; otherwise you should set it to
> true when reading partially too).
> So when reading partially the GetFrameSize function
> would always return -1, which is the contrary of what
> it should do (this function was indeed especially
> added for when reading partially, since when reading
> fully you can still use - if you want - the list of
> DataBuffer - or whatever may be its name).

OK, that sounds good to me :)



From steve.lhomme at free.fr  Sun Dec  7 19:03:05 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Sun, 07 Dec 2003 19:03:05 +0100
Subject: [Matroska-devel] Re: Re: Control Track
In-Reply-To: <bqt7av$i1c$1@sea.gmane.org>
References: <bqs8g8$28l$1@sea.gmane.org>
	<bqs9f5$3gk$1@sea.gmane.org>	<3FD1E312.7080903@free.fr>
	<bqt7av$i1c$1@sea.gmane.org>
Message-ID: <3FD36B59.5030206@free.fr>

Pamel wrote:

> I figured on just using the track number.  That should be perfectly usable for
> Matroska, but also general enough to be adaptable to other containers.  Is there
> any issue with just using a track number?

No, most container should have numbers... Maybe for Matroska the track 
UID should be used instead of the track number. Because it was added to 
really identify the track.

>>>7.  Switching to another file.  (I am nervous about this because of the
>>>potential for abuse/virus)
>>
>>As long as it's just a file to render, no real pb.
> 
> 
> What if it tries to open an EXE and a crummy player runs it?  I don't know, I
> guess it would be the users fault for using a crummy player?

An unsecure player, yes.



From steve.lhomme at free.fr  Sun Dec  7 19:08:47 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Sun, 07 Dec 2003 19:08:47 +0100
Subject: [Matroska-devel] Re: Re: Control Track
In-Reply-To: <bqt85k$jce$1@sea.gmane.org>
References: <bqs8g8$28l$1@sea.gmane.org>	<bqsb4u$5im$1@sea.gmane.org><3FD1B2B7.9010400@hrz.tu-chemnitz.de>	<3FD1E535.3020705@free.fr>
	<bqt85k$jce$1@sea.gmane.org>
Message-ID: <3FD36CAF.1040808@free.fr>

Pamel wrote:

> "Steve Lhomme" wrote...
> 
>>Alexander No? wrote:
>>
>>>What about an interpreter language for the control track, which supports
>>>variables, arrays, jumps, loops etc?
>>
>>I agree about the variables and some basic programming features like
>><if>, <else>, <while>...
> 
> 
> I like the idea, but adding branching to the abilities greatly increases the
> complexity of the interpreter.  Someone has to code it, and unless someone is
> volunteering, then perhaps simpler is better.
> 
> One other point is that I was planning on just using a simple XML-type file to
> do everything.  If branching is added, what type of format should I use?  C++?
> Writing a JIT compiler for something like that doesn't sound fun....

It's no so complicated to do. The XML data have to be interpreted 
anyway... And for the syntax I think what I put above is enough. But of 
course it's more complicated than having nothing. If you go the XML way 
you can start with something basic without variables/loops and they will 
be added later (will be needed at some points).




From jcsston at wiesneronline.net  Mon Dec  8 06:44:26 2003
From: jcsston at wiesneronline.net (Jory)
Date: Sun, 7 Dec 2003 23:44:26 -0600
Subject: [Matroska-devel] New Simple Matroska Tag System Proposal
Message-ID: <000b01c3bd4e$90c404d0$0200a8c0@jcsston>

Hi,

IMHO Currently the Matroska Tag system is much too complex.

In terms of lib size.
1,422,760 bytes for all .obj files compiled with VC7.0
454,387 bytes just for .obj files of the tag system or 32% of the total lib
size.

In term of implementation size.
In the Matroska Shell Ext, the code handling the tag display & r/w alone is
more than all the other features.

Have simple name & value pairs. Similar to Ogg comments and APEv2. I think
those would stand a better chance for being commonly used because the amount
of code needed for ogg style comments is laughable compared to the current
Matroska tag system

EBML Tree
Tags
-Tag
-- Targets
  --- Track UID
  --- Chapter UID
  --- Attachment UID
  --- ...
-- Simple Tag
  --- Name - ASCII String
  --- String Value - UTF-8 String
  --- Binary Value - Binary Data


What do you think?,
Jory







From paul at msn.com  Mon Dec  8 07:17:55 2003
From: paul at msn.com (Pamel)
Date: Mon, 8 Dec 2003 00:17:55 -0600
Subject: [Matroska-devel] Re: New Simple Matroska Tag System Proposal
References: <000b01c3bd4e$90c404d0$0200a8c0@jcsston>
Message-ID: <br1527$msf$1@sea.gmane.org>

"Jory" wrote...
> IMHO Currently the Matroska Tag system is much too complex.

This has been commented several times by different people.

> In terms of lib size.
> 1,422,760 bytes for all .obj files compiled with VC7.0
> 454,387 bytes just for .obj files of the tag system or 32% of the total lib
> size.
>
> In term of implementation size.
> In the Matroska Shell Ext, the code handling the tag display & r/w alone is
> more than all the other features.

I think that the complexity of the tagging system is inhibiting it from being
widely used.  Having simpler code to accomplish it would undoubtedly help.

> Have simple name & value pairs. Similar to Ogg comments and APEv2. I think
> those would stand a better chance for being commonly used because the amount
> of code needed for ogg style comments is laughable compared to the current
> Matroska tag system

Okay, in general I dislike the Ogg comments system.  I won't discourse on the
details now, but it is certainly agains the EBML idea used everywhere else.
But, its simplicity is overwhelming in that even I could write a program to make
Ogg comments.

ofstream tags; tags("tags.txt"); tags<<"NAME=VALUE"<<endl;

Voila.  Simplicity is certainly a key, but this is not flexible enough.

> EBML Tree
> Tags
> -Tag
> -- Targets
>   --- Track UID
>   --- Chapter UID
>   --- Attachment UID
>   --- ...
> -- Simple Tag
>   --- Name - ASCII String
>   --- String Value - UTF-8 String
>   --- Binary Value - Binary Data

I think that there should be an INT and FLOAT element as well as the String and
Binary.

> What do you think?,

Getting it done could be pretty fast if the current Element Names were used for
the "Name" and the Types for the String/Binary/Whatever.  If you wanted you
could keep stuff like the MultiEntity URL by using something like "Composer.URL"
for the "Name".  You wouldn't be able to group it with the actual composer if
there were multiple ones like the current system, but whatever.

If everyone wants to simplify the Tags, then it will make it less flexible, but
it will make it MUCH more easy to implement.  I would be hard pressed to say for
sure which is better.


Pamel





From paul at msn.com  Mon Dec  8 07:30:03 2003
From: paul at msn.com (Pamel)
Date: Mon, 8 Dec 2003 00:30:03 -0600
Subject: [Matroska-devel] Re: New Simple Matroska Tag System Proposal
References: <000b01c3bd4e$90c404d0$0200a8c0@jcsston>
	<br1527$msf$1@sea.gmane.org>
Message-ID: <br15p0$no4$1@sea.gmane.org>

I forgot to mention that this would not affect any of the current info in files
concerning Track names and languages.

I have not seen any serious use of the current tagging system so changing it now
should not have any widespread effect.


Pamel





From steve.lhomme at free.fr  Mon Dec  8 09:35:19 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Mon, 08 Dec 2003 09:35:19 +0100
Subject: [Matroska-devel] Re: New Simple Matroska Tag System Proposal
In-Reply-To: <br15p0$no4$1@sea.gmane.org>
References: <000b01c3bd4e$90c404d0$0200a8c0@jcsston>	<br1527$msf$1@sea.gmane.org>
	<br15p0$no4$1@sea.gmane.org>
Message-ID: <3FD437C7.7040101@free.fr>

Pamel wrote:
> I forgot to mention that this would not affect any of the current info in files
> concerning Track names and languages.
> 
> I have not seen any serious use of the current tagging system so changing it now
> should not have any widespread effect.

That must be a joke. Someone claims it's too big and take 1/3 of the 
code and another claims noone uses it...

Anyway I made my best when we decided for the tag system NOT to have a 
"key=value" system that would lead to incompatibilities between 
softwares/use. And I still think it's the way to go unless someone can 
convince me that 200 keys is better than 200 EBML IDs.



From rbultje at ronald.bitfreak.net  Mon Dec  8 10:06:23 2003
From: rbultje at ronald.bitfreak.net (Ronald Bultje)
Date: Mon, 08 Dec 2003 10:06:23 +0100
Subject: [Matroska-devel] Re: New Simple Matroska Tag System Proposal
In-Reply-To: <br1527$msf$1@sea.gmane.org>
References: <000b01c3bd4e$90c404d0$0200a8c0@jcsston>
	<br1527$msf$1@sea.gmane.org>
Message-ID: <1070874382.28529.65.camel@shrek.bitfreak.net>

Hi,

woohoo, finally someone hit the red button. Thank you, Jory.

On Mon, 2003-12-08 at 07:17, Pamel wrote:
> I think that there should be an INT and FLOAT element as well as the String and
> Binary.

Why? Tagging is generally intended for display only. The tagging has no
actual use whatsoever apart from pure joy and excitement. Any other type
than a string (i.e. UTF8 element) is wrong in this respect. Only a
string assures me that I will get exactly that string displayed that I
intended to be displayed when I wrote the tag. Anything non-string in a
tag is (imho) bloat. In the end, it becomes a string anyway. And if you
want to do anything else than displaying it (that's what you indicate by
not making it a string), you shouldn't make it a tag but something else
(in KaxInfo or so).

> > What do you think?,

The complexity is my single most important reason for not having
implemented it yet in my GStreamer C (de)muxer. If there was a simple
way to do this, I would add support right away. I fully support Jory's
complaints about the current tags (I've mentioned some of them too in
the past) and favour any simplification. :). Even if it's compatible to
the current, but a simple standardized subset or so.
I mean, I really don't care about the email address of the third-in-row
director of movie X or the home address of the second camera man of
movie Y. And nobody with common sense is going to use those.

Ronald

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



From steve.lhomme at free.fr  Mon Dec  8 13:38:40 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Mon, 08 Dec 2003 13:38:40 +0100
Subject: [Matroska-devel] Re: New Simple Matroska Tag System Proposal
In-Reply-To: <1070874382.28529.65.camel@shrek.bitfreak.net>
References: <000b01c3bd4e$90c404d0$0200a8c0@jcsston>	<br1527$msf$1@sea.gmane.org>
	<1070874382.28529.65.camel@shrek.bitfreak.net>
Message-ID: <3FD470D0.7010301@free.fr>

Ronald Bultje wrote:

> Why? Tagging is generally intended for display only. The tagging has no
> actual use whatsoever apart from pure joy and excitement. Any other type
> than a string (i.e. UTF8 element) is wrong in this respect. Only a
> string assures me that I will get exactly that string displayed that I
> intended to be displayed when I wrote the tag. Anything non-string in a
> tag is (imho) bloat. In the end, it becomes a string anyway. And if you
> want to do anything else than displaying it (that's what you indicate by
> not making it a string), you shouldn't make it a tag but something else
> (in KaxInfo or so).

What about a database of files containing the tags for each file ? You 
think database only deal with strings just because at one point it's 
displayed ?

> The complexity is my single most important reason for not having
> implemented it yet in my GStreamer C (de)muxer. If there was a simple
> way to do this, I would add support right away. I fully support Jory's
> complaints about the current tags (I've mentioned some of them too in
> the past) and favour any simplification. :). Even if it's compatible to

You know the EBML concept, you know you don't have to support ALL tags 
under the sun. If you don't want to support all of them because you 
don't like some of them is another story.



From steve.lhomme at free.fr  Mon Dec  8 13:39:45 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Mon, 08 Dec 2003 13:39:45 +0100
Subject: [Matroska-devel] Re: New Simple Matroska Tag System Proposal
In-Reply-To: <1070874382.28529.65.camel@shrek.bitfreak.net>
References: <000b01c3bd4e$90c404d0$0200a8c0@jcsston>	<br1527$msf$1@sea.gmane.org>
	<1070874382.28529.65.camel@shrek.bitfreak.net>
Message-ID: <3FD47111.9080202@free.fr>

Ronald Bultje wrote:
> I mean, I really don't care about the email address of the third-in-row
> director of movie X or the home address of the second camera man of
> movie Y. And nobody with common sense is going to use those.

We don't have this tag IIRC... But you will if you want to go the 
"key=value" way ! Someone will add it at some point and will complain 
noone cares about it.



From rbultje at ronald.bitfreak.net  Mon Dec  8 13:58:32 2003
From: rbultje at ronald.bitfreak.net (Ronald Bultje)
Date: Mon, 08 Dec 2003 13:58:32 +0100
Subject: [Matroska-devel] Re: New Simple Matroska Tag System Proposal
In-Reply-To: <3FD470D0.7010301@free.fr>
References: <000b01c3bd4e$90c404d0$0200a8c0@jcsston>
	<br1527$msf$1@sea.gmane.org>
	<1070874382.28529.65.camel@shrek.bitfreak.net>
	<3FD470D0.7010301@free.fr>
Message-ID: <1070888312.22908.89.camel@shrek.bitfreak.net>

On Mon, 2003-12-08 at 13:38, Steve Lhomme wrote:
> You know the EBML concept, you know you don't have to support ALL tags 
> under the sun. If you don't want to support all of them because you 
> don't like some of them is another story.

It would be a good idea if there was a very small standardized subset
that was documented to be often used and ought to be supported by
players. That'd give me a simple start for deciding on which tags to
support and which not.

I know I don't have to support each and any. I wasn't planning on that
either. ;).

Ronald

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



From paul at msn.com  Mon Dec  8 14:50:46 2003
From: paul at msn.com (Pamel)
Date: Mon, 8 Dec 2003 07:50:46 -0600
Subject: [Matroska-devel] Re: Re: New Simple Matroska Tag System Proposal
References: <000b01c3bd4e$90c404d0$0200a8c0@jcsston><br1527$msf$1@sea.gmane.org><1070874382.28529.65.camel@shrek.bitfreak.net><3FD470D0.7010301@free.fr>
	<1070888312.22908.89.camel@shrek.bitfreak.net>
Message-ID: <br1vjb$3v5$1@sea.gmane.org>

"Ronald Bultje" wrote...
> On Mon, 2003-12-08 at 13:38, Steve Lhomme wrote:
> > You know the EBML concept, you know you don't have to support ALL tags
> > under the sun. If you don't want to support all of them because you
> > don't like some of them is another story.

I didn't get this email...


Pamel





From jcsston at wiesneronline.net  Mon Dec  8 16:49:40 2003
From: jcsston at wiesneronline.net (Jory)
Date: Mon, 8 Dec 2003 09:49:40 -0600
Subject: [Matroska-devel] Re: New Simple Matroska Tag System Proposal
References: <000b01c3bd4e$90c404d0$0200a8c0@jcsston>	<br1527$msf$1@sea.gmane.org><1070874382.28529.65.camel@shrek.bitfreak.net>
	<3FD47111.9080202@free.fr>
Message-ID: <002801c3bda3$9e235360$0200a8c0@jcsston>

----- Original Message -----
From: "Steve Lhomme" <steve.lhomme at free.fr>
To: "Discussion about the current and future development of Matroska"
<matroska-devel at lists.matroska.org>
Sent: Monday, December 08, 2003 2:35 AM
Subject: Re: [Matroska-devel] Re: New Simple Matroska Tag System Proposal


> Pamel wrote:
> > I forgot to mention that this would not affect any of the current info
in files
> > concerning Track names and languages.
> >
> > I have not seen any serious use of the current tagging system so
changing it now
> > should not have any widespread effect.
>
> That must be a joke. Someone claims it's too big and take 1/3 of the
> code and another claims noone uses it...
>
> Anyway I made my best when we decided for the tag system NOT to have a
> "key=value" system that would lead to incompatibilities between
> softwares/use. And I still think it's the way to go unless someone can
> convince me that 200 keys is better than 200 EBML IDs.

The keys are human-readable and can be displayed directly to the user. While
I doubt anyone could make sense of a EBML ID.

----- Original Message -----
From: "Steve Lhomme" <steve.lhomme at free.fr>
To: "Discussion about the current and future development of Matroska"
<matroska-devel at lists.matroska.org>
Sent: Monday, December 08, 2003 6:39 AM
Subject: Re: [Matroska-devel] Re: New Simple Matroska Tag System Proposal


> Ronald Bultje wrote:
> > I mean, I really don't care about the email address of the third-in-row
> > director of movie X or the home address of the second camera man of
> > movie Y. And nobody with common sense is going to use those.
>
> We don't have this tag IIRC... But you will if you want to go the
> "key=value" way ! Someone will add it at some point and will complain
> noone cares about it.
>

If we went the key=value way it wouldn't matter what the user added. Because
it would require no more code to support 1000 keys than 100 keys (if
properly implemented).



Jory




From unmei at matroska.org  Mon Dec  8 16:45:04 2003
From: unmei at matroska.org (unmei)
Date: Mon, 08 Dec 2003 16:45:04 +0100
Subject: [Matroska-devel] Re: New Simple Matroska Tag System Proposal
In-Reply-To: <1070888312.22908.89.camel@shrek.bitfreak.net>
References: <000b01c3bd4e$90c404d0$0200a8c0@jcsston>	<br1527$msf$1@sea.gmane.org>	<1070874382.28529.65.camel@shrek.bitfreak.net>	<3FD470D0.7010301@free.fr>
	<1070888312.22908.89.camel@shrek.bitfreak.net>
Message-ID: <br26a2$j1l$1@sea.gmane.org>

Ronald Bultje wrote:
> It would be a good idea if there was a very small standardized subset
> that was documented to be often used and ought to be supported by
> players. That'd give me a simple start for deciding on which tags to
> support and which not.

fansubbers often fill in the avi INFO fields INAM,IART,ICOP,ISUBJ,ISFT 
as supported by ND/VD(M) ..i think making the matroska equivalents 
easily accessible, ie like title in mkvmerge now, would definitely be 
appreciated by many.




From paul at msn.com  Mon Dec  8 17:19:31 2003
From: paul at msn.com (Pamel)
Date: Mon, 8 Dec 2003 10:19:31 -0600
Subject: [Matroska-devel] Re: Re: New Simple Matroska Tag System Proposal
References: <000b01c3bd4e$90c404d0$0200a8c0@jcsston>	<br1527$msf$1@sea.gmane.org><1070874382.28529.65.camel@shrek.bitfreak.net><3FD47111.9080202@free.fr>
	<002801c3bda3$9e235360$0200a8c0@jcsston>
Message-ID: <br28a5$npk$1@sea.gmane.org>

"Jory" <jcsston at wiesneronline.net> wrote in message
news:002801c3bda3$9e235360$0200a8c0 at jcsston...
> If we went the key=value way it wouldn't matter what the user added. Because
> it would require no more code to support 1000 keys than 100 keys (if
> properly implemented).

For reading back code that is.

For writing code you want to have a standard file that all programmers can use
so you don't have people using all sorts of varying spelling and capitalization.
That would create all sorts of compatibility issues, which is the biggest main
concern?  You NEED to make sure that everyone uses the exact same strings for
the "Name" field if you use it.


Pamel





From paul at msn.com  Mon Dec  8 17:37:11 2003
From: paul at msn.com (Pamel)
Date: Mon, 8 Dec 2003 10:37:11 -0600
Subject: [Matroska-devel] Re: Re: New Simple Matroska Tag System Proposal
References: <000b01c3bd4e$90c404d0$0200a8c0@jcsston>	<br1527$msf$1@sea.gmane.org><1070874382.28529.65.camel@shrek.bitfreak.net>
	<3FD47111.9080202@free.fr>
Message-ID: <br29b8$q7s$1@sea.gmane.org>

"Steve Lhomme" wrote...
> We don't have this tag IIRC... But you will if you want to go the
> "key=value" way ! Someone will add it at some point and will complain
> noone cares about it.

Conversation from April:

Steve:
"At one point we have to stop. Maybe that's where a more generic system comes.
With "TAG_NAME" = "TAG_VALUE". Anyone can add whatever and we keep a list of
"possible" ones, but not endorsed as standard."

Paul:
"*shudder*  That's what Ogg uses.  Just look at the lack of compatibility that
created.  The few people that try to use it don't even follow the
recommendations OR the specs.  I'll just leave in the "Involved people list" tag
from ID3 in the EntityName element.  People should be able to use that
and use the Comments element under the MultiEntity to describe the obscure
job/shirt color of the person named."

Steve:
"I know this is also want I wanted to avoid as a "general" system. These tags
are not endorsed as part of the specs. But allow a kind of "easy" compatibility.
They should mostly be used for application specific tags (like a database stored
in matroska ;)."

http://article.gmane.org/gmane.comp.multimedia.matroska.devel/552
http://article.gmane.org/gmane.comp.multimedia.matroska.devel/559
http://article.gmane.org/gmane.comp.multimedia.matroska.devel/560

I stand by what I said before.  But I do recognize that it is inhibiting getting
the tags used.  I think it may turn in to a battle of, should the getting the
tags accepted with compatibility issues or having them be compatible, but no one
uses them.


Pamel





From steve.lhomme at free.fr  Mon Dec  8 21:02:57 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Mon, 08 Dec 2003 21:02:57 +0100
Subject: [Matroska-devel] Re: New Simple Matroska Tag System Proposal
In-Reply-To: <002801c3bda3$9e235360$0200a8c0@jcsston>
References: <000b01c3bd4e$90c404d0$0200a8c0@jcsston>	<br1527$msf$1@sea.gmane.org><1070874382.28529.65.camel@shrek.bitfreak.net>	<3FD47111.9080202@free.fr>
	<002801c3bda3$9e235360$0200a8c0@jcsston>
Message-ID: <3FD4D8F1.2060108@free.fr>

Jory wrote:
>>That must be a joke. Someone claims it's too big and take 1/3 of the
>>code and another claims noone uses it...
>>
>>Anyway I made my best when we decided for the tag system NOT to have a
>>"key=value" system that would lead to incompatibilities between
>>softwares/use. And I still think it's the way to go unless someone can
>>convince me that 200 keys is better than 200 EBML IDs.
> 
> 
> The keys are human-readable and can be displayed directly to the user. While
> I doubt anyone could make sense of a EBML ID.

OK, Unicode strings can quickly get unreadable, and I'm sure you don't 
want ASCII strings in your key/value pair. And as there is a separation 
for the string, I guess there must be some Escape character at some 
point which will also make some characters unreadable. And in the end 
noone is reading a movie or audio file in an hexa editor.

> If we went the key=value way it wouldn't matter what the user added. Because
> it would require no more code to support 1000 keys than 100 keys (if
> properly implemented).

Mmm, so you don't want hierarchy/groups ? 1000 keys all at the same 
level, that sounds bad too me. And even some things (like the same kind 
of info at different level) are impossible.



From alexander.noe at s2001.tu-chemnitz.de  Mon Dec  8 21:37:52 2003
From: alexander.noe at s2001.tu-chemnitz.de (=?ISO-8859-1?Q?Alexander_No=E9?=)
Date: Mon, 08 Dec 2003 21:37:52 +0100
Subject: [Matroska-devel] Re: New Simple Matroska Tag System Proposal
In-Reply-To: <3FD4D8F1.2060108@free.fr>
References: <000b01c3bd4e$90c404d0$0200a8c0@jcsston>	<br1527$msf$1@sea.gmane.org><1070874382.28529.65.camel@shrek.bitfreak.net>	<3FD47111.9080202@free.fr>	<002801c3bda3$9e235360$0200a8c0@jcsston>
	<3FD4D8F1.2060108@free.fr>
Message-ID: <3FD4E120.30300@hrz.tu-chemnitz.de>

Steve Lhomme wrote:

> OK, Unicode strings can quickly get unreadable

They get just as unreadable as unicode track names and unicode segment 
titles under pseudo
OSes like win 9x/me...



Alex




From steve.lhomme at free.fr  Mon Dec  8 21:46:00 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Mon, 08 Dec 2003 21:46:00 +0100
Subject: [Matroska-devel] Re: New Simple Matroska Tag System Proposal
In-Reply-To: <3FD4E120.30300@hrz.tu-chemnitz.de>
References: <000b01c3bd4e$90c404d0$0200a8c0@jcsston>	<br1527$msf$1@sea.gmane.org><1070874382.28529.65.camel@shrek.bitfreak.net>	<3FD47111.9080202@free.fr>	<002801c3bda3$9e235360$0200a8c0@jcsston>	<3FD4D8F1.2060108@free.fr>
	<3FD4E120.30300@hrz.tu-chemnitz.de>
Message-ID: <3FD4E308.80908@free.fr>

Alexander No? wrote:

> Steve Lhomme wrote:
> 
>> OK, Unicode strings can quickly get unreadable
> 
> 
> They get just as unreadable as unicode track names and unicode segment 
> titles under pseudo
> OSes like win 9x/me...

Which doesn't mean Unicode is not the way to go.



From unmei at matroska.org  Mon Dec  8 22:10:49 2003
From: unmei at matroska.org (unmei)
Date: Mon, 08 Dec 2003 22:10:49 +0100
Subject: [Matroska-devel] Re: New Simple Matroska Tag System Proposal
In-Reply-To: <3FD4E308.80908@free.fr>
References: <000b01c3bd4e$90c404d0$0200a8c0@jcsston>	<br1527$msf$1@sea.gmane.org><1070874382.28529.65.camel@shrek.bitfreak.net>	<3FD47111.9080202@free.fr>	<002801c3bda3$9e235360$0200a8c0@jcsston>	<3FD4D8F1.2060108@free.fr>	<3FD4E120.30300@hrz.tu-chemnitz.de>
	<3FD4E308.80908@free.fr>
Message-ID: <3FD4E8D9.2090109@matroska.org>

OK, Unicode strings can quickly get unreadable

>>
>>
>> They get just as unreadable as unicode track names and unicode 
>> segment titles under pseudo
>> OSes like win 9x/me...
>
>
> Which doesn't mean Unicode is not the way to go.
>
IF/AS you already have unicode track names, seg titles (and subtitles), 
it would be irritating NOT to use unicode for tags (and people sure want 
accents,umlauts,kanji whatever in tags)



From alexander.noe at s2001.tu-chemnitz.de  Mon Dec  8 22:18:47 2003
From: alexander.noe at s2001.tu-chemnitz.de (=?ISO-8859-1?Q?Alexander_No=E9?=)
Date: Mon, 08 Dec 2003 22:18:47 +0100
Subject: [Matroska-devel] Re: New Simple Matroska Tag System Proposal
In-Reply-To: <3FD4E8D9.2090109@matroska.org>
References: <000b01c3bd4e$90c404d0$0200a8c0@jcsston>	<br1527$msf$1@sea.gmane.org><1070874382.28529.65.camel@shrek.bitfreak.net>	<3FD47111.9080202@free.fr>	<002801c3bda3$9e235360$0200a8c0@jcsston>	<3FD4D8F1.2060108@free.fr>	<3FD4E120.30300@hrz.tu-chemnitz.de>	<3FD4E308.80908@free.fr>
	<3FD4E8D9.2090109@matroska.org>
Message-ID: <3FD4EAB7.2030203@hrz.tu-chemnitz.de>

unmei wrote:

> IF/AS you already have unicode track names, seg titles (and 
> subtitles), it would be irritating NOT to use unicode for tags (and 
> people sure want accents,umlauts,kanji whatever in tags) 

Or just plain, simple ???????, for which there is no (working) way to 
write it in ASCII, if
you don't want to b0rk around with charsets.



Alex




From alexander.noe at s2001.tu-chemnitz.de  Mon Dec  8 22:21:13 2003
From: alexander.noe at s2001.tu-chemnitz.de (=?ISO-8859-1?Q?Alexander_No=E9?=)
Date: Mon, 08 Dec 2003 22:21:13 +0100
Subject: [Matroska-devel] Re: New Simple Matroska Tag System Proposal
In-Reply-To: <3FD4EAB7.2030203@hrz.tu-chemnitz.de>
References: <000b01c3bd4e$90c404d0$0200a8c0@jcsston>	<br1527$msf$1@sea.gmane.org><1070874382.28529.65.camel@shrek.bitfreak.net>	<3FD47111.9080202@free.fr>	<002801c3bda3$9e235360$0200a8c0@jcsston>	<3FD4D8F1.2060108@free.fr>	<3FD4E120.30300@hrz.tu-chemnitz.de>	<3FD4E308.80908@free.fr>
	<3FD4E8D9.2090109@matroska.org>
	<3FD4EAB7.2030203@hrz.tu-chemnitz.de>
Message-ID: <3FD4EB49.1020401@hrz.tu-chemnitz.de>

 >> Or just plain, simple ???????,

OK, utf-8 does not react..... this should have been cyrillic....



Alex




From spyder at matroska.org  Mon Dec  8 22:13:20 2003
From: spyder at matroska.org (John Cannon)
Date: Mon, 8 Dec 2003 15:13:20 -0600
Subject: [Matroska-devel] Re: Re: New Simple Matroska Tag System Proposal
References: <000b01c3bd4e$90c404d0$0200a8c0@jcsston>	<br1527$msf$1@sea.gmane.org><br15p0$no4$1@sea.gmane.org>
	<3FD437C7.7040101@free.fr>
Message-ID: <br2pfu$vml$1@sea.gmane.org>


"Steve Lhomme" <steve.lhomme at free.fr> wrote in message
news:3FD437C7.7040101 at free.fr...
> Pamel wrote:
> > I forgot to mention that this would not affect any of the current info
in files
> > concerning Track names and languages.
> >
> > I have not seen any serious use of the current tagging system so
changing it now
> > should not have any widespread effect.
>
> That must be a joke. Someone claims it's too big and take 1/3 of the
> code and another claims noone uses it...
>
> Anyway I made my best when we decided for the tag system NOT to have a
> "key=value" system that would lead to incompatibilities between
> softwares/use. And I still think it's the way to go unless someone can
> convince me that 200 keys is better than 200 EBML IDs.

I agree with Steve.  However I do acknowledge that the current system is
really complex.  But complexity comes with flexibility ;)  Perhaps we can
find a way to reduce the complexity of _using_ the library at least?

Spyder





From spyder at matroska.org  Mon Dec  8 21:43:55 2003
From: spyder at matroska.org (John Cannon)
Date: Mon, 8 Dec 2003 14:43:55 -0600
Subject: [Matroska-devel] Re: New Simple Matroska Tag System Proposal
References: <000b01c3bd4e$90c404d0$0200a8c0@jcsston>	<br1527$msf$1@sea.gmane.org><1070874382.28529.65.camel@shrek.bitfreak.net>	<3FD47111.9080202@free.fr><002801c3bda3$9e235360$0200a8c0@jcsston>
	<3FD4D8F1.2060108@free.fr>
Message-ID: <000d01c3bdcc$1528f690$0cc8c8c8@johnc2>


----- Original Message -----
From: "Steve Lhomme" <steve.lhomme at free.fr>
To: "Discussion about the current and future development of Matroska"
<matroska-devel at lists.matroska.org>
Sent: Monday, December 08, 2003 2:02 PM
Subject: Re: [Matroska-devel] Re: New Simple Matroska Tag System Proposal


> Jory wrote:
> >>That must be a joke. Someone claims it's too big and take 1/3 of the
> >>code and another claims noone uses it...
> >>
> >>Anyway I made my best when we decided for the tag system NOT to have a
> >>"key=value" system that would lead to incompatibilities between
> >>softwares/use. And I still think it's the way to go unless someone can
> >>convince me that 200 keys is better than 200 EBML IDs.
> >
> >
> > The keys are human-readable and can be displayed directly to the user.
While
> > I doubt anyone could make sense of a EBML ID.
>
> OK, Unicode strings can quickly get unreadable, and I'm sure you don't
> want ASCII strings in your key/value pair. And as there is a separation
> for the string, I guess there must be some Escape character at some
> point which will also make some characters unreadable. And in the end
> noone is reading a movie or audio file in an hexa editor.
>
> > If we went the key=value way it wouldn't matter what the user added.
Because
> > it would require no more code to support 1000 keys than 100 keys (if
> > properly implemented).
>
> Mmm, so you don't want hierarchy/groups ? 1000 keys all at the same
> level, that sounds bad too me. And even some things (like the same kind
> of info at different level) are impossible.

Just wanted to let everyone know that I agree with Steve.  The current
system is better than a key=value type system.  I do however agree that the
current system is complex.  But if we are going to redo the tags, we need to
make some better way of doing it, not simply key=value.  That's too
uncontrolled IMO.

Spyder
Coming soon... http://www.spyder482.com :)




From spyder at matroska.org  Mon Dec  8 23:13:20 2003
From: spyder at matroska.org (John Cannon)
Date: Mon, 8 Dec 2003 16:13:20 -0600
Subject: [Matroska-devel] Re: New Simple Matroska Tag System Proposal
References: <000b01c3bd4e$90c404d0$0200a8c0@jcsston>	<br1527$msf$1@sea.gmane.org><1070874382.28529.65.camel@shrek.bitfreak.net>	<3FD47111.9080202@free.fr><002801c3bda3$9e235360$0200a8c0@jcsston><3FD4D8F1.2060108@free.fr>
	<000d01c3bdcc$1528f690$0cc8c8c8@johnc2>
Message-ID: <003f01c3bdd8$7df37a40$0cc8c8c8@johnc2>

> Just wanted to let everyone know that I agree with Steve.  The current
> system is better than a key=value type system.  I do however agree that
the
> current system is complex.  But if we are going to redo the tags, we need
to
> make some better way of doing it, not simply key=value.  That's too
> uncontrolled IMO.
>
> Spyder
> Coming soon... http://www.spyder482.com :)

Oh look my mail did send ;)




From jcsston at wiesneronline.net  Tue Dec  9 02:33:24 2003
From: jcsston at wiesneronline.net (Jory)
Date: Mon, 8 Dec 2003 19:33:24 -0600
Subject: [Matroska-devel] Re: New Simple Matroska Tag System Proposal
References: <000b01c3bd4e$90c404d0$0200a8c0@jcsston>	<br1527$msf$1@sea.gmane.org><1070874382.28529.65.camel@shrek.bitfreak.net>	<3FD47111.9080202@free.fr><002801c3bda3$9e235360$0200a8c0@jcsston>
	<3FD4D8F1.2060108@free.fr>
Message-ID: <003801c3bdf4$b153e0c0$0200a8c0@jcsston>

----- Original Message -----
From: "Ronald Bultje" <rbultje at ronald.bitfreak.net>
To: "Discussion about the current and future development of Matroska"
<matroska-devel at lists.matroska.org>
Sent: Monday, December 08, 2003 6:58 AM
Subject: Re: [Matroska-devel] Re: New Simple Matroska Tag System Proposal


> On Mon, 2003-12-08 at 13:38, Steve Lhomme wrote:
> > You know the EBML concept, you know you don't have to support ALL tags
> > under the sun. If you don't want to support all of them because you
> > don't like some of them is another story.
>
> It would be a good idea if there was a very small standardized subset
> that was documented to be often used and ought to be supported by
> players. That'd give me a simple start for deciding on which tags to
> support and which not.

The problem with that is that to support even the simplest fields with the
current system you have support most of it. All the Multi-*'s for example.


----- Original Message -----
From: "Steve Lhomme" <steve.lhomme at free.fr>
To: "Discussion about the current and future development of Matroska"
<matroska-devel at lists.matroska.org>
Sent: Monday, December 08, 2003 2:02 PM
Subject: Re: [Matroska-devel] Re: New Simple Matroska Tag System Proposal


> Jory wrote:
> >>That must be a joke. Someone claims it's too big and take 1/3 of the
> >>code and another claims noone uses it...
> >>
> >>Anyway I made my best when we decided for the tag system NOT to have a
> >>"key=value" system that would lead to incompatibilities between
> >>softwares/use. And I still think it's the way to go unless someone can
> >>convince me that 200 keys is better than 200 EBML IDs.
> >
> >
> > The keys are human-readable and can be displayed directly to the user.
While
> > I doubt anyone could make sense of a EBML ID.
>
> OK, Unicode strings can quickly get unreadable, and I'm sure you don't
> want ASCII strings in your key/value pair. And as there is a separation
> for the string, I guess there must be some Escape character at some
> point which will also make some characters unreadable.

The element I was proposing had a ASCII string for the key and a UTF-8 value
-- Simple Tag
  --- Name (Key) - ASCII String
  --- String (Value) - UTF-8 String
The Key would only allow A-Z 1-9 _ characters.

> And in the end noone is reading a movie or audio file in an hexa editor.
Yes, but how would your tag program display those fields? In hex?

/me still waiting from comments from someone who has made a tag editor




From theo_brendel at hotmail.com  Wed Dec 10 16:03:52 2003
From: theo_brendel at hotmail.com (Steven Mingam)
Date: Wed, 10 Dec 2003 16:03:52 +0100
Subject: [Matroska-devel] Re: Control Track
References: <bqs8g8$28l$1@sea.gmane.org> <bqs9f5$3gk$1@sea.gmane.org>
Message-ID: <br7ckd$ofs$1@sea.gmane.org>

I did some search on gpac/osmo/mpeg4 menu system and noticed that there is
plenty of format that support what you said and more ...

look at  SMIL ( http://www.w3.org/TR/smil20/ ) (realnetworks fully support
this), and especially the "SMIL 2.0 Control Content Modules"  (
http://www.w3.org/TR/smil20/smil-content.html )

Well it's perhaps a bit overkill, but it can do everything needed, and there
is a lot code for parsing (rendering ?) that. Like MSXML, and various
opensource projects (full list here : http://www.w3c.org/AudioVideo/ )

Another way is XMT (official  MPEG-4 format) and the binary version BiFS.

Perhaps supporting some basics features of one of those format at the
begining and develop it further after is conceivable ?



"Pamel" <paul at msn.com> a ?crit dans le message de news:
bqs9f5$3gk$1 at sea.gmane.org...
> The API's that it will interface with:
>
>
> 1.  Audio switching
> 2.  Subtitle switching
> 3.  Video switching (Toff will make a video switcher someday...)
> 4.  Volume control
> 5.  Seeking to time.
> 6.  Seeking to chapters. (Maybe this isn't needed with seeking to time?)
> 7.  Switching to another file.  (I am nervous about this because of the
> potential for abuse/virus)
>
>
>
> Pamel





From paul at msn.com  Fri Dec 12 06:40:10 2003
From: paul at msn.com (Pamel)
Date: Thu, 11 Dec 2003 23:40:10 -0600
Subject: [Matroska-devel] Re: Control Track
References: <bqs8g8$28l$1@sea.gmane.org> <bqs9f5$3gk$1@sea.gmane.org>
	<br7ckd$ofs$1@sea.gmane.org>
Message-ID: <brbkbd$j2v$1@sea.gmane.org>

Thanks.  I had taken a look at SMIL previously but had forgotten about it.
When I have time next week I will look again.


Pamel

"Steven Mingam" <theo_brendel at hotmail.com> wrote in message
news:br7ckd$ofs$1 at sea.gmane.org...
> I did some search on gpac/osmo/mpeg4 menu system and noticed that there is
> plenty of format that support what you said and more ...
>
> look at  SMIL ( http://www.w3.org/TR/smil20/ ) (realnetworks fully support
> this), and especially the "SMIL 2.0 Control Content Modules"  (
> http://www.w3.org/TR/smil20/smil-content.html )
>
> Well it's perhaps a bit overkill, but it can do everything needed, and there
> is a lot code for parsing (rendering ?) that. Like MSXML, and various
> opensource projects (full list here : http://www.w3c.org/AudioVideo/ )





From chris at matroska.org  Fri Dec 12 17:12:44 2003
From: chris at matroska.org (Christian HJ Wiesner)
Date: Fri, 12 Dec 2003 17:12:44 +0100
Subject: [Matroska-devel] MKV menus
In-Reply-To: <3FD0D203.1050904@free.fr>
References: <3FD0D203.1050904@free.fr>
Message-ID: <3FD9E8FC.6020709@matroska.org>

Hi list,

i recommend you read here : 
http://forum.doom9.org/showthread.php?s=&threadid=66583

Bond has obviously made a script to convert DVD menues into MPEG4 menues 
with GPAC, so the two seem to be compatible already. Another reason for 
us to jump on supporting MPEG4 menues instaed of making a new one ?

Steve Lhomme wrote:

> Well, adding menus to Matroska is not as simple as it may seem. Because
> we want to have at least the capabilities of the one in DVDs, but even
> more...
> I think we should do a kind of survey of what people expect from their
> menus. And we also have to see what part goes into the container and
> what does not.
> Bring on all possible ideas then we'll collect them and try to assemble
> them :)





From steve.lhomme at free.fr  Sat Dec 13 11:52:52 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Sat, 13 Dec 2003 11:52:52 +0100
Subject: [Matroska-devel] MKV menus
In-Reply-To: <3FD9E8FC.6020709@matroska.org>
References: <3FD0D203.1050904@free.fr> <3FD9E8FC.6020709@matroska.org>
Message-ID: <3FDAEF84.6000603@free.fr>

Christian HJ Wiesner wrote:

> Hi list,
> 
> i recommend you read here : 
> http://forum.doom9.org/showthread.php?s=&threadid=66583
> 
> Bond has obviously made a script to convert DVD menues into MPEG4 menues 
> with GPAC, so the two seem to be compatible already. Another reason for 
> us to jump on supporting MPEG4 menues instaed of making a new one ?

As long as it fits the Matroska paradigm (things divided into tracks and 
packets with timestamps), yes.



From chris at matroska.org  Sat Dec 13 23:52:27 2003
From: chris at matroska.org (Christian HJ Wiesner)
Date: Sat, 13 Dec 2003 23:52:27 +0100
Subject: [Matroska-devel] MKV menus
In-Reply-To: <3FDAEF84.6000603@free.fr>
References: <3FD0D203.1050904@free.fr> <3FD9E8FC.6020709@matroska.org>
	<3FDAEF84.6000603@free.fr>
Message-ID: <3FDB982B.5090207@matroska.org>

Steve Lhomme wrote:

> Christian HJ Wiesner wrote:
>
>> Hi list,
>> i recommend you read here : 
>> http://forum.doom9.org/showthread.php?s=&threadid=66583
>> Bond has obviously made a script to convert DVD menues into MPEG4 
>> menues with GPAC, so the two seem to be compatible already. Another 
>> reason for us to jump on supporting MPEG4 menues instaed of making a 
>> new one ?
>
> As long as it fits the Matroska paradigm (things divided into tracks 
> and packets with timestamps), yes.

Well it seems it does, but the patent/license question is still open it 
seems. Betaboy is of great help here, he is constantly digging out great 
links about this :

http://news.earthweb.com/dev-news/article.php/2231651

The MP4 menue system seems to be based on SMIL, a XML variant, and gets 
compiled into bifs, a binary version of it ..... you heard this before 
;-) ??? Now, the very important question is, is all of this patented and 
subject to licenses, or not ?

Christian





From steve.lhomme at free.fr  Sun Dec 14 00:04:45 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Sun, 14 Dec 2003 00:04:45 +0100
Subject: [Matroska-devel] MKV menus
In-Reply-To: <3FDB982B.5090207@matroska.org>
References: <3FD0D203.1050904@free.fr>
	<3FD9E8FC.6020709@matroska.org>	<3FDAEF84.6000603@free.fr>
	<3FDB982B.5090207@matroska.org>
Message-ID: <3FDB9B0D.7@free.fr>

Christian HJ Wiesner wrote:

> Steve Lhomme wrote:
> 
>> Christian HJ Wiesner wrote:
>>
>>> Hi list,
>>> i recommend you read here : 
>>> http://forum.doom9.org/showthread.php?s=&threadid=66583
>>> Bond has obviously made a script to convert DVD menues into MPEG4 
>>> menues with GPAC, so the two seem to be compatible already. Another 
>>> reason for us to jump on supporting MPEG4 menues instaed of making a 
>>> new one ?
>>
>>
>> As long as it fits the Matroska paradigm (things divided into tracks 
>> and packets with timestamps), yes.
> 
> 
> Well it seems it does, but the patent/license question is still open it 
> seems. Betaboy is of great help here, he is constantly digging out great 
> links about this :
> 
> http://news.earthweb.com/dev-news/article.php/2231651
> 
> The MP4 menue system seems to be based on SMIL, a XML variant, and gets 
> compiled into bifs, a binary version of it ..... you heard this before 
> ;-) ??? Now, the very important question is, is all of this patented and 
> subject to licenses, or not ?

If we do SMIL (W3C standard) compiled in EBML, we can probably avoid a 
lot of troubles.



From unmei at matroska.org  Sun Dec 14 00:09:15 2003
From: unmei at matroska.org (unmei)
Date: Sun, 14 Dec 2003 00:09:15 +0100
Subject: [Matroska-devel] muxed usf
Message-ID: <brg632$781$1@sea.gmane.org>

some random thoughts and approaches for muxing usf into matroska. please 
keep in mind i have not much experience what is hard to implement or 
takes much cpu power. also i am not implementing mkv, so i dont know the 
internals -> that's why it's just a buch of thoughts :) (RFC)
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: usf.notes.txt
URL: <http://lists.matroska.org/pipermail/matroska-devel/attachments/20031214/5759f91f/attachment.txt>

From paul at msn.com  Sun Dec 14 00:20:17 2003
From: paul at msn.com (Pamel)
Date: Sat, 13 Dec 2003 17:20:17 -0600
Subject: [Matroska-devel] Re: Control Track
References: <bqs8g8$28l$1@sea.gmane.org> <bqs9f5$3gk$1@sea.gmane.org>
	<br7ckd$ofs$1@sea.gmane.org>
Message-ID: <brg6rf$8bj$1@sea.gmane.org>

"Steven Mingam" wrote...
> look at  SMIL ( http://www.w3.org/TR/smil20/ ) (realnetworks fully support
> this), and especially the "SMIL 2.0 Control Content Modules"  (
> http://www.w3.org/TR/smil20/smil-content.html )

Just glanced over it.

> Well it's perhaps a bit overkill, but it can do everything needed, and there
> is a lot code for parsing (rendering ?) that. Like MSXML, and various
> opensource projects (full list here : http://www.w3c.org/AudioVideo/ )

Two words come to mind, "big" and "complex".  But yes, there is a lot of
available code to be able to work with it.

> Another way is XMT (official  MPEG-4 format) and the binary version BiFS.

This probably won't be an option due to liscensing issues.

> Perhaps supporting some basics features of one of those format at the
> begining and develop it further after is conceivable ?

We could definitely pick and choose the options that we want to support here.
However, I only see three reasons to use such a small subset of SMIL2:

1. Someone already familiar with SMIL2 will have a very small learning curve.
2. We can say that we use an existing open standard.
3. Reduce documentation by referring to the SMIL spec.

I doubt that point one will be much of an issue given that almost no one is
familiar with the workings of SMIL2.  But point two could certainly be an
important to us as that is one of the purposes of Matroska.  Also, everyone is a
fan of using open standards.  Point 3 would be a small plus, but would probably
be more than offset in the amount of time it would take to read through the
SMIL2 specs and create a subset.

Any opinions on this?


Pamel





From paul at msn.com  Sun Dec 14 10:19:13 2003
From: paul at msn.com (Pamel)
Date: Sun, 14 Dec 2003 03:19:13 -0600
Subject: [Matroska-devel] Re: MKV menus
References: <3FD0D203.1050904@free.fr><3FD9E8FC.6020709@matroska.org>	<3FDAEF84.6000603@free.fr><3FDB982B.5090207@matroska.org>
	<3FDB9B0D.7@free.fr>
Message-ID: <brh9uc$ikp$1@sea.gmane.org>

"Steve Lhomme" wrote...
> Christian HJ Wiesner wrote:
> > The MP4 menue system seems to be based on SMIL, a XML variant, and gets
> > compiled into bifs, a binary version of it ..... you heard this before
> > ;-) ??? Now, the very important question is, is all of this patented and
> > subject to licenses, or not ?
>
> If we do SMIL (W3C standard) compiled in EBML, we can probably avoid a
> lot of troubles.

Nope, that would make it worse.  The license agreements that the different
consortium members made is that there will be no licensing fees as long as the
products infringing on the patents are SMIL2 compliant.  This should mean that
if you make a system that uses SMIL2, then you shouldn't be subject to any
licensing fees.  If you alter it in any way to a form that is not SMIL2
compliant, then you could be subject to fees.

Given this, you could leave a SMIL2 in its natural form and use it without any
fears.


Pamel





From steve.lhomme at free.fr  Sun Dec 14 10:31:07 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Sun, 14 Dec 2003 10:31:07 +0100
Subject: [Matroska-devel] Re: MKV menus
In-Reply-To: <brh9uc$ikp$1@sea.gmane.org>
References: <3FD0D203.1050904@free.fr><3FD9E8FC.6020709@matroska.org>	<3FDAEF84.6000603@free.fr><3FDB982B.5090207@matroska.org>	<3FDB9B0D.7@free.fr>
	<brh9uc$ikp$1@sea.gmane.org>
Message-ID: <3FDC2DDB.4010507@free.fr>

Pamel wrote:

> "Steve Lhomme" wrote...
> 
>>Christian HJ Wiesner wrote:
>>
>>>The MP4 menue system seems to be based on SMIL, a XML variant, and gets
>>>compiled into bifs, a binary version of it ..... you heard this before
>>>;-) ??? Now, the very important question is, is all of this patented and
>>>subject to licenses, or not ?
>>
>>If we do SMIL (W3C standard) compiled in EBML, we can probably avoid a
>>lot of troubles.
> 
> 
> Nope, that would make it worse.  The license agreements that the different
> consortium members made is that there will be no licensing fees as long as the
> products infringing on the patents are SMIL2 compliant.  This should mean that
> if you make a system that uses SMIL2, then you shouldn't be subject to any
> licensing fees.  If you alter it in any way to a form that is not SMIL2
> compliant, then you could be subject to fees.
> 
> Given this, you could leave a SMIL2 in its natural form and use it without any
> fears.

Well, putting it in EBML form would be like compressing it. That's all. 
I don't think it's subject to any patent. And in my mind it's good to 
have it in a less complex and shorter form : we can control what 
features of SMIL/SMIL2 is mapped in our system.



From paul at msn.com  Sun Dec 14 10:49:32 2003
From: paul at msn.com (Pamel)
Date: Sun, 14 Dec 2003 03:49:32 -0600
Subject: [Matroska-devel] Re: muxed usf
References: <brg632$781$1@sea.gmane.org>
Message-ID: <brhbn7$kos$1@sea.gmane.org>

I'm really tired right now, so please excuse my grammar.

Here are my comments on Unmei's USF notes.

TAGS
*all tags are translated into EBML IDs

I still don't understand fully why USF needs to be stored in EBML.  I understand
that people don't want to have to use an XML parser.  But you will either need
an XML parser, or libebml.  I don't see why one would be so much better in this
case.  Mind you that I'm not particularly opposed to it, it just seems like an
unnecessary step.

**tags that are inevitable get the lowest ID integer
**tags occuring the most often get as low ID integer as possible

Yep.

**tags that denote tags requiring much processing get high IDs

I don't know if I follow the reasoning behind this.  Even if a tag would require
a lot of processing power, but is likely to be common, shouldn't it have a low
ID?

EMBED
**Fonts embedded in XML-USF should be muxed into the MKV file as attachment file
(and not stored in a <embed> in EBML-USF).

I would initially say that it would seem most natural to store an embedded font
in the codec private.  However this have several drawbacks, for instance the
font would have to be stored several times if it is used in more than one track.

**Pictures (embedded in XML-USF or external to XML-USF) should be inlined base64
encoded. This will eventually cause picture to be stored multiple times, but it
avoids the necessity to either have all embeds loaded into RAM during the entire
playback or seek to the embed during playback.

There is no reason to use base64 if you are using EBML.  You can have an ID
store binary data fine.  In fact, thats probably the biggest argument for using
EBML instead of text-XML.

**Eventually the RAM chached method is faster and if the additional RAM used is
no concern it were optimal since the embeds can be decoded before even start to
playback (avoiding a CPU peak when encountering a picture). But embed without
caching (read: seek to the embed section and decode WHILE playback is in
progress) is most likely going to kill the playability.

But where are you going to store the pictures to cache?  Storing in the codec
private seems excessive, but possible.  Storing in a seperate attachment is
probably fine if you can also get attached fonts to work.

OTHER POINTS
*are subtitle streams laced (interleaved with audio and video steams) ? I guess
not...anyway EBML-USF should use the same method as used for other subtitle
formats.

All streams are interleaved together, including subtitles.  (Laced is a whole
different thing, and subtitles should never be laced.)

*a muxer must sort the <subtitle> by ascending start time.

As the streams are all interleaved, this would be essential.

*XML-USF files containing multiple <subtitles> sections are treated like
multiple subtitle files (each gets a stream, with metadata,styles... doubled).

Each subtitle "stream" should be separated into its own track.  Having two
subtitle streams in the same track is b0rked.

I think it was discussed earlier that certain things should just go into the
codec private.  Basically anything that doesn't have a timecode attached to it.
For instance, the Styles should all be stored in the codecprivate so that you
know they are all loaded at start time.  This is important because you have no
garauntee that the first few Blocks of a stream will be loaded if someone
immediately seeks to the middle of a stream.


Pamel





From paul at msn.com  Sun Dec 14 10:56:09 2003
From: paul at msn.com (Pamel)
Date: Sun, 14 Dec 2003 03:56:09 -0600
Subject: [Matroska-devel] Re: Re: MKV menus
References: <3FD0D203.1050904@free.fr><3FD9E8FC.6020709@matroska.org>	<3FDAEF84.6000603@free.fr><3FDB982B.5090207@matroska.org>	<3FDB9B0D.7@free.fr><brh9uc$ikp$1@sea.gmane.org>
	<3FDC2DDB.4010507@free.fr>
Message-ID: <brhc3k$l8e$1@sea.gmane.org>

"Steve Lhomme"  wrote...
> Well, putting it in EBML form would be like compressing it. That's all.
> I don't think it's subject to any patent. And in my mind it's good to
> have it in a less complex and shorter form : we can control what
> features of SMIL/SMIL2 is mapped in our system.

Unfortunately the patents do not deal directly with SMIL but rather cover
actions being accomplished by the SMIL.  So changing the container (XML vs.
EBML) would definitely not exclude it from the patents.  However, it would
probably make it subjectable to fees because it would no longer be compatible
with SMIL which requires the use of XML.

http://www.w3.org/2001/05/23/SMIL-IPR-statements.html


Pamel





From chris at matroska.org  Sun Dec 14 22:31:03 2003
From: chris at matroska.org (Christian HJ Wiesner)
Date: Sun, 14 Dec 2003 22:31:03 +0100
Subject: [Matroska-devel] Subtitles in MP4 .. a mess !!
Message-ID: <3FDCD697.2020505@matroska.org>

Read here : 
http://forum.doom9.org/showthread.php?s=&threadid=66661&perpage=20&pagenumber=3

*[quote]ND Subtitles & Chapters issue ; from bobolobo, member of the 
Nero Digital dev team :*

I'd like to bring some clarifications about ND mp4 files, Subtitles and 
Chapters support as it seems to generate much discussions, lack of 
understanding, etc. I hope this could enlight you on the way it is done 
and why.

Basically, the mpeg-4 standard doesn't specify a way to handle subtitles 
and chapters. That is to say the notion of movie subtitles and chapters 
doesn't exist in the standard. From that assumption, there is no reason 
to say subtiltes or chapters are ISO compliant or not since there is no 
spec for this.

However mpeg-4 is a very rich standard and provide several tools one can 
use to implement the support of subtitles and chapters. For the 
subtitles, we can have :

- 2D BIFS
- Streaming Text Format (14496-17)
- private data

The first approach (2D BIFS) consists in the use of the complex mpeg-4 
system layer to describe a presentation composed of multiple objects 
(audio stream, video stream, 2D bitmap, etc.). In the absolute this 
should be the best way to implement subtitles. However, due to its 
complexity it would involve a lot of work for us which simply means more 
delay before the release ! Beside this constraint, we were also faced to 
the fact that such complex system management would become a real 
headache on embedded platforms (ie standalones) were resource are 
extrexemly limited. Therefore a fast adoption of MP4 format in this 
area. Just imagine us telling standalone manufacturers : to support MP4 
it's quite easy, just read the 1000 pages of mpeg-4 BIFS system 
standard, then make it fit in your 16 kB of memory and you'll get it ! 
You'll understand that solution was not reasonable for us and that's why 
we prefer in our first stage to not use this implementation. But in 
futur evolutions, the addition of new features like menus, 
interactivity, and with the spreading of more powerful chips, we may 
seriously consider this solution.

The second solution "Streaming Text Format" is a new part of the 
standard not approved yet. It uses text data rather than bitmap for the 
subtitles and relies on the previous system layer. Considering subtitles 
in DVD are bitmap it would require some OCR process. In conclusion this 
solution is even harder to implement (imagine bitmap to unicode 
conversion for chinese or arabic language !). So we coulnd't choose this 
way.

And finaly the last solution uses mp4 file user data to store our info. 
Since the mp4 file provides private data space, we simply put our 
compressed data here. These user data must be discarded by decoders that 
don't know how to handle them so that shouldn't hurt.
This was the best compromise we found and basically this doesn't differ 
much from other system like vobsub which stores data in a file beside.

For the chapter list, we applied the same recipe since there was no 
really other mean to achieve this.

I hope this clarify a little bit things and help you to understand why 
these choice were done.

And last but not least, for those who are concerned about ND MP4 files 
support on their standalone, be sure we're making much efforts in 
promoting ISO MP4 support in standalones. Discussions are on the way and 
hopefuly mp4 support will come quite soon.[/quote]


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.matroska.org/pipermail/matroska-devel/attachments/20031214/931c4e44/attachment.html>

From jcsston at wiesneronline.net  Thu Dec 18 05:50:18 2003
From: jcsston at wiesneronline.net (Jory)
Date: Wed, 17 Dec 2003 22:50:18 -0600
Subject: [Matroska-devel] Re: New Simple Matroska Tag System Proposal
References: <000b01c3bd4e$90c404d0$0200a8c0@jcsston>	<br1527$msf$1@sea.gmane.org><1070874382.28529.65.camel@shrek.bitfreak.net>	<3FD47111.9080202@free.fr><002801c3bda3$9e235360$0200a8c0@jcsston><3FD4D8F1.2060108@free.fr>
	<003801c3bdf4$b153e0c0$0200a8c0@jcsston>
Message-ID: <001901c3c522$7c2b2c70$0200a8c0@jcsston>

I have been talking with Pamel and he came up with an interesting idea.
Have nested tags combined with the Simple Tags

EBML Layout
-- Simple Tag
   --- Name - ASCII String
   --- String Value - UTF-8 String
   --- Binary Value - Binary Data
   --- Simple Tag
      ---- Name - ASCII String
      ---- String Value - UTF-8 String
      ---- Binary Value - Binary Data
   --- Simple Tag
      ---- Name - ASCII String
      ---- String Value - UTF-8 String
      ---- Binary Value - Binary Data

This way we could have the power that the Multi-*'s offered while still
staying simple. A limit of 128 or 255 levels would be more than reasonable.

Say you wanted to store the birthdate of the boss of the webmaster who made
the website of the guy who took the album picture.
ALBUM
- PICTURE
-- PHOTOGRAPHER
--- WEBSITE
---- WEBMASTER
----- BOSS
------ BIRTHDATE

Toff suggested that conversion to xml and searching with a xpath like syntax
could work with this.

XML Form
<tag>
<name>Album</name>
<value>A made up album name</value>
<tag>
<name>Picture</name>
<value>The picture</value>
<tag>
<name>Photographer</name>
<value>John Doe</value>
<tag>
<name>Website</name>
<value>http://www.john-doe-photo.com/</value>
<tag>
<name>Webmaster</name>
<value>Doe Man</value>
<tag>
<name>Boss</name>
<value>Superman</value>
<tag>
<name>Birthdate</name>
<value>12/07/1945</value>
</tag>
</tag>
</tag>
</tag>
</tag>
</tag>
</tag>

I thought of a way we could do event based tagging with this too. Have a
base tag named EVENTS. Then a nested tag called TIME with a value of the
time the event happens like "00:01:34.43" and then have nested tags under
that for tag about the events.
EVENTS
- TIME
-- SONG
--- ARTIST
--- TITLE

I also think we could map all the AAF and MXF tags to this, but I don't know
of any AAF or MXF editor as of yet.

Jory



From paul at msn.com  Thu Dec 18 09:35:38 2003
From: paul at msn.com (Pamel)
Date: Thu, 18 Dec 2003 02:35:38 -0600
Subject: [Matroska-devel] Re: New Simple Matroska Tag System Proposal 2.0
References: <000b01c3bd4e$90c404d0$0200a8c0@jcsston>	<br1527$msf$1@sea.gmane.org><1070874382.28529.65.camel@shrek.bitfreak.net>	<3FD47111.9080202@free.fr><002801c3bda3$9e235360$0200a8c0@jcsston><3FD4D8F1.2060108@free.fr><003801c3bdf4$b153e0c0$0200a8c0@jcsston>
	<001901c3c522$7c2b2c70$0200a8c0@jcsston>
Message-ID: <brrors$94b$1@sea.gmane.org>

"Jory" wrote...
> I have been talking with Pamel and he came up with an interesting idea.
> Have nested tags combined with the Simple Tags
>
> EBML Layout
> -- Simple Tag
>    --- Name - ASCII String
>    --- String Value - UTF-8 String
>    --- Binary Value - Binary Data
>    --- Simple Tag
>       ---- Name - ASCII String
>       ---- String Value - UTF-8 String
>       ---- Binary Value - Binary Data
>    --- Simple Tag
>       ---- Name - ASCII String
>       ---- String Value - UTF-8 String
>       ---- Binary Value - Binary Data

My idea was actually a little different in that I was suggesting a different ID
for the nested tags.  Then say that you should only use a certain set of tags at
the first level, and then another set at the next level.  Also, any application
that didn't want to display more complicated tag information would just not have
to know the next layer ElementID, thus skipping them entirely.

I don't really know which would be better though.

> This way we could have the power that the Multi-*'s offered while still
> staying simple. A limit of 128 or 255 levels would be more than reasonable.
>
> Say you wanted to store the birthdate of the boss of the webmaster who made
> the website of the guy who took the album picture.
> ALBUM
> - PICTURE
> -- PHOTOGRAPHER
> --- WEBSITE
> ---- WEBMASTER
> ----- BOSS
> ------ BIRTHDATE

I don't personally see a usefulness of allowing more than one level of nesting.
More on this below.

> Toff suggested that conversion to xml and searching with a xpath like syntax
> could work with this.

The XML authoring could be very handy as a tag authoring format for across
multiple types of systems other than Matroska. This idea is intriguing to me.

> I thought of a way we could do event based tagging with this too. Have a
> base tag named EVENTS. Then a nested tag called TIME with a value of the
> time the event happens like "00:01:34.43" and then have nested tags under
> that for tag about the events.
> EVENTS
> - TIME
> -- SONG
> --- ARTIST
> --- TITLE

I think that stuff in the Tags that is sectioned by time should only use the
Chapters to identify the time.  Event based items could use a Tag Stream that
interleaves the tagging data with the other tracks using timecodes and
durations.

> I also think we could map all the AAF and MXF tags to this, but I don't know
> of any AAF or MXF editor as of yet.

This is where it gets interesting.  If you allowed nesting several layers deep
then you could actually accomplish support of most of the AAF/MXF system of
tagging that allows multiple levels of nested attributes.  If you combined the
many nested layers with specific time based tags then you could support all of
AAF/MXF.  (at least as well as I understand it)  But, it depends on how
complicated you want to make it.

I still believe that a very specific set of tags should be defined that can be
used in the "Name - ASCII String".  This list must be freely available in
several different formats to make sure that developers always use the list
directly, thus preventing incompatibilities from being introduced.  There is
always that danger for using a String for the ID, but in this case I would say
that the benefits definitely outweigh the potential problems.

I had some big reservations about what Jory was suggesting initially, but this
new turn has resolved all of those.  I now feel confident that this is where the
Matroska Tags need to go.


Pamel





From alexander.noe at s2001.tu-chemnitz.de  Thu Dec 18 19:10:40 2003
From: alexander.noe at s2001.tu-chemnitz.de (=?ISO-8859-1?Q?Alexander_No=E9?=)
Date: Thu, 18 Dec 2003 19:10:40 +0100
Subject: [Matroska-devel] Re: New Simple Matroska Tag System Proposal 2.0
In-Reply-To: <brrors$94b$1@sea.gmane.org>
References: <000b01c3bd4e$90c404d0$0200a8c0@jcsston>	<br1527$msf$1@sea.gmane.org><1070874382.28529.65.camel@shrek.bitfreak.net>	<3FD47111.9080202@free.fr><002801c3bda3$9e235360$0200a8c0@jcsston><3FD4D8F1.2060108@free.fr><003801c3bdf4$b153e0c0$0200a8c0@jcsston>	<001901c3c522$7c2b2c70$0200a8c0@jcsston>
	<brrors$94b$1@sea.gmane.org>
Message-ID: <3FE1EDA0.2040903@hrz.tu-chemnitz.de>

Pamel wrote:

>
>I don't personally see a usefulness of allowing more than one level of nesting.
>More on this below.
>  
>
Is your brain working iteratively???

A Tag is either
   empty
or
   a set of <name, value> along with a finite number of Tags

Restricting the maximum depth would make it more complex....

Sth else. Someone came up with the terrible idea of making tag names 
being ASCII.
Did you ever try to read russian, written in ASCII?? Matroska is full of 
UTF-8
anyway, so why not use it now?



Alex




From chris at matroska.org  Thu Dec 18 19:15:49 2003
From: chris at matroska.org (Christian HJ Wiesner)
Date: Thu, 18 Dec 2003 19:15:49 +0100
Subject: [Matroska-devel] matroska Foobar2k implementation
Message-ID: <3FE1EED5.2020408@matroska.org>

Hi Jory,

here an interesting IRC log from #foobar2000 on irc.freenode.net for you 
( sorry about the short rant in the middle ;-) ) :

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

<DEATH> wrap mp3/mpc into matroska then kill all improvements it gives 
over raw mp3/mpc
<adiabatic> what's the point of MPC-in-Matroska, anyway?
<DEATH> mpc seeking ist death
<DEATH> inefficient
* CompactDick concurs
<DEATH> think playing mpc+cue over LAN
<ChrHJW_Zhengzhou> yup :)
<DEATH> same goes for mp3
<CompactDick> you can feel the lag on a slower machine, like my PII 366
<CompactDick> ogg works fine here
* ChrHJW_Zhengzhou is still working on his first FLAC + CUE in MKA ed2k 
release, with chapters and other Goodies ...
<DEATH> i made mpc+cue behave semi-decently when playing from local hdd 
on athlonxp
<CompactDick> as it should
<DEATH> but it is still ass in algorithm efficiency terms
* ChrHJW_Zhengzhou is now known as ChrHJW_Beijing
<DEATH> ChrHJW_whatever: some people seem to want to implement mka 
support in fb2k using reader api
<DEATH> that would kill fast seeking
<ChrHJW_Beijing> i understand this is no good idea ?
<ChrHJW_Beijing> oh ...
<DEATH> probably can be hacked to work at all but it is no good
<ChrHJW_Beijing> who are this people ?
<ChrHJW_Beijing> can we convince them to make it better ?
<DEATH> <jcsston> ah, I think I've found the problem. the file class 
handles different 'protocols' file://, http://, etc.(to my 
understanding) if I add a matroska file as a location like 
'matroska://C:/test.mka' the matroska file class is called :) I'm 
guessing that with the default 'file://' the internal file class was 
handling it
<DEATH> havent been able to communicate with him
<DEATH> but he seems to want to emulate reading from a raw mpc file
<ChrHJW_Beijing> oh, Jory
<ChrHJW_Beijing> i talk to him
<DEATH> so no fast seeking for you
<ChrHJW_Beijing> you have a message for him i can transfer ?
<DEATH> lemme say this again
<ChrHJW_Beijing> jcsston at matroska.org
* ChrHJW_Beijing is logging
<DEATH> you need some kind of third-party-extendable interface that 
turns mpc/mp3/whatever compressed packets into audio data, right ?
<DEATH> add your own interface class to fb2k and let others implement it
<adiabatic> MTRH: A (fairly dated, since there's over a billion of 'em 
now) Monty Python song.
<DEATH> like i did with packet_decoder in 0.7.6 (for MP4 playback)
<ChrHJW_Beijing> got you
<ChrHJW_Beijing> if we add this class, is there a collision with a 
normal MKA reader ?
<DEATH> if you cant get stuff working with packet_decoder interface i 
have in 0.7.6, write your own interface, and i'll add that interface to 
mp3/mpc/vorbis/aac/whatever decoders in foo_input_std
<DEATH> ?
<ChrHJW_Beijing> or can he finish his work to have a first support ?
<ChrHJW_Beijing> even if its suboptimal that way ?
<DEATH> lemme flood how mp4 parsing works again
<DEATH> there is input_mp4 class, which is just like any other input
<DEATH> but it finds packet_decoder interface that can handle data type 
contained in mp4 file being read
<DEATH> and uses that decoder
<DEATH> like writing plugins to a plugin
<DEATH> ideally, MKA could do the same logic
<DEATH> main problem is that you need to be able to call different 
(often third-party-supplied) audio decoders, right ?
<DEATH> anyway, take 0.7.6 mp4 parser as sample code
<ChrHJW_Beijing> sounds good
<DEATH> in foo_input_std
* ChrHJW_Beijing is again wondering about the way jcsston is working .. 
he is always coding first, and communicating afterwards :/ ....
<DEATH> hmm
<DEATH> do you have sample commandline decoder or smth
<DEATH> maybe i should look into implementing that myself
<DEATH> since this thing will probably get popular
<DEATH> would be better if this used same decoder API as mp4
<DEATH> which may involve changes in that api
<DEATH> bbl
-----------------------------------------------------------------------------------------------------




From spyder at matroska.org  Thu Dec 18 19:26:28 2003
From: spyder at matroska.org (John Cannon)
Date: Thu, 18 Dec 2003 12:26:28 -0600
Subject: [Matroska-devel] Re: New Simple Matroska Tag System Proposal 2.0
References: <000b01c3bd4e$90c404d0$0200a8c0@jcsston>	<br1527$msf$1@sea.gmane.org><1070874382.28529.65.camel@shrek.bitfreak.net>	<3FD47111.9080202@free.fr><002801c3bda3$9e235360$0200a8c0@jcsston><3FD4D8F1.2060108@free.fr><003801c3bdf4$b153e0c0$0200a8c0@j
	<brrors$94b$1@sea.gmane.org>
Message-ID: <001b01c3c594$74b61eb0$0cc8c8c8@johnc2>

Just wanted to butt in here...

> There is
> always that danger for using a String for the ID, but in this case I would
say
> that the benefits definitely outweigh the potential problems.

Ummm, why is a string ID anymore dangerous than using an EBML ID?  They are
both forms binary(as is everything almost) and both must have formal
restrictions placed on them in order to preserve the standard.  To me it
seems no more dangerous than the byte IDs.  I personally haven't dealt with
the Tags in MKV yet.  So I can't say I have any problem with the current
system.  However, I have a lot of faith in Jory as a programmer and I can
see that he has a problem with it.  He has probably spent the most time
working with Tags out of all of us, of course I know he's not the only one
to do anything with them.  As for what should be done, if we are going to
change the format, I vote for XML'izing the tags.  But of course I like XML
:).  It would make authoring easy.

Just another thought, how hard would it be to make a simple tool to do
XML->EBML->XML conversion...  If it could be done in a reasonably small
size, we could take tags as XML for input and return them as output in XML,
hiding the EBML side completely for tag editing... just a thought.

Spyder



From chris at matroska.org  Thu Dec 18 21:37:55 2003
From: chris at matroska.org (Christian HJ Wiesner)
Date: Thu, 18 Dec 2003 21:37:55 +0100
Subject: [Matroska-devel] Re: New Simple Matroska Tag System Proposal 2.0
In-Reply-To: <brrors$94b$1@sea.gmane.org>
References: <000b01c3bd4e$90c404d0$0200a8c0@jcsston>	<br1527$msf$1@sea.gmane.org><1070874382.28529.65.camel@shrek.bitfreak.net>	<3FD47111.9080202@free.fr><002801c3bda3$9e235360$0200a8c0@jcsston><3FD4D8F1.2060108@free.fr><003801c3bdf4$b153e0c0$0200a8c0@j
	<brrors$94b$1@sea.gmane.org>
Message-ID: <3FE21023.5050202@matroska.org>

from spyder, his email client stripped the subject line it seems, so i 
got it for moderation :

Just wanted to butt in here...


>> There is
>> always that danger for using a String for the ID, but in this case I would
>  
>
say

>> that the benefits definitely outweigh the potential problems.
>  
>

Ummm, why is a string ID anymore dangerous than using an EBML ID?  They are
both forms binary(as is everything almost) and both must have formal
restrictions placed on them in order to preserve the standard.  To me it
seems no more dangerous than the byte IDs.  I personally haven't dealt with
the Tags in MKV yet.  So I can't say I have any problem with the current
system.  However, I have a lot of faith in Jory as a programmer and I can
see that he has a problem with it.  He has probably spent the most time
working with Tags out of all of us, of course I know he's not the only one
to do anything with them.  As for what should be done, if we are going to
change the format, I vote for XML'izing the tags.  But of course I like XML
.  It would make authoring easy.

Just another thought, how hard would it be to make a simple tool to do
XML->EBML->XML conversion...  If it could be done in a reasonably small
size, we could take tags as XML for input and return them as output in XML,
hiding the EBML side completely for tag editing... just a thought.

Spyder





From paul at msn.com  Sat Dec 20 01:01:51 2003
From: paul at msn.com (Pamel)
Date: Fri, 19 Dec 2003 18:01:51 -0600
Subject: [Matroska-devel] Re: Re: New Simple Matroska Tag System Proposal 2.0
References: <000b01c3bd4e$90c404d0$0200a8c0@jcsston>	<br1527$msf$1@sea.gmane.org><1070874382.28529.65.camel@shrek.bitfreak.net>	<3FD47111.9080202@free.fr><002801c3bda3$9e235360$0200a8c0@jcsston><3FD4D8F1.2060108@free.fr><003801c3bdf4$b153e0c0$0200a8c0@jcsston>	<001901c3c522$7c2b2c70$0200a8c0@jcsston><brrors$94b$1@sea.gmane.org>
	<3FE1EDA0.2040903@hrz.tu-chemnitz.de>
Message-ID: <bs03g7$2su$1@sea.gmane.org>

"Alexander No?" wrote...
> Is your brain working iteratively???
>
> A Tag is either
>    empty
> or
>    a set of <name, value> along with a finite number of Tags

I don't follow you.

> Restricting the maximum depth would make it more complex....

Okay...I assume this would have to do with the above statements?  I believe that
displaying tags that only allow one layer deep would be much easier than an
infinite number of layers.

> Sth else. Someone came up with the terrible idea of making tag names
> being ASCII.

That would be Steve I think.

> Did you ever try to read russian, written in ASCII?? Matroska is full of
> UTF-8 anyway, so why not use it now?

Because there will only be around 25 characters used total for all of the tags.
There is no reason to use UTF-8 in this for the official Matroska tags.  And
restricting it like this means that there is less chance of someone getting the
names wrong.  Besides, aren't ASCII characters the same in UTF-8?


Pamel





From jcsston at wiesneronline.net  Sat Dec 20 10:15:44 2003
From: jcsston at wiesneronline.net (Jory)
Date: Sat, 20 Dec 2003 03:15:44 -0600
Subject: [Matroska-devel] matroska Foobar2k implementation
References: <3FE1EED5.2020408@matroska.org>
Message-ID: <000801c3c6d9$f315c940$0200a8c0@jcsston>

Just to give everyone a short update.
Using the packet_decoder interface in foobar2000 I have a mostly working
matroska reader.
Seeking works and I believe it is sample accurate
It has problems with lacing right now but I think I'll have them fixed soon.
;)
I've played MP3, AAC/MAIN, and AAC/LC which is all the current
packet_decoders.

Jory

----- Original Message -----
From: "Christian HJ Wiesner" <chris at matroska.org>
To: "Discussion about the current and future development of Matroska"
<matroska-devel at lists.matroska.org>; <mpc-devel at freelists.org>;
<jcsston at matroska.org>
Sent: Thursday, December 18, 2003 12:15 PM
Subject: [Matroska-devel] matroska Foobar2k implementation


> Hi Jory,
>
> here an interesting IRC log from #foobar2000 on irc.freenode.net for you
> ( sorry about the short rant in the middle ;-) ) :
>
> --------------------------------------------------------------------------
-------------------------
>
> <DEATH> wrap mp3/mpc into matroska then kill all improvements it gives
> over raw mp3/mpc
> <adiabatic> what's the point of MPC-in-Matroska, anyway?
> <DEATH> mpc seeking ist death
> <DEATH> inefficient
> * CompactDick concurs
> <DEATH> think playing mpc+cue over LAN
> <ChrHJW_Zhengzhou> yup :)
> <DEATH> same goes for mp3
> <CompactDick> you can feel the lag on a slower machine, like my PII 366
> <CompactDick> ogg works fine here
> * ChrHJW_Zhengzhou is still working on his first FLAC + CUE in MKA ed2k
> release, with chapters and other Goodies ...
> <DEATH> i made mpc+cue behave semi-decently when playing from local hdd
> on athlonxp
> <CompactDick> as it should
> <DEATH> but it is still ass in algorithm efficiency terms
> * ChrHJW_Zhengzhou is now known as ChrHJW_Beijing
> <DEATH> ChrHJW_whatever: some people seem to want to implement mka
> support in fb2k using reader api
> <DEATH> that would kill fast seeking
> <ChrHJW_Beijing> i understand this is no good idea ?
> <ChrHJW_Beijing> oh ...
> <DEATH> probably can be hacked to work at all but it is no good
> <ChrHJW_Beijing> who are this people ?
> <ChrHJW_Beijing> can we convince them to make it better ?
> <DEATH> <jcsston> ah, I think I've found the problem. the file class
> handles different 'protocols' file://, http://, etc.(to my
> understanding) if I add a matroska file as a location like
> 'matroska://C:/test.mka' the matroska file class is called :) I'm
> guessing that with the default 'file://' the internal file class was
> handling it
> <DEATH> havent been able to communicate with him
> <DEATH> but he seems to want to emulate reading from a raw mpc file
> <ChrHJW_Beijing> oh, Jory
> <ChrHJW_Beijing> i talk to him
> <DEATH> so no fast seeking for you
> <ChrHJW_Beijing> you have a message for him i can transfer ?
> <DEATH> lemme say this again
> <ChrHJW_Beijing> jcsston at matroska.org
> * ChrHJW_Beijing is logging
> <DEATH> you need some kind of third-party-extendable interface that
> turns mpc/mp3/whatever compressed packets into audio data, right ?
> <DEATH> add your own interface class to fb2k and let others implement it
> <adiabatic> MTRH: A (fairly dated, since there's over a billion of 'em
> now) Monty Python song.
> <DEATH> like i did with packet_decoder in 0.7.6 (for MP4 playback)
> <ChrHJW_Beijing> got you
> <ChrHJW_Beijing> if we add this class, is there a collision with a
> normal MKA reader ?
> <DEATH> if you cant get stuff working with packet_decoder interface i
> have in 0.7.6, write your own interface, and i'll add that interface to
> mp3/mpc/vorbis/aac/whatever decoders in foo_input_std
> <DEATH> ?
> <ChrHJW_Beijing> or can he finish his work to have a first support ?
> <ChrHJW_Beijing> even if its suboptimal that way ?
> <DEATH> lemme flood how mp4 parsing works again
> <DEATH> there is input_mp4 class, which is just like any other input
> <DEATH> but it finds packet_decoder interface that can handle data type
> contained in mp4 file being read
> <DEATH> and uses that decoder
> <DEATH> like writing plugins to a plugin
> <DEATH> ideally, MKA could do the same logic
> <DEATH> main problem is that you need to be able to call different
> (often third-party-supplied) audio decoders, right ?
> <DEATH> anyway, take 0.7.6 mp4 parser as sample code
> <ChrHJW_Beijing> sounds good
> <DEATH> in foo_input_std
> * ChrHJW_Beijing is again wondering about the way jcsston is working ..
> he is always coding first, and communicating afterwards :/ ....
> <DEATH> hmm
> <DEATH> do you have sample commandline decoder or smth
> <DEATH> maybe i should look into implementing that myself
> <DEATH> since this thing will probably get popular
> <DEATH> would be better if this used same decoder API as mp4
> <DEATH> which may involve changes in that api
> <DEATH> bbl
> --------------------------------------------------------------------------
---------------------------
>
>
> _______________________________________________
> Matroska-devel mailing list
> Matroska-devel at lists.matroska.org
> http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel



From paul at msn.com  Sat Dec 20 10:33:28 2003
From: paul at msn.com (Pamel)
Date: Sat, 20 Dec 2003 03:33:28 -0600
Subject: [Matroska-devel] Re: Re: New Simple Matroska Tag System Proposal 2.0
References: <000b01c3bd4e$90c404d0$0200a8c0@jcsston>	<br1527$msf$1@sea.gmane.org><1070874382.28529.65.camel@shrek.bitfreak.net>	<3FD47111.9080202@free.fr><002801c3bda3$9e235360$0200a8c0@jcsston><3FD4D8F1.2060108@free.fr><003801c3bdf4$b153e0c0$0200a8c0@j<brrors$94b$1@sea.gmane.org>
	<001b01c3c594$74b61eb0$0cc8c8c8@johnc2>
Message-ID: <bs14vu$r2j$1@sea.gmane.org>

This got lost the first time, so I hope it doesn't happen again.

"John Cannon" wrote...
> Ummm, why is a string ID anymore dangerous than using an EBML ID?

To enter a non-standard tag when using EBML ID's as identifiers means that you
actually have to change the read/write library to use those new ID's.  For
example, libmatroska.  For a string ID, it would be transparent to libmatroska
so any program could just pass it all sorts of non-standard b0rked strings for
tag names.

> Just another thought, how hard would it be to make a simple tool to do
> XML->EBML->XML conversion...  If it could be done in a reasonably small
> size, we could take tags as XML for input and return them as output in XML,
> hiding the EBML side completely for tag editing... just a thought.

It would be so easy to make this kind of tool that I could almost do it. Almost.


Pamel






From chris at matroska.org  Sat Dec 20 18:49:14 2003
From: chris at matroska.org (Christian HJ Wiesner)
Date: Sat, 20 Dec 2003 18:49:14 +0100
Subject: [Matroska-devel] 1. FLAC in matroska 2. New matroska splitter and
	muxer release ?
Message-ID: <3FE48B9A.4050504@matroska.org>


Hi,

i have some questions about FLAC in matroska, and those will lead to a 
request for a new splitter and muxer relase also ( @ gabest ;)  ) :

1. Mosu has native FLAC muxing working in mkvmerge since some time now ( 
at least .flac file work fine, .ogg gave me errors last time i tried ), 
but unfortunately we cant play them yet on Windows it seems :( . The 
reason for this is that the native FLAC ID 'A_FLAC' is not mapped to the 
GUID of the CoreFLAC decoder filter yet, but according to Toff this is 
in the CVS on sourceforge already, so its maybe just a matter of making 
a new release.

As for jcsston's FLAC encoder filter, there are two issues we should 
resolve IMHO :

- according to the guys from VirtualVCR they cant use the filter for 
capturing yet, because its not listed amongst the audio encoder filters 
in DirectShow yet. I guess this shouldnt be too big of a problem

- its still using 'A_MS/ACM' and a wFormat tag when writing into MKV, 
what i dont like too much to be honest. I dont know if its possible now 
to determin frame boundaries in it, but if this is the case, then there 
should be a way to make Gabest's matroska muxer recognize the filter on 
the input, and to write a native ID instead ?


2. @Gabest,

as mentioned above, is it possible to make a new release of what is in 
CVS currently, so that native FLAC in MKx will work on DirectShow ? 
Also, how big of an effort would it be to update matroska muxer, thus 
that it writes a native FLAC ID when connected to CoreFLAC encoder ( 
http://corecodec.org/projects/coreflac ) ?

Best regards

Christian



From gabest at freemail.hu  Sat Dec 20 19:00:23 2003
From: gabest at freemail.hu (Gabest)
Date: Sat, 20 Dec 2003 19:00:23 +0100
Subject: [Matroska-devel] Re: 1. FLAC in matroska 2. New matroska splitter
	and muxer release ?
References: <3FE48B9A.4050504@matroska.org>
Message-ID: <2b2801c3c723$240620b0$0100a8c0@i2400p4>

> as mentioned above, is it possible to make a new release of what is in
> CVS currently, so that native FLAC in MKx will work on DirectShow ?

Ok, as soon as sf.net comes back online :)

> Also, how big of an effort would it be to update matroska muxer, thus
> that it writes a native FLAC ID when connected to CoreFLAC encoder (
> http://corecodec.org/projects/coreflac ) ?

Right now the acm wave format 0xF1AC is mapped to "A_FLAC" in the source
code. Is that be ok or has anything changed?



From spyder at matroska.org  Sat Dec 20 19:46:02 2003
From: spyder at matroska.org (John Cannon)
Date: Sat, 20 Dec 2003 12:46:02 -0600
Subject: [Matroska-devel] Re: Re: New Simple Matroska Tag System Proposal
	2.0
References: <000b01c3bd4e$90c404d0$0200a8c0@jcsston>	<br1527$msf$1@sea.gmane.org><1070874382.28529.65.camel@shrek.bitfreak.net>	<3FD47111.9080202@free.fr><002801c3bda3$9e235360$0200a8c0@jcsston><3FD4D8F1.2060108@free.fr><003801c3bdf4$b153e0c0$0200a8c0@j
	<bs14vu$r2j$1@sea.gmane.org>
Message-ID: <004501c3c729$85a4ea30$0cc8c8c8@johnc2>

> To enter a non-standard tag when using EBML ID's as identifiers means that
you
> actually have to change the read/write library to use those new ID's.  For
> example, libmatroska.  For a string ID, it would be transparent to
libmatroska
> so any program could just pass it all sorts of non-standard b0rked strings
for
> tag names.

Ok, so you want to make no real standard in a lib itself then, just allow
any tags with any names to be added in the way that Ogg does?  I fail to see
the restriction in this then.  If there is no lib to enforce what goes in
and in what way you can very easily have incompatabilities.  But maybe this
is just all placed on the app developer then which is OK as long as they
conform to the standard.

> > Just another thought, how hard would it be to make a simple tool to do
> > XML->EBML->XML conversion...  If it could be done in a reasonably small
> > size, we could take tags as XML for input and return them as output in
XML,
> > hiding the EBML side completely for tag editing... just a thought.
>
> It would be so easy to make this kind of tool that I could almost do it.
Almost.

Well, it's highly possible but the key point here is how large the code
would be.  As I don't really use tags much except for labeling my music, I
am withdrawing from this discussion :P  Milk is a more pressing matter for
me ;)

Spyder

PS: Outlook is being retarded so if this sends wrong, please forward it, i
will get thunderbird ASAP.




From paul at msn.com  Sat Dec 20 21:51:37 2003
From: paul at msn.com (Pamel)
Date: Sat, 20 Dec 2003 14:51:37 -0600
Subject: [Matroska-devel] Matroska Tag System 2.0 Proposal
Message-ID: <bs2cnc$4pt$1@sea.gmane.org>

Here is a rough draft of the new tag system.  I haven't committed it to
CVS yet because I'm waiting for Jory to change the name of the current
Tag index.html so that changes are tracked in it.

http://www.jkfanclub.com:81/matroska/matroska-cvs-root/doc/website/technical/specs/tagging/index.html

Please note the example XML file as a potential official authoring format.

Also, the EBML IDs need to be checked and probably changed.  I'm
not sure if a whole new Tags element ID wants to be created or not.
Jory says that he could probably have all of the tags automatically
convert when using any of his programs.

The list of Tags is basically complete, but needs a little bit of cleanup
now that they are all multi-level.

I didn't write the maximum number of levels because I don't know what
would be best.

Also note that all tags are either UTF-8 or a binary dump of something
else.  Honestly I would prefer the use of U/INT is several places, but
this is the absolute simplest method.  It leaves it up to the applications
to deal with it, which I'm sure they will be able to do...

Also, the use of UTF-8 for the TagName means that a TagName could
be written in any language.  However, every supported Matroska tag is
only using uppercase Latin characters.  This means that their reading and
writing is the same in ASCII and UTF-8.  That means that a hardware
player could simple read and display the tag names without having to
store the names.  Of course if it tries to display the value of a tag that is
written in Chinese, it would probably just show b0rked characters.

Please try to post any changes quickly so that the Tag changes can be
formalized and Jory can add full tagging support to his fb2k plugin.


Pamel





From unmei at matroska.org  Sat Dec 20 22:50:12 2003
From: unmei at matroska.org (unmei)
Date: Sat, 20 Dec 2003 22:50:12 +0100
Subject: [Matroska-devel] Re: Re: New Simple Matroska Tag System Proposal
	2.0
Message-ID: <3FE4C414.80803@matroska.org>

Pamel wrote:

> Besides, aren't ASCII characters the same in UTF-8?
>
0x00 .. 0x7F (incl. digits, english chars): yes,
things above ("extended ascii", ie $,?,accents): no



From alexander.noe at s2001.tu-chemnitz.de  Sat Dec 20 23:01:13 2003
From: alexander.noe at s2001.tu-chemnitz.de (=?ISO-8859-15?Q?Alexander_No=E9?=)
Date: Sat, 20 Dec 2003 23:01:13 +0100
Subject: [Matroska-devel] Re: Re: New Simple Matroska Tag System Proposal
	2.0
In-Reply-To: <3FE4C414.80803@matroska.org>
References: <3FE4C414.80803@matroska.org>
Message-ID: <3FE4C6A9.9040500@hrz.tu-chemnitz.de>

unmei wrote:

> Pamel wrote:
>
>> Besides, aren't ASCII characters the same in UTF-8?
>>
> 0x00 .. 0x7F (incl. digits, english chars): yes,
> things above ("extended ascii", ie $,?,accents): no 

$ is 0x24 :o


Alex




From paul at msn.com  Sun Dec 21 08:23:31 2003
From: paul at msn.com (Pamel)
Date: Sun, 21 Dec 2003 01:23:31 -0600
Subject: [Matroska-devel] Re: Matroska Tag System 2.0 Proposal
References: <bs2cnc$4pt$1@sea.gmane.org>
Message-ID: <bs3ho3$bj9$1@sea.gmane.org>

Uploaded the proposal to CVS as the tags specs so that everyone can make changes directly to it.


Pamel





From steve.lhomme at free.fr  Mon Dec 22 23:10:59 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Mon, 22 Dec 2003 23:10:59 +0100
Subject: [Matroska-devel] Re: muxed usf
In-Reply-To: <brhbn7$kos$1@sea.gmane.org>
References: <brg632$781$1@sea.gmane.org> <brhbn7$kos$1@sea.gmane.org>
Message-ID: <3FE76BF3.8030100@free.fr>

Pamel wrote:

> EMBED
> **Fonts embedded in XML-USF should be muxed into the MKV file as attachment file
> (and not stored in a <embed> in EBML-USF).
> 
> I would initially say that it would seem most natural to store an embedded font
> in the codec private.  However this have several drawbacks, for instance the
> font would have to be stored several times if it is used in more than one track.

How about portable fonts ? Fonts are usually tied to an OS. So when 
describing a font you should either be able to specify an OS independant 
version (sans-serif, terminal, etc), or different font names and the 
first that matches is selected.

> I think it was discussed earlier that certain things should just go into the
> codec private.  Basically anything that doesn't have a timecode attached to it.
> For instance, the Styles should all be stored in the codecprivate so that you
> know they are all loaded at start time.  This is important because you have no
> garauntee that the first few Blocks of a stream will be loaded if someone
> immediately seeks to the middle of a stream.

The thing with Codec Private is that it's not supported in decoders yet. 
And I'm not sure it can be handled in DirectShow (dunno about MPlayer or 
VLC).



From steve.lhomme at free.fr  Mon Dec 22 23:21:24 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Mon, 22 Dec 2003 23:21:24 +0100
Subject: [Matroska-devel] Re: Re: New Simple Matroska Tag System Proposal
	2.0
In-Reply-To: <bs14vu$r2j$1@sea.gmane.org>
References: <000b01c3bd4e$90c404d0$0200a8c0@jcsston>	<br1527$msf$1@sea.gmane.org><1070874382.28529.65.camel@shrek.bitfreak.net>	<3FD47111.9080202@free.fr><002801c3bda3$9e235360$0200a8c0@jcsston><3FD4D8F1.2060108@free.fr><003801c3bdf4$b153e0c0$0200a8c0@j<brrors$94b$1@sea.gmane.org>	<001b01c3c594$74b61eb0$0cc8c8c8@johnc2>
	<bs14vu$r2j$1@sea.gmane.org>
Message-ID: <3FE76E64.3080202@free.fr>

Pamel wrote:

> This got lost the first time, so I hope it doesn't happen again.
> 
> "John Cannon" wrote...
> 
>>Ummm, why is a string ID anymore dangerous than using an EBML ID?
> 
> 
> To enter a non-standard tag when using EBML ID's as identifiers means that you
> actually have to change the read/write library to use those new ID's.  For
> example, libmatroska.  For a string ID, it would be transparent to libmatroska
> so any program could just pass it all sorts of non-standard b0rked strings for
> tag names.

I don't get the point with String IDs... String IDs stored in EBML 
content ?

[EBML-ID][EBML length][String ID][Data] ?
or
[String ID][EBML length][Data] ?

IMO, both are useless.
EBML allows all kinds of binary data.



From steve.lhomme at free.fr  Mon Dec 22 23:26:18 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Mon, 22 Dec 2003 23:26:18 +0100
Subject: [Matroska-devel] Re: Re: New Simple Matroska Tag System Proposal
	2.0
In-Reply-To: <3FE4C414.80803@matroska.org>
References: <3FE4C414.80803@matroska.org>
Message-ID: <3FE76F8A.5080705@free.fr>

unmei wrote:

> Pamel wrote:
> 
>> Besides, aren't ASCII characters the same in UTF-8?
>>
> 0x00 .. 0x7F (incl. digits, english chars): yes,
> things above ("extended ascii", ie $,?,accents): no

Only 0x20 to 0x7E are displayable in ASCII.



From unmei at matroska.org  Mon Dec 22 23:58:24 2003
From: unmei at matroska.org (unmei)
Date: Mon, 22 Dec 2003 23:58:24 +0100
Subject: [Matroska-devel] Re: muxed usf
In-Reply-To: <3FE76BF3.8030100@free.fr>
References: <brg632$781$1@sea.gmane.org> <brhbn7$kos$1@sea.gmane.org>
	<3FE76BF3.8030100@free.fr>
Message-ID: <3FE77710.4060603@matroska.org>

Steve Lhomme wrote:

> How about portable fonts ? Fonts are usually tied to an OS. So when 
> describing a font you should either be able to specify an OS 
> independant version (sans-serif, terminal, etc), or different font 
> names and the first that matches is selected.

im talking about font files embedded in the USF (not font references). 
You don't usually do this for standard fonts but only for decorative 
ones to make sure the viewer sees it exactly like intended, and afaik 
its only planned for TTF. Of course a renderer should provide a 
mechanism to deal with embedded fonts that are missing/broken/not 
suitable for the OS.

What you mention is done by the use of the attribute font-family. USF 
knows two ways to specify the font: font-face which takes exactly one 
font name and no generic families and font-family which takes a list of 
fonts in preferred order and should include a generic font family (at 
the end of the list).

If you have a embedded font you still have either a font-face, 
font-family or both, which differ in no way from normal such attributes. 
The only difference is that a file is embedded which can be extracted 
and used in the case the font is not available on the target system.
My interpretation is, that a renderer should extract all embedded files 
to a temp, then check which fonts are not yet installed (and install 
them if the user whishes so).
Given a USF with embedded MyFont.ttf and the following font usages (in 
styles or font markup)  family="ms sans serif, sans-serif" and 
family="my font, fantasy".
A windows player would use the system's TTF sans serif for the first and 
for the second it has 3 possibilities: a) the user has already installed 
a font called "my font", it will be used even if it is not the same as 
the embedded one b) no font "my font" installed, the user does not wish 
font auto-install -> the rendered does a font match against fantasy in 
the installed fonts. c) no font "my font" installed, the user allows 
auto-install: the renderer extracts the font, sees its not installed, 
copies the file to windows/fonts/ and makes a corresponding entry in the 
registry (doh!).
On a system, without TTF support (linux?), no font "ms sans serif" 
installed: the first will generate a font matching against "sans-serif" 
and a matching font is used. The second: two possibilites: a) the user 
has a font "my font" installed (not a TTF, but ie a type one with that 
name) -> it will be used even if its something completely different than 
the embedded myFont.ttf b) no font "my font" installed -> font match 
against fantasy.



From steve.lhomme at free.fr  Tue Dec 23 00:08:31 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Tue, 23 Dec 2003 00:08:31 +0100
Subject: [Matroska-devel] Re: muxed usf
In-Reply-To: <3FE77710.4060603@matroska.org>
References: <brg632$781$1@sea.gmane.org>
	<brhbn7$kos$1@sea.gmane.org>	<3FE76BF3.8030100@free.fr>
	<3FE77710.4060603@matroska.org>
Message-ID: <3FE7796F.2090604@free.fr>

unmei wrote:

> Steve Lhomme wrote:
> 
>> How about portable fonts ? Fonts are usually tied to an OS. So when 
>> describing a font you should either be able to specify an OS 
>> independant version (sans-serif, terminal, etc), or different font 
>> names and the first that matches is selected.
> 
> 
> im talking about font files embedded in the USF (not font references). 
 > ...
> against fantasy.

OK, that was just to make it clear. Now it is :)



From paul at msn.com  Tue Dec 23 22:48:30 2003
From: paul at msn.com (Pamel)
Date: Tue, 23 Dec 2003 15:48:30 -0600
Subject: [Matroska-devel] Dropping elements for the Matroska 1.0 spec
Message-ID: <bsad75$83h$1@sea.gmane.org>

In preperation to release a 1.0 specs, we need to remove any unused elements.
Unused elements will be kept in the main specs for as it progresses.  The 1.0
branch will be frozen so that if a file was created 1.0 compliant, any 1.0
compliant reader will be able to play it back (assuming codecs/compression
libs/decryption libs exist).

To do this we want to remove all unused elements from the specs to make
de/muxers as simple as possible.

Examples of things not included in the main specs are the SignatureSlot and
TimeSlice elements.  Neither of these are used at this point in time and so can
be removed from the 1.0 specs.

Here is a list of potential elements to remove from the 1.0 specs.  Please
comment on elements that should be added or removed from the list.
http://www.jkfanclub.com:81/matroska/matroska-cvs-root/doc/website/technical/specs/version1/removedelements.html

For the benefit of all those with b0rked firewalls that don't like port 81, here
is the list.

Element Name Level Class-ID Multi Range Default Type inside element Description
Global elements (used everywhere in the format)
signature
SignatureSlot 1+ [1B][53][86][67] * - - sub-elements Contain signature of some
(coming) elements in the stream.
SignatureAlgo 2+ [7E][8A] - - - u-integer Signature algorithm used (1=RSA,
2=elliptic).
SignatureHash 2+ [7E][9A] - - - u-integer Hash algorithm used (1=SHA1-160,
2=MD5).
SignaturePublicKey 2+ [7E][A5] - - - binary The public key to use with the
algorithm (in the case of a PKI-based signature).
Signature 2+ [7E][B5] - - - binary The signature of the data (until a new.
SignatureElements 2+ [7E][5B] - - - sub-elements Contains elements that will be
used to compute the signature.
SignatureElementList 3+ [7E][7B] * - - sub-elements A list consists of a number
of consecutive elements that represent one case where data is used in signature.
Ex: Cluster|Block|BlockAdditional means that the BlockAdditional of all Blocks
in all Clusters is used for encryption.
SignedElement 4+ [86] * - - binary An element ID whose data will be used to
compute the signature.
end of signature
Cluster
Position 2 [A7] - - - u-integer Position of the Cluster in the segment (0 in
live broadcast streams). It might help to resynchronise offset on damaged
streams.
PrevSize 2 [AB] - - - u-integer Size of the previous Cluster, in octets. Can be
useful for backward playing.
BlockVirtual 3 [A2] * - - binary (see Block Virtual) A Block with no data. It
must be stored in the stream at the place the real Block should be in display
order.
BlockAdditions 3 [75][A1] - - - sub-elements Contain additional blocks to
complete the main one. An EBML parser that has no knowledge of the Block
structure could still see and use/skip these data.
BlockMore 4 [A6] * - - sub-elements Contain the BlockAdditional and some
parameters.
BlockAddID 5 [EE] - - >0 u-integer An ID to identify the BlockAdditional (0 is
the main Block).
BlockAdditional 5 [A5] - - - (see Block) Same structure as a Block interpreted
by the codec as it wishes (using the ID).
ReferenceVirtual 3 [FD] - - - integer Relative position of the data that should
be in position of the virtual block.
CodecState 3 [A4] - - - binary The new codec state to use. Data interpretation
is private to the codec. This information should always be referenced by a seek
entry.
Slices 3 [8E] * - - sub-elements Contains slices description.
TimeSlice 4 [E8] * - - sub-elements Contains extra time information about the
data contained in the Block.
LaceNumber 5 [CC] - - 0 u-integer The reverse number of the frame in the lace (0
is the last frame, 1 is the next to last, etc).
FrameNumber 5 [CD] - - 0 u-integer The number of the frame to generate from this
lace with this delay (allow you to generate many frames from the same
Block/Frame).
BlockAdditionID 5 [CB] - - 0 u-integer The ID of the BlockAdditional element (0
is the main Block).
Delay 5 [CE] - - 0 u-integer The (scaled) delay to apply to the element.
Duration 5 [CF] - - TrackDuration u-integer The (scaled) duration to apply to
the element.
Track
FlagEnabled 3 [B9] - 0-1 1 u-integer (1 bit) Set if the track is used.
FlagDefault 3 [88] - 0-1 1 u-integer (1 bit) Set if the track is the default for
its TrackType.
FlagLacing 3 [9C] - 0-1 1 u-integer (1 bit) Set if the track may contain blocks
using lacing.
MinCache 3 [6D][E7] - - 0 u-integer The minimum number of frames a player should
be able to cache during playback.
MaxCache 3 [6D][F8] - - - u-integer The maximum cache size required to store
referenced frames in and the current frame. 0 means no cache is needed.
CodecSettings 3 [3A][96][97] - - - UTF-8 A string describing the encoding
setting used.
CodecInfoURL 3 [3B][40][40] * - - string A URL to find information about the
codec used.
CodecDownloadURL 3 [26][B2][40] * - - string A URL to download about the codec
used.
CodecDecodeAll 3 [AA] - 0-1 1 u-integer (1 bit) The codec can decode potentially
damaged data.
TrackOverlay 3 [6F][AB] - - - u-integer Specify that this track is an overlay
track for the Track specified (in the u-integer).
video
FlagInterlaced 4 [9A] - 0-1 0 u-integer (1 bit) Set if the video is interlaced.
StereoMode 4 [53][B8] - 0-3 0 u-integer Stereo-3D video mode on 2 bits (0: mono,
1: right eye, 2: left eye, 3: both eyes).
DisplayUnit 4 [54][B2] - - 0 u-integer Type of the unit for DisplayWidth/Height
(0: pixels, 1: centimeters, 2: inches).
AspectRatioType 4 [54][B3] - - 0 u-integer Specify the possible modifications to
the aspect ratio (0: free resizing, 1: keep aspect ratio, 2: fixed).
GammaValue 4 [2F][B5][23] - >0 - float Gamma Value.
end video
audio
OutputSamplingFrequency 4 [78][B5] - >0 8000.0 float Real output sampling
frequency in Hz (used for SBR techniques).
Channels 4 [9F] - not 0 1 u-integer Numbers of channels in the track.
ChannelPositions 4 [7D][7B] - - - binary Table of horizontal angles for each
successive channel, see appendix.
BitDepth 4 [62][64] - not 0 - u-integer Bits per sample, mostly used for PCM.
end audio
content encoding
ContentEncryption 5 [50][35] - - - sub-elements Settings describing the
encryption used. Must be present if the value of ContentEncodingType is 1 and
absent otherwise.
ContentEncAlgo 6 [47][e1] - - 0 u-integer The encryption algorithm used. The
value '0' means that the contents have not been encrypted but only signed.
Predefined values:
1 - DES, 2 - 3DES, 3 - Twofish, 4 - Blowfish, 5 - AES
ContentEncKeyID 6 [47][e2] - - - binary For public key algorithms this is the ID
of the public key the the data was encrypted with.
ContentSignature 6 [47][e3] - - - binary A cryptographic signature of the
contents.
ContentSigKeyID 6 [47][e4] - - - binary This is the ID of the private key the
data was signed with.
ContentSigAlgo 6 [47][e5] - - 0 u-integer The algorithm used for the signature.
A value of '0' means that the contents have not been signed but only encrypted.
Predefined values:
1 - RSA
ContentSigHashAlgo 6 [47][e6] - - 0 u-integer The hash algorithm used for the
signature. A value of '0' means that the contents have not been signed but only
encrypted. Predefined values:
1 - SHA1-160
2 - MD5
end content encoding
Cueing Data
Cues 1 [1C][53][BB][6B] - - - sub-elements A top-level element to speed seeking
access. All entries are local to the segment.
CuePoint 2 [BB] * - - sub-elements Contains all information relative to a seek
point in the segment.
CueTime 3 [B3] - - - u-integer Absolute timecode according to the segment time
base.
CueTrackPositions 3 [B7] * - - sub-elements Contain positions for different
tracks corresponding to the timecode.
CueTrack 4 [F7] - >0 - u-integer The track for which a position is given.
CueClusterPosition 4 [F1] - - - u-integer The position of the Cluster containing
the required Block.
CueBlockNumber 4 [53][87] - not 0 1 u-integer Number of the Block of Track X in
the specified Cluster.
CueCodecState 4 [EA] - - 0 u-integer The position of the Codec State
corresponding to this Cue element. 0 means that the data is taken from the
initial Track Entry.
CueReference 4 [DB] * - - sub-elements The Clusters containing the required
referenced Blocks.
CueRefTime 5 [96] - - - u-integer Timecode of the referenced Block.
CueRefCluster 5 [97] - - - u-integer Position of the Cluster containing the
referenced Block.
CueRefNumber 5 [53][5F] - not 0 1 u-integer Number of the referenced Block of
Track X in the specified Cluster.
CueRefCodecState 5 [EB] - - 0 u-integer The position of the Codec State
corresponding to this referenced element. 0 means that the data is taken from
the initial Track Entry.
Chapters
ChapterTrack 4+ [8F] - - - sub-elements List of tracks on which the chapter
applies. If this element is not present, all tracks apply
ChapterTrackNumber 5+ [89] - >0 - u-integer UID of the track which data are
specified.
ChapLanguage 5+ [43][7C] * - eng string The languages corresponding to the
string, in the ISO-639-2 form.
ChapCountry 5+ [43][7E] * - - string The countries corresponding to the string,
same 2 octets as in Internet domains.





From moritz at bunkus.org  Tue Dec 23 23:33:03 2003
From: moritz at bunkus.org (Moritz Bunkus)
Date: Tue, 23 Dec 2003 23:33:03 +0100
Subject: [Matroska-devel] Dropping elements for the Matroska 1.0 spec
In-Reply-To: <bsad75$83h$1@sea.gmane.org>
References: <bsad75$83h$1@sea.gmane.org>
Message-ID: <20031223223302.GC26077@bunkus.org>

Hi,

I basically agree, but I (and others) already use at least some of
these:


> PrevSize 2 [AB] - - - u-integer Size of the previous Cluster, in octets. Can be
> useful for backward playing.

I think I remember alexnoe saying he uses this, but I'm not sure.

> Slices 3 [8E] * - - sub-elements Contains slices description.

mkvmerge uses the complete slice system if the user enables it with a
cmd line option.

> FlagDefault 3 [88] - 0-1 1 u-integer (1 bit) Set if the track is the default for
> its TrackType.
> FlagLacing 3 [9C] - 0-1 1 u-integer (1 bit) Set if the track may contain blocks
> using lacing.
> MinCache 3 [6D][E7] - - 0 u-integer The minimum number of frames a player should
> be able to cache during playback.
> MaxCache 3 [6D][F8] - - - u-integer The maximum cache size required to store
> referenced frames in and the current frame. 0 means no cache is
> needed.

These four are used every time.

> OutputSamplingFrequency 4 [78][B5] - >0 8000.0 float Real output sampling
> frequency in Hz (used for SBR techniques).

Used for HE-AAC.

> Channels 4 [9F] - not 0 1 u-integer Numbers of channels in the track.

!?

> BitDepth 4 [62][64] - not 0 - u-integer Bits per sample, mostly used for PCM.
> end audio
> content encoding

Used for PCM.

> ContentEncryption 5 [50][35] - - - sub-elements Settings describing the
> encryption used. Must be present if the value of ContentEncodingType is 1 and
> absent otherwise.

and all the sub elements should be left unchanged, mkvmerge/mkvinfo
already uses them.

> ChapterTrack 4+ [8F] - - - sub-elements List of tracks on which the chapter
> applies. If this element is not present, all tracks apply
> ChapterTrackNumber 5+ [89] - >0 - u-integer UID of the track which data are
> specified.
> ChapLanguage 5+ [43][7C] * - eng string The languages corresponding to the
> string, in the ISO-639-2 form.
> ChapCountry 5+ [43][7E] * - - string The countries corresponding to the string,
> same 2 octets as in Internet domains.

Also used by mmg, mkvmerge.

Mosu

-- 
If Darl McBride was in charge, he'd probably make marriage
unconstitutional too, since clearly it de-emphasizes the commercial
nature of normal human interaction, and probably is a major impediment
to the commercial growth of prostitution. - Linus Torvalds


From paul at msn.com  Wed Dec 24 07:31:48 2003
From: paul at msn.com (Pamel)
Date: Wed, 24 Dec 2003 00:31:48 -0600
Subject: [Matroska-devel] Re: Dropping elements for the Matroska 1.0 spec
References: <bsad75$83h$1@sea.gmane.org> <20031223223302.GC26077@bunkus.org>
Message-ID: <bsbbsa$4s5$1@sea.gmane.org>

"Moritz Bunkus" wrote...
> I basically agree, but I (and others) already use at least some of
> these:

Good.  I don't know what elements are used, so I need you guys to fill me in.

> > PrevSize 2 [AB] - - - u-integer Size of the previous Cluster, in octets. Can
be
> > useful for backward playing.
>
> I think I remember alexnoe saying he uses this, but I'm not sure.

I looked in the logs and it looks like Gabest writes them.

> > Slices 3 [8E] * - - sub-elements Contains slices description.
>
> mkvmerge uses the complete slice system if the user enables it with a
> cmd line option.

Okay.  We need this for backwards compatability.  Perhaps a note though that it
there is no need to write it as the benefits are marginal?

> > FlagDefault 3 [88] - 0-1 1 u-integer (1 bit) Set if the track is the default
for
> > ....
> These four are used every time.

Okay.

> > OutputSamplingFrequency 4 [78][B5] - >0 8000.0 float Real output sampling
> > frequency in Hz (used for SBR techniques).
> Used for HE-AAC.

I wasn't sure if you actually used it.

> > ContentEncryption 5 [50][35] - - - sub-elements Settings describing the
> > encryption used. Must be present if the value of ContentEncodingType is 1
and
> > absent otherwise.
>
> and all the sub elements should be left unchanged, mkvmerge/mkvinfo
> already uses them.

I was split because I wasn't sure if this was used at all.  We really need to
update that encryption DS filter to use this field.

> > ChapterTrack 4+ [8F] - - - sub-elements List of tracks on which the chapter
> > ....
> Also used by mmg, mkvmerge.

Okay.

Can anyone tell me what all is used from the Cues?  I honestly don't know much
about this.


Pamel





From steve.lhomme at free.fr  Wed Dec 24 09:43:52 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Wed, 24 Dec 2003 09:43:52 +0100
Subject: [Matroska-devel] Dropping elements for the Matroska 1.0 spec
In-Reply-To: <20031223223302.GC26077@bunkus.org>
References: <bsad75$83h$1@sea.gmane.org> <20031223223302.GC26077@bunkus.org>
Message-ID: <3FE951C8.5040107@free.fr>

Moritz Bunkus wrote:
> Hi,
> 
> I basically agree, but I (and others) already use at least some of
> these:

Cool, that's also the ones I pointed out to Pamel :)



From steve.lhomme at free.fr  Wed Dec 24 09:45:57 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Wed, 24 Dec 2003 09:45:57 +0100
Subject: [Matroska-devel] Re: Dropping elements for the Matroska 1.0 spec
In-Reply-To: <bsbbsa$4s5$1@sea.gmane.org>
References: <bsad75$83h$1@sea.gmane.org> <20031223223302.GC26077@bunkus.org>
	<bsbbsa$4s5$1@sea.gmane.org>
Message-ID: <3FE95245.20709@free.fr>

Pamel wrote:
> Can anyone tell me what all is used from the Cues?  I honestly don't know much
> about this.

Maybe the CueCodecState can be dropped.
And all the CueReference thing too (only if it's not used).




From paul at msn.com  Fri Dec 26 19:18:20 2003
From: paul at msn.com (Paul Bryson)
Date: Fri, 26 Dec 2003 12:18:20 -0600
Subject: [Matroska-devel] Re: Dropping elements for the Matroska 1.0 spec
References: <bsad75$83h$1@sea.gmane.org>
Message-ID: <bshu0h$qo9$1@sea.gmane.org>

"Pamel" wrote...
> In preperation to release a 1.0 specs, we need to remove any unused elements.

Here is the first commit of a 1.0 specs.
http://cvs.corecodec.org/cgi-bin/viewcvs.cgi/*checkout*/matroska/doc/website/technical/specs/version1/index.html
34 less elements, less notes, and a smaller appendix.

The quick list of removed elements is here:
http://cvs.corecodec.org/cgi-bin/viewcvs.cgi/*checkout*/matroska/doc/website/technical/specs/version1/removedelements.html

And yes, I know this *should* be done differently in CVS, but I am a little lazy
at the moment and it can be fixed later.


Paul Bryson





From christian at matroska.org  Sat Dec 27 21:53:30 2003
From: christian at matroska.org (ChristianHJW)
Date: Sat, 27 Dec 2003 21:53:30 +0100
Subject: [Matroska-devel] Re: Common Opensource codec API
In-Reply-To: <20030630185332.49209.qmail@mail.com>
References: <20030630185332.49209.qmail@mail.com>
Message-ID: <3FEDF14A.80805@matroska.org>

@mplayer devs :

guys, what do you think about a new mailing list on your server, where 
everybody interested in the subject, from all the other involved 
projects, can subscribe to ? Its not really making a lot of sense IMO to 
x-post over several MLs to discuss this ( interesting and important ) 
subject ?

What about media-api at mplayerhq.hu

or the like ?

Regards

Christian

Toby Hudon wrote:
> ----- Original Message -----
> From: Leif Johnson <leif at ambient.2y.net>
> Date: Mon, 30 Jun 2003 12:53:36 -0400 
> To: bartscgr at ra.informatik.uni-stuttgart.de
> Subject: Re: [xine-devel] Re: [gst-devel] Re: [UCI-Devel] Re: Common Opensource codec API
> 
> 
>>You all might find some inspiration in LADSPA, a pretty nice audio plugin
>>API hammered out on the linux-audio-dev mailing list : http://ladspa.org/.
>>It's written for audio plugins only, but I thought some of the concepts
>>might be helpful for more generic types of plugins.
>>
>>leif
>>
> 
> 
> Sorry I'm not a linux user so I probably wouldn't be able to do much with it. Can you give me a quick overview?




From christian at matroska.org  Sun Dec 28 10:09:44 2003
From: christian at matroska.org (ChristianHJW)
Date: Sun, 28 Dec 2003 10:09:44 +0100
Subject: [Matroska-devel] Re: Common Opensource codec API
In-Reply-To: <20031228004313.GC257@brightrain.aerifal.cx>
References: <20030629003605.46801.qmail@web12906.mail.yahoo.com>	<Pine.A41.4.44.0306292204360.50932-100000@public.uni-hamburg.de>	<20030629213651.GA17101@goofy.disney.gb>
	<20031228004313.GC257@brightrain.aerifal.cx>
Message-ID: <3FEE9DD8.2030503@matroska.org>

D Richard Felker III wrote:

> On Sun, Jun 29, 2003 at 11:36:52PM +0200, Guenter Bartsch wrote:
>>>>I was working with this kind of design before, but
>>>>nobody seemed interested in doing it. Basicly the
>>>>language of the API layer is immaterial, what
>>>>matters is the messages and data getting passed
>>>>through it (my system used a message/struct 2
>>>>parameter function for everything). 
 >>>>
>>>So we basically wrap this in CORBA then? ;)
>>
>>*lol* ... yeah, overengineering seems to be quite common in those
>>"do-the-right-thing-fixed-forever-joined-effort" style aproaches :>
> 
> This is beyond just "lol". It's more to the point of "let's commit the
> drone who wrote such madness to an asylum". At the risk of getting
> flamed, may I ask if the person who wrote this was a Matroska
> developer?

Toby is not a matroska developer. He is the developer of a codec called 
WARP ( http://corecodec.org/projects/warp ), and he was not capable of 
finishing the codec because he was fighting months with the crappy, 
limited and inflexible VfW API.
WARP needs an interface that does allow it to load a big number of 
frames into a huge buffer, as the main compression algo of WARP will 
work in the time domaine, means on the variation of a single pixel over 
a number of frames.

This codec is very unusual in his basic functionality and Toby had to 
fight with a limited codec API to be able to work with it, so you might 
think that the developer behind it would know how a codec API should be 
looking like to be future compatible.

After all, all our discussions are, again and again, basically going 
about the same matter :

You guys always want to keep things extremely simple and performant, and 
i have no idea why that is. Maybe you cant afford new PCs with 
state-of-the-art CPUs, and are running your boxes on AMD K6's or 
similar, dont know. I have a pretty old Pentium III system, only 800 
MHz, with a 32 MB 4xAGP videocard, and even with crappy, bloated Windows 
+ plus even more bloated, even more crappier matroska i was never ever 
close to have CPU performance problems. So, there seems to be a clear 
conflict of interests, for whatever reason.

matroska people are primarily not interested in the performance of our 
code, not at all. We are thinking 10 years ahead, and compared to the 
necessary decoding power to play a HDTV ( 1280 x 960 ) h.264 ( AVC, 
MPEG4-10 ) video, the CPU cycles you will need to parse a matroska file 
or to use a CORBA wrapped codec API, will just be peanuts, so why should 
we care at all .... ??



>>>Seriously: We need a simple little set of functions that a plugin needs to
>>>implement. If it is not dead simple, nobody will implement it.
>>>That was the important part: If it is not dead simple, nobody will
>>>implement it. And that goes for apps _and_ plugins.
>>
>>my point exactly. this is just about defining simple, easy-to-use apis
>>for various multimedia plugins/modules. i too think we should just
>>define a basic set of functions which each plugin type should support,
>>not more. the api should be extensible, though - both, individual
>>implementations should be able to add fields and functions as well as
>>there should be a possibility to add (probably optional) functions 
>>to the api in the future 
>  
> This is stupid. You can just wrap the code instead. A basic/dumb
> filter will be easy to wrap, and a more complicated one will not
> easily fit into a common api anyway.

Again the same conflict. In your 'boneheaded' concentration on 
simplicity and performance, you are prefering to have an API that cant 
deal with some special filters. For us, a filter API that cant deal with 
*ANY* possible filter we can think of today, is just crap. If it cant 
deal with today's filters, how could you expect the API to hold longer 
than 2 years, with respect to today's development speed ?

I cant get rid of my impression that at least *some* devs here are so 
proud they finally understood how MPEG works ( i dont ;-) ), they are 
now much too focussed on the MPEG way and how things are generally done 
today. You may call matroska bloated and non-performant. Well, maybe 
thats the case. However, i promise you matroska will be still here in 5 
years, it will be looking completely different than today as we had to 
adapt it to the needs of tomorrow, but all old files will still be 100% 
compatible thanks to the very flexible ( = bloated, in your opinion ) 
underlying EBML structure. We'll see ....

>>over the weekend i have looked through mplayer g2's and xine's stream/input
>>and demux module apis and found them to be quite similar - it should
>>definitely be possible to define a common interface here. i'm planning
>>to set up a little website documenting the two aproaches, maybe i'll
>>also look at other media players (not sure how many aproaches i'll be
>>able to keep in my mind simultaneously ;) ). hope this will be a good
>>starting point for a common api
>  
> There will be no common api, unless xine wants to adopt mplayer api.

Fortunately, you are not the one deciding this. I am glad the discussion 
was started again, mainly with respect to Atilla's planned video 
developer meeting in Switzerland next year. I sincerely hope that the 
conversation about a new API will not stop, and that we can move things 
forward until then.

If the mplayer people will not be interested to set up a specific 
mailing list for that, we will do so soon.

> Common api means the EXACT same thing as a common player. If mplayer
> and xine are using the same stream layer, the same demuxer layer, the
> same codec and filter layer, and the same output modules, then the
> ONLY difference between the two is the 10 lines of wrapper code in
> main.c to put it all together. This is beyond idiotic. MPlayer is
> better than the stupid windows crap because it _doesn't_ just wrap
> DirectShow with gui widgets, but instead implements everything itself,
> and does so much more efficiently and more correctly. 
> Rich

Yes, maybe. So finally Linux players could start to improve and try to 
offer all the functionalities that are standard in the Windows world 
since ages. Why that is ? Because the main playback function, however 
crappy and bloated it is implemented, is done nicely by DirectShow and 
player developers can concentrate on improving the user interface and 
add more features, like live capturing, playlists, timeshifting, remote 
control, etc . ....

Christian
matroska project admin
http://www.matroska.org



From moritz at bunkus.org  Sun Dec 28 10:46:31 2003
From: moritz at bunkus.org (Moritz Bunkus)
Date: Sun, 28 Dec 2003 10:46:31 +0100
Subject: [Matroska-devel] new tagging system?
Message-ID: <20031228094631.GL26077@bunkus.org>

Heya,

has there been a _complete_ proposal for the new tagging system?
Including all elements? If yes, could someone please point me to it, and
if not, could someone (Jory?) please make one as soon as possible? So
far I've "only" seen a healthy discussion about it and its finer points,
but nothing solid...

Thanks :)

Mosu

-- 
If Darl McBride was in charge, he'd probably make marriage
unconstitutional too, since clearly it de-emphasizes the commercial
nature of normal human interaction, and probably is a major impediment
to the commercial growth of prostitution. - Linus Torvalds


From alexander.noe at s2001.tu-chemnitz.de  Sun Dec 28 11:31:53 2003
From: alexander.noe at s2001.tu-chemnitz.de (alexander.noe at s2001.tu-chemnitz.de)
Date: Sun, 28 Dec 2003 11:31:53 +0100
Subject: [Matroska-devel] Re: Dropping elements for the Matroska 1.0 spec
In-Reply-To: <bsbbsa$4s5$1@sea.gmane.org>
References: <bsad75$83h$1@sea.gmane.org> <20031223223302.GC26077@bunkus.org>
	<bsbbsa$4s5$1@sea.gmane.org>
Message-ID: <1072607513.3feeb11949620@mail.tu-chemnitz.de>

Zitat von Pamel <paul at msn.com>:

>>> PrevSize 2 [AB] - - - u-integer Size of the previous Cluster, in octets.
>>> Can be useful for backward playing.
>>
>> I think I remember alexnoe saying he uses this, but I'm not sure.
> 
> I looked in the logs and it looks like Gabest writes them.

AVI-Mux GUI can be configured to write them, which is the standard
setting.

>>> Slices 3 [8E] * - - sub-elements Contains slices description.
>>
>> mkvmerge uses the complete slice system if the user enables it with a
>> cmd line option.
> 
> Okay.  We need this for backwards compatability.  Perhaps a note though that
> it
> there is no need to write it as the benefits are marginal?

Huh? Marginal would be > 0 .... I don't see any use at all for those.
But yes, they need to be kept for backward compatibility.

> > > OutputSamplingFrequency 4 [78][B5] - >0 8000.0 float Real output
> sampling
> > > frequency in Hz (used for SBR techniques).
> > Used for HE-AAC.

*Introduced* for HE-AAC
 



Alex


From alexander.noe at s2001.tu-chemnitz.de  Sun Dec 28 11:45:54 2003
From: alexander.noe at s2001.tu-chemnitz.de (alexander.noe at s2001.tu-chemnitz.de)
Date: Sun, 28 Dec 2003 11:45:54 +0100
Subject: [Matroska-devel] Dropping elements for the Matroska 1.0 spec
In-Reply-To: <bsad75$83h$1@sea.gmane.org>
References: <bsad75$83h$1@sea.gmane.org>
Message-ID: <1072608354.3feeb4625783a@mail.tu-chemnitz.de>

Zitat von Pamel <paul at msn.com>:

> Cluster
> Position 2 [A7] - - -

Also written by AVI-Mux GUI, if activated (default)
http://www-user.tu-chemnitz.de/~noe/Video-Zeug/AVIMux%20GUI/en_output_options_window.html

> BlockVirtual 3 [A2] * - - binary (see Block Virtual) A Block with no data.

Actually, I recently thought about using BlockVirtual for some kind
of editing: You could e.g. edit a subtitle block, making it longer,
and replace the next block by a virtual block while moving the real block
to the end of the file.
Even though this is not yet possible with any editor, fixing a typo in
a subtitle block without rewriting the entire file (and maybe extracting
the subtitle before) would be nice.

> FlagDefault 3 [88]

Should be kept: 
<dreaming>
If no subtitle track has this flag, no subtitle should be played
by default. Each track having this flag should be played by default
(e.g. I want the elvish-only subtitle in LOTR by default, but
certainly not a complete subtitle, if there is only a complete one)
</dreaming>

> FlagLacing 3 [9C] 

My matroska code already writes warnings if it detects a laced block
in a stream where the lacing flag is not set.

> Channels 4 [9F] 

Where else would you want to get the number of channels from?





Alex


From paul at msn.com  Sun Dec 28 13:13:09 2003
From: paul at msn.com (Paul Bryson)
Date: Sun, 28 Dec 2003 06:13:09 -0600
Subject: [Matroska-devel] Re: new tagging system?
References: <20031228094631.GL26077@bunkus.org>
Message-ID: <bsmhbg$ti0$1@sea.gmane.org>

"Moritz Bunkus" wrote...
> has there been a _complete_ proposal for the new tagging system?
> Including all elements? If yes, could someone please point me to it, and
> if not, could someone (Jory?) please make one as soon as possible? So
> far I've "only" seen a healthy discussion about it and its finer points,
> but nothing solid...

Well, there was mostly just discussion in IRC, on HydrogenAudio, and on the ML.
In  case you missed it, I copied an email that I sent to the ML below.  I later
sent another email saying I had committed to CVS.  You should be able to read
the specs from there now.  But comments are still wanted.


Pamel

Old email:
Here is a rough draft of the new tag system.  I haven't committed it to
CVS yet because I'm waiting for Jory to change the name of the current
Tag index.html so that changes are tracked in it.

http://www.jkfanclub.com:81/matroska/matroska-cvs-root/doc/website/technical/specs/tagging/index.html

Please note the example XML file as a potential official authoring format.

Also, the EBML IDs need to be checked and probably changed.  I'm
not sure if a whole new Tags element ID wants to be created or not.
Jory says that he could probably have all of the tags automatically
convert when using any of his programs.

The list of Tags is basically complete, but needs a little bit of cleanup
now that they are all multi-level.

I didn't write the maximum number of levels because I don't know what
would be best.

Also note that all tags are either UTF-8 or a binary dump of something
else.  Honestly I would prefer the use of U/INT is several places, but
this is the absolute simplest method.  It leaves it up to the applications
to deal with it, which I'm sure they will be able to do...

Also, the use of UTF-8 for the TagName means that a TagName could
be written in any language.  However, every supported Matroska tag is
only using uppercase Latin characters.  This means that their reading and
writing is the same in ASCII and UTF-8.  That means that a hardware
player could simple read and display the tag names without having to
store the names.  Of course if it tries to display the value of a tag that is
written in Chinese, it would probably just show b0rked characters.

Please try to post any changes quickly so that the Tag changes can be
formalized and Jory can add full tagging support to his fb2k plugin.


Pamel





From attila at kinali.ch  Sun Dec 28 16:28:38 2003
From: attila at kinali.ch (Attila Kinali)
Date: Sun, 28 Dec 2003 16:28:38 +0100
Subject: [Matroska-devel] Re: [MPlayer-dev-eng] Re: Common Opensource codec
	API
In-Reply-To: <3FEE9DD8.2030503@matroska.org>
References: <20030629003605.46801.qmail@web12906.mail.yahoo.com>
	<Pine.A41.4.44.0306292204360.50932-100000@public.uni-hamburg.de>
	<20030629213651.GA17101@goofy.disney.gb>
	<20031228004313.GC257@brightrain.aerifal.cx>
	<3FEE9DD8.2030503@matroska.org>
Message-ID: <20031228162838.117a3a72.attila@kinali.ch>

On Sun, 28 Dec 2003 10:09:44 +0100
ChristianHJW <christian at matroska.org> wrote:


> You guys always want to keep things extremely simple and performant, and 
> i have no idea why that is. Maybe you cant afford new PCs with 
> state-of-the-art CPUs, and are running your boxes on AMD K6's or 
> similar, dont know. I have a pretty old Pentium III system, only 800 
> MHz, with a 32 MB 4xAGP videocard, and even with crappy, bloated Windows 
> + plus even more bloated, even more crappier matroska i was never ever 
> close to have CPU performance problems. So, there seems to be a clear 
> conflict of interests, for whatever reason.

ROTFL

Sorry, but that's just...
You know, a program needs to run as fast as possible, no matter what
it does, otherwise we end up waiting for the computer and justify
Wirth's law ("programs slow down faster than computers get faster").
Beside, not everyone has the money to buy a top computer like you do.
You may dont know that computer components cost more (2-3 times more)
in countries like Turkey than they do here (not to mention that they
earn 10 times less). Your comment reminds me Marie Anntoinette's
"Why dont they eat cakes if they dont have bread ?". It has the same
ignorant and arrogant sound.

> matroska people are primarily not interested in the performance of our 
> code, not at all. We are thinking 10 years ahead, and compared to the 
> necessary decoding power to play a HDTV ( 1280 x 960 ) h.264 ( AVC, 
> MPEG4-10 ) video, the CPU cycles you will need to parse a matroska file 
> or to use a CORBA wrapped codec API, will just be peanuts, so why should 
> we care at all .... ??

Yes, we also design for the future, but keep in mind that the time
for THz processors hasn't yet come. A good engineer always gets
the best performance out of a machine without sacrifizing functionality,
but at the same time he doesnt overcomplicate things just because
it might be usefull in an unknown future.


 
> I cant get rid of my impression that at least *some* devs here are so 
> proud they finally understood how MPEG works ( i dont ;-) ), they are 
> now much too focussed on the MPEG way and how things are generally done 
> today. You may call matroska bloated and non-performant. Well, maybe 
> thats the case. However, i promise you matroska will be still here in 5 
> years, it will be looking completely different than today as we had to 
> adapt it to the needs of tomorrow, but all old files will still be 100% 
> compatible thanks to the very flexible ( = bloated, in your opinion ) 
> underlying EBML structure. We'll see ....

Ok, just have a look a the code (i hope you can read code)
demux_avi.c is around 850 lines of code and contains everything
needed for avi demuxing.
demux_mkv.c is over 3100 lines of code, which are mostly hard to understand
(IMHO) and is only a wrapper for the matroska libs which themself contain
again about 10k lines of code. I know, mkvs functionality is much higher
than avis, but imho it doesnt justify 13k lines of code (in comparison to
this, demux_nut.c from G2 is just 500 loc and has about the same functionality)
and a 1:3 ratio of loc in the libs and corresbonding code in the program itself
is for me sign that something fundamental went wrong. Maybe someone (with
the heart of an engineer) should write a pure c implementation of your 
libs to see whether it's the design of mkv or just the libs.

 
> Fortunately, you are not the one deciding this. I am glad the discussion 
> was started again, mainly with respect to Atilla's planned video 
> developer meeting in Switzerland next year. I sincerely hope that the 
> conversation about a new API will not stop, and that we can move things 
> forward until then.

Just go on...
 

> > Common api means the EXACT same thing as a common player. If mplayer
> > and xine are using the same stream layer, the same demuxer layer, the
> > same codec and filter layer, and the same output modules, then the
> > ONLY difference between the two is the 10 lines of wrapper code in
> > main.c to put it all together. This is beyond idiotic. MPlayer is
> > better than the stupid windows crap because it _doesn't_ just wrap
> > DirectShow with gui widgets, but instead implements everything itself,
> > and does so much more efficiently and more correctly. 
> > Rich
> 
> Yes, maybe. So finally Linux players could start to improve and try to 
> offer all the functionalities that are standard in the Windows world 
> since ages. Why that is ? Because the main playback function, however 
> crappy and bloated it is implemented, is done nicely by DirectShow and 
> player developers can concentrate on improving the user interface and 
> add more features, like live capturing, playlists, timeshifting, remote 
> control, etc . ....

Then why do more and more windows user use mplayer eventhough there
is no nice gui available on windows ? 


				Attila Kinali
-- 
egp ist vergleichbar mit einem ikea bausatz fuer flugzeugtraeger
			-- reeler in +kaosu


From moritz at bunkus.org  Sun Dec 28 17:03:26 2003
From: moritz at bunkus.org (Moritz Bunkus)
Date: Sun, 28 Dec 2003 17:03:26 +0100
Subject: [Matroska-devel] implemented new tagging into libmatroska
Message-ID: <20031228160326.GM26077@bunkus.org>

Heya,

the new specs look ok to me, and the EbmlIDs are ok as well. I've taken
the liberty of implementing support for these elements in
libmatroska. The version number has been bumped to
0.6.2. libmatroska/test/tags/test9.cpp also includes code for these new
tags. mkvinfo can already display them (changes will be cheked into SVN
in a minute).

Mosu

-- 
If Darl McBride was in charge, he'd probably make marriage
unconstitutional too, since clearly it de-emphasizes the commercial
nature of normal human interaction, and probably is a major impediment
to the commercial growth of prostitution. - Linus Torvalds


From moritz at bunkus.org  Sun Dec 28 17:05:05 2003
From: moritz at bunkus.org (Moritz Bunkus)
Date: Sun, 28 Dec 2003 17:05:05 +0100
Subject: [Matroska-devel] okok..
Message-ID: <20031228160505.GN26077@bunkus.org>

...I should have checked, support was already
present. Sorry. Nevertheless I'll update test9.cpp and the version
number.

-- 
If Darl McBride was in charge, he'd probably make marriage
unconstitutional too, since clearly it de-emphasizes the commercial
nature of normal human interaction, and probably is a major impediment
to the commercial growth of prostitution. - Linus Torvalds


From steve.lhomme at free.fr  Sun Dec 28 18:15:39 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Sun, 28 Dec 2003 18:15:39 +0100
Subject: [Matroska-devel] Re: Dropping elements for the Matroska 1.0 spec
In-Reply-To: <bshu0h$qo9$1@sea.gmane.org>
References: <bsad75$83h$1@sea.gmane.org> <bshu0h$qo9$1@sea.gmane.org>
Message-ID: <3FEF0FBB.9090205@free.fr>

Paul Bryson wrote:

> "Pamel" wrote...
> 
>>In preperation to release a 1.0 specs, we need to remove any unused elements.
> 
> 
> Here is the first commit of a 1.0 specs.
> http://cvs.corecodec.org/cgi-bin/viewcvs.cgi/*checkout*/matroska/doc/website/technical/specs/version1/index.html
> 34 less elements, less notes, and a smaller appendix.
> 
> The quick list of removed elements is here:
> http://cvs.corecodec.org/cgi-bin/viewcvs.cgi/*checkout*/matroska/doc/website/technical/specs/version1/removedelements.html
> 
> And yes, I know this *should* be done differently in CVS, but I am a little lazy
> at the moment and it can be fixed later.

Mmm, I should have told you before. You should have used the HTML 
comment not to display the elements removed. But keep them in the source 
file for later use... If everyone agree I'll merge the new and old 
version this way.



From moritz at bunkus.org  Sun Dec 28 18:22:03 2003
From: moritz at bunkus.org (Moritz Bunkus)
Date: Sun, 28 Dec 2003 18:22:03 +0100
Subject: [Matroska-devel] Re: Dropping elements for the Matroska 1.0 spec
In-Reply-To: <3FEF0FBB.9090205@free.fr>
References: <bsad75$83h$1@sea.gmane.org> <bshu0h$qo9$1@sea.gmane.org>
	<3FEF0FBB.9090205@free.fr>
Message-ID: <20031228172203.GO26077@bunkus.org>

Hi,

sounds good.

Mosu

-- 
If Darl McBride was in charge, he'd probably make marriage
unconstitutional too, since clearly it de-emphasizes the commercial
nature of normal human interaction, and probably is a major impediment
to the commercial growth of prostitution. - Linus Torvalds


From steve.lhomme at free.fr  Sun Dec 28 18:28:33 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Sun, 28 Dec 2003 18:28:33 +0100
Subject: [Matroska-devel] Re: Common Opensource codec	API
In-Reply-To: <20031228162838.117a3a72.attila@kinali.ch>
References: <20030629003605.46801.qmail@web12906.mail.yahoo.com>	<Pine.A41.4.44.0306292204360.50932-100000@public.uni-hamburg.de>	<20030629213651.GA17101@goofy.disney.gb>	<20031228004313.GC257@brightrain.aerifal.cx>	<3FEE9DD8.2030503@matroska.org>
	<20031228162838.117a3a72.attila@kinali.ch>
Message-ID: <3FEF12C1.3060104@free.fr>

I haven't read all threads of all MLs (yes, a central point to discuss 
that would be a good idea). But let me explain in short why I think a 
standardisation, not just of the codec system, is needed.

* It's about not reinventing the wheel for every new project (we all 
made mistakes that can now be avoided to others).
* It's about making sure that if a project becomes dead all the work 
done on it can be reused easily on another one.
* It's to make sure that once a project get a new feature all other ones 
can quickly benefit from it.

Instead of sterile competition between each other (all going the same 
way but in parallel not incrementally), we'd rather compete with 
commercial products (Quicktime+iTunes, Windows multimedia computers, etc).




From spyder at matroska.org  Sun Dec 28 19:25:25 2003
From: spyder at matroska.org (John Cannon)
Date: Sun, 28 Dec 2003 12:25:25 -0600
Subject: [Matroska-devel] Re: [MPlayer-dev-eng] Re: Common Opensource
	codec	API
In-Reply-To: <20031228162838.117a3a72.attila@kinali.ch>
References: <20030629003605.46801.qmail@web12906.mail.yahoo.com>	<Pine.A41.4.44.0306292204360.50932-100000@public.uni-hamburg.de>	<20030629213651.GA17101@goofy.disney.gb>	<20031228004313.GC257@brightrain.aerifal.cx>	<3FEE9DD8.2030503@matroska.org>
	<20031228162838.117a3a72.attila@kinali.ch>
Message-ID: <3FEF2015.4090701@matroska.org>

Attila Kinali wrote:

>
>Then why do more and more windows user use mplayer eventhough there
>is no nice gui available on windows ? 
>  
>

I like mplayer because of it's simplicity and it's support for nearly 
anything I throw at it.  Can we please stop bashing everything and focus 
on the API topic :)  I have started playing with an API myself but I 
know it's far from perfect.  And surely you all will find something 
wrong with the way I implemented it.  But it's not aimed (at least by 
me) to be THE ultimate solution to this problem.  I just wanted to make 
my own encoder app.  While designing this, I have noticed that 
libavcodec and libavformat are nice but still a little lacking.  
libavformat is getting better IMO with the introduction of the 
read_frame functions.  As far as I can see, neither is pluggable, 
allowing codecs or demuxers/muxers to be added later which is a little 
limiting IMO.  My little API simply makes a miniature COM-like interface 
for shared libraries to allow plugin loading.  It's very small and 
simple IMO.  Of course it's not as simple as a plain C library but it 
provides a bit more flexibility.  Right now I only have demuxer and 
muxer interfaces defined though.  And I use a C++ wrapper on the 
application side so I know you will hate that  ;)

John Cannon
Matroska Team

PS: I think the reason libmatroska is so large is that it is aimed at 
easy extension and not so much toward small code size.  Of course it can 
be smaller, see BBB's C muxer/demuxer for gstreamer.  libmatroska uses a 
lot of templates and stuff which i get confused by but it's all meant to 
be a reference implementation, one that correctly builds and handles 
matroska.  Gabest and alexnoe have bothe coded their own implementations 
and I am quite sure they're less than 10k lines of code.



From rbultje at ronald.bitfreak.net  Sun Dec 28 19:35:37 2003
From: rbultje at ronald.bitfreak.net (Ronald Bultje)
Date: Sun, 28 Dec 2003 19:35:37 +0100
Subject: [Matroska-devel] Re: [MPlayer-dev-eng] Re: Common Opensource
	codec	API
In-Reply-To: <3FEF2015.4090701@matroska.org>
References: <20030629003605.46801.qmail@web12906.mail.yahoo.com>
	<Pine.A41.4.44.0306292204360.50932-100000@public.uni-hamburg.de>
	<20030629213651.GA17101@goofy.disney.gb>
	<20031228004313.GC257@brightrain.aerifal.cx>
	<3FEE9DD8.2030503@matroska.org>
	<20031228162838.117a3a72.attila@kinali.ch>
	<3FEF2015.4090701@matroska.org>
Message-ID: <1072636536.25156.245.camel@shrek.bitfreak.net>

Hi all,

On Sun, 2003-12-28 at 19:25, John Cannon wrote:
> see BBB's C muxer/demuxer for gstreamer.

[rbultje at shrek gst-plugins]$ cat gst-libs/gst/riff/riff-read.[ch]
gst/avi/gstavidemux.[ch] | wc -l
   2630
[rbultje at shrek gst-plugins]$ cat gst/matroska/ebml-read.[ch]
gst/matroska/matroska-demux.[ch] | wc -l
   3684

Which I intend to port to ffmpeg (but somewhat differently, for your
pleasure). My GStreamer-coding style is quite different from ffmpeg (I
use more empty lines, less loops, more case/switch stuff, many different
functions for small things - all aimed at less maintainance, not less
code), so I'm guessing I can bring it down to 1500-2000 lines of code if
I adapt style a bit (comparable to the quicktime reader, for example).
Should be acceptable, no?

Anyway, I heard Xine is also developping all this, so I'm interested in
how they do this.

Ronald

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



From christian at matroska.org  Sun Dec 28 23:36:39 2003
From: christian at matroska.org (ChristianHJW)
Date: Sun, 28 Dec 2003 23:36:39 +0100
Subject: [Matroska-devel]  Common Opensource codec API
In-Reply-To: <3FEE9DD8.2030503@matroska.org>
References: <20030629003605.46801.qmail@web12906.mail.yahoo.com>	<Pine.A41.4.44.0306292204360.50932-100000@public.uni-hamburg.de>	<20030629213651.GA17101@goofy.disney.gb>	<20031228004313.GC257@brightrain.aerifal.cx>
	<3FEE9DD8.2030503@matroska.org>
Message-ID: <3FEF5AF7.7090403@matroska.org>

Hi again,

this email is the last one that i will x-post to several lists. We set 
up a new ML specifically for the subject of the new media API, email 
adress of the list is

media-api AT lists.matroska.org

For subscription goto http://lists.matroska.org ( mailman ), and 
everybody who is really interested in this subject is invited to do so. 
One of the biggest benefits of this new list is that Mr. Felker will 
hopefully not subscribe to it, so i dont have to read his brainless and 
insulting '... we mplayer devs are the best, all others suck... ' BS.

Marco Gaddoni wrote:
 > mmm ... a programmer not striving for simplicity ....
 > I fear your code.
 > I am unsatisfied with ogm and wanted to give a try
 > to the mkv thing but now i am thinking again.
 > (Has anyone tryed quicktime .mov or mp4 ?)
 > I humbly suggest you (and every other programmer
 > that has not yet done) to read
 >
 > The Practice of Programming
 > by Brian W. Kernighan (Author), Rob Pike (Author)
 > ISBN: 020161586X

Marco,
to make this clear, i am *NOT* a developer myself. I am just a helping 
hand for the matroska team, and i care about the website from time to 
time ( yes, i know it needs an update badly ;-) ). I know i am talking 
with a different language than you developers sometimes, but this is 
simply because i see things with the eyes of the *USER*, and i hope the 
matroska devs will confirm that this is sometimes pretty helpful. After 
all, its the *USERS* who decide if a program is good or bad, not the 
developers making it or the coding style that was used.
About the book you were suggesting, i can tell you that the people 
working in the matroska team are certainly aware of the principles of 
good programming. But, if we have to make a decision between a powerful 
container, feature rich and user friendly, with full unicode support for 
international use, and a poor and simple extension to the current MPEG 
container with low CPU usage, we know what we are going for.
I made a couple of test. I was loading a normal MKV, with one XviD video 
track, one audio track and 2 subtitle tracks, in VirtualdubMod, and 
remuxed it into a new MKV file by leaving away one of the subs tracks. 
This requires a complete demux/mux , as the new file will have a 
different number of tracks and therefore completely new headers, etc. 
Here the result of the tests on my PIII 800 Mhz with a normal SD-RAM :
Muxing Speed : 850 fps
CPU load : ca. 30% ( for both demux and mux with libmatroska in both 
cases, plus editing in VirtualdubMod )
In short, i think its allowed to say that under normal circumstances the 
playback of this file with 25 fps will use less than 1% CPU in any case, 
and this was if 'bloated' libmatroska was used for that. In reality 
there are at least 4 existing faster playback libs now, and 3 of them 
are in C ( soon in FFMPEG ). So, if anybody tells you that matroska is 
bloated and playback is using too much CPU power, tell him to shut up.
For your information, since last week there is an alpha of PocketMVP 
with matroska support, using BBB's C library. So, matroska playback on 
PocketPCs should soon become reality. Any more doubts with respect to 
'performance' ???

Attila Kinali wrote:
 > ROTFL
 > Sorry, but that's just...
 > You may dont know that computer components cost more (2-3 times more)
 > in countries like Turkey than they do here (not to mention that they
 > earn 10 times less). Your comment reminds me Marie Anntoinette's
 > "Why dont they eat cakes if they dont have bread ?". It has the same
 > ignorant and arrogant sound.

Sorry, i didnt mean to sound arrogant, not at all. Just as a quick test, 
i was installing the latest matroska packs on the laptop of my son ( 
PIII 650, 128 MB RAM, 12 GB HDD, 16 MB video ) that i had bought him for 
his learning programs for his 5th b-day ( did cost me 150,- ?, used and 
in bad shape, from my company ). I could easily play a MKV file with RV9 
( RealVideo 9 ) in 708 x 432 ( anamorphic ) and HE-AAC. CPU load was 
constantly above 80%, true, but the file played fine. As stated above, 
even PocketPCs can now play MKV files, admittedly using a nice and slim 
C lib and not libmatroska, so what more do you guys want ?

Anyhow, in my original email i wanted to make clear that a common API 
might help to improve development of opensource projects a lot, and this 
means not only players, but also codecs and editors, and the possible 
constraints on performance should be neglectible, and well worth the 
advantages we get.

Again, this was my personal opinion, and everybody sharing it is happily 
invited to continue discussion on the new mailing list mentioned on the 
top of this email.

Best regards

Christian
matroska project admin
http://www.matroska.org



From gldm at mail.com  Mon Dec 29 06:33:18 2003
From: gldm at mail.com (Toby Hudon)
Date: Mon, 29 Dec 2003 00:33:18 -0500
Subject: [Matroska-devel] Re: [UCI-Devel] Re: [MPlayer-dev-eng] Re: Common
	Opensource codec API
Message-ID: <20031229053318.54344.qmail@mail.com>


----- Original Message -----
From: Attila Kinali <attila at kinali.ch>
Date: Sun, 28 Dec 2003 16:28:38 +0100
To: mplayer-dev-eng at mplayerhq.hu
Subject: [UCI-Devel] Re: [MPlayer-dev-eng] Re: Common Opensource codec API

> On Sun, 28 Dec 2003 10:09:44 +0100
> ChristianHJW <christian at matroska.org> wrote:
> 
> 
> > You guys always want to keep things extremely simple and performant, and 
> > i have no idea why that is. Maybe you cant afford new PCs with 
> > state-of-the-art CPUs, and are running your boxes on AMD K6's or 
> > similar, dont know. I have a pretty old Pentium III system, only 800 
> > MHz, with a 32 MB 4xAGP videocard, and even with crappy, bloated Windows 
> > + plus even more bloated, even more crappier matroska i was never ever 
> > close to have CPU performance problems. So, there seems to be a clear 
> > conflict of interests, for whatever reason.
> 
> ROTFL
> 
> Sorry, but that's just...
> You know, a program needs to run as fast as possible, no matter what
> it does, otherwise we end up waiting for the computer and justify
> Wirth's law ("programs slow down faster than computers get faster").
> Beside, not everyone has the money to buy a top computer like you do.
> You may dont know that computer components cost more (2-3 times more)
> in countries like Turkey than they do here (not to mention that they
> earn 10 times less). Your comment reminds me Marie Anntoinette's
> "Why dont they eat cakes if they dont have bread ?". It has the same
> ignorant and arrogant sound.
> 

No, not everything needs to run as fast as possible if it has too many other tradeoffs. If it did then why aren't you hand coding everything in assembly instead of wasting your time with things like C?

I can't speak for Matroska's design because I'm not all that familliar with it, but I designed my project with readibility of code and scalability of the algorithm and the entire thing including the interface isn't even 3100 lines if I remember right.

Moore's law makes CPU speed effectively infinite given enough time. Programmer man-hours however, will always be finite. Designing systems that are easy to understand and extend makes them easier to go back and optimize or improve later. Speed can be important but writing it so it can be understood, even if you go back and comment that to put in a faster implementation, is often even more important.
-- 
___________________________________________________________
Sign-up for Ads Free at Mail.com
http://promo.mail.com/adsfreejump.htm



From paul at msn.com  Mon Dec 29 07:17:27 2003
From: paul at msn.com (Paul Bryson)
Date: Mon, 29 Dec 2003 00:17:27 -0600
Subject: [Matroska-devel] Re: [UCI-Devel] Re: [MPlayer-dev-eng] Re:
	CommonOpensource codec API
References: <20031229053318.54344.qmail@mail.com>
Message-ID: <bsogsd$5eq$1@sea.gmane.org>

"Toby Hudon" wrote...
> No, not everything needs to run as fast as possible if it has too many other
tradeoffs. If it did then why aren't you hand coding everything in assembly
instead of wasting your time with things like C?

Oh so true.  This type of thing works like a regression curve.  Devoting more
time to it reaches a point of diminishing returns where the time that you spend
increasing speed is so much larger than the marginal increases in speed that you
are getting, especially compared with the total speed.  Its a point of
diminishing returns.  The secret is to simply find that sweet spot on the curve
where the time that you are devoting is being used to create code of SUFFICIENT
speed.

> Moore's law makes CPU speed effectively infinite given enough time. Programmer
man-hours however, will always be finite. Designing systems that are easy to
understand and extend makes them easier to go back and optimize or improve
later. Speed can be important but writing it so it can be understood, even if
you go back and comment that to put in a faster implementation, is often even
more important.

Ah, Toby.  This is why I love reading what you write.  You have such a talent
for the metaphysical.


Pamel

BTW, Toby where have you been?  I was hoping you would show up to help spyder482
with his API.





From paul at msn.com  Mon Dec 29 09:42:37 2003
From: paul at msn.com (Paul Bryson)
Date: Mon, 29 Dec 2003 02:42:37 -0600
Subject: [Matroska-devel] ContentEncodings element use in DirectShow
Message-ID: <bsopcl$f38$1@sea.gmane.org>

http://matroska.corecodec.org/technical/specs/index.html#ContentEncodings

There is not currently a way for any DirectShow filter to take advantage of this
element.  In theory, you should be able to have several generic DirectShow
filters that each handle encryption and compression.  When a file is loaded that
uses encryption/compression on one of the streams, the appropriate
encryption/compression filters are loaded for that stream in the order indicated
with the ContentEncodingOrder element.

IE, if a video stream has zlib, Blowfish, and lzo1x on it in that order, then
the resulting graph should look something like this:

Matrsoka Splitter
    |
zlib decompressor
    |
Blowfish decrypter
    |
lzo1x decompressor
    |
ffdshow
    |
Video Renderer

The process is that the Matroska Splitter has to expose a pin that only the zlib
compressor will connect to.  Then it has to pass it all of the initialization
data for the codec and decompressor, and all other encryption/compression
filters in the chain.  Then that filter needs to expose a pin that passes the
same data on, minus the data needed for itself. And the process continues until
the last encryption/compression filter exposes the normal pin for the
decompressor allowing the data to be decoded.

The problem is that I don't think there is any standard way to pass on this kind
of data.

I bugged Jory about creating a decryption filter that can do this but it would
be nice to know if there are any existing DirectShow standards that would cover
what would be required for this.  Also, if anyone has any ideas on a good way to
get this done, that would be great.  This is one of the features that should be
working for the Matroska 1.0 specs release so any help to speed it along would
be great.


Pamel





From moritz at bunkus.org  Tue Dec 30 10:57:12 2003
From: moritz at bunkus.org (Moritz Bunkus)
Date: Tue, 30 Dec 2003 10:57:12 +0100
Subject: [Matroska-devel] new releases of libebml & libmatroska
Message-ID: <20031230095712.GC21226@bunkus.org>

Heya,

what about the new tagging system? It has been implemented in
libmatroska, and so far no objections have come forward. We should
release a new version, 0.6.2 (I've already bumped the version number to
it in CVS).

Same for libebml - the version in CVS is at 0.6.3, but the last official
release was 0.6.2. I assume that CVS contains the fixes Cyrius mentioned
a couple of days back, so why not release a new version?

If no one objects I'll make a new release tomorrow or on January 1st.

Mosu

-- 
If Darl McBride was in charge, he'd probably make marriage
unconstitutional too, since clearly it de-emphasizes the commercial
nature of normal human interaction, and probably is a major impediment
to the commercial growth of prostitution. - Linus Torvalds


From paul at msn.com  Tue Dec 30 11:03:11 2003
From: paul at msn.com (Paul Bryson)
Date: Tue, 30 Dec 2003 04:03:11 -0600
Subject: [Matroska-devel] Re: Dropping elements for the Matroska 1.0 spec
References: <bsad75$83h$1@sea.gmane.org>
	<1072608354.3feeb4625783a@mail.tu-chemnitz.de>
Message-ID: <bsrife$kkp$1@sea.gmane.org>

> > <alexander.noe> wrote...
> > BlockVirtual 3 [A2] * - - binary (see Block Virtual) A Block with no data.
>
> Actually, I recently thought about using BlockVirtual for some kind
> of editing: You could e.g. edit a subtitle block, making it longer,
> and replace the next block by a virtual block while moving the real block
> to the end of the file.
> Even though this is not yet possible with any editor, fixing a typo in
> a subtitle block without rewriting the entire file (and maybe extracting
> the subtitle before) would be nice.

Sounds like a good idea to me, but not for the 1.0 release.  This sounds like
something that would fit nicely in the 2.0 release.  Remember this is everything
that has a working implementation.  If there is no implementation of it, then
there is no need to include it in the 1.0 specs.

> > FlagDefault 3 [88]
>
> Should be kept:
> <dreaming>
> If no subtitle track has this flag, no subtitle should be played
> by default. Each track having this flag should be played by default
> (e.g. I want the elvish-only subtitle in LOTR by default, but
> certainly not a complete subtitle, if there is only a complete one)
> </dreaming>

Same as above.  Well, perhaps somebody could implement this pretty quickly so it
would go in the 1.0 specs.


Pamel





From rbultje at ronald.bitfreak.net  Tue Dec 30 11:27:23 2003
From: rbultje at ronald.bitfreak.net (Ronald Bultje)
Date: Tue, 30 Dec 2003 11:27:23 +0100
Subject: [Matroska-devel] new releases of libebml & libmatroska
In-Reply-To: <20031230095712.GC21226@bunkus.org>
References: <20031230095712.GC21226@bunkus.org>
Message-ID: <1072780042.2257.7.camel@shrek.bitfreak.net>

Hi,

On Tue, 2003-12-30 at 10:57, Moritz Bunkus wrote:
> what about the new tagging system? It has been implemented in
> libmatroska, and so far no objections have come forward. We should
> release a new version, 0.6.2 (I've already bumped the version number to
> it in CVS).

Short introduction please? So I can implement this in GStreamer
properly.

Ronald

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



From moritz at bunkus.org  Tue Dec 30 11:36:01 2003
From: moritz at bunkus.org (Moritz Bunkus)
Date: Tue, 30 Dec 2003 11:36:01 +0100
Subject: [Matroska-devel] new releases of libebml & libmatroska
In-Reply-To: <1072780042.2257.7.camel@shrek.bitfreak.net>
References: <20031230095712.GC21226@bunkus.org>
	<1072780042.2257.7.camel@shrek.bitfreak.net>
Message-ID: <20031230103601.GD21226@bunkus.org>

Heya Ronald,

> Short introduction please? So I can implement this in GStreamer
> properly.

Read this fine email:
http://lists.matroska.org/pipermail/matroska-devel/2003-December/001220.html

The "specs" page on www.matroska.org also contains this new stuff if you
hit the "tags" link:
http://matroska.corecodec.org/technical/specs/tagging/index.html

Mosu

-- 
If Darl McBride was in charge, he'd probably make marriage
unconstitutional too, since clearly it de-emphasizes the commercial
nature of normal human interaction, and probably is a major impediment
to the commercial growth of prostitution. - Linus Torvalds