From DaveEL at leffe.dnsalias.com  Wed Oct  1 12:38:36 2003
From: DaveEL at leffe.dnsalias.com (DaveEL at leffe.dnsalias.com)
Date: Wed, 1 Oct 2003 12:38:36 +0200 (CEST)
Subject: [Matroska-devel] Re: format of CodecIDs
In-Reply-To: <20030930100007.BE69244000C@p15097576.pureserver.info>
References: <20030930100007.BE69244000C@p15097576.pureserver.info>
Message-ID: <4652.212.56.100.238.1065004716.squirrel@leffe.dnsalias.com>


> Message: 4
> Date: Tue, 30 Sep 2003 10:56:09 +0200
> From: Moritz Bunkus <moritz at bunkus.org>
> Subject: [Matroska-devel] format of CodecIDs
> To: Matroska devel <matroska-devel at lists.matroska.org>
> Message-ID: <20030930085609.GG13138 at bunkus.org>
> Content-Type: text/plain; charset=us-ascii
>
> Hi.
>
> Right now we've reached a critical point in the Matroska development,
> and we need to make a decision about how to store some additional
> information.
>
> The thing I'm talking about is compression (e.g. zlib compressed
> VobSubs) and encryption (jcsston has just implemented something with AES
> encryption). The problem is that we have to store these facts somehow.
>
> Here we have two choices:
>
> 1) Append the information to the CodecID.
> 2) Introduce new track information elements.
>
> So far I've assumed that we would chose 1) and have acted accordingly
> and introduced S_VOBSUB/ZLIB as the CodecID for compressed
> VobSubs. Please note that NO release of mkvtoolnix so far featured this
> compression, so there are NO files that use this CodecID out in the
> open. Therefore we can still change it.
>
> The drawback with this CodecID is that I've just appended '/ZLIB' to the
> CodecID. But if we want to do this the right way then we have to
> separate the content type (S_VOBSUB) from the modifications it went
> through (compression with ZLIB). A 'standard CodecID' could look like
> this:
>
> 1) Track type, followed by an underscore,
> 2) Content type, may be grouped, separator is the forward slash '/',
> 3) Optional flags indicating modifications, separator is some character
> that won't occur otherwise, e.g. the at sign '@'.
> 4) Each flag consists of a descriptor and a value, separated by a colon
> ':'.
> 5) Order of the flags is important. The first flag to occur is the first
> modification used when it was put into the container. Demuxers have to
> apply those counter-modifications from back to front.
>
> Example:
>
> Normal VobSubs: S_VOBSUB
> Compressed VobSubs: S_VOBSUB at COMPRESSION:ZLIB
> VobSubs that have been compressed first and then encoded with AES:
> S_VOBSUB at COMPRESSION:ZLIB at ENCRYPTION:AES
>
> Obvious drawback: The CodecID gets pretty unreadable. And it might not
> be very Matroska-like.
>
> Second approach: introduce new track info elements. This approach is
> more Matroska-like. Possible names could be KaxContentCompression and
> KaxContentEncryption, each being an unsigned integer.
>
> As I said: we have to be quick about this! Compressed VobSubs should be
> a reality soon, and we need a concise system by then.
>
> Thoughts? Other ideas?
>
> --
>  ==> Ciao, Mosu (Moritz Bunkus)
>

Ok ive got loads of stuff to do today so i can't type this idea up
correctly so ill just post the irc log. :)

[11:22] <DaveEL> my personal oppinion by using content-coding elements
rather then compression and encryption would be better as long as you can
have multiple content codng elements per stream
[11:23] <MosuAtWork> huh? :)
[11:23] <MosuAtWork> please explain :)
[11:29] <DaveEL> reading mailing list yesterday
[11:30] <DaveEL> about using codec ids like s_vobsub/lzo etc
[11:30] <MosuAtWork> so you propose to have only one new element,
KaxContentCoding
[11:30] <MosuAtWork> which could be added multiple times for different
purposes
[11:30] <MosuAtWork> ?
[11:31] <DaveEL> well as long as you can have multiple ordered
KaxContentCodings
[11:31] <DaveEL> yeah
[11:31] <DaveEL> its more general then encription and compression :)
[11:33] <DaveEL> but its just an idea
[11:33] <DaveEL> but that was certainly my first reaction when i read your
post yesterday
[11:34] <MosuAtWork> you can have multiple entities, and the order
definitely can have a significance
[11:34] <MosuAtWork> maybe it'd be better to introduce a new subtree
[11:34] <MosuAtWork> KaxContentCoding
[11:34] <MosuAtWork> \- KaxCodingOrder
[11:34] <MosuAtWork>  + KaxCodingType
[11:34] <MosuAtWork>  + KaxCodingSettings
[11:34] <MosuAtWork> or whatever
[11:35] <MosuAtWork> order being a uint telling when it was used during
encoding/muxing
[11:35] <MosuAtWork> that would erase any ambiguitiy
[11:35] <MosuAtWork> -i
[11:35] <MosuAtWork> why don't you reply on the ml with your idea? :)

DaveEL


From chris at matroska.org  Wed Oct  1 16:05:32 2003
From: chris at matroska.org (Christian HJ Wiesner)
Date: Wed, 01 Oct 2003 16:05:32 +0200
Subject: [Matroska-devel] Re: [mpc-devel] Re: [mpc-users] A friendly welcome
	to the new subscribers
In-Reply-To: <1065026875.24654.10.camel@localhost.localdomain>
References: <3F7AD5CF.3070207@matroska.org>
	<1065026875.24654.10.camel@localhost.localdomain>
Message-ID: <3F7ADF2C.7000607@matroska.org>

Jo?l Bourquard wrote:

>Hi Christian
>
>Thanks a lot for this warm welcome !
>I joined the mailing lists, so that I'd know where developments are
>headed and if/where I could help.
>So my first question would be, what are the current concerns, ideas,
>goodies, problems(?) in the ongoing development of Matroska and Musepack
>right now.
>  
>
Forget matroska for the time being, the much more important thing is now 
to finally get MPC SV8 moving. As i was writing on HA.org, i am of the 
opinion that Frank could be remotivated to work on the encoder of SV8 if 
we show him he is not alone on this project. So, first of all anybody 
with some background in basic programming should be looking at the SV8 
bitstream specs and comment on them, it doesnt need indeep knowledge of 
psy models for that.

Once we get some feedback from Frank about the current status of the SV8 
bitstream, we should start making a SV7 to SV8 conversion program. Once 
we have that, i'd be astonished if Frank could not find his motivation 
again to help with the encoder tuning, his favourite field.

>About me: I have not much experience in programming lossy audio codecs
>(ie: psymodels), but have deep interest in compression (entropy coding)
>and also signal processing. Also I'd describe myself as a perfectionist
>(and I like making fast algorithms, just like other people like driving
>fast cars).
>Greetings to all developers here.. :-)
>Jo?l
>
Great :D ! If you ever have some spare time, we are just discussing on 
matroska-devel how to best compress subtitles when storing them in MKV 
files ;) .... zlib will only give us a 1:2 compression on them, if we 
compress them block for block, which is necessary if we want to make the 
files editable ....

Christian
MPC and matroska project admin



From steve.lhomme at free.fr  Thu Oct  2 14:02:14 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Thu, 02 Oct 2003 14:02:14 +0200
Subject: [Matroska-devel] More on encryption
Message-ID: <3F7C13C6.2080608@free.fr>

http://news.zdnet.co.uk/software/developer/0,39020387,2122616,00.htm

Maybe we shold use OpenSSL for the encryption. Jory made a little 
encoder/decoder filter in DirectShow. I think we should try to use the 
encryptions used in OpenSSL (which is basically a network thing).

Maybe we should contact some people working on this lib to have some 
good advices.



From rbultje at ronald.bitfreak.net  Thu Oct  2 14:58:20 2003
From: rbultje at ronald.bitfreak.net (Ronald Bultje)
Date: Thu, 02 Oct 2003 14:58:20 +0200
Subject: [Matroska-devel] More on encryption
In-Reply-To: <3F7C13C6.2080608@free.fr>
References: <3F7C13C6.2080608@free.fr>
Message-ID: <1065099500.4041.222.camel@shrek.bitfreak.net>

Hi Steve,

On Thu, 2003-10-02 at 14:02, Steve Lhomme wrote:
> Maybe we shold use OpenSSL for the encryption. Jory made a little 
> encoder/decoder filter in DirectShow. I think we should try to use the 
> encryptions used in OpenSSL (which is basically a network thing).

What encryption you want to use, depends very much on your goals to
accomplish with it. Do you want to obfuscate media (i.e. only make it
readable to those who you give permission, and only in those ways that
you permit)? Or do you want to compress it (decrease data size)?
Something else?

OpenSSL definately isn't that fast, though it's extremely good and
secure in what it does. Don't forget that it's merely a key encryptor,
i.e. if you've got the data on-disk and the key on-disk, nothing
prevents you from reading the file, no matter how secure you're making
it. Every encryption type has its limitations, nothing is 100% secure.

For compression, I'd advise zlib. OpenSSL isn't a lossless compressor.

Ronald

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



From moritz at bunkus.org  Mon Oct  6 11:45:07 2003
From: moritz at bunkus.org (Moritz Bunkus)
Date: Mon, 6 Oct 2003 11:45:07 +0200
Subject: [Matroska-devel] updated 'downloads' page
Message-ID: <20031006094507.GU13138@bunkus.org>

Hi.

I don't know whether the translators read this list, but I'm sending
this anyway. I've updated the downloads page. Please update your
translations. Thanks.

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


From steve.lhomme at free.fr  Tue Oct  7 18:06:16 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Tue, 07 Oct 2003 18:06:16 +0200
Subject: [Matroska-devel] LWING_GAIN
Message-ID: <3F82E478.8030601@free.fr>

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

Do we use this tag ?
The only transmuxing app for OGM to MKV AFAIK are mkvmerge and VDM. Do 
they preserve this tag ? And tags in general ?

Also, a comment on MMG (as seen in mkvmerge 0.7.1), it would be nice to 
have the duration of each stream of a file. This way it's possible to 
know if the audio and video have the same duration (in the case of 
dropped frames for example).



From paul at msn.com  Wed Oct  8 03:29:03 2003
From: paul at msn.com (Pamel)
Date: Tue, 7 Oct 2003 20:29:03 -0500
Subject: [Matroska-devel] Re: LWING_GAIN
References: <3F82E478.8030601@free.fr>
Message-ID: <blvp80$aio$1@sea.gmane.org>

"Steve Lhomme" <steve.lhomme at free.fr> wrote...
> Do we use this tag ?
> The only transmuxing app for OGM to MKV AFAIK are mkvmerge and VDM. Do
> they preserve this tag ? And tags in general ?

With the exception of the Shell Extension, I don't think that anyone uses the
Tags.  Perhaps as tools mature, they will begin to carry around more tags.  It
would be nice to have a common interface for tags between formats.  Perhaps if
someone mapped all of the tags of different formats to the MPEG-7 tags?


Pamel





From suiryc at yahoo.com  Wed Oct  8 16:33:52 2003
From: suiryc at yahoo.com (Cyrius)
Date: Wed, 8 Oct 2003 07:33:52 -0700 (PDT)
Subject: [Matroska-devel] LWING_GAIN
In-Reply-To: <3F82E478.8030601@free.fr>
Message-ID: <20031008143352.12126.qmail@web12908.mail.yahoo.com>


--- Steve Lhomme <steve.lhomme at free.fr> wrote:
>
http://forum.doom9.org/showthread.php?s=&threadid=62848
> 
> Do we use this tag ?
> The only transmuxing app for OGM to MKV AFAIK are
> mkvmerge and VDM. Do 
> they preserve this tag ? And tags in general ?

In general I preserve the most tags I can.
I don't map this specific tag to any that could exist
in Matroska, however, as I stated in the thread, in
the case of Ogg Vorbis we (that is all tools) keep the
3 Vorbis headers in the Matroska file because we need
them to setup the decoder (CoreVorbis, but that would
be the same for any other Vorbis decoder, we need
those 3 Packets).
And the LWING_GAIN tag is stored in the second Packet,
so this tag is at least stored in the private codec
data and sent to setup the decoder during playback.

__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com


From steve.lhomme at free.fr  Thu Oct  9 23:41:13 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Thu, 09 Oct 2003 23:41:13 +0200
Subject: [Matroska-devel] DV in Matroska ?
Message-ID: <3F85D5F9.2010207@free.fr>

Maybe it will be possible someday !

http://bugzilla.schirmacher.de/show_bug.cgi?id=64



From chris at matroska.org  Sat Oct 11 11:28:23 2003
From: chris at matroska.org (Christian HJ Wiesner)
Date: Sat, 11 Oct 2003 11:28:23 +0200
Subject: [Matroska-devel] New Subtitles standard from Frank Klemm
Message-ID: <3F87CD37.4070203@matroska.org>

Message from Frank about Subtitles ( a new standard ) :

Generische Methode, mit der man unter anderem Untertitel generieren kann.

Das, was angezeigt wird, entsteht durch die ?berlagerung von Ebenen.

Von diesen Ebenen gibt es z.B. 256 St?ck (oder eine flexible Anzahl).

Je h?her die Ebenennummer, um so h?her die Priorit?t bei der ?berlagerung.

Ebene 0 ist typischerweise eine schwarze Fl?che.
Ebene 1 ist typsicherweise der eigentliche Film.
Ebene 2 bis 255 k?nnen f?r Untertitel benutzt werden.

Bereiche au?erhalb eines Bildes sind immer transparent.
Innerhalb des Bildes h?ngt es vom Bildformat und vom Bild ab.
Sinnvollerweise sind f?r Untertitel Bildformate und Bilder zu nutzen, die
Transparenz benutzen.

Beispiel:

Bildschirmgr??e:   1920 x 1080 Pixel
Format des Filmes: 1920 x  816 Pixel  MPEG-4
Untertitel:   max. 1920 x  132 Pixel  Bildformat, das Transparenz und 15 Farben definiert

Der schwarze Hintergrund braucht nicht explizit definiert zu werden. Er
liegt hinter allen Bildern. Er liegt in Layerebene 0 und ist schwarz.

Typischerweise auf Layer 1 liegt der Spielfilm. Er ist nur 1920 x 816 (AR:
1:2.35 gro?). Auf Layer 2 und gr??er liegen z.B. Untertitel. Entweder man
beschr?nkt sich auf den schwarzen Streifen unten oder man mu? f?r Untertitel
ein Format benutzen, was Transparenz erlaubt.

Ein Bild bleibt so lange stehen, bis es gel?scht wird (im einfachsten Fall
durch ?berschreiben mit einem weiteren Bild der Gr??e 0 x 0 Pixel).
Mit Untertitteln in zwei Layern (z.B. 2 und 3) kann man damit z.B.
bitrateneffektiv immer "alte" Teile stehen lassen, in dem man z.B. 
wechselseitig auf zwei Layer schreibt.


	klwjlkfhoqwiedkl
	wqelfkplwqkfklwl   <--- Film
	wpqfkdqwkfpflwqe

        Ich liebe Dich!




	klwjlkfhoqwiedkl
	wqelfkplwqkfklwl   <--- Film
	wpqfkdqwkfpflwqe

        Ich liebe Dich!
        (Sirenengeheul)



	klwjlkfhoqwiedkl
	wqelfkplwqkfklwl   <--- Film
	wpqfkdqwkfpflwqe

        
        (Sirenengeheul)




	klwjlkfhoqwiedkl
	wqelfkplwqkfklwl   <--- Film
	wpqfkdqwkfpflwqe

        
   (Sirenengeheul wird lauter)



	klwjlkfhoqwiedkl
	wqelfkplwqkfklwl   <--- Film
	wpqfkdqwkfpflwqe

     ...la? uns verschwinden        
   (Sirenengeheul wird lauter)




F?r jeden Layer kann man technisch gesehen beliebige Formate
benutzen:

 - M-JPEG, MPEG-1, 2, 4 als Bild			
	R = R(Bild)
	G = G(Bild)
	B = B(Bild)

 - M-JPEG, MPEG-1, 2, 4 als Transparenzmaps		

        T = a + b * R(Bild) + c * G(Bild) + d * B(Bild)		a, b, c, d sind neben dem Bild zu kodieren
        if ( T < 0 ) T = 0
        if ( T > 1 ) T = 1				Transparenz ist zwischen 0 und 1
	R = R(Hiltergrund) * (1 - T) + R(Bild) * T
	G = G(Hiltergrund) * (1 - T) + G(Bild) * T
	B = B(Hiltergrund) * (1 - T) + B(Bild) * T

   Hinter einem schwarzen Hintergrund ergibt bei a=1, b,c,d>=0 ein "MPEG-1,
   2, 4 als Transparenzmaps" genau das gleiche Bild wie ein normales Bild.

 - Bildformate, die keine Transparenz unterst?tzen.
   Hier ist die Konstruktion eines Transparenzkanals ?hnlich wie bei "MPEG-1,
   2, 4 als Transparenzmaps" m?glich

 - Bildformate, die von Natur aus Transparenz unterst?tzen
   Das ist nat?rlich die eleganteste L?sung. Hiermut sind farbige Schriften
   und Antialising der Schrift m?glich.

 - Text: Besonders f?r Bild?bertragungen mit geringen Bitraten, aber auch
   f?r reine Audiosignale mit Songtexten sollte es m?glich sein, nicht
   gerenderte Untertitel zu verwenden. Die Untertitel sollten dann nur noch:
     - Text (Unicode)
     - Farbe (12 bit)
     - Font (max. 4 Fonts sind zu definieren)
     - Gr??e
     - Position
   enthalten. Mit 300 bps erh?lt man so sinnvolle Untertitel.

BTW ist PNG vergleichsweise einfach zu dekodieren. Das die meisten
Anzeigeprogramme auf Tr?gheit optimiert sind, t?uscht viele dar?ber hinweg,
das MPEGs wesentlich aufwendiger zu dekodieren sind.

==================================================================================

Beispiele:

Untertitel mit morphenden Buchstaben:  	MPEG-1, 2, 4 als Transparenzmaps
Bewegende Untertitel:                  	MPEG-1, 2, 4 als Transparenzmaps
Normale S/W Untertitel:		       	1-bit PNGs
Normale S/W Untertitel mit Antialiasing:2-bit PNGs


Probleme:

Richtig problematisch werden solche Dinge erst, wenn man verschieden gro?e
Pixel f?r die Layer zulassen will. Bild hat z.B. 352 x 288er Aufl?sung,
Untertitel, damit nicht so pixelig, haben 720 x 576 Pixel.

-- Frank Klemm





From paul at msn.com  Sat Oct 11 15:54:36 2003
From: paul at msn.com (Pamel)
Date: Sat, 11 Oct 2003 08:54:36 -0500
Subject: [Matroska-devel] Re: New Subtitles standard from Frank Klemm
References: <3F87CD37.4070203@matroska.org>
Message-ID: <bm922a$28t$1@sea.gmane.org>

"Christian HJ Wiesner" <chris at matroska.org> wrote...
Message from Frank about Subtitles ( a new standard ) :

Generische Methode, mit der man unter anderem Untertitel generieren kann.


Would someone offer a general English description of this for us uneducated
folks?

Strange, OE refuses to indent the original message.


Pamel





From alexander.noe at s2001.tu-chemnitz.de  Sat Oct 11 23:52:24 2003
From: alexander.noe at s2001.tu-chemnitz.de (=?ISO-8859-15?Q?Alexander_No=E9?=)
Date: Sat, 11 Oct 2003 23:52:24 +0200
Subject: [Matroska-devel] Re: New Subtitles standard from Frank Klemm
In-Reply-To: <bm922a$28t$1@sea.gmane.org>
References: <3F87CD37.4070203@matroska.org> <bm922a$28t$1@sea.gmane.org>
Message-ID: <3F887B98.1030307@hrz.tu-chemnitz.de>

Pamel wrote:

>"Christian HJ Wiesner" <chris at matroska.org> wrote...
>Message from Frank about Subtitles ( a new standard ) :
>
>Generische Methode, mit der man unter anderem Untertitel generieren kann.
>
>
>Would someone offer a general English description of this for us uneducated
>folks?
>
Frank wants to use layers like a Direct3D Z-Buffer. Layer 0 is black, 
Layer 1 is the movie,
Layer 2-k are for subtitles. So you can basicly add text to an existing 
subtitle without
coding some stuff twice, which is especially interesting for picture 
subtitles using a format
that supports transparency.

Then, there is a lot of self-evident stuff.




Alex



From chris at matroska.org  Sun Oct 12 18:41:59 2003
From: chris at matroska.org (Christian HJ Wiesner)
Date: Sun, 12 Oct 2003 18:41:59 +0200
Subject: [Matroska-devel] Replay Gain Value in matroska - are they handled
	at all ?
Message-ID: <3F898457.200@matroska.org>

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

comments welcome ...

Christian



From chris at matroska.org  Mon Oct 13 03:24:15 2003
From: chris at matroska.org (Christian HJ Wiesner)
Date: Mon, 13 Oct 2003 03:24:15 +0200
Subject: [Matroska-devel] Adding matroska support to FFMPEG via
 libmatroska/libebml, in C++ ?
Message-ID: <3F89FEBF.9030908@matroska.org>


Hi,

given we would change our license to L-GPL, whats the current opinion of 
the dev team on including C++ code into FFMPEG ? Has it changed since 
then, with GCC support for C++ being improved lately, or you still 
insist on plain C ? No offense, just curious ....

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



From rvs at sun.com  Mon Oct 13 19:33:34 2003
From: rvs at sun.com (Roman Shaposhnick)
Date: Mon, 13 Oct 2003 10:33:34 -0700
Subject: [Matroska-devel] Re: [Ffmpeg-devel] Adding matroska support to
	FFMPEG via libmatroska/libebml, in C++ ?
In-Reply-To: <3F89FEBF.9030908@matroska.org>
References: <3F89FEBF.9030908@matroska.org>
Message-ID: <20031013103334.C3257@submarine>

Personally, I'd be against adding C++ parts to ffmpeg.

Thanks,
Roman.

P.S. Why did you pick C++ to develop a potentially cross-platform library
in the first place: it's so much harder to get a buy-in for a C++ code.... 
No offense, just curious ....

On Mon, Oct 13, 2003 at 03:24:15AM +0200, Christian HJ Wiesner wrote:
> 
> Hi,
> 
> given we would change our license to L-GPL, whats the current opinion of 
> the dev team on including C++ code into FFMPEG ? Has it changed since 
> then, with GCC support for C++ being improved lately, or you still 
> insist on plain C ? No offense, just curious ....
> 
> Christian
> matroska project admin
> http://www.matroska.org
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> SourceForge.net hosts over 70,000 Open Source Projects.
> See the people who have HELPED US provide better services:
> Click here: http://sourceforge.net/supporters.php
> _______________________________________________
> Ffmpeg-devel mailing list
> Ffmpeg-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/ffmpeg-devel


From chris at matroska.org  Mon Oct 13 21:38:47 2003
From: chris at matroska.org (Christian HJ Wiesner)
Date: Mon, 13 Oct 2003 21:38:47 +0200
Subject: [Matroska-devel] Re: [Ffmpeg-devel] Adding matroska support to
	FFMPEG via libmatroska/libebml, in C++ ?
In-Reply-To: <20031013103334.C3257@submarine>
References: <3F89FEBF.9030908@matroska.org> <20031013103334.C3257@submarine>
Message-ID: <3F8AFF47.1050805@matroska.org>

Hi Roman,

Roman Shaposhnick wrote:

>Personally, I'd be against adding C++ parts to ffmpeg.
>
>Thanks,
>Roman.
>
>P.S. Why did you pick C++ to develop a potentially cross-platform library
>in the first place: it's so much harder to get a buy-in for a C++ code.... 
>No offense, just curious ....
>  
>

To be honest, i guess we never expected that matroska would become such 
a great success in the first place, so the acceptance of the main 
library for integration into well introduced and widespread libs like 
FFMPEG was not at all in the focus when our devs, mainly Steve 'robux4' 
Lhomme, started working on the lib. They simply chose a language they 
thought would allow them the best results in the shortest possible time, 
and for sure one major reason here was that all of them were fitter in 
coding in C++ than in C.

Strange enough, there are 3 different implementations now ( 
libmatroska/libebml, Gabest' Guliverkli matroska DShow filters and 
alexnoe's AVImux-GUI ), and all of them are C++ :O ! To make sure there 
is no misunderstanding, both Gabest and alexnoe were NOT using 
libmatroska for their tools, but coded their own implementation based on 
the specs, and each of them decided to go for C++ for that.

Of course, we know very well that matroska's success is based on the 
existing apps for making matroska files, namely Mosu's MKVtoolnix on 
Linux ( and now also Win32 ) and Cyrius' VirtualdubMod, and again both 
preferred using the C++ lib instead of rewriting it in C ..... anyhow, 
thanks for the update, i hope some day somebody will make a 4th 
implementation in plain C, and you guys help to include it into FFMPEG 
:) .....

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

>On Mon, Oct 13, 2003 at 03:24:15AM +0200, Christian HJ Wiesner wrote:
>  
>
>>Hi,
>>
>>given we would change our license to L-GPL, whats the current opinion of 
>>the dev team on including C++ code into FFMPEG ? Has it changed since 
>>then, with GCC support for C++ being improved lately, or you still 
>>insist on plain C ? No offense, just curious ....
>>
>>Christian
>>matroska project admin
>>http://www.matroska.org
>>




From christian at matroska.org  Mon Oct 13 22:57:53 2003
From: christian at matroska.org (ChristianHJW)
Date: Mon, 13 Oct 2003 22:57:53 +0200
Subject: [Matroska-devel] Re: Adding matroska support to FFMPEG via
 libmatroska/libebml, in C++ ?
In-Reply-To: <20031013201441.GO452@zewt.org>
References: <3F89FEBF.9030908@matroska.org>
	<20031013025438.GH2856@brightrain.aerifal.cx>
	<20031013042119.GI452@zewt.org>
	<20031013195506.GO2856@brightrain.aerifal.cx>
	<20031013201441.GO452@zewt.org>
Message-ID: <3F8B11D1.2040602@matroska.org>

Glenn Maynard wrote:
> On Mon, Oct 13, 2003 at 03:55:06PM -0400, D Richard Felker III wrote:
>>>>ROTFL!!! The new "improved" versions of gcc with better C++ support
>>>>are so buggy they're not usable.
>>>False.  Proof by contradiction: I use g++ 3.3 actively and successfully.
>>What an idiotic misuse of the phrase "proof by contradiction". Don't
>>try such crap on mathematicians/logicians. FYI, almost EVERY version
> Anyway, I've had my fill of your constant personal attacks against people
> who have the nerve to disagree with you.  Go ahead and have the last
> word, if you like.  :)

Never mind, i guess Richard's answer was not really ment to attack you, 
i think he simply goes through the roof and starts to get personal 
whenever he hears or reads the word 'matroska' , especially if in 
combination with using C++ or C, for whatever strange reasons .... maybe 
my fault, back in the days when i was going on people's nerves about 
joining the matroska dev team on mplayer-dev-eng, i dont know ...

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



From rvs at sun.com  Mon Oct 13 23:02:48 2003
From: rvs at sun.com (Roman Shaposhnick)
Date: Mon, 13 Oct 2003 14:02:48 -0700
Subject: [Matroska-devel] Re: [Ffmpeg-devel] Adding matroska support to
	FFMPEG via libmatroska/libebml, in C++ ?
In-Reply-To: <3F8AFF47.1050805@matroska.org>
References: <3F89FEBF.9030908@matroska.org> <20031013103334.C3257@submarine>
	<3F8AFF47.1050805@matroska.org>
Message-ID: <20031013140248.A25461@submarine>

It may sound funny, but that's how I judge an A/V format I know
nothing of: if it can be written in good understandable C and
the implementation is short enough to be grasped by just looking
at C source -- than it's a good one.

Just my 2c.

Thanks,
Roman.

P.S. Granted, I suppose, there are a lot of examples when a 
potentially good format could be completely screwed by the 
implementation (take libpng for example) but still...

On Mon, Oct 13, 2003 at 09:38:47PM +0200, Christian HJ Wiesner wrote:
> Hi Roman,
> 
> Roman Shaposhnick wrote:
> 
> >Personally, I'd be against adding C++ parts to ffmpeg.
> >
> >Thanks,
> >Roman.
> >
> >P.S. Why did you pick C++ to develop a potentially cross-platform library
> >in the first place: it's so much harder to get a buy-in for a C++ code.... 
> >No offense, just curious ....
> > 
> >
> 
> To be honest, i guess we never expected that matroska would become such 
> a great success in the first place, so the acceptance of the main 
> library for integration into well introduced and widespread libs like 
> FFMPEG was not at all in the focus when our devs, mainly Steve 'robux4' 
> Lhomme, started working on the lib. They simply chose a language they 
> thought would allow them the best results in the shortest possible time, 
> and for sure one major reason here was that all of them were fitter in 
> coding in C++ than in C.
> 
> Strange enough, there are 3 different implementations now ( 
> libmatroska/libebml, Gabest' Guliverkli matroska DShow filters and 
> alexnoe's AVImux-GUI ), and all of them are C++ :O ! To make sure there 
> is no misunderstanding, both Gabest and alexnoe were NOT using 
> libmatroska for their tools, but coded their own implementation based on 
> the specs, and each of them decided to go for C++ for that.
> 
> Of course, we know very well that matroska's success is based on the 
> existing apps for making matroska files, namely Mosu's MKVtoolnix on 
> Linux ( and now also Win32 ) and Cyrius' VirtualdubMod, and again both 
> preferred using the C++ lib instead of rewriting it in C ..... anyhow, 
> thanks for the update, i hope some day somebody will make a 4th 
> implementation in plain C, and you guys help to include it into FFMPEG 
> :) .....
> 
> Christian
> matroska project admin
> http://www.matroska.org
> 
> >On Mon, Oct 13, 2003 at 03:24:15AM +0200, Christian HJ Wiesner wrote:
> > 
> >
> >>Hi,
> >>
> >>given we would change our license to L-GPL, whats the current opinion of 
> >>the dev team on including C++ code into FFMPEG ? Has it changed since 
> >>then, with GCC support for C++ being improved lately, or you still 
> >>insist on plain C ? No offense, just curious ....
> >>
> >>Christian
> >>matroska project admin
> >>http://www.matroska.org
> >>
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> SourceForge.net hosts over 70,000 Open Source Projects.
> See the people who have HELPED US provide better services:
> Click here: http://sourceforge.net/supporters.php
> _______________________________________________
> Ffmpeg-devel mailing list
> Ffmpeg-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/ffmpeg-devel


From mru at users.sourceforge.net  Mon Oct 13 23:03:41 2003
From: mru at users.sourceforge.net (=?iso-8859-1?q?M=E5ns_Rullg=E5rd?=)
Date: Mon, 13 Oct 2003 23:03:41 +0200
Subject: [Matroska-devel] Re: [Ffmpeg-devel] Adding matroska support to
	FFMPEG via libmatroska/libebml, in C++ ?
In-Reply-To: <3F8AFF47.1050805@matroska.org> (Christian HJ Wiesner's message
	of "Mon, 13 Oct 2003 21:38:47 +0200")
References: <3F89FEBF.9030908@matroska.org> <20031013103334.C3257@submarine>
	<3F8AFF47.1050805@matroska.org>
Message-ID: <yw1xekxgx32q.fsf@users.sourceforge.net>

Christian HJ Wiesner <chris at matroska.org> writes:

> Of course, we know very well that matroska's success is based on the

Success?  I haven't seen of matroska files in the wild, yet.

> existing apps for making matroska files, namely Mosu's MKVtoolnix on
> Linux ( and now also Win32 ) and Cyrius' VirtualdubMod, and again both
> preferred using the C++ lib instead of rewriting it in C ..... anyhow,
> thanks for the update, i hope some day somebody will make a 4th
> implementation in plain C, and you guys help to include it into FFMPEG

If lots of matroska files start coming my way, I'll probably code
something up in C.

-- 
M?ns Rullg?rd
mru at users.sf.net


From chris at matroska.org  Mon Oct 13 23:47:34 2003
From: chris at matroska.org (Christian HJ Wiesner)
Date: Mon, 13 Oct 2003 23:47:34 +0200
Subject: [Matroska-devel] Re: [Ffmpeg-devel] Adding matroska support to
	FFMPEG via libmatroska/libebml, in C++ ?
In-Reply-To: <yw1xekxgx32q.fsf@users.sourceforge.net>
References: <3F89FEBF.9030908@matroska.org>
	<20031013103334.C3257@submarine>	<3F8AFF47.1050805@matroska.org>
	<yw1xekxgx32q.fsf@users.sourceforge.net>
Message-ID: <3F8B1D76.8060809@matroska.org>

M?ns Rullg?rd wrote:

>Christian HJ Wiesner <chris at matroska.org> writes:
>
>  
>
>>Of course, we know very well that matroska's success is based on the
>>    
>>
>
>Success?  I haven't seen of matroska files in the wild, yet.
>

out in the wild ? .... you mean there : 
http://www.jigle.com/search?p=&t=0&x=mkv&sl=1&su=&ma=3&l=10&a=0 ? or 
there : http://team-mkv.fr.st or there : http://www.matroska.web.pt or 
there : http://www.matroska.tk or there : 
http://m17n.cool.ne.jp/matroska/ or there : 
http://board.dvds-kopieren.de/board.php?boardid=79 .........

>>existing apps for making matroska files, namely Mosu's MKVtoolnix on
>>Linux ( and now also Win32 ) and Cyrius' VirtualdubMod, and again both
>>preferred using the C++ lib instead of rewriting it in C ..... anyhow,
>>thanks for the update, i hope some day somebody will make a 4th
>>implementation in plain C, and you guys help to include it into FFMPEG
>>    
>>
>
>If lots of matroska files start coming my way, I'll probably code
>something up in C.
>
I take your word on that Mans :D  ..... you'd be more than welcome in 
the team, and we'd support you best we can, MKV support in FFMPEG is 
something we really dream of since some time now ....

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



From mru at users.sourceforge.net  Mon Oct 13 23:51:15 2003
From: mru at users.sourceforge.net (=?iso-8859-1?q?M=E5ns_Rullg=E5rd?=)
Date: Mon, 13 Oct 2003 23:51:15 +0200
Subject: [Matroska-devel] Re: [Ffmpeg-devel] Adding matroska support to
	FFMPEG via libmatroska/libebml, in C++ ?
In-Reply-To: <20031013140248.A25461@submarine> (Roman Shaposhnick's message
	of "Mon, 13 Oct 2003 14:02:48 -0700")
References: <3F89FEBF.9030908@matroska.org> <20031013103334.C3257@submarine>
	<3F8AFF47.1050805@matroska.org> <20031013140248.A25461@submarine>
Message-ID: <yw1xad84x0vg.fsf@users.sourceforge.net>

Roman Shaposhnick <rvs at sun.com> writes:

> It may sound funny, but that's how I judge an A/V format I know
> nothing of: if it can be written in good understandable C and
> the implementation is short enough to be grasped by just looking
> at C source -- than it's a good one.

The existence of a good specification is also requirement.  The MPEG
formats are excellent in this respect.

> P.S. Granted, I suppose, there are a lot of examples when a 
> potentially good format could be completely screwed by the 
> implementation (take libpng for example) but still...

Ogg also comes to mind.

-- 
M?ns Rullg?rd
mru at users.sf.net


From chris at matroska.org  Tue Oct 14 00:02:23 2003
From: chris at matroska.org (Christian HJ Wiesner)
Date: Tue, 14 Oct 2003 00:02:23 +0200
Subject: [Matroska-devel] Re: [Ffmpeg-devel] Adding matroska support to
	FFMPEG via libmatroska/libebml, in C++ ?
In-Reply-To: <yw1xad84x0vg.fsf@users.sourceforge.net>
References: <3F89FEBF.9030908@matroska.org>
	<20031013103334.C3257@submarine>	<3F8AFF47.1050805@matroska.org>
	<20031013140248.A25461@submarine>
	<yw1xad84x0vg.fsf@users.sourceforge.net>
Message-ID: <3F8B20EF.8010406@matroska.org>

M?ns Rullg?rd wrote:

>Roman Shaposhnick <rvs at sun.com> writes:
>
>  
>
>>It may sound funny, but that's how I judge an A/V format I know
>>nothing of: if it can be written in good understandable C and
>>the implementation is short enough to be grasped by just looking
>>at C source -- than it's a good one.
>>    
>>
>
>The existence of a good specification is also requirement.  The MPEG
>formats are excellent in this respect.
>
matroska had well documented specs before even a single line of code was 
written : 
http://cvs.corecodec.org/cgi-bin/viewcvs.cgi/*checkout*/matroska/doc/website/technical/index.html

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



From mru at users.sourceforge.net  Tue Oct 14 00:09:43 2003
From: mru at users.sourceforge.net (=?iso-8859-1?q?M=E5ns_Rullg=E5rd?=)
Date: Tue, 14 Oct 2003 00:09:43 +0200
Subject: [Matroska-devel] Re: [Ffmpeg-devel] Adding matroska support to
	FFMPEG via libmatroska/libebml, in C++ ?
In-Reply-To: <3F8B1D76.8060809@matroska.org> (Christian HJ Wiesner's message
	of "Mon, 13 Oct 2003 23:47:34 +0200")
References: <3F89FEBF.9030908@matroska.org> <20031013103334.C3257@submarine>
	<3F8AFF47.1050805@matroska.org>
	<yw1xekxgx32q.fsf@users.sourceforge.net>
	<3F8B1D76.8060809@matroska.org>
Message-ID: <yw1x65isx00o.fsf@users.sourceforge.net>

Christian HJ Wiesner <chris at matroska.org> writes:

>>>Of course, we know very well that matroska's success is based on the
>>
>>Success?  I haven't seen of matroska files in the wild, yet.
>>
>
> out in the wild ? .... you mean there :
> http://www.jigle.com/search?p=&t=0&x=mkv&sl=1&su=&ma=3&l=10&a=0 ? or
> there : http://team-mkv.fr.st or there : http://www.matroska.web.pt or
> there : http://www.matroska.tk or there :
> http://m17n.cool.ne.jp/matroska/ or there :
> http://board.dvds-kopieren.de/board.php?boardid=79 .........

Official sites, fan sites and obscure discussion forums don't count.

-- 
M?ns Rullg?rd
mru at users.sf.net


From mru at users.sourceforge.net  Tue Oct 14 00:21:17 2003
From: mru at users.sourceforge.net (=?iso-8859-1?q?M=E5ns_Rullg=E5rd?=)
Date: Tue, 14 Oct 2003 00:21:17 +0200
Subject: [Matroska-devel] Re: [Ffmpeg-devel] Adding matroska support to
	FFMPEG via libmatroska/libebml, in C++ ?
In-Reply-To: <3F8B20EF.8010406@matroska.org> (Christian HJ Wiesner's message
	of "Tue, 14 Oct 2003 00:02:23 +0200")
References: <3F89FEBF.9030908@matroska.org> <20031013103334.C3257@submarine>
	<3F8AFF47.1050805@matroska.org> <20031013140248.A25461@submarine>
	<yw1xad84x0vg.fsf@users.sourceforge.net>
	<3F8B20EF.8010406@matroska.org>
Message-ID: <yw1x1xtgwzhe.fsf@users.sourceforge.net>

Christian HJ Wiesner <chris at matroska.org> writes:

>>>It may sound funny, but that's how I judge an A/V format I know
>>>nothing of: if it can be written in good understandable C and
>>>the implementation is short enough to be grasped by just looking
>>>at C source -- than it's a good one.
>>>
>>
>>The existence of a good specification is also requirement.  The MPEG
>>formats are excellent in this respect.
>>
> matroska had well documented specs before even a single line of code
> was written :
> http://cvs.corecodec.org/cgi-bin/viewcvs.cgi/*checkout*/matroska/doc/website/technical/index.html

It's a good start, but it's a long way from the quality of the MPEG
specs.

-- 
M?ns Rullg?rd
mru at users.sf.net


From chris at matroska.org  Tue Oct 14 00:38:36 2003
From: chris at matroska.org (Christian HJ Wiesner)
Date: Tue, 14 Oct 2003 00:38:36 +0200
Subject: [Matroska-devel] Re: [Ffmpeg-devel] Adding matroska support to
	FFMPEG via libmatroska/libebml, in C++ ?
In-Reply-To: <yw1x65isx00o.fsf@users.sourceforge.net>
References: <3F89FEBF.9030908@matroska.org>
	<20031013103334.C3257@submarine>	<3F8AFF47.1050805@matroska.org>	<yw1xekxgx32q.fsf@users.sourceforge.net>	<3F8B1D76.8060809@matroska.org>
	<yw1x65isx00o.fsf@users.sourceforge.net>
Message-ID: <3F8B296C.6080800@matroska.org>

M?ns Rullg?rd wrote:

>Christian HJ Wiesner <chris at matroska.org> writes:
>  
>
>>>>Of course, we know very well that matroska's success is based on the
>>>>        
>>>>
>>>Success?  I haven't seen of matroska files in the wild, yet.
>>>      
>>>
>>out in the wild ? .... you mean there :
>>http://www.jigle.com/search?p=&t=0&x=mkv&sl=1&su=&ma=3&l=10&a=0 ? or
>>there : http://team-mkv.fr.st or there : http://www.matroska.web.pt or
>>there : http://www.matroska.tk or there :
>>http://m17n.cool.ne.jp/matroska/ or there :
>>http://board.dvds-kopieren.de/board.php?boardid=79 .........
>>    
>>
>
>Official sites, fan sites and obscure discussion forums don't count.
>  
>
:o :O !! What sites DO count then ? The daily mirror ? The observer ? 
Time magazine ?? :P .....

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



From christian at matroska.org  Tue Oct 14 05:46:12 2003
From: christian at matroska.org (ChristianHJW)
Date: Tue, 14 Oct 2003 05:46:12 +0200
Subject: [Matroska-devel] Re: Adding matroska support to   FFMPEG via
	libmatroska/libebml, in C++ ?
In-Reply-To: <Pine.SOL.4.05.10310131619220.24029-100000@babu.pcisys.net>
References: <3F8B20EF.8010406@matroska.org>
	<Pine.SOL.4.05.10310131619220.24029-100000@babu.pcisys.net>
Message-ID: <3F8B7184.6030902@matroska.org>

Mike Melanson wrote:
> On Tue, 14 Oct 2003, Christian HJ Wiesner wrote: 
>>matroska had well documented specs before even a single line of code was 
>>written :  
> 	Hmm, I had almost forgotten how exhaustively-specified the format
> is. Pursuant to the recent list discussion on palette handling, how does
> Matroska deal with palettes? How about palette changes during playback?
> 	Thanks.. 	-Mike Melanson

As always i am not the expert here, but a quick check with jcsston 
brought up the 'codec state' element will allow you to more or less 
reinitialize the codec within the video stream, and allow to change 
resolution, colour space, etc., but not the codec itself .... is this 
the same as 'palette' ?

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



From paul at msn.com  Tue Oct 14 08:47:32 2003
From: paul at msn.com (Pamel)
Date: Tue, 14 Oct 2003 01:47:32 -0500
Subject: [Matroska-devel] Re: Re: [Ffmpeg-devel] Adding matroska support
	toFFMPEG via libmatroska/libebml, in C++ ?
References: <3F89FEBF.9030908@matroska.org>
	<20031013103334.C3257@submarine><3F8AFF47.1050805@matroska.org><yw1xekxgx32q.fsf@users.sourceforge.net><3F8B1D76.8060809@matroska.org>
	<yw1x65isx00o.fsf@users.sourceforge.net>
Message-ID: <bmg651$upl$1@sea.gmane.org>

"M?ns Rullg?rd" <mru at users.sourceforge.net> wrote...
>>>>Of course, we know very well that matroska's success is based on the
>>>Success?  I haven't seen of matroska files in the wild, yet.
>Official sites, fan sites and obscure discussion forums don't count.

What counts as 'the wild' for you?  I know that it has been mentioned in
computer magazines, but articles are not the same as files.  If you are not
including p2p, anime groups, or discussion boards, then I guess you wouldn't see
them out in the wild.  But, leaving those out, the only files that you really
see out in the wild are either WMV9 and RV9.


Pamel





From paul at msn.com  Tue Oct 14 08:59:07 2003
From: paul at msn.com (Pamel)
Date: Tue, 14 Oct 2003 01:59:07 -0500
Subject: [Matroska-devel] Re: Re: [Ffmpeg-devel] Adding matroska support
	toFFMPEG via libmatroska/libebml, in C++ ?
References: <3F89FEBF.9030908@matroska.org>
	<20031013103334.C3257@submarine><3F8AFF47.1050805@matroska.org>
	<20031013140248.A25461@submarine><yw1xad84x0vg.fsf@users.sourceforge.net><3F8B20EF.8010406@matroska.org>
	<yw1x1xtgwzhe.fsf@users.sourceforge.net>
Message-ID: <bmg6qo$vq3$1@sea.gmane.org>

"M?ns Rullg?rd" <mru at users.sourceforge.net> wrote ...
Christian HJ Wiesner <chris at matroska.org> writes:
>> matroska had well documented specs before even a single line of code
>> was written :
>>
http://cvs.corecodec.org/cgi-bin/viewcvs.cgi/*checkout*/matroska/doc/website/technical/index.html

>It's a good start, but it's a long way from the quality of the MPEG
>specs.

Sadly we don't have anyone that is paid to sit around all day and write overly
exhaustive specs.  But, thankfully, we are only defining the specs on a general
container.  One of the reasons that the MPEG specs are so big is that they
define so many different layers in several different configurations.  We have a
lot less to define.  Though we are certainly not yet anywhere close to one of
the ISO MPEG spec docs in covering every aspect, what we have so far is
certainly sufficient.  At least, the fact that two working independent
implementations have been made from the specs is a good indication to this.


Pamel





From alexander.noe at s2001.tu-chemnitz.de  Tue Oct 14 09:51:38 2003
From: alexander.noe at s2001.tu-chemnitz.de (=?ISO-8859-15?Q?Alexander_No=E9?=)
Date: Tue, 14 Oct 2003 09:51:38 +0200
Subject: [Matroska-devel] Re: Re: [Ffmpeg-devel] Adding matroska support
	toFFMPEG via libmatroska/libebml, in C++ ?
In-Reply-To: <bmg6qo$vq3$1@sea.gmane.org>
References: <3F89FEBF.9030908@matroska.org>	<20031013103334.C3257@submarine><3F8AFF47.1050805@matroska.org>	<20031013140248.A25461@submarine><yw1xad84x0vg.fsf@users.sourceforge.net><3F8B20EF.8010406@matroska.org>	<yw1x1xtgwzhe.fsf@users.sourceforge.net>
	<bmg6qo$vq3$1@sea.gmane.org>
Message-ID: <3F8BAB0A.2040600@hrz.tu-chemnitz.de>

Pamel wrote:

>Sadly we don't have anyone that is paid to sit around all day and write overly
>exhaustive specs.  But, thankfully, we are only defining the specs on a general
>container.  One of the reasons that the MPEG specs are so big is that they
>define so many different layers in several different configurations.  We have a
>lot less to define.  Though we are certainly not yet anywhere close to one of
>the ISO MPEG spec docs in covering every aspect, what we have so far is
>certainly sufficient.  At least, the fact that two working independent
>implementations have been made from the specs is a good indication to this.
>
Actually, there is libmatroska, mine and gabest's implementation, all of 
which are independant from
each other, so there are 3, unless you made the specs from libmatroska 
(and not vica-versa) or unless libmatroska does not work.



Alex



From steve.lhomme at free.fr  Tue Oct 14 10:04:53 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Tue, 14 Oct 2003 10:04:53 +0200
Subject: [Matroska-devel] Advices on C++
Message-ID: <3F8BAE25.2000301@free.fr>

http://www.artima.com/intv/goldilocks.html

  from Stroustrup



From steve.lhomme at free.fr  Tue Oct 14 10:48:35 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Tue, 14 Oct 2003 10:48:35 +0200
Subject: [Matroska-devel] Re: [Ffmpeg-devel] Adding matroska support to
	FFMPEG via libmatroska/libebml, in C++ ?
In-Reply-To: <yw1x65isx00o.fsf@users.sourceforge.net>
References: <3F89FEBF.9030908@matroska.org>
	<20031013103334.C3257@submarine>	<3F8AFF47.1050805@matroska.org>	<yw1xekxgx32q.fsf@users.sourceforge.net>	<3F8B1D76.8060809@matroska.org>
	<yw1x65isx00o.fsf@users.sourceforge.net>
Message-ID: <3F8BB863.0@free.fr>

M?ns Rullg?rd wrote:

> Official sites, fan sites and obscure discussion forums don't count.

So who was first ? The chicken or the egg ?
Hopefully not everybody is as conservative as you. Otherwise new things 
would never appear.



From alexander.noe at s2001.tu-chemnitz.de  Tue Oct 14 10:57:36 2003
From: alexander.noe at s2001.tu-chemnitz.de (=?ISO-8859-1?Q?Alexander_No=E9?=)
Date: Tue, 14 Oct 2003 10:57:36 +0200
Subject: [Matroska-devel] Re: [Ffmpeg-devel] Adding matroska support to
	FFMPEG via libmatroska/libebml, in C++ ?
In-Reply-To: <3F8BB863.0@free.fr>
References: <3F89FEBF.9030908@matroska.org>	<20031013103334.C3257@submarine>	<3F8AFF47.1050805@matroska.org>	<yw1xekxgx32q.fsf@users.sourceforge.net>	<3F8B1D76.8060809@matroska.org>	<yw1x65isx00o.fsf@users.sourceforge.net>
	<3F8BB863.0@free.fr>
Message-ID: <3F8BBA80.4070607@hrz.tu-chemnitz.de>

Steve Lhomme wrote:

> M?ns Rullg?rd wrote:
>
>> Official sites, fan sites and obscure discussion forums don't count.
>
>
> So who was first ? The chicken or the egg ?
> Hopefully not everybody is as conservative as you. Otherwise new 
> things would never appear.

<sarcasm>
Steve, don't waste your time, whatever you come up with, it won't 
count.... if someone wants to
hack new stuff into AVI, i'm here!
</sarcasm>


Alex



From mru at users.sourceforge.net  Tue Oct 14 11:00:30 2003
From: mru at users.sourceforge.net (=?iso-8859-1?q?M=E5ns_Rullg=E5rd?=)
Date: Tue, 14 Oct 2003 11:00:30 +0200
Subject: [Matroska-devel] Re: [Ffmpeg-devel] Adding matroska support to
	FFMPEG via libmatroska/libebml, in C++ ?
In-Reply-To: <3F8BB863.0@free.fr> (Steve Lhomme's message of "Tue, 14 Oct
	2003 10:48:35 +0200")
References: <3F89FEBF.9030908@matroska.org> <20031013103334.C3257@submarine>
	<3F8AFF47.1050805@matroska.org>
	<yw1xekxgx32q.fsf@users.sourceforge.net>
	<3F8B1D76.8060809@matroska.org>
	<yw1x65isx00o.fsf@users.sourceforge.net> <3F8BB863.0@free.fr>
Message-ID: <yw1xismstcr5.fsf@users.sourceforge.net>

Steve Lhomme <steve.lhomme at free.fr> writes:

>> Official sites, fan sites and obscure discussion forums don't count.
>
> So who was first ? The chicken or the egg ?
> Hopefully not everybody is as conservative as you. Otherwise new
> things would never appear.

I'm all for changes, if they have a good reason.  I don't see the need
for another file format.  IMHO, the MPEG formats are good enough, and
are already widely accepted.  To be worthwhile, a new format should
add something significant over the existing formats.

In this case, I merely stated that quoting an official promotion site
doesn't really prove the popularity of anything.

-- 
M?ns Rullg?rd
mru at users.sf.net


From alexander.noe at s2001.tu-chemnitz.de  Tue Oct 14 11:05:19 2003
From: alexander.noe at s2001.tu-chemnitz.de (=?ISO-8859-1?Q?Alexander_No=E9?=)
Date: Tue, 14 Oct 2003 11:05:19 +0200
Subject: [Matroska-devel] Re: [Ffmpeg-devel] Adding matroska support to
	FFMPEG via libmatroska/libebml, in C++ ?
In-Reply-To: <yw1xismstcr5.fsf@users.sourceforge.net>
References: <3F89FEBF.9030908@matroska.org>
	<20031013103334.C3257@submarine>	<3F8AFF47.1050805@matroska.org>	<yw1xekxgx32q.fsf@users.sourceforge.net>	<3F8B1D76.8060809@matroska.org>	<yw1x65isx00o.fsf@users.sourceforge.net>
	<3F8BB863.0@free.fr> <yw1xismstcr5.fsf@users.sourceforge.net>
Message-ID: <3F8BBC4F.1020409@hrz.tu-chemnitz.de>

M?ns Rullg?rd wrote:

>In this case, I merely stated that quoting an official promotion site
>doesn't really prove the popularity of anything.
>
Wrong (it would be a bit more correct if you left out 'merely'). 
And please define what an 'obscure forum' is. 





Alex



From steve.lhomme at free.fr  Tue Oct 14 11:22:27 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Tue, 14 Oct 2003 11:22:27 +0200
Subject: [Matroska-devel] Re: [Ffmpeg-devel] Adding matroska support to
	FFMPEG via libmatroska/libebml, in C++ ?
In-Reply-To: <yw1xismstcr5.fsf@users.sourceforge.net>
References: <3F89FEBF.9030908@matroska.org>
	<20031013103334.C3257@submarine>	<3F8AFF47.1050805@matroska.org>	<yw1xekxgx32q.fsf@users.sourceforge.net>	<3F8B1D76.8060809@matroska.org>	<yw1x65isx00o.fsf@users.sourceforge.net>
	<3F8BB863.0@free.fr> <yw1xismstcr5.fsf@users.sourceforge.net>
Message-ID: <3F8BC053.3060601@free.fr>

M?ns Rullg?rd wrote:
> I'm all for changes, if they have a good reason.  I don't see the need
> for another file format.  IMHO, the MPEG formats are good enough, and
> are already widely accepted.  To be worthwhile, a new format should
> add something significant over the existing formats.

Lower overhead size, specs available to everyone for free, royalty free, 
opened to any codec, extensible as you wish, all based on an easy 
principle (EBML). That's all that comes to my mind for now.

> In this case, I merely stated that quoting an official promotion site
> doesn't really prove the popularity of anything.

So what would be decisive for you ? Popularity of a crap format ? Of an 
unpopular format that is technically good ? Matroska has a (fast) 
growing popularity and is technically good (I won't claim it's the best, 
but it's among the best ones). What else do you need ?



From alexander.noe at s2001.tu-chemnitz.de  Tue Oct 14 11:29:19 2003
From: alexander.noe at s2001.tu-chemnitz.de (=?ISO-8859-1?Q?Alexander_No=E9?=)
Date: Tue, 14 Oct 2003 11:29:19 +0200
Subject: [Matroska-devel] Re: [Ffmpeg-devel] Adding matroska support to
	FFMPEG via libmatroska/libebml, in C++ ?
In-Reply-To: <3F8BC053.3060601@free.fr>
References: <3F89FEBF.9030908@matroska.org>	<20031013103334.C3257@submarine>	<3F8AFF47.1050805@matroska.org>	<yw1xekxgx32q.fsf@users.sourceforge.net>	<3F8B1D76.8060809@matroska.org>	<yw1x65isx00o.fsf@users.sourceforge.net>	<3F8BB863.0@free.fr>
	<yw1xismstcr5.fsf@users.sourceforge.net> <3F8BC053.3060601@free.fr>
Message-ID: <3F8BC1EF.4080501@hrz.tu-chemnitz.de>

Steve Lhomme wrote:

> Lower overhead size

You feed some nice little scandinavian creatures each time you claim this...

http://www-user.tu-chemnitz.de/~noe/Video-Zeug/AVIMux%20GUI/en_overhead_comparison.html



Alex



From Liisachan at faireal.net  Tue Oct 14 11:42:06 2003
From: Liisachan at faireal.net (Liisachan)
Date: Tue, 14 Oct 2003 18:42:06 +0900
Subject: [Matroska-devel] Re: [Ffmpeg-devel] Adding matroska support to
	FFMPEG via libmatroska/libebml, in C++ ?
In-Reply-To: <yw1xismstcr5.fsf@users.sourceforge.net>
References: <3F89FEBF.9030908@matroska.org>
	<20031013103334.C3257@submarine>	<3F8AFF47.1050805@matroska.org>	<yw1xekxgx32q.fsf@users.sourceforge.net>	<3F8B1D76.8060809@matroska.org>	<yw1x65isx00o.fsf@users.sourceforge.net>
	<3F8BB863.0@free.fr> <yw1xismstcr5.fsf@users.sourceforge.net>
Message-ID: <3F8BC4EE.2020703@faireal.net>

M?ns Rullg?rd wrote:

>I'm all for changes, if they have a good reason.  I don't see the need
>for another file format.  IMHO, the MPEG formats are good enough, and
>are already widely accepted.  To be worthwhile, a new format should
>add something significant over the existing formats.
>
>In this case, I merely stated that quoting an official promotion site
>doesn't really prove the popularity of anything.
>
>  
>
Hi
I think you want to just ignore fansubbing and I m not interested in 
conflicts between devs,
but just for record--not just for you--
as a plain truth, real users/leechers do love one of mkv's new features,
no matter how devs think what.

A typical conversation...

[2003-10-10 16:41:08 +0900] <user A> *mkv
[2003-10-10 16:41:17 +0900] <user A> this is really good format
[2003-10-10 16:41:20 +0900] <user A> better then ogm :I~
[2003-10-10 16:41:25 +0900] <user B> yeah
[2003-10-10 16:41:31 +0900] <user A> just seeing pictures :I~
[2003-10-10 16:41:55 +0900] * user A is wondering if its work at win98se
[2003-10-10 16:42:06 +0900] <user B> oh you can't tell from pictures
[2003-10-10 16:42:15 +0900] <user B> it's only a container format
[2003-10-10 16:42:23 +0900] <user A> hehe yeah
[2003-10-10 16:42:26 +0900] <user A> i mean
[2003-10-10 16:42:32 +0900] <user A> its bettter then ogm
[2003-10-10 16:42:40 +0900] <user B> agreed
[2003-10-10 16:42:42 +0900] <user A> cause the subtitles actually have 
effects
[2003-10-10 16:42:45 +0900] <user A> and stuff
[2003-10-10 16:42:56 +0900] <user A> the softsub way are better :S

Actually "User A" doesn't know what he is talking about very well,
but he means S_SSA.

Use A and B are both avarage end-users, not devs nor subbers who use MKV

Honestly, as a user (subber) what I love is not Matroska itself, but 
soft-ssa.
I will try MPEG-4 container too as soon as I can freely embed a better 
sub format in it.
I know MPEG-4 can do many things when everything is ready

Just FYI, here's subbers' conversation--we know something in MKV is not new

[2003-10-10 21:40:39 +0900] <Subber A> did u hear akraze did trilingual 
scrapped princess in matroska?
[2003-10-10 21:41:47 +0900] <Subber A> chinese, japanese english
[2003-10-10 21:43:21 +0900] <Subber A> well...anime-kraze is big group 
like aone...
[2003-10-10 21:43:22 +0900] <Subber B> so they fansubbed in 3 langs
[2003-10-10 21:43:26 +0900] <Subber B> or just ripped from dvd?
[2003-10-10 21:43:51 +0900] <Subber A> raw is from dvd, but it's fansubbed
[2003-10-10 21:44:25 +0900] <Subber B> but i m seeing a lot of things 
now in MKV
[2003-10-10 21:44:30 +0900] <Subber B> for instance, ranma 1/2
[2003-10-10 21:44:39 +0900] <Subber B> or Initial D
[2003-10-10 21:44:47 +0900] <Subber A> are they using matroska's special 
abilities?
[2003-10-10 21:44:54 +0900] <Subber A> like karaoke/etc
[2003-10-10 21:45:00 +0900] <Subber B> DualAudio
[2003-10-10 21:45:07 +0900] <Subber B> not that special
[2003-10-10 21:45:09 +0900] <Subber A> ogm already has it
[2003-10-10 21:45:13 +0900] <Subber B> even avi
[2003-10-10 21:45:43 +0900] <Subber A> doing matroska just for matroska 
is baka
[2003-10-10 21:46:14 +0900] <Subber A> if u do matroska, u should use 
it's abilities...
[2003-10-10 21:46:23 +0900] <Subber B> not true
[2003-10-10 21:46:31 +0900] <Subber B> just using matroska will make 
your file smaller

*Liisachan*



From steve.lhomme at free.fr  Tue Oct 14 11:54:24 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Tue, 14 Oct 2003 11:54:24 +0200
Subject: [Matroska-devel] Re: [Ffmpeg-devel] Adding matroska support to
	FFMPEG via libmatroska/libebml, in C++ ?
In-Reply-To: <3F8BC1EF.4080501@hrz.tu-chemnitz.de>
References: <3F89FEBF.9030908@matroska.org>	<20031013103334.C3257@submarine>	<3F8AFF47.1050805@matroska.org>	<yw1xekxgx32q.fsf@users.sourceforge.net>	<3F8B1D76.8060809@matroska.org>	<yw1x65isx00o.fsf@users.sourceforge.net>	<3F8BB863.0@free.fr>	<yw1xismstcr5.fsf@users.sourceforge.net>
	<3F8BC053.3060601@free.fr> <3F8BC1EF.4080501@hrz.tu-chemnitz.de>
Message-ID: <3F8BC7D0.8020305@free.fr>

Alexander No? wrote:

> Steve Lhomme wrote:
> 
>> Lower overhead size
> 
> 
> You feed some nice little scandinavian creatures each time you claim 
> this...
> 
> http://www-user.tu-chemnitz.de/~noe/Video-Zeug/AVIMux%20GUI/en_overhead_comparison.html 

Would "lower overhead in many cases" or "lower overhead for the same 
level or reliability" or "lower overhead for the same level of features" 
suit you better ?

BTW, did you try "6 AC3 frames per matroska Block" in your tests ? It's 
not the best thing to do because of timecode drifting or edition 
boundaries. But it's still possible and valid. It's all a decoder 
problem, not a matroska problem. And as the AC3 (or MPEG audio 1/2/3) 
decoders are usually done as data stream, feeding them with 1 or 6 
frames should work the same. At least as well as when data come from 
AVI... So IMO your test is a bit biased.



From alexander.noe at s2001.tu-chemnitz.de  Tue Oct 14 11:53:10 2003
From: alexander.noe at s2001.tu-chemnitz.de (=?ISO-8859-1?Q?Alexander_No=E9?=)
Date: Tue, 14 Oct 2003 11:53:10 +0200
Subject: [Matroska-devel] Re: [Ffmpeg-devel] Adding matroska support to
	FFMPEG via libmatroska/libebml, in C++ ?
In-Reply-To: <3F8BC4EE.2020703@faireal.net>
References: <3F89FEBF.9030908@matroska.org>	<20031013103334.C3257@submarine>	<3F8AFF47.1050805@matroska.org>	<yw1xekxgx32q.fsf@users.sourceforge.net>	<3F8B1D76.8060809@matroska.org>	<yw1x65isx00o.fsf@users.sourceforge.net>	<3F8BB863.0@free.fr>
	<yw1xismstcr5.fsf@users.sourceforge.net>
	<3F8BC4EE.2020703@faireal.net>
Message-ID: <3F8BC786.4060602@hrz.tu-chemnitz.de>

Liisachan wrote:

> A typical conversation...
>
> [2003-10-10 16:41:08 +0900] <user A> *mkv
> [2003-10-10 16:41:17 +0900] <user A> this is really good format
> [2003-10-10 16:41:20 +0900] <user A> better then ogm :I~
> [2003-10-10 16:41:25 +0900] <user B> yeah
> [2003-10-10 16:41:31 +0900] <user A> just seeing pictures :I~
> [2003-10-10 16:41:55 +0900] * user A is wondering if its work at win98se
> [2003-10-10 16:42:06 +0900] <user B> oh you can't tell from pictures
> [2003-10-10 16:42:15 +0900] <user B> it's only a container format
> [2003-10-10 16:42:23 +0900] <user A> hehe yeah
> [2003-10-10 16:42:26 +0900] <user A> i mean
> [2003-10-10 16:42:32 +0900] <user A> its bettter then ogm
> [2003-10-10 16:42:40 +0900] <user B> agreed
> [2003-10-10 16:42:42 +0900] <user A> cause the subtitles actually have 
> effects
> [2003-10-10 16:42:45 +0900] <user A> and stuff
> [2003-10-10 16:42:56 +0900] <user A> the softsub way are better :S 

At that point, I should add that AVI can do that as well.....

> Actually "User A" doesn't know what he is talking about very well,
> but he means S_SSA. 

No, he means S_TEXT/SSA. The code 'S_SSA' has been used by some very old
versions of mkvmerge and is wrong. I hope that no one is using mkvmerge 
0.4.x any longer...

> [2003-10-10 21:46:31 +0900] <Subber B> just using matroska will make 
> your file smaller 

Again overhead talk :o


Alex



From alexander.noe at s2001.tu-chemnitz.de  Tue Oct 14 12:01:10 2003
From: alexander.noe at s2001.tu-chemnitz.de (=?ISO-8859-1?Q?Alexander_No=E9?=)
Date: Tue, 14 Oct 2003 12:01:10 +0200
Subject: [Matroska-devel] Re: [Ffmpeg-devel] Adding matroska support to
	FFMPEG via libmatroska/libebml, in C++ ?
In-Reply-To: <3F8BC7D0.8020305@free.fr>
References: <3F89FEBF.9030908@matroska.org>	<20031013103334.C3257@submarine>	<3F8AFF47.1050805@matroska.org>	<yw1xekxgx32q.fsf@users.sourceforge.net>	<3F8B1D76.8060809@matroska.org>	<yw1x65isx00o.fsf@users.sourceforge.net>	<3F8BB863.0@free.fr>	<yw1xismstcr5.fsf@users.sourceforge.net>	<3F8BC053.3060601@free.fr>
	<3F8BC1EF.4080501@hrz.tu-chemnitz.de> <3F8BC7D0.8020305@free.fr>
Message-ID: <3F8BC966.8020103@hrz.tu-chemnitz.de>

Steve Lhomme wrote:

> BTW, did you try "6 AC3 frames per matroska Block" in your tests?

With frames of 1536 bytes, you need 7 bytes to code the size of each 
block, so that lacing is not an option.
If you suggest to put several blocks of AC3 audio into one matroska 
block, Mosu will kill you (and me
as well), but I will try that. BTW, a constant-frame-size-flag in the 
block header would resolve that issue.

> It's not the best thing to do because of timecode drifting or edition 
> boundaries. But it's still possible and valid. It's all a decoder 
> problem, not a matroska problem. And as the AC3 (or MPEG audio 1/2/3) 
> decoders are usually done as data stream, feeding them with 1 or 6 
> frames should work the same. At least as well as when data come from 
> AVI... So IMO your test is a bit biased. 

I test standard conform. If you want to see results with violations of 
what we have agreed on, then
I will do those tests and add an option to avimux gui to write such 
b0rked files on the risk of the user.
If you put 6 frames of AC3 in one matroska block, the saved overhead, 
compared to AVI, should
be one byte per frame in theory. It would IMHO be a hack, but you know 
that I like hacks, and I
will implement it if you explicitely tell me to implement a hack.

But see the constant-frame-size-flag-thing for lace headers. It would be 
no hack and achieve the same affect.


Alex



From Liisachan at faireal.net  Tue Oct 14 12:22:00 2003
From: Liisachan at faireal.net (Liisachan)
Date: Tue, 14 Oct 2003 19:22:00 +0900
Subject: [Matroska-devel] Re: [Ffmpeg-devel] Adding matroska support to
	FFMPEG via libmatroska/libebml, in C++ ?
In-Reply-To: <3F8BC786.4060602@hrz.tu-chemnitz.de>
References: <3F89FEBF.9030908@matroska.org>	<20031013103334.C3257@submarine>	<3F8AFF47.1050805@matroska.org>	<yw1xekxgx32q.fsf@users.sourceforge.net>	<3F8B1D76.8060809@matroska.org>	<yw1x65isx00o.fsf@users.sourceforge.net>	<3F8BB863.0@free.fr>	<yw1xismstcr5.fsf@users.sourceforge.net>	<3F8BC4EE.2020703@faireal.net>
	<3F8BC786.4060602@hrz.tu-chemnitz.de>
Message-ID: <3F8BCE48.7020800@faireal.net>

Alexander No? wrote:

>
> At that point, I should add that AVI can do that as well.....
>
Yeah, I didn't say I hate AVI and probably I am the very one who wrote 
about
Soft SSA with AVI-Mux GUI for the frist time in japan, on 23 March 2003
http://www.faireal.net/articles/7/14/#d30323_3

I wrote: "This shows now AVI is better than OGM in a way"

Then, a big magazine in Japan "Net Runner" found this
Even in its webpage, that big magazine recomended to use AVI-MUX gui to 
embed SSA in the movie,
altho, in reality, ppl do prefer MKV for some reasons...(maybe because 
of Vorbis/AAC supports?)
# I know about Ogg Vorbis ACM too

What I was trying to say was not "The format X is the best and the other 
formats are bad"
but "Matroska is not that bad and popular in a way among endusers." 
That's just it.

>
> No, he means S_TEXT/SSA. The code 'S_SSA' has been used by some very old
> versions of mkvmerge and is wrong. I hope that no one is using 
> mkvmerge 0.4.x any longer...
>
You are right, sorry.


>
> Again overhead talk :o

Just mux XviD + AC3 in AVI / OGM /MKV
MKV is obviously smaller...and usually AVI is the 2nd best in smallness
I don't know the theory, but this is everyone's real-life experience, i 
think.

But this is not the main reason why more and more ppl are begining to 
hate AVI--
if size was the problem, they wouldnt use OGM

and I agree there may be new possibilities in AVI and OGM too,
tho common users cannot access to it atm, and SSA in OGM is still too 
buggy for real use

* Liisachan *






From steve.lhomme at free.fr  Tue Oct 14 12:31:58 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Tue, 14 Oct 2003 12:31:58 +0200
Subject: [Matroska-devel] Re: [Ffmpeg-devel] Adding matroska support to
	FFMPEG via libmatroska/libebml, in C++ ?
In-Reply-To: <3F8BC966.8020103@hrz.tu-chemnitz.de>
References: <3F89FEBF.9030908@matroska.org>	<20031013103334.C3257@submarine>	<3F8AFF47.1050805@matroska.org>	<yw1xekxgx32q.fsf@users.sourceforge.net>	<3F8B1D76.8060809@matroska.org>	<yw1x65isx00o.fsf@users.sourceforge.net>	<3F8BB863.0@free.fr>	<yw1xismstcr5.fsf@users.sourceforge.net>	<3F8BC053.3060601@free.fr>	<3F8BC1EF.4080501@hrz.tu-chemnitz.de>
	<3F8BC7D0.8020305@free.fr> <3F8BC966.8020103@hrz.tu-chemnitz.de>
Message-ID: <3F8BD09E.2080404@free.fr>

Alexander No? wrote:

> I test standard conform. If you want to see results with violations of 
> what we have agreed on, then
> I will do those tests and add an option to avimux gui to write such 
> b0rked files on the risk of the user.
> If you put 6 frames of AC3 in one matroska block, the saved overhead, 
> compared to AVI, should
> be one byte per frame in theory. It would IMHO be a hack, but you know 
> that I like hacks, and I
> will implement it if you explicitely tell me to implement a hack.
> 
> But see the constant-frame-size-flag-thing for lace headers. It would be 
> no hack and achieve the same affect.

If what you did in AVI to achieve that is a hack, it's reasonable to do 
the same with matroska... If you want to compare apples and apples.

Now the flag you propose may be an option. But IMO it's not necessary. 
It's not matroska's business to know what is inside a block. It's all a 
codec problem. As I said, for AC3 and MPEG Audio, this behaviour should 
never be a problem on any platform. As these codex contain built-in 
framing. (or did we remove the one in AC3 ? I doubt it)



From alexander.noe at s2001.tu-chemnitz.de  Tue Oct 14 12:43:56 2003
From: alexander.noe at s2001.tu-chemnitz.de (=?ISO-8859-1?Q?Alexander_No=E9?=)
Date: Tue, 14 Oct 2003 12:43:56 +0200
Subject: [Matroska-devel] Re: [Ffmpeg-devel] Adding matroska support to
	FFMPEG via libmatroska/libebml, in C++ ?
In-Reply-To: <3F8BD09E.2080404@free.fr>
References: <3F89FEBF.9030908@matroska.org>	<20031013103334.C3257@submarine>	<3F8AFF47.1050805@matroska.org>	<yw1xekxgx32q.fsf@users.sourceforge.net>	<3F8B1D76.8060809@matroska.org>	<yw1x65isx00o.fsf@users.sourceforge.net>	<3F8BB863.0@free.fr>	<yw1xismstcr5.fsf@users.sourceforge.net>	<3F8BC053.3060601@free.fr>	<3F8BC1EF.4080501@hrz.tu-chemnitz.de>	<3F8BC7D0.8020305@free.fr>
	<3F8BC966.8020103@hrz.tu-chemnitz.de> <3F8BD09E.2080404@free.fr>
Message-ID: <3F8BD36C.7030606@hrz.tu-chemnitz.de>

Steve Lhomme wrote:

> If what you did in AVI to achieve that is a hack, it's reasonable to 
> do the same with matroska... 

The difference is that AVI is explicetly designed to be used that way, 
while we agreed on
'writing audio properly' to matroska.

>  (or did we remove the one in AC3 ? I doubt it) 

No, we didn't. I take your mail as a 'yes' and will implement this as 
soon as possible.

But if you want to remux such a file, you get very bad cutting 
precision, that's why I
want a flag indicating that all frames are of equal size, so that the 
frames of a lace can
be retrieved without writing the sizes for each frame (but just by 
knowing the number
of frames from the lace header and the total size from the block size 
element). It would
be the same for dts or mp2/mp3.



Alex



From steve.lhomme at free.fr  Tue Oct 14 13:08:06 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Tue, 14 Oct 2003 13:08:06 +0200
Subject: [Matroska-devel] Re: [Ffmpeg-devel] Adding matroska support to
	FFMPEG via libmatroska/libebml, in C++ ?
In-Reply-To: <3F8BD36C.7030606@hrz.tu-chemnitz.de>
References: <3F89FEBF.9030908@matroska.org>	<20031013103334.C3257@submarine>	<3F8AFF47.1050805@matroska.org>	<yw1xekxgx32q.fsf@users.sourceforge.net>	<3F8B1D76.8060809@matroska.org>	<yw1x65isx00o.fsf@users.sourceforge.net>	<3F8BB863.0@free.fr>	<yw1xismstcr5.fsf@users.sourceforge.net>	<3F8BC053.3060601@free.fr>	<3F8BC1EF.4080501@hrz.tu-chemnitz.de>	<3F8BC7D0.8020305@free.fr>	<3F8BC966.8020103@hrz.tu-chemnitz.de>
	<3F8BD09E.2080404@free.fr> <3F8BD36C.7030606@hrz.tu-chemnitz.de>
Message-ID: <3F8BD916.8070001@free.fr>

Alexander No? wrote:
> But if you want to remux such a file, you get very bad cutting 
> precision, that's why I
> want a flag indicating that all frames are of equal size, so that the 
> frames of a lace can
> be retrieved without writing the sizes for each frame (but just by 
> knowing the number
> of frames from the lace header and the total size from the block size 
> element). It would
> be the same for dts or mp2/mp3.

Nop, that's not the philosophy inside matroska. What is inside a Block 
is unknown to the container. If you want to do such thing, you need some 
extra code (specific to a codec) that will find back the frames inside 
the block. That's why it's not encouraged (unless you don't need any 
editing for your file, which is what "publishers" just need).



From alexander.noe at s2001.tu-chemnitz.de  Tue Oct 14 13:42:51 2003
From: alexander.noe at s2001.tu-chemnitz.de (=?ISO-8859-1?Q?Alexander_No=E9?=)
Date: Tue, 14 Oct 2003 13:42:51 +0200
Subject: [Matroska-devel] Re: [Ffmpeg-devel] Adding matroska support to
	FFMPEG via libmatroska/libebml, in C++ ?
In-Reply-To: <3F8BCE48.7020800@faireal.net>
References: <3F89FEBF.9030908@matroska.org>	<20031013103334.C3257@submarine>	<3F8AFF47.1050805@matroska.org>	<yw1xekxgx32q.fsf@users.sourceforge.net>	<3F8B1D76.8060809@matroska.org>	<yw1x65isx00o.fsf@users.sourceforge.net>	<3F8BB863.0@free.fr>	<yw1xismstcr5.fsf@users.sourceforge.net>	<3F8BC4EE.2020703@faireal.net>	<3F8BC786.4060602@hrz.tu-chemnitz.de>
	<3F8BCE48.7020800@faireal.net>
Message-ID: <3F8BE13B.4010504@hrz.tu-chemnitz.de>

Liisachan wrote:

> What I was trying to say was not "The format X is the best and the 
> other formats are bad"
> but "Matroska is not that bad and popular in a way among endusers." 
> That's just it. 

Right

> Just mux XviD + AC3 in AVI / OGM /MKV
> MKV is obviously smaller...and usually AVI is the 2nd best in smallness 

I've only recently added a setting to solve that problem.

> But this is not the main reason why more and more ppl are begining to 
> hate AVI--
> if size was the problem, they wouldnt use OGM 

Well, I don't use it :-)

> and I agree there may be new possibilities in AVI and OGM too,
> tho common users cannot access to it atm, and SSA in OGM is still too 
> buggy for real use 

I would not have spent 2 weeks on writing 5.000 or 6.000 lines of 
Matroska code (that
is only my 'lib'!) of I did not see a serious reason to. I just do not 
want people to claim
things which are untrue. We don't sell stuff for money :-)



Alex



From chris at matroska.org  Tue Oct 14 13:42:26 2003
From: chris at matroska.org (Christian HJ Wiesner)
Date: Tue, 14 Oct 2003 13:42:26 +0200
Subject: [Matroska-devel] Re: [Ffmpeg-devel] Adding matroska support to
	FFMPEG via libmatroska/libebml, in C++ ?
In-Reply-To: <3F8BBC4F.1020409@hrz.tu-chemnitz.de>
References: <3F89FEBF.9030908@matroska.org>	<20031013103334.C3257@submarine>	<3F8AFF47.1050805@matroska.org>	<yw1xekxgx32q.fsf@users.sourceforge.net>	<3F8B1D76.8060809@matroska.org>	<yw1x65isx00o.fsf@users.sourceforge.net>	<3F8BB863.0@free.fr>
	<yw1xismstcr5.fsf@users.sourceforge.net>
	<3F8BBC4F.1020409@hrz.tu-chemnitz.de>
Message-ID: <3F8BE122.9010900@matroska.org>

Alexander No? wrote:

> M?ns Rullg?rd wrote:
>
>> In this case, I merely stated that quoting an official promotion site
>> doesn't really prove the popularity of anything.
>
> Wrong (it would be a bit more correct if you left out 'merely'). And 
> please define what an 'obscure forum' is.
> Alex 

Alex, you are aware that your messages dont reach the guy because he is 
not reading on our mailing list, but on the ffmpeg-devel list ?? 
However, this list would be copied automatically if you would be using 
the 'reply-all' button on your mail client, as he and Steve are doing ...

Christian



From moritz at bunkus.org  Tue Oct 14 14:21:26 2003
From: moritz at bunkus.org (Moritz Bunkus)
Date: Tue, 14 Oct 2003 14:21:26 +0200
Subject: [Matroska-devel] Re: [Ffmpeg-devel] Adding matroska support to
	FFMPEG via libmatroska/libebml, in C++ ?
In-Reply-To: <3F8BE13B.4010504@hrz.tu-chemnitz.de>
References: <3F8AFF47.1050805@matroska.org>
	<yw1xekxgx32q.fsf@users.sourceforge.net>
	<3F8B1D76.8060809@matroska.org>
	<yw1x65isx00o.fsf@users.sourceforge.net> <3F8BB863.0@free.fr>
	<yw1xismstcr5.fsf@users.sourceforge.net>
	<3F8BC4EE.2020703@faireal.net>
	<3F8BC786.4060602@hrz.tu-chemnitz.de>
	<3F8BCE48.7020800@faireal.net>
	<3F8BE13B.4010504@hrz.tu-chemnitz.de>
Message-ID: <20031014122126.GB1806@bunkus.org>

Hi.

> I would not have spent 2 weeks on writing 5.000 or 6.000 lines of
> Matroska code (that is only my 'lib'!) of I did not see a serious
> reason to. I just do not want people to claim things which are untrue.

That's definitely something to keep in mind when reading Alex' mails :)
He has spent a LOT of time writing Matroska code, and I don't think he
would have done it if he thought Matroska was a waste of time and effot.

> We don't sell stuff for money :-)

What!? We won't get rich by developping Matroska? Bummer :( Now I'm so
disappointed I'm going to shoot me right now.

;)

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


From steve.lhomme at free.fr  Tue Oct 14 14:39:49 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Tue, 14 Oct 2003 14:39:49 +0200
Subject: [Matroska-devel] Re: [Ffmpeg-devel] Adding matroska support to
	FFMPEG via libmatroska/libebml, in C++ ?
In-Reply-To: <20031014122126.GB1806@bunkus.org>
References: <3F8AFF47.1050805@matroska.org>	<yw1xekxgx32q.fsf@users.sourceforge.net>	<3F8B1D76.8060809@matroska.org>	<yw1x65isx00o.fsf@users.sourceforge.net>
	<3F8BB863.0@free.fr>	<yw1xismstcr5.fsf@users.sourceforge.net>	<3F8BC4EE.2020703@faireal.net>	<3F8BC786.4060602@hrz.tu-chemnitz.de>	<3F8BCE48.7020800@faireal.net>	<3F8BE13B.4010504@hrz.tu-chemnitz.de>
	<20031014122126.GB1806@bunkus.org>
Message-ID: <3F8BEE95.2040908@free.fr>

Moritz Bunkus wrote:
> What!? We won't get rich by developping Matroska? Bummer :( Now I'm so
> disappointed I'm going to shoot me right now.
> 
> ;)

What do you think of putting multiple AC3 frames in one block in 
matroska ? (let's try to start with 2 to see the potential gain). It 
should not lead to any playback problem. Only editing will be bad.



From moritz at bunkus.org  Tue Oct 14 14:42:16 2003
From: moritz at bunkus.org (Moritz Bunkus)
Date: Tue, 14 Oct 2003 14:42:16 +0200
Subject: [Matroska-devel] Re: [Ffmpeg-devel] Adding matroska support to
	FFMPEG via libmatroska/libebml, in C++ ?
In-Reply-To: <3F8BEE95.2040908@free.fr>
References: <3F8B1D76.8060809@matroska.org>
	<yw1x65isx00o.fsf@users.sourceforge.net> <3F8BB863.0@free.fr>
	<yw1xismstcr5.fsf@users.sourceforge.net>
	<3F8BC4EE.2020703@faireal.net>
	<3F8BC786.4060602@hrz.tu-chemnitz.de>
	<3F8BCE48.7020800@faireal.net>
	<3F8BE13B.4010504@hrz.tu-chemnitz.de>
	<20031014122126.GB1806@bunkus.org> <3F8BEE95.2040908@free.fr>
Message-ID: <20031014124215.GC1806@bunkus.org>

Hi.

> What do you think of putting multiple AC3 frames in one block in 
> matroska ? (let's try to start with 2 to see the potential gain). It 
> should not lead to any playback problem. Only editing will be bad.

I'm personally a big fan of having 'one media block in one Matroska
block' and will always try to write code that'll achieve this. I could
change that easily for the 'usual suspects' (AAC, AC3, MP3), and maybe
I'll add such a mode/hack. But I'd never document it ;)

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


From alexander.noe at s2001.tu-chemnitz.de  Tue Oct 14 14:47:13 2003
From: alexander.noe at s2001.tu-chemnitz.de (=?ISO-8859-1?Q?Alexander_No=E9?=)
Date: Tue, 14 Oct 2003 14:47:13 +0200
Subject: [Matroska-devel] Re: [Ffmpeg-devel] Adding matroska support to
	FFMPEG via libmatroska/libebml, in C++ ?
In-Reply-To: <3F8BEE95.2040908@free.fr>
References: <3F8AFF47.1050805@matroska.org>	<yw1xekxgx32q.fsf@users.sourceforge.net>	<3F8B1D76.8060809@matroska.org>	<yw1x65isx00o.fsf@users.sourceforge.net>	<3F8BB863.0@free.fr>	<yw1xismstcr5.fsf@users.sourceforge.net>	<3F8BC4EE.2020703@faireal.net>	<3F8BC786.4060602@hrz.tu-chemnitz.de>	<3F8BCE48.7020800@faireal.net>	<3F8BE13B.4010504@hrz.tu-chemnitz.de>	<20031014122126.GB1806@bunkus.org>
	<3F8BEE95.2040908@free.fr>
Message-ID: <3F8BF051.8090306@hrz.tu-chemnitz.de>

Steve Lhomme wrote:

> Moritz Bunkus wrote:
>
>> What!? We won't get rich by developping Matroska? Bummer :( Now I'm so
>> disappointed I'm going to shoot me right now.
>>
>> ;)
>
>
> What do you think of putting multiple AC3 frames in one block in 
> matroska ? (let's try to start with 2 to see the potential gain). It 
> should not lead to any playback problem. Only editing will be bad. 

The setting will be adjustable. Just as the cluster length is printed in 
red color if the user sets a value higher than 30 seconds, this setting
will be red for any value different from 1.


Alex



From alexander.noe at s2001.tu-chemnitz.de  Tue Oct 14 15:13:39 2003
From: alexander.noe at s2001.tu-chemnitz.de (=?ISO-8859-1?Q?Alexander_No=E9?=)
Date: Tue, 14 Oct 2003 15:13:39 +0200
Subject: [Matroska-devel] Re: [Ffmpeg-devel] Adding matroska support to
	FFMPEG via libmatroska/libebml, in C++ ?
In-Reply-To: <3F8BEE95.2040908@free.fr>
References: <3F8AFF47.1050805@matroska.org>	<yw1xekxgx32q.fsf@users.sourceforge.net>	<3F8B1D76.8060809@matroska.org>	<yw1x65isx00o.fsf@users.sourceforge.net>	<3F8BB863.0@free.fr>	<yw1xismstcr5.fsf@users.sourceforge.net>	<3F8BC4EE.2020703@faireal.net>	<3F8BC786.4060602@hrz.tu-chemnitz.de>	<3F8BCE48.7020800@faireal.net>	<3F8BE13B.4010504@hrz.tu-chemnitz.de>	<20031014122126.GB1806@bunkus.org>
	<3F8BEE95.2040908@free.fr>
Message-ID: <3F8BF683.7050208@hrz.tu-chemnitz.de>

Steve Lhomme wrote:

> Moritz Bunkus wrote:
>
>> What!? We won't get rich by developping Matroska? Bummer :( Now I'm so
>> disappointed I'm going to shoot me right now.
>>
>> ;)
>
>
> What do you think of putting multiple AC3 frames in one block in 
> matroska ? (let's try to start with 2 to see the potential gain). It 
> should not lead to any playback problem. Only editing will be bad. 

A first test with 4 frames per block reduced the overhead of the file 
from over 9 MB to 4,4 MB
(4 AC3 audio streams) and plays fine in Mediaplayer Classic.


Alex



From chris at matroska.org  Tue Oct 14 15:16:23 2003
From: chris at matroska.org (Christian HJ Wiesner)
Date: Tue, 14 Oct 2003 15:16:23 +0200
Subject: [Matroska-devel] Re: [Ffmpeg-devel] Adding matroska support to
	FFMPEG via libmatroska/libebml, in C++ ?
In-Reply-To: <20031014124215.GC1806@bunkus.org>
References: <3F8B1D76.8060809@matroska.org>	<yw1x65isx00o.fsf@users.sourceforge.net>
	<3F8BB863.0@free.fr>	<yw1xismstcr5.fsf@users.sourceforge.net>	<3F8BC4EE.2020703@faireal.net>	<3F8BC786.4060602@hrz.tu-chemnitz.de>	<3F8BCE48.7020800@faireal.net>	<3F8BE13B.4010504@hrz.tu-chemnitz.de>	<20031014122126.GB1806@bunkus.org>
	<3F8BEE95.2040908@free.fr> <20031014124215.GC1806@bunkus.org>
Message-ID: <3F8BF727.7090908@matroska.org>

Moritz Bunkus wrote:

>Hi.
>  
>
>>What do you think of putting multiple AC3 frames in one block in 
>>matroska ? (let's try to start with 2 to see the potential gain). It 
>>should not lead to any playback problem. Only editing will be bad.
>>    
>>
>
>I'm personally a big fan of having 'one media block in one Matroska
>block' and will always try to write code that'll achieve this. I could
>change that easily for the 'usual suspects' (AAC, AC3, MP3), and maybe
>I'll add such a mode/hack. But I'd never document it ;)
>
I love this guy, really i do :) ! Mosu, you are sooo right about this, i 
really hope you will stay with the project for a very long time !! IMHO 
and as stated on IRC just a couple of minutes ago, compatibility and 
playability should always be the higher goals than trying to save a few 
100 KB of overhead. If i would be the main developer, i would also make 
much stricter specs than robux4 did, as IMHO the freedom of the 
programmer/developer for file creation should stand behind the needs of 
the users, and that is to have a file that plays fine under all 
circumstances, and on all players ... just think of the potentially 
upcoming hardware devices, and consider what damage you can do to the 
project if those companies using matroska to overcome compatibility 
problem with b0rked and hacked AVI files on their hardware units, run 
into exactly those when users create fancy MKV files and they will not 
play :( ...

Christian
matroska project admin





From moritz at bunkus.org  Tue Oct 14 15:27:02 2003
From: moritz at bunkus.org (Moritz Bunkus)
Date: Tue, 14 Oct 2003 15:27:02 +0200
Subject: [Matroska-devel] Re: [Ffmpeg-devel] Adding matroska support to
	FFMPEG via libmatroska/libebml, in C++ ?
In-Reply-To: <3F8BF727.7090908@matroska.org>
References: <3F8BB863.0@free.fr> <yw1xismstcr5.fsf@users.sourceforge.net>
	<3F8BC4EE.2020703@faireal.net>
	<3F8BC786.4060602@hrz.tu-chemnitz.de>
	<3F8BCE48.7020800@faireal.net>
	<3F8BE13B.4010504@hrz.tu-chemnitz.de>
	<20031014122126.GB1806@bunkus.org> <3F8BEE95.2040908@free.fr>
	<20031014124215.GC1806@bunkus.org> <3F8BF727.7090908@matroska.org>
Message-ID: <20031014132702.GD1806@bunkus.org>

Hi.

> If i would be the main developer, i would also make much stricter
> specs than robux4 did, as IMHO the freedom of the programmer/developer
> for file creation should stand behind the needs of the users, and that
> is to have a file that plays fine under all circumstances, and on all
> players

I had the same discussion with Steve myself, but now I share his point
of view: Users will 'just decide' that sane options and sane files are
better. They'll probably experiment with experimental features, but when
they see that they get problems with those which they don't have with
'sane' options then they'll stick to the sane ones.

Have a little faith in the users ;)

> ... just think of the potentially upcoming hardware devices, and
> consider what damage you can do to the project if those companies
> using matroska to overcome compatibility problem with b0rked and
> hacked AVI files on their hardware units, run into exactly those when
> users create fancy MKV files and they will not play :( ...

Well that's what hardware profiles are for. I think we'll have some
'rules' which features a file must not use in order to be considered
'playable by hardware'.

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


From chris at matroska.org  Tue Oct 14 15:36:58 2003
From: chris at matroska.org (Christian HJ Wiesner)
Date: Tue, 14 Oct 2003 15:36:58 +0200
Subject: [Matroska-devel] Re: [Ffmpeg-devel] Adding matroska support to
	FFMPEG via libmatroska/libebml, in C++ ?
In-Reply-To: <20031014132702.GD1806@bunkus.org>
References: <3F8BB863.0@free.fr>
	<yw1xismstcr5.fsf@users.sourceforge.net>	<3F8BC4EE.2020703@faireal.net>	<3F8BC786.4060602@hrz.tu-chemnitz.de>	<3F8BCE48.7020800@faireal.net>	<3F8BE13B.4010504@hrz.tu-chemnitz.de>	<20031014122126.GB1806@bunkus.org>
	<3F8BEE95.2040908@free.fr>	<20031014124215.GC1806@bunkus.org>
	<3F8BF727.7090908@matroska.org> <20031014132702.GD1806@bunkus.org>
Message-ID: <3F8BFBFA.2090204@matroska.org>

Moritz Bunkus wrote:

>>... just think of the potentially upcoming hardware devices, and
>>consider what damage you can do to the project if those companies
>>using matroska to overcome compatibility problem with b0rked and
>>hacked AVI files on their hardware units, run into exactly those when
>>users create fancy MKV files and they will not play :( ...
>>    
>>
>Well that's what hardware profiles are for. I think we'll have some
>'rules' which features a file must not use in order to be considered
>'playable by hardware'.
>  
>
Yes, but we should aim to release tools such that 99% of all matroska 
files are playable by hardware devices in any case, even if the creation 
tools did not follow the hardware profile suggestions literally, because 
this will improve the interest of the hardware manufacturers in our 
container. Fortunately all current existing matroska creation apps will 
produce files that CAN be played fine by normal hardware devices, unless 
any strange switches were used, so we are on the safe side here. But i 
see it with sorrow that now there is a tendency to make the apps more 
and more powerful to 'tweak' the specs, thus making it hard for current 
hardware devices to play those files, as these dont have the processing 
power of fast drives to handle such files ....

Christian




From steve.lhomme at free.fr  Tue Oct 14 15:42:45 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Tue, 14 Oct 2003 15:42:45 +0200
Subject: [Matroska-devel] Re: [Ffmpeg-devel] Adding matroska support to
	FFMPEG via libmatroska/libebml, in C++ ?
In-Reply-To: <3F8BF727.7090908@matroska.org>
References: <3F8B1D76.8060809@matroska.org>	<yw1x65isx00o.fsf@users.sourceforge.net>	<3F8BB863.0@free.fr>	<yw1xismstcr5.fsf@users.sourceforge.net>	<3F8BC4EE.2020703@faireal.net>	<3F8BC786.4060602@hrz.tu-chemnitz.de>	<3F8BCE48.7020800@faireal.net>	<3F8BE13B.4010504@hrz.tu-chemnitz.de>	<20031014122126.GB1806@bunkus.org>	<3F8BEE95.2040908@free.fr>
	<20031014124215.GC1806@bunkus.org> <3F8BF727.7090908@matroska.org>
Message-ID: <3F8BFD55.3020103@free.fr>

Christian HJ Wiesner wrote:

> I love this guy, really i do :) ! Mosu, you are sooo right about this, i 
> really hope you will stay with the project for a very long time !! IMHO 
> and as stated on IRC just a couple of minutes ago, compatibility and 
> playability should always be the higher goals than trying to save a few 
> 100 KB of overhead. If i would be the main developer, i would also make 
> much stricter specs than robux4 did, as IMHO the freedom of the 
> programmer/developer for file creation should stand behind the needs of 
> the users, and that is to have a file that plays fine under all 
> circumstances, and on all players ... just think of the potentially 
> upcoming hardware devices, and consider what damage you can do to the 
> project if those companies using matroska to overcome compatibility 
> problem with b0rked and hacked AVI files on their hardware units, run 
> into exactly those when users create fancy MKV files and they will not 
> play :( ...

Yes but,
1) Alex's test shows that we do have the smaller overhead. (that was not 
obivous to him before). So now he cannot claim anymore than AVI can beat 
MKV. (of course there are probably cases where it would, but not in 90% 
of cases)

2) This is only for specific audio codecs that have internal framing. 
I'm 90% sure any hardware/software player that can decode these will 
have no problem being fed with multiple frames at once. I know this is 
the case for MP3 at least. And as, so far, we are the ones who define 
how each codec should interpret data out of a Block. We can change it 
easily and that will be the standard way in matroska. And that won't 
prevent anyone from using 1frame=1block. So I see no real compatibility 
problem here.



From alexander.noe at s2001.tu-chemnitz.de  Tue Oct 14 16:00:01 2003
From: alexander.noe at s2001.tu-chemnitz.de (=?ISO-8859-1?Q?Alexander_No=E9?=)
Date: Tue, 14 Oct 2003 16:00:01 +0200
Subject: [Matroska-devel] Re: [Ffmpeg-devel] Adding matroska support to
	FFMPEG via libmatroska/libebml, in C++ ?
In-Reply-To: <3F8BFD55.3020103@free.fr>
References: <3F8B1D76.8060809@matroska.org>	<yw1x65isx00o.fsf@users.sourceforge.net>	<3F8BB863.0@free.fr>	<yw1xismstcr5.fsf@users.sourceforge.net>	<3F8BC4EE.2020703@faireal.net>	<3F8BC786.4060602@hrz.tu-chemnitz.de>	<3F8BCE48.7020800@faireal.net>	<3F8BE13B.4010504@hrz.tu-chemnitz.de>	<20031014122126.GB1806@bunkus.org>	<3F8BEE95.2040908@free.fr>	<20031014124215.GC1806@bunkus.org>
	<3F8BF727.7090908@matroska.org> <3F8BFD55.3020103@free.fr>
Message-ID: <3F8C0161.5050407@hrz.tu-chemnitz.de>

Steve Lhomme wrote:

> 2) This is only for specific audio codecs that have internal framing. 
> I'm 90% sure any hardware/software player that can decode these will 
> have no problem being fed with multiple frames at once. I know this is 
> the case for MP3 at least. And as, so far, we are the ones who define 
> how each codec should interpret data out of a Block. We can change it 
> easily and that will be the standard way in matroska. And that won't 
> prevent anyone from using 1frame=1block. So I see no real 
> compatibility problem here. 

Some hardware decoders HAVE to be fed with 2 AC3 frames at once. Mosu 
said that
the AC3 filters should be made take care of b0rked hardware.

 > 1) Alex's test shows that we do have the smaller overhead. (that was 
not obivous
 > to him before).

It was. But it is a hack, and I did wait for your permission to hack 
matroska. If
you had said before that I can hack it, I would have done it...

 > So now he cannot claim anymore than AVI can > beat MKV. (of course
 > there are probably cases where it would, but not in 90% of cases)

The AVI overhead is constant at 16 bytes per chunk. Matroska has 13 for
a p-frame and 16 for a b-frame. So with video-only, it is impossible.

If you allow the same frame grouping for audio frames in Matroska as for 
AVI, I
would not see any possibility to get the AVI overhead below the Matroska 
overhead.


Alex



From steve.lhomme at free.fr  Tue Oct 14 16:34:38 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Tue, 14 Oct 2003 16:34:38 +0200
Subject: [Matroska-devel] Re: [Ffmpeg-devel] Adding matroska support to
	FFMPEG via libmatroska/libebml, in C++ ?
In-Reply-To: <3F8C0161.5050407@hrz.tu-chemnitz.de>
References: <3F8B1D76.8060809@matroska.org>	<yw1x65isx00o.fsf@users.sourceforge.net>	<3F8BB863.0@free.fr>	<yw1xismstcr5.fsf@users.sourceforge.net>	<3F8BC4EE.2020703@faireal.net>	<3F8BC786.4060602@hrz.tu-chemnitz.de>	<3F8BCE48.7020800@faireal.net>	<3F8BE13B.4010504@hrz.tu-chemnitz.de>	<20031014122126.GB1806@bunkus.org>	<3F8BEE95.2040908@free.fr>	<20031014124215.GC1806@bunkus.org>	<3F8BF727.7090908@matroska.org>
	<3F8BFD55.3020103@free.fr> <3F8C0161.5050407@hrz.tu-chemnitz.de>
Message-ID: <3F8C097E.9080404@free.fr>

Alexander No? wrote:
> It was. But it is a hack, and I did wait for your permission to hack 
> matroska. If
> you had said before that I can hack it, I would have done it...

Yup, but we simply need to change the codec page on our website to make 
this hack official. And all existing fils with AC3 would still work ! So 
I would call it a progress or new feature, not a hack (well it is, as 
long as it's not in the codec specs).

> The AVI overhead is constant at 16 bytes per chunk. Matroska has 13 for
> a p-frame and 16 for a b-frame. So with video-only, it is impossible.
> 
> If you allow the same frame grouping for audio frames in Matroska as for 
> AVI, I
> would not see any possibility to get the AVI overhead below the Matroska 
> overhead.

Good, we're progressing ;)



From paul at msn.com  Tue Oct 14 17:02:52 2003
From: paul at msn.com (Pamel)
Date: Tue, 14 Oct 2003 10:02:52 -0500
Subject: [Matroska-devel] Re: Re: [Ffmpeg-devel] Adding matroska support
	toFFMPEG via libmatroska/libebml, in C++ ?
References: <3F8B1D76.8060809@matroska.org>	<yw1x65isx00o.fsf@users.sourceforge.net>	<3F8BB863.0@free.fr>	<yw1xismstcr5.fsf@users.sourceforge.net>	<3F8BC4EE.2020703@faireal.net>	<3F8BC786.4060602@hrz.tu-chemnitz.de>	<3F8BCE48.7020800@faireal.net>	<3F8BE13B.4010504@hrz.tu-chemnitz.de>	<20031014122126.GB1806@bunkus.org>	<3F8BEE95.2040908@free.fr>	<20031014124215.GC1806@bunkus.org>	<3F8BF727.7090908@matroska.org><3F8BFD55.3020103@free.fr>
	<3F8C0161.5050407@hrz.tu-chemnitz.de> <3F8C097E.9080404@free.fr>
Message-ID: <bmh35m$q6n$1@sea.gmane.org>

"Steve Lhomme" <steve.lhomme at free.fr> wrote in message
news:3F8C097E.9080404 at free.fr...
>Yup, but we simply need to change the codec page on our website to make
>this hack official. And all existing fils with AC3 would still work ! So
>I would call it a progress or new feature, not a hack (well it is, as
>long as it's not in the codec specs).

Why not just make a Type2 Block that is improved?  It should not be hard, the
only programs that HAVE to be updated are the playback programs, and there
aren't that many programs to update.  Make the lace sizes EBML style, and add a
bit flag for all laced frames being the same size. Easy, eh?


Pamel.





From suiryc at yahoo.com  Tue Oct 14 17:20:16 2003
From: suiryc at yahoo.com (Cyrius)
Date: Tue, 14 Oct 2003 08:20:16 -0700 (PDT)
Subject: [Matroska-devel] Re: Re: [Ffmpeg-devel] Adding matroska support
	toFFMPEG via libmatroska/libebml, in C++ ?
In-Reply-To: <bmh35m$q6n$1@sea.gmane.org>
Message-ID: <20031014152016.5565.qmail@web12908.mail.yahoo.com>

--- Pamel <paul at msn.com> wrote:
> Why not just make a Type2 Block that is improved? 
> It should not be hard, the
> only programs that HAVE to be updated are the
> playback programs, and there
> aren't that many programs to update.
If the new Block defined this way can inherit from the
already existing Block, and provided that the programs
(or filters) use the common functions to retrieve the
frames (in libmatroska, 'NumberFrames' to get the
number of frames, and 'GetBuffer' to retrieve a
pointer to a class holding the important data about a
frame) then the programs would even be easily updated
by just taking into account the new EBML ID.

Of course I don't know for Gabest's and Alexnoe's
implementation since they use their own system instead
of libmatroska.

> Make the lace
> sizes EBML style, and add a
> bit flag for all laced frames being the same size.
> Easy, eh?
Yeah easy ;). It's true that using the EBML style for
encoding the size of a lace would require less space
than the current system.
But before doing anything like that some tests should
be made to make sure there is no (or at least not too
important) drawback on speed: is encoding/decoding an
EBML encoded size faster or slower than the current
system ?


__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com


From alexander.noe at s2001.tu-chemnitz.de  Tue Oct 14 17:25:05 2003
From: alexander.noe at s2001.tu-chemnitz.de (=?ISO-8859-1?Q?Alexander_No=E9?=)
Date: Tue, 14 Oct 2003 17:25:05 +0200
Subject: [Matroska-devel] Re: Re: [Ffmpeg-devel] Adding matroska support
	toFFMPEG via libmatroska/libebml, in C++ ?
In-Reply-To: <20031014152016.5565.qmail@web12908.mail.yahoo.com>
References: <20031014152016.5565.qmail@web12908.mail.yahoo.com>
Message-ID: <3F8C1551.3030205@hrz.tu-chemnitz.de>

Cyrius wrote:

>Of course I don't know for Gabest's and Alexnoe's
>implementation since they use their own system instead
>of libmatroska.
>
Mine could easily be updated

>Yeah easy ;). It's true that using the EBML style for
>encoding the size of a lace would require less space
>than the current system.
>But before doing anything like that some tests should
>be made to make sure there is no (or at least not too
>important) drawback on speed: is encoding/decoding an
>EBML encoded size faster or slower than the current
>system?
>
The current system is CRAP. But both systems could use lookup tables,
for reasonable block sizes, so they can be made work at the same 
performance.



Alex



From steve.lhomme at free.fr  Tue Oct 14 17:34:01 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Tue, 14 Oct 2003 17:34:01 +0200
Subject: [Matroska-devel] Re: Re: [Ffmpeg-devel] Adding matroska support
	toFFMPEG via libmatroska/libebml, in C++ ?
In-Reply-To: <bmh35m$q6n$1@sea.gmane.org>
References: <3F8B1D76.8060809@matroska.org>	<yw1x65isx00o.fsf@users.sourceforge.net>	<3F8BB863.0@free.fr>	<yw1xismstcr5.fsf@users.sourceforge.net>	<3F8BC4EE.2020703@faireal.net>	<3F8BC786.4060602@hrz.tu-chemnitz.de>	<3F8BCE48.7020800@faireal.net>	<3F8BE13B.4010504@hrz.tu-chemnitz.de>	<20031014122126.GB1806@bunkus.org>	<3F8BEE95.2040908@free.fr>	<20031014124215.GC1806@bunkus.org>	<3F8BF727.7090908@matroska.org><3F8BFD55.3020103@free.fr>	<3F8C0161.5050407@hrz.tu-chemnitz.de>
	<3F8C097E.9080404@free.fr> <bmh35m$q6n$1@sea.gmane.org>
Message-ID: <3F8C1769.3050905@free.fr>

Pamel wrote:
> "Steve Lhomme" <steve.lhomme at free.fr> wrote in message
> news:3F8C097E.9080404 at free.fr...
> 
>>Yup, but we simply need to change the codec page on our website to make
>>this hack official. And all existing fils with AC3 would still work ! So
>>I would call it a progress or new feature, not a hack (well it is, as
>>long as it's not in the codec specs).
> 
> 
> Why not just make a Type2 Block that is improved?  It should not be hard, the
> only programs that HAVE to be updated are the playback programs, and there
> aren't that many programs to update.  Make the lace sizes EBML style, and add a
> bit flag for all laced frames being the same size. Easy, eh?

Because it's going to make writing softawre more complicated for no 
reason. And still, your solution would take more space (still using 
lacing). So that's not needed for now.



From steve.lhomme at free.fr  Tue Oct 14 17:54:57 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Tue, 14 Oct 2003 17:54:57 +0200
Subject: [Matroska-devel] Re: Re: [Ffmpeg-devel] Adding matroska support
	toFFMPEG via libmatroska/libebml, in C++ ?
In-Reply-To: <20031014152016.5565.qmail@web12908.mail.yahoo.com>
References: <20031014152016.5565.qmail@web12908.mail.yahoo.com>
Message-ID: <3F8C1C51.90306@free.fr>

Cyrius wrote:
>>Make the lace
>>sizes EBML style, and add a
>>bit flag for all laced frames being the same size.
>>Easy, eh?
> 
> Yeah easy ;). It's true that using the EBML style for
> encoding the size of a lace would require less space
> than the current system.
> But before doing anything like that some tests should
> be made to make sure there is no (or at least not too
> important) drawback on speed: is encoding/decoding an
> EBML encoded size faster or slower than the current
> system ?

Mmm, you're starting to convince me about that "lacing2" thing. It's 
true that compared to the original lacing, it would take less space, and 
serve the same goal. It's strange that Xiph didn't come up with this 
idea ! It would also allow lacing of bigger frames (and lacing would 
still be efficient). The size of each lace could even be differential to 
the preceeding. That means 100, 120, 110 is coded as : 100, 20, -10.

So I'm OK to create this new Block2. But it will require every known 
matroska reader to be updated at the same time (to avoid problems). So 
we should see what is in the wild and coordinate the update, so that 
it's transparent to the users. (new files will not play with older 
readers)... If we do add a Block2 we should also make sure some other 
things don't need to be added/changed at the same time.

About the speed, I think it's equal. As the old way takes more space, it 
may just take more iteration to compute+write it. So I think the new 
method would be faster (maybe not the differential one).



From steve.lhomme at free.fr  Tue Oct 14 18:02:26 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Tue, 14 Oct 2003 18:02:26 +0200
Subject: [Matroska-devel] Re: Re: [Ffmpeg-devel] Adding matroska support
	toFFMPEG via libmatroska/libebml, in C++ ?
In-Reply-To: <3F8C1769.3050905@free.fr>
References: <3F8B1D76.8060809@matroska.org>	<yw1x65isx00o.fsf@users.sourceforge.net>	<3F8BB863.0@free.fr>	<yw1xismstcr5.fsf@users.sourceforge.net>	<3F8BC4EE.2020703@faireal.net>	<3F8BC786.4060602@hrz.tu-chemnitz.de>	<3F8BCE48.7020800@faireal.net>	<3F8BE13B.4010504@hrz.tu-chemnitz.de>	<20031014122126.GB1806@bunkus.org>	<3F8BEE95.2040908@free.fr>	<20031014124215.GC1806@bunkus.org>	<3F8BF727.7090908@matroska.org><3F8BFD55.3020103@free.fr>	<3F8C0161.5050407@hrz.tu-chemnitz.de>	<3F8C097E.9080404@free.fr>
	<bmh35m$q6n$1@sea.gmane.org> <3F8C1769.3050905@free.fr>
Message-ID: <3F8C1E12.4050301@free.fr>

Coded-size in the lace for the following sizes (in octet) :

                 old     new
   0 < S <127     1       1
128 < S <254     1       2
255 < S <509     2       2
510 < S <764     3       2
765 < S <1019    4       2
etc...

So the old lacing would still be enough for all codec with frames 
usually smaller than 509. Only low bitrate codex are in this case.
And it would be more efficient for codex with some frames between 128 
and 254 octets... Anyone have some stats on real world examples ? With 
low/medium/large bitrates ? For MP3, Vorbis and AAC ?



From alexander.noe at s2001.tu-chemnitz.de  Tue Oct 14 18:05:51 2003
From: alexander.noe at s2001.tu-chemnitz.de (=?ISO-8859-1?Q?Alexander_No=E9?=)
Date: Tue, 14 Oct 2003 18:05:51 +0200
Subject: [Matroska-devel] Re: Re: [Ffmpeg-devel] Adding matroska support
	toFFMPEG via libmatroska/libebml, in C++ ?
In-Reply-To: <3F8C1E12.4050301@free.fr>
References: <3F8B1D76.8060809@matroska.org>	<yw1x65isx00o.fsf@users.sourceforge.net>	<3F8BB863.0@free.fr>	<yw1xismstcr5.fsf@users.sourceforge.net>	<3F8BC4EE.2020703@faireal.net>	<3F8BC786.4060602@hrz.tu-chemnitz.de>	<3F8BCE48.7020800@faireal.net>	<3F8BE13B.4010504@hrz.tu-chemnitz.de>	<20031014122126.GB1806@bunkus.org>	<3F8BEE95.2040908@free.fr>	<20031014124215.GC1806@bunkus.org>	<3F8BF727.7090908@matroska.org><3F8BFD55.3020103@free.fr>	<3F8C0161.5050407@hrz.tu-chemnitz.de>	<3F8C097E.9080404@free.fr>	<bmh35m$q6n$1@sea.gmane.org>
	<3F8C1769.3050905@free.fr> <3F8C1E12.4050301@free.fr>
Message-ID: <3F8C1EDF.2020405@hrz.tu-chemnitz.de>

Steve Lhomme wrote:

> Coded-size in the lace for the following sizes (in octet) :
>
>                 old     new
>   0 < S <127     1       1
> 128 < S <254     1       2
> 255 < S <509     2       2
> 510 < S <764     3       2
> 765 < S <1019    4       2
> etc...
>
> So the old lacing would still be enough for all codec with frames 
> usually smaller than 509. Only low bitrate codex are in this case.
> And it would be more efficient for codex with some frames between 128 
> and 254 octets... Anyone have some stats on real world examples ? With 
> low/medium/large bitrates ? For MP3, Vorbis and AAC ? 

MP3: 960 bytes for 320 kbps @ 48 kHz, 417-418 bytes for 128 kpbs @ 44.1 khz
AC3: 768 bytes for 192 kbps, 1536 bytes for 384 kbps, 1792 bytes for 448 
kbps
DTS: 1009 bytes for 768 kbps
Vorbis would not gain anything from a new block type.

I'd say that the new block type has a flag to indicate what lacing 
system is used, or that the muxing app
is to choose which block type to use. Even video frames could be laced, 
btw :-)


Alex.



From steve.lhomme at free.fr  Tue Oct 14 18:12:36 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Tue, 14 Oct 2003 18:12:36 +0200
Subject: [Matroska-devel] Re: Re: [Ffmpeg-devel] Adding matroska support
	toFFMPEG via libmatroska/libebml, in C++ ?
In-Reply-To: <3F8C1769.3050905@free.fr>
References: <3F8B1D76.8060809@matroska.org>	<yw1x65isx00o.fsf@users.sourceforge.net>	<3F8BB863.0@free.fr>	<yw1xismstcr5.fsf@users.sourceforge.net>	<3F8BC4EE.2020703@faireal.net>	<3F8BC786.4060602@hrz.tu-chemnitz.de>	<3F8BCE48.7020800@faireal.net>	<3F8BE13B.4010504@hrz.tu-chemnitz.de>	<20031014122126.GB1806@bunkus.org>	<3F8BEE95.2040908@free.fr>	<20031014124215.GC1806@bunkus.org>	<3F8BF727.7090908@matroska.org><3F8BFD55.3020103@free.fr>	<3F8C0161.5050407@hrz.tu-chemnitz.de>	<3F8C097E.9080404@free.fr>
	<bmh35m$q6n$1@sea.gmane.org> <3F8C1769.3050905@free.fr>
Message-ID: <3F8C2074.30307@free.fr>

If we make the move, it should be done as quickly as possible.
At least all softwares that can encode should be updated now not avoid 
producing files with the old lacing. Because it should be phased out and 
marked as "obsolete" (but still part of the specs).

We always wanted to make files created now still be compatible with 
future players, so it should be ! IMO we should keep the same Block we 
use now, but just set a bit in the Block header (as suggested by Pamel 
?) to say that it's an alternative lacing...

bit 6-5 :
00 : no lacing
10 : old lacing
01 : new lacing
11 : reserved for another lacing system

That means all future players will have to keep the legacy of this old 
deprecated lacing... Well as it's not a complicated feature (as long as 
you have the other one working) it should never be a problem. But we 
need to avoid ASAP people to use the old one.

That should be quite easy to have people make the move ASAP. As long as 
you show them (who already use lacing) that their files will be smaller !



From moritz at bunkus.org  Tue Oct 14 18:16:31 2003
From: moritz at bunkus.org (Moritz Bunkus)
Date: Tue, 14 Oct 2003 18:16:31 +0200
Subject: [Matroska-devel] Re: Re: [Ffmpeg-devel] Adding matroska support
	toFFMPEG via libmatroska/libebml, in C++ ?
In-Reply-To: <3F8C1EDF.2020405@hrz.tu-chemnitz.de>
References: <3F8BE13B.4010504@hrz.tu-chemnitz.de>
	<20031014122126.GB1806@bunkus.org> <3F8BEE95.2040908@free.fr>
	<20031014124215.GC1806@bunkus.org>
	<3F8C0161.5050407@hrz.tu-chemnitz.de>
	<3F8C097E.9080404@free.fr> <bmh35m$q6n$1@sea.gmane.org>
	<3F8C1769.3050905@free.fr> <3F8C1E12.4050301@free.fr>
	<3F8C1EDF.2020405@hrz.tu-chemnitz.de>
Message-ID: <20031014161631.GH1806@bunkus.org>

Hi.

> Even video frames could be laced, btw :-)

What about references?

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


From alexander.noe at s2001.tu-chemnitz.de  Tue Oct 14 18:18:43 2003
From: alexander.noe at s2001.tu-chemnitz.de (=?ISO-8859-1?Q?Alexander_No=E9?=)
Date: Tue, 14 Oct 2003 18:18:43 +0200
Subject: [Matroska-devel] Re: Re: [Ffmpeg-devel] Adding matroska support
	toFFMPEG via libmatroska/libebml, in C++ ?
In-Reply-To: <20031014161631.GH1806@bunkus.org>
References: <3F8BE13B.4010504@hrz.tu-chemnitz.de>	<20031014122126.GB1806@bunkus.org>
	<3F8BEE95.2040908@free.fr>	<20031014124215.GC1806@bunkus.org>	<3F8C0161.5050407@hrz.tu-chemnitz.de>	<3F8C097E.9080404@free.fr>
	<bmh35m$q6n$1@sea.gmane.org>	<3F8C1769.3050905@free.fr>
	<3F8C1E12.4050301@free.fr>	<3F8C1EDF.2020405@hrz.tu-chemnitz.de>
	<20031014161631.GH1806@bunkus.org>
Message-ID: <3F8C21E3.2030200@hrz.tu-chemnitz.de>

Moritz Bunkus wrote:

>Hi.
>
>  
>
>>Even video frames could be laced, btw :-)
>>    
>>
>
>What about references?
>
Good point. Although you could declare the Reference blocks to be
an array (of whatever), this would make the thing crappy.

Forget about lacing video frames then :-)



Alex



From moritz at bunkus.org  Tue Oct 14 18:36:45 2003
From: moritz at bunkus.org (Moritz Bunkus)
Date: Tue, 14 Oct 2003 18:36:45 +0200
Subject: [Matroska-devel] Re: Re: [Ffmpeg-devel] Adding matroska support
	toFFMPEG via libmatroska/libebml, in C++ ?
In-Reply-To: <3F8C2074.30307@free.fr>
References: <3F8BCE48.7020800@faireal.net>
	<3F8BE13B.4010504@hrz.tu-chemnitz.de>
	<20031014122126.GB1806@bunkus.org> <3F8BEE95.2040908@free.fr>
	<20031014124215.GC1806@bunkus.org>
	<3F8C0161.5050407@hrz.tu-chemnitz.de>
	<3F8C097E.9080404@free.fr> <bmh35m$q6n$1@sea.gmane.org>
	<3F8C1769.3050905@free.fr> <3F8C2074.30307@free.fr>
Message-ID: <20031014163645.GI1806@bunkus.org>

Hi.

Backwards compat is a MUST. Use the bit for it.

How exactly should the new block look? I propose...
a) a flag 'same length for every block',
b) store all lengths EBML style and use differential to first value

That would produce the smallest files IMHO.

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


From alexander.noe at s2001.tu-chemnitz.de  Tue Oct 14 18:39:56 2003
From: alexander.noe at s2001.tu-chemnitz.de (=?ISO-8859-1?Q?Alexander_No=E9?=)
Date: Tue, 14 Oct 2003 18:39:56 +0200
Subject: [Matroska-devel] Re: Re: [Ffmpeg-devel] Adding matroska support
	toFFMPEG via libmatroska/libebml, in C++ ?
In-Reply-To: <20031014163645.GI1806@bunkus.org>
References: <3F8BCE48.7020800@faireal.net>	<3F8BE13B.4010504@hrz.tu-chemnitz.de>	<20031014122126.GB1806@bunkus.org>
	<3F8BEE95.2040908@free.fr>	<20031014124215.GC1806@bunkus.org>	<3F8C0161.5050407@hrz.tu-chemnitz.de>	<3F8C097E.9080404@free.fr>
	<bmh35m$q6n$1@sea.gmane.org>	<3F8C1769.3050905@free.fr>
	<3F8C2074.30307@free.fr> <20031014163645.GI1806@bunkus.org>
Message-ID: <3F8C26DC.4000704@hrz.tu-chemnitz.de>

Moritz Bunkus wrote:

>Hi.
>
>Backwards compat is a MUST. Use the bit for it.
>
>How exactly should the new block look? I propose...
>a) a flag 'same length for every block',
>b) store all lengths EBML style and use differential to first value
>
I could live with that, even though it were signed variable size ints.



Alex



From steve.lhomme at free.fr  Tue Oct 14 18:45:17 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Tue, 14 Oct 2003 18:45:17 +0200
Subject: [Matroska-devel] Re: Re: [Ffmpeg-devel] Adding matroska support
	toFFMPEG via libmatroska/libebml, in C++ ?
In-Reply-To: <3F8C21E3.2030200@hrz.tu-chemnitz.de>
References: <3F8BE13B.4010504@hrz.tu-chemnitz.de>	<20031014122126.GB1806@bunkus.org>	<3F8BEE95.2040908@free.fr>	<20031014124215.GC1806@bunkus.org>	<3F8C0161.5050407@hrz.tu-chemnitz.de>	<3F8C097E.9080404@free.fr>	<bmh35m$q6n$1@sea.gmane.org>	<3F8C1769.3050905@free.fr>	<3F8C1E12.4050301@free.fr>	<3F8C1EDF.2020405@hrz.tu-chemnitz.de>	<20031014161631.GH1806@bunkus.org>
	<3F8C21E3.2030200@hrz.tu-chemnitz.de>
Message-ID: <3F8C281D.3060409@free.fr>

Alexander No? wrote:

>>> Even video frames could be laced, btw :-)
>>>   
>>
>>
>> What about references?
>>
> Good point. Although you could declare the Reference blocks to be
> an array (of whatever), this would make the thing crappy.
> 
> Forget about lacing video frames then :-)

Guys, with the TimeSlice system I think you can reference such frames. 
But maybe I'm wrong.

About the new lacing. I'll make the necessary changes in libmatroska and 
the specs tonight. I'll use a new bit in the Block header. And the size 
in the lace will be coded the EBML way, in a differential way (as 
already explained).



From moritz at bunkus.org  Tue Oct 14 18:57:33 2003
From: moritz at bunkus.org (Moritz Bunkus)
Date: Tue, 14 Oct 2003 18:57:33 +0200
Subject: [Matroska-devel] libmatroska wish
Message-ID: <20031014165733.GJ1806@bunkus.org>

Hey robux,

while you're at it, one wish of mine would be to have a Read() function
in EbmlMaster to be extended to take another bool parameter, 'read
fully' or whatever it might be called. The idea is not to read the
complete data frames but only their headers - that would be useful for
scanning the file. It'd make reading the file a bit (or even a lot)
faster, and there's less memcpy if the user explicitely wants that.

(I need it for mkvinfo and for mkvmerge's 1st pass during splitting -
for those I only need the frame lengths, timecodes etc, not the actual
frame contents.)

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


From paul at msn.com  Tue Oct 14 19:41:19 2003
From: paul at msn.com (Pamel)
Date: Tue, 14 Oct 2003 12:41:19 -0500
Subject: [Matroska-devel] Re: Re: Re: [Ffmpeg-devel] Adding matroska
	supporttoFFMPEG via libmatroska/libebml, in C++ ?
References: <3F8BCE48.7020800@faireal.net>	<3F8BE13B.4010504@hrz.tu-chemnitz.de>	<20031014122126.GB1806@bunkus.org><3F8BEE95.2040908@free.fr>	<20031014124215.GC1806@bunkus.org>	<3F8C0161.5050407@hrz.tu-chemnitz.de>	<3F8C097E.9080404@free.fr><bmh35m$q6n$1@sea.gmane.org>	<3F8C1769.3050905@free.fr><3F8C2074.30307@free.fr>
	<20031014163645.GI1806@bunkus.org>
	<3F8C26DC.4000704@hrz.tu-chemnitz.de>
Message-ID: <bmhcep$h0g$1@sea.gmane.org>

"Alexander No?" <alexander.noe at s2001.tu-chemnitz.de> wrote...
> Moritz Bunkus wrote:
> >Backwards compat is a MUST. Use the bit for it.

What if we just had a new ID for the new block design?  Old readers would just
skip it and would register no Blocks from the stream, which is the point of EBML
anyway.  Everything else would be identical, so new coding would just be to
handle the new ID.  What is the cost/benefit of going to a new ID?

> >How exactly should the new block look? I propose...
> >a) a flag 'same length for every block',
> >b) store all lengths EBML style and use differential to first value
> >
> I could live with that, even though it were signed variable size ints.

Would this help out with the higher bitrate codecs?  The only one that I know of
that wouldn't use the 'same length flag' would be VBR MP3.  So, would VBR MP3
benefit from using differentials?

For low bitrate I believe the main issue is Vorbis.  (Does AAC really ever use
variable sized packets?)  I remember Mosu once posted the typical sizes of
Vorbis packets.  If Vorbis uses packets that are the same size, close to each
other, than I can see this being useful, but if it typically varies the size a
lot from packet to packet, then it would probably take as much, or more, to use
the signed ints.


Pamel





From moritz at bunkus.org  Tue Oct 14 20:00:10 2003
From: moritz at bunkus.org (Moritz Bunkus)
Date: Tue, 14 Oct 2003 20:00:10 +0200
Subject: [Matroska-devel] Re: Re: Re: [Ffmpeg-devel] Adding matroska
	supporttoFFMPEG via libmatroska/libebml, in C++ ?
In-Reply-To: <bmhcep$h0g$1@sea.gmane.org>
References: <3F8BCE48.7020800@faireal.net>
	<3F8BE13B.4010504@hrz.tu-chemnitz.de>
	<20031014124215.GC1806@bunkus.org>
	<3F8C0161.5050407@hrz.tu-chemnitz.de>
	<20031014163645.GI1806@bunkus.org>
	<3F8C26DC.4000704@hrz.tu-chemnitz.de> <bmhcep$h0g$1@sea.gmane.org>
Message-ID: <20031014180010.GK1806@bunkus.org>

Hi.

> What if we just had a new ID for the new block design?  Old readers would just
> skip it and would register no Blocks from the stream, which is the point of EBML
> anyway.  Everything else would be identical, so new coding would just be to
> handle the new ID.  What is the cost/benefit of going to a new ID?

Yeah, a new ID might be good. Only drawback I see so far is that we'd
have one more 1 byte ID that's used, but hey, they're there to be used ;)

> Would this help out with the higher bitrate codecs?  The only one that I know of
> that wouldn't use the 'same length flag' would be VBR MP3.  So, would VBR MP3
> benefit from using differentials?

Dunno. No VBR track will have this flag set - this is not about duration but
bitrate. Nevertheless AC3 is CBR if I recall correctly. AAC is VBR and
looks really interesting: (just one sample here)

|  + Block (track number 1, 8 frame(s), timecode 0.000s)
|   + Frame with size 333
|   + Frame with size 329
|   + Frame with size 331
|   + Frame with size 341
|   + Frame with size 345
|   + Frame with size 337
|   + Frame with size 342
|   + Frame with size 340
| + Block group
|  + Block (track number 1, 8 frame(s), timecode 0.170s)
|   + Frame with size 339
|   + Frame with size 341
|   + Frame with size 338
|   + Frame with size 344
|   + Frame with size 345
|   + Frame with size 339
|   + Frame with size 342
|   + Frame with size 333

Here differential values would actually be a gain.

For Vorbis things are different:

|  + Block (track number 1, 8 frame(s), timecode 0.000s)
|   + Frame with size 26
|   + Frame with size 273
|   + Frame with size 223
|   + Frame with size 209
|   + Frame with size 213
|   + Frame with size 207
|   + Frame with size 209
|   + Frame with size 221
| + Block group
|  + Block (track number 1, 8 frame(s), timecode 0.141s)
|   + Frame with size 41
|   + Frame with size 55
|   + Frame with size 56
|   + Frame with size 218
|   + Frame with size 195
|   + Frame with size 193
|   + Frame with size 207
|   + Frame with size 201
| + Block group
|  + Block (track number 1, 8 frame(s), timecode 0.256s)
|   + Frame with size 208
|   + Frame with size 200
|   + Frame with size 204
|   + Frame with size 208
|   + Frame with size 205
|   + Frame with size 209
|   + Frame with size 207
|   + Frame with size 204

Here you might be lucky (or not), but for this example differential
coding would be the winner, too.

And as Cyrius just said:
[.19:57:29.] <@Cyrius> Pamel: some CBR MP3 streams also have variable
frame size
[.19:57:44.] <@Cyrius> those at 44.1kHz (for mpeg v1) IIRC
[.19:58:03.] <@Cyrius> actually those ones vary of 1 byte
[.19:58:21.] <@Cyrius> e.g. 417/418 bytes per frame
[.19:58:29.] <@Pamel> We will lie then and say they are all the same
size.
[.19:58:41.] <@Cyrius> you can't :p
[.19:58:47.] <@Cyrius> we are talking of lacing
[.19:58:51.] <@Pamel> Just pad the frame.  ;)
[.19:59:02.] <@Cyrius> if you lie about the size then you won't read the
correct amount of data :p
[.19:59:09.] <@Cyrius> lol
[.19:59:15.] <@Cyrius> no padding allowed :p
[.19:59:25.] <@Pamel> How often do you see those?

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


From christian at matroska.org  Tue Oct 14 22:02:44 2003
From: christian at matroska.org (ChristianHJW)
Date: Tue, 14 Oct 2003 22:02:44 +0200
Subject: [Matroska-devel] Re: Adding matroska support to FFMPEG via
	libmatroska/libebml, in C++ ?
In-Reply-To: <20031014142122.GZ2856@brightrain.aerifal.cx>
References: <3F89FEBF.9030908@matroska.org> <20031013103334.C3257@submarine>
	<3F8AFF47.1050805@matroska.org>
	<yw1xekxgx32q.fsf@users.sourceforge.net>
	<3F8B1D76.8060809@matroska.org>
	<yw1x65isx00o.fsf@users.sourceforge.net> <3F8BB863.0@free.fr>
	<yw1xismstcr5.fsf@users.sourceforge.net> <3F8BC053.3060601@free.fr>
	<20031014142122.GZ2856@brightrain.aerifal.cx>
Message-ID: <3F8C5664.2010604@matroska.org>

@ Michael, all : I promise this is my last email about this subject to 
the list, at least for the time being.

D Richard Felker III wrote:
> Hint 1: Matroska has large overhead.

Richard, you always claim that, but i havent seen any proof of those yet 
from your side. Show me another container with a similar flexibility 
that can produce smaller file sizes and is extendable for the next 10 
years. I bet you cant.

> Hint 2: Matroska is so overcomplicated and bloated that the specs
> might as well not be available.

Well, there seem to be a couple of programmers now that dont have any 
problems understanding those 'bloated' specs and make working code based 
on it. It took Gabest 3 days to make his implementation, and he made it 
from scratch, and even wrapped a DirectShow parser and muxer filter 
around it. I would ask you to not judge about things from the view of 
your obviously limited coding capabilities all the time. Just because 
you think they are 'bloated' they dont have to be necessarily like that.

>>opened to any codec, extensible as you wish, all based on an easy 
>>principle (EBML). That's all that comes to my mind for now.
> ROTFL! Perhaps you should learn about this stuff from a performance
> software perspective rather than from a CS-professor perspective. EBML
> is inefficient and totally unnecessary.

LOL ! Sorry, but i cant help laughing here. We had a couple of important 
aspects to respect when making the specs, but for sure 'performance 
perspectives' were not amongst them. Any small Pentium 3 can play 
matroska files without having to invest more than 2% of his CPU power 
for parsing of the file. And when i think about the CPU requirements for 
upcoming compression formats like h.264, this argument just makes me 
smile, sorry.

Richard, you think much to MPEG biased, in a very narrow angle of view. 
We didnt make a container primarily for the existing compression formats 
of today. If we had them in mind, we would have extended the good old 
MPEG container a bit.

>>>In this case, I merely stated that quoting an official promotion site
>>>doesn't really prove the popularity of anything.
>>So what would be decisive for you ? Popularity of a crap format ? Of an 
>>unpopular format that is technically good ? Matroska has a (fast) 
>>growing popularity and is technically good (I won't claim it's the best, 
>>but it's among the best ones). What else do you need ?
>  
> It's technically bad. All it succeeds in doing is being better than
> the horrible avi and ogm containers. Rich

Yes, its much better than AVI already, and the compression formats where 
matroska will be excellent to use with are not even specified yet ;) ....

Regards

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



From steve.lhomme at free.fr  Tue Oct 14 22:11:13 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Tue, 14 Oct 2003 22:11:13 +0200
Subject: [Matroska-devel] Re: Re: [Ffmpeg-devel] Adding matroska support
	toFFMPEG via libmatroska/libebml, in C++ ?
In-Reply-To: <20031014163645.GI1806@bunkus.org>
References: <3F8BCE48.7020800@faireal.net>	<3F8BE13B.4010504@hrz.tu-chemnitz.de>	<20031014122126.GB1806@bunkus.org>
	<3F8BEE95.2040908@free.fr>	<20031014124215.GC1806@bunkus.org>	<3F8C0161.5050407@hrz.tu-chemnitz.de>	<3F8C097E.9080404@free.fr>
	<bmh35m$q6n$1@sea.gmane.org>	<3F8C1769.3050905@free.fr>
	<3F8C2074.30307@free.fr> <20031014163645.GI1806@bunkus.org>
Message-ID: <3F8C5861.8090807@free.fr>

Moritz Bunkus wrote:
> Hi.
> 
> Backwards compat is a MUST. Use the bit for it.
> 
> How exactly should the new block look? I propose...
> a) a flag 'same length for every block',
> b) store all lengths EBML style and use differential to first value
> 
> That would produce the smallest files IMHO.

OK, that makes 3 lacing + no lacing. That fits in the 2 bits I want to 
use in the header (bit 5-6) :
00 no lacing
01 lacing 1 (original)
11 lacing 2 (EBMLed)
10 fixed lacing




From steve.lhomme at free.fr  Tue Oct 14 22:19:07 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Tue, 14 Oct 2003 22:19:07 +0200
Subject: [Matroska-devel] Re: Re: Re: [Ffmpeg-devel] Adding
	matroska	supporttoFFMPEG via libmatroska/libebml, in C++ ?
In-Reply-To: <20031014180010.GK1806@bunkus.org>
References: <3F8BCE48.7020800@faireal.net>	<3F8BE13B.4010504@hrz.tu-chemnitz.de>	<20031014124215.GC1806@bunkus.org>	<3F8C0161.5050407@hrz.tu-chemnitz.de>	<20031014163645.GI1806@bunkus.org>	<3F8C26DC.4000704@hrz.tu-chemnitz.de>
	<bmhcep$h0g$1@sea.gmane.org> <20031014180010.GK1806@bunkus.org>
Message-ID: <3F8C5A3B.4010801@free.fr>

Moritz Bunkus wrote:

> And as Cyrius just said:
> [.19:57:29.] <@Cyrius> Pamel: some CBR MP3 streams also have variable
> frame size
> [.19:57:44.] <@Cyrius> those at 44.1kHz (for mpeg v1) IIRC
> [.19:58:03.] <@Cyrius> actually those ones vary of 1 byte
> [.19:58:21.] <@Cyrius> e.g. 417/418 bytes per frame

I can confirm that. That's why I was talking earlier (or on IRC) about 
real CBR. Which is not even the case for MP3 CBR. In a system with 
automatic lacing, it would be OK to have the fixed-size lace (PCM would 
benefit from it). So we can keep it, even though it will rarely be used.



From alexander.noe at s2001.tu-chemnitz.de  Tue Oct 14 22:20:32 2003
From: alexander.noe at s2001.tu-chemnitz.de (=?ISO-8859-1?Q?Alexander_No=E9?=)
Date: Tue, 14 Oct 2003 22:20:32 +0200
Subject: [Matroska-devel] Re: Re: Re: [Ffmpeg-devel]
	Adding	matroska	supporttoFFMPEG via libmatroska/libebml, in C++ ?
In-Reply-To: <3F8C5A3B.4010801@free.fr>
References: <3F8BCE48.7020800@faireal.net>	<3F8BE13B.4010504@hrz.tu-chemnitz.de>	<20031014124215.GC1806@bunkus.org>	<3F8C0161.5050407@hrz.tu-chemnitz.de>	<20031014163645.GI1806@bunkus.org>	<3F8C26DC.4000704@hrz.tu-chemnitz.de>	<bmhcep$h0g$1@sea.gmane.org>
	<20031014180010.GK1806@bunkus.org> <3F8C5A3B.4010801@free.fr>
Message-ID: <3F8C5A90.2090203@hrz.tu-chemnitz.de>

Steve Lhomme wrote:

> Moritz Bunkus wrote:
>
>> And as Cyrius just said:
>> [.19:57:29.] <@Cyrius> Pamel: some CBR MP3 streams also have variable
>> frame size
>> [.19:57:44.] <@Cyrius> those at 44.1kHz (for mpeg v1) IIRC
>> [.19:58:03.] <@Cyrius> actually those ones vary of 1 byte
>> [.19:58:21.] <@Cyrius> e.g. 417/418 bytes per frame
>
>
> I can confirm that. That's why I was talking earlier (or on IRC) about 
> real CBR. Which is not even the case for MP3 CBR.

For 48 khz mp3, it is



Alex



From steve.lhomme at free.fr  Tue Oct 14 22:25:44 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Tue, 14 Oct 2003 22:25:44 +0200
Subject: [Matroska-devel] Re: Adding matroska support to FFMPEG
	via	libmatroska/libebml, in C++ ?
In-Reply-To: <3F8C5664.2010604@matroska.org>
References: <3F89FEBF.9030908@matroska.org>
	<20031013103334.C3257@submarine>	<3F8AFF47.1050805@matroska.org>	<yw1xekxgx32q.fsf@users.sourceforge.net>	<3F8B1D76.8060809@matroska.org>	<yw1x65isx00o.fsf@users.sourceforge.net>
	<3F8BB863.0@free.fr>	<yw1xismstcr5.fsf@users.sourceforge.net>
	<3F8BC053.3060601@free.fr>	<20031014142122.GZ2856@brightrain.aerifal.cx>
	<3F8C5664.2010604@matroska.org>
Message-ID: <3F8C5BC8.4010409@free.fr>

ChristianHJW wrote:

> D Richard Felker III wrote:
> 
>> Hint 1: Matroska has large overhead.

>>> opened to any codec, extensible as you wish, all based on an easy 
>>> principle (EBML). That's all that comes to my mind for now.
>>
>> ROTFL! Perhaps you should learn about this stuff from a performance
>> software perspective rather than from a CS-professor perspective. EBML
>> is inefficient and totally unnecessary.


>>>> In this case, I merely stated that quoting an official promotion site
>>>> doesn't really prove the popularity of anything.
>>>
>>> So what would be decisive for you ? Popularity of a crap format ? Of 
>>> an unpopular format that is technically good ? Matroska has a (fast) 
>>> growing popularity and is technically good (I won't claim it's the 
>>> best, but it's among the best ones). What else do you need ?
>>
>>  
>> It's technically bad. All it succeeds in doing is being better than
>> the horrible avi and ogm containers. Rich


It's incredible how far a man is ready to go to get ridiculous... We can 
prove what we say, and you can't. Apparently you know nothing about 
matroska since you can't read bloated specs. So please shut the fuck up. 
I'm sure that will leave time for everyone to do more creative things.



From christian at matroska.org  Wed Oct 15 04:59:22 2003
From: christian at matroska.org (ChristianHJW)
Date: Wed, 15 Oct 2003 04:59:22 +0200
Subject: [Fwd: Re: Re: [Matroska-devel] Re: Adding matroska support to FFMPEG
	via libmatroska/libebml, in C++ ?]
Message-ID: <3F8CB80A.6060003@matroska.org>

I promised not to reply anymore to ffmpeg-devel AT lists.sf.net after my 
last email, but i thought i forward you Felker's last reply, in case 
anybody likes to point him to Alex Noe's overhead comparison ;) ....

Michael Niedermayer, the author of the 'nut' specs, certainly knows his 
stuff, no doubt. He wasnt interested to help making our specs that time, 
but came with his specs after we started making matroska a reality. 
There is no working implementation of 'nut' AFAIK, and i really hope it 
will stay that way. Low overhead was never our main focus, but future 
extendability, and overhead will be even less important when DVD burners 
will have replaced CDs completely, so whats the point. I wonder if a nut 
file could easily support h.264 NALUs or can be edited without a codec ....

Christian

-------- Original Message --------
Subject: Re: Re: [Matroska-devel] Re: Adding matroska support to FFMPEG 
via libmatroska/libebml, in C++ ?
Date: Tue, 14 Oct 2003 19:42:47 -0400
From: D Richard Felker III <dalias at aerifal.cx>
Reply-To: ffmpeg-devel at lists.sourceforge.net
Newsgroups: gmane.comp.video.ffmpeg.devel
References: <20031013103334.C3257 at submarine> 
<3F8AFF47.1050805 at matroska.org> <yw1xekxgx32q.fsf at users.sourceforge.net> 
<3F8B1D76.8060809 at matroska.org> <yw1x65isx00o.fsf at users.sourceforge.net> 
<3F8BB863.0 at free.fr> <yw1xismstcr5.fsf at users.sourceforge.net> 
<3F8BC053.3060601 at free.fr> <20031014142122.GZ2856 at brightrain.aerifal.cx> 
<3F8C5664.2010604 at matroska.org>

On Tue, Oct 14, 2003 at 10:02:44PM +0200, ChristianHJW wrote:
> @ Michael, all : I promise this is my last email about this subject to 
> the list, at least for the time being.
> 
> D Richard Felker III wrote:
> >Hint 1: Matroska has large overhead.
> 
> Richard, you always claim that, but i havent seen any proof of those yet 
> from your side. Show me another container with a similar flexibility 
> that can produce smaller file sizes and is extendable for the next 10 
> years. I bet you cant.

I'll let you do it for me. Tell me how many bytes per frame in
overhead you have, and we'll compare it to nut. I have no desire to go
back and read your spec again (it was bad enough the first time). What
I can guarantee is that if you tag fields in addition to storing the
data, you will inherently use a lot more space, and that makes a big
difference at low bitrate (and even a significant difference at
moderate bitrates).

> >Hint 2: Matroska is so overcomplicated and bloated that the specs
> >might as well not be available.
> 
> Well, there seem to be a couple of programmers now that dont have any 
> problems understanding those 'bloated' specs and make working code based 
> on it. It took Gabest 3 days to make his implementation, and he made it 
> from scratch, and even wrapped a DirectShow parser and muxer filter 

Good for him. Did he do it with no aid but the spec document, or did
he ask you for help, and/or read your source? I find it hard to
believe anyone could write a demuxer using your specs alone, and have
it behave fully as you expect.

> around it. I would ask you to not judge about things from the view of 
> your obviously limited coding capabilities all the time. Just because 
> you think they are 'bloated' they dont have to be necessarily like that.

I don't think my coding abilities are the topic in question here.

> >>opened to any codec, extensible as you wish, all based on an easy 
> >>principle (EBML). That's all that comes to my mind for now.
> >ROTFL! Perhaps you should learn about this stuff from a performance
> >software perspective rather than from a CS-professor perspective. EBML
> >is inefficient and totally unnecessary.
> 
> LOL ! Sorry, but i cant help laughing here. We had a couple of important 
> aspects to respect when making the specs, but for sure 'performance 
> perspectives' were not amongst them. Any small Pentium 3 can play 
> matroska files without having to invest more than 2% of his CPU power 
> for parsing of the file. And when i think about the CPU requirements for 
> upcoming compression formats like h.264, this argument just makes me 
> smile, sorry.

Then you misunderstood. It has nothing to do with cpu time required to
decode, but the mindset. The people who designed NUT are competent and
experienced in writing performance code, and the efficiency-oriented
mindset that goes along with it. You're designing from a horrible
XML-inspired undergrad CS dork mindset.

Actually, bitstream parsing performance can be an issue too, but I
doubt the cpu requirements of Matroska are very high.

> Richard, you think much to MPEG biased, in a very narrow angle of view. 
> We didnt make a container primarily for the existing compression formats 
> of today. If we had them in mind, we would have extended the good old 
> MPEG container a bit.

This is nonsense. NUT can contain any audio and video content,
regardless of codec, present or future. There are only a few very
simple requirements to be able to claim this; AVI was just so poorly
designed that it does not meet them.

BTW, I find this claim of yours amusing, since Matroska does not allow
packet-resolution seeking in vorbis audio.

> >>>In this case, I merely stated that quoting an official promotion site
> >>>doesn't really prove the popularity of anything.
> >>So what would be decisive for you ? Popularity of a crap format ? Of an 
> >>unpopular format that is technically good ? Matroska has a (fast) 
> >>growing popularity and is technically good (I won't claim it's the best, 
> >>but it's among the best ones). What else do you need ?
> > 
> >It's technically bad. All it succeeds in doing is being better than
> >the horrible avi and ogm containers. Rich
> 
> Yes, its much better than AVI already, and the compression formats where 
> matroska will be excellent to use with are not even specified yet ;) ....

This is bullshit. If you're going to make such a claim, back it up.
However, I promise you that you can't.

Rich



-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php



From jcsston at toughguy.net  Wed Oct 15 07:46:16 2003
From: jcsston at toughguy.net (Jory)
Date: Wed, 15 Oct 2003 00:46:16 -0500
Subject: [Matroska-devel] Fw: MatroskaUtils
Message-ID: <001701c392e0$9f9d1f70$0200a8c0@jcsston>

I've commited the followed define/includes to libebml CVS.

----- Original Message ----- 
From: "Zen" <Zen at MediaArea.net>
To: "Jory" <jcsston at toughguy.net>
Sent: Tuesday, October 14, 2003 4:43 PM
Subject: Re: MatroskaUtils


> Another thing : I don't know how to contact libebml developers 
> (CoreCodec.org is a little bazaar, with not a lot of bug reports, I am 
> afraid that the tracker is useless :((  )
> 
> How to contact them to say them this :
> Add this line in EbmlBinary.h :
> #if defined (__BORLANDC__) //Maybe other compilers?
>     #include <mem.h>
> #endif //__BORLANDC__
> Add this line in StdIOCallback.h :
> #if defined (__BORLANDC__) //Maybe other compilers?
>     #include <errno.h>
>     #include <stdio.h>
> #endif //__BORLANDC__
> 
> Thanks for your attention
> Jerome
> 



From steve.lhomme at free.fr  Wed Oct 15 09:47:07 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Wed, 15 Oct 2003 09:47:07 +0200
Subject: [Fwd: Re: Re: [Matroska-devel] Re: Adding matroska support to
	FFMPEG	via libmatroska/libebml, in C++ ?]
In-Reply-To: <3F8CB80A.6060003@matroska.org>
References: <3F8CB80A.6060003@matroska.org>
Message-ID: <3F8CFB7B.6010201@free.fr>

ChristianHJW wrote:
> I promised not to reply anymore to ffmpeg-devel AT lists.sf.net after my 
> last email, but i thought i forward you Felker's last reply, in case 
> anybody likes to point him to Alex Noe's overhead comparison ;) ....
> 
> Michael Niedermayer, the author of the 'nut' specs, certainly knows his 
> stuff, no doubt. He wasnt interested to help making our specs that time, 
> but came with his specs after we started making matroska a reality. 
> There is no working implementation of 'nut' AFAIK, and i really hope it 
> will stay that way. Low overhead was never our main focus, but future 
> extendability, and overhead will be even less important when DVD burners 
> will have replaced CDs completely, so whats the point. I wonder if a nut 
> file could easily support h.264 NALUs or can be edited without a codec ....

As I was told on IRC : don't feed the troll... I should have remembered 
that.
Maybe NUT (was that the Mplayer Container ?) is good at some stuff. But 
based on why the troll says, it sound like a mix of MPEG & AVI. Which 
has nothing new or interresting. Also the comparison of mindset makes me 
feel like the old debate ASM vs C vs C++. Depending on what you need to 
do, one is better than the other.



From moritz at bunkus.org  Wed Oct 15 10:23:38 2003
From: moritz at bunkus.org (Moritz Bunkus)
Date: Wed, 15 Oct 2003 10:23:38 +0200
Subject: [Fwd: Re: Re: [Matroska-devel] Re: Adding matroska support to
	FFMPEG via libmatroska/libebml, in C++ ?]
In-Reply-To: <3F8CB80A.6060003@matroska.org>
References: <3F8CB80A.6060003@matroska.org>
Message-ID: <20031015082338.GM1806@bunkus.org>

Hi.

> There is no working implementation of 'nut' AFAIK, and i really hope
> it will stay that way.

There's a NUT demuxer in ffmpeg and mplayer G2 so far, but I don't know
whether or not they have a muxer, too.

Anyway, they don't aim to be our contenders, so just ignore them for now.

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


From steve.lhomme at free.fr  Wed Oct 15 10:37:00 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Wed, 15 Oct 2003 10:37:00 +0200
Subject: [Matroska-devel] Rejig (for spyder)
Message-ID: <3F8D072C.3000103@free.fr>

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

Did you check that out ?



From steve.lhomme at free.fr  Wed Oct 15 12:51:44 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Wed, 15 Oct 2003 12:51:44 +0200
Subject: [Matroska-devel] Added lacing
In-Reply-To: <3F8C5A90.2090203@hrz.tu-chemnitz.de>
References: <3F8BCE48.7020800@faireal.net>	<3F8BE13B.4010504@hrz.tu-chemnitz.de>	<20031014124215.GC1806@bunkus.org>	<3F8C0161.5050407@hrz.tu-chemnitz.de>	<20031014163645.GI1806@bunkus.org>	<3F8C26DC.4000704@hrz.tu-chemnitz.de>	<bmhcep$h0g$1@sea.gmane.org>	<20031014180010.GK1806@bunkus.org>
	<3F8C5A3B.4010801@free.fr> <3F8C5A90.2090203@hrz.tu-chemnitz.de>
Message-ID: <3F8D26C0.8030109@free.fr>

2 thing about the new lacing :

- As we use bit 6 for EBML lacing too, old players may confuse between 
EBML and Xiph lacing. That introduces a problem with players/readers. 
But as we know all the current ones, we can fix them and inform people. 
IMO that's not a major problem. People know we are still in development 
stage for both the format and the code (especially they can understand 
that the code has problems). Otherwise we can use one more bit. But I 
don't think it's that worth.

- I will make some tests between different ways to store the sign in the 
EBML lacing. Namely the way I put in the specs and the way Alexnoe 
suggested of putting a signed value directly in the EBML. I'll make some 
speed tests and see which one is better to read/write (performance 
should be best for reading)... If anyone wants to code that before 
myself (tonight or friday evening), feel free ;)



From alexander.noe at s2001.tu-chemnitz.de  Wed Oct 15 12:56:47 2003
From: alexander.noe at s2001.tu-chemnitz.de (=?ISO-8859-1?Q?Alexander_No=E9?=)
Date: Wed, 15 Oct 2003 12:56:47 +0200
Subject: [Matroska-devel] Added lacing
In-Reply-To: <3F8D26C0.8030109@free.fr>
References: <3F8BCE48.7020800@faireal.net>	<3F8BE13B.4010504@hrz.tu-chemnitz.de>	<20031014124215.GC1806@bunkus.org>	<3F8C0161.5050407@hrz.tu-chemnitz.de>	<20031014163645.GI1806@bunkus.org>	<3F8C26DC.4000704@hrz.tu-chemnitz.de>	<bmhcep$h0g$1@sea.gmane.org>	<20031014180010.GK1806@bunkus.org>	<3F8C5A3B.4010801@free.fr>
	<3F8C5A90.2090203@hrz.tu-chemnitz.de> <3F8D26C0.8030109@free.fr>
Message-ID: <3F8D27EF.6090608@hrz.tu-chemnitz.de>

Steve Lhomme wrote:

> - I will make some tests between different ways to store the sign in 
> the EBML lacing. Namely the way I put in the specs and the way Alexnoe 
> suggested of putting a signed value directly in the EBML. I'll make 
> some speed tests and see which one is better to read/write 
> (performance should be best for reading)... If anyone wants to code 
> that before myself (tonight or friday evening), feel free ;) 

I've already implemented both versions, and it really does not matter. 
Since you could use lookup tables
for both cases for small sizes, the performance is equal as well. Leave 
it as it is in the specs (large
sizes rarely occur).



Alex



From steve.lhomme at free.fr  Wed Oct 15 13:05:13 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Wed, 15 Oct 2003 13:05:13 +0200
Subject: [Matroska-devel] Added lacing
In-Reply-To: <3F8D27EF.6090608@hrz.tu-chemnitz.de>
References: <3F8BCE48.7020800@faireal.net>	<3F8BE13B.4010504@hrz.tu-chemnitz.de>	<20031014124215.GC1806@bunkus.org>	<3F8C0161.5050407@hrz.tu-chemnitz.de>	<20031014163645.GI1806@bunkus.org>	<3F8C26DC.4000704@hrz.tu-chemnitz.de>	<bmhcep$h0g$1@sea.gmane.org>	<20031014180010.GK1806@bunkus.org>	<3F8C5A3B.4010801@free.fr>	<3F8C5A90.2090203@hrz.tu-chemnitz.de>
	<3F8D26C0.8030109@free.fr> <3F8D27EF.6090608@hrz.tu-chemnitz.de>
Message-ID: <3F8D29E9.7040807@free.fr>

Alexander No? wrote:

> Steve Lhomme wrote:
> 
>> - I will make some tests between different ways to store the sign in 
>> the EBML lacing. Namely the way I put in the specs and the way Alexnoe 
>> suggested of putting a signed value directly in the EBML. I'll make 
>> some speed tests and see which one is better to read/write 
>> (performance should be best for reading)... If anyone wants to code 
>> that before myself (tonight or friday evening), feel free ;) 
> 
> 
> I've already implemented both versions, and it really does not matter. 
> Since you could use lookup tables
> for both cases for small sizes, the performance is equal as well. Leave 
> it as it is in the specs (large
> sizes rarely occur).

I'm not sure I understand your answer. Did you implement the 2 different 
ways of storing the size in EBML lacing ? Or the 2 different lacing 
methods ?

And what do you mean by "large sizes rarely occur" ? In the case of EBML 
lacing, this is differential, so only large variations matter.

And the lookup-table is overkill IMO, especially for VBR codex (where 
any size of frame can occur).



From alexander.noe at s2001.tu-chemnitz.de  Wed Oct 15 13:09:04 2003
From: alexander.noe at s2001.tu-chemnitz.de (=?ISO-8859-1?Q?Alexander_No=E9?=)
Date: Wed, 15 Oct 2003 13:09:04 +0200
Subject: [Matroska-devel] Added lacing
In-Reply-To: <3F8D29E9.7040807@free.fr>
References: <3F8BCE48.7020800@faireal.net>	<3F8BE13B.4010504@hrz.tu-chemnitz.de>	<20031014124215.GC1806@bunkus.org>	<3F8C0161.5050407@hrz.tu-chemnitz.de>	<20031014163645.GI1806@bunkus.org>	<3F8C26DC.4000704@hrz.tu-chemnitz.de>	<bmhcep$h0g$1@sea.gmane.org>	<20031014180010.GK1806@bunkus.org>	<3F8C5A3B.4010801@free.fr>	<3F8C5A90.2090203@hrz.tu-chemnitz.de>	<3F8D26C0.8030109@free.fr>
	<3F8D27EF.6090608@hrz.tu-chemnitz.de> <3F8D29E9.7040807@free.fr>
Message-ID: <3F8D2AD0.4090803@hrz.tu-chemnitz.de>

Steve Lhomme wrote:

> I'm not sure I understand your answer. Did you implement the 2 
> different ways of storing the size in EBML lacing ? 

I first tried my version of signed ebml ints (0xFF = -1) and then yours 
(0xFF = 63).

> And what do you mean by "large sizes rarely occur" ? 

Most of the size elemens you have to code will be small; small enough to 
fit in
2 bytes. So a small lookup table could catch most encode inquiries.

> And the lookup-table is overkill IMO, especially for VBR codex (where 
> any size of frame can occur). 

You could use a lookup table for example for 0-16383 and use normal 
encoding for
higher numbers. The, all methods, whetever you could possibly think of 
to store signed
ebml ints, would take the same amount of time.


Alex



From steve.lhomme at free.fr  Wed Oct 15 13:18:03 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Wed, 15 Oct 2003 13:18:03 +0200
Subject: [Matroska-devel] Added lacing
In-Reply-To: <3F8D2AD0.4090803@hrz.tu-chemnitz.de>
References: <3F8BCE48.7020800@faireal.net>	<3F8BE13B.4010504@hrz.tu-chemnitz.de>	<20031014124215.GC1806@bunkus.org>	<3F8C0161.5050407@hrz.tu-chemnitz.de>	<20031014163645.GI1806@bunkus.org>	<3F8C26DC.4000704@hrz.tu-chemnitz.de>	<bmhcep$h0g$1@sea.gmane.org>	<20031014180010.GK1806@bunkus.org>	<3F8C5A3B.4010801@free.fr>	<3F8C5A90.2090203@hrz.tu-chemnitz.de>	<3F8D26C0.8030109@free.fr>	<3F8D27EF.6090608@hrz.tu-chemnitz.de>
	<3F8D29E9.7040807@free.fr> <3F8D2AD0.4090803@hrz.tu-chemnitz.de>
Message-ID: <3F8D2CEB.2090303@free.fr>

Alexander No? wrote:
> Most of the size elemens you have to code will be small; small enough to 
> fit in
> 2 bytes. So a small lookup table could catch most encode inquiries.
> 
>> And the lookup-table is overkill IMO, especially for VBR codex (where 
>> any size of frame can occur). 
> 
> 
> You could use a lookup table for example for 0-16383 and use normal 
> encoding for
> higher numbers. The, all methods, whetever you could possibly think of 
> to store signed
> ebml ints, would take the same amount of time.

Mmm, would the lookup table need to be generated on a Block basis ? on a 
Cluster basis ? On a file basis ? It sounds like some compression to me. 
That's why I think it's overkill. And looking for a size in a table 
would take more time than having the size directly.



From alexander.noe at s2001.tu-chemnitz.de  Wed Oct 15 13:25:25 2003
From: alexander.noe at s2001.tu-chemnitz.de (=?ISO-8859-1?Q?Alexander_No=E9?=)
Date: Wed, 15 Oct 2003 13:25:25 +0200
Subject: [Matroska-devel] Added lacing
In-Reply-To: <3F8D2CEB.2090303@free.fr>
References: <3F8BCE48.7020800@faireal.net>	<3F8BE13B.4010504@hrz.tu-chemnitz.de>	<20031014124215.GC1806@bunkus.org>	<3F8C0161.5050407@hrz.tu-chemnitz.de>	<20031014163645.GI1806@bunkus.org>	<3F8C26DC.4000704@hrz.tu-chemnitz.de>	<bmhcep$h0g$1@sea.gmane.org>	<20031014180010.GK1806@bunkus.org>	<3F8C5A3B.4010801@free.fr>	<3F8C5A90.2090203@hrz.tu-chemnitz.de>	<3F8D26C0.8030109@free.fr>	<3F8D27EF.6090608@hrz.tu-chemnitz.de>	<3F8D29E9.7040807@free.fr>
	<3F8D2AD0.4090803@hrz.tu-chemnitz.de> <3F8D2CEB.2090303@free.fr>
Message-ID: <3F8D2EA5.6050208@hrz.tu-chemnitz.de>

Steve Lhomme wrote:

> Mmm, would the lookup table need to be generated on a Block basis ? on 
> a Cluster basis ? On a file basis ? It sounds like some compression to 
> me. That's why I think it's overkill. And looking for a size in a 
> table would take more time than having the size directly. 

No.... you worried about performance, not about filesize, so I'm not 
sure where this
interpretation comes from :oO  I was thinking about a lookup table for 
the conversion
between __int64 and ebml integers.



Alex



From steve.lhomme at free.fr  Wed Oct 15 13:37:19 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Wed, 15 Oct 2003 13:37:19 +0200
Subject: [Matroska-devel] Added lacing
In-Reply-To: <3F8D2EA5.6050208@hrz.tu-chemnitz.de>
References: <3F8BCE48.7020800@faireal.net>	<3F8BE13B.4010504@hrz.tu-chemnitz.de>	<20031014124215.GC1806@bunkus.org>	<3F8C0161.5050407@hrz.tu-chemnitz.de>	<20031014163645.GI1806@bunkus.org>	<3F8C26DC.4000704@hrz.tu-chemnitz.de>	<bmhcep$h0g$1@sea.gmane.org>	<20031014180010.GK1806@bunkus.org>	<3F8C5A3B.4010801@free.fr>	<3F8C5A90.2090203@hrz.tu-chemnitz.de>	<3F8D26C0.8030109@free.fr>	<3F8D27EF.6090608@hrz.tu-chemnitz.de>	<3F8D29E9.7040807@free.fr>	<3F8D2AD0.4090803@hrz.tu-chemnitz.de>
	<3F8D2CEB.2090303@free.fr> <3F8D2EA5.6050208@hrz.tu-chemnitz.de>
Message-ID: <3F8D316F.6050006@free.fr>

Alexander No? wrote:

> Steve Lhomme wrote:
> 
>> Mmm, would the lookup table need to be generated on a Block basis ? on 
>> a Cluster basis ? On a file basis ? It sounds like some compression to 
>> me. That's why I think it's overkill. And looking for a size in a 
>> table would take more time than having the size directly. 
> 
> 
> No.... you worried about performance, not about filesize, so I'm not 
> sure where this
> interpretation comes from :oO  I was thinking about a lookup table for 
> the conversion
> between __int64 and ebml integers.

OK, I get it now :)
Well, I still think it's overkill (and maybe not even faster).



From paul at msn.com  Wed Oct 15 14:40:32 2003
From: paul at msn.com (Pamel)
Date: Wed, 15 Oct 2003 07:40:32 -0500
Subject: [Matroska-devel] Re: Re: Re: Re: Adding matroska support to
	FFMPEGvia libmatroska/libebml, in C++ ?]
References: <3F8CB80A.6060003@matroska.org>
Message-ID: <bmjf7v$uj3$1@sea.gmane.org>

For the benefit of anyone reading the Matroska.Devel list:

> On Tue, Oct 14, 2003 at 10:02:44PM +0200, ChristianHJW wrote:
> > @ Michael, all : I promise this is my last email about this subject to
> > the list, at least for the time being.
> >
> > D Richard Felker III wrote:
> > >Hint 1: Matroska has large overhead.
> >
> > Richard, you always claim that, but i havent seen any proof of those yet
> > from your side. Show me another container with a similar flexibility
> > that can produce smaller file sizes and is extendable for the next 10
> > years. I bet you cant.
>
> I'll let you do it for me. Tell me how many bytes per frame in
> overhead you have, and we'll compare it to nut. I have no desire to go
> back and read your spec again (it was bad enough the first time). What
> I can guarantee is that if you tag fields in addition to storing the
> data, you will inherently use a lot more space, and that makes a big
> difference at low bitrate (and even a significant difference at
> moderate bitrates).

I think 10 bytes for I, 13 for P, and 16 for B.  This will also drop
significantly if the new lacing system is used.  It should also be noted that
the referencing system was changed during spec creation from single bit flags
for I,P,B to a system that allows referencing any frame and any number of frames
in a stream.  If the goal was absolute lowest overhead, the bit flags would have
been used.  But since flexibility and future-proofing was the goal, the newer
method was chosen. (AVI is 16 bytes per frame)

> > >Hint 2: Matroska is so overcomplicated and bloated that the specs
> > >might as well not be available.
> >
> > Well, there seem to be a couple of programmers now that dont have any
> > problems understanding those 'bloated' specs and make working code based
> > on it. It took Gabest 3 days to make his implementation, and he made it
> > from scratch, and even wrapped a DirectShow parser and muxer filter
>
> Good for him. Did he do it with no aid but the spec document, or did
> he ask you for help, and/or read your source? I find it hard to
> believe anyone could write a demuxer using your specs alone, and have
> it behave fully as you expect.

He did ask for clarification on a few points, and if I'm not mistaken, found
some errors in the specs.  Those errors were fixed.

> > around it. I would ask you to not judge about things from the view of
> > your obviously limited coding capabilities all the time. Just because
> > you think they are 'bloated' they dont have to be necessarily like that.
>
> I don't think my coding abilities are the topic in question here.

There are several topics here, and that is one of them.  Having a non-coder
declare the greatness of bit-efficiency of one format or another is a bit
dubious.  IE, you are better off hearing the opinions of Mosu, Cyrius, Alexnoe,
RobUx4, or MNiedermayer  rather than ChristianHJW or DRFelker.

> > >>opened to any codec, extensible as you wish, all based on an easy
> > >>principle (EBML). That's all that comes to my mind for now.
> > >ROTFL! Perhaps you should learn about this stuff from a performance
> > >software perspective rather than from a CS-professor perspective. EBML
> > >is inefficient and totally unnecessary.
> >
> > LOL ! Sorry, but i cant help laughing here. We had a couple of important
> > aspects to respect when making the specs, but for sure 'performance
> > perspectives' were not amongst them. Any small Pentium 3 can play
> > matroska files without having to invest more than 2% of his CPU power
> > for parsing of the file. And when i think about the CPU requirements for
> > upcoming compression formats like h.264, this argument just makes me
> > smile, sorry.
>
> Then you misunderstood. It has nothing to do with cpu time required to
> decode, but the mindset. The people who designed NUT are competent and
> experienced in writing performance code, and the efficiency-oriented
> mindset that goes along with it. You're designing from a horrible
> XML-inspired undergrad CS dork mindset.

This is such a strange and out of place comment that I have no idea how to
comment on it.  Perhaps just saying that his mommy was a foo-head would be
sufficient?

> Actually, bitstream parsing performance can be an issue too, but I
> doubt the cpu requirements of Matroska are very high.

They aren't.  But if overhead and bit-stream parsing aren't issues, I'm not sure
what is.  As I said before, flexibility and future-proofing were the main
concerns of the Matroska team.  The fact that overhead and bit-stream parsing
aren't issues is just a wonderful coincedence.  ;)

> > Richard, you think much to MPEG biased, in a very narrow angle of view.
> > We didnt make a container primarily for the existing compression formats
> > of today. If we had them in mind, we would have extended the good old
> > MPEG container a bit.
>
> This is nonsense. NUT can contain any audio and video content,
> regardless of codec, present or future. There are only a few very
> simple requirements to be able to claim this; AVI was just so poorly
> designed that it does not meet them.

Do you allow multiple references to any frame in the stream?

> BTW, I find this claim of yours amusing, since Matroska does not allow
> packet-resolution seeking in vorbis audio.

False.  Not really sure where he got this one, but that was one of the points of
Matroska, to put one frame/block.  If you lace frames, then you will only have 1
timecode for a few frames (100-500ms), so you could certainly seek to any frame,
but you wouldn't know the timecode of it. But you are not required to use
lacing, it just reduces overhead.

> > >>>In this case, I merely stated that quoting an official promotion site
> > >>>doesn't really prove the popularity of anything.
> > >>So what would be decisive for you ? Popularity of a crap format ? Of an
> > >>unpopular format that is technically good ? Matroska has a (fast)
> > >>growing popularity and is technically good (I won't claim it's the best,
> > >>but it's among the best ones). What else do you need ?
> > >
> > >It's technically bad. All it succeeds in doing is being better than
> > >the horrible avi and ogm containers. Rich
> >
> > Yes, its much better than AVI already, and the compression formats where
> > matroska will be excellent to use with are not even specified yet ;) ....
>
> This is bullshit. If you're going to make such a claim, back it up.
> However, I promise you that you can't.

I hate arguments like this.  What happens is that someone knocks something, and
when someone offers proof that what was said was wrong, they knock something
else.  There will never be an acknowledgement that they were wrong, and it will
never end.  It will just get more and more dumb.  Regardless, I will answer
this.

One codec idea was WARP.  The idea is to use a wavlet transform across a group
of frames (say 32) and store the encoded block for all 32 frames in a single I
frame.  Then you have some way to say, that the other 31 frames have to be
rendered using only data from that block and what their timecodes would be.  In
matroska you would just define a special element to indicate that.  You could
store the data in AVI, and use P-frames as dummy frames, but that would be far
less elegant. The Matroska method would not just work, but would be an excellent
way of doing it.


Pamel





From christian at matroska.org  Wed Oct 15 23:03:58 2003
From: christian at matroska.org (ChristianHJW)
Date: Wed, 15 Oct 2003 23:03:58 +0200
Subject: [Matroska-devel] Re: matroska USE flag
In-Reply-To: <200310151309.46343.luke-jr@gentoo.org>
References: <200310150459.39638.luke-jr@gentoo.org>
	<200310151022.34233.pauldv@gentoo.org>
	<200310151309.46343.luke-jr@gentoo.org>
Message-ID: <3F8DB63E.8010703@matroska.org>

Luke-Jr wrote:
>>>Matroska is a (relatively) new container format for things like video and
>>>audio. Programs (such as MPlayer) would use such a flag for depending on
>>>libmatroska and using --enable-matroska. Comments?
>>Is it stable, are there allready programs that use it?
> Not sure, as it just came to my attention when videos recently started using 
> it more often, but that would suggest it is stable...

Yes, matroska is stable, and both libmatroska and libebml are in Debian
stable already. It is supported in the following apps and players right
now :

- mplayer ( Linux, win32, MacOSX, BeOS )
- VLC ( Linux, win32, MacOSX )
- Gstreamer/lavrec ( Linux ), only HEAD, so its not in GNOME yet
- Mosu's MKVtoolnix/mkvmerge ( Linux, win32 )
- DirectShow splitter ( win32 )
- DirectShow muxer ( win32 )
- a mod of Virtualdub, called VirtualdubMod .. lol :) ( win32 )
- AVImux-GUI ( win32 )
- X-Box Mediapack

We are working on a C lib ( splitter/parser first ) for getting included
into FFMPEG also, but that may take a little while.


> Programs in Portage I am aware of that would use it are media-video/
> {vlc,mplayer}
> 
>>If the first answer is yes, and the second is more than 1 then I think we
>>can add the use flag.
> Luke-Jr
> Developer, Gentoo Linux

Great ! :) If you need assistance in any respect, please visit us on
irc.corecodec.com #matroska or drop a mail to
matroska-devel at lists.matroska.org

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



From christian at matroska.org  Thu Oct 16 08:52:02 2003
From: christian at matroska.org (ChristianHJW)
Date: Thu, 16 Oct 2003 08:52:02 +0200
Subject: [Matroska-devel] Re: Problem compiling mplayer under cygwin/mingw
	with Matroska support
In-Reply-To: <40968983887961.15526@send5.inner-21cn.com>
References: <40968983887961.15526@send5.inner-21cn.com>
Message-ID: <3F8E4012.6090801@matroska.org>

Hi,

we will try to put this on our homepage also, great work !!

Christian

Goodwu wrote:
> gcc -c -O4 -march=i486 -mcpu=i686 -pipe -ffast-math -fomit-frame-pointer -D_LARG
> EFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D__CYGWIN__ -I../loader  -I/usr/local/inclu
> de      -o demux_mkv.o demux_mkv.cpp
> In file included from /usr/include/c++/3.3.1/cctype:49,
>                  from /usr/include/c++/3.3.1/iosfwd:47,
>                  from /usr/include/c++/3.3.1/bits/stl_algobase.h:70,
>                  from /usr/include/c++/3.3.1/vector:67,
>                  from demux_mkv.cpp:29:
> /usr/include/ctype.h:39: error: parse error before `)' token
> In file included from /usr/include/errno.h:9,
>                  from /usr/include/c++/3.3.1/cerrno:48,
>                  from /usr/local/include/ebml/StdIOCallback.h:41,
>                  from demux_mkv.cpp:36:
> /usr/include/sys/errno.h:20: error: parse error before `)' token
> /usr/include/sys/errno.h:21: error: parse error before `)' token
> /usr/include/sys/errno.h:23: error: parse error before `)' token
> /usr/include/sys/errno.h:24: error: parse error before `)' token
> make: *** [demux_mkv.o] Error 1
> make: Leaving directory `/home/www/main-cygwin/libmpdemux'
> 
> How to fix:
> Move the following lines to the beginning of demux_mkv.cpp:
> 
> #include <vector>
> 
> #include <ebml/EbmlHead.h>
> #include <ebml/EbmlSubHead.h>
> #include <ebml/EbmlStream.h>
> #include <ebml/EbmlContexts.h>
> #include <ebml/EbmlVersion.h>
> #include <ebml/StdIOCallback.h>
> 
> #include <matroska/KaxAttachments.h>
> #include <matroska/KaxBlock.h>
> #include <matroska/KaxBlockData.h>
> #include <matroska/KaxChapters.h>
> #include <matroska/KaxCluster.h>
> #include <matroska/KaxClusterData.h>
> #include <matroska/KaxContexts.h>
> #include <matroska/KaxCues.h>
> #include <matroska/KaxCuesData.h>
> #include <matroska/KaxInfo.h>
> #include <matroska/KaxInfoData.h>
> #include <matroska/KaxSeekHead.h>
> #include <matroska/KaxSegment.h>
> #include <matroska/KaxTracks.h>
> #include <matroska/KaxTrackAudio.h>
> #include <matroska/KaxTrackVideo.h>
> #include <matroska/KaxTrackEntryData.h>
> #include <matroska/FileKax.h>




From spyder at matroska.org  Thu Oct 16 17:09:05 2003
From: spyder at matroska.org (spyder)
Date: Thu, 16 Oct 2003 10:09:05 -0500
Subject: [Matroska-devel] Rejig (for spyder)
In-Reply-To: <3F8D072C.3000103@free.fr>
References: <3F8D072C.3000103@free.fr>
Message-ID: <E1AA9k3-0006CH-00@goose.mail.pas.earthlink.net>

On Wednesday 15 October 2003 03:37, Steve Lhomme wrote:
> http://forum.doom9.org/showthread.php?s=&threadid=62849&perpage=20&pagenumb
>er=2
>
> Did you check that out ?
It's a transcoder...a quite complex one too since it doesn't fully decode, it 
only drops the bitrate of the streams by adjusting quants etc. I think.  My 
code now lets me get the timestamps off of GOP headers(really useless though) 
and it properly chops the streams into frames.  I can determine frame 
type(I,P,or B), and also framerate, resolution, and aspect ratio of the clip. 
 The problem I have hit now is how to create timecodes for the streams.  
MPEG2 video allows a mixture of 23.976 and 29.97fps video that creates big 
problems for calculating timestamps.  I can break the stream down further to 
determine if the frames are supposed to be 23.976 w/ playback-pulldown or if 
they are real 29.97fps.  Then the new problem is, will decoders care if they 
get 23.976fps timestamps for some frames and then 29.97fps timestamps for 
others.  I think that the decoders don't really need the timestamp info 
anyway as there is none in the raw ES.  I will look at the PS specs today and 
see if we could reuse the timestamps directly from it.  I think it doesn't 
stamp every frame necessarily though.

John


From paul at msn.com  Thu Oct 16 18:07:51 2003
From: paul at msn.com (Pamel)
Date: Thu, 16 Oct 2003 11:07:51 -0500
Subject: [Matroska-devel] Re: Rejig (for spyder)
References: <3F8D072C.3000103@free.fr>
	<E1AA9k3-0006CH-00@goose.mail.pas.earthlink.net>
Message-ID: <bmmfog$dq7$1@sea.gmane.org>

"spyder" <spyder at matroska.org> wrote...
>I think that the decoders don't really need the timestamp info
>anyway as there is none in the raw ES.  I will look at the PS specs today and
>see if we could reuse the timestamps directly from it.  I think it doesn't
>stamp every frame necessarily though.

We still need timecodes fore each frame in Matroska.


Pamel





From spyder at matroska.org  Thu Oct 16 18:33:40 2003
From: spyder at matroska.org (spyder)
Date: Thu, 16 Oct 2003 11:33:40 -0500
Subject: [Matroska-devel] Re: Rejig (for spyder)
In-Reply-To: <bmmfog$dq7$1@sea.gmane.org>
References: <3F8D072C.3000103@free.fr>
	<E1AA9k3-0006CH-00@goose.mail.pas.earthlink.net>
	<bmmfog$dq7$1@sea.gmane.org>
Message-ID: <E1AAB3w-0000oy-00@conure.mail.pas.earthlink.net>

On Thursday 16 October 2003 11:07, Pamel wrote:
> "spyder" <spyder at matroska.org> wrote...
>
> >I think that the decoders don't really need the timestamp info
> >anyway as there is none in the raw ES.  I will look at the PS specs today
> > and see if we could reuse the timestamps directly from it.  I think it
> > doesn't stamp every frame necessarily though.
>
> We still need timecodes fore each frame in Matroska.
>
I know...that's the problem ;)


From alexander.noe at s2001.tu-chemnitz.de  Thu Oct 16 18:35:27 2003
From: alexander.noe at s2001.tu-chemnitz.de (=?ISO-8859-1?Q?Alexander_No=E9?=)
Date: Thu, 16 Oct 2003 18:35:27 +0200
Subject: [Matroska-devel] Re: Rejig (for spyder)
In-Reply-To: <E1AAB3w-0000oy-00@conure.mail.pas.earthlink.net>
References: <3F8D072C.3000103@free.fr>	<E1AA9k3-0006CH-00@goose.mail.pas.earthlink.net>	<bmmfog$dq7$1@sea.gmane.org>
	<E1AAB3w-0000oy-00@conure.mail.pas.earthlink.net>
Message-ID: <3F8EC8CF.301@hrz.tu-chemnitz.de>

spyder wrote:

>On Thursday 16 October 2003 11:07, Pamel wrote:
>  
>
>>"spyder" <spyder at matroska.org> wrote...
>>
>>    
>>
>>>I think that the decoders don't really need the timestamp info
>>>anyway as there is none in the raw ES.  I will look at the PS specs today
>>>and see if we could reuse the timestamps directly from it.  I think it
>>>doesn't stamp every frame necessarily though.
>>>      
>>>
>>We still need timecodes fore each frame in Matroska.
>>
>>    
>>
>I know...that's the problem ;)
>
No. The real problem are people who copy /b mpeg files :)



Alex



From moritz at bunkus.org  Fri Oct 17 00:02:28 2003
From: moritz at bunkus.org (Moritz Bunkus)
Date: Fri, 17 Oct 2003 00:02:28 +0200
Subject: [Matroska-devel] DRAFT: new elements for compression/encryption
Message-ID: <20031016220228.GU1806@bunkus.org>

Hi.

Regarding the VobSub issue, here's the draft for some new
elements.

KaxTracks (old)
\+ KaxTrackEntry (old)
 \+ KaxContentEncoding (master, optional, multiple)
  \+ KaxContentEncodingType (UInt, mandatory, single, default 0)
   + KaxContentEncodingMethod (UInt, mandatory, single, default 0)
   + KaxContentEncodingScope (UInt, mandatory, single, default 0)
   + KaxContentEncodingSettings (binary, optional, single)

KaxContentEncoding: A master containing the aforementioned children. Can
be used multiple times. Order is important! The order in which the
multiple KaxContentEncoding elements are stored in the file is the same
order that the data manipulation has been done during encoding/muxing,
so a decoder/demuxer would have to reverse this order.

* KaxContentEncodingType: Tells the kind of modification
done. Predefined values:
0 - compression
1 - encryption
Default value is 0.

* KaxContentEncodingMethod: Tells what exactly was done with the
data. Depends on KaxContentEncodingType.

For compression:
0 - zlib (each frame's contents were compressed with the zlib library)
1 - bzlib (each frame's contents were compressed with the zlib library)

For encryption:
0 - ... (not yet specified; possible algorithms include DES, 3DES, AES,
ElGammal...)

Default value is 0.

* KaxContentEncodingScope: Tell whether the frame contents, the track's
private data or both have been modified in this way.
0 - only the frame contents
1 - only the track's private data
2 - both
Default value is 0.

* KaxContentEncodingSettings: Additional information for the method
used. Could be the ID of the key used in an asymmetric encryption method
(aka. public key cryptography).

Example: Let's say you have a codec that needs a big XML file for
initialization (around 200kb), but the frames it outputs are already
compressed heavily and would not gain from further compression. This
would be indicated by...

KaxTracks
\+ KaxTrackEntry
 \+ ...
  + KaxContentEncoding
  \+ (KaxContentEncodingType = 0, compression, default value)
   + (KaxContentEncodingMethod = 0, zlib compression, default value)
   + KaxContentEncodingScope = 1, only the private data

CodecIDs: I don't know how robux choses his IDs, but I propose the
following ones:

KaxContentEncoding: 0x6240, 2
KaxContentEncodingType: 0x5031, 2
KaxContentEncodingMethod: 0x5032, 2
KaxContentEncodingScope: 0x5033, 2
KaxContentEncodingSettings: 0x5034, 2

Please send comments/suggestions as soon as possible - I'd like to make
this permanent this weekend!

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


From moritz at bunkus.org  Fri Oct 17 00:08:20 2003
From: moritz at bunkus.org (Moritz Bunkus)
Date: Fri, 17 Oct 2003 00:08:20 +0200
Subject: [Matroska-devel] DRAFT: new elements for compression/encryption
In-Reply-To: <20031016220228.GU1806@bunkus.org>
References: <20031016220228.GU1806@bunkus.org>
Message-ID: <20031016220820.GW1806@bunkus.org>

Hi.

> For compression:
> 0 - zlib (each frame's contents were compressed with the zlib library)
> 1 - bzlib (each frame's contents were compressed with the zlib
> library)

The mistake and how it should be corrected is obvious ;)


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


From moritz at bunkus.org  Fri Oct 17 00:19:16 2003
From: moritz at bunkus.org (Moritz Bunkus)
Date: Fri, 17 Oct 2003 00:19:16 +0200
Subject: [Matroska-devel] DRAFT: new elements for compression/encryption
In-Reply-To: <20031016220228.GU1806@bunkus.org>
References: <20031016220228.GU1806@bunkus.org>
Message-ID: <20031016221916.GX1806@bunkus.org>

Hi.

> CodecIDs: I don't know how robux choses his IDs, but I propose the
> following ones:

LOL. Not CodecIDs but EbmlIds ;)

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


From paul at msn.com  Fri Oct 17 01:18:36 2003
From: paul at msn.com (Pamel)
Date: Thu, 16 Oct 2003 18:18:36 -0500
Subject: [Matroska-devel] Re: DRAFT: new elements for compression/encryption
References: <20031016220228.GU1806@bunkus.org>
Message-ID: <bmn904$guf$1@sea.gmane.org>

"Moritz Bunkus" <moritz at bunkus.org> wrote...
> KaxContentEncoding: A master containing the aforementioned children. Can
> be used multiple times. Order is important! The order in which the
> multiple KaxContentEncoding elements are stored in the file is the same
> order that the data manipulation has been done during encoding/muxing,
> so a decoder/demuxer would have to reverse this order.

Bad!  Order sensetive data is a nono in EBML.  In theory you should be able to
reorganize randomized elements into a 'normal' file.  An easy way to do this
would be to add another element for priority.   KaxContentEncodingPriority
maybe?  The first KaxContentEncoding that you make will have a priority of 0,
next would be 1, then 2, etc.  Then when go to playback, you just start at the
highest priority.

> * KaxContentEncodingType: Tells the kind of modification
> done. Predefined values:
> 0 - compression
> 1 - encryption
> Default value is 0.

Maybe instead use:
0 - none
1 - compression
2 - encryption
Default value is 0.

> For compression:
> 0 - zlib (each frame's contents were compressed with the zlib library)
> 1 - bzlib (each frame's contents were compressed with the zlib library)
>
> For encryption:
> 0 - ... (not yet specified; possible algorithms include DES, 3DES, AES,
> ElGammal...)
>
> Default value is 0.

Again, wouldn't 0 be 'none' ?

> * KaxContentEncodingScope: Tell whether the frame contents, the track's
> private data or both have been modified in this way.
> 0 - only the frame contents
> 1 - only the track's private data
> 2 - both
> Default value is 0.

I like that, its clever.  I can imagine that people would just start using one
all of the time, but this saves us the trouble of deciding which that would be.

> * KaxContentEncodingSettings: Additional information for the method
> used. Could be the ID of the key used in an asymmetric encryption method
> (aka. public key cryptography).

Some thought will need to be put into this, but not right now, as long as the
element is defined.  Before defining exactly how this element is defined you
should probably talk to someone experienced in cryptography and DRM.

> Please send comments/suggestions as soon as possible - I'd like to make
> this permanent this weekend!

It looks pretty solid to me with the exception of the 'order sensitive
elements'.


Pamel





From moritz at bunkus.org  Fri Oct 17 09:50:42 2003
From: moritz at bunkus.org (Moritz Bunkus)
Date: Fri, 17 Oct 2003 09:50:42 +0200
Subject: [Matroska-devel] DRAFT: 2nd try at the new elements for
	compression/encryption
Message-ID: <20031017075042.GY1806@bunkus.org>

Hi.

First of all: thanks for your input, especially Pamel. It was good I've
written the last mail, because it allowed me to think about it clearly
and see the deficiencies.

Here's my second attempt.

Preface: The last one had two drawbacks: relying on the order (minor)
and being totally insufficient for encryption (I usually know a lot
about encryption and was clearly too preoccupied when I wrote my last
mail).

So here I go again.

KaxTracks (old)
\+ KaxTrackEntry (old)
 \+ KaxContentEncoding (master, optional, multiple)
  \+ KaxContentEncodingOrder (UInt, mandatory, unique, single,
     default 0)
   + KaxContentEncodingScope (UInt, mandatory, single, default 0)
   + KaxContentEncodingType (UInt, mandatory, single, default 0)
   + KaxContentCompression (master, optional, single)
   \+ KaxContentCompressionAlgo (UInt, mandatory, single, default 0)
    + KaxContentCompressionSettings (binary, optional, single)
   \+ KaxContentEncryption (master, optional, single)
    + KaxContentEncryptionAlgo (UInt, optional, single)
    + KaxContentEncryptionKeyID (binary, optional, single)
    + KaxContentSignatureAlgo (UInt, optional, single)
    + KaxContentSignatureHashAlgo (UInt, optional, single)
    + KaxContentSignatureKeyID (binary, optional, single)
    + KaxContentSignature (binary, optional, single)

* KaxContentEncoding: A master containing the aforementioned
  children. Can be used multiple times. Order is NOT important :)

* KaxContentEncodingOrder: Tells when this modification was used during
  encoding/muxing. Starting with 0 counting upwards. The decoder/demuxer
  has to start with the highest order number it finds and work its way
  down.
  Default value is 0.
  This value has to be unique over all KaxContentEncodingOrder elements
  in the segment.

* KaxContentEncodingScope: Tell whether the frame contents, the track's
  private data or both have been modified in this way.
  0 - only the frame contents,
  1 - only the track's private data,
  2 - both
  Default value is 0.

* KaxContentEncodingType: Tells the kind of modification
  done. Predefined values:
  0 - compression
  1 - encryption
  Default value is 0.

Depending on the value of KaxContentEncodingType one of the following
masters is used.

* KaxContentCompression: Contains settings for compression.

* KaxContentCompressionAlgo: Names the compression algorithm
  used. Predefined values:
  0 - zlib (each frame's contents were compressed with the zlib library)
  1 - bzlib (each frame's contents were compressed with the bzlib
      library)
  Default is 0. 0 is NOT none - if no compression is used then there
  shouldn't be a KaxContentEncoding element present in the first place.

* KaxContentCompressionSettings: Settings that might be needed by the
  decompressor.

* KaxContentEncryption: Contains settings for encryption and
  signatures.

* KaxContentEncryptionAlgo: Encryption algorithm used. Predefined
  values:
  0 - none
  1 - DES
  2 - 3DES
  3 - Twofish
  4 - Blowfish
  5 - AES
  ....
  Default value is 0.
  Here 0 IS 'none' because you might want to sign the contents but not
  encrypt them.

* KaxContentEncryptionKeyID: For public key algorithms this is the ID of
  the public key used to encrypt the data with. Only the owner of the
  corresponding private key will be able to decrypt this data.

* KaxContentSignatureAlgo: Signature algorithm used, if any. Predefined
  values:
  0 - none
  1 - RSA
  ....
  Default value is 0.
  Here 0 IS 'none' because you might want to encrypt the contents but
  not sign them.

* KaxContentSignatureHashAlgo: The hash algorithm used for the
  signature. Predefined values:
  0 - none
  1 - SHA1-160
  2 - MD5
  ....
  Default value is 0, although I don't know any signature algorithm that
  does not use a hash function. But let's stay flexible.

* KaxContentSignatureKeyID: The ID of the private key used to make this
  signature. All folks with the corresponding public key can check for
  its authenticity.
  Must be present if KaxContentSignatureAlgo is not 0.

* KaxContentSignature: The signature itself.
  Must be present if KaxContentSignatureAlgo is not 0.

EbmlIds: I don't know how robux choses his IDs, but I propose the
following ones:

 \+ KaxContentEncoding 0x6240, 2
  \+ KaxContentEncodingOrder 0x5031, 2
   + KaxContentEncodingScope 0x5032, 2
   + KaxContentEncodingType 0x5033, 2
   + KaxContentCompression 0x5034, 2
   \+ KaxContentCompressionAlgo 0x4254, 2
    + KaxContentCompressionSettings 0x4255, 2
   \+ KaxContentEncryption 0x5035, 2
    + KaxContentEncryptionAlgo 0x47e1, 2
    + KaxContentEncryptionKeyID 0x47e2, 2
    + KaxContentSignatureAlgo 0x47e3, 2
    + KaxContentSignatureHashAlgo 0x47e4, 2
    + KaxContentSignatureKeyID 0x47e5, 2
    + KaxContentSignature 0x47e6, 2

Please send comments/suggestions as soon as possible - I'd like to make
this permanent this weekend!

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


From steve.lhomme at free.fr  Fri Oct 17 09:54:49 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Fri, 17 Oct 2003 09:54:49 +0200
Subject: [Matroska-devel] DRAFT: new elements for compression/encryption
In-Reply-To: <20031016220228.GU1806@bunkus.org>
References: <20031016220228.GU1806@bunkus.org>
Message-ID: <3F8FA049.3040405@free.fr>

Moritz Bunkus wrote:
> Hi.
> 
> Regarding the VobSub issue, here's the draft for some new
> elements.
> 
> KaxTracks (old)
> \+ KaxTrackEntry (old)
>  \+ KaxContentEncoding (master, optional, multiple)
>   \+ KaxContentEncodingType (UInt, mandatory, single, default 0)
>    + KaxContentEncodingMethod (UInt, mandatory, single, default 0)
>    + KaxContentEncodingScope (UInt, mandatory, single, default 0)
>    + KaxContentEncodingSettings (binary, optional, single)
> 
> KaxContentEncoding: A master containing the aforementioned children. Can
> be used multiple times. Order is important! The order in which the
> multiple KaxContentEncoding elements are stored in the file is the same
> order that the data manipulation has been done during encoding/muxing,
> so a decoder/demuxer would have to reverse this order.

It all sounds good to me, except for the order thing (even though the 
Checksum already assume you keep elements in order).
Why not just adding KaxContentEncodingOrder under KaxContentEncoding ?



From steve.lhomme at free.fr  Fri Oct 17 09:55:50 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Fri, 17 Oct 2003 09:55:50 +0200
Subject: [Matroska-devel] DRAFT: new elements for compression/encryption
In-Reply-To: <20031016221916.GX1806@bunkus.org>
References: <20031016220228.GU1806@bunkus.org>
	<20031016221916.GX1806@bunkus.org>
Message-ID: <3F8FA086.3060804@free.fr>

Moritz Bunkus wrote:

> Hi.
> 
> 
>>CodecIDs: I don't know how robux choses his IDs, but I propose the
>>following ones:
> 
> 
> LOL. Not CodecIDs but EbmlIds ;)

BTW, did you check if they are not in use ? If so they are OK with me.



From moritz at bunkus.org  Fri Oct 17 09:57:41 2003
From: moritz at bunkus.org (Moritz Bunkus)
Date: Fri, 17 Oct 2003 09:57:41 +0200
Subject: [Matroska-devel] DRAFT: new elements for compression/encryption
In-Reply-To: <3F8FA086.3060804@free.fr>
References: <20031016220228.GU1806@bunkus.org>
	<20031016221916.GX1806@bunkus.org> <3F8FA086.3060804@free.fr>
Message-ID: <20031017075741.GZ1806@bunkus.org>

Hi.

> BTW, did you check if they are not in use ? If so they are OK with me.

Yes, I grepped for them in libmatroska/src :)

Anyway, have a look at the mail I just wrote - those elements should be
better.

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


From steve.lhomme at free.fr  Fri Oct 17 10:00:27 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Fri, 17 Oct 2003 10:00:27 +0200
Subject: [Matroska-devel] Re: DRAFT: new elements for
	compression/encryption
In-Reply-To: <bmn904$guf$1@sea.gmane.org>
References: <20031016220228.GU1806@bunkus.org> <bmn904$guf$1@sea.gmane.org>
Message-ID: <3F8FA19B.6010704@free.fr>

Pamel wrote:

>>* KaxContentEncodingScope: Tell whether the frame contents, the track's
>>private data or both have been modified in this way.
>>0 - only the frame contents
>>1 - only the track's private data
>>2 - both
>>Default value is 0.
> 
> 
> I like that, its clever.  I can imagine that people would just start using one
> all of the time, but this saves us the trouble of deciding which that would be.

How about the "only certain frames" ? That would also encryption of only 
some parts of a movie or 1 frame every 3, so that the user still need to 
get a way do decrypt it and still be somehow playable. It would also 
save some encryption time on some systems.
I propose a bitfield for these values :
bit 0 : track's private data
bit 1 : frames marked as such (we need to use something in the frame, 
probably a bit in the frame header)
bit 2 : all frames

I was thinking about adding a Bitfield EBML type someday. Maybe we could 
do it now.




From steve.lhomme at free.fr  Fri Oct 17 10:29:51 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Fri, 17 Oct 2003 10:29:51 +0200
Subject: [Matroska-devel] Re: DRAFT: new elements for
	compression/encryption
In-Reply-To: <bmn904$guf$1@sea.gmane.org>
References: <20031016220228.GU1806@bunkus.org> <bmn904$guf$1@sea.gmane.org>
Message-ID: <3F8FA87F.9090106@free.fr>

Pamel wrote:

>>* KaxContentEncodingScope: Tell whether the frame contents, the track's
>>private data or both have been modified in this way.
>>0 - only the frame contents
>>1 - only the track's private data
>>2 - both
>>Default value is 0.
> 
> 
> I like that, its clever.  I can imagine that people would just start using one
> all of the time, but this saves us the trouble of deciding which that would be.

How about the "only certain frames" ? That would also encryption of only 
some parts of a movie or 1 frame every 3, so that the user still need to 
get a way do decrypt it and still be somehow playable. It would also 
save some encryption time on some systems.
I propose a bitfield for these values :
bit 0 : track's private data
bit 1 : frames marked as such (we need to use something in the frame, 
probably a bit in the frame header)
bit 2 : all frames

I was thinking about adding a Bitfield EBML type someday. Maybe we could 
do it now.




From rbultje at ronald.bitfreak.net  Fri Oct 17 10:47:00 2003
From: rbultje at ronald.bitfreak.net (Ronald Bultje)
Date: Fri, 17 Oct 2003 10:47:00 +0200
Subject: [Matroska-devel] Re: DRAFT: new elements for
	compression/encryption
In-Reply-To: <3F8FA19B.6010704@free.fr>
References: <20031016220228.GU1806@bunkus.org> <bmn904$guf$1@sea.gmane.org>
	<3F8FA19B.6010704@free.fr>
Message-ID: <1066380383.28224.345.camel@shrek.bitfreak.net>

On Fri, 2003-10-17 at 10:00, Steve Lhomme wrote:
> I was thinking about adding a Bitfield EBML type someday. Maybe we could 
> do it now.

How is a bitfield different from a uint?

Ronald

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



From steve.lhomme at free.fr  Fri Oct 17 10:56:03 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Fri, 17 Oct 2003 10:56:03 +0200
Subject: [Matroska-devel] Re: DRAFT: new elements
	for	compression/encryption
In-Reply-To: <1066380383.28224.345.camel@shrek.bitfreak.net>
References: <20031016220228.GU1806@bunkus.org>
	<bmn904$guf$1@sea.gmane.org>	<3F8FA19B.6010704@free.fr>
	<1066380383.28224.345.camel@shrek.bitfreak.net>
Message-ID: <3F8FAEA3.9040406@free.fr>

Ronald Bultje wrote:

> On Fri, 2003-10-17 at 10:00, Steve Lhomme wrote:
> 
>>I was thinking about adding a Bitfield EBML type someday. Maybe we could 
>>do it now.
> 
> 
> How is a bitfield different from a uint?

The same difference between a uint and an sint : the interpretation.

An application may care about one specific bit in the field and not the 
rest. While with an int you have the value that you have to interpret 
completely.

In other words, a bitfield contains many different "data", unlike an 
uint/sint which contains linear values.



From rbultje at ronald.bitfreak.net  Fri Oct 17 11:30:55 2003
From: rbultje at ronald.bitfreak.net (Ronald Bultje)
Date: Fri, 17 Oct 2003 11:30:55 +0200
Subject: [Matroska-devel] Re: DRAFT: new elements
	for	compression/encryption
In-Reply-To: <3F8FAEA3.9040406@free.fr>
References: <20031016220228.GU1806@bunkus.org> <bmn904$guf$1@sea.gmane.org>
	<3F8FA19B.6010704@free.fr>
	<1066380383.28224.345.camel@shrek.bitfreak.net>
	<3F8FAEA3.9040406@free.fr>
Message-ID: <1066383054.4270.353.camel@shrek.bitfreak.net>

On Fri, 2003-10-17 at 10:56, Steve Lhomme wrote:
> In other words, a bitfield contains many different "data", unlike an 
> uint/sint which contains linear values.

No, differently: how, in code, differs an EbmlUint from a EbmlBitfield?
A sint/uint differ in binary. A uint/bitfield will not differ in binary,
and their interpretation will not differ either. At best, you would
provide a macro set like set_bit() and get_bit(). Apart from that,
they're exactly the same.

Or maybe I'm thinking too much in terms of C. In my C lib, EbmlDate and
EbmlSint or EbmlAscii and EbmlUTF8 are aliases of each other. They're
the same.

Ronald

Ronald

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



From steve.lhomme at free.fr  Fri Oct 17 11:36:08 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Fri, 17 Oct 2003 11:36:08 +0200
Subject: [Matroska-devel] Re: DRAFT: new
	elements	for	compression/encryption
In-Reply-To: <1066383054.4270.353.camel@shrek.bitfreak.net>
References: <20031016220228.GU1806@bunkus.org>
	<bmn904$guf$1@sea.gmane.org>	<3F8FA19B.6010704@free.fr>	<1066380383.28224.345.camel@shrek.bitfreak.net>	<3F8FAEA3.9040406@free.fr>
	<1066383054.4270.353.camel@shrek.bitfreak.net>
Message-ID: <3F8FB808.6000608@free.fr>

Ronald Bultje wrote:

> On Fri, 2003-10-17 at 10:56, Steve Lhomme wrote:
> 
>>In other words, a bitfield contains many different "data", unlike an 
>>uint/sint which contains linear values.
> 
> 
> No, differently: how, in code, differs an EbmlUint from a EbmlBitfield?
> A sint/uint differ in binary. A uint/bitfield will not differ in binary,
> and their interpretation will not differ either. At best, you would
> provide a macro set like set_bit() and get_bit(). Apart from that,
> they're exactly the same.
> 
> Or maybe I'm thinking too much in terms of C. In my C lib, EbmlDate and
> EbmlSint or EbmlAscii and EbmlUTF8 are aliases of each other. They're
> the same.

OK, so in your code, the bitfield handling would just be a new alias. 
But that doesn't mean EbmlUTF8 is the same as EbmlDate :)

The difference between an EbmlUint and EbmlBitfield would be the way to 
retrieve/store data from it. As, so far in libebml, the reader/writer 
doesn't need to care of how data are stored in the field, it should have 
no way/need of knowing the position of some bits in the bitfield. It 
should just require the name of a bit section (one or more bits) and the 
number of bits to set (with values in local endianess).



From suiryc at yahoo.com  Fri Oct 17 16:28:41 2003
From: suiryc at yahoo.com (Cyrius)
Date: Fri, 17 Oct 2003 07:28:41 -0700 (PDT)
Subject: [Matroska-devel] Element order in EBML/libebml
In-Reply-To: <20031017075042.GY1806@bunkus.org>
Message-ID: <20031017142841.42021.qmail@web12905.mail.yahoo.com>

Mosu:
> Regarding the VobSub issue, here's the draft for
some new elements.
>
> KaxTracks (old)
> \+ KaxTrackEntry (old)
>  \+ KaxContentEncoding (master, optional, multiple)
>   \+ KaxContentEncodingType (UInt, mandatory,
single, default 0)
>    + KaxContentEncodingMethod (UInt, mandatory,
single, default 0)
>    + KaxContentEncodingScope (UInt, mandatory,
single, default 0)
>    + KaxContentEncodingSettings (binary, optional,
single)
>
> * KaxContentEncoding: A master containing the
aforementioned
> children. Can be used multiple times. Order is
important!
> The order in which the multiple KaxContentEncoding
elements are
> stored in the file is the same order that the data
manipulation
> has been done during encoding/muxing, so a
decoder/demuxer would
> have to reverse this order.

Pamel:
> Bad!  Order sensetive data is a nono in EBML.

robUx4:
> It all sounds good to me, except for the order thing
(even though
> the Checksum already assume you keep elements in
order).
> Why not just adding KaxContentEncodingOrder under
> KaxContentEncoding ?

Mosu:
> Here's my second attempt.
>
> Preface: The last one had two drawbacks: relying on
the order
> (minor) and being totally insufficient for
encryption (I usually
> know a lot about encryption and was clearly too
preoccupied when I
> wrote my last mail).
>
> So here I go again.
>
> KaxTracks (old)
> \+ KaxTrackEntry (old)
>  \+ KaxContentEncoding (master, optional, multiple)
>   \+ KaxContentEncodingOrder (UInt, mandatory,
unique, single
>                                                   ,
default 0)
>    + KaxContentEncodingScope (UInt, mandatory,
single, default 0)
>    + KaxContentEncodingType (UInt, mandatory,
single, default 0)
>    + KaxContentCompression (master, optional,
single)
>    \+ KaxContentCompressionAlgo (UInt, mandatory,
single, default 0)
>     + KaxContentCompressionSettings (binary,
optional, single)
>    \+ KaxContentEncryption (master, optional,
single)
>     + KaxContentEncryptionAlgo (UInt, optional,
single)
>     + KaxContentEncryptionKeyID (binary, optional,
single)
>     + KaxContentSignatureAlgo (UInt, optional,
single)
>     + KaxContentSignatureHashAlgo (UInt, optional,
single)
>     + KaxContentSignatureKeyID (binary, optional,
single)
>     + KaxContentSignature (binary, optional, single)
>
> * KaxContentEncoding: A master containing the
aforementioned
>   children. Can be used multiple times. Order is NOT
important :)



Now someone will have to cut the crap !!
Either there is some incredible nonsense somewhere,
either I'm completly stupid! (that can be possible
too)

Here are a few things about how libebml and
libmatroska works (as far as I could understand) :
For master elements there are children (subelements)
that have to be present (mandatory elements) and some
that don't have to. Some elements can also be present
multiple times (that's the case of
KaxContentEncoding).
Now to enforce mandatory elements the current
implementation of libebml automatically create the
mandatory children when you create an element (e.g.
when you create a KaxTrackEncoding, libebml would
automatically create a KaxContentEncodingOrder, a
KaxContentEncodingScope, ... and add them of the newly
created KaxTrackEncoding element). Then when you need
to set the data of those mandatory subelements the
library would give you the children that has been
created in advance.
If you need to create a new children that isn't
mandatory (or for an element that can be found
multiple times) the library will create it for you
(there are some functions to do this, but one could
also create it and add it to the master) and add it in
the list of the children (IIRC libebml uses STL
containers where elements have an order here).

In this manner the order of the mandatory children
KaxContentEncodingOrder, KaxContentEncodingScope, ...
isn't respected by libebml. This means that depending
on the order in which those elements have been
declared in the Context of KaxContentEncoding, libebml
will always store them in a certain order (that may
then be different from the order in which we filled
their data).
But, provided what I wrote earlier is true, as far as
same elements are concerned (e.g. the
KaxContentEncoding elements as children of the
KaxTrackEntry element) their order is (and have to be
- see later) respected. Indeed if I add a
KaxContentEncoding to a KaxTrackEntry, then another
one, ..., their order should remain intact (provided I
was right saying that ordered STL containers are used
in libebml). The same would apply if the
KaxContentEncoding was a mandatory element that could
be present multiple times: the first occurence
(mandatory) of the element would have been created
beforehand and the other ones would have been added
after (thus still respecting the order).


If all I said here is crap then we (people relying on
libebml and libmatroska) have a serious problem. If I
said bullshit till now, this would mean that order
really can't be guaranted by libebml. What does this
imply ? Simple :
First, it's true that a KaxContentEncodingOrder
element would be necessary in KaxContentEncoding, in
order to know in which order we need to treat the
elements.
_But_ that would mean that we need such an ordering
elements for _ALL_ elements that are multiple in a
given context. So where would this be needed ? e.g. in
the KaxCluster (yes, even if most of us create them
and write them one by one, nothing tell that other or
future apps don't create a KaxSegment and multiple
KaxCluster in memory ... even so would you add in the
specs that people shouldn't hold a KaxSegment with
KaxCluster children in memory ? that would be
nonsense), but also in each KaxBlock (I let you
imagine the amount of overhead that would represent).
Why in each KaxBlock ? If the order can't be guaranted
then we need to sort the KaxBlock elements when we
read a whole KaxCluster in memory.
Some of you will say "Simple, just order them thanks
to the timecodes". Yes .. but no, what do you do with
native MPEG4 streams where frames are stored
out-of-order ? Someone knowing the MPEG4 specs would
say "Just take into account the type of the frame -
IBP - and their timecode and you can sort them too".
True, but then what do you do with (future) codecs
that would store the frame in yet another order or use
other kind of frames ? You would say "Oh sorry, I
don't know in which order the frames are stored, I
can't reorder them, you will have to wait for an
upgrade of the program to take into account this new
codec" ? If so you can already remove the lines in all
the docs about Matroska mentioning that this container
is great because applications can edit Matroska files
without having to know what is inside.

This would also mean that up to now we (devels using
libebml and libmatroska) have been writing
unpredictible data. Indeed most of us create a
KaxCluster in memory and add KaxBlock elements when
needed, and finally write the KaxCluster in the file
when we consider the Cluster full. Generally we add
the KaxBlock elements in a certain order (trying to
achieve a good stream - audio/video/text -
interleaving so that data stay in sync even at the
container level). So the order in which we added the
data is important.
Not to mention, when we read back the data from a
Matroska file we assume we get the KaxBlock elements
in the correct order.

Same goes for MPEG4. KaxBlock elements have been added
in a specific order (the coding order). If this order
can't be guaranted, then you can also remove the lines
telling that Matroska can safely store native MPEG4
streams.


Last but not least. Let's consider why a new ordering
element (KaxContentEncoding) has been asked :
> Bad!  Order sensitive data is a nono in EBML.
I don't think that's really true. Ebml by itself
introduce order (when you read an EBML stream,
elements have been written in a certain order).
The actual reason would be
"Bad! Order sensitive data is a nono in libebml."
Yeah that's true. As I said earlier in the current
libebml order of _certain_ elements (the mandatory
ones) isn't guaranted to be the one in which you wrote
them.
So that would mean that Matroska specs would have to
be changed because of a _possible_ implementation of
those specs ? (keep in mind that alexnoe wrote hiw own
library, and it seems that he doesn't have this
element order problem - Gabest too wrote his own
implementation, but I don't recall if he replaced
libmatroska only or both libs). IMHO that would be a
nonsense.
Up to now I only saw implementations being changed to
follow the specs, not the contrary.


That's my point of view. Now I may also be completly
stupid and missed something else in EBML/libebml
(that's possible). If so I guess I will just shut up
and won't write anything else before a long time :P
(as if I had written often till now ;))


Best regards
Cyrius

__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com


From paul at msn.com  Fri Oct 17 16:58:50 2003
From: paul at msn.com (Pamel)
Date: Fri, 17 Oct 2003 09:58:50 -0500
Subject: [Matroska-devel] Re: Element order in EBML/libebml
References: <20031017075042.GY1806@bunkus.org>
	<20031017142841.42021.qmail@web12905.mail.yahoo.com>
Message-ID: <bmp02s$qjp$1@sea.gmane.org>

"Cyrius" <suiryc at yahoo.com> wrote...
> Pamel:
> > Bad!  Order sensetive data is a nono in EBML.

Sorry, I meant to say, Matroska.  EBML doesn't have anything inherently that
cares in the specs.

> Some of you will say "Simple, just order them thanks
> to the timecodes". Yes .. but no, what do you do with
> native MPEG4 streams where frames are stored
> out-of-order ? Someone knowing the MPEG4 specs would
> say "Just take into account the type of the frame -
> IBP - and their timecode and you can sort them too".
> True, but then what do you do with (future) codecs
> that would store the frame in yet another order or use
> other kind of frames ? You would say "Oh sorry, I
> don't know in which order the frames are stored, I
> can't reorder them, you will have to wait for an
> upgrade of the program to take into account this new
> codec" ? If so you can already remove the lines in all
> the docs about Matroska mentioning that this container
> is great because applications can edit Matroska files
> without having to know what is inside.

You could still edit them because you would be able to tell what frames were
still needed by references.  Reorganizing the frames for a specific codec type
should be fine, as long as you are ABLE to.

> Last but not least. Let's consider why a new ordering
> element (KaxContentEncoding) has been asked :
> > Bad!  Order sensitive data is a nono in EBML.
> I don't think that's really true. Ebml by itself
> introduce order (when you read an EBML stream,
> elements have been written in a certain order).

Right, its was my booboo.


Pamel





From steve.lhomme at free.fr  Fri Oct 17 17:20:06 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Fri, 17 Oct 2003 17:20:06 +0200
Subject: [Matroska-devel] Element order in EBML/libebml
In-Reply-To: <20031017142841.42021.qmail@web12905.mail.yahoo.com>
References: <20031017142841.42021.qmail@web12905.mail.yahoo.com>
Message-ID: <3F9008A6.1030105@free.fr>

Cyrius wrote:

...lots of things. And I won't comment everything.
But EBML, in general, does induce an order for elements. You could swap 
some and the meaning of the file has to be the same.

The only problem is when Chesksum is used. Once it's set, you can't 
change the order, unless you compute the checksum again. So that's still 
possible.

For the rest, there is no case where the order of elements matters. Even 
for blocks not in coding+display order. I think DirectShow is capable of 
being feed with timecodes in no particular order (as long as it's not in 
the past of what has been rendered)... But that's a problem for hardware 
players that can't reorder frames easily (BTW, it has always been said 
that a Cluster should be held full in memory)...

For elements that DO need an order, it has to be written somwehere. So 
far, for Blocks and now for Encoding, it is an EBML element. (timecode, 
coding order)



From suiryc at yahoo.com  Fri Oct 17 17:23:02 2003
From: suiryc at yahoo.com (Cyrius)
Date: Fri, 17 Oct 2003 08:23:02 -0700 (PDT)
Subject: [Matroska-devel] Re: Element order in EBML/libebml
In-Reply-To: <bmp02s$qjp$1@sea.gmane.org>
Message-ID: <20031017152302.24597.qmail@web12902.mail.yahoo.com>

--- Pamel <paul at msn.com> wrote:
> You could still edit them because you would be able
> to tell what frames were
> still needed by references.  Reorganizing the frames
> for a specific codec type
> should be fine, as long as you are ABLE to.
Yeah true I forgot the references. This indeed allow
to edit the file without having to know about the
codec ^^; (my error)
However even if you are able to know which frames you
have to keep, that doesn't help with codecs that need
to decode frames in a certain order (nowadays I think
that means all the codecs ;)). So in this case if
there is a problem with ordering then applications
would be unable to serve data in the correct order to
the codec, meaning that till now we were really lucky
that Matroska files play correctly :P

> > Last but not least. Let's consider why a new
> ordering
> > element (KaxContentEncoding) has been asked :
> > > Bad!  Order sensitive data is a nono in EBML.
> > I don't think that's really true. Ebml by itself
> > introduce order (when you read an EBML stream,
> > elements have been written in a certain order).
> 
> Right, its was my booboo.
:) yup, anyway the problem I talked about mainly
concerns libebml and the Matroska specs, not EBML by itself.

__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com


From suiryc at yahoo.com  Fri Oct 17 17:43:14 2003
From: suiryc at yahoo.com (Cyrius)
Date: Fri, 17 Oct 2003 08:43:14 -0700 (PDT)
Subject: [Matroska-devel] Element order in EBML/libebml
In-Reply-To: <3F9008A6.1030105@free.fr>
Message-ID: <20031017154314.31434.qmail@web12908.mail.yahoo.com>

--- Steve Lhomme <steve.lhomme at free.fr> wrote:
> But EBML, in general, does induce an order for
> elements. You could swap 
> some and the meaning of the file has to be the same.
For some elements that is indeed possible (e.g. I
don't care if the reference of a frame is written
before or after the frame by itself, both ordering is
handled), but order matters at some point.

> For the rest, there is no case where the order of
> elements matters. Even 
> for blocks not in coding+display order. I think
> DirectShow is capable of 
> being feed with timecodes in no particular order (as
> long as it's not in 
> the past of what has been rendered)...
And we can even send audio data to a video stream in
DirectShow. No really, order matters. If you send data
in another order than what needs a codec don't expect
to playback properly the file.

> But that's a
> problem for hardware 
> players that can't reorder frames easily (BTW, it
> has always been said 
> that a Cluster should be held full in memory)...
So in this case libebml/EBML doesn't guarantee the
order of the data, and thus nobody can tell for sure
that data will be send in correct order to the codec.
So actually when we write a Matroska file we don't
know if the codec will be able to decode the data we
would send (in an unpredictible order), and if the
file will be playable.

> For elements that DO need an order, it has to be
> written somwehere. So 
> far, for Blocks and now for Encoding, it is an EBML
> element. (timecode, 
> coding order)
But here you assume you know the content of the file
(what kind of codec was used, what data ordering this
codec needs). Anyway since the order can't be
guaranted (since the order of elements can be changed
without the meaning of the file being altered) you
can't even assume that the order in which elements
will be read back is correct (and since you don't know
how to reorder the data you can't playback the file) !?!?

__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com


From chris at matroska.org  Fri Oct 17 19:45:27 2003
From: chris at matroska.org (Christian HJ Wiesner)
Date: Fri, 17 Oct 2003 19:45:27 +0200
Subject: [Matroska-devel] Vobsub in MKV .... Mosu has it working,
 Toff is updating Gabest's
 splitter, but where is Gabest to help with updating vsfilter :O ??
Message-ID: <3F902AB7.1070708@matroska.org>


Cheers guys,

Mosu has vobsub muxing into MKV done, and he can even play them in a
non-public version of mplayer already. Soon after the specs have been
100% fixed and the compression option is working also, he will release a
new mkvtoolnix version and commit his CVS changes to mplayer CVS. I
guess i dont need to tell you what a boost in matroska's acceptance and
wide spread use this may cause, especially in Asian countries where
OCRing of subs is a pain somtimes ....

While Toff has done a great job lately to update the splitter filter on
the Guliverkli homepage, sending a patch to Gabest, i have no doubts he
can add the mapping of the new codec IDs to the splitter in no time (
maybe its done already ? ), but how can we motivate Gabest to update
vsfilter so it can play embedded vobsubs ?

Can anybody drive to Hungary and separate Gabest and his new GF, at
least temporarily  :D :D ??? ( he keeps telling us its a new job, but i
dont believe him :P ... ) .....

Christian





From steve.lhomme at free.fr  Fri Oct 17 19:58:06 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Fri, 17 Oct 2003 19:58:06 +0200
Subject: [Matroska-devel] Element order in EBML/libebml
In-Reply-To: <20031017154314.31434.qmail@web12908.mail.yahoo.com>
References: <20031017154314.31434.qmail@web12908.mail.yahoo.com>
Message-ID: <3F902DAE.1060304@free.fr>

Cyrius wrote:
>>But that's a
>>problem for hardware 
>>players that can't reorder frames easily (BTW, it
>>has always been said 
>>that a Cluster should be held full in memory)...
> 
> So in this case libebml/EBML doesn't guarantee the
> order of the data, and thus nobody can tell for sure
> that data will be send in correct order to the codec.
> So actually when we write a Matroska file we don't
> know if the codec will be able to decode the data we
> would send (in an unpredictible order), and if the
> file will be playable.

No, because you forget one part. For example the MPEG4 native matroska 
stream is in coding order. But we don't assume ALL MPEG4 decoder uses 
this order. That's the job of the link between the matroska reader and 
the codec to please everyone.

But where you are right is that the coding order is defined. But it's 
not enforced. Unless we can find a way to do so. Maybe adding a Block 
Order number to each BlockGroup ? But in general (at least in my mind) 
the order of elements is never assumed.

Also for files produced with other players, the order of the mandatory 
elements doesn't matter, as on reading we erase all of them prior to 
reading.



From chris at matroska.org  Fri Oct 17 16:38:31 2003
From: chris at matroska.org (Christian HJ Wiesner)
Date: Fri, 17 Oct 2003 16:38:31 +0200
Subject: [Matroska-devel] Vobsub in MKV .... Mosu has it working,
 Toff is updating Gabest's
 splitter, but where is Gabest to help with updating vsfilter :O ??
Message-ID: <3F8FFEE7.4070202@matroska.org>


Cheers guys,

Mosu has vobsub muxing into MKV done, and he can even play them in a 
non-public version of mplayer already. Soon after the specs have been 
100% fixed and the compression option is working also, he will release a 
new mkvtoolnix version and commit his CVS changes to mplayer CVS. I 
guess i dont need to tell you what a boost in matroska's acceptance and 
wide spread use this may cause, especially in Asian countries where 
OCRing of subs is a pain somtimes ....

While Toff has done a great job lately to update the splitter filter on 
the Guliverkli homepage, sending a patch to Gabest, i have no doubts he 
can add the mapping of the new codec IDs to the splitter in no time ( 
maybe its done already ? ), but how can we motivate Gabest to update 
vsfilter so it can play embedded vobsubs ?

Can anybody drive to Hungary and separate Gabest and his new GF, at 
least temporarily  :D :D ??? ( he keeps telling us its a new job, but i 
dont believe him :P ... ) .....

Christian




From Liisachan at faireal.net  Fri Oct 17 20:43:26 2003
From: Liisachan at faireal.net (Liisachan)
Date: Sat, 18 Oct 2003 03:43:26 +0900
Subject: [Matroska-devel] Vobsub in MKV .... Mosu has it working, Toff
	is updating Gabest's splitter, but where is Gabest to help with updating
	vsfilter :O ??
In-Reply-To: <3F902AB7.1070708@matroska.org>
References: <3F902AB7.1070708@matroska.org>
Message-ID: <3F90384E.7080501@faireal.net>

Christian HJ Wiesner wrote:

>
> Cheers guys,
>
> Mosu has vobsub muxing into MKV done, and he can even play them in a
> non-public version of mplayer already. Soon after the specs have been
> 100% fixed and the compression option is working also, he will release a
> new mkvtoolnix version and commit his CVS changes to mplayer CVS. I
> guess i dont need to tell you what a boost in matroska's acceptance and
> wide spread use this may cause, especially in Asian countries where
> OCRing of subs is a pain somtimes ....
>
Great news! Long-waited things, and I'd bet many ppl are too lazy to OCR
even in Europe, and will welcome that.


> While Toff has done a great job lately to update the splitter filter on
> the Guliverkli homepage, sending a patch to Gabest, i have no doubts he
> can add the mapping of the new codec IDs to the splitter in no time (
> maybe its done already ? ), but how can we motivate Gabest to update
> vsfilter so it can play embedded vobsubs ?
>
> Can anybody drive to Hungary and separate Gabest and his new GF, at
> least temporarily  :D :D ??? ( he keeps telling us its a new job, but i
> dont believe him :P ... ) .....
>
Well, a guy from "PC Japan"( a major paper magazine
 in japan --> http://www.zdnet.co.jp/magazine/pcjapan/ )
has just asked me to write something about Matroska, like 6 pages
for the next issue of their magazine, which will be on sale on 13.nov.2003
If matroska/vsfilter supports SUB+IDX very soon, like in 7 days,
I can add about SUB+IDX supports and in that case
I promise I'll write "This filter is developed by Gabest, a godlike person,
we all have to thank him" in Japanese :D

Or else, I might write "SUB will be supported very soon,
but the developer in charge, Gabest, is now too busy because of his new gf!"
;)

* Liisachan *



From suiryc at yahoo.com  Fri Oct 17 21:01:54 2003
From: suiryc at yahoo.com (Cyrius)
Date: Fri, 17 Oct 2003 12:01:54 -0700 (PDT)
Subject: [Matroska-devel] Element order in EBML/libebml
In-Reply-To: <3F902DAE.1060304@free.fr>
Message-ID: <20031017190154.78539.qmail@web12908.mail.yahoo.com>

--- Steve Lhomme <steve.lhomme at free.fr> wrote:
> > So in this case libebml/EBML doesn't guarantee the
> > order of the data, and thus nobody can tell for
> sure
> > that data will be send in correct order to the
> codec.
> > So actually when we write a Matroska file we don't
> > know if the codec will be able to decode the data
> we
> > would send (in an unpredictible order), and if the
> > file will be playable.
> 
> No, because you forget one part. For example the
> MPEG4 native matroska 
> stream is in coding order. But we don't assume ALL
> MPEG4 decoder uses 
> this order. That's the job of the link between the
> matroska reader and 
> the codec to please everyone.

That can't be possible, you are talking of ordering
while you already said that ordering doesn't matter.
So there can't possibly be an MPEG4 coding ordering
inside a Matroska file since there is no ordering.

So actually every program dealing with a matroska file
would have to first see what is the content of the
file (normal codec - IP frames; mpeg4 codec - mpeg4
coding order; other kind of codecs - other kind of
order) and then ensure the order of data is correct in
the file/stream (since as per specs the order doesn't
matter and thus isn't guaranted) and if necessary
reorder the frames.

In other words what was said till now is that if I
ever decide to produce a Matroka file where everything
is reversed (in each KaxCluster the KaxBlocks are
written in inverse order, and in the KaxSegment the
KaxClusters are written in reverse order - in other
words frames are stored from the end of the clip till
the beginning in reverse order) then this file would
respect all the specs (EBML and Matroska) and you
won't have to complain about it.

Then I can tell that I don't think any filter will
ever be able to or even want to
1. play this file
2. do it gaplessly

__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com


From moritz at bunkus.org  Fri Oct 17 21:43:16 2003
From: moritz at bunkus.org (Moritz Bunkus)
Date: Fri, 17 Oct 2003 21:43:16 +0200
Subject: [Matroska-devel] Vobsub in MKV .... Mosu has it working,
	Toff is updating Gabest's splitter,
	but where is Gabest to help with updating vsfilter :O ??
In-Reply-To: <3F90384E.7080501@faireal.net>
References: <3F902AB7.1070708@matroska.org> <3F90384E.7080501@faireal.net>
Message-ID: <20031017194316.GC1806@bunkus.org>

Heya,

> Well, a guy from "PC Japan"( a major paper magazine
> in japan --> http://www.zdnet.co.jp/magazine/pcjapan/ )
> has just asked me to write something about Matroska, like 6 pages
> for the next issue of their magazine, which will be on sale on
> 13.nov.2003

Very nice :)

> If matroska/vsfilter supports SUB+IDX very soon, like in 7 days,

That's too soon, I'm afraid :( Perhaps you could write something like
'...is being implemented at the moment and should be available by now'
because it might be doable until the release date (nov 13) ;)

> Or else, I might write "SUB will be supported very soon,
> but the developer in charge, Gabest, is now too busy because of his new gf!"
> ;)

Then you'll have to send him a copy of that magazine along with a
translation ;)

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


From Liisachan at faireal.net  Fri Oct 17 22:09:58 2003
From: Liisachan at faireal.net (Liisachan)
Date: Sat, 18 Oct 2003 05:09:58 +0900
Subject: [Matroska-devel] Vobsub in MKV .... Mosu has it working,	Toff
	is updating Gabest's splitter, but where is Gabest to help with updating
	vsfilter :O ??
In-Reply-To: <20031017194316.GC1806@bunkus.org>
References: <3F902AB7.1070708@matroska.org> <3F90384E.7080501@faireal.net>
	<20031017194316.GC1806@bunkus.org>
Message-ID: <3F904C96.4080302@faireal.net>

Moritz Bunkus wrote:

>>If matroska/vsfilter supports SUB+IDX very soon, like in 7 days,
>>    
>>
>
>That's too soon, I'm afraid :( Perhaps you could write something like
>'...is being implemented at the moment and should be available by now'
>because it might be doable until the release date (nov 13) ;)
>
>  
>
Very well :)  Haste makes waste.  the article can be attractive enough
even without that. Readers have to check the official site and all
at least once anyway. I'll recommend to do so

>>Or else, I might write "SUB will be supported very soon,
>>but the developer in charge, Gabest, is now too busy because of his new gf!"
>>;)
>>    
>>
>
>Then you'll have to send him a copy of that magazine along with a
>translation ;)
>
>  
>
I bet someone will scan the pages,  but come to think of it
i could translate the article before the magazine is out,
because i'm the one who writes it...

Christian HJ Wiesner wrote:

 > especially in Asian countries where
 > OCRing of subs is a pain somtimes ....

For record, it is not "a pain sometimes" but "always impossible"
unless you don't type the all lines manually


* Liisachan *



From chris at matroska.org  Fri Oct 17 21:24:48 2003
From: chris at matroska.org (Christian HJ Wiesner)
Date: Fri, 17 Oct 2003 21:24:48 +0200
Subject: [Matroska-devel] Vobsub in MKV .... Mosu has it working, Toff
	is updating Gabest's splitter, but where is Gabest to help with updating
	vsfilter :O ??
In-Reply-To: <3F90384E.7080501@faireal.net>
References: <3F902AB7.1070708@matroska.org> <3F90384E.7080501@faireal.net>
Message-ID: <3F904200.2040500@matroska.org>

Liisachan wrote:

> Christian HJ Wiesner wrote:
>
>> Cheers guys,
>> Mosu has vobsub muxing into MKV done
>
> Great news! Long-waited things, and I'd bet many ppl are too lazy to OCR
> even in Europe, and will welcome that.

Thats a killer !!! Good bye OGM ..... LOL .....farewell NUT ..... LMAO 
..... ;) ....

>> While Toff has done a great job lately to update the splitter filter 
>> on the Guliverkli homepage, sending a patch to Gabest, i have no 
>> doubts he
>> can add the mapping of the new codec IDs to the splitter in no time (
>> maybe its done already ? ), but how can we motivate Gabest to update
>> vsfilter so it can play embedded vobsubs ?
>>
>> Can anybody drive to Hungary and separate Gabest and his new GF, at
>> least temporarily  :D :D ??? ( he keeps telling us its a new job, but i
>> dont believe him :P ... ) .....
>>
> Well, a guy from "PC Japan"( a major paper magazine
> in japan --> http://www.zdnet.co.jp/magazine/pcjapan/ )
> has just asked me to write something about Matroska, like 6 pages
> for the next issue of their magazine, which will be on sale on 
> 13.nov.2003 

:O :O !!!! 6 pages !!!!!!! Oh my God !!  Can i copy this on the CHIP 
guys .. they just gave us 1/12 of a page ;) ....

> If matroska/vsfilter supports SUB+IDX very soon, like in 7 days,
> I can add about SUB+IDX supports and in that case
> I promise I'll write "This filter is developed by Gabest, a godlike 
> person,
> we all have to thank him" in Japanese :D 

Just do it, write its possible right now, because Gabest is a real 
gentleman and he can not risk that your reputation gets damaged, so he 
has to code it :P ...

> Or else, I might write "SUB will be supported very soon,
> but the developer in charge, Gabest, is now too busy because of his 
> new gf!"
> ;)

Hehehehehe ... yeah, great plan, do that :D !

Christian



From moritz at bunkus.org  Sat Oct 18 13:45:22 2003
From: moritz at bunkus.org (Moritz Bunkus)
Date: Sat, 18 Oct 2003 13:45:22 +0200
Subject: [Matroska-devel] DRAFT: 2nd try at the new elements for
	compression/encryption
In-Reply-To: <20031017075042.GY1806@bunkus.org>
References: <20031017075042.GY1806@bunkus.org>
Message-ID: <20031018114522.GJ1806@bunkus.org>

Hi.

> KaxTracks (old)
> \+ KaxTrackEntry (old)
>  \+ KaxContentEncoding (master, optional, multiple)
>   \+ KaxContentEncodingOrder (UInt, mandatory, unique, single,
>      default 0)
>    + KaxContentEncodingScope (UInt, mandatory, single, default 0)
>    + KaxContentEncodingType (UInt, mandatory, single, default 0)
>    + KaxContentCompression (master, optional, single)
>    \+ KaxContentCompressionAlgo (UInt, mandatory, single, default 0)
>     + KaxContentCompressionSettings (binary, optional, single)
>    \+ KaxContentEncryption (master, optional, single)
>     + KaxContentEncryptionAlgo (UInt, optional, single)
>     + KaxContentEncryptionKeyID (binary, optional, single)
>     + KaxContentSignatureAlgo (UInt, optional, single)
>     + KaxContentSignatureHashAlgo (UInt, optional, single)
>     + KaxContentSignatureKeyID (binary, optional, single)
>     + KaxContentSignature (binary, optional, single)

I've implemented this scheme locally, but I haven't committed anything
to CVS yet. You have until tomorrow evening to cry 'stop!' or I'll
commit ;)

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


From moritz at bunkus.org  Sat Oct 18 13:51:12 2003
From: moritz at bunkus.org (Moritz Bunkus)
Date: Sat, 18 Oct 2003 13:51:12 +0200
Subject: [Matroska-devel] Re: DRAFT: new elements for
	compression/encryption
In-Reply-To: <3F8FA87F.9090106@free.fr>
References: <20031016220228.GU1806@bunkus.org> <bmn904$guf$1@sea.gmane.org>
	<3F8FA87F.9090106@free.fr>
Message-ID: <20031018115112.GK1806@bunkus.org>

Hi.

> How about the "only certain frames" ? That would also encryption of only 
> some parts of a movie or 1 frame every 3, so that the user still need to 
> get a way do decrypt it and still be somehow playable. It would also 
> save some encryption time on some systems.

Not possible - or not without HUGE overhead. You cannot simply use a bit
in the block or something like that because you can have more than one
ContentEncoding element present. So you probably need something like
this for each block that you want to mark specifically:

KaxBlockGroup
\+ KaxBlockEncoding
 \+ KaxBlockEncodingOrder (references the ContentEncoding block)
  + KaxBlockEncodingDone (wether or not encoding has been done to this
    block)

Depending on how you interpret the lack of such a KaxBlockEncoding
element in a BlockGroup read from disc you'll have more or less overhead
- but it'll be huge. (If no KaxBlockEncoding element is present then the
block has been encoded - or has it not?)

Let's keep this simple and not introduce this ability. It's a 'maybe
nice to have', but I can't really imagine an useful application for it.

> I propose a bitfield for these values :
> bit 0 : track's private data
> bit 1 : frames marked as such (we need to use something in the frame, 
> probably a bit in the frame header)
> bit 2 : all frames

What if both bit 1 and 2 are set? 2 has precedence over 1 I suppose.

> I was thinking about adding a Bitfield EBML type someday. Maybe we could 
> do it now.

If you can do it fast, then I'm fine with it, but I want to get this
done sooner than later.

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


From moritz at bunkus.org  Sun Oct 19 18:10:05 2003
From: moritz at bunkus.org (Moritz Bunkus)
Date: Sun, 19 Oct 2003 18:10:05 +0200
Subject: [Matroska-devel] new content encoding elements
Message-ID: <20031019161005.GO1806@bunkus.org>

Hi.

I've committed the new sources for the content encoding elements and
written the specs for them. Only one change has been done compared to my
second draft (ContentEncodingScope); please read the specs to find out
what I've chosen.

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


From steve.lhomme at free.fr  Sun Oct 19 20:15:24 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Sun, 19 Oct 2003 20:15:24 +0200
Subject: [Matroska-devel] new content encoding elements
In-Reply-To: <20031019161005.GO1806@bunkus.org>
References: <20031019161005.GO1806@bunkus.org>
Message-ID: <3F92D4BC.70009@free.fr>

Moritz Bunkus wrote:
> Hi.
> 
> I've committed the new sources for the content encoding elements and
> written the specs for them. Only one change has been done compared to my
> second draft (ContentEncodingScope); please read the specs to find out
> what I've chosen.

I'll have a look. Dunno when but not tonight (I need to get back my 
sleeping time). But I had not much complaint with the previous version. 
IMO the order thing is not really a problem.



From chris at matroska.org  Mon Oct 20 10:42:24 2003
From: chris at matroska.org (Christian HJ Wiesner)
Date: Mon, 20 Oct 2003 10:42:24 +0200
Subject: [Matroska-devel] Public poll on Doom9 about hardware support for
	matroska
Message-ID: <3F939FF0.8020608@matroska.org>


Hi guys,

this poll here was discussed with Doom9 before, and approved by him :

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

Lets see how many interested users we have for that, and what it would 
be worth to them :) ! This poll will be used in my constraints to get 
proper hardware support for matroska.

Christian



From suiryc at yahoo.com  Mon Oct 20 16:56:51 2003
From: suiryc at yahoo.com (Cyrius)
Date: Mon, 20 Oct 2003 07:56:51 -0700 (PDT)
Subject: [Matroska-devel] Element order in EBML/libebml
In-Reply-To: <20031017190154.78539.qmail@web12908.mail.yahoo.com>
Message-ID: <20031020145651.65230.qmail@web12904.mail.yahoo.com>

The "ordering doesn't matter" still need to be
discussed.
If order doesn't matter I don't see why we all try to
mux the stream in sync (and e.g. write the subtitles
block just after the video at which time they should
appear, and so on).

If order doesn't matter that means you would have to
load the file in memory and sort the elements to get
back the correct order (that's just to point out some
nonsense behind "order doesn't matter")

__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com


From rbultje at ronald.bitfreak.net  Mon Oct 20 17:07:43 2003
From: rbultje at ronald.bitfreak.net (Ronald Bultje)
Date: Mon, 20 Oct 2003 17:07:43 +0200
Subject: [Matroska-devel] Element order in EBML/libebml
In-Reply-To: <20031020145651.65230.qmail@web12904.mail.yahoo.com>
References: <20031020145651.65230.qmail@web12904.mail.yahoo.com>
Message-ID: <1066662463.4270.441.camel@shrek.bitfreak.net>

On Mon, 2003-10-20 at 16:56, Cyrius wrote:
> If order doesn't matter that means you would have to
> load the file in memory and sort the elements to get
> back the correct order (that's just to point out some
> nonsense behind "order doesn't matter")

That's what DirectShow and GStreamer do, right? At least GStreamer does
so in a way. We read blocks from files, place them in a queue and let
the decoder decode it when it feels like it. Then, the outputs play this
decoded data back (possible from another queue). There can be any number
of queues in the pipeline and any number of buffers (with a maximum, of
course, but that's not the point). The only element that takes care of
sync is the video/audio output. So I might be reading 10 MB ahead of the
data that I'm currently playing, my decoder might be 8 MB ahead and the
rest might be queued in between. So if my video/audio data of the same
time are 8 MB apart from each other, you won't notice (in GStreamer).

Order indeed doesn't matter, not that much.

Placing things in order still can matter at parts where the queue'ing is
harder than this. Imagine live stream viewing, these kind of things.
That's why you try to keep streams synchronized in the file.

Ronald

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



From steve.lhomme at free.fr  Mon Oct 20 17:08:22 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Mon, 20 Oct 2003 17:08:22 +0200
Subject: [Matroska-devel] Element order in EBML/libebml
In-Reply-To: <20031020145651.65230.qmail@web12904.mail.yahoo.com>
References: <20031020145651.65230.qmail@web12904.mail.yahoo.com>
Message-ID: <3F93FA66.2090509@free.fr>

Cyrius wrote:

> The "ordering doesn't matter" still need to be
> discussed.
> If order doesn't matter I don't see why we all try to
> mux the stream in sync (and e.g. write the subtitles
> block just after the video at which time they should
> appear, and so on).
> 
> If order doesn't matter that means you would have to
> load the file in memory and sort the elements to get
> back the correct order (that's just to point out some
> nonsense behind "order doesn't matter")

OK, I agree, there IS a problem based on what I said with the MPEG4 
encoding order (as an example). I proposed that we add an order number 
to each block (or to each frame) that would help such a possible 
reorder. But for now this is not a problem and probably never will. 
Because I don't know any reader that change the order of elements on 
reading. And rewriting or adding elements to such an element would not 
change the order in libebml (and probably any other library).



From suiryc at yahoo.com  Mon Oct 20 17:24:29 2003
From: suiryc at yahoo.com (Cyrius)
Date: Mon, 20 Oct 2003 08:24:29 -0700 (PDT)
Subject: [Matroska-devel] Element order in EBML/libebml
In-Reply-To: <1066662463.4270.441.camel@shrek.bitfreak.net>
Message-ID: <20031020152429.94376.qmail@web12907.mail.yahoo.com>

--- Ronald Bultje <rbultje at ronald.bitfreak.net> wrote:
> On Mon, 2003-10-20 at 16:56, Cyrius wrote:
> > If order doesn't matter that means you would have
> to
> > load the file in memory and sort the elements to
> get
> > back the correct order (that's just to point out
> some
> > nonsense behind "order doesn't matter")
> 
> That's what DirectShow and GStreamer do, right? At
> least GStreamer does
> so in a way. We read blocks from files, place them
> in a queue and let
> the decoder decode it when it feels like it. Then,
> the outputs play this
> decoded data back (possible from another queue).
> There can be any number
> of queues in the pipeline and any number of buffers
> (with a maximum, of
> course, but that's not the point). The only element
> that takes care of
> sync is the video/audio output. So I might be
> reading 10 MB ahead of the
> data that I'm currently playing, my decoder might be
> 8 MB ahead and the
> rest might be queued in between. So if my
> video/audio data of the same
> time are 8 MB apart from each other, you won't
> notice (in GStreamer).
> 
> Order indeed doesn't matter, not that much.
> 
> Placing things in order still can matter at parts
> where the queue'ing is
> harder than this. Imagine live stream viewing, these
> kind of things.
> That's why you try to keep streams synchronized in
> the file.

It's true that the data can be buffered (when
possible, it's harder in live streaming as you said)
in case the data interleaving is shifted (that's e.g.
the case in AVI when using preloading of audio).
The problem here is that the specs don't say you can't
(e.g) swap the order of the data (i.e. write frame 5,
4, 3, 2, 1 in the file).
When you know what kind of stream it is you can still
reorder the frames (for a standard I/P stream the
frame order should be 1, 2, 3, 4, 5; for I/P/B streams
in coding order it would be ...; etc), but if you
don't know in which order send the frames to the codec
there will be problems (if you send frames in reverse
order the codec will think that the stream is broken
and won't decode properly the stream, and will
certainly not sort the frames for us, nor the
multimedia layer used - DirectShow, GStreamer, ...).


--- Steve Lhomme <steve.lhomme at free.fr> wrote:
> OK, I agree, there IS a problem based on what I said
> with the MPEG4 
> encoding order (as an example). I proposed that we
> add an order number 
> to each block (or to each frame) that would help
> such a possible 
> reorder. But for now this is not a problem and
> probably never will. 
> Because I don't know any reader that change the
> order of elements on 
> reading. And rewriting or adding elements to such an
> element would not 
> change the order in libebml (and probably any other
> library).

Yes we all write the data in the correct order because
for us the order matter for the data.

It's true that for some elements in the file the order
doesn't really matter (e.g. KaxChapters could be
before KaxTracks, after KaxTracks and before the first
KaxCluster, or even at the end of the file; of course
in this case the KaxSeekHead would help to know where
the element is if we need it right at the start), but
in the case of the data (KaxBlock) the order matter if
you want to be able to decode the stream. So IMO
"order doesn't matter" ... for some elements and
matters for others.





From steve.lhomme at free.fr  Mon Oct 20 17:37:22 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Mon, 20 Oct 2003 17:37:22 +0200
Subject: [Matroska-devel] Element order in EBML/libebml
In-Reply-To: <20031020152429.94376.qmail@web12907.mail.yahoo.com>
References: <20031020152429.94376.qmail@web12907.mail.yahoo.com>
Message-ID: <3F940132.5060707@free.fr>

Cyrius wrote:
> Yes we all write the data in the correct order because
> for us the order matter for the data.
> 
> It's true that for some elements in the file the order
> doesn't really matter (e.g. KaxChapters could be
> before KaxTracks, after KaxTracks and before the first
> KaxCluster, or even at the end of the file; of course
> in this case the KaxSeekHead would help to know where
> the element is if we need it right at the start), but
> in the case of the data (KaxBlock) the order matter if
> you want to be able to decode the stream. So IMO
> "order doesn't matter" ... for some elements and
> matters for others.

MMmm, let's say order doesn't matter. And for some elements we need to 
have the order written because order matters. We already have the 
timecode (and order in some other places). If we need more (for safety 
and editing/correcting) we can add it.



From chris at matroska.org  Mon Oct 20 18:43:41 2003
From: chris at matroska.org (Christian HJ Wiesner)
Date: Mon, 20 Oct 2003 18:43:41 +0200
Subject: [Matroska-devel] matroska excluded from Gordian Knot 0.29 Alpha
Message-ID: <3F9410BD.3070300@matroska.org>


Hi guys,

just so you know, Toni 'len0x' , the main developer of the Gordian Knot, 
has informed me that he will not add MKV support in the upcoming public 
alpha release of Gordian Knot, because there is still no working 
overhead formula / code he could use. The release is due in about 5 
days, and we are invited to give him anything of value until then.

I guess i dont need to tell you all how important this would have been 
for us. I was recommending to him to simply use the AVI overhead 
calculation, as both are close in most cases and MKV is always a little 
bit smaller ( of course, only when the AVI is muxed with Virtualdub, not 
with AVImux-GUI ;-) ) .... he said he will consider to do that, but 
didnt give me any confirmation if its possible.

If anybody has a good idea how we can solve this problem, please shout 
LOUD !

Christian



From alexander.noe at s2001.tu-chemnitz.de  Mon Oct 20 18:50:08 2003
From: alexander.noe at s2001.tu-chemnitz.de (=?ISO-8859-1?Q?Alexander_No=E9?=)
Date: Mon, 20 Oct 2003 18:50:08 +0200
Subject: [Matroska-devel] matroska excluded from Gordian Knot 0.29 Alpha
In-Reply-To: <3F9410BD.3070300@matroska.org>
References: <3F9410BD.3070300@matroska.org>
Message-ID: <3F941240.7020808@hrz.tu-chemnitz.de>

Christian HJ Wiesner wrote:

> I guess i dont need to tell you all how important this would have been 
> for us. I was recommending to him to simply use the AVI overhead 
> calculation

No, i'd prefer him to throw a dice. That's more accurate

> , as both are close in most cases and MKV is always a little bit 
> smaller ( of course, only when the AVI is muxed with Virtualdub, not 
> with AVImux-GUI ;-) ) .... he said he will consider to do that, but 
> didnt give me any confirmation if its possible. 

I hope he won't. Even the current implemention of overhead code in 
avimux gui, includung the prediction
of ebml lacing overhead, is more accurate than using the AVI code...



Alex



From chris at matroska.org  Mon Oct 20 19:03:09 2003
From: chris at matroska.org (Christian HJ Wiesner)
Date: Mon, 20 Oct 2003 19:03:09 +0200
Subject: [Matroska-devel] USF revival !!! Where are your alpha editors guys
	??
Message-ID: <3F94154D.5050308@matroska.org>


Hi unmei, hi kovac_andre ( if you are reading ) !

While we didnt look at USF for a little while, we will now revitalize 
this subject a lot, because of recent events ( we may tell you on IRC, 
in private, but not here on a public list :D ), and because USF is XML 
and can be ead with EXPAT on programmable hardware units ;-)  ...

Are your editors usable already ? Could you make some changes to them to 
respect some small, last minute changes made by Toff ?

unmei, is the version here the most actual : 
http://www.hta-bi.bfh.ch/~seilf/ ?? Do you have the email adress from 
Kovac Endre ?

Please use the 'reply-all' button when answering.

Thanks

Christian



From paul at msn.com  Tue Oct 21 06:22:25 2003
From: paul at msn.com (Pamel)
Date: Mon, 20 Oct 2003 23:22:25 -0500
Subject: [Matroska-devel] Re: matroska excluded from Gordian Knot 0.29 Alpha
References: <3F9410BD.3070300@matroska.org>
	<3F941240.7020808@hrz.tu-chemnitz.de>
Message-ID: <bn2c9j$3tp$1@sea.gmane.org>

"Alexander No?" wrote ...
> Christian HJ Wiesner wrote:
>
> > I guess i dont need to tell you all how important this would have been
> > for us. I was recommending to him to simply use the AVI overhead
> > calculation
>
> No, i'd prefer him to throw a dice. That's more accurate

Using the AVI code would tell you what size the file will not reach. This is
probably better than nothing at all.


Pamel





From chris at matroska.org  Tue Oct 21 09:28:55 2003
From: chris at matroska.org (Christian HJ Wiesner)
Date: Tue, 21 Oct 2003 09:28:55 +0200
Subject: [Matroska-devel] Re: matroska excluded from Gordian Knot 0.29
	Alpha
In-Reply-To: <bn2c9j$3tp$1@sea.gmane.org>
References: <3F9410BD.3070300@matroska.org>	<3F941240.7020808@hrz.tu-chemnitz.de>
	<bn2c9j$3tp$1@sea.gmane.org>
Message-ID: <3F94E037.4030207@matroska.org>

Pamel wrote:

> Using the AVI code would tell you what size the file will not reach. 
> This is
>
>probably better than nothing at all.
>Pamel
>  
>
 This was exactly the idea ... it will always leave some MB to include 
either TCMP or one of the matroska packs with the CD :D ....

Christian



From alexander.noe at s2001.tu-chemnitz.de  Tue Oct 21 11:37:33 2003
From: alexander.noe at s2001.tu-chemnitz.de (=?ISO-8859-1?Q?Alexander_No=E9?=)
Date: Tue, 21 Oct 2003 11:37:33 +0200
Subject: [Matroska-devel] Re: matroska excluded from Gordian Knot 0.29
	Alpha
In-Reply-To: <3F94E037.4030207@matroska.org>
References: <3F9410BD.3070300@matroska.org>	<3F941240.7020808@hrz.tu-chemnitz.de>	<bn2c9j$3tp$1@sea.gmane.org>
	<3F94E037.4030207@matroska.org>
Message-ID: <3F94FE5D.8060904@hrz.tu-chemnitz.de>

Christian HJ Wiesner wrote:

> Pamel wrote:
>
>> Using the AVI code would tell you what size the file will not reach. 
>> This is
>>
>> probably better than nothing at all.
>> Pamel
>>  
>>
> This was exactly the idea ... it will always leave some MB to include 
> either TCMP or one of the matroska packs with the CD :D .... 

I've found out why my code was b0rked. However, with this EBML lacing, I 
will *never* promise an
accuracy any better than 10% for overhead prediction. Basicly, it will 
be off by not more than
0.5 bytes per frame (it can be 1 or 2, so if I assume 1.5 bytes per 
frame, it won't be off by more than
0,5), i.e. 75 kB per hour and stream, which is 450 kB for 3 languages in 
a 2h movie, which is
about 10% of the total overhead of such a thing, roughly estimated. The 
more vbr audio streams
there are, the worse *could* the estimation be.

Anything better would require statistical analysis of the output of 
certain encoders for each bitrate and
quality setting. What you see in the attached file is 3 hours, but only 
one stream.



Alex
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: proto.txt
URL: <http://lists.matroska.org/pipermail/matroska-devel/attachments/20031021/3b70561b/attachment.txt>

From chris at matroska.org  Tue Oct 21 12:21:51 2003
From: chris at matroska.org (Christian HJ Wiesner)
Date: Tue, 21 Oct 2003 12:21:51 +0200
Subject: [Fwd: Re: [Matroska-devel] Re: matroska excluded from Gordian Knot
	0.29	Alpha]
Message-ID: <3F9508BF.9090506@matroska.org>

Ok,

this email is going to the gordianknot-alphas list and to matroska-devel 
also. matroska devs please note you cant send emails to the GKnot list 
if you are not subscribed.

Toni, Alex has overworked his MKV overhead code again, and i guess the 
accuracy he thinks is possible should be more than ok for the purposes 
in GKnot. Would you be prepared to look at it again ? You mentioned you 
need a formula for it to work, i dont know if Alex Noe can make such a 
formula from his code, but isnt the C++ code usable somehow ? Maybe as a 
DLL ?

Christian


-------- Original Message --------
Subject: 	Re: [Matroska-devel] Re: matroska excluded from Gordian Knot 
0.29 Alpha
Date: 	Tue, 21 Oct 2003 11:37:33 +0200
From: 	Alexander No? <alexander.noe at s2001.tu-chemnitz.de>
Reply-To: 	Discussion about the current and future development of 
Matroska <matroska-devel at lists.matroska.org>
To: 	Discussion about the current and future development of Matroska 
<matroska-devel at lists.matroska.org>
References: 	<3F9410BD.3070300 at matroska.org> 
<3F941240.7020808 at hrz.tu-chemnitz.de> <bn2c9j$3tp$1 at sea.gmane.org> 
<3F94E037.4030207 at matroska.org>



Christian HJ Wiesner wrote:

> Pamel wrote:
>
>> Using the AVI code would tell you what size the file will not reach. 
>> This is
>>
>> probably better than nothing at all.
>> Pamel
>>  
>>
> This was exactly the idea ... it will always leave some MB to include 
> either TCMP or one of the matroska packs with the CD :D .... 

I've found out why my code was b0rked. However, with this EBML lacing, I 
will *never* promise an
accuracy any better than 10% for overhead prediction. Basicly, it will 
be off by not more than
0.5 bytes per frame (it can be 1 or 2, so if I assume 1.5 bytes per 
frame, it won't be off by more than
0,5), i.e. 75 kB per hour and stream, which is 450 kB for 3 languages in 
a 2h movie, which is
about 10% of the total overhead of such a thing, roughly estimated. The 
more vbr audio streams
there are, the worse *could* the estimation be.

Anything better would require statistical analysis of the output of 
certain encoders for each bitrate and
quality setting. What you see in the attached file is 3 hours, but only 
one stream.



Alex


-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: proto.txt
URL: <http://lists.matroska.org/pipermail/matroska-devel/attachments/20031021/d49cdd65/attachment.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: file:///C|/DOKUME%7E1/V-CW/LOKALE%7E1/TEMP/nsmail-2.txt
URL: <http://lists.matroska.org/pipermail/matroska-devel/attachments/20031021/d49cdd65/attachment-0001.txt>

From steve.lhomme at free.fr  Tue Oct 21 15:38:17 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Tue, 21 Oct 2003 15:38:17 +0200
Subject: [Matroska-devel] Subtitles can contain a virus ???
Message-ID: <3F9536C9.3020602@free.fr>

http://www.presence-pc.com/news/n1915.html

Where is Gabest ?



From steve.lhomme at free.fr  Tue Oct 21 15:40:59 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Tue, 21 Oct 2003 15:40:59 +0200
Subject: [Matroska-devel] Subtitles can contain a virus ???
In-Reply-To: <3F9536C9.3020602@free.fr>
References: <3F9536C9.3020602@free.fr>
Message-ID: <3F95376B.5010805@free.fr>

Steve Lhomme wrote:

> http://www.presence-pc.com/news/n1915.html
> 
> Where is Gabest ?

http://www.bitdefender.com/bd/site/presscenter.php?menu_id=23&n_id=49

Never mind, it's not contained IN the movie...



From moritz at bunkus.org  Tue Oct 21 16:44:09 2003
From: moritz at bunkus.org (Moritz Bunkus)
Date: Tue, 21 Oct 2003 16:44:09 +0200
Subject: [Matroska-devel] new content encoding elements
In-Reply-To: <3F92D4BC.70009@free.fr>
References: <20031019161005.GO1806@bunkus.org> <3F92D4BC.70009@free.fr>
Message-ID: <20031021144409.GC18749@bunkus.org>

Hi.

> I'll have a look. Dunno when but not tonight (I need to get back my 
> sleeping time). But I had not much complaint with the previous version. 
> IMO the order thing is not really a problem.

Any objections? :) If not then you should add your new lacing code (it
ain't in yet, or is it?), boost the version number to 0.6.0 and release
a new version.

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


From steve.lhomme at free.fr  Tue Oct 21 16:51:58 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Tue, 21 Oct 2003 16:51:58 +0200
Subject: [Matroska-devel] new content encoding elements
In-Reply-To: <20031021144409.GC18749@bunkus.org>
References: <20031019161005.GO1806@bunkus.org> <3F92D4BC.70009@free.fr>
	<20031021144409.GC18749@bunkus.org>
Message-ID: <3F95480E.3070704@free.fr>

Moritz Bunkus wrote:

> Hi.
> 
> 
>>I'll have a look. Dunno when but not tonight (I need to get back my 
>>sleeping time). But I had not much complaint with the previous version. 
>>IMO the order thing is not really a problem.
> 
> 
> Any objections? :) If not then you should add your new lacing code (it
> ain't in yet, or is it?), boost the version number to 0.6.0 and release
> a new version.

It's not finished yet as I have to make changes in the old lacing (code 
factorisation). I think it will be done tonight. Then I'll merge with 
your changes. The default lacing will be LACING_EBML (not LACING_XIPH) 
so the old code will probably not be compatible (it just needs changing 
a parameter here and there).



From chris at matroska.org  Tue Oct 21 16:56:46 2003
From: chris at matroska.org (Christian HJ Wiesner)
Date: Tue, 21 Oct 2003 16:56:46 +0200
Subject: [Gordianknot-alphas] [Fwd: Re: [Matroska-devel] Re: matroska
	excluded from Gordian Knot 0.29	Alpha]
In-Reply-To: <000601c397c2$89a35c20$2606a992@speedo>
References: <000601c397c2$89a35c20$2606a992@speedo>
Message-ID: <3F95492E.3080809@matroska.org>

Tony Lenox wrote:

>Christian,
>
>Are you sure that current Alex's overhead is the same as overhead produced
>by VDubMod 1.5.1.1a
>
There has not been much changes in terms of overhead since 1.5.1.1a, so 
we should be fine anyhow

>(1.5.4.1 is seriously bugged for XviD users, I'm going to roll back to
>1.5.1.1a instead)
>
What build ? Please note, if you will use a too early build, we are 
maybe asking you politely to exclude MKV support for the time being and 
make it a later stage. There have been some early builds of 
VirtualdubMod where MKV files created with it were spec compliant and 
playable, but had some serious flaws, so we wouldnt wnat to spread more 
of these files if possible.

>I would apriciate the posting of exact code (if not the formula, but there
>should be 1-2-1 correspondence anyway) 
>
Cant we post the sources here to the mailing list ? Else i can organize 
they get uploaded, and i pass you the link ...

>either here, or in the forum where I can ask questions. len0x
>
Or on IRC, where you are always welcome ;) ....

Christian



From moritz at bunkus.org  Tue Oct 21 17:07:01 2003
From: moritz at bunkus.org (Moritz Bunkus)
Date: Tue, 21 Oct 2003 17:07:01 +0200
Subject: [Matroska-devel] Element order in EBML/libebml
In-Reply-To: <20031020152429.94376.qmail@web12907.mail.yahoo.com>
References: <1066662463.4270.441.camel@shrek.bitfreak.net>
	<20031020152429.94376.qmail@web12907.mail.yahoo.com>
Message-ID: <20031021150701.GD18749@bunkus.org>

Hi.

Here's my take on the 'does order matter?' issue. It's rather long, but
please read it fully, because I think that this whole business is
basically a non-issue.

1) What do we want?

We want to be able to play a movie ( = a Matroska file, same goes for
audio only files, I'm just simplifying) with as little effort as
possible. We want to have files that are as small as possible while
retaining as much information about the contents as possible. We want to
have a flexible format.

2) How can that be achieved?

Little effort: This means (among other things) that you should be able
to play the file from front to back without having to seek backwards at
all. This implies having the track information before the first cluster,
and it implies a certain order of data in the file. This also means that
we do NOT want to buffer half of the file just because audio and video
are not interleaved properly.

Small files: We don't want to store useless stuff like a 'element order
number' for elements that occur very often.

Flexible format: We based EBML on XML, and Matroska is our DTD (a bit
simplified, but the comparison works in this case). But EBML is neither
equal to XML, nor does it follow the same principles in every way.

3) How do others achieve this?

XML is very flexible. It lets you create your own elements. If you have
a DTD then you have a certain set of elements that can be children of
other elements, may occur multiple times etc. Sounds like Matroska,
doesn't it? Yes, but one important difference is the topic of 'ordering
elements'. For a XML document with a DTD you have a fixed order of
different elements, meaning that
<book>
  <title>Stupid White Men</title>
  <author>Michael Moore</author>
</book>
and
<book>
  <author>Michael Moore</author>
  <title>Stupid White Men</title>
</book>
are not the same document! One will comply to the DTD while the other
does not. In Matroska this is DIFFERENT - here the chapters may come
after the clusters or before them.
In XML the order of multiple entities of the same element do NOT
matter. These two documents are the same:
<telephone>
  <key>1</key>
  <key>2</key>
</telephone>
and
<telephone>
  <key>2</key>
  <key>1</key>
</telephone>
At the moment we have the same behaviour with Matroska.

Other multimedia file formats however chose to have an order - the order
in which you put the data into the container does matter and should (or
must?) be kept intact in order for the demuxer/decoder to be handled
properly. Fully indexed formats usually don't need this (!) because they
have the index which will tell the block order. Matroska is not a fully
indexed format. However in many cases we already have an implicit order:
Clusters have a cluster timecode, and we agree that blocks should be
stored in coding order (which is basically the timecode if no B frames
are present).

4) How should we do it?

Just to clarify some words (I copy the definitions from a RFC2119):

1. MUST   This word, or the terms "REQUIRED" or "SHALL", mean that the
   definition is an absolute requirement of the specification.
3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
   may exist valid reasons in particular circumstances to ignore a
   particular item, but the full implications must be understood and
   carefully weighed before choosing a different course.

I will use these two words in the following requirements. My goal is to
chose the PRACTICAL solution, not necessarily the MOST ELEGANT or
TECHNICALLY SUPERIOR one.

1. Order of Matroska elements does generally NOT matter. Exceptions:
2. The order of Clusters and BlockGroups DOES matter. Details:
  1. Clusters MUST be ordered by the smallest global timecode of all
     block groups present in it. In most cases this is the cluster
     timecode, but it does not have to be.
  2. The block groups for each track MUST be ordered by their coding
     order.
3. Block groups SHOULD be interleaved sanely. No limitations will be
   given for this, but basically all the information required to play
   back all tracks at timecode X should be in close proximity to each
   other in the file.
4. All level 1 elements SHOULD be easy to find by the demuxer. This
   means that they either are positioned before the first cluster or
   that they can be found by parsing and following meta seek elements
   (which again SHOULD be easy to find).

What this means is that what we already do is the Right Way to do
things. We should just formalize it. We should not have to add an
element to each block group describing its position in the Great Scheme
of Things. It would create a HUGE overhead, and it would make us the
laughing stock of the whole multimedia industry.

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


From steve.lhomme at free.fr  Tue Oct 21 17:31:32 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Tue, 21 Oct 2003 17:31:32 +0200
Subject: [Matroska-devel] Element order in EBML/libebml
In-Reply-To: <20031021150701.GD18749@bunkus.org>
References: <1066662463.4270.441.camel@shrek.bitfreak.net>	<20031020152429.94376.qmail@web12907.mail.yahoo.com>
	<20031021150701.GD18749@bunkus.org>
Message-ID: <3F955154.3030700@free.fr>

Moritz Bunkus wrote:
> What this means is that what we already do is the Right Way to do
> things. We should just formalize it. We should not have to add an
> element to each block group describing its position in the Great Scheme
> of Things. It would create a HUGE overhead, and it would make us the
> laughing stock of the whole multimedia industry.

I agree, because in the end noone is going to reorder a file before 
playing it back... And noone is going to produce a "damaged" file when 
order is b0rked...



From steve.lhomme at free.fr  Tue Oct 21 18:09:56 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Tue, 21 Oct 2003 18:09:56 +0200
Subject: [Matroska-devel] new content encoding elements
In-Reply-To: <20031021144409.GC18749@bunkus.org>
References: <20031019161005.GO1806@bunkus.org> <3F92D4BC.70009@free.fr>
	<20031021144409.GC18749@bunkus.org>
Message-ID: <3F955A54.9060804@free.fr>

Moritz Bunkus wrote:

> Hi.
> 
> 
>>I'll have a look. Dunno when but not tonight (I need to get back my 
>>sleeping time). But I had not much complaint with the previous version. 
>>IMO the order thing is not really a problem.
> 
> 
> Any objections? :) If not then you should add your new lacing code (it
> ain't in yet, or is it?), boost the version number to 0.6.0 and release
> a new version.

I was just looking at the specs and noticed you can have many 
"ContentEncoding". I think it would be better to have them all in a 
larger element. Otherwise you have to scan the whole track entry to find 
them all.

When the "frame contents" is selected for encryption/compression, does 
it apply to all frame contents ? Or you can select a few (as I 
suggested) and then, how ? What about lacing ? Does it apply to all the 
lace in one pass, or each elements (frames) of the lace separately ?



From moritz at bunkus.org  Tue Oct 21 19:51:07 2003
From: moritz at bunkus.org (Moritz Bunkus)
Date: Tue, 21 Oct 2003 19:51:07 +0200
Subject: [Matroska-devel] new content encoding elements
In-Reply-To: <3F955A54.9060804@free.fr>
References: <20031019161005.GO1806@bunkus.org> <3F92D4BC.70009@free.fr>
	<20031021144409.GC18749@bunkus.org> <3F955A54.9060804@free.fr>
Message-ID: <20031021175107.GH18749@bunkus.org>

Hi.

> I was just looking at the specs and noticed you can have many 
> "ContentEncoding". I think it would be better to have them all in a 
> larger element. Otherwise you have to scan the whole track entry to find 
> them all.

Ok, I'll call it 'KaxContentEncodings' (notice the 's' ;)) and move
everything one level down.

> When the "frame contents" is selected for encryption/compression, does 
> it apply to all frame contents ?

At the moment this flag means 'all frames'. That should be made clear in
the specs, I'll change the wording if necessary.

> Or you can select a few (as I 
> suggested) and then, how ?

Not yet. I suggest we leave that out and can safely introduce this via a
new flag later on, because for that we need at least three new elements
under KaxBlockGroup which we will have to think about very carefully.

> What about lacing ? Does it apply to all the 
> lace in one pass, or each elements (frames) of the lace separately ?

Separately! Anything else wouldn't make any sense. Let's assume Alex'
AVIMuxGui writes laces with 20 elements - we couldn't just copy the
blocks over because libmatroska only puts up to eight blocks into one
lace.

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


From moritz at bunkus.org  Tue Oct 21 20:25:55 2003
From: moritz at bunkus.org (Moritz Bunkus)
Date: Tue, 21 Oct 2003 20:25:55 +0200
Subject: [Matroska-devel] new content encoding elements
In-Reply-To: <20031021175107.GH18749@bunkus.org>
References: <20031019161005.GO1806@bunkus.org> <3F92D4BC.70009@free.fr>
	<20031021144409.GC18749@bunkus.org> <3F955A54.9060804@free.fr>
	<20031021175107.GH18749@bunkus.org>
Message-ID: <20031021182555.GI18749@bunkus.org>

Hi.

> Ok, I'll call it 'KaxContentEncodings' (notice the 's' ;)) and move
> everything one level down.

Committed to both libmatroska and the specs web page.

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


From steve.lhomme at free.fr  Tue Oct 21 21:01:20 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Tue, 21 Oct 2003 21:01:20 +0200
Subject: [Matroska-devel] new content encoding elements
In-Reply-To: <20031021182555.GI18749@bunkus.org>
References: <20031019161005.GO1806@bunkus.org>
	<3F92D4BC.70009@free.fr>	<20031021144409.GC18749@bunkus.org>
	<3F955A54.9060804@free.fr>	<20031021175107.GH18749@bunkus.org>
	<20031021182555.GI18749@bunkus.org>
Message-ID: <3F958280.3020500@free.fr>

Moritz Bunkus wrote:
> Hi.
> 
> 
>>Ok, I'll call it 'KaxContentEncodings' (notice the 's' ;)) and move
>>everything one level down.
> 
> 
> Committed to both libmatroska and the specs web page.

OK, I agree with all the rest too.

I'm going to update the lacing stuff tonight.



From steve.lhomme at free.fr  Wed Oct 22 12:19:14 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Wed, 22 Oct 2003 12:19:14 +0200
Subject: [Matroska-devel] New lacing
Message-ID: <3F9659A2.9070807@free.fr>

Here is the second part of the new lacing handling. As I can't commit to 
CVS from here, I put the source in zip here.

Read & Write of different lacing methods is now supported, although it 
needs more testing (with various sizes/methods).

I will later update some more code in EbmlElement to use the new 
functions and optimize speed a bit.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lacing-read.zip
Type: application/zip
Size: 15897 bytes
Desc: not available
URL: <http://lists.matroska.org/pipermail/matroska-devel/attachments/20031022/fda43dc9/attachment.zip>

From paul at msn.com  Wed Oct 22 16:19:46 2003
From: paul at msn.com (Pamel)
Date: Wed, 22 Oct 2003 09:19:46 -0500
Subject: [Matroska-devel] Re: New lacing
References: <3F9659A2.9070807@free.fr>
Message-ID: <bn63m0$tod$1@sea.gmane.org>

"Steve Lhomme" <steve.lhomme at free.fr> wrote...
> Here is the second part of the new lacing handling. As I can't commit to
> CVS from here, I put the source in zip here.

I went ahead and committed it to CVS.  I'm sure that for generations to come
people will wonder why in the world Pamel would be committing something to
libmatroska.


Pamel





From steve.lhomme at free.fr  Wed Oct 22 16:24:21 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Wed, 22 Oct 2003 16:24:21 +0200
Subject: [Matroska-devel] Re: New lacing
In-Reply-To: <bn63m0$tod$1@sea.gmane.org>
References: <3F9659A2.9070807@free.fr> <bn63m0$tod$1@sea.gmane.org>
Message-ID: <3F969315.6040105@free.fr>

Pamel wrote:
> "Steve Lhomme" <steve.lhomme at free.fr> wrote...
> 
>>Here is the second part of the new lacing handling. As I can't commit to
>>CVS from here, I put the source in zip here.
> 
> 
> I went ahead and committed it to CVS.  I'm sure that for generations to come
> people will wonder why in the world Pamel would be committing something to
> libmatroska.

LOL.
Later you can show the CVS log to your kids !



From suiryc at yahoo.com  Wed Oct 22 18:17:34 2003
From: suiryc at yahoo.com (Cyrius)
Date: Wed, 22 Oct 2003 09:17:34 -0700 (PDT)
Subject: [Matroska-devel] Element order in EBML/libebml
In-Reply-To: <3F955154.3030700@free.fr>
Message-ID: <20031022161734.62195.qmail@web12904.mail.yahoo.com>

--- Steve Lhomme <steve.lhomme at free.fr> wrote:
> Moritz Bunkus wrote:
> > What this means is that what we already do is the
> Right Way to do
> > things. We should just formalize it. We should not
> have to add an
> > element to each block group describing its
> position in the Great Scheme
> > of Things. It would create a HUGE overhead, and it
> would make us the
> > laughing stock of the whole multimedia industry.
> 
> I agree, because in the end noone is going to
> reorder a file before 
> playing it back... And noone is going to produce a
> "damaged" file when 
> order is b0rked...

Ah, finally we come to a common conclusion :)

__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com


From chris at matroska.org  Fri Oct 24 15:59:17 2003
From: chris at matroska.org (Christian HJ Wiesner)
Date: Fri, 24 Oct 2003 15:59:17 +0200
Subject: [Matroska-devel] USF : Universal Subtitles Standard - Improved
 hardware support with EBML muxing ?
Message-ID: <3F993035.2060402@matroska.org>


Hi all,

we had some discussion about how to put USF ( http://usf.corecodec.org ) 
into matroska the best way today. Two ways were discussed :

1. Leave USF in XML Form, as its coming out from the two existing USF 
editors from unmei and kovacsendre. The XML will be stored in a matroska 
block, with timestamp and duration, just like SRT and SSA.

2. Convert USF XML into USF EBML. This would save the XML parser for 
hardware  players, which is possible in principal, but can limit adaption.

To use 2. would obviously require a lot more work from the devs, Toff 
said we had to map about 80 tags to EBML IDs. I was filing a job 
proposal on sourceforge today, asking for a learner in C who wanted to 
look at the job, lets see if somebody will answer.

In the meantime, i want opinions please.

@Stefan Andersen : you were mentioning on IRC that your hardware players 
have a XML lib already ? I guess it would be no limitation for you if 
left USF as it is, being XML ?

Christian
matroska project admin

BTW : I learned from kovacsendre that his USF editor has a SSA parser 
already, and can convert SSA to USF since some time already, preserving 
most of the advanced functions ;) ...
BTW2 : Please use the 'reply all' function of your mail client when replying



From moritz at bunkus.org  Sat Oct 25 00:05:48 2003
From: moritz at bunkus.org (Moritz Bunkus)
Date: Sat, 25 Oct 2003 00:05:48 +0200
Subject: [Matroska-devel] New lacing
In-Reply-To: <3F9659A2.9070807@free.fr>
References: <3F9659A2.9070807@free.fr>
Message-ID: <20031024220548.GG2961@bunkus.org>

Hi.

> Read & Write of different lacing methods is now supported, although it
> needs more testing (with various sizes/methods).

I've done a lot of coding/bug hunting/bug fixing tonight. I've
implemented LACING_AUTO and fixed a couple of bugs you had produced in
your new lacing code (and already committed it to CVS). LACING_AUTO will
chose the best lacing method for each block automatically (Xiph, Ebml of
fixed). If Xiph and Ebml are equally small then Ebml is chosen ;)

Some numbers:

1) Source is a 800MB OGM file (one video track, one Vorbis track). Small
   Vorbis packets let me expect that Xiph will be used rather often.

   Results (number of times a specific scheme was chosen for a block):
   lacing: fixed: 42, xiph: 41350, ebml: 3751

   File sizes:
   823805473 v-newauto.mkv
   823805654 v-old.mkv

   A very, very small gain only (181 bytes).

2) Source is a 700MB AVI (one video track, one VBR MP3 track). VBR means
   different packet sizes, so fixed won't be used too often, but packets
   are so big that Xiph will be inefficient most of the time.

   Results:
   lacing: fixed: 1261, xiph: 15, ebml: 23407

   File sizes:
   730793618 v2-newauto.mkv
   730922201 v2-old.mkv

   A more substantial gain (128583 bytes).

3) Source is a 350MB AVI (one video track, one AC3 track). As AC3 is CBR
   we should be able to have a lot of, or only, fixed lacing situations.

   Results:
   lacing: fixed: 11559, xiph: 0, ebml: 0
   Bingo! :)

   File sizes:
   364724855 v3-newauto.mkv
   365042724 v3-old.mkv

   Definitely a substantial gain (317869 bytes).

Summary: LACING_AUTO is the winner. The CLEAR winner :)

Note: This code needs testing!

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


From steve.lhomme at free.fr  Sat Oct 25 10:50:36 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Sat, 25 Oct 2003 10:50:36 +0200
Subject: [Matroska-devel] New lacing
In-Reply-To: <20031024220548.GG2961@bunkus.org>
References: <3F9659A2.9070807@free.fr> <20031024220548.GG2961@bunkus.org>
Message-ID: <3F9A395C.8090601@free.fr>

Moritz Bunkus wrote:
> Hi.
> 
> 
>>Read & Write of different lacing methods is now supported, although it
>>needs more testing (with various sizes/methods).
> 
> 
> I've done a lot of coding/bug hunting/bug fixing tonight. I've
> implemented LACING_AUTO and fixed a couple of bugs you had produced in
> your new lacing code (and already committed it to CVS). LACING_AUTO will
> chose the best lacing method for each block automatically (Xiph, Ebml of
> fixed). If Xiph and Ebml are equally small then Ebml is chosen ;)
> 
> Some numbers:
> 
> 1) Source is a 800MB OGM file (one video track, one Vorbis track). Small
>    Vorbis packets let me expect that Xiph will be used rather often.
> 
>    A very, very small gain only (181 bytes).
> 
> 2) Source is a 700MB AVI (one video track, one VBR MP3 track). VBR means
>    different packet sizes, so fixed won't be used too often, but packets
>    are so big that Xiph will be inefficient most of the time.
> 
>    A more substantial gain (128583 bytes).
> 
> 3) Source is a 350MB AVI (one video track, one AC3 track). As AC3 is CBR
>    we should be able to have a lot of, or only, fixed lacing situations.
> 
>    Definitely a substantial gain (317869 bytes).
> 
> Summary: LACING_AUTO is the winner. The CLEAR winner :)
> 
> Note: This code needs testing!

Wonderful work, as usual !!! These gains should be enough to convince 
people to update their tools.

I was going to implement it later. Now I'm going to improve the 
EBML-coded-size decoding, as it currently doesn't allow SizeUnknown. 
When it will I'll modify FindNextElement() and FindNextID() to use it.

Also the good thing is that these routines are in C so could be used in 
an EBML C library or any other code (like Gabest's muxer/demuxer).



From moritz at bunkus.org  Sat Oct 25 13:06:41 2003
From: moritz at bunkus.org (Moritz Bunkus)
Date: Sat, 25 Oct 2003 13:06:41 +0200
Subject: [Matroska-devel] New lacing
In-Reply-To: <3F9A395C.8090601@free.fr>
References: <3F9659A2.9070807@free.fr> <20031024220548.GG2961@bunkus.org>
	<3F9A395C.8090601@free.fr>
Message-ID: <20031025110640.GJ2961@bunkus.org>

Hi.

> Wonderful work, as usual !!! These gains should be enough to convince 
> people to update their tools.

Hmm, there is still a bug in that code - the timecodes are borked
somehow. I'll investigate.

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


From moritz at bunkus.org  Sat Oct 25 14:05:53 2003
From: moritz at bunkus.org (Moritz Bunkus)
Date: Sat, 25 Oct 2003 14:05:53 +0200
Subject: [Matroska-devel] New lacing
In-Reply-To: <20031025110640.GJ2961@bunkus.org>
References: <3F9659A2.9070807@free.fr> <20031024220548.GG2961@bunkus.org>
	<3F9A395C.8090601@free.fr> <20031025110640.GJ2961@bunkus.org>
Message-ID: <20031025120553.GK2961@bunkus.org>

Hi.

> Hmm, there is still a bug in that code - the timecodes are borked
> somehow. I'll investigate.

Forget it, wasn't a bug but an older version of the lib lying around
somewhere on my system that produced these funky results.

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


From chris at matroska.org  Mon Oct 27 11:34:38 2003
From: chris at matroska.org (Christian HJ Wiesner)
Date: Mon, 27 Oct 2003 11:34:38 +0100
Subject: [Matroska-devel] GPAC opensource Menue System based on MPEG4
	standards
In-Reply-To: <3F6CB89E.7070106@matroska.org>
References: <3F6CB89E.7070106@matroska.org>
Message-ID: <3F9CF4BE.9080804@matroska.org>

Hi,

about menues in MP4 and MKV please read here and comment :

http://forum.doom9.org/showthread.php?s=&postid=391219#post391219

Christian

Christian HJ Wiesner wrote:

>
> http://gpac.sourceforge.net/
>
> http://www.comelec.enst.fr/osmo4/#samples
>
> Seems that MP4 container is not as limited as we thought :( ....
>
> Christian
>
>
> _______________________________________________
> Matroska-devel mailing list
> Matroska-devel at lists.matroska.org
> http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel
>




From SEILF at hta-bi.bfh.ch  Tue Oct 28 09:08:09 2003
From: SEILF at hta-bi.bfh.ch (Seiler Fabien)
Date: Tue, 28 Oct 2003 09:08:09 +0100
Subject: [Matroska-devel] Re: USF : Universal Subtitles Standard - Improved
	hardware support with EBML muxing ?
Message-ID: <1067328489.ba16f240SEILF@hta-bi.bfh.ch>

I was "absent" for a month now, because i first had pre-diploma exams, then i moved and at my new address i don't have intenet upto now (they have to install new cables in the house before i can use my cable modem :((( this could be done in the next two week , i hope) 

..so, i'm completely uninformed.. but still, i continued to code on u96, but i haven't uploaded recent builds.  

About which form to use for muxing, i don't have a preference. For sole PC use i see no problem in the XML approach and i guess the size would not be considerably bigger than in EBML format. In my experience, USF files are 20-50% bigger than the same content in "full"* SSA .. i guess EBML USF would be about 50% the size of XML USF, but as we talk about maybe 50-100 vs. 25-50 KB this is not really important IMHO. 
On the other side i understand very well it is not very good if a hardware device needs a XML parser just for USF subtitles ... 

*
(SSA can omit "attributes" decreasing its size by about 50% , but this feature is not supported by any of Gabest's parsers (VobSub, VSfilter) and U96 might be the only app beside Sub Station Alpha itself that supports it)

If the decision goes to EBML USF, i guess i would have to provide a export function, writing a *.mks file with pre-EBMLed USF, but i have not looked into EBML/Matroska structure at all and i most probably would need extensive help from the experienced matroska coders -even if it's only to use the libebml, libmatroska properly ;). Well, i am not opposed to the EBML variant, i just fear the work it would imply for me :P

I could also imagine allowing both formats. At least for a first time (test phase). Once a PC based parser would know both formats it is obviously it can map the tags xml<->ebml - This would later enable us to restrict the specs to EBML format only and this parser could be used in a transitional time to convert those files muxed with xml to EBML format. IF both formats are allowed for some time AND a later restriction is planned THEN the test phase allowing both should be short to avoid too many users creating files they have to convert later (or only releasing the muxer over IRC or hiding one format, like mkvmerge only supporting through CLI not in MMG or similar solution).

This approach is not very straight forward, but if there is no one who can give really convincing arguments for or against one of the formats, it could be desirable to evaluate both methods to gain experience which dis-/advantages each format has.

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

One thing i wait for is embedded files (base 64 encoded). I support the SSA file embedding by now and adding support for base 64 is already coded, but without a spec i don't know in what tags i should write the encoded file :) - my suggestion were:

- a new root level node <embedded> (same level as the <styles>,<metadata>,<subtitles> but preferably the last node due to the potentially large size of the embedded data)

- inside <embedded> any number of <file> nodes. <file> should have a mandatory attribute "filename" or "name" and optinal attributes "size" and/or "rawsize" (encoded, decored size in bytes). The content of the <file> node is the base64 encoded file data.

DTD proposal (dont know if the synthax is correct, i don't have XML references at hand here in school): 

<!element USFSubtitles (..., embedded?, ...) >

<!element embedded (file*)>

<!element file  #CDATA> <!-- the CDATA is the base64 data -->
<!attribute filename string> <!-- should be marked mandatory -->
<!attribute size string> <!-- should be marked optional -->
<!attribute rawsize string> <!-- should be marked optional -->

Furthermore i would like to see effects and shapes defined sometime and a decicion whether to merge karaoke and text nodes or not. If no one is working/going to work on these i might work out a real (valid) "DTD proposal" for a next specifications draft once i completed and uploaded the new u96 version (this or next week?)

@Chris

>unmei, is the version here the most actual : 
>http://www.hta-bi.bfh.ch/~seilf/ ?? Do you have the >email adress from 
>Kovac Endre ?

sorry, i don't have the mail address of Endre and i haven't had contact with him for a long time already. (I didnt even know about his SSA support, which i btw can provide as well - ASS not yet but basic ASS could be implemented in a short time once i start it)

this is by far NOT the most recent version - heh you might have guessed from the date! - its july or august - right before i moved the project to corecodec. The most recent version should now always be on 

http://corecodec.org/projects/u96 

Still, this is at the moment a month old, i will upload a new build soon - through my school if i have to wait for internet much longer.

The next release already has the following new features over the current release (september, build 477):

-karaoke editor
-improved selection handling (set/copy/erase/move/attribute change/from OGM (text) and matroska (xml) chapters)
-image sequence generator
-undo (restore points)
-all the other things i forgot

-maybe more if i can't decide to release and keep adding new stuff any longer :p

unmei, u96 USF editor programmer



From christian at matroska.org  Tue Oct 28 02:14:10 2003
From: christian at matroska.org (ChristianHJW)
Date: Tue, 28 Oct 2003 02:14:10 +0100
Subject: [Matroska-devel] Re: Will VLC be the first player on win32 to
 support embedded vobsub's in MKV ?
In-Reply-To: <20031027224812.GA4804@hobbes>
References: <3F9C7F51.2020005@matroska.org> <20031027224812.GA4804@hobbes>
Message-ID: <3F9DC2E2.8010909@matroska.org>

Sigmund Augdal wrote:

>What exactly are vobsubs? Are those the kind of subtiles that are embedded
>in dvds? 
>
yes

>Since vlc supports those, it will probably be just a few lines to
>fix in the matroska demux to make it work. 
>
thats what i hope

>But I can't find any samples
>anywhere.
>  
>
I sent them to thedj ( hartman AT videolan.org  ) ... will resend the 
email to you now ...

Christian

>Sigmund
>
>On Mon, Oct 27, 2003 at 03:13:37AM +0100, ChristianHJW wrote:
>  
>
>>Guys,
>>
>>we have problems getting it to work on DirectShow without Gabest 
>>updating vsfilter, and the mplayer win32 builds seem to have a problem 
>>recently.
>>
>>I sent samples and Mosu's mplayer patch to thedj recently ... any idea 
>>if you can implement it ? It sucks to have a new, brilliant feature and 
>>only Linux people can play it :( ....
>>
>>Christian
>>matroska project admin
>>http://www.matroska.org
>>
>>-- 
>>This is the vlc-devel mailing-list, see http://www.videolan.org/vlc/
>>To unsubscribe, please read http://developers.videolan.org/lists.html
>>If you are in trouble, please contact <postmaster at videolan.org>
>>    
>>
>
>  
>




From sigmunau at stud.ntnu.no  Mon Oct 27 23:48:12 2003
From: sigmunau at stud.ntnu.no (Sigmund Augdal)
Date: Mon, 27 Oct 2003 23:48:12 +0100
Subject: [Matroska-devel] Re: Will VLC be the first player on win32 to
	support embedded vobsub's in MKV ?
In-Reply-To: <3F9C7F51.2020005@matroska.org>
References: <3F9C7F51.2020005@matroska.org>
Message-ID: <20031027224812.GA4804@hobbes>

What exactly are vobsubs? Are those the kind of subtiles that are embedded
in dvds? Since vlc supports those, it will probably be just a few lines to
fix in the matroska demux to make it work. But I can't find any samples
anywhere.

Sigmund

On Mon, Oct 27, 2003 at 03:13:37AM +0100, ChristianHJW wrote:
> 
> Guys,
> 
> we have problems getting it to work on DirectShow without Gabest 
> updating vsfilter, and the mplayer win32 builds seem to have a problem 
> recently.
> 
> I sent samples and Mosu's mplayer patch to thedj recently ... any idea 
> if you can implement it ? It sucks to have a new, brilliant feature and 
> only Linux people can play it :( ....
> 
> Christian
> matroska project admin
> http://www.matroska.org
> 
> -- 
> This is the vlc-devel mailing-list, see http://www.videolan.org/vlc/
> To unsubscribe, please read http://developers.videolan.org/lists.html
> If you are in trouble, please contact <postmaster at videolan.org>


From christian at matroska.org  Mon Oct 27 03:13:37 2003
From: christian at matroska.org (ChristianHJW)
Date: Mon, 27 Oct 2003 03:13:37 +0100
Subject: [Matroska-devel] Will VLC be the first player on win32 to support
 embedded vobsub's in MKV ?
Message-ID: <3F9C7F51.2020005@matroska.org>


Guys,

we have problems getting it to work on DirectShow without Gabest 
updating vsfilter, and the mplayer win32 builds seem to have a problem 
recently.

I sent samples and Mosu's mplayer patch to thedj recently ... any idea 
if you can implement it ? It sucks to have a new, brilliant feature and 
only Linux people can play it :( ....

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



From moritz at bunkus.org  Tue Oct 28 22:57:35 2003
From: moritz at bunkus.org (Moritz Bunkus)
Date: Tue, 28 Oct 2003 22:57:35 +0100
Subject: [Matroska-devel] VobSubs in Matroska
Message-ID: <20031028215735.GC13719@bunkus.org>

Hi.

Dnumgis from vlc was here tonight, and we talked about VobSubs. Seems
like that the normal VobSub file contains a MPEG program stream which in
turn contains the SPU packets we need. In mplayer's Matroska demuxer I
have a basic MPEG program stream parser.

After talking with Dnumgis I think that we should only store the SPU
packets as the MPEG program stream around them is not needed, produces
overhead and complicates things for no reason. So far no official tool
is available that can create VobSubs-in-Matroska so we're safe to change
it now.

Any objections?

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


From moritz at bunkus.org  Tue Oct 28 23:28:38 2003
From: moritz at bunkus.org (Moritz Bunkus)
Date: Tue, 28 Oct 2003 23:28:38 +0100
Subject: [Matroska-devel] libebml & libmatroska released
Message-ID: <20031028222838.GD13719@bunkus.org>

Notes:

- modified libebml/src/EbmlMaster to work with gcc 2.95
- updated debian/changelog in both libs
- removed the tag v070 from libmatroska and applied the correct tag v060

Uploaded both .tar.bz2 archives to matroska.free.fr and updated the
downloads page.

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


From chris at matroska.org  Wed Oct 29 00:16:54 2003
From: chris at matroska.org (Christian HJ Wiesner)
Date: Wed, 29 Oct 2003 00:16:54 +0100
Subject: [Matroska-devel] VobSubs in Matroska
In-Reply-To: <20031028215735.GC13719@bunkus.org>
References: <20031028215735.GC13719@bunkus.org>
Message-ID: <3F9EF8E6.5050603@matroska.org>

Moritz Bunkus wrote:

>Hi.
>
>Dnumgis from vlc was here tonight, and we talked about VobSubs. Seems
>like that the normal VobSub file contains a MPEG program stream which in
>turn contains the SPU packets we need. In mplayer's Matroska demuxer I
>have a basic MPEG program stream parser.
>
>After talking with Dnumgis I think that we should only store the SPU
>packets as the MPEG program stream around them is not needed, produces
>overhead and complicates things for no reason. So far no official tool
>is available that can create VobSubs-in-Matroska so we're safe to change
>it now.
>
>Any objections?
>
I agree, now is the time to make it right. Just some things :

- how big is the overhead introduced by the MPEG PS ?

- if we leave it like we have it now, will it be easier for other apps 
or hardware devices to support this with the MPEG PS ?

- when demuxing it from the MKV, can we restore the original .sub file ?

Christian



From moritz at bunkus.org  Wed Oct 29 08:56:03 2003
From: moritz at bunkus.org (Moritz Bunkus)
Date: Wed, 29 Oct 2003 08:56:03 +0100
Subject: [Matroska-devel] VobSubs in Matroska
In-Reply-To: <3F9EF8E6.5050603@matroska.org>
References: <20031028215735.GC13719@bunkus.org> <3F9EF8E6.5050603@matroska.org>
Message-ID: <20031029075603.GF13719@bunkus.org>

Hi.

> I agree, now is the time to make it right. Just some things :
> 
> - how big is the overhead introduced by the MPEG PS ?

Significant. In VobSubs, each block has a size that is a multiple of
2048 bytes. 32 are MPEG headers, 2 and the end some other stuff, and if
the SPU packet is smaller than the rest then filling is used. So the
overhead may be somewhere between 34 and a LOT more. Maybe I can give
you some figures for a VobSub tonight.

> - if we leave it like we have it now, will it be easier for other apps 
> or hardware devices to support this with the MPEG PS ?

No. Every Matroska demuxer would also need a basic MPEG PS demuxer in
order to get the SPU packets. Things like timestamp, track ID etc are
available from the Matroska container anyway.

> - when demuxing it from the MKV, can we restore the original .sub file
>   ?

Very likely, yes. Just recreate the MPEG PS stream. It will not be the
original stream but very close. Not original because the track ID is
stored in the stream and that one gets lost because we use our Matroska
track numbers, but that's a minor issue and not worth keeping the
overhead and complexity.

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


From christian at matroska.org  Wed Oct 29 13:49:28 2003
From: christian at matroska.org (ChristianHJW)
Date: Wed, 29 Oct 2003 13:49:28 +0100
Subject: [Matroska-devel] Re: Will VLC be the first player on win32 to
 support embedded vobsub's in MKV ?
In-Reply-To: <20031028112633.GA2139@hobbes>
References: <3F9C7F51.2020005@matroska.org> <20031027224812.GA4804@hobbes>
	<3F9DC2E2.8010909@matroska.org> <20031028112633.GA2139@hobbes>
Message-ID: <3F9FB758.4040804@matroska.org>


Thanks  Sigmund,

 for your precious input on this issue in our IRC channel yesterday. You 
suggested to demux the vobsub tracks from their MPEG Program Stream to 
save overhead and make the hadnling in VLC simpler. Here a copy of the 
channel log from this morning, self explaining i guess :

<MosuSleeping> chris: i'm off to uni now, but i managed to get the mpeg 
ps parser into mkvmerge
<MosuSleeping> results:
<MosuSleeping> overhead is about 69% (!)
<MosuSleeping> the overhead of mpeg ps + the buffer filling to the 2048 
byte boundaries

69% overhead reduction  !! This means we can now mux a vobsub track of 
about 4 MB into MKV with only 2 MB additional filesize for a complete 
track !

Thanks, we will provide you soon with new samples

Christian
matroska project admin

Sigmund Augdal wrote:

>>I sent them to thedj ( hartman AT videolan.org  ) ... will resend the 
>>email to you now ...
>>    
>>
>I got the links from thedj and gave it a little shot yesterday, but so far
>no go. Is there some extra packaging, or some special case for timing?
>Anyway, I'll have a look at the docs another day if not someone beat me to
>the goal.
>
>
>Sigmund
>
>  
>




From moritz at bunkus.org  Wed Oct 29 16:11:43 2003
From: moritz at bunkus.org (Moritz Bunkus)
Date: Wed, 29 Oct 2003 16:11:43 +0100
Subject: [Matroska-devel] VobSubs in Matroska
In-Reply-To: <20031029075603.GF13719@bunkus.org>
References: <20031028215735.GC13719@bunkus.org> <3F9EF8E6.5050603@matroska.org>
	<20031029075603.GF13719@bunkus.org>
Message-ID: <20031029151143.GI13719@bunkus.org>

Hi.

You want numbers? I'll give you some ;)

m.sub is the uncompressed source, m.rar the RAR compressed source

-rwxr--r--    1 mosu     vj        5838848 2003-09-21 11:39 vs/m.sub
-rw-r--r--    1 mosu     vj        1147820 2003-10-29 16:10 m.rar
-rw-r--r--    1 mosu     vj        4479392 2003-10-29 16:07 v-nocomp.mks
-rw-r--r--    1 mosu     vj        2102686 2003-10-29 16:07 v-zlib.mks

(We always knew we'd be bigger than the rar, nut this is a reduction to
36% which is VERY good IMHO.)

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


From moritz at bunkus.org  Wed Oct 29 19:26:50 2003
From: moritz at bunkus.org (Moritz Bunkus)
Date: Wed, 29 Oct 2003 19:26:50 +0100
Subject: [Matroska-devel] VobSubs in Matroska
In-Reply-To: <20031028215735.GC13719@bunkus.org>
References: <20031028215735.GC13719@bunkus.org>
Message-ID: <20031029182650.GJ13719@bunkus.org>

Hi.

> After talking with Dnumgis I think that we should only store the SPU
> packets as the MPEG program stream around them is not needed, produces
> overhead and complicates things for no reason.

This is now official: I've changed the specs and mkvmerge accordingly.

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


From sigmunau at stud.ntnu.no  Thu Oct 30 00:45:59 2003
From: sigmunau at stud.ntnu.no (Sigmund Augdal)
Date: Thu, 30 Oct 2003 00:45:59 +0100
Subject: [Matroska-devel] Re: Will VLC be the first player on win32 to
	support embedded vobsub's in MKV ?
In-Reply-To: <3F9C7F51.2020005@matroska.org>
References: <3F9C7F51.2020005@matroska.org>
Message-ID: <20031029234559.GA31915@hobbes>

I think I dare say yes to this. The patch to the mkv demux has just been
commited. The only file I've had to test this with, had some strange timing
issues ( with audio as well as subtitle track ), and the spu track had a
larger resolution than the actual video ( so I had to run "vlc --spumargin=1"
to keep the subtitles inside the video ).

These issues may need further adressing at a later point, but curious
persons could try a nightly build from
http://vthr.via.ecp.fr/~videolan/build/

in a day or two.

Sigmund Augdal


From spyder at matroska.org  Thu Oct 30 01:11:22 2003
From: spyder at matroska.org (spyder)
Date: Wed, 29 Oct 2003 18:11:22 -0600
Subject: [Matroska-devel] MPEG2 in MKV!
Message-ID: <E1AF0PM-00037W-00@scaup.mail.pas.earthlink.net>

Hi,

I finally finished this code and it seems to be working fine.  I am going to 
test in a second on a MPEG1 clip out of curiosity.  But reading mpeg2 seems 
fine.  I just need to implant this code in someone's muxer :)  Right now it 
tells a lot of details about the frames such as whether it's progressive, 
interlaced, pulldown-on-playback etc.

The problem is how to mux this.  I think the GOP header should go with the 
I-frame in a single block.  Also, there are repeated sequence headers before 
most GOPs.  We can stick these with the I frame as well.  The decoders should 
have no problem with this.  The frames are in coding order.  And the problem 
comes here:  Some frames in MPEG2 video actually decode to 2 frames on 
playback to produce a 3:2 pulldown.  I can detect these frames with my code 
but how do we timestamp them.  I will be on IRC tomorrow (Thursday) at aroun 
9am my time.  I think I am GMT-7 but not sure about that ;)

/me goes to check that mpeg1 stream.

IT WORKS!!!! W00T!!!!  MPEG1 is packetized too :O

John


From moritz at bunkus.org  Thu Oct 30 01:14:52 2003
From: moritz at bunkus.org (Moritz Bunkus)
Date: Thu, 30 Oct 2003 01:14:52 +0100
Subject: [Matroska-devel] Re: Will VLC be the first player on win32 to
	support embedded vobsub's in MKV ?
In-Reply-To: <20031029234559.GA31915@hobbes>
References: <3F9C7F51.2020005@matroska.org> <20031029234559.GA31915@hobbes>
Message-ID: <20031030001452.GK13719@bunkus.org>

Hi.

(After talking with him on IRC)

> The only file I've had to test this with, had some strange timing
> issues ( with audio as well as subtitle track ),

His audio issues are most likely due to the new lacing, and he hadn't
yet upgraded to the new library versions.

Update:
[.01:09:51.] < Dnumgis> fixed it!
[.01:09:53.] < Dnumgis> yess!

:)

> and the spu track had a larger resolution than the actual video ( so I
> had to run "vlc --spumargin=1" to keep the subtitles inside the video
> ).

Unfortunately this is normal for VObSubs. VobSubs are just extracted
from the DVD and not processed in any way. Therefore they retain the
full resolution while the usual encodes crop and/or scale the video. So
the strategy how to overlay the VobSub stream with the video depends a
bit on several factors, e.g. if the playback is fullscreen or not
etc. If not (windowed) then aligning the bottom of the subs with the
bottom of the video and centering the subs horizontally might work. But
I'm no expert.

Anyway, I'm really happy that VLC will support VobSubs in Matroska :)

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


From jcsston at toughguy.net  Thu Oct 30 03:01:15 2003
From: jcsston at toughguy.net (Jory)
Date: Wed, 29 Oct 2003 20:01:15 -0600
Subject: [Matroska-devel] MPEG2 in MKV!
References: <E1AF0PM-00037W-00@scaup.mail.pas.earthlink.net>
Message-ID: <000801c39e89$b5f89060$0200a8c0@jcsston>

W00T !!!
Now you can put MPEG-2 in MKV !!!

BTW GMT -6 is Central time zone ;) !!!

Jory !!!

/me wonders what is happening with his !!! key...
----- Original Message -----
From: "spyder" <spyder at matroska.org>
To: <matroska-devel at lists.matroska.org>
Sent: Wednesday, October 29, 2003 6:11 PM
Subject: [Matroska-devel] MPEG2 in MKV!


Hi,

I finally finished this code and it seems to be working fine.  I am going to
test in a second on a MPEG1 clip out of curiosity.  But reading mpeg2 seems
fine.  I just need to implant this code in someone's muxer :)  Right now it
tells a lot of details about the frames such as whether it's progressive,
interlaced, pulldown-on-playback etc.

The problem is how to mux this.  I think the GOP header should go with the
I-frame in a single block.  Also, there are repeated sequence headers before
most GOPs.  We can stick these with the I frame as well.  The decoders
should
have no problem with this.  The frames are in coding order.  And the problem
comes here:  Some frames in MPEG2 video actually decode to 2 frames on
playback to produce a 3:2 pulldown.  I can detect these frames with my code
but how do we timestamp them.  I will be on IRC tomorrow (Thursday) at aroun
9am my time.  I think I am GMT-7 but not sure about that ;)

/me goes to check that mpeg1 stream.

IT WORKS!!!! W00T!!!!  MPEG1 is packetized too :O

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




From chris at matroska.org  Thu Oct 30 06:07:43 2003
From: chris at matroska.org (Christian HJ Wiesner)
Date: Thu, 30 Oct 2003 06:07:43 +0100
Subject: [Matroska-devel] MPEG2 in MKV!
In-Reply-To: <E1AF0PM-00037W-00@scaup.mail.pas.earthlink.net>
References: <E1AF0PM-00037W-00@scaup.mail.pas.earthlink.net>
Message-ID: <3FA09C9F.4020800@matroska.org>


John,

congrats !!! It took you some time to make it, i know understanding the 
MPEG bitstream specs is not easy, but you always believed in that you 
can make it, and here you are !
About your questions :

spyder wrote:

>Hi,
>
>I finally finished this code and it seems to be working fine.  I am going to 
>test in a second on a MPEG1 clip out of curiosity.  But reading mpeg2 seems 
>fine.  I just need to implant this code in someone's muxer :)  Right now it 
>tells a lot of details about the frames such as whether it's progressive, 
>interlaced, pulldown-on-playback etc.
>
>The problem is how to mux this.  I think the GOP header should go with the 
>I-frame in a single block.
>
What are the alternatives ? Introducing a GOP element ? Could this maybe 
help for advanced editing ?

>  Also, there are repeated sequence headers before 
>most GOPs.  We can stick these with the I frame as well.
>
As above .... a sequence header element ? Do these have 'read-only' 
character or do they have to be modified on editing ?

>  The decoders should 
>have no problem with this.  The frames are in coding order.  And the problem 
>comes here:  Some frames in MPEG2 video actually decode to 2 frames on 
>playback to produce a 3:2 pulldown.  I can detect these frames with my code 
>but how do we timestamp them.
>
Timeslice ? What was the name of the feature again we introduced for 
handling of h.264 NALU's ?

>  I will be on IRC tomorrow (Thursday) at aroun 
>9am my time.  I think I am GMT-7 but not sure about that ;)
>  
>
I will soon be GMT +7 .... so we probably wont see each other on IRC for 
a while ;) ....

>/me goes to check that mpeg1 stream.
>IT WORKS!!!! W00T!!!!  MPEG1 is packetized too :O
>John
>
:) !   /me hugs John

Christian




From spyder at matroska.org  Thu Oct 30 06:15:57 2003
From: spyder at matroska.org (spyder)
Date: Wed, 29 Oct 2003 23:15:57 -0600
Subject: [Matroska-devel] MPEG2 in MKV!
In-Reply-To: <3FA09C9F.4020800@matroska.org>
References: <E1AF0PM-00037W-00@scaup.mail.pas.earthlink.net>
	<3FA09C9F.4020800@matroska.org>
Message-ID: <E1AF5A5-0004DK-00@albatross.mail.pas.earthlink.net>

On Wednesday 29 October 2003 23:07, Christian HJ Wiesner wrote:
> John,
>
> congrats !!! It took you some time to make it, i know understanding the
> MPEG bitstream specs is not easy, but you always believed in that you
> can make it, and here you are !
> About your questions :
>
> spyder wrote:
> >The problem is how to mux this.  I think the GOP header should go with the
> >I-frame in a single block.
>
> What are the alternatives ? Introducing a GOP element ? Could this maybe
> help for advanced editing ?

I don't think that's necessary.  The GOP header is only needed for the few 
frames that follow.  And it always comes before an I-frame by my 
understanding.  So basicly it's part of the I-frame IMO.

> >  Also, there are repeated sequence headers before
> >most GOPs.  We can stick these with the I frame as well.
>
> As above .... a sequence header element ? Do these have 'read-only'
> character or do they have to be modified on editing ?

The sequence header can have a few changed properties I think but nothing 
should be changed unless the actual encoding is.


> >  The decoders should
> >have no problem with this.  The frames are in coding order.  And the
> > problem comes here:  Some frames in MPEG2 video actually decode to 2
> > frames on playback to produce a 3:2 pulldown.  I can detect these frames
> > with my code but how do we timestamp them.
>
> Timeslice ? What was the name of the feature again we introduced for
> handling of h.264 NALU's ?

I don't know :P  This is where I am lost.  Mosu says he doesn't know either 
;)

John


From spyder at matroska.org  Thu Oct 30 08:06:03 2003
From: spyder at matroska.org (spyder)
Date: Thu, 30 Oct 2003 01:06:03 -0600
Subject: [Matroska-devel] MPEG2 in MKV!
In-Reply-To: <E1AF0PM-00037W-00@scaup.mail.pas.earthlink.net>
References: <E1AF0PM-00037W-00@scaup.mail.pas.earthlink.net>
Message-ID: <E1AF6sd-0006Gg-00@snipe.mail.pas.earthlink.net>

Okay, after some discussion with Pamel.  I think i found a solution that 
could work if the streams are all structured the same.

The repeat first field pulldown works like this:

You have 4 progressive frames, 1/6 of a second of 24fps video:
(r indicates the RFF flag is set)

[A] [B] [Cr] [Dr] 

which decodes into (uppercase = first field, lowercase = second field):

[Aa] [Bb] [Cc] [CD] [dD]

not the incorrect matching of the fields at the end and the increase in frame 
count to 30fps

I think we can make frame D have a double length duration to compensate for 
the time difference.  The decoder must receive frame D before it can create 
the extra frame so it must be frame D.  If a decoder wants to drop the 
pulldown, it can simply ignore the RFF flag and then only output one frame 
with a double duration or just output at 24fps assuming of course that there 
is no real interlaced content or the decoder will handle that itself.  In my 
samples, these RFF combinations occur in sequntial pairs.  So this method 
should work.  However, you could technically have:

[Ar] [B] [C] [Dr] -> [Aa] [AB] [bC] [cD] [Dd]

This makes a godawful mess but could happen.

So the way I see it, we do the following:
[{SequenceHeader}{GOPHeader}{I-Frame}] [P] [B] [B] ...

We set timecodes for the frame following the first RFF to double length.  The 
other timecodes are just normally computed using the framerate.

Ok, new problem...Pamel and I were discussing this and removing sections of 
an MPEG2 MKV file could produce erroneous files if you remove a sequence 
header that changed the quantizers in mid-stream which would make the rest of 
the file invalid.  We need a better way to store the sequence header or 
otherwise the overhead for storing the sequence headers with every GOP would 
be tremendous, a few hundred extra bytes per I frame.  The sequence header 
can change properties of the video stream so it must be written in the file 
and not just tucked away in codec private.

MPEG2 is one ugly codec.  It's very error resilient.  You don't even have to 
have the GOP headers it turns out.  And on top of that, you don't need I 
frames either...Of course, you can't expect perfect playback then ;)

John


From spyder at matroska.org  Thu Oct 30 08:20:15 2003
From: spyder at matroska.org (spyder)
Date: Thu, 30 Oct 2003 01:20:15 -0600
Subject: [Matroska-devel] MPEG2 in MKV!
In-Reply-To: <E1AF6sd-0006Gg-00@snipe.mail.pas.earthlink.net>
References: <E1AF0PM-00037W-00@scaup.mail.pas.earthlink.net>
	<E1AF6sd-0006Gg-00@snipe.mail.pas.earthlink.net>
Message-ID: <E1AF76N-0000Iy-00@snipe.mail.pas.earthlink.net>

On Thursday 30 October 2003 01:06, spyder wrote:
> We need a better way to store the sequence header or
> otherwise the overhead for storing the sequence headers with every GOP
> would be tremendous, a few hundred extra bytes per I frame.  

It's 150 bytes for a DVD sample I have here.  That could add up fast.

John


From chris at matroska.org  Thu Oct 30 10:21:10 2003
From: chris at matroska.org (Christian HJ Wiesner)
Date: Thu, 30 Oct 2003 10:21:10 +0100
Subject: [Matroska-devel] MPEG2 in MKV!
In-Reply-To: <E1AF6sd-0006Gg-00@snipe.mail.pas.earthlink.net>
References: <E1AF0PM-00037W-00@scaup.mail.pas.earthlink.net>
	<E1AF6sd-0006Gg-00@snipe.mail.pas.earthlink.net>
Message-ID: <3FA0D806.3010407@matroska.org>

spyder wrote:

>Ok, new problem...Pamel and I were discussing this and removing sections of 
>an MPEG2 MKV file could produce erroneous files if you remove a sequence 
>header that changed the quantizers in mid-stream which would make the rest of 
>the file invalid.  We need a better way to store the sequence header or 
>otherwise the overhead for storing the sequence headers with every GOP would 
>be tremendous, a few hundred extra bytes per I frame.  The sequence header 
>can change properties of the video stream so it must be written in the file 
>and not just tucked away in codec private.
>  
>
John,

i was recently pointed to the 'codec state' element that is already in 
the MKV specs, could this element be used to store the sequence headers 
maybe ? With 'codec state' , IIRC, the idea behind it was to be able to 
change the picture resolution, colourspace etc. during playback and 
within one video stream, without creating several streams and appending 
them. Only thing that couldnt be changed was the codec itself AFAIK. 
Basically, if the parser finds a 'codec state' element in the stream, it 
has to reinitialize the codec completely, dont know if its ever possible 
to play such a stream on DirectShow, maybe only if we finally implement 
a resizing filter into the splitter, dont know, the DShow experts to 
clarify please.

This leads me to another problem : you are aware that we can not make 
and release a MPEG2 decoder specifically for MPEG2 coming from MKV, do 
you ? Is there any chance to reproduce at least an MPEG2 Elementary 
Stream from the MPEG2 track in MKV, such that external existing decoders 
can play the stuff, like ffdshow etc. ? Please tell me its possible and 
you didnt forget that  :-) .....

Christian





From moritz at bunkus.org  Thu Oct 30 12:40:22 2003
From: moritz at bunkus.org (Moritz Bunkus)
Date: Thu, 30 Oct 2003 12:40:22 +0100
Subject: [Matroska-devel] libmatroska - AddFrame lacks default lacing type
Message-ID: <20031030114022.GQ13719@bunkus.org>

Hi,

Steve you forgot to set the default lacing type for the AddFrame calls
in KaxBlock.h. I thought we agreed that we should just make them '=
LACING_AUTO' which would not require changes to existing programs. So I
suppose we do that and release libmatroska 0.6.1 today.

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


From steve.lhomme at free.fr  Thu Oct 30 12:48:15 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Thu, 30 Oct 2003 12:48:15 +0100
Subject: [Matroska-devel] libmatroska - AddFrame lacks default lacing type
In-Reply-To: <20031030114022.GQ13719@bunkus.org>
References: <20031030114022.GQ13719@bunkus.org>
Message-ID: <3FA0FA7F.2040604@free.fr>

Moritz Bunkus wrote:

> Hi,
> 
> Steve you forgot to set the default lacing type for the AddFrame calls
> in KaxBlock.h. I thought we agreed that we should just make them '=
> LACING_AUTO' which would not require changes to existing programs. So I
> suppose we do that and release libmatroska 0.6.1 today.

Yes.
BTW now that you mention it, I think I forgot to add the thing you asked 
(which I'll check in the ML). I'll have a look tonight.

I also want to work on the "final" Matroska logo in Flash to have 
various resizable version with different colors. (Flash is great for 
that). I'll keep everyone informed.



From spyder at matroska.org  Thu Oct 30 16:59:41 2003
From: spyder at matroska.org (spyder)
Date: Thu, 30 Oct 2003 09:59:41 -0600
Subject: [Matroska-devel] MPEG2 in MKV!
In-Reply-To: <3FA0D806.3010407@matroska.org>
References: <E1AF0PM-00037W-00@scaup.mail.pas.earthlink.net>
	<E1AF6sd-0006Gg-00@snipe.mail.pas.earthlink.net>
	<3FA0D806.3010407@matroska.org>
Message-ID: <E1AFFD3-0006CA-00@harrier.mail.pas.earthlink.net>

> i was recently pointed to the 'codec state' element that is already in
> the MKV specs, could this element be used to store the sequence headers
> maybe ? With 'codec state' , IIRC, the idea behind it was to be able to
> change the picture resolution, colourspace etc. during playback and
> within one video stream, without creating several streams and appending
> them. Only thing that couldnt be changed was the codec itself AFAIK.
> Basically, if the parser finds a 'codec state' element in the stream, it
> has to reinitialize the codec completely, dont know if its ever possible
> to play such a stream on DirectShow, maybe only if we finally implement
> a resizing filter into the splitter, dont know, the DShow experts to
> clarify please.
>
> This leads me to another problem : you are aware that we can not make
> and release a MPEG2 decoder specifically for MPEG2 coming from MKV, do
> you ? Is there any chance to reproduce at least an MPEG2 Elementary
> Stream from the MPEG2 track in MKV, such that external existing decoders
> can play the stuff, like ffdshow etc. ? Please tell me its possible and
> you didnt forget that  :-) .....

Codec state should be what we are looking for I guess.  The codec won't have 
to be reinitialized though, only fed the new sequence header.  We weren't 
planning on making an MPEG2 decoder.  It should be able to be fed to any 
mpeg2 video decoder.  I am not sure exactly how those work but Gabest would 
know since MPC includes one ;) 


From paul at msn.com  Thu Oct 30 17:32:36 2003
From: paul at msn.com (Pamel)
Date: Thu, 30 Oct 2003 10:32:36 -0600
Subject: [Matroska-devel] Re: MPEG2 in MKV!
References: <E1AF0PM-00037W-00@scaup.mail.pas.earthlink.net>
Message-ID: <bnree1$8sq$1@sea.gmane.org>

So far we have two options for the Sequence Headers:

1. Store the sequence header inside the Block with every I frame.  If the
sequence header changes before a P frame, then store it with the P frame, and
every following I frame.

2. Use the CodecState element in Matroska which is what it is for.  The sequence
header will likely be repeated before every I frame anyway so this would take
two or three additional bytes as you have to store the EBML element and size.

Honestly the CodecState is more finesse, but I hate it.  There is no way to know
where a codec state is in a stream.  If you seek, then you are going to miss the
codec state and your decode will be screwed.  But if you put the codec state in
the track information, would it be any good for streaming?

The biggest problem is that the existing MPEG-2 decoders expect so much stuff
that it makes it hard to do things well.  If we tweaked existing MPEG-2
decoders, this would be a lot easier.  For instance, MPEG-2 decoders expect the
Sequence Headers as part of the stream, so even if it was in a seperate element
it would need to be just put into the stream for the MPEG-2 decoders.

I vote for option 1.  It may take an additional 150bytes per I frame in MPEG-2,
but in theory all of that is already in the stream so there shouldn't be any
additional bloat.


Pamel





From spyder at matroska.org  Thu Oct 30 17:59:46 2003
From: spyder at matroska.org (spyder)
Date: Thu, 30 Oct 2003 10:59:46 -0600
Subject: [Matroska-devel] Re: MPEG2 in MKV!
In-Reply-To: <bnree1$8sq$1@sea.gmane.org>
References: <E1AF0PM-00037W-00@scaup.mail.pas.earthlink.net>
	<bnree1$8sq$1@sea.gmane.org>
Message-ID: <E1AFG9B-0002AI-00@hawk.mail.pas.earthlink.net>

On Thursday 30 October 2003 10:32, Pamel wrote:
> So far we have two options for the Sequence Headers:
>
> 1. Store the sequence header inside the Block with every I frame.  If the
> sequence header changes before a P frame, then store it with the P frame,
> and every following I frame.
>
> 2. Use the CodecState element in Matroska which is what it is for.  The
> sequence header will likely be repeated before every I frame anyway so this
> would take two or three additional bytes as you have to store the EBML
> element and size.
>
> Honestly the CodecState is more finesse, but I hate it.  There is no way to
> know where a codec state is in a stream.  If you seek, then you are going
> to miss the codec state and your decode will be screwed.  But if you put
> the codec state in the track information, would it be any good for
> streaming?
>
> The biggest problem is that the existing MPEG-2 decoders expect so much
> stuff that it makes it hard to do things well.  If we tweaked existing
> MPEG-2 decoders, this would be a lot easier.  For instance, MPEG-2 decoders
> expect the Sequence Headers as part of the stream, so even if it was in a
> seperate element it would need to be just put into the stream for the
> MPEG-2 decoders.
>
> I vote for option 1.  It may take an additional 150bytes per I frame in
> MPEG-2, but in theory all of that is already in the stream so there
> shouldn't be any additional bloat.
>
>
> Pamel
 Agreed :)

John


From paul at msn.com  Thu Oct 30 18:02:38 2003
From: paul at msn.com (Pamel)
Date: Thu, 30 Oct 2003 11:02:38 -0600
Subject: [Matroska-devel] Re: MPEG2 in MKV!
References: <E1AF0PM-00037W-00@scaup.mail.pas.earthlink.net>
Message-ID: <bnrg6b$dmo$1@sea.gmane.org>

First a little description of what pulldown is.  If the RFF bit is set in the
sequence header then then this progressive sequence of frames:

[A][B][C][D]

will be decoded to an interlaced sequence where the first letter is the first
field and the second letter is the second field in the interlaced image.  A
single image is split so that the odd lines become the uppercase letter and the
even lines become the lowercase.  The third and fourth images are combined so
that the image sequence looks like this:

[Aa][Bb][Cc][CD][Dd]


There are two ways to handle the pulldown. You can store it like its stored in
MPEG-2, or you can 'fix' it an remove the pulldown.

1. Store the four frames with timecodes like you are going to store 5 frames.
The fourth frame will have a duration that is twice the duration of the other
frames.  This should leave space for the decoder to generate the extra frame.

2.  Forbid pulldown.  When transferring the frames into MKV, you set the RFF
flag to 0, change the framerate, and space the frames out for what actually
exists.

John pointed out that you shouldn't force people to use progressive, but I say
you can encourage them.  So, I vote that we have both methods as an option in
muxing tools.  The default should be option 2, but you could set option 1.


Pamel





From gabest at freemail.hu  Thu Oct 30 18:03:38 2003
From: gabest at freemail.hu (Gabest)
Date: Thu, 30 Oct 2003 18:03:38 +0100
Subject: [Matroska-devel] MPEG2 in MKV!
References: <E1AF0PM-00037W-00@scaup.mail.pas.earthlink.net><E1AF6sd-0006Gg-00@snipe.mail.pas.earthlink.net><3FA0D806.3010407@matroska.org>
	<E1AFFD3-0006CA-00@harrier.mail.pas.earthlink.net>
Message-ID: <02b101c39f07$c3970e30$0100a8c0@i2400p4>

> Codec state should be what we are looking for I guess.  The codec won't
have
> to be reinitialized though, only fed the new sequence header.  We weren't
> planning on making an MPEG2 decoder.  It should be able to be fed to any
> mpeg2 video decoder.  I am not sure exactly how those work but Gabest
would
> know since MPC includes one ;)

There is a sequence header in the format block of the connection media type
(MPEG1VIDEOINFO::bSequenceHeader, MPEG2VIDEOINFO::dwSequenceHeader), but it
is only there to pass the width/height/framerate to the decoder initially
(otherwise it wouldn't be able to create its own output media type). This
and the following sequence headers are present in the data stream, just like
all the other packet types, and they are better to be in the stream because
that's what the decoders expect already. So, if it was put into a
'codecstate' element, then the splitter would have to mix it into the data
stream, but only if the stream is mpeg and not in other cases. This sounds
very unclean to me.

Btw, if anyone has a downloadable sample of mkv with vobsub or mpeg inside,
I'd like to test them sometime in the weekend :)



From steve.lhomme at free.fr  Thu Oct 30 18:08:32 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Thu, 30 Oct 2003 18:08:32 +0100
Subject: [Matroska-devel] Re: MPEG2 in MKV!
In-Reply-To: <E1AFG9B-0002AI-00@hawk.mail.pas.earthlink.net>
References: <E1AF0PM-00037W-00@scaup.mail.pas.earthlink.net>	<bnree1$8sq$1@sea.gmane.org>
	<E1AFG9B-0002AI-00@hawk.mail.pas.earthlink.net>
Message-ID: <3FA14590.4080006@free.fr>

spyder wrote:

> On Thursday 30 October 2003 10:32, Pamel wrote:
> 
>>So far we have two options for the Sequence Headers:
>>
>>1. Store the sequence header inside the Block with every I frame.  If the
>>sequence header changes before a P frame, then store it with the P frame,
>>and every following I frame.
>>
>>2. Use the CodecState element in Matroska which is what it is for.  The
>>sequence header will likely be repeated before every I frame anyway so this
>>would take two or three additional bytes as you have to store the EBML
>>element and size.
>>
>>Honestly the CodecState is more finesse, but I hate it.  There is no way to
>>know where a codec state is in a stream.  If you seek, then you are going
>>to miss the codec state and your decode will be screwed.  But if you put
>>the codec state in the track information, would it be any good for
>>streaming?

What if the codec state is stored with every I frame ? (which makes a 
lot of sense)



From paul at msn.com  Thu Oct 30 18:13:50 2003
From: paul at msn.com (Pamel)
Date: Thu, 30 Oct 2003 11:13:50 -0600
Subject: [Matroska-devel] Re: MPEG2 in MKV!
References: <E1AF0PM-00037W-00@scaup.mail.pas.earthlink.net>
Message-ID: <bnrgrb$fhm$1@sea.gmane.org>

>From the way that I voted for things, this is how they would look.

Every I frame Block would look like this:

[sequence header][GOP(optional)][I frame]


Most P and B frames would only have a frame stored in their Block. The only
exception to this is if a sequence header changes before a P frame, then that
particular P frame's Block would look like this:

[sequence header][P frame]


If the RFF flag is set, then the second frame used in the pulldown will have a
duration that is twice the duration of the other frames.


The Codec-Private is left empty.


Pamel





From spyder at matroska.org  Thu Oct 30 18:21:53 2003
From: spyder at matroska.org (spyder)
Date: Thu, 30 Oct 2003 11:21:53 -0600
Subject: [Matroska-devel] MPEG2 in MKV!
In-Reply-To: <02b101c39f07$c3970e30$0100a8c0@i2400p4>
References: <E1AF0PM-00037W-00@scaup.mail.pas.earthlink.net>
	<E1AFFD3-0006CA-00@harrier.mail.pas.earthlink.net>
	<02b101c39f07$c3970e30$0100a8c0@i2400p4>
Message-ID: <E1AFGUa-0001QI-00@hawk.mail.pas.earthlink.net>

> Btw, if anyone has a downloadable sample of mkv with vobsub or mpeg inside,
> I'd like to test them sometime in the weekend :)
We have no muxer for mpeg yet.  :/  My mpeg video parser handles both mpeg1 
and 2 if you are interested :)  It should be useable in your DS filter as it 
merely buffers data until you can pull a frame.

John

PS: you made a big mistake, we can't think you are dead anymore :P  Christian 
will be all over you :P


From paul at msn.com  Thu Oct 30 18:26:05 2003
From: paul at msn.com (Pamel)
Date: Thu, 30 Oct 2003 11:26:05 -0600
Subject: [Matroska-devel] Re: MPEG2 in MKV!
References: <E1AF0PM-00037W-00@scaup.mail.pas.earthlink.net><E1AF6sd-0006Gg-00@snipe.mail.pas.earthlink.net><3FA0D806.3010407@matroska.org><E1AFFD3-0006CA-00@harrier.mail.pas.earthlink.net>
	<02b101c39f07$c3970e30$0100a8c0@i2400p4>
Message-ID: <bnrhib$hg5$1@sea.gmane.org>

"Gabest" wrote...
> There is a sequence header in the format block of the connection media type
> (MPEG1VIDEOINFO::bSequenceHeader, MPEG2VIDEOINFO::dwSequenceHeader), but it
> is only there to pass the width/height/framerate to the decoder initially
> (otherwise it wouldn't be able to create its own output media type). This
> and the following sequence headers are present in the data stream, just like
> all the other packet types, and they are better to be in the stream because
> that's what the decoders expect already. So, if it was put into a
> 'codecstate' element, then the splitter would have to mix it into the data
> stream, but only if the stream is mpeg and not in other cases. This sounds
> very unclean to me.

You are quite correct.

> Btw, if anyone has a downloadable sample of mkv with vobsub or mpeg inside,
> I'd like to test them sometime in the weekend :)

Here is a file that contains the old design.  I think they just changed it so
that the MPEG headers are stripped and only the image data is left.  I think
Mosu could make you a new one.
http://haali.cs.msu.ru/vsshort-foreignvobsubs-uncomp.mkv

BTW, good to see you are alive.  :)


Pamel





From spyder at matroska.org  Thu Oct 30 18:29:29 2003
From: spyder at matroska.org (spyder)
Date: Thu, 30 Oct 2003 11:29:29 -0600
Subject: [Matroska-devel] Re: MPEG2 in MKV!
In-Reply-To: <bnrg6b$dmo$1@sea.gmane.org>
References: <E1AF0PM-00037W-00@scaup.mail.pas.earthlink.net>
	<bnrg6b$dmo$1@sea.gmane.org>
Message-ID: <E1AFGbw-0003nO-00@hawk.mail.pas.earthlink.net>

>The third and fourth
> images are combined so that the image sequence looks like this:
>
> [Aa][Bb][Cc][CD][Dd]

Ummm, RFF repeats the first field last ie, in 121 order. not 112. :P

Your output sequence would be:
[Aa] [Bb] [Cc] [CD] [dD]

Check a dvd video decoded without force-film, the 4th and 5th frames are 
combed.

>
>
> There are two ways to handle the pulldown. You can store it like its stored
> in MPEG-2, or you can 'fix' it an remove the pulldown.

Bad idea to remove the pulldown.  MPEG decoders expect constant framerate and 
you can't change the framerate to 24fps becasue you would need to drop some 
frames which would break the encoding scheme of mpeg2.  (ie, removing data 
referenced by other frames)

>
> 1. Store the four frames with timecodes like you are going to store 5
> frames. The fourth frame will have a duration that is twice the duration of
> the other frames.  This should leave space for the decoder to generate the
> extra frame.

Yes.  i agree with this.

> 2.  Forbid pulldown.  When transferring the frames into MKV, you set the
> RFF flag to 0, change the framerate, and space the frames out for what
> actually exists.

NO NO NO NO NO NO

> John pointed out that you shouldn't force people to use progressive, but I
> say you can encourage them.  So, I vote that we have both methods as an
> option in muxing tools.  The default should be option 2, but you could set
> option 1.

See above :P


John


From moritz at bunkus.org  Thu Oct 30 18:32:09 2003
From: moritz at bunkus.org (Moritz Bunkus)
Date: Thu, 30 Oct 2003 18:32:09 +0100
Subject: [Matroska-devel] Re: MPEG2 in MKV!
In-Reply-To: <bnrhib$hg5$1@sea.gmane.org>
References: <02b101c39f07$c3970e30$0100a8c0@i2400p4>
	<bnrhib$hg5$1@sea.gmane.org>
Message-ID: <20031030173209.GB13719@bunkus.org>

Hi.

Good to see you, Gabest.

> http://haali.cs.msu.ru/vsshort-foreignvobsubs-uncomp.mkv

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

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


From spyder at matroska.org  Thu Oct 30 18:36:04 2003
From: spyder at matroska.org (spyder)
Date: Thu, 30 Oct 2003 11:36:04 -0600
Subject: [Matroska-devel] Re: MPEG2 in MKV!
In-Reply-To: <3FA14590.4080006@free.fr>
References: <E1AF0PM-00037W-00@scaup.mail.pas.earthlink.net>
	<E1AFG9B-0002AI-00@hawk.mail.pas.earthlink.net>
	<3FA14590.4080006@free.fr>
Message-ID: <E1AFGiJ-0005jn-00@hawk.mail.pas.earthlink.net>

> What if the codec state is stored with every I frame ? (which makes a
> lot of sense)
Could make sense but I agree with Gabest, they should just go in the actual 
frame data.


From moritz at bunkus.org  Thu Oct 30 18:39:14 2003
From: moritz at bunkus.org (Moritz Bunkus)
Date: Thu, 30 Oct 2003 18:39:14 +0100
Subject: [Matroska-devel] libmatroska - AddFrame lacks default lacing type
In-Reply-To: <3FA0FA7F.2040604@free.fr>
References: <20031030114022.GQ13719@bunkus.org> <3FA0FA7F.2040604@free.fr>
Message-ID: <20031030173914.GC13719@bunkus.org>

Hi.

> Yes.

Ok, I've already updated KaxVersion.h (and the debian subdir) to 0.6.1
and added default values for AddFrame() in KaxBlock.h. So commit what
you have to, then tag and release :)

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


From steve.lhomme at free.fr  Thu Oct 30 18:42:19 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Thu, 30 Oct 2003 18:42:19 +0100
Subject: [Matroska-devel] Re: MPEG2 in MKV!
In-Reply-To: <E1AFGiJ-0005jn-00@hawk.mail.pas.earthlink.net>
References: <E1AF0PM-00037W-00@scaup.mail.pas.earthlink.net>	<E1AFG9B-0002AI-00@hawk.mail.pas.earthlink.net>	<3FA14590.4080006@free.fr>
	<E1AFGiJ-0005jn-00@hawk.mail.pas.earthlink.net>
Message-ID: <3FA14D7B.3070807@free.fr>

spyder wrote:

>>What if the codec state is stored with every I frame ? (which makes a
>>lot of sense)
> 
> Could make sense but I agree with Gabest, they should just go in the actual 
> frame data.

Only if the I-frame can't be decoded without it.



From spyder at matroska.org  Thu Oct 30 18:42:42 2003
From: spyder at matroska.org (spyder)
Date: Thu, 30 Oct 2003 11:42:42 -0600
Subject: [Matroska-devel] Re: MPEG2 in MKV!
In-Reply-To: <3FA14D7B.3070807@free.fr>
References: <E1AF0PM-00037W-00@scaup.mail.pas.earthlink.net>
	<E1AFGiJ-0005jn-00@hawk.mail.pas.earthlink.net>
	<3FA14D7B.3070807@free.fr>
Message-ID: <E1AFGoj-0007nb-00@hawk.mail.pas.earthlink.net>

On Thursday 30 October 2003 11:42, you wrote:
> spyder wrote:
> >>What if the codec state is stored with every I frame ? (which makes a
> >>lot of sense)
> >
> > Could make sense but I agree with Gabest, they should just go in the
> > actual frame data.
>
> Only if the I-frame can't be decoded without it.

Well, we can check to see if it's a duplicate to the previous one iw which 
case we can remove it if you want.  Otherwise it must be there for the 
decoder to decode as it changes quantizers(the only thing that can change 
from header to header).

John


From paul at msn.com  Thu Oct 30 18:51:20 2003
From: paul at msn.com (Pamel)
Date: Thu, 30 Oct 2003 11:51:20 -0600
Subject: [Matroska-devel] Re: Re: MPEG2 in MKV!
References: <E1AF0PM-00037W-00@scaup.mail.pas.earthlink.net><bnrg6b$dmo$1@sea.gmane.org>
	<E1AFGbw-0003nO-00@hawk.mail.pas.earthlink.net>
Message-ID: <bnrj1l$l3h$1@sea.gmane.org>

"spyder" <spyder at matroska.org> wrote...
>> [Aa][Bb][Cc][CD][Dd]
> Ummm, RFF repeats the first field last ie, in 121 order. not 112. :P
> Your output sequence would be:
> [Aa] [Bb] [Cc] [CD] [dD]

I copied and pasted what you put in IRC.
[00:11] <spyder482> here's the way it actually works according to mpeg docs:
[00:12] <spyder482> [A][B][Cr][Dr] yields [Aa][Bb][Cc][CD][Dd] on decode


>> There are two ways to handle the pulldown. You can store it like its stored
>> in MPEG-2, or you can 'fix' it an remove the pulldown.

> Bad idea to remove the pulldown.  MPEG decoders expect constant framerate and
> you can't change the framerate to 24fps becasue you would need to drop some
> frames which would break the encoding scheme of mpeg2.  (ie, removing data
> referenced by other frames)

We just need to change to framerate as specified in the Sequence headers.


Pamel





From spyder at matroska.org  Thu Oct 30 18:56:25 2003
From: spyder at matroska.org (spyder)
Date: Thu, 30 Oct 2003 11:56:25 -0600
Subject: [Matroska-devel] Re: Re: MPEG2 in MKV!
In-Reply-To: <bnrj1l$l3h$1@sea.gmane.org>
References: <E1AF0PM-00037W-00@scaup.mail.pas.earthlink.net>
	<E1AFGbw-0003nO-00@hawk.mail.pas.earthlink.net>
	<bnrj1l$l3h$1@sea.gmane.org>
Message-ID: <E1AFH2X-0006Fh-00@harrier.mail.pas.earthlink.net>

> I copied and pasted what you put in IRC.
> [00:11] <spyder482> here's the way it actually works according to mpeg
> docs: [00:12] <spyder482> [A][B][Cr][Dr] yields [Aa][Bb][Cc][CD][Dd] on
> decode

Then I was wrong :P

> > Bad idea to remove the pulldown.  MPEG decoders expect constant framerate
> > and you can't change the framerate to 24fps becasue you would need to
> > drop some frames which would break the encoding scheme of mpeg2.  (ie,
> > removing data referenced by other frames)
>
> We just need to change to framerate as specified in the Sequence headers.

No...then you introduce sync errors.  Not all files will be played in crappy 
DirectShow filters.  MPEG video has a framerate for a reason, it's not just 
informational.  If you change the framerate but leave more frames then you 
intorduce sync problems.  If you drop the extra frames then you break the 
stream.  Besides, we shouldn't have to destroy any mpeg compliance just to 
put the stream in MKV.  As I said before, the ONLY thing allowed to change 
from sequence header to sequence header is the QUANTIZERS!  You can't change 
framerate, resolution, colorspace, progressive vs. interlaced etc..  Only 
those 128 bytes for the quantizer are allowed to change.  Otherwise the 
stream is b0rked and no longer spec compliant.

John


From spyder at matroska.org  Thu Oct 30 19:39:21 2003
From: spyder at matroska.org (spyder)
Date: Thu, 30 Oct 2003 12:39:21 -0600
Subject: [Matroska-devel] Re: MPEG2 in MKV!
In-Reply-To: <bnrgrb$fhm$1@sea.gmane.org>
References: <E1AF0PM-00037W-00@scaup.mail.pas.earthlink.net>
	<bnrgrb$fhm$1@sea.gmane.org>
Message-ID: <E1AFHhY-0002LM-00@flamingo.mail.pas.earthlink.net>

> From the way that I voted for things, this is how they would look.
>
> Every I frame Block would look like this:
>
> [sequence header][GOP(optional)][I frame]
>
>
> Most P and B frames would only have a frame stored in their Block. The only
> exception to this is if a sequence header changes before a P frame, then
> that particular P frame's Block would look like this:
>
> [sequence header][P frame]
>
>
> If the RFF flag is set, then the second frame used in the pulldown will
> have a duration that is twice the duration of the other frames.
>
>
> The Codec-Private is left empty.

We can place one sequence header in codec private maybe.  All else is ok.


From paul at msn.com  Thu Oct 30 19:48:06 2003
From: paul at msn.com (Pamel)
Date: Thu, 30 Oct 2003 12:48:06 -0600
Subject: [Matroska-devel] Re: Re: MPEG2 in MKV!
References: <E1AF0PM-00037W-00@scaup.mail.pas.earthlink.net><bnrgrb$fhm$1@sea.gmane.org>
	<E1AFHhY-0002LM-00@flamingo.mail.pas.earthlink.net>
Message-ID: <bnrmc3$vhm$1@sea.gmane.org>

"spyder" wrote...
>> The Codec-Private is left empty.
> We can place one sequence header in codec private maybe.  All else is ok.

I agree, but I think it should be optional.  On by default.


Pamel





From spyder at matroska.org  Thu Oct 30 19:51:03 2003
From: spyder at matroska.org (spyder)
Date: Thu, 30 Oct 2003 12:51:03 -0600
Subject: [Matroska-devel] Re: Re: MPEG2 in MKV!
In-Reply-To: <bnrmc3$vhm$1@sea.gmane.org>
References: <E1AF0PM-00037W-00@scaup.mail.pas.earthlink.net>
	<E1AFHhY-0002LM-00@flamingo.mail.pas.earthlink.net>
	<bnrmc3$vhm$1@sea.gmane.org>
Message-ID: <E1AFHt3-0005Ii-00@flamingo.mail.pas.earthlink.net>

On Thursday 30 October 2003 12:48, you wrote:
> "spyder" wrote...
>
> >> The Codec-Private is left empty.
> >
> > We can place one sequence header in codec private maybe.  All else is ok.
>
> I agree, but I think it should be optional.  On by default.

LMAO! You really want to save that 150 bytes per file huh? :P


From paul at msn.com  Thu Oct 30 19:57:17 2003
From: paul at msn.com (Pamel)
Date: Thu, 30 Oct 2003 12:57:17 -0600
Subject: [Matroska-devel] Re: Re: Re: MPEG2 in MKV!
References: <E1AF0PM-00037W-00@scaup.mail.pas.earthlink.net><E1AFGbw-0003nO-00@hawk.mail.pas.earthlink.net><bnrj1l$l3h$1@sea.gmane.org>
	<E1AFH2X-0006Fh-00@harrier.mail.pas.earthlink.net>
Message-ID: <bnrmta$17r$1@sea.gmane.org>

"spyder" wrote...
> No...then you introduce sync errors.  Not all files will be played in crappy
> DirectShow filters.  MPEG video has a framerate for a reason, it's not just
> informational.  If you change the framerate but leave more frames then you
> intorduce sync problems.  If you drop the extra frames then you break the
> stream.  Besides, we shouldn't have to destroy any mpeg compliance just to
> put the stream in MKV.  As I said before, the ONLY thing allowed to change
> from sequence header to sequence header is the QUANTIZERS!  You can't change
> framerate, resolution, colorspace, progressive vs. interlaced etc..  Only
> those 128 bytes for the quantizer are allowed to change.  Otherwise the
> stream is b0rked and no longer spec compliant.

Fine, we leave the Sequence Headers as they are.  Leave the ability to write the
streams as a full MPEG-2 ES stream like I said before.  This is an alternative
method to make things 'better'.  We shouldn't be worrying about crappy MPEG-2 DS
filters.  We tell people not to use crappy Vorbis DS filters, we can tell them
not to use crappy MPEG-2 DS filters too.

In any event, it should be a simple matter to regenerate a fully compliant
MPEG-2 ES stream from the this better method anyway.  Just reenable the RFF flag
and change the timecodes back to method 1.

Method 1:  Store the four frames with timecodes like you are going to store 5
frames. The fourth frame will have a duration that is twice the duration of the
other frames.  This should leave space for the decoder to generate the extra
frame.

Method 2 is better, we just need to make sure that everyone that can use a
Matroska file does not use a crappy decoder. If someone wants full backwards
compatibility IN THE FILE, then use method 1.  Very simple.


Pamel





From spyder at matroska.org  Thu Oct 30 20:01:12 2003
From: spyder at matroska.org (spyder)
Date: Thu, 30 Oct 2003 13:01:12 -0600
Subject: [Matroska-devel] Re: Re: Re: MPEG2 in MKV!
In-Reply-To: <bnrmta$17r$1@sea.gmane.org>
References: <E1AF0PM-00037W-00@scaup.mail.pas.earthlink.net>
	<E1AFH2X-0006Fh-00@harrier.mail.pas.earthlink.net>
	<bnrmta$17r$1@sea.gmane.org>
Message-ID: <E1AFI2f-0001I1-00@cardinal.mail.pas.earthlink.net>

> We shouldn't be worrying
> about crappy MPEG-2 DS filters.  We tell people not to use crappy Vorbis DS
> filters, we can tell them not to use crappy MPEG-2 DS filters too.

umm... I wouldn't call the spec compliant decoders crappy :P That's some 
backward logic. :P




From paul at msn.com  Thu Oct 30 20:10:31 2003
From: paul at msn.com (Pamel)
Date: Thu, 30 Oct 2003 13:10:31 -0600
Subject: [Matroska-devel] Re: Re: Re: Re: MPEG2 in MKV!
References: <E1AF0PM-00037W-00@scaup.mail.pas.earthlink.net><E1AFH2X-0006Fh-00@harrier.mail.pas.earthlink.net><bnrmta$17r$1@sea.gmane.org>
	<E1AFI2f-0001I1-00@cardinal.mail.pas.earthlink.net>
Message-ID: <bnrnm3$35t$1@sea.gmane.org>

"spyder" <spyder at matroska.org> wrote...
> umm... I wouldn't call the spec compliant decoders crappy :P That's some
> backward logic. :P

If its decoding a crappy spec, then its a crappy decoder.  ;)


Pamel





From spyder at matroska.org  Thu Oct 30 20:12:11 2003
From: spyder at matroska.org (spyder)
Date: Thu, 30 Oct 2003 13:12:11 -0600
Subject: [Matroska-devel] Re: Re: Re: Re: MPEG2 in MKV!
In-Reply-To: <bnrnm3$35t$1@sea.gmane.org>
References: <E1AF0PM-00037W-00@scaup.mail.pas.earthlink.net>
	<E1AFI2f-0001I1-00@cardinal.mail.pas.earthlink.net>
	<bnrnm3$35t$1@sea.gmane.org>
Message-ID: <E1AFIDJ-0004Vi-00@cardinal.mail.pas.earthlink.net>

On Thursday 30 October 2003 13:10, you wrote:
> "spyder" <spyder at matroska.org> wrote...
>
> > umm... I wouldn't call the spec compliant decoders crappy :P That's some
> > backward logic. :P
>
> If its decoding a crappy spec, then its a crappy decoder.  ;)
MPEG is not a crappy spec.  it's quite nice actually.  But very very codec 
limited ;)


From moritz at bunkus.org  Thu Oct 30 21:16:43 2003
From: moritz at bunkus.org (Moritz Bunkus)
Date: Thu, 30 Oct 2003 21:16:43 +0100
Subject: [Matroska-devel] Re: Re: Re: Re: MPEG2 in MKV!
In-Reply-To: <bnrnm3$35t$1@sea.gmane.org>
References: <E1AFI2f-0001I1-00@cardinal.mail.pas.earthlink.net>
	<bnrnm3$35t$1@sea.gmane.org>
Message-ID: <20031030201643.GE13719@bunkus.org>

Hi.

> If its decoding a crappy spec, then its a crappy decoder.  ;)

;) Not really. The saying is 'be as liberal possible in what you accept
and as conservative as possible in what you produce'. Any encoder
producing non-specs-compliant stuff is crappy, but a decoder that
accepts such stuff is actually pretty good.

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


From steve.lhomme at free.fr  Fri Oct 31 00:18:19 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Fri, 31 Oct 2003 00:18:19 +0100
Subject: [Matroska-devel] libmatroska - AddFrame lacks default lacing type
In-Reply-To: <20031030173914.GC13719@bunkus.org>
References: <20031030114022.GQ13719@bunkus.org> <3FA0FA7F.2040604@free.fr>
	<20031030173914.GC13719@bunkus.org>
Message-ID: <3FA19C3B.3070109@free.fr>

Moritz Bunkus wrote:

> Hi.
> 
> 
>>Yes.
> 
> 
> Ok, I've already updated KaxVersion.h (and the debian subdir) to 0.6.1
> and added default values for AddFrame() in KaxBlock.h. So commit what
> you have to, then tag and release :)

Done, I've added a parameter to Read() and ReadData() to be able not to 
read an element fully. That's currently only in use in KaxBlock where 
you can read the whole Block header but not the content.

Tagged and released in the usual place :
- 0.6.2 for libebml
- 0.6.1 for libmatroska



From petr at anime.cz  Fri Oct 31 06:53:13 2003
From: petr at anime.cz (Petr Vyskocil)
Date: Fri, 31 Oct 2003 14:53:13 +0900
Subject: [Matroska-devel] Re: VobSubs in Matroska
References: <20031028215735.GC13719@bunkus.org> <3F9EF8E6.5050603@matroska.org>
	<20031029075603.GF13719@bunkus.org>
Message-ID: <01b201c39f73$46d1dd00$55a45da5@puchiko>


> > - when demuxing it from the MKV, can we restore the original .sub file
> >   ?
>
> Very likely, yes. Just recreate the MPEG PS stream. It will not be the
> original stream but very close. Not original because the track ID is
> stored in the stream and that one gets lost because we use our Matroska
> track numbers, but that's a minor issue and not worth keeping the
> overhead and complexity.

The MPEG PS can be reconstructed with the code in SubLog Extractor
http://www.xs4all.nl/~vielle/video/sublog.html (GPLed)

Yusaku



From moritz at bunkus.org  Fri Oct 31 09:51:05 2003
From: moritz at bunkus.org (Moritz Bunkus)
Date: Fri, 31 Oct 2003 09:51:05 +0100
Subject: [Matroska-devel] libmatroska - AddFrame lacks default lacing type
In-Reply-To: <3FA19C3B.3070109@free.fr>
References: <20031030114022.GQ13719@bunkus.org> <3FA0FA7F.2040604@free.fr>
	<20031030173914.GC13719@bunkus.org> <3FA19C3B.3070109@free.fr>
Message-ID: <20031031085105.GF13719@bunkus.org>

Hi.

> Tagged and released in the usual place :
> - 0.6.2 for libebml
> - 0.6.1 for libmatroska

Hmm. I forgot to change libebml/debian/changelog with the new version
because I didn't realize we would have to release libebml, too.

I'm fixing this along with the messed up new line/carriage returns and
will re-release both libs.

We should also think about that only one person makes releases - that
would probably be me, because I have to update the debian
directories. This could hopefully avoid the need for re-releases...

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


From moritz at bunkus.org  Fri Oct 31 10:14:18 2003
From: moritz at bunkus.org (Moritz Bunkus)
Date: Fri, 31 Oct 2003 10:14:18 +0100
Subject: [Matroska-devel] libmatroska - AddFrame lacks default lacing type
In-Reply-To: <20031031085105.GF13719@bunkus.org>
References: <20031030114022.GQ13719@bunkus.org> <3FA0FA7F.2040604@free.fr>
	<20031030173914.GC13719@bunkus.org> <3FA19C3B.3070109@free.fr>
	<20031031085105.GF13719@bunkus.org>
Message-ID: <20031031091418.GG13719@bunkus.org>

Hi.

Re-release has been done, and the web pages have been updated accordingly.

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


From steve.lhomme at free.fr  Fri Oct 31 10:27:16 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Fri, 31 Oct 2003 10:27:16 +0100
Subject: [Matroska-devel] libmatroska - AddFrame lacks default lacing type
In-Reply-To: <20031031085105.GF13719@bunkus.org>
References: <20031030114022.GQ13719@bunkus.org>
	<3FA0FA7F.2040604@free.fr>	<20031030173914.GC13719@bunkus.org>
	<3FA19C3B.3070109@free.fr> <20031031085105.GF13719@bunkus.org>
Message-ID: <3FA22AF4.6000506@free.fr>

Moritz Bunkus wrote:

> We should also think about that only one person makes releases - that
> would probably be me, because I have to update the debian
> directories. This could hopefully avoid the need for re-releases...

If you want to do it, that's fine with me :D

BTW, the MLs seem to lag a lot these days. Any particular reasons ? 
Maybe too many people subscribed ?



From moritz at bunkus.org  Fri Oct 31 10:35:23 2003
From: moritz at bunkus.org (Moritz Bunkus)
Date: Fri, 31 Oct 2003 10:35:23 +0100
Subject: [Matroska-devel] libmatroska - AddFrame lacks default lacing type
In-Reply-To: <3FA22AF4.6000506@free.fr>
References: <20031030114022.GQ13719@bunkus.org> <3FA0FA7F.2040604@free.fr>
	<20031030173914.GC13719@bunkus.org> <3FA19C3B.3070109@free.fr>
	<20031031085105.GF13719@bunkus.org> <3FA22AF4.6000506@free.fr>
Message-ID: <20031031093523.GH13719@bunkus.org>

Hi.

> If you want to do it, that's fine with me :D

Ok, I'll do it (and I'll create a short TODO check list for me ;)).

> BTW, the MLs seem to lag a lot these days. Any particular reasons ? 
> Maybe too many people subscribed ?

It surely does not lag for me, but if free.fr has problems like THIS:

Oct 31 10:25:37 p15097576 postfix/smtp[17565]: 26226440011:
  to=<steve.lhomme at free.fr>, relay=mx.free.fr[213.228.0.13], delay=1,
  status=deferred (host mx.free.fr[213.228.0.13] said: 451 qq trouble
  creating files in queue (#4.3.0) (in reply to end of DATA command))

then it's definitely not my server's fault ;)

Juding from the logs: Your mail arrived at 10:25:25, and delivery to
most of the members was done by 10:25:41. My server can handle much
more, in this case it's really the other servers (free.fr here) that are
problematic.

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


From steve.lhomme at free.fr  Fri Oct 31 10:42:19 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Fri, 31 Oct 2003 10:42:19 +0100
Subject: [Matroska-devel] libmatroska - AddFrame lacks default lacing type
In-Reply-To: <20031031093523.GH13719@bunkus.org>
References: <20031030114022.GQ13719@bunkus.org>
	<3FA0FA7F.2040604@free.fr>	<20031030173914.GC13719@bunkus.org>
	<3FA19C3B.3070109@free.fr>	<20031031085105.GF13719@bunkus.org>
	<3FA22AF4.6000506@free.fr> <20031031093523.GH13719@bunkus.org>
Message-ID: <3FA22E7B.1080301@free.fr>

Moritz Bunkus wrote:
> It surely does not lag for me, but if free.fr has problems like THIS:
> 
> Oct 31 10:25:37 p15097576 postfix/smtp[17565]: 26226440011:
>   to=<steve.lhomme at free.fr>, relay=mx.free.fr[213.228.0.13], delay=1,
>   status=deferred (host mx.free.fr[213.228.0.13] said: 451 qq trouble
>   creating files in queue (#4.3.0) (in reply to end of DATA command))
> 
> then it's definitely not my server's fault ;)
> 
> Juding from the logs: Your mail arrived at 10:25:25, and delivery to
> most of the members was done by 10:25:41. My server can handle much
> more, in this case it's really the other servers (free.fr here) that are
> problematic.

The strange thing is that I received your answer before my message...
But it's true that free.fr seem to have some problems with receiveing 
emails.

9online (my new provider) seem to have even more troubles, the SMTP was 
inaccessible yesterday (hopefully I have my Linux box always running).

Strange era...



From moritz at bunkus.org  Fri Oct 31 13:42:18 2003
From: moritz at bunkus.org (Moritz Bunkus)
Date: Fri, 31 Oct 2003 13:42:18 +0100
Subject: [Matroska-devel] libmatroska - AddFrame lacks default lacing type
In-Reply-To: <20031031085105.GF13719@bunkus.org>
References: <20031030114022.GQ13719@bunkus.org> <3FA0FA7F.2040604@free.fr>
	<20031030173914.GC13719@bunkus.org> <3FA19C3B.3070109@free.fr>
	<20031031085105.GF13719@bunkus.org>
Message-ID: <20031031124218.GI13719@bunkus.org>

Hi.

Another re-release - In three files the default value for ReadFully was
missing (EbmlMaster.h, EbmlBinary.h, KaxBlock.h). I've fixed this,
re-tagged, re-built the archived, re-uploaded them.

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


From steve.lhomme at free.fr  Fri Oct 31 13:48:09 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Fri, 31 Oct 2003 13:48:09 +0100
Subject: [Matroska-devel] libmatroska - AddFrame lacks default lacing type
In-Reply-To: <20031031124218.GI13719@bunkus.org>
References: <20031030114022.GQ13719@bunkus.org>
	<3FA0FA7F.2040604@free.fr>	<20031030173914.GC13719@bunkus.org>
	<3FA19C3B.3070109@free.fr>	<20031031085105.GF13719@bunkus.org>
	<20031031124218.GI13719@bunkus.org>
Message-ID: <3FA25A09.3090706@free.fr>

Moritz Bunkus wrote:

> Hi.
> 
> Another re-release - In three files the default value for ReadFully was
> missing (EbmlMaster.h, EbmlBinary.h, KaxBlock.h). I've fixed this,
> re-tagged, re-built the archived, re-uploaded them.

In some cases it's better not to put default value. I think it's better 
to put it in "helper" functions that a dumb user will use (like 
EbmlMaster::Read()) but not in low functions. For example I didn't put a 
value on purpose for EbmlBinary. (at first I didn't want to put it 
anywhere, but it doesn't make sense to check an integer without the value)



From moritz at bunkus.org  Fri Oct 31 13:53:03 2003
From: moritz at bunkus.org (Moritz Bunkus)
Date: Fri, 31 Oct 2003 13:53:03 +0100
Subject: [Matroska-devel] libmatroska - AddFrame lacks default lacing type
In-Reply-To: <3FA25A09.3090706@free.fr>
References: <20031030114022.GQ13719@bunkus.org> <3FA0FA7F.2040604@free.fr>
	<20031030173914.GC13719@bunkus.org> <3FA19C3B.3070109@free.fr>
	<20031031085105.GF13719@bunkus.org>
	<20031031124218.GI13719@bunkus.org> <3FA25A09.3090706@free.fr>
Message-ID: <20031031125303.GJ13719@bunkus.org>

Hi.

> In some cases it's better not to put default value. I think it's better 
> to put it in "helper" functions that a dumb user will use (like 
> EbmlMaster::Read()) but not in low functions. For example I didn't put a 
> value on purpose for EbmlBinary. (at first I didn't want to put it 
> anywhere, but it doesn't make sense to check an integer without the
> value)

Ok, for EbmlMaster/EbmlBinary it wasn't really needed, that was too fast
a reaction of mine. But KaxBlock.h should get it (API compatibility) as
it just keeps the behaviour consistent to earlier versions.

So we can remove the defaults for the two Ebml* again for the next
release.

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


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

Moritz Bunkus wrote:

> Hi.
> 
> 
>>In some cases it's better not to put default value. I think it's better 
>>to put it in "helper" functions that a dumb user will use (like 
>>EbmlMaster::Read()) but not in low functions. For example I didn't put a 
>>value on purpose for EbmlBinary. (at first I didn't want to put it 
>>anywhere, but it doesn't make sense to check an integer without the
>>value)
> 
> 
> Ok, for EbmlMaster/EbmlBinary it wasn't really needed, that was too fast
> a reaction of mine. But KaxBlock.h should get it (API compatibility) as
> it just keeps the behaviour consistent to earlier versions.
> 
> So we can remove the defaults for the two Ebml* again for the next
> release.

OK.

BTW, not that I think of it, it *does* make sense to have 
ReadFully=false for an integer. Because in EbmlMaster::Read() it would 
read the ID+length and leave the value behind. Which is nice if you 
really don't want to read values and just the data structure.

But that also means in your case (reading a Cluster without the Block 
data only) using ReadFully=false would read nothing, just the structure. 
So IMO ReadFully should be moved from an integer to a bitfield. With 
values like :

0 Read no data (no integer content)
1 Read all data
2 Read partial data (ie integers OK, but not Block data)

Only the handling of the '2' value needs to be added (in 
libebml+libmatroska), the rest is backward compatible.




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

Steve Lhomme wrote:

[edit]
> BTW, not that I think of it, it *does* make sense to have 

s/not/now/

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

Should be :
0 Read partial data (ie integers OK, but not Block data)
1 Read all data
2 Read no data (no integer content)

As 0 and 1 are the current implementation.



From chris at matroska.org  Fri Oct 31 16:40:10 2003
From: chris at matroska.org (Christian HJ Wiesner)
Date: Fri, 31 Oct 2003 16:40:10 +0100
Subject: [Matroska-devel] The near future of matroska - where do we go now ?
Message-ID: <3FA2825A.9020009@matroska.org>



Hi guys,

i thought it time to hear your opinion about where we go with matroska 
in the near future. Here the open issues i see today :

- vobsub in mkv ( solved soon, muxing done, VLC/Mplayer playback done )

- vobsub playback on DirectShow ( Gabest :D ? )

- MPEG1/2 video in MKV

- MPEG1/2 video playback on DirectShow, mplayer and VLC

- Native MPEG4 MKV files encoding

- Native MPEG4 MKV files transmuxing from AVI/OGM, using sysKin's frame 
reader code

- USF in MKV

- Hardware support ( C parser library )

- Hardware profiles  ( together with Stefan )

- FFMPEG / libavcodec / Xine support ( C parser library )

- MPC SV8 support ?

- FLAC support

- Wavpack ( lossy/lossless audio codec ) support

- Theora video support

- Quicktime / Sorenson support ?? ( if ever )

- Control Tracks

- Menues

- Codec State ( resizing in the middle of the stream etc. )

Did i forget anything ??? If i didnt forget anything ..... this is 
actually enough for one year of work maybe, but what do we do after that 
:-) ??? Any ideas ?

Lets do a kind of brainstorming here on the list guys, tell me what you 
think ...

I still feel matroska needed an opensource video encoder/editor tool 
that was not based on Virtualdub like VirtualdubMod, such that handling 
of the MKVs based on timestamps would be possible. But, this would mean 
a lot of work, and a lot of help from new devs we needed to bring on 
board. We could maybe steal the codec API from the new upcoming FFMPEG 
0.5.x release, and the container API from mplayer G2, as suggested by 
Alex Bergeraszi from the mplayer core dev team. Still, it will take us a 
long while until we even had the same functionality as avs2matroska from 
DaveEL, this congenial tool that unfortunately never was finished, if we 
imply that we had to include means to use xvid.dll dynamically instead 
of statically, to avoid license problems.

Its brainstorming time ..... let your ideas flow .... and use the 'reply 
all' button on your mail client in any case ;) ...

Christian




From steve.lhomme at free.fr  Fri Oct 31 16:48:32 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Fri, 31 Oct 2003 16:48:32 +0100
Subject: [Matroska-devel] Re: [Matroska-general] The near future of matroska
 - where do we go now	?
In-Reply-To: <3FA2825A.9020009@matroska.org>
References: <3FA2825A.9020009@matroska.org>
Message-ID: <3FA28450.2070900@free.fr>

Christian HJ Wiesner wrote:

> Hi guys,
> 
> i thought it time to hear your opinion about where we go with matroska 
> in the near future. Here the open issues i see today :
> 
> - vobsub in mkv ( solved soon, muxing done, VLC/Mplayer playback done )

...

> - Menues
> 
> - Codec State ( resizing in the middle of the stream etc. )
> 
> Did i forget anything ??? If i didnt forget anything ..... this is 
> actually enough for one year of work maybe, but what do we do after that 
> :-) ??? Any ideas ?

Streaming / Broadcasting / Multicasting over TCP, HTTP and UDP.



From jcsston at toughguy.net  Fri Oct 31 18:09:32 2003
From: jcsston at toughguy.net (Jory)
Date: Fri, 31 Oct 2003 11:09:32 -0600
Subject: [Matroska-devel] Re: [Matroska-general] The near future of matroska
	- where do we go now?
References: <3FA2825A.9020009@matroska.org>
Message-ID: <001c01c39fd1$cd23c2c0$0200a8c0@jcsston>

> - FLAC support
> 

FLAC is already supported via the FLAC DShow En/Decoder filters.
http://www.hydrogenaudio.org/index.php?showtopic=13921

Jory



From paul at msn.com  Fri Oct 31 19:48:27 2003
From: paul at msn.com (Pamel)
Date: Fri, 31 Oct 2003 12:48:27 -0600
Subject: [Matroska-devel] Re: The near future of matroska - where do we go
	now ?
References: <3FA2825A.9020009@matroska.org>
Message-ID: <bnuap6$7dp$1@sea.gmane.org>

"Christian HJ Wiesner" wrote...
> I still feel matroska needed an opensource video encoder/editor tool
> that was not based on Virtualdub like VirtualdubMod, such that handling
> of the MKVs based on timestamps would be possible. But, this would mean
> a lot of work, and a lot of help from new devs we needed to bring on
> board. We could maybe steal the codec API from the new upcoming FFMPEG
> 0.5.x release, and the container API from mplayer G2, as suggested by
> Alex Bergeraszi from the mplayer core dev team.

I don't really see why you would need totally separate API's for the codec and
the container.  They are transferring all of the same data.  Uncompressed data,
compressed data, codec info, timecode, durations, and errors.  Then you just
need a way to push/pull that information and you have an API.


Pamel