From gldm at mail.com  Tue Jul  1 19:35:24 2003
From: gldm at mail.com (Toby Hudon)
Date: Tue, 01 Jul 2003 12:35:24 -0500
Subject: [matroska-devel] Re: [gst-devel] Fwd: Re: [UCI-Devel] Re: Common Opensource codec API
Message-ID: <20030701173525.85525.qmail@mail.com>


----- Original Message -----
From: Ronald Bultje <rbultje at ronald.bitfreak.net>
Date: 30 Jun 2003 23:17:44 +0200 
To: Toby Hudon <gldm at mail.com>
Subject: Re: [gst-devel] Fwd: Re: [UCI-Devel] Re: Common Opensource codec API

> But that's the whole issue, the messages. You're just moving the problem
> over from linkage space to message space. The problem here is actually
> to define how all this works. ;).
>

Well it's got to be somewhere. There's obviously a fairly big number of things to do, get frames, configure things, get keyframes, etc. It's got to be somewhere, and I figured defined message constants are easier to type than function calls and their parameters without errors. Also if we're going to assume that for simplicity not everyone will have to implement every possible function, what happens when an app calls a function that a component doesn't support? Does the system bomb or what? With the message system the caller just looks at the return value to know what's going on, there's no chance of hitting a function without a definition.

Unless you expect people to have say, 200 functions most of which are empty... that seems kinda redundant to me when a switch's default case is alot cleaner and has the same effect.
 
> Funnily, you're taking XVID as an example, but xvid is horrible. Look at
> the API. There's one struct per message. No extendibility. No
> configurability. Perfect for a one-task API, but not at all usable for a
> generic API.
> 

Sorry I just picked a codec name at random, I haven't looked at their API that much but from what I've seen trying to write my VFW code based on theirs it's most likely a mess as you say.

> GStreamer (GObject)'s way of defining all this is easier. Make
> name/value pairs, make a standard doc that describes which types support
> what base properties. Since there's no limit on name/value pairs,
> there's no limit in extendibility. Making this two-way allows the
> application to view these properties, too.
> And, even better, this method doesn't depend on GStreamer or GObject at
> all. GStreamer just implements it in that specific way.
> 

Never seen it, or even heard of it for that matter. What do you mean by name/value pairs, you mean just variables? How is this better or different than what I was talking about? You'd still need to define a standard doc (i.e. a bunch of constants defined for messages and their data structs/docs), and as for what supports what you find out when you try to pass a message, if it returns 0 it's unsupported. You as the caller get the job of handling it if that's a problem.

> The good thing of your approach is actually its simplicity, and I like
> that. However, I wouldn't vote for sticking to one function, since that
> only moves the definition problem over from linkage space to message
> space, and that has no advantage, imho. However, the idea of using as
> little functions as possible up to a certain amount sounds good, I'll
> try sticking to that. :).
> 

Well I could see segregating different types of operations into different functions, such as the linking of dynamic libraries, and I've already said that'd probably want to be seperate. But for the actual video processing itself, why would you put it in multiple functions? Since filters, codecs, etc all have similar needs, doesn't it make more sense for them to just be able to pick and choose from the defined operations instead of forcing them to implmement functions they might not need? I still don't know what happens when you call a function that isn't there, can you please tell me? I haven't tried this but I'd suspect it isn't pretty.

> > If you have a simpler idea please let me know, and BTW what is 
> > CORBA?
> 
> Something like COM, but for Unix/Linux.
> 

What's COM?

-- 
__________________________________________________________
Sign-up for your own FREE Personalized E-mail at Mail.com
http://www.mail.com/?sr=signup

http://www.matroska.org


From chris at matroska.org  Wed Jul  2 13:30:14 2003
From: chris at matroska.org (Christian HJ Wiesner)
Date: Wed, 02 Jul 2003 13:30:14 +0200
Subject: [matroska-devel] OMF container format from AVID - the basis for AAF
Message-ID: <3F02C246.4000409@matroska.org>

Hi,

certainly not a real competitor to matroska or MCF as OSS projects, just 
another closed source/open specs thinggie like Nullsoft's NSV and 
trolltech's MPX :

http://www.swgrille.com/whats_new/default.htm

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


      The OMF Specification

OMF is an edit data interchange format introduced by Avid Technology in 
1990. OMF is a binary file format using object-oriented technology. It 
uses a ?Bento? object container (an Apple technology) into which data in 
the form of the 'OMF Object Model' is placed.

The use of the Bento container provides the foundation for building an 
extensible interchange format. The Avid OMF Object Model is an 
insightful design for capturing edit data. As a whole, the format 
provides the capability of interchanging very rich edit information 
about a project. This comes at the cost of abstraction and complexity ? 
in other words, it is not so easy to understand.

Originally released as OMF1, OMF2 was introduced in 1996 to enhance the 
capabilities and efficiencies. While both formats share similar 
technologies, OMF2 is very different from OMF1 in terms of data types, 
properties, and semantics. This bifurcation of the formats caused even 
more complexity, but most applications will unfortunately need to 
support both.

The specification of both OMF1 and OMF2 are published by Avid.
-------------------------------------------------------------------------


It seems that this OMF container is used as the basis for this other 
thing we came across already, named AAF :

http://www.v-site.net/smpte-ne/articles/qt30aaf.html

-------------------------------------------------
AAF metadata interchange will be based on Avid's Open Media Framework 
Interchange (OMFI). OMFI was previously implemented in Apple's Bento 
container architecture, now declared end-of-life by Apple. Its container 
architecture will be newly implemented in Microsoft's object-oriented 
COM-based Structured Storage. OMFI is widely used in the audio industry 
for exchange of audio files that must synchronize with edited video and 
film productions. It is also used by Heuris' MPEG Power Professional 
MPEG encoders to extract cut points from a production, which become 
I-frames in the Encoding Control List (ECL), and to locate SFX and TX 
that need special encoder handling. But Avid has only recently extended 
OMFI metadata and media interchange to its own line of video and film 
products, and not yet completely. Outside of Avid, only a few of Avid's 
NLE (nonlinear editing) competitors can exchange compositional metadata 
and Motion-JPEG video media via OMFI, notable Tektronix/Lightworks and 
Softimage (Microsoft). This is not entirely Avid's fault. Their partners 
have had the spec for years and not implemented it. Ironically, some 
OMFI media files can be interchanged using QuickTime 3. For example, 
Avid's entry-level nonlinear editor Cinema can use QuickTime 3 to open 
high-end Avid Media Composer files. At NAB'98 Discreet Logic showed 
their editing and effects workstations exchanging files between 
Macintosh and Windows.
--------------------------------------------------------


A guy came to the Virtualdub support forum, claiming OMF/AAF superiority 
and 50+ years readability :
http://virtualdub.everwicked.com/index.php?act=ST&f=6&t=3636&s=455d0b2d2d1f934c81f16b3824eb3226

I flamed the heck out of him :D ...since then he didnt come back ( 
pretty stupid thing to claim something will work in 50+ years from now, 
especially in the world we are living in today ;-) ) ....

Just FYI, nothing we have to worry about, there are no open source 
libraries for any of them AFAIK ;) ...


Christian






http://www.matroska.org


From steve.lhomme at free.fr  Wed Jul  2 14:33:41 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Wed, 2 Jul 2003 14:33:41 +0200
Subject: [matroska-devel] Re: OMF container format from AVID - the basis for AAF
References: <3F02C246.4000409@matroska.org>
Message-ID: <005601c34096$2bc61620$0c7ba8c0@ing12>

> The use of the Bento container provides the foundation for building an
> extensible interchange format. The Avid OMF Object Model is an
> insightful design for capturing edit data. As a whole, the format
> provides the capability of interchanging very rich edit information
> about a project. This comes at the cost of abstraction and complexity ?
> in other words, it is not so easy to understand.

IMO it just proves that it sucks ;)

BTW, with Avid support they surely have a good user base (professional
digital edition). That would be great to convince Avid to use matroska (for
free).

http://www.matroska.org


From paul at msn.com  Wed Jul  2 19:17:10 2003
From: paul at msn.com (Pamel)
Date: Wed, 2 Jul 2003 12:17:10 -0500
Subject: [matroska-devel] Re: OMF container format from AVID - the basis for AAF
References: <3F02C246.4000409@matroska.org>
Message-ID: <bdv40r$a96$1@main.gmane.org>

"Christian HJ Wiesner" <chris at matroska.org> wrote ...
> certainly not a real competitor to matroska or MCF as OSS projects, just
> another closed source/open specs thinggie like Nullsoft's NSV and
> trolltech's MPX :

The thing about OMF and MXF using AAF is that AAF implements MPEG-7 from the
beginning.  It is a partial implementation, but it is an implementation.
Matroska could also implement an MPEG-7 compatibility matrix if it liked,
but I have not yet seen a list of the tags that are supported in MPEG-7.  If
anyone comes across such a list, would you point me in that direction?
(MPEG-7 is really just a complex tagging system. Last I checked, AAF had
around 250 tags, where Matroska has around 100.)


Pamel



http://www.matroska.org


From moritz at bunkus.org  Fri Jul  4 00:44:55 2003
From: moritz at bunkus.org (Moritz Bunkus)
Date: Fri, 4 Jul 2003 00:44:55 +0200
Subject: [matroska-devel] tag reading borked?
Message-ID: <20030703224455.GV1544@bunkus.org>

Heya Steve,

I've experimented with tags, and have the same problems that jcsston
has.

Here's the code to create some dummy comments at the end of a file:

  KaxTags &tags = GetChild<KaxTags>(*kax_segment);
  KaxTag &tag = GetChild<KaxTag>(tags);
  KaxTagTargets &targets = GetChild<KaxTagTargets>(tag);
  *(static_cast<EbmlUInteger *>(&GetChild<KaxTagTrackUID>(targets))) =
    1234;
  *(static_cast<EbmlUInteger *>(&GetChild<KaxTagChapterUID>(targets))) =
    5678;
  KaxTagGeneral &general = GetChild<KaxTagGeneral>(tag);
  *(static_cast<EbmlUnicodeString *>(&GetChild<KaxTagSubject>(general)))
  =
    cstr_to_UTFstring("Subject");
  *(static_cast<EbmlUnicodeString
  *>(&GetChild<KaxTagBibliography>(general))) =
    cstr_to_UTFstring("Bibliography");
  *(static_cast<EbmlString *>(&GetChild<KaxTagLanguage>(general))) =
  "ger";
  tags.Render(*out);

This works. Here's the output of my new mkvinfo:

|+ Tags at 734945
| + Tag at 734950
|  + Targets at 734953
|   + Track UID: 1234 at 734956
|   + Chapter UID: 5678 at 734961
|  + General at 734966
|   + Unknown element: N7libebml15DummyRawElementE at 734969

So the first element that it cannot find is the KaxTagSubject. But this
element IS in the file, and it appears to be OK. Here's a small excerpt
from the hexdump:

000B36E0  00 12 54 C3  67 B3 73 73   B0 63 C0 8A  63 C5 82 04  ..T.g.ss.c..c...
000B36F0  D2 63 C4 82  16 2E 67 C9   A0 29 C1 87  53 75 62 6A  .c....g..)..Subj
000B3700  65 63 74 44  88 8C 42 69   62 6C 69 6F  67 72 61 70  ectD..Bibliograp
000B3710  68 79 22 B5  9C 83 67 65   72                        hy"...ger

The three bytes directly before the Subject are 29 C1 87 which are OK
according to KaxTag.cpp:

EbmlId KaxTagSubject_TheId               (0x29C1, 2);

The length, 7, is good as well.

I'll upload the file to
http://www.bunkus.org/videotools/mkvtoolnix/tagreading.mka

This problem seems to occur with a lot of tags, btw, not only with the
Subject.

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


From steve.lhomme at free.fr  Sat Jul  5 17:14:27 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Sat, 05 Jul 2003 17:14:27 +0200
Subject: [matroska-devel] Re: tag reading borked?
In-Reply-To: <20030703224455.GV1544@bunkus.org>
References: <20030703224455.GV1544@bunkus.org>
Message-ID: <3F06EB53.5060908@free.fr>

Moritz Bunkus wrote:
> This problem seems to occur with a lot of tags, btw, not only with the
> Subject.

This was due to some IDs not EBML compliant. It's fixed in 0.5.0alpha2 
in the downloads of matroska.free.fr. The doc has also been updated, 
but... not in CVS yet.

http://www.matroska.org


From chris at matroska.org  Fri Jul  4 23:29:06 2003
From: chris at matroska.org (Christian HJ Wiesner)
Date: Fri, 04 Jul 2003 23:29:06 +0200
Subject: [matroska-devel] Ogg Tags 'Recommendation' list
Message-ID: <3F05F1A2.4010104@matroska.org>

http://reactor-core.org/ogg-tag-recommendations.html

When reading vorbis-devel, you know that there is a lot of flaming going 
on about this list, as the authors of it would like to see a kind of 
standardization for Ogg Tags, while many others in the list want their 
own custom tags to be used .... however, maybe worth looking at it ...

Christian

http://www.matroska.org


From paul at msn.com  Sat Jul  5 04:51:53 2003
From: paul at msn.com (Pamel)
Date: Fri, 4 Jul 2003 21:51:53 -0500
Subject: [matroska-devel] Re: Ogg Tags 'Recommendation' list
References: <3F05F1A2.4010104@matroska.org>
Message-ID: <be5edq$ugb$1@main.gmane.org>

I looked over the list, but I didn't spot any tags that we don't already
have.  Well, I'm not sure exactly what "OPUS" is for...


Pamel

"Christian HJ Wiesner" <chris at matroska.org> wrote..
> http://reactor-core.org/ogg-tag-recommendations.html
>
> When reading vorbis-devel, you know that there is a lot of flaming going
> on about this list, as the authors of it would like to see a kind of
> standardization for Ogg Tags, while many others in the list want their
> own custom tags to be used .... however, maybe worth looking at it ...
>
> Christian
>
> http://www.matroska.org
>



http://www.matroska.org


From chris at matroska.org  Fri Jul  4 23:56:38 2003
From: chris at matroska.org (Christian HJ Wiesner)
Date: Fri, 04 Jul 2003 23:56:38 +0200
Subject: [matroska-devel] Request for cheking our tagging system to Jonathan Walther from Debian.org
Message-ID: <3F05F816.1000307@matroska.org>


Hi Jonathan,

i see you are fighting for a standardized tagging system on vorbis-devel 
and vorbis-general , link is here : 
http://reactor-core.org/ogg-tag-recommendations.html

You may have noticed we are in the process of establishing an open 
standard A/V container format to replace good old AVI, adding high 
flexibility and versatility for the future. However, with respect to 
tags being used we are rather conservative. We decided to create a 
standard set of tags that should be supported by every app 
creating/editing/reading matroska files.

Here our draft for a matroska tagging system : 
http://www.matroska.org/specs/matroskatags.html

However, we added a system so that users can define custom tags also, if 
they absolutely feel like doing that. Jonathan, i'd be very interested 
to hear your opinion about our draft, as you seem to have a lot of 
expertise here. Please, when replying, use the reply-all of your email 
client so the answer makes its way to the list ....

Regards

Christian




http://www.matroska.org


From chris at matroska.org  Tue Jul  8 17:33:34 2003
From: chris at matroska.org (Christian HJ Wiesner)
Date: Tue, 08 Jul 2003 17:33:34 +0200
Subject: [Matroska-devel] Testemail 2
Message-ID: <3F0AE44E.3060406@matroska.org>

Testemail 2




From jcsston at ToughGuy.net  Tue Jul  8 22:39:12 2003
From: jcsston at ToughGuy.net (Jory)
Date: Tue, 8 Jul 2003 15:39:12 -0500
Subject: [Matroska-devel] Storing FLAC in Matroska
Message-ID: <005101c34591$00e3cf10$0200a8c0@jcsston>

Hello,
    I'm looking into storing FLAC audio in Matroska and I have a few
questions.

1. Can I use libflac to extract the compressed frames?
Or will I need to write up a simple file parser?

2. What is required to decode the frames?
>From the docs I understand that you need the FRAME and you may need the
METADATA_BLOCK.


Thanks,
Jory Stone
jcsston at toughguy.net

Matroska, the new, extensible open standard A/V container format
http://www.matroska.org/




From xflac at yahoo.com  Wed Jul  9 00:02:49 2003
From: xflac at yahoo.com (Josh Coalson)
Date: Tue, 8 Jul 2003 15:02:49 -0700 (PDT)
Subject: [Matroska-devel] Re: [Flac-dev] Storing FLAC in Matroska
In-Reply-To: <005101c34591$00e3cf10$0200a8c0@jcsston>
Message-ID: <20030708220249.43697.qmail@web13804.mail.yahoo.com>

--- Jory <jcsston at ToughGuy.net> wrote:
> Hello,
>     I'm looking into storing FLAC audio in Matroska and I have a few
> questions.
> 
> 1. Can I use libflac to extract the compressed frames?
> Or will I need to write up a simple file parser?

I'm not sure I understand your question, but one unfortunate
fact about native FLAC is that you cannot discover the frame
boundaries without decoding.  But you can decode a file, and
after each frame get the current stream position from the
decoder, which will tell you where to chop the original stream.
See the source for metaflac for an example, where it uses this
method to add seekpoints to a seektable.

> 2. What is required to decode the frames?
> From the docs I understand that you need the FRAME and you may need
> the
> METADATA_BLOCK.

If it is in the streamable subset, you need only what's in the
frames.  If not, you may need some numbers from the STREAMINFO
metadata block.  Search for 'subset' on
http://flac.sourceforge.net/format.html

Josh


__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com


From chris at matroska.org  Wed Jul  9 15:42:50 2003
From: chris at matroska.org (Christian HJ Wiesner)
Date: Wed, 09 Jul 2003 15:42:50 +0200
Subject: [Matroska-devel] New Mailing Lists up and running
Message-ID: <3F0C1BDA.3010103@matroska.org>

Hi everybody,

if you received an email about being subscribed to a new matroska 
mailing list, dont panic, you dont have to read yet another list. As you 
may know, freelists.org was down for a while as a thunderstorm destroyed 
their PC central. As we had no idea how long it would take unil they 
have it up and running, we made a step we had been thinking of since a 
long time and created our own mailing list server, which is hosted on 
bunkus.org ( Mosu's server ). He installed mailman for this, and i was 
just waiting for freelists.org to be up again to be able to 'steal' all 
the email adresses from the subscription list, and subscribe all of you 
manually.

This was done today and i would like to ask you to use this new mail 
adresses from now on ( freelists.org will be abandoned soon ) :

matroska-general at lists.matroska.org
matroska-devel at lists.matroska.org
matroska-users at lists.matroska.org
matroska-cvs at lists.matroska.org

Please note that its matroska-user*S* now, while it was matroska-user_   
before.

If you plan to change the subscription go here :

http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-general
http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel
http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-cvs
http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-users


We hope you understand why we were doing this, the matroska project has 
meanwhile reached an importance where we simply dont want to depend on 
an external host for the ML archive and distribution. The new solution, 
with  lists.matroska.org as TLD, is giving us a lot of freedom in terms 
of choice of server. Cyt0plas is planning to install mailman on 
corecodec.org also, so if we had a problem with bunkus.org we could 
easily transcribe the complete MLs to cc.org, without having to change 
anything.

Regards

Christian



From mosu at bunkus.net  Thu Jul 10 00:21:06 2003
From: mosu at bunkus.net (Moritz Bunkus)
Date: Thu, 10 Jul 2003 00:21:06 +0200
Subject: [Matroska-devel] 0.5.0beta1 is borked
Message-ID: <20030709222106.GB26444@bunkus.org>

Hi.

beta1 is as borked as alpha4 was. alpha3 is working ok.

My tag test executable was linked against beta1, mkvinfo was linked
against alpha3 and beta1. For alpha3 the output is mostly ok, for beta1
it's borked whenever a higher level element is encountered. Yes, all my
upper_lvl_el tests are '... > 0' and not '... != 0'.

Using gdb shows that the next FindNextElement after the ChapterUID has
been displayed is a dummy element.

-- 
 ==> Ciao, Mosu (Moritz Bunkus)
-------------- next part --------------
+ EBML head at 0
+ Segment at 24
|+ Tags at 33
| + Tag at 39
|  + Targets at 43
|   + Track UID: 1234 at 46
|   + Chapter UID: 5678 at 51
|   + Unknown element: N7libebml15DummyRawElementE at 56
|   + Unknown element: N7libebml15DummyRawElementE at 292
|   + Unknown element: N7libebml15DummyRawElementE at 385
|   + Unknown element: N7libebml15DummyRawElementE at 494
|   + Unknown element: N7libebml15DummyRawElementE at 615
|   + Unknown element: N7libebml15DummyRawElementE at 647
|   + Unknown element: N7libebml15DummyRawElementE at 732
|   + Unknown element: N7libebml15DummyRawElementE at 774
|   + Unknown element: N7libebml15DummyRawElementE at 820
|  + General at 56
|   + Subject: Subject at 60
|   + Bibliography: Bibliography at 70
|   + Language: ger at 85
|   + Rating: length 5, data: 0x68 0x61 0x6c 0x6c 0x6f  at 92
|   + Encoder: Encoder at 100
|   + Encode settings: EncodeSettings at 110
|   + File: File at 127
|   + Archival location: ArchivalLocation at 134
|   + Keywords: Keywords, 1 at 153
|   + Keywords: Keywords, 2 at 167
|   + Mood: Mood at 181
|   + Record location: RecordLocation, 1 at 188
|   + Record location: RecordLocation, 2 at 208
|   + Source: Source at 228
|   + Source form: SourceForm at 237
|   + Product: Product at 250
|   + Original media type: OriginalMediaType at 260
|   + Play counter: 123456 at 280
|   + Popularimeter: 234567 at 286
|   + Unknown element: N7libebml15DummyRawElementE at 292
|   + Unknown element: N7libebml15DummyRawElementE at 385
|   + Unknown element: N7libebml15DummyRawElementE at 494
|   + Unknown element: N7libebml15DummyRawElementE at 615
|   + Unknown element: N7libebml15DummyRawElementE at 647
|   + Unknown element: N7libebml15DummyRawElementE at 732
|   + Unknown element: N7libebml15DummyRawElementE at 774
|   + Unknown element: N7libebml15DummyRawElementE at 820
|  + Genres at 292
|   + Audio genre: AudioGenre at 295
|   + Video genre: length 5, data: 0x68 0x61 0x6c 0x6c 0x6f  at 308
|   + Sub genre: SubGenre at 316
|   + Unknown element: N7libebml15DummyRawElementE at 327
|   + Unknown element: N7libebml15DummyRawElementE at 385
|   + Unknown element: N7libebml15DummyRawElementE at 494
|   + Unknown element: N7libebml15DummyRawElementE at 615
|   + Unknown element: N7libebml15DummyRawElementE at 647
|   + Unknown element: N7libebml15DummyRawElementE at 732
|   + Unknown element: N7libebml15DummyRawElementE at 774
|   + Unknown element: N7libebml15DummyRawElementE at 820
|  + Audio specific at 385
|   + Audio encryption: length 5, data: 0x68 0x61 0x6c 0x6c 0x6f  at 388
|   + Audio gain: 42.000 at 396
|   + Audio peak: 54.000 at 403
|   + BPM: 23.000 at 410
|   + Equalisation: length 5, data: 0x68 0x61 0x6c 0x6c 0x6f  at 417
|   + Disc track: 2 at 425
|   + Set part: 4 at 429
|   + Initial key: InitialKey at 433
|   + Official audio file URL: OfficialAudioFileURL at 446
|   + Official audio source URL: OfficialAudioSourceURL at 469
|   + Unknown element: N7libebml15DummyRawElementE at 494
|   + Unknown element: N7libebml15DummyRawElementE at 615
|   + Unknown element: N7libebml15DummyRawElementE at 647
|   + Unknown element: N7libebml15DummyRawElementE at 732
|   + Unknown element: N7libebml15DummyRawElementE at 774
|   + Unknown element: N7libebml15DummyRawElementE at 820
|  + Multi commercial at 494
|   + Commercial at 497
|    + Type: 3 (Owner) at 500
|    + Address: MultiCommercialAddress at 504
|    + URL: MultiCommercialURL at 529
|    + Email: MultiCommercialEmail at 550
|    + Multi price at 573
|     + Currency: MultiPriceCurrency at 576
|     + Amount: 42.000 at 597
|     + Price date: Wed Jul  9 22:01:18 2003 UTC at 604
|     + Unknown element: N7libebml15DummyRawElementE at 615
|     + Unknown element: N7libebml15DummyRawElementE at 647
|     + Unknown element: N7libebml15DummyRawElementE at 732
|     + Unknown element: N7libebml15DummyRawElementE at 774
|     + Unknown element: N7libebml15DummyRawElementE at 820
|    + Unknown element: N7libebml15DummyRawElementE at 615
|    + Unknown element: N7libebml15DummyRawElementE at 647
|    + Unknown element: N7libebml15DummyRawElementE at 732
|    + Unknown element: N7libebml15DummyRawElementE at 774
|    + Unknown element: N7libebml15DummyRawElementE at 820
|   + Unknown element: N7libebml15DummyRawElementE at 615
|   + Unknown element: N7libebml15DummyRawElementE at 647
|   + Unknown element: N7libebml15DummyRawElementE at 732
|   + Unknown element: N7libebml15DummyRawElementE at 774
|   + Unknown element: N7libebml15DummyRawElementE at 820
|  + Multi date at 615
|   + Date at 618
|    + Type: 4 (Original release date) at 621
|    + Begin: Wed Jul  9 22:01:18 2003 UTC at 625
|    + End: Wed Jul  9 22:01:18 2003 UTC at 636
|    + Unknown element: N7libebml15DummyRawElementE at 647
|    + Unknown element: N7libebml15DummyRawElementE at 732
|    + Unknown element: N7libebml15DummyRawElementE at 774
|    + Unknown element: N7libebml15DummyRawElementE at 820
|   + Unknown element: N7libebml15DummyRawElementE at 647
|   + Unknown element: N7libebml15DummyRawElementE at 732
|   + Unknown element: N7libebml15DummyRawElementE at 774
|   + Unknown element: N7libebml15DummyRawElementE at 820
|  + Multi entity at 647
|   + Entity at 650
|    + Type: 1 (Lyricist / text writer) at 653
|    + Name: MultiEntityName at 657
|    + URL: MultiEntityURL at 675
|    + Email: MultiEntityEmail at 692
|    + Address: MultiEntityAddress at 711
|    + Unknown element: N7libebml15DummyRawElementE at 732
|    + Unknown element: N7libebml15DummyRawElementE at 774
|    + Unknown element: N7libebml15DummyRawElementE at 820
|   + Unknown element: N7libebml15DummyRawElementE at 732
|   + Unknown element: N7libebml15DummyRawElementE at 774
|   + Unknown element: N7libebml15DummyRawElementE at 820
|  + Multi identifier at 732
|   + Identifier at 735
|    + Type: 5 (EAN) at 738
|    + Binary: length 5, data: 0x68 0x61 0x6c 0x6c 0x6f  at 742
|    + String: MultiIdentifierString at 750
|    + Unknown element: N7libebml15DummyRawElementE at 774
|    + Unknown element: N7libebml15DummyRawElementE at 820
|   + Unknown element: N7libebml15DummyRawElementE at 774
|   + Unknown element: N7libebml15DummyRawElementE at 820
|  + Multi legal at 774
|   + Legal at 777
|    + Type: 3 (Terms of use) at 780
|    + URL: MultiLegalURL at 784
|    + Address: MultiLegalAddress at 800
|    + Unknown element: N7libebml15DummyRawElementE at 820
|   + Unknown element: N7libebml15DummyRawElementE at 820
|  + Multi title at 820
|   + Title at 824
|    + Type: 2 (Album / movie / show title) at 828
|    + Name: MultiTitleName at 832
|    + Sub title: MultiTitleSubTitle at 849
|    + Edition: MultiTitleEdition at 870
|    + Address: MultiTitleAddress at 890
|    + URL: MultiTitleURL at 910
|    + Email: MultiTitleEmail at 926
|    + Language: MultiTitleLanguage at 944
-------------- next part --------------
+ EBML head at 0
+ Segment at 24
|+ Tags at 33
| + Tag at 39
|  + Targets at 43
|   + Track UID: 1234 at 46
|   + Chapter UID: 5678 at 51
|  + General at 56
|   + Subject: Subject at 60
|   + Bibliography: Bibliography at 70
|   + Language: ger at 85
|   + Rating: length 5, data: 0x68 0x61 0x6c 0x6c 0x6f  at 92
|   + Encoder: Encoder at 100
|   + Encode settings: EncodeSettings at 110
|   + File: File at 127
|   + Archival location: ArchivalLocation at 134
|   + Keywords: Keywords, 1 at 153
|   + Keywords: Keywords, 2 at 167
|   + Mood: Mood at 181
|   + Record location: RecordLocation, 1 at 188
|   + Record location: RecordLocation, 2 at 208
|   + Source: Source at 228
|   + Source form: SourceForm at 237
|   + Product: Product at 250
|   + Original media type: OriginalMediaType at 260
|   + Play counter: 123456 at 280
|   + Popularimeter: 234567 at 286
|  + Genres at 292
|   + Audio genre: AudioGenre at 295
|   + Video genre: length 5, data: 0x68 0x61 0x6c 0x6c 0x6f  at 308
|   + Sub genre: SubGenre at 316
|  + Image specific at 327
|   + Capture DPI: 42 at 330
|   + Capture lightness: length 5, data: 0x68 0x61 0x6c 0x6c 0x6f  at 334
|   + Capture palette setting: 54 at 342
|   + Capture sharpness: length 5, data: 0x68 0x61 0x6c 0x6c 0x6f  at 346
|   + Cropped: Cropped at 354
|   + Original dimensions: OriginalDimensions at 364
|  + Audio specific at 385
|   + Audio encryption: length 5, data: 0x68 0x61 0x6c 0x6c 0x6f  at 388
|   + Audio gain: 42.000 at 396
|   + Audio peak: 54.000 at 403
|   + BPM: 23.000 at 410
|   + Equalisation: length 5, data: 0x68 0x61 0x6c 0x6c 0x6f  at 417
|   + Disc track: 2 at 425
|   + Set part: 4 at 429
|   + Initial key: InitialKey at 433
|   + Official audio file URL: OfficialAudioFileURL at 446
|   + Official audio source URL: OfficialAudioSourceURL at 469
|  + Multi commercial at 494
|   + Commercial at 497
|    + Type: 3 (Owner) at 500
|    + Address: MultiCommercialAddress at 504
|    + URL: MultiCommercialURL at 529
|    + Email: MultiCommercialEmail at 550
|    + Multi price at 573
|     + Currency: MultiPriceCurrency at 576
|     + Amount: 42.000 at 597
|     + Price date: Wed Jul  9 22:01:18 2003 UTC at 604
|   + Unknown element: N11libmatroska15KaxTagMultiDateE at 615
|  + Multi entity at 647
|   + Entity at 650
|    + Type: 1 (Lyricist / text writer) at 653
|    + Name: MultiEntityName at 657
|    + URL: MultiEntityURL at 675
|    + Email: MultiEntityEmail at 692
|    + Address: MultiEntityAddress at 711
|  + Multi identifier at 732
|   + Identifier at 735
|    + Type: 5 (EAN) at 738
|    + Binary: length 5, data: 0x68 0x61 0x6c 0x6c 0x6f  at 742
|    + String: MultiIdentifierString at 750
|  + Multi legal at 774
|   + Legal at 777
|    + Type: 3 (Terms of use) at 780
|    + URL: MultiLegalURL at 784
|    + Address: MultiLegalAddress at 800
|  + Multi title at 820
|   + Title at 824
|    + Type: 2 (Album / movie / show title) at 828
|    + Name: MultiTitleName at 832
|    + Sub title: MultiTitleSubTitle at 849
|    + Edition: MultiTitleEdition at 870
|    + Address: MultiTitleAddress at 890
|    + URL: MultiTitleURL at 910
|    + Email: MultiTitleEmail at 926
|    + Language: MultiTitleLanguage at 944
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.matroska.org/pipermail/matroska-devel/attachments/20030710/00eb6631/attachment.pgp>

From steve.lhomme at free.fr  Thu Jul 10 08:23:44 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Thu, 10 Jul 2003 08:23:44 +0200
Subject: [Matroska-devel] 0.5.0beta1 is borked
In-Reply-To: <20030709222106.GB26444@bunkus.org>
References: <20030709222106.GB26444@bunkus.org>
Message-ID: <3F0D0670.9040902@free.fr>

Moritz Bunkus wrote:
> Hi.
> 
> beta1 is as borked as alpha4 was. alpha3 is working ok.
> 
> My tag test executable was linked against beta1, mkvinfo was linked
> against alpha3 and beta1. For alpha3 the output is mostly ok, for beta1
> it's borked whenever a higher level element is encountered. Yes, all my
> upper_lvl_el tests are '... > 0' and not '... != 0'.
> 
> Using gdb shows that the next FindNextElement after the ChapterUID has
> been displayed is a dummy element.

What does test8 say ?
Because test8 works fine when using EbmlMaster::Read or when the reading 
is done in the while. Maybe your code use something that is not working 
anymore. Please check your code against EbmlMaster::Read.



From mosu at bunkus.net  Thu Jul 10 09:51:17 2003
From: mosu at bunkus.net (Moritz Bunkus)
Date: Thu, 10 Jul 2003 09:51:17 +0200
Subject: [Matroska-devel] 0.5.0beta1 is borked
In-Reply-To: <3F0D0670.9040902@free.fr>
References: <20030709222106.GB26444@bunkus.org> <3F0D0670.9040902@free.fr>
Message-ID: <20030710075117.GA24812@bunkus.org>

Hi.

> What does test8 say ?

Successfully opened file "test.mkv" in mode "rb". The handle is
0x8095228

EBML : [1A][45][DF][A3]

- Tags found
  All mandatory elements found
   Tag
    Targets
     Track UID (will be removed)
     Chapter UID
    -- Again After Deletion --
    Targets
     Chapter UID
    -- Done --
    General
     Subject
     Bibliography
     Language
    MultiCommercial
    MultiCommercial
    MultiDate
    MultiDate

> Because test8 works fine when using EbmlMaster::Read or when the reading 
> is done in the while. Maybe your code use something that is not working 
> anymore. Please check your code against EbmlMaster::Read.

You don't see those dummy elements because you don't print unknown
elements but just ignore them. I do print those, and the code I'm using
has been the same for the last 5 months or so.

The thing is that mkvinfo/0.5.0beta1 finds them all, too, just a lot of
dummy elements in between! Have a look at part of the output of
beta1.txt:

|  + Targets at 43
|   + Track UID: 1234 at 46
|   + Chapter UID: 5678 at 51
|   + Unknown element: N7libebml15DummyRawElementE at 56
|   + Unknown element: N7libebml15DummyRawElementE at 292
|   + Unknown element: N7libebml15DummyRawElementE at 385
|   + Unknown element: N7libebml15DummyRawElementE at 494
|   + Unknown element: N7libebml15DummyRawElementE at 615
|   + Unknown element: N7libebml15DummyRawElementE at 647
|   + Unknown element: N7libebml15DummyRawElementE at 732
|   + Unknown element: N7libebml15DummyRawElementE at 774
|   + Unknown element: N7libebml15DummyRawElementE at 820
|  + General at 56
|   + Subject: Subject at 60

The numbers are the file positions. So after ChapterUID has been found
the following code is executed (ChapterUID is a level 4 element called
'l4'):

                  if (upper_lvl_el > 0) {    // we're coming from l5
                    upper_lvl_el--;
                    delete l4;
                    l4 = l5;
                    if (upper_lvl_el > 0)
                      break;
                  
                  } else {
                    l4->SkipData(*es, l4->Generic().Context);
                    delete l4;
                    l4 = es->FindNextElement(l3->Generic().Context,
                                             upper_lvl_el, 0xFFFFFFFFL,
                    true,
                                             1);
                  }


I've checked with gdb and upper_lvl_el is == 0 at the moment, so the
else block is being executed. l4->SkipData, delete l4, l4 =
es->FindNextElement(...). That very FindNextElement returns that
dummyraw element.

The funny thing is that after it has read all those dummyrawelements
(which are at the same positions all the other level 3 elements are
at!!) it jumps BACK to where it found the first dummyrawelement, and
behold, now it finds the known KaxTagGenral.

As I said: Recompiling (make clean all) against alpha3 works fine - no
dummyrawelements at all (apart from the one element that was still
borked in alpha3, but that's not the point). alpha4 behaves just like
beta1.

-- 
 ==> Ciao, Mosu (Moritz Bunkus)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.matroska.org/pipermail/matroska-devel/attachments/20030710/9f6aadb3/attachment.pgp>

From moritz at bunkus.org  Mon Jul 14 09:20:59 2003
From: moritz at bunkus.org (Moritz Bunkus)
Date: Mon, 14 Jul 2003 09:20:59 +0200
Subject: [Matroska-devel] spelling mistake in the specs and the sources
Message-ID: <20030714072059.GA14863@bunkus.org>

Heya,

KaxAttachements should be KaxAttachments without an 'e'. Please correct
that, Steve :)

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


From steve.lhomme at free.fr  Wed Jul 16 17:56:57 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Wed, 16 Jul 2003 17:56:57 +0200
Subject: [Matroska-devel] CVS is up
Message-ID: <006101c34bb2$e3106430$0c7ba8c0@ing12>

As we don't know when the "original" CVS data will be available, I've
created the libebml and libmatroska modules in the matroska CVS on CoreCodec
(as it was before).

The current sources are 0.5.0-beta7 that includes the latest chapter version
and CRC read/write working for both "automatic" and "manual" reading.

MkxDs will follow when I have a new version working.

Be carefull with CVS there are some problems (especially when you deal with
more than one directory at a time). Please pay attention to the error
messages.




From steve.lhomme at free.fr  Thu Jul 17 16:00:17 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Thu, 17 Jul 2003 16:00:17 +0200
Subject: [Matroska-devel] Preliminary Chapter interface for the DirectShow
	splitters
Message-ID: <005401c34c6b$c0ff6300$0c7ba8c0@ing12>

After some work with Gabest we have come to this simple and already good API
to query informations about Chapters from the splitter.

I attach an include file that describes this API. Gabest will probably
publish a version with the DirectShow interface part (or Toff).


-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: SplitterChapter.h
URL: <http://lists.matroska.org/pipermail/matroska-devel/attachments/20030717/06ddc195/attachment.h>

From gabest at freemail.hu  Thu Jul 17 16:55:32 2003
From: gabest at freemail.hu (Gabest)
Date: Thu, 17 Jul 2003 16:55:32 +0200
Subject: [Matroska-devel] Preliminary Chapter interface for the
	DirectShowsplitters
References: <005401c34c6b$c0ff6300$0c7ba8c0@ing12>
Message-ID: <040401c34c73$792bced0$0100a8c0@i2400p4>


----- Original Message -----
From: "Steve Lhomme" <steve.lhomme at free.fr>
To: <matroska-devel at lists.matroska.org>
Sent: Thursday, July 17, 2003 4:00 PM
Subject: [Matroska-devel] Preliminary Chapter interface for the
DirectShowsplitters


> After some work with Gabest we have come to this simple and already good
API
> to query informations about Chapters from the splitter.
>
> I attach an include file that describes this API. Gabest will probably
> publish a version with the DirectShow interface part (or Toff).

And here it is, with a few notes:
- UINT times in the ChapterElement struct were corrected to be
REFERENCE_TIME, which is typedefed from int64.
- vc7 can recognize the uuid attribute, but if you are using vc6, you may
want to use the old commented-out interface header.
- This interface will probably be extended by inheritace later, to support
more of the features of matroska.

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: ichapterinfo.h
URL: <http://lists.matroska.org/pipermail/matroska-devel/attachments/20030717/cc91a1dc/attachment.h>

From steve.lhomme at free.fr  Fri Jul 18 14:26:46 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Fri, 18 Jul 2003 14:26:46 +0200
Subject: [matroska-devel] Re: Attachments
References: <ber708$qnd$1@main.gmane.org> <bf8me7$vbr$1@main.gmane.org>
Message-ID: <008301c34d27$dab2cc80$0c7ba8c0@ing12>

> > We need to come up with a standard naming convention for the CD cover
> > picture, as well as the other pictures, so that they can be loaded
> > automatically.  Perhaps something like:
> >
> > Does anyone have any ideas for how we could associate some tags to a
> > picture?  For instance, if you have the MultiEntity for the song writer,
and
> > you have his picture attached, what would be a good way to associate the
> > two?
> >
>
> If tags can be associated with attachments, why a standard naming
> convention?
> IMHO using a special tag to refer the cover would make sense, or won't it?

I'm not sure you can currently associate a Tag with an attachement (it would
require a unique ID for each attachment). But it could be easily added.



From gabest at freemail.hu  Fri Jul 18 15:39:52 2003
From: gabest at freemail.hu (Gabest)
Date: Fri, 18 Jul 2003 15:39:52 +0200
Subject: [matroska-devel] Re: Attachments
References: <ber708$qnd$1@main.gmane.org> <bf8me7$vbr$1@main.gmane.org>
	<008301c34d27$dab2cc80$0c7ba8c0@ing12>
Message-ID: <013401c34d32$10ce87a0$0100a8c0@i2400p4>

Hey people, what's up with the irc server?


From moritz at bunkus.org  Fri Jul 18 15:56:24 2003
From: moritz at bunkus.org (Moritz Bunkus)
Date: Fri, 18 Jul 2003 15:56:24 +0200
Subject: [matroska-devel] Re: Attachments
In-Reply-To: <013401c34d32$10ce87a0$0100a8c0@i2400p4>
References: <ber708$qnd$1@main.gmane.org> <bf8me7$vbr$1@main.gmane.org>
	<008301c34d27$dab2cc80$0c7ba8c0@ing12>
	<013401c34d32$10ce87a0$0100a8c0@i2400p4>
Message-ID: <20030718135624.GI9533@bunkus.org>

Hi.

> Hey people, what's up with the irc server?

It got hacked.

(Just kidding.)

Tracerouting gets me a 'no route to host' from a router still in
Germany, so it seems that some routing has been seriously fucked up.

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


From steve.lhomme at free.fr  Fri Jul 18 15:59:16 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Fri, 18 Jul 2003 15:59:16 +0200
Subject: [matroska-devel] Re: Attachments
References: <ber708$qnd$1@main.gmane.org>
	<bf8me7$vbr$1@main.gmane.org><008301c34d27$dab2cc80$0c7ba8c0@ing12>
	<013401c34d32$10ce87a0$0100a8c0@i2400p4>
Message-ID: <00a701c34d34$c70afc90$0c7ba8c0@ing12>

> Hey people, what's up with the irc server?

Yeah, I can't connect neither. I didn't know if it was my connection (8kbps
shared with many people) or something else...
Let's ask Betaboy about it... What is his e-mail ?




From gabest at freemail.hu  Fri Jul 18 16:10:23 2003
From: gabest at freemail.hu (Gabest)
Date: Fri, 18 Jul 2003 16:10:23 +0200
Subject: [matroska-devel] Re: Attachments
References: <ber708$qnd$1@main.gmane.org>
	<bf8me7$vbr$1@main.gmane.org><008301c34d27$dab2cc80$0c7ba8c0@ing12><013401c34d32$10ce87a0$0100a8c0@i2400p4>
	<20030718135624.GI9533@bunkus.org>
Message-ID: <014801c34d36$542af520$0100a8c0@i2400p4>

This is really bad :'( I need to ask Cyrius about why vdm can't save or
frameserve  mkv to avi or wav with pcm audio. Someone here would try to
capture into matroska with virtualvcr, but he's getting upset that he can't
do anything with the captured file currently. The goal would be to feed it
into CCE somehow, and then to author a dvd. Any idea?

> Tracerouting gets me a 'no route to host' from a router still in
> Germany, so it seems that some routing has been seriously fucked up.

The same here, tracert dies at the second step, still inside Hungary.



From moritz at bunkus.org  Sat Jul 19 10:18:18 2003
From: moritz at bunkus.org (Moritz Bunkus)
Date: Sat, 19 Jul 2003 10:18:18 +0200
Subject: [matroska-devel] bug in mkvextract?
In-Reply-To: <003a01c34d97$448fc8a0$0500a8c0@gabor>
References: <003a01c34d97$448fc8a0$0500a8c0@gabor>
Message-ID: <20030719081818.GJ9533@bunkus.org>

Hi.

Please use the new lists at http://lists.matroska.org/, not the lists at
@freelists.org. And no need to CC me on the mails, I'm
subscribed. Thanks :)


> I guess I've found bug 4GB DWORD in mkvextract ms windows version.
> The extraction from files that are larger than 4GB will fail and the progress indicator will go
> above 100%.

Ok, thanks, I'll use the fix you've sent in the other mail.

-- 
 ==> Ciao, Mosu (Moritz Bunkus)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.matroska.org/pipermail/matroska-devel/attachments/20030719/bfa787a4/attachment.pgp>

From moritz at bunkus.org  Sat Jul 19 10:56:14 2003
From: moritz at bunkus.org (Moritz Bunkus)
Date: Sat, 19 Jul 2003 10:56:14 +0200
Subject: [Matroska-devel] copying/cloning/moving ebml elements
Message-ID: <20030719085614.GK9533@bunkus.org>

Heya Steve,

for proper tag support I need some infrastructure regarding the Ebml*
thingies. Let's take the simple example that I read two Matroska files
and that both contain tags. Now I want to write the merged tags to the
new file, but I don't want two KaxTags but two KaxTag under a single
KaxTags.

So what I need is:

1. I find the KaxTags in both files and Read() them. Now I have the tags
   in memory in two variables, e.g. tags1 and tags2.
2. I create a destination KaxTags object, d_tags.
3. I copy all KaxTag children from tags1 into d_tags. Same for tags2.
4. I Render() d_tags into the output file.

This is the case of copying subtrees around. I also need to be able to
move a subtree from one EbmlMaster to another, e.g. move a KaxTag child
from tags1 to d_tags. The second case is different in that when I delete
tags1 and d_tags the subtree should of course only be deleted when I
delete the d_tags.

The 'moving' case seems to to be possible already if I understand
EbmlMaster.h correctly: The Remove() function can remove the KaxTag
child from the tags1 parent, and I can use PushElement to add the KaxTag
child to its new parent, d_tags. Is that correct?

But for copying we need proper copy ctors. I can easily write them for
EbmlString, EbmlUnicodeString, EbmlBinary, but not for EbmlMaster (at
least not easily). That's where I ask for your help ;)

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


From steve.lhomme at free.fr  Sat Jul 19 12:19:21 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Sat, 19 Jul 2003 12:19:21 +0200
Subject: [Matroska-devel] copying/cloning/moving ebml elements
In-Reply-To: <20030719085614.GK9533@bunkus.org>
References: <20030719085614.GK9533@bunkus.org>
Message-ID: <3F191B29.6090001@free.fr>

Moritz Bunkus wrote:
> Heya Steve,
> 
> for proper tag support I need some infrastructure regarding the Ebml*
> thingies. Let's take the simple example that I read two Matroska files
> and that both contain tags. Now I want to write the merged tags to the
> new file, but I don't want two KaxTags but two KaxTag under a single
> KaxTags.
> 
> So what I need is:
> 
> 1. I find the KaxTags in both files and Read() them. Now I have the tags
>    in memory in two variables, e.g. tags1 and tags2.
> 2. I create a destination KaxTags object, d_tags.
> 3. I copy all KaxTag children from tags1 into d_tags. Same for tags2.

No need, you can just push the 2 KaxTag you have (tags1[0] and tags2[0]) 
in a new KaxTags.

> 4. I Render() d_tags into the output file.
> 
> This is the case of copying subtrees around. I also need to be able to
> move a subtree from one EbmlMaster to another, e.g. move a KaxTag child
> from tags1 to d_tags. The second case is different in that when I delete
> tags1 and d_tags the subtree should of course only be deleted when I
> delete the d_tags.
> 
> The 'moving' case seems to to be possible already if I understand
> EbmlMaster.h correctly: The Remove() function can remove the KaxTag
> child from the tags1 parent, and I can use PushElement to add the KaxTag
> child to its new parent, d_tags. Is that correct?

Yes (I should have read until here).

> But for copying we need proper copy ctors. I can easily write them for
> EbmlString, EbmlUnicodeString, EbmlBinary, but not for EbmlMaster (at
> least not easily). That's where I ask for your help ;)

Mmmm, I already thought of that. What happens for an EbmlBinary ? We 
copy the binary data or the reference, and if so who is allowed to free it ?

The thing that is easier to implement is allow to remove an element from 
an EbmlMaster without freeing it. That's exactly what Remove() does. So 
you can take an EbmlElement from a Master and move it to another Master. 
You are responsible to free it if it's not contained in a Master. Also 
if the same element is in 2 masters, it will be freed twice. Not good. 
So be careful with that.




From rududuvideocodec at ifrance.com  Sat Jul 19 18:44:03 2003
From: rududuvideocodec at ifrance.com (nicolas)
Date: Sat, 19 Jul 2003 18:44:03 +0200
Subject: [Matroska-devel] codec API
Message-ID: <3F197553.6020303@ifrance.com>

Hello!

Some days ago there was a discution about the new API to be able to use 
all the new Matroska features.
Here is what Ronald Bultje said :

[quote]

    PS Christian, you've asked me to come up with a document, I'll try to do
    that in the course of this week. Give me a few days, I have a job, too.
    . I'll take some ideas from the list and mix them together with some
    of my own.

[/quote]

I am planning to release a version 1.0 of Rududu codec as soon as 
possible. This version will be for vfw and will not be able to use B 
frames. But contrary to what I have said before, I will implement B 
frames in Rududu. This will come after the 1.0 release.
So I am interrested in moving to a new API/file format able to handle B 
frames (and multiple refs for the future).
As pamel said in this thread 
<http://forum.doom9.org/showthread.php?threadid=52325&goto=newpost> 
there are solutions to put Rududu encoded datas in Matroska, but I'm 
looking for a more clean and definitive solution.

So I would like to see if something as been done for this API and if I 
can help giving my point of view of codec developper. I could probably 
help more, but I'm not an experienced developper and I don't know 
anything about API creation.

Nicolas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.matroska.org/pipermail/matroska-devel/attachments/20030719/bb2587f7/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: wink_n.gif
Type: image/gif
Size: 139 bytes
Desc: not available
URL: <http://lists.matroska.org/pipermail/matroska-devel/attachments/20030719/bb2587f7/attachment.gif>

From rududuvideocodec at ifrance.com  Sat Jul 19 22:00:05 2003
From: rududuvideocodec at ifrance.com (nicolas)
Date: Sat, 19 Jul 2003 22:00:05 +0200
Subject: [Matroska-devel] codec API
In-Reply-To: <3F197553.6020303@ifrance.com>
References: <3F197553.6020303@ifrance.com>
Message-ID: <3F19A345.7020106@ifrance.com>

Me again ...

http://bytesex.org/v4l/

Is this API able to do all what is needed ? Is it widely used under Linux ?



From chris at matroska.org  Tue Jul 22 15:12:32 2003
From: chris at matroska.org (Christian HJ Wiesner)
Date: Tue, 22 Jul 2003 15:12:32 +0200
Subject: [Matroska-devel] Matroska Release 4th August 2003 ( CHIP release )
 - table of working/missing features
Message-ID: <3F1D3840.805@matroska.org>

An HTML attachment was scrubbed...
URL: <http://lists.matroska.org/pipermail/matroska-devel/attachments/20030722/e823db06/attachment.html>

From spyder at matroska.org  Tue Jul 22 16:36:21 2003
From: spyder at matroska.org (John Cannon)
Date: Tue, 22 Jul 2003 09:36:21 -0500
Subject: [Matroska-devel] Re: [Matroska-general] Matroska Release 4th August
	2003 ( CHIP release ) - table of working/missing features
References: <3F1D3840.805@matroska.org>
Message-ID: <002501c3505e$9fcee470$95a8be3f@johnc>

Hi,

I am working right now on a buffer system to split an mpeg2 video stream into frame and header packets.  The system should be reusable in other tools to packetize the mpeg2 video for placement in Matroska.  When I finish this code, I will write a LemAPI plugin to play with.  I would also make an mkvmerge packetizer but Mosu's API scares me ;)

We discussed the technical points of placing mpeg2 in matroska and I think the best way would be to put the sequence header in the CodecPrivate and then put the GOP headers with the I frame of the GOP.  As far as other features, they can be added but this is basically a reader for mpeg2, the rest will not be part of this code.

John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.matroska.org/pipermail/matroska-devel/attachments/20030722/c779541f/attachment.html>

From rbultje at ronald.bitfreak.net  Tue Jul 22 16:46:20 2003
From: rbultje at ronald.bitfreak.net (Ronald Bultje)
Date: 22 Jul 2003 16:46:20 +0200
Subject: [Matroska-devel] Re: [Matroska-general] Matroska Release 4th
	August 2003 ( CHIP release ) - table of working/missing features
In-Reply-To: <002501c3505e$9fcee470$95a8be3f@johnc>
References: <3F1D3840.805@matroska.org> <002501c3505e$9fcee470$95a8be3f@johnc>
Message-ID: <1058885180.2238.241.camel@shrek.bitfreak.net>

Hey John,

On Tue, 2003-07-22 at 16:36, John Cannon wrote:
> We discussed the technical points of placing mpeg2 in matroska and I
> think the best way would be to put the sequence header in the
> CodecPrivate and then put the GOP headers with the I frame of the
> GOP.  As far as other features, they can be added but this is
> basically a reader for mpeg2, the rest will not be part of this code.

You're assuming that an MPEG stream has only one sequence header, which
isn't correct, afaik.

Ronald

-- 
Ronald Bultje <rbultje at ronald.bitfreak.net>



From chris at matroska.org  Wed Jul 23 04:10:21 2003
From: chris at matroska.org (Christian HJ Wiesner)
Date: Wed, 23 Jul 2003 04:10:21 +0200
Subject: [Matroska-devel] Re: Seeking ogg-vorbis
In-Reply-To: <5.2.0.9.0.20030722175421.00d89d28@msa.com.mx>
References: <bfkdtk$5bd$1@main.gmane.org> <bfkdtk$5bd$1@main.gmane.org>
	<5.2.0.9.0.20030722175421.00d89d28@msa.com.mx>
Message-ID: <3F1DEE8D.2030002@matroska.org>

On what platforms are you ( both recording and playback ) ? matroska 
container is timestamp based, if you start recording at timestamp 
0:00.00.000 h ( in ns ) at every morning , you can easily jump to what 
was happening at 16:30 h by seeking the CUE table for this timestamp. 
Our DirectShow filter should allow to jump to a specifictime even after 
a small modification, with a  specific player ( we know the MPC guy and 
the TCMP guys ( http://corecoded.com ) . Let me know if we can  help.

Christian

Rodrigo G?mez wrote:

> Hi Christian.
>
> Thanks for the quick reply.
>
> This is my first time in this audio-related projects, so I'm a totally 
> newbie here.
>
> What do you mean here? Not using ogg but another container? Is this 
> easy? As I said, I have the recording engine working, and it was more 
> or less painless. The problem here, as almost any developer, is that 
> I'm in a deadline... the sales people has actually started to sell 
> this :-|... They will never understand, I guess. :)
>
> I don't know if this is easy to do, but I need something like Winamp 
> does. You can jump to a specific time in the file, no matter how long 
> is it.
>
> I didn't mentioned this in the ng, but I only need to specify the 
> start time, and, if the user wants to move to another time, the 
> decoder will stop, and it will start as if it was the first time.
>
> Thanks!
>
> Rodrigo G?mez
>
> At 12:52 a.m. 23/07/2003 +0200, you wrote:
>
>> Rodrigo G?mez wrote:
>>
>>> Hi there.
>>> I have been hearing to ogg vorbis for maybe 2 years and I can only 
>>> say: it
>>> is fantastic!
>>> Right now, I'm working in a project that uses ogg vorbis as the 
>>> format for
>>> recording. I have now a working recording engine (I have recorded up 
>>> to 8
>>> channels at the same time and my computer uses only about 30% of the
>>> processor, wich is great in this project), and I'm starting with the 
>>> playing
>>> engine.
>>> I have seen the examples, but they are somewhat "simplistic" (no 
>>> mean to
>>> offense anybody!). I need to solve the following scheme:
>>>     - The files I'm playing represent up to 24 hours of
>>
>>
>> You may want to consider storing your Vorbis streams in another 
>> container with enhanced seeking via CUE tables ?
>>
>> Christian
>> http://www.matroska.org
>>
>>
>
>




From spyder at matroska.org  Wed Jul 23 17:51:42 2003
From: spyder at matroska.org (John Cannon)
Date: Wed, 23 Jul 2003 10:51:42 -0500
Subject: [Matroska-devel] Re: [Matroska-general] Matroska Release
	4thAugust 2003 ( CHIP release ) - table of working/missing features
References: <3F1D3840.805@matroska.org> <002501c3505e$9fcee470$95a8be3f@johnc>
	<1058885180.2238.241.camel@shrek.bitfreak.net>
Message-ID: <001101c35132$50b9bbb0$0100a8c0@JOHNC2>

The sequence headers are all the same unless the stream changes I think.  If
not, they can always be attached to the nearest frame...  Since we can't
allow different streams types in the same track anyway, this shouldn't be a
problem.  I will check it out before we finalize this though.


----- Original Message -----
From: "Ronald Bultje" <rbultje at ronald.bitfreak.net>
To: "Discussion about the current and future development of Matroska"
<matroska-devel at lists.matroska.org>
Sent: Tuesday, July 22, 2003 9:46 AM
Subject: Re: [Matroska-devel] Re: [Matroska-general] Matroska Release
4thAugust 2003 ( CHIP release ) - table of working/missing features


> Hey John,
>
> On Tue, 2003-07-22 at 16:36, John Cannon wrote:
> > We discussed the technical points of placing mpeg2 in matroska and I
> > think the best way would be to put the sequence header in the
> > CodecPrivate and then put the GOP headers with the I frame of the
> > GOP.  As far as other features, they can be added but this is
> > basically a reader for mpeg2, the rest will not be part of this code.
>
> You're assuming that an MPEG stream has only one sequence header, which
> isn't correct, afaik.
>
> Ronald
>
> --
> Ronald Bultje <rbultje at ronald.bitfreak.net>
>
> _______________________________________________
> Matroska-devel mailing list
> Matroska-devel at lists.matroska.org
> http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel



From spyder at matroska.org  Wed Jul 23 17:54:58 2003
From: spyder at matroska.org (John Cannon)
Date: Wed, 23 Jul 2003 10:54:58 -0500
Subject: [Matroska-devel] Re: [Matroska-general] Matroska Release4thAugust
	2003 ( CHIP release ) - table of working/missing features
References: <3F1D3840.805@matroska.org>
	<002501c3505e$9fcee470$95a8be3f@johnc><1058885180.2238.241.camel@shrek.bitfreak.net>
	<001101c35132$50b9bbb0$0100a8c0@JOHNC2>
Message-ID: <002101c35132$c549f940$0100a8c0@JOHNC2>

Or then again, we have that CodecState mechanism for this I think.
----- Original Message -----
From: "John Cannon" <spyder at matroska.org>
To: "Discussion about the current and future development of Matroska"
<matroska-devel at lists.matroska.org>
Sent: Wednesday, July 23, 2003 10:51 AM
Subject: Re: [Matroska-devel] Re: [Matroska-general] Matroska
Release4thAugust 2003 ( CHIP release ) - table of working/missing features


> The sequence headers are all the same unless the stream changes I think.
If
> not, they can always be attached to the nearest frame...  Since we can't
> allow different streams types in the same track anyway, this shouldn't be
a
> problem.  I will check it out before we finalize this though.
>
>
> ----- Original Message -----
> From: "Ronald Bultje" <rbultje at ronald.bitfreak.net>
> To: "Discussion about the current and future development of Matroska"
> <matroska-devel at lists.matroska.org>
> Sent: Tuesday, July 22, 2003 9:46 AM
> Subject: Re: [Matroska-devel] Re: [Matroska-general] Matroska Release
> 4thAugust 2003 ( CHIP release ) - table of working/missing features
>
>
> > Hey John,
> >
> > On Tue, 2003-07-22 at 16:36, John Cannon wrote:
> > > We discussed the technical points of placing mpeg2 in matroska and I
> > > think the best way would be to put the sequence header in the
> > > CodecPrivate and then put the GOP headers with the I frame of the
> > > GOP.  As far as other features, they can be added but this is
> > > basically a reader for mpeg2, the rest will not be part of this code.
> >
> > You're assuming that an MPEG stream has only one sequence header, which
> > isn't correct, afaik.
> >
> > Ronald
> >
> > --
> > Ronald Bultje <rbultje at ronald.bitfreak.net>
> >
> > _______________________________________________
> > Matroska-devel mailing list
> > Matroska-devel at lists.matroska.org
> > http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel
>
> _______________________________________________
> Matroska-devel mailing list
> Matroska-devel at lists.matroska.org
> http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel



From moritz at bunkus.org  Wed Jul 23 22:34:14 2003
From: moritz at bunkus.org (Moritz Bunkus)
Date: Wed, 23 Jul 2003 22:34:14 +0200
Subject: [Matroska-devel] Re: [Matroska-general] Matroska Release 4th
	August 2003 ( CHIP release ) - table of working/missing features
In-Reply-To: <002501c3505e$9fcee470$95a8be3f@johnc>
References: <3F1D3840.805@matroska.org> <002501c3505e$9fcee470$95a8be3f@johnc>
Message-ID: <20030723203414.GO9533@bunkus.org>

Heya.

I've updated my column. As it turned out my next week will be even
fuller with job related programming stuff than my last one. On top of
that I'll be away from July 31st until late August 3rd, so no
programming there either.

I've cut back on almost everything on the list. The two things I'd
REALLY like to have working until the release are tags and
chapters. While I've just written my first file with tags (read from a
XML file, not hardcoded, but the way that users will add tags themselves
later) I simply won't have the time to spend on chapter support.

Maybe (and this is a VERY uncertain 'maybe') I can get a limited chapter
support working until then (which would allow neither nesting nor
specifying the languages, so it'd be basically what OGM chapter support
looks like atm). But no promises whatsoever.

Tag support will still take some time (documentation, support for
extracting tags back to XML with mkvextract) so that's where my energy
will be spent.

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


From steve.lhomme at free.fr  Thu Jul 24 00:21:52 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Thu, 24 Jul 2003 00:21:52 +0200
Subject: [Matroska-devel] Re: [Matroska-general] Matroska Release 4th
	August 2003 ( CHIP release ) - table of working/missing features
In-Reply-To: <20030723203414.GO9533@bunkus.org>
References: <3F1D3840.805@matroska.org> <002501c3505e$9fcee470$95a8be3f@johnc>
	<20030723203414.GO9533@bunkus.org>
Message-ID: <3F1F0A80.7040904@free.fr>

Moritz Bunkus wrote:
> 
> Maybe (and this is a VERY uncertain 'maybe') I can get a limited chapter
> support working until then (which would allow neither nesting nor
> specifying the languages, so it'd be basically what OGM chapter support
> looks like atm). But no promises whatsoever.
> 
> Tag support will still take some time (documentation, support for
> extracting tags back to XML with mkvextract) so that's where my energy
> will be spent.

If you can make the text working, I think it will be easy for any 
programmer to do the same with Chapters which are much less complicated 
than tags and probably will work the same way (XML source). So we'll see 
how things go until the 4th.



From steve.lhomme at free.fr  Thu Jul 24 10:34:22 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Thu, 24 Jul 2003 10:34:22 +0200
Subject: [Matroska-devel] Re: [Matroska-general] Matroska Release
	4thAugust 2003 ( CHIP release ) - table of working/missing features
References: <3F1D3840.805@matroska.org> <002501c3505e$9fcee470$95a8be3f@johnc>
	<20030723203414.GO9533@bunkus.org>
Message-ID: <003a01c351be$625f1360$0c7ba8c0@ing12>

As it was not mentioned on the ML already, here is the up to date version of
the features table :

http://cvs.corecodec.org/cgi-bin/viewcvs.cgi/*checkout*/matroska/doc/website
/features.html

(please note that from now it's a valid XHTML document)

We'll be done when everything is green :>



From chris at matroska.org  Thu Jul 24 18:04:42 2003
From: chris at matroska.org (Christian HJ Wiesner)
Date: Thu, 24 Jul 2003 18:04:42 +0200
Subject: [Matroska-devel] Re: [Matroska-general] Matroska Release	4thAugust
	2003 ( CHIP release ) - table of working/missing features
In-Reply-To: <003a01c351be$625f1360$0c7ba8c0@ing12>
References: <3F1D3840.805@matroska.org>
	<002501c3505e$9fcee470$95a8be3f@johnc>	<20030723203414.GO9533@bunkus.org>
	<003a01c351be$625f1360$0c7ba8c0@ing12>
Message-ID: <3F20039A.1060403@matroska.org>

Steve Lhomme wrote:

>As it was not mentioned on the ML already, here is the up to date version of
>the features table :
>http://cvs.corecodec.org/cgi-bin/viewcvs.cgi/*checkout*/matroska/doc/website/features.html
>(please note that from now it's a valid XHTML document)
>We'll be done when everything is green :>
>

Jesus ... i do see very little green still :D !!! At least, nobody from 
us is going to be bored for the next year or so ;) ......

Christian

@jcsston, fenrir, BBB, DaveEL : any chance you can comment briefly also 
on your plans until 4th august ?




From moritz at bunkus.org  Thu Jul 24 22:39:38 2003
From: moritz at bunkus.org (Moritz Bunkus)
Date: Thu, 24 Jul 2003 22:39:38 +0200
Subject: [Matroska-devel] EbmlMaster...
Message-ID: <20030724203938.GS9533@bunkus.org>

Hi.

robux, I need a way to create an EbmlMaster, but that Master must not
create its mandatory children. I need that for tag parsing.

Now I've though about adding a "bool bCreateMandatory = false" to
EbmlMaster's ctor, but that won't work with GetChild. Problem is that
FindFirstElt uses the Create method to create the elements, which of
course can't pass the bCreateMandatory through...

Why do I need this?

Well when reading the XML document I create the elements on the fly. So
e.g. I encounter <MultiDate>, <Date> and then <DateType>. When I've
encountered <Data> I create a KaxTagDate. Later, when I encounter
<DateType>, I use FindElt<KaxTagMultiDateType>(date) to see if such an
element already exists. Of course it does - because it was automatically
created. But I'd like to show my user a nice error message, like 'sorry,
only one instance of DateType allowed under Date'. This is not possible
now - or only with double book keeping on my side. This will enlarge my
code by 150%, and I cannot do that before the release.

So please help me... I need a way to elegantly create these children
without the mandatory elements!

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


From moritz at bunkus.org  Thu Jul 24 23:12:00 2003
From: moritz at bunkus.org (Moritz Bunkus)
Date: Thu, 24 Jul 2003 23:12:00 +0200
Subject: [Matroska-devel] EbmlMaster...
In-Reply-To: <20030724203938.GS9533@bunkus.org>
References: <20030724203938.GS9533@bunkus.org>
Message-ID: <20030724211200.GT9533@bunkus.org>

Hi.

Here's a solution to my problem that strangely smells like HACK, but I
don't care at the moment:

template <typename Type>Type &GetEmptyChild(EbmlMaster &master) {
  EbmlElement *e;

  e = master.FindFirstElt(Type::ClassInfos, true);
  try {
    EbmlMaster *m = &dynamic_cast<EbmlMaster &>(*e);
    if (m != NULL)
      while (m->ListSize() > 0) {
        delete (*m)[0];
        m->Remove(0);
      }
  } catch (...) {
  }

  return *(static_cast<Type *>(e));
}

template <typename Type>Type &GetNextEmptyChild(EbmlMaster &master,
                                                const Type &past_elt) {
  EbmlElement *e;

  e = master.FindNextElt(past_elt, true);
  try {
    EbmlMaster *m = &dynamic_cast<EbmlMaster &>(*e);
    if (m != NULL)
      while (m->ListSize() > 0) {
        delete (*m)[0];
        m->Remove(0);
      }
  } catch (...) {
  }

  return *(static_cast<Type *>(e));
}

I will definitely not add that to EbmlMaster.h but only use it in my
source files.

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


From moritz at bunkus.org  Thu Jul 24 23:55:36 2003
From: moritz at bunkus.org (Moritz Bunkus)
Date: Thu, 24 Jul 2003 23:55:36 +0200
Subject: [Matroska-devel] problems with Read() and tags!
Message-ID: <20030724215536.GU9533@bunkus.org>

Hi.

Me again.

There's a bug/problem in the libs when using Read() to read the KaxTags.

Here's the test scenario: Modify test9.cpp like this:

    KaxTagTargets &targets = GetChild<KaxTagTargets>(tag);
    *(static_cast<EbmlUInteger *>(&GetChild<KaxTagTrackUID>(targets))) =
      1;

      // comment of the Targets
//      KaxTagMultiComment &mcomB =
GetChild<KaxTagMultiComment>(targets);
//     *(static_cast<EbmlString *>
//       (&GetChild<KaxTagMultiCommentName>(mcomB))) =
//       "Comment Level 5";

//     *(static_cast<EbmlUInteger
*>(&GetChild<KaxTagChapterUID>(targets))) =
//       5678;

//      KaxTagMultiComment &mcomA = GetChild<KaxTagMultiComment>(tag);
//     *(static_cast<EbmlString *>
//       (&GetChild<KaxTagMultiCommentName>(mcomA))) =
//       "Comment Level 3";

The changes only disable some MultiComments and the ChapterUID. This is
test8's output:

- Tags found
  * All mandatory elements found *
   Tag
    Targets
     Track UID
    General
     Subject
     Bibliography
     Language
    MultiCommercial
     Commercial
      Type
      Prices
       Currency
       Amount
    MultiDate

Looks fine to me.

Repeat this excercise, but set the TrackUID to 0, its default value, so
it won't be written to the file. This leaves Targets empty in the
file. Now fire up test8 and look at the output:

- Tags found
  * All mandatory elements found *
   Tag
    Targets
    General
    General
    MultiCommercial
    MultiCommercial
    MultiDate
    MultiDate

There's definitely something wrong here...

BTW: Here's a nice little dumper function for such purposes:

static void dumpsizes(EbmlElement *e, int level) {
  int i;

  for (i = 0; i < level; i++)
    printf(" ");
  printf("%s", typeid(*e).name());

  try {
    EbmlMaster *m = &dynamic_cast<EbmlMaster &>(*e);
    if (m != NULL) {
      printf(" (size: %u)\n", m->ListSize());
      for (i = 0; i < m->ListSize(); i++)
        dumpsizes((*m)[i], level + 1);
    } else
      printf("\n");
  } catch (...) {
      printf("\n");
  }
}

Its output for the 'TrackUID = 1' case is:

N11libmatroska7KaxTagsE (size: 1)
 N11libmatroska6KaxTagE (size: 11)
  N11libmatroska13KaxTagTargetsE (size: 1)
   N11libmatroska14KaxTagTrackUIDE
  N11libmatroska13KaxTagGeneralE (size: 19)
   N11libmatroska13KaxTagSubjectE
   N11libmatroska18KaxTagBibliographyE
   N11libmatroska14KaxTagLanguageE
   N11libmatroska12KaxTagRatingE
   N11libmatroska13KaxTagEncoderE
   N11libmatroska20KaxTagEncodeSettingsE
   N11libmatroska10KaxTagFileE
   N11libmatroska22KaxTagArchivalLocationE
   N11libmatroska14KaxTagKeywordsE
   N11libmatroska14KaxTagKeywordsE
   N11libmatroska10KaxTagMoodE
   N11libmatroska20KaxTagRecordLocationE
   N11libmatroska20KaxTagRecordLocationE
   N11libmatroska12KaxTagSourceE
   N11libmatroska16KaxTagSourceFormE
   N11libmatroska13KaxTagProductE
   N11libmatroska23KaxTagOriginalMediaTypeE
   N11libmatroska17KaxTagPlayCounterE
   N11libmatroska19KaxTagPopularimeterE
  N11libmatroska12KaxTagGenresE (size: 3)
   N11libmatroska16KaxTagAudioGenreE
   N11libmatroska16KaxTagVideoGenreE
   N11libmatroska14KaxTagSubGenreE
  N11libmatroska19KaxTagAudioSpecificE (size: 10)
   N11libmatroska21KaxTagAudioEncryptionE
   N11libmatroska15KaxTagAudioGainE
   N11libmatroska15KaxTagAudioPeakE
   N11libmatroska9KaxTagBPME
   N11libmatroska18KaxTagEqualisationE
   N11libmatroska15KaxTagDiscTrackE
   N11libmatroska13KaxTagSetPartE
   N11libmatroska16KaxTagInitialKeyE
   N11libmatroska26KaxTagOfficialAudioFileURLE
   N11libmatroska28KaxTagOfficialAudioSourceURLE
  N11libmatroska19KaxTagImageSpecificE (size: 6)
   N11libmatroska16KaxTagCaptureDPIE
   N11libmatroska22KaxTagCaptureLightnessE
   N11libmatroska27KaxTagCapturePaletteSettingE
   N11libmatroska22KaxTagCaptureSharpnessE
   N11libmatroska13KaxTagCroppedE
   N11libmatroska24KaxTagOriginalDimensionsE
  N11libmatroska21KaxTagMultiCommercialE (size: 1)
   N11libmatroska16KaxTagCommercialE (size: 5)
    N11libmatroska25KaxTagMultiCommercialTypeE
    N11libmatroska28KaxTagMultiCommercialAddressE
    N11libmatroska24KaxTagMultiCommercialURLE
    N11libmatroska26KaxTagMultiCommercialEmailE
    N11libmatroska16KaxTagMultiPriceE (size: 3)
     N11libmatroska24KaxTagMultiPriceCurrencyE
     N11libmatroska22KaxTagMultiPriceAmountE
     N11libmatroska25KaxTagMultiPricePriceDateE
  N11libmatroska15KaxTagMultiDateE (size: 1)
   N11libmatroska10KaxTagDateE (size: 3)
    N11libmatroska19KaxTagMultiDateTypeE
    N11libmatroska24KaxTagMultiDateDateBeginE
    N11libmatroska22KaxTagMultiDateDateEndE
  N11libmatroska17KaxTagMultiEntityE (size: 1)
   N11libmatroska12KaxTagEntityE (size: 5)
    N11libmatroska21KaxTagMultiEntityTypeE
    N11libmatroska21KaxTagMultiEntityNameE
    N11libmatroska20KaxTagMultiEntityURLE
    N11libmatroska22KaxTagMultiEntityEmailE
    N11libmatroska24KaxTagMultiEntityAddressE
  N11libmatroska21KaxTagMultiIdentifierE (size: 1)
   N11libmatroska16KaxTagIdentifierE (size: 3)
    N11libmatroska25KaxTagMultiIdentifierTypeE
    N11libmatroska27KaxTagMultiIdentifierBinaryE
    N11libmatroska27KaxTagMultiIdentifierStringE
  N11libmatroska16KaxTagMultiLegalE (size: 1)
   N11libmatroska11KaxTagLegalE (size: 3)
    N11libmatroska20KaxTagMultiLegalTypeE
    N11libmatroska19KaxTagMultiLegalURLE
    N11libmatroska23KaxTagMultiLegalAddressE
  N11libmatroska16KaxTagMultiTitleE (size: 1)
   N11libmatroska11KaxTagTitleE (size: 8)
    N11libmatroska20KaxTagMultiTitleTypeE
    N11libmatroska20KaxTagMultiTitleNameE
    N11libmatroska24KaxTagMultiTitleSubTitleE
    N11libmatroska23KaxTagMultiTitleEditionE
    N11libmatroska23KaxTagMultiTitleAddressE
    N11libmatroska19KaxTagMultiTitleURLE
    N11libmatroska21KaxTagMultiTitleEmailE
    N11libmatroska24KaxTagMultiTitleLanguageE

Now the output for the 'TrackUID = 0' case:

N11libmatroska7KaxTagsE (size: 1)
 N11libmatroska6KaxTagE (size: 21)
  N11libmatroska13KaxTagTargetsE (size: 0)
  N11libmatroska13KaxTagGeneralE (size: 0)
  N11libmatroska13KaxTagGeneralE (size: 0)
  N11libmatroska12KaxTagGenresE (size: 0)
  N11libmatroska12KaxTagGenresE (size: 0)
  N11libmatroska19KaxTagAudioSpecificE (size: 0)
  N11libmatroska19KaxTagAudioSpecificE (size: 0)
  N11libmatroska19KaxTagImageSpecificE (size: 0)
  N11libmatroska19KaxTagImageSpecificE (size: 0)
  N11libmatroska21KaxTagMultiCommercialE (size: 0)
  N11libmatroska21KaxTagMultiCommercialE (size: 0)
  N11libmatroska15KaxTagMultiDateE (size: 0)
  N11libmatroska15KaxTagMultiDateE (size: 0)
  N11libmatroska17KaxTagMultiEntityE (size: 0)
  N11libmatroska17KaxTagMultiEntityE (size: 0)
  N11libmatroska21KaxTagMultiIdentifierE (size: 0)
  N11libmatroska21KaxTagMultiIdentifierE (size: 0)
  N11libmatroska16KaxTagMultiLegalE (size: 0)
  N11libmatroska16KaxTagMultiLegalE (size: 0)
  N11libmatroska16KaxTagMultiTitleE (size: 0)
  N11libmatroska16KaxTagMultiTitleE (size: 0)

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


From steve.lhomme at free.fr  Fri Jul 25 09:30:11 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Fri, 25 Jul 2003 09:30:11 +0200
Subject: [Matroska-devel] EbmlMaster...
References: <20030724203938.GS9533@bunkus.org>
Message-ID: <001201c3527e$94f66b00$0c7ba8c0@ing12>

> Hi.
>
> robux, I need a way to create an EbmlMaster, but that Master must not
> create its mandatory children. I need that for tag parsing.
>
> Now I've though about adding a "bool bCreateMandatory = false" to
> EbmlMaster's ctor, but that won't work with GetChild. Problem is that
> FindFirstElt uses the Create method to create the elements, which of
> course can't pass the bCreateMandatory through...
>
> Why do I need this?

The mandatory elements are created at every creation even if you don't want
them (enforce the law). If you don't want them after creation, just clear()
the list of elements. If a method to do this doesn't exist in EbmlMaster, it
can be created easily.

> Well when reading the XML document I create the elements on the fly. So
> e.g. I encounter <MultiDate>, <Date> and then <DateType>. When I've
> encountered <Data> I create a KaxTagDate. Later, when I encounter
> <DateType>, I use FindElt<KaxTagMultiDateType>(date) to see if such an
> element already exists. Of course it does - because it was automatically
> created. But I'd like to show my user a nice error message, like 'sorry,
> only one instance of DateType allowed under Date'. This is not possible
> now - or only with double book keeping on my side. This will enlarge my
> code by 150%, and I cannot do that before the release.

See above, if you create the elements manually, you could remove everything
after creation and start with that... Mandatory elements will still be
checked on writing.




From steve.lhomme at free.fr  Fri Jul 25 09:37:38 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Fri, 25 Jul 2003 09:37:38 +0200
Subject: [Matroska-devel] problems with Read() and tags!
References: <20030724215536.GU9533@bunkus.org>
Message-ID: <004501c3527f$a1e5c4e0$0c7ba8c0@ing12>

OK, I'll check that tonight.
Thx a lot.

----- Original Message ----- 
From: "Moritz Bunkus" <moritz at bunkus.org>
To: "Matroska devel" <matroska-devel at lists.matroska.org>
Sent: Thursday, July 24, 2003 11:55 PM
Subject: [Matroska-devel] problems with Read() and tags!


> Hi.
> 
> Me again.
> 
> There's a bug/problem in the libs when using Read() to read the KaxTags.
> 
> Here's the test scenario: Modify test9.cpp like this:
> 
>     KaxTagTargets &targets = GetChild<KaxTagTargets>(tag);
>     *(static_cast<EbmlUInteger *>(&GetChild<KaxTagTrackUID>(targets))) =
>       1;
> 
>       // comment of the Targets
> //      KaxTagMultiComment &mcomB =
> GetChild<KaxTagMultiComment>(targets);
> //     *(static_cast<EbmlString *>
> //       (&GetChild<KaxTagMultiCommentName>(mcomB))) =
> //       "Comment Level 5";
> 
> //     *(static_cast<EbmlUInteger
> *>(&GetChild<KaxTagChapterUID>(targets))) =
> //       5678;
> 
> //      KaxTagMultiComment &mcomA = GetChild<KaxTagMultiComment>(tag);
> //     *(static_cast<EbmlString *>
> //       (&GetChild<KaxTagMultiCommentName>(mcomA))) =
> //       "Comment Level 3";
> 
> The changes only disable some MultiComments and the ChapterUID. This is
> test8's output:
> 
> - Tags found
>   * All mandatory elements found *
>    Tag
>     Targets
>      Track UID
>     General
>      Subject
>      Bibliography
>      Language
>     MultiCommercial
>      Commercial
>       Type
>       Prices
>        Currency
>        Amount
>     MultiDate
> 
> Looks fine to me.
> 
> Repeat this excercise, but set the TrackUID to 0, its default value, so
> it won't be written to the file. This leaves Targets empty in the
> file. Now fire up test8 and look at the output:
> 
> - Tags found
>   * All mandatory elements found *
>    Tag
>     Targets
>     General
>     General
>     MultiCommercial
>     MultiCommercial
>     MultiDate
>     MultiDate
> 
> There's definitely something wrong here...
> 
> BTW: Here's a nice little dumper function for such purposes:
> 
> static void dumpsizes(EbmlElement *e, int level) {
>   int i;
> 
>   for (i = 0; i < level; i++)
>     printf(" ");
>   printf("%s", typeid(*e).name());
> 
>   try {
>     EbmlMaster *m = &dynamic_cast<EbmlMaster &>(*e);
>     if (m != NULL) {
>       printf(" (size: %u)\n", m->ListSize());
>       for (i = 0; i < m->ListSize(); i++)
>         dumpsizes((*m)[i], level + 1);
>     } else
>       printf("\n");
>   } catch (...) {
>       printf("\n");
>   }
> }
> 
> Its output for the 'TrackUID = 1' case is:
> 
> N11libmatroska7KaxTagsE (size: 1)
>  N11libmatroska6KaxTagE (size: 11)
>   N11libmatroska13KaxTagTargetsE (size: 1)
>    N11libmatroska14KaxTagTrackUIDE
>   N11libmatroska13KaxTagGeneralE (size: 19)
>    N11libmatroska13KaxTagSubjectE
>    N11libmatroska18KaxTagBibliographyE
>    N11libmatroska14KaxTagLanguageE
>    N11libmatroska12KaxTagRatingE
>    N11libmatroska13KaxTagEncoderE
>    N11libmatroska20KaxTagEncodeSettingsE
>    N11libmatroska10KaxTagFileE
>    N11libmatroska22KaxTagArchivalLocationE
>    N11libmatroska14KaxTagKeywordsE
>    N11libmatroska14KaxTagKeywordsE
>    N11libmatroska10KaxTagMoodE
>    N11libmatroska20KaxTagRecordLocationE
>    N11libmatroska20KaxTagRecordLocationE
>    N11libmatroska12KaxTagSourceE
>    N11libmatroska16KaxTagSourceFormE
>    N11libmatroska13KaxTagProductE
>    N11libmatroska23KaxTagOriginalMediaTypeE
>    N11libmatroska17KaxTagPlayCounterE
>    N11libmatroska19KaxTagPopularimeterE
>   N11libmatroska12KaxTagGenresE (size: 3)
>    N11libmatroska16KaxTagAudioGenreE
>    N11libmatroska16KaxTagVideoGenreE
>    N11libmatroska14KaxTagSubGenreE
>   N11libmatroska19KaxTagAudioSpecificE (size: 10)
>    N11libmatroska21KaxTagAudioEncryptionE
>    N11libmatroska15KaxTagAudioGainE
>    N11libmatroska15KaxTagAudioPeakE
>    N11libmatroska9KaxTagBPME
>    N11libmatroska18KaxTagEqualisationE
>    N11libmatroska15KaxTagDiscTrackE
>    N11libmatroska13KaxTagSetPartE
>    N11libmatroska16KaxTagInitialKeyE
>    N11libmatroska26KaxTagOfficialAudioFileURLE
>    N11libmatroska28KaxTagOfficialAudioSourceURLE
>   N11libmatroska19KaxTagImageSpecificE (size: 6)
>    N11libmatroska16KaxTagCaptureDPIE
>    N11libmatroska22KaxTagCaptureLightnessE
>    N11libmatroska27KaxTagCapturePaletteSettingE
>    N11libmatroska22KaxTagCaptureSharpnessE
>    N11libmatroska13KaxTagCroppedE
>    N11libmatroska24KaxTagOriginalDimensionsE
>   N11libmatroska21KaxTagMultiCommercialE (size: 1)
>    N11libmatroska16KaxTagCommercialE (size: 5)
>     N11libmatroska25KaxTagMultiCommercialTypeE
>     N11libmatroska28KaxTagMultiCommercialAddressE
>     N11libmatroska24KaxTagMultiCommercialURLE
>     N11libmatroska26KaxTagMultiCommercialEmailE
>     N11libmatroska16KaxTagMultiPriceE (size: 3)
>      N11libmatroska24KaxTagMultiPriceCurrencyE
>      N11libmatroska22KaxTagMultiPriceAmountE
>      N11libmatroska25KaxTagMultiPricePriceDateE
>   N11libmatroska15KaxTagMultiDateE (size: 1)
>    N11libmatroska10KaxTagDateE (size: 3)
>     N11libmatroska19KaxTagMultiDateTypeE
>     N11libmatroska24KaxTagMultiDateDateBeginE
>     N11libmatroska22KaxTagMultiDateDateEndE
>   N11libmatroska17KaxTagMultiEntityE (size: 1)
>    N11libmatroska12KaxTagEntityE (size: 5)
>     N11libmatroska21KaxTagMultiEntityTypeE
>     N11libmatroska21KaxTagMultiEntityNameE
>     N11libmatroska20KaxTagMultiEntityURLE
>     N11libmatroska22KaxTagMultiEntityEmailE
>     N11libmatroska24KaxTagMultiEntityAddressE
>   N11libmatroska21KaxTagMultiIdentifierE (size: 1)
>    N11libmatroska16KaxTagIdentifierE (size: 3)
>     N11libmatroska25KaxTagMultiIdentifierTypeE
>     N11libmatroska27KaxTagMultiIdentifierBinaryE
>     N11libmatroska27KaxTagMultiIdentifierStringE
>   N11libmatroska16KaxTagMultiLegalE (size: 1)
>    N11libmatroska11KaxTagLegalE (size: 3)
>     N11libmatroska20KaxTagMultiLegalTypeE
>     N11libmatroska19KaxTagMultiLegalURLE
>     N11libmatroska23KaxTagMultiLegalAddressE
>   N11libmatroska16KaxTagMultiTitleE (size: 1)
>    N11libmatroska11KaxTagTitleE (size: 8)
>     N11libmatroska20KaxTagMultiTitleTypeE
>     N11libmatroska20KaxTagMultiTitleNameE
>     N11libmatroska24KaxTagMultiTitleSubTitleE
>     N11libmatroska23KaxTagMultiTitleEditionE
>     N11libmatroska23KaxTagMultiTitleAddressE
>     N11libmatroska19KaxTagMultiTitleURLE
>     N11libmatroska21KaxTagMultiTitleEmailE
>     N11libmatroska24KaxTagMultiTitleLanguageE
> 
> Now the output for the 'TrackUID = 0' case:
> 
> N11libmatroska7KaxTagsE (size: 1)
>  N11libmatroska6KaxTagE (size: 21)
>   N11libmatroska13KaxTagTargetsE (size: 0)
>   N11libmatroska13KaxTagGeneralE (size: 0)
>   N11libmatroska13KaxTagGeneralE (size: 0)
>   N11libmatroska12KaxTagGenresE (size: 0)
>   N11libmatroska12KaxTagGenresE (size: 0)
>   N11libmatroska19KaxTagAudioSpecificE (size: 0)
>   N11libmatroska19KaxTagAudioSpecificE (size: 0)
>   N11libmatroska19KaxTagImageSpecificE (size: 0)
>   N11libmatroska19KaxTagImageSpecificE (size: 0)
>   N11libmatroska21KaxTagMultiCommercialE (size: 0)
>   N11libmatroska21KaxTagMultiCommercialE (size: 0)
>   N11libmatroska15KaxTagMultiDateE (size: 0)
>   N11libmatroska15KaxTagMultiDateE (size: 0)
>   N11libmatroska17KaxTagMultiEntityE (size: 0)
>   N11libmatroska17KaxTagMultiEntityE (size: 0)
>   N11libmatroska21KaxTagMultiIdentifierE (size: 0)
>   N11libmatroska21KaxTagMultiIdentifierE (size: 0)
>   N11libmatroska16KaxTagMultiLegalE (size: 0)
>   N11libmatroska16KaxTagMultiLegalE (size: 0)
>   N11libmatroska16KaxTagMultiTitleE (size: 0)
>   N11libmatroska16KaxTagMultiTitleE (size: 0)
> 
> -- 
>  ==> Ciao, Mosu (Moritz Bunkus)
> _______________________________________________
> Matroska-devel mailing list
> Matroska-devel at lists.matroska.org
> http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel
> 



From steve.lhomme at free.fr  Fri Jul 25 14:56:43 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Fri, 25 Jul 2003 14:56:43 +0200
Subject: [Matroska-devel] Specs stylesheet
Message-ID: <012401c352ac$32a6ca70$0c7ba8c0@ing12>

Why do the stylesheet selection works here :
http://cvs.corecodec.org/cgi-bin/viewcvs.cgi/*checkout*/matroska/doc/website
/technical/index.html

and not here :
http://cvs.corecodec.org/cgi-bin/viewcvs.cgi/*checkout*/matroska/doc/website
/technical/specs/index.html

?



From rbultje at ronald.bitfreak.net  Fri Jul 25 16:43:13 2003
From: rbultje at ronald.bitfreak.net (Ronald Bultje)
Date: 25 Jul 2003 16:43:13 +0200
Subject: [Matroska-devel] Re: [Matroska-general] Matroska
	Release	4thAugust 2003 ( CHIP release ) - table of working/missing
	features
In-Reply-To: <3F20039A.1060403@matroska.org>
References: <3F1D3840.805@matroska.org>
	<002501c3505e$9fcee470$95a8be3f@johnc>	<20030723203414.GO9533@bunkus.org>
	<003a01c351be$625f1360$0c7ba8c0@ing12> <3F20039A.1060403@matroska.org>
Message-ID: <1059144172.15954.55.camel@shrek.bitfreak.net>

Hey Chris,

I promised to respond, so here goes:

On Thu, 2003-07-24 at 18:04, Christian HJ Wiesner wrote:
> @jcsston, fenrir, BBB, DaveEL : any chance you can comment briefly also 
> on your plans until 4th august ?

Nothing big, basically. For my work, we've gotten mkv demuxing in
GStreamer (see Gst CVS) and mkv muxing in lavrec2 (not yet released
publically, will happen later on) to work, and that's all we need for
now. So, finetuning only.

Privately, I'll want to port the lavrec2 mkv muxing module over to
GStreamer, but that'll only happen when I've got some other muxing
formats going. I'm thinking of ASF and Quicktime here. Matroska will
come along with them. Concerning the demuxer, there's just the kaxtags
and table of contents that need implementing. And some details, but
nothing serious. It basically just works.

In the mean time, I'll work on gst-rec (video recording tool) with mkv
support as part of it. :).

Ronald

-- 
Ronald Bultje <rbultje at ronald.bitfreak.net>



From steve.lhomme at free.fr  Fri Jul 25 19:04:10 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Fri, 25 Jul 2003 19:04:10 +0200
Subject: [Matroska-devel] CVS backup
Message-ID: <3F21630A.70609@free.fr>

As it seems we lost many modifications (hopefully nothing impossible to 
recover) it would be *very* appreaciated to be able to have access to a 
daily .tar.gz (or .tar.bz2) of each CVSROOT for each project. As 
available on SourceForge. So the people with a permanent connection 
(hopefully me, someday) can backup the CVS on their own machine in case 
of a hardware crash... It would also be good to know at what time these 
backups are done.

BetaBoy ? Cyt0plas ?



From jcsston at ToughGuy.net  Fri Jul 25 19:29:49 2003
From: jcsston at ToughGuy.net (Jory)
Date: Fri, 25 Jul 2003 12:29:49 -0500
Subject: [Matroska-devel] Re: [Matroska-general] Matroska
	Release	4thAugust2003 ( CHIP release ) - table of
	working/missing features
References: <3F1D3840.805@matroska.org><002501c3505e$9fcee470$95a8be3f@johnc>	<20030723203414.GO9533@bunkus.org><003a01c351be$625f1360$0c7ba8c0@ing12>
	<3F20039A.1060403@matroska.org>
Message-ID: <003001c352d2$5e64a5d0$0200a8c0@jcsston>

Well my plans until the 4th of August is
- Get tags working in the Shell Extension and CDL.
- Debug, debug, debug. (The last release of the CDL was very buggy)
- and if I have time, work more on Context Menu muxing/demuxing (right-click
in Explorer)

The Thumbnail, Page, Tooltip Shell Extensions seem to be working fine. :)

That's all for now,
Jory Stone
jcsston at toughguy.net
Matroska, the new, extensible open standard A/V container format
http://www.matroska.org/

----- Original Message -----
From: "Christian HJ Wiesner" <chris at matroska.org>
To: "Discussion about the current and future development of Matroska"
<matroska-devel at lists.matroska.org>
Sent: Thursday, July 24, 2003 11:04 AM
Subject: Re: [Matroska-devel] Re: [Matroska-general] Matroska Release
4thAugust2003 ( CHIP release ) - table of working/missing features


> Steve Lhomme wrote:
>
> >As it was not mentioned on the ML already, here is the up to date version
of
> >the features table :
>
>http://cvs.corecodec.org/cgi-bin/viewcvs.cgi/*checkout*/matroska/doc/websit
e/features.html
> >(please note that from now it's a valid XHTML document)
> >We'll be done when everything is green :>
> >
>
> Jesus ... i do see very little green still :D !!! At least, nobody from
> us is going to be bored for the next year or so ;) ......
>
> Christian
>
> @jcsston, fenrir, BBB, DaveEL : any chance you can comment briefly also
> on your plans until 4th august ?
>
>
> _______________________________________________
> Matroska-devel mailing list
> Matroska-devel at lists.matroska.org
> http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel




From steve.lhomme at free.fr  Fri Jul 25 21:29:11 2003
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Fri, 25 Jul 2003 21:29:11 +0200
Subject: [Matroska-devel] Re: ...
In-Reply-To: <20030725105352.GA6087@linet-services.de>
References: <20030725105352.GA6087@linet-services.de>
Message-ID: <3F218507.6050007@free.fr>

Moritz Bunkus wrote:
> ...and this is the result:
> 
> (0x22B59C,
> (0x4461,
> (0x5BAE,
> (0x5BB9,
> (0x5BDA,
> (0x5BDB,

Multiple IDs are now fixed in the CVS (spec and code).



From paul at msn.com  Sat Jul 26 01:15:22 2003
From: paul at msn.com (Paul)
Date: Fri, 25 Jul 2003 18:15:22 -0500
Subject: [Matroska-devel] Re: Re: [Matroska-general]
	MatroskaRelease	4thAugust 2003 ( CHIP release ) - table of
	working/missingfeatures
References: <3F1D3840.805@matroska.org><002501c3505e$9fcee470$95a8be3f@johnc>	<20030723203414.GO9533@bunkus.org><003a01c351be$625f1360$0c7ba8c0@ing12>
	<3F20039A.1060403@matroska.org>
	<1059144172.15954.55.camel@shrek.bitfreak.net>
Message-ID: <BAY4-DAV67UQ9cAgjHX00003156@hotmail.com>

I don't know how handy it would be, but you might want to implement chapters
in your recording for easy seek?


Pamel
----- Original Message ----- 
From: "Ronald Bultje" <rbultje at ronald.bitfreak.net>
Newsgroups: gmane.comp.multimedia.matroska.devel
Sent: Friday, July 25, 2003 9:43 AM
Subject: Re: Re: [Matroska-general] MatroskaRelease 4thAugust 2003 ( CHIP
release ) - table of working/missingfeatures


Hey Chris,

I promised to respond, so here goes:

On Thu, 2003-07-24 at 18:04, Christian HJ Wiesner wrote:
> @jcsston, fenrir, BBB, DaveEL : any chance you can comment briefly also
> on your plans until 4th august ?

Nothing big, basically. For my work, we've gotten mkv demuxing in
GStreamer (see Gst CVS) and mkv muxing in lavrec2 (not yet released
publically, will happen later on) to work, and that's all we need for
now. So, finetuning only.

Privately, I'll want to port the lavrec2 mkv muxing module over to
GStreamer, but that'll only happen when I've got some other muxing
formats going. I'm thinking of ASF and Quicktime here. Matroska will
come along with them. Concerning the demuxer, there's just the kaxtags
and table of contents that need implementing. And some details, but
nothing serious. It basically just works.

In the mean time, I'll work on gst-rec (video recording tool) with mkv
support as part of it. :).

Ronald

-- 
Ronald Bultje <rbultje at ronald.bitfreak.net>

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


From christian at matroska.org  Sun Jul 27 09:12:32 2003
From: christian at matroska.org (ChristianHJW)
Date: Sun, 27 Jul 2003 09:12:32 +0200
Subject: [Matroska-devel] Dev-API-4 : Possibility to mark a defined area of
 the encoded picture
 as 'BLACK=0' , to encode BlackBars with absolute minimum of bitrate ?
Message-ID: <3F237B60.1090800@matroska.org>


Hi,

sorry if i am too dumb to look this up from the specs, but does 
dev-api-4 allow apps to tell XviD to set certain areas of the picture 
internally to 'BLACK', such that these macroblocks are just written as 
'0' from the encoder ?

The idea is to encode letterboxed DVDs without using a resizing filter 
or any cropping, but to not waste bits and time on XviD trying to find 
out how to encode the black bars. Of course, a nice avisynth script 
could add nice borders on top and bottom to the picture after cropping, 
and these would be 'BLACK' and nothing else, but then still XviD would 
waste precious encoding time on trying to encode this.

If you ask why, well, looking at present MPEG4 hardware decoders it 
seems they have to invest a lot of their limited processing power into 
decoding and resizing the picture, while it would probably be much 
easier for them if the get the MPEG4 video in the same resolution and 
Aspect Ratio as the original DVD has, especially with respect to 
interlaced material ??

MP4 container supports the AR flag in the MPEG4 video header, and i 
would start to make all my encodings using standard resolutions like

720 x 576 or 480 x 576, using the different standard AR flags ( 4:3, 
16:9, 21:9 ) to make sure my XVID MPEG4 video streams are compatible 
with these standard resolutions for any MPEG4 hardware device, not only 
those based on the SIGMA chip ( reading AVIs, in 1:1 AR only and without 
supporting interlacing ).

Sidenote ( more future orientated ) :

For our matroska 'hardware profiles' we will suggest to stick to the 
following resolutions when making native MPEG4 MKV files, as we hope 
they will be easier to support in future standalones ( remember you can 
easily make a MP4 from a MKV if you use either AAC or MP3 audio ) :

352 x 240 ( VCD NTSC )
352 x 288 ( VCD PAL )
480 x 240 ( new )
480 x 288 ( new )
480 x 352 ( new )
480 x 480 ( S-VCD NTSC )
480 x 576 ( S-VCD PAL )
560 x 240 ( new )
560 x 288 ( new )
560 x 352 ( new )
560 x 480 ( new )
560 x 576 ( new )
640 x 288 ( new )
640 x 352 ( new )
640 x 480 ( new )
640 X 576 ( new )
720 x 288 ( new )
720 x 352 ( new )
720 X 480 ( DVD NTSC )
720 X 576 ( DVD PAL )

AR can be 4:3, 16:9 or 21:9 ( 2.35:1 ), for any of them, giving you a 
lot of possibilities to play, resulting in a big variety of pixel 
numbers also and different 'flavours' depending on whether your focus is 
on TV or PC playback. But all of them could be supported with a few 
standard interlacing algorithms even in current hardware decoders of 
today, if we're not mistaken.

For the upcoming HDTV those could be :

1024 x 480 ( AR 4:3 , 16:9 , 21:9 )
1024 x 576 ( AR 4:3 , 16:9 , 21:9 )
1024 x 768 ( AR 4:3 , 16:9 , 21:9 )


Sorry for the long email, but it would be great if it could be 
considered to support the ability to set certain macroblocks to '0' from 
Dev-Api-4 ( and i would suggest to limit this to complete 8 x 8 
macroblocks, anything else would defeat the purpose, even if this would 
mean cropping a few lines into the original picture ).

Thanks a lot


Christian



From Liisachan at faireal.net  Mon Jul 28 02:44:23 2003
From: Liisachan at faireal.net (Liisachan)
Date: Mon, 28 Jul 2003 09:44:23 +0900
Subject: [Matroska-devel] font matching algorithm needed
Message-ID: <3F2471E7.30508@faireal.net>

In SSA, you _must_ specify a font-name in the header:

[V4 Styles]
Format: Name, Fontname, Fontsize, PrimaryColour, SecondaryColour, 
TertiaryColour, BackColour, Bold, Italic, BorderStyle, Outline, Shadow, 
Alignment, MarginL, MarginR, MarginV, AlphaLevel, Encoding
Style: style1,Verdana,28,...

OR you _can_ specify a fontname with a \fn tag:

Dialogue: Marked=0,0:00:10.25,0:00:12.83,style1,,0000,0000,0000,,Let's 
change the font {\fnTimes New Roman}temporarily.

The problem is, today's subtitle renders is trying to use the font 
speficied, even if the system does not have it.
 
I got this feeback about our 15-language soft-ssa sample clip:

"too bad my mplayer fontconfig code doesn't check if the glyphs are 
available,
 so half of the subs (especially russian or polish) miss all characters"

This can happen on Windows too.
I myself found this problem when we were handling Tatar.
So  I'd like the coders to think about this:

1. Like mozilla can handle CSS like "font-family: Verdana" even tho the 
system doesnt have Verdana,
a subtitle renderer may look for ANY available glyphs for that code 
point in the system,
if the specified font is not installed (Verdana, and Times New Roman in 
the above examples)
Anything is really better than nothing

2.  TTF embedding is not only for fancy layout. It is softa "must" to 
sub in a "minor" language which uses
special glyphs (like Divehi)--otherwise, Matroska with subs couldn't be 
portable.
For instance, ArialTat.ttf is only 63KB in size. If you can embed this 
small file and "call" it from the SSA in MKV,
any system can replay Tatar subs, which is really cool. This is 
obviously better than picture-sub,
because this way you can handle font more flexibly, like changing 
fontsize font-color etc.

3. The mechanism 1 and 2 are critically important in order to make MKV 
x-platform.
On windows, probably eveyone has "Verdana" and "Times New Roman"
but it d be wonderful if you can play the same Matroska file on many OS's,
including Mac, Linux, FreeBSD etc etc, seamlessly.

 You can't assume "Verdana" is universally available on any systems.
But the subtitle renderer on that OS can--and should--try to find 
available glyphs in that system.
This is possible, because UTF-8 will give you a code point, not a glyph.

4. As a side note, while SSA is somehow windows-centric from its origin,
USF is more sophisticated, where you can specify a generic font like this:

family="Times, 'Times New Roman', serif"

Probably USF is the way to go.

Our sample clip with 15 languages is available here,
and you can test it by yourself:

http://ld-anime.faireal.net/guide/test.matroska


*Liisachan*


 



From chris at matroska.org  Mon Jul 28 16:20:23 2003
From: chris at matroska.org (Christian HJ Wiesner)
Date: Mon, 28 Jul 2003 16:20:23 +0200
Subject: [Matroska-devel] Re: Fwd: RE: about matroska support in
	XMPEG/FlaskMPEG/Adobe Premiere
In-Reply-To: <oprs0pa3rssqx01t@localhost>
References: <77701F18D74C9D4C80B885FB041E94DF03274B@musmsx401.ger.corp.intel.com>
	<oprs0pa3rssqx01t@localhost>
Message-ID: <3F253127.6080605@matroska.org>

Hi Eric,

just a quick hello from my side to you, if you need any kind of advice 
or info for the matroska plugin, just gimme a shout.

About matroska ( http://www.matroska.org )  :

Its open standard / open source, license is dual GPL/QPL, but as the lib 
is mainly written from one man we can easily license commercial apps 
also, including hardware companies planning to support it in 
standalones. The core of matroska is a kin of binary version of XML, we 
called it EBML and made it an opensource project of its own ( 
http://sf.net/projects/ebml ), and were meanwhile informed that 2 other 
projects adapted EBML for their purposes ( being completely unrelated ). 
The idea behind is is to have a flexible framework for matroska, that 
allows to adapt/extend the format easily for the future, without 
breaking backwards compatibility, a bit similar to 'atoms' in MP4, but 
much more powerful. We have been bashed a lot for not having built 
matroska on top of Ogg, but we feel our solution is much better. The 
only real competitor to matroska is MP4 IMHO, and we have our focus on 
editability and flexibility, while MP4 has advantages with respect to 
streaming.

The container currently supports

Every VCM codec ( DivX, XviD, HuffYuv, WMV9 VCM, 3ivX, ON2 VP3/4/5 , etc. )
Every ACM codec
MP3
AC3
Vorbis
AAC
AAC PLus
DTS
MPEG4 ISO Simple Profile
MPEG4 ISO Simple Advanced Profile ( not via VCM codec, requires linked 
DLL, as we dont accept b-frame hackery like packed bitsream in this 
'native' mode )
RV9 ( Real Video )
RA9 Real Audio ( Cook, ATRAC, etc. )
SRT text subtitles ( UTF8, even from different codec pages )
SSA/ASS text subtitles

Next to come :

FLAC lossless compressed audio ( for capturing )
RLE compressed picture subs ( vobsub from DVDs )
USF subs
lzo compressed picture subs ( 1:10 compared to RLE )
Ogg Theora video
flexible EDC/ECC(FEC) elements for enhanced file protection ( mode2 
form2 burning )

matroska files can contain any number of timestamp based 
video/audio/subs tracks and be of arbitrary file size, one team member 
has successfully captured a 14 hrs 80 GB file using the DShow matroska 
muxer filter and a Pinnacle DC10+ capture card.

Available tools are :

libmatroska/libebml : the main libs, written in C++ 
http://corecodec.org/projects/matroska
VirtualdubMod :  Creating and editing of matroska files, even with 
multiple audio and subs streams ; http://sf.net/projects/virtualdubmod
MKVtoolnix : CLI based matroska muxer for Linux and win32 called 
mkvmerge, and mkvinfo to find out about MKV files
DirectShow parser filters ( we have 2 of them ;) ) - the better one is 
on http://sf.net/projects/guliverkli and called matroska splitter , made 
by Gabest the VobSub author
DirectShow muxer filter, also by Gabest, same page, called matroska muxer
A DirectShow based Mediaplayer called 'The Core Media Player' coming 
with special matroska support ( tags, etc. ), on http://www.corecoded.com
Videolan Player VLC with matroska support  http://videolan.org
mplayer , Linux Mediaplayer ... can be compiled with matroska support, 
libebml/libmatroska 0.5.0 or newer from CVS is required http://mplayerhq.hu
Gentoo support, available in the official Gentoo packages
Matroska shell extension for win32 ... to be released 4th august
GUI, based on wxWindows for both Linux and win32, for mkvmerge  - not 
released yet, hopefully beta until 4th august also
Gstreamer playback plugin for matroska, soon a muxer plugin also 
htp://www.gstreamer.net
CoreAAC, CoreVorbis : DirectShow decoders for AAC and Vorbis, for use 
with matroska DShow splitter/parser filters ; 
http://corecodec.org/projects/coreaac and corevorbis

CHIP, the 2nd biggest PC magazine in Germany will include all those 
tools in the September issue, any chance we could get our hands on an 
alpha version of the plugin until then ?

I would like to invite you to visit us on our developers IRC channel on 
irc.corecodec.com #matroska , we could give you perfect support for the 
XMPEG plugin there, or alternatively you could send all your questions 
to me or to the developer mailing list ( see cc. above ).

Best regards

ChristianHJW

Selur wrote:

> Hier mal letzte mail die ich von Eric bekommen habe,..
>
> Cu Selur
> ------- Forwarded message -------
> From: "Chauvet, Eric" <eric.chauvet at intel.com>
> To: <selur at flaskmpeg.info>
> Subject: RE: about matroska support,...
> Date: Mon, 28 Jul 2003 13:04:57 +0200
>
>> See comments below.
>> Regards,
>>
>>     Eric.
>>
>> -----Original Message-----
>> From: Selur [mailto:selur at flaskmpeg.info] Sent: 28 July 2003 12:14
>> To: Chauvet, Eric
>> Subject: Re: about matroska support,...
>>
>>
>>> And if the plugin is compatible Adobe Premiere and stable, it can be 
>>> distributed in XMPEG package... If the plugin have to be adapted for 
>>> Adobe Premiere, let me know. I can do that quickly at home.
>>
>> Okay, so you are still interested ;) (happy to her that)
>>
>>> What's that -> flaskmpeg.info?
>>
>> The main page is the official german Flaskmpeg page. The message board
>> of the page is the official german flaskmpeg and DVDtoOgm (it's an 
>> delphi application that does DVD to ogm/mkv conversions) message 
>> board. Since Xmpeg is 'kind of' like Flaskmpeg we also offer support 
>> for it. (Btw.
>> the german language pack is from one of our moderators (Jensenmanm))
>> --> Interresting. I'll take a look on your site to understand the
>> advantage of these new formats.
>>
>> About my person:
>> I'm one of the admins of the board (also moderator in the german 
>> doom9 board), studying computer science and always doing some beta 
>> testing for
>>
>> different applications/codecs around video decoding and encoding.
>>
>> -------
>>
>> Since you kind of mentioned that you are interested in general to
>> support other output formats in Xmpeg I contacted ChristianHJW 
>> (christian at matroska.org ) an spoke with him about a SDK, an API or 
>> something similiar.
>> --> Let's have a look on it. It can be very interresting to start
>> innovating with matroska.
>>
>> He told me that they got an API (and some non official tools, not in the
>>
>> cvs) for this, and I should contact you and inform me if you are 
>> still interested. ;)
>> --> Yes. Please tell him to integrate this new format in a Adobe
>> Premiere plugin. I'm the specialist to work around it. In this way,
>> matroska will become available for any Adobe Premiere like software
>> (XMPEG, FlasKMPEG, DVDx,...)
>>
>> So since you are I'll contact Chris and tell him you are. :)
>>
>> Hopefully he'll send me some more infos I can forward to you. If you
>> like you could contact him by yourself, don't how good it's french 
>> is, but if
>> I remember right some of the matroska developers are french, the 
>> language shouldn't be a problem at all. (my own french is very rosted 
>> ;) )
>> --> He can contact me directly to my E-Mail : developpeu at mp3guest.com to
>> have some discution about this work.
>>
>> So if you like to contact him, you could do, or you just wait till I
>> wrote him and he send me some informations I can forward to you.
>> --> ...
>>
>>
>> Cu Selur
>>
>>
>
>
>




From tronic at trn.iki.fi  Mon Jul 28 21:04:33 2003
From: tronic at trn.iki.fi (=?ISO-8859-1?Q?Lasse_K=E4rkk=E4inen?=)
Date: Mon, 28 Jul 2003 22:04:33 +0300
Subject: [Matroska-devel] Uncompressed video
Message-ID: <3F2573C1.3050400@trn.iki.fi>

'lo all.

I suggest using the following format names:

V_Raw_Grey8
   Simple greyscale; uint8 values, where 0=black, 0xFF=white, ordering is
   from top-left of the image to top-right, then to the bottom.

V_Raw_RGB24
   Same ordering as with Grey8. Red value is first, then green and blue,
   no padding byte (ie. no 32 bits per pixel, just 24).

V_Raw_YUY2
   Same ordering as with Grey8. First pixel Y first, then U for it and
   the next pixel, second pixel Y, then V for the these two pixels.
   Width must be multiple of two.

V_Raw_YV12
   Grey8 Y pane, followed by U pane with half resolution in vertical
   and horizontal direction, then followed by V pane with half resolution
   in each direction.
   Width and height must be multiple of two.

All "comes first" sentences assume big-endian byte ordering.

(others could be added on request, if someone actually DOES need 'em 
(adding one because it is nice to have everything is a bad idea IMO), 
and if they differ from these with something else than byte ordering)

This would make the format naming system directly compatible with MCF.

- Tronic -



From rbultje at ronald.bitfreak.net  Mon Jul 28 22:48:31 2003
From: rbultje at ronald.bitfreak.net (Ronald Bultje)
Date: 28 Jul 2003 22:48:31 +0200
Subject: [Matroska-devel] Uncompressed video
In-Reply-To: <3F2573C1.3050400@trn.iki.fi>
References: <3F2573C1.3050400@trn.iki.fi>
Message-ID: <1059425311.14798.51.camel@localhost.localdomain>

Hi Lasse,

On Mon, 2003-07-28 at 21:04, Lasse K?rkk?inen wrote:
> I suggest using the following format names:
> V_Raw_Grey8
> V_Raw_RGB24
> V_Raw_YUY2
> V_Raw_YV12

Wasn't the colourspace kax element supposed to handle this? (It's a
four-byte binary element in the form of a YUV fourcc as described in the
YUV section of http://fourcc.org/, afaik.

Ronald

-- 
Ronald Bultje <rbultje at ronald.bitfreak.net>



From chris at matroska.org  Mon Jul 28 23:42:51 2003
From: chris at matroska.org (Christian HJ Wiesner)
Date: Mon, 28 Jul 2003 23:42:51 +0200
Subject: [Matroska-devel] Uncompressed video
In-Reply-To: <1059425311.14798.51.camel@localhost.localdomain>
References: <3F2573C1.3050400@trn.iki.fi>
	<1059425311.14798.51.camel@localhost.localdomain>
Message-ID: <3F2598DB.4070707@matroska.org>

Ronald Bultje wrote:

>Hi Lasse,
>
>On Mon, 2003-07-28 at 21:04, Lasse K?rkk?inen wrote:
>  
>
>>I suggest using the following format names:
>>V_Raw_Grey8
>>V_Raw_RGB24
>>V_Raw_YUY2
>>V_Raw_YV12
>>    
>>
>
>Wasn't the colourspace kax element supposed to handle this? (It's a
>four-byte binary element in the form of a YUV fourcc as described in the
>YUV section of http://fourcc.org/, afaik.
>
>Ronald
>
Yes, thats why we set the codec ID to V_UNCOMPRESSED, allt the rest goes 
into into KaxColourSpace .....

Christian



From chris at matroska.org  Tue Jul 29 11:10:19 2003
From: chris at matroska.org (Christian HJ Wiesner)
Date: Tue, 29 Jul 2003 11:10:19 +0200
Subject: [Matroska-devel] Re: [XviD-devel] Dev-API-4 : Possibility to mark a
 defined area of
 the encoded picture as 'BLACK=0' , to encode BlackBars with absolute minimum
 of bitrate ?
In-Reply-To: <20030727090147.GA756@leeloo>
References: <3F237B60.1090800@matroska.org> <20030727090147.GA756@leeloo>
Message-ID: <3F2639FB.9090307@matroska.org>


Hi GomGom,

thanks for your reply. Dont forget to visit us by time on 
irc.corecodec.com , #matroska , we could even found an anime free #xvid 
channel there ;) .... LOL

Edouard Gomez wrote:

>Syskin has  better skills  in ME  than I, but  afaik, as  soon as  a SAD
>comparison is zero, the ME returns and that's all done. This implies not
>so much  CPU time  for the borders  (unless they  are not 16px  sized in
>height, one  MB line will take  a bit more of  CPU, but it  would be the
>case with "bb" hints anyway)
>So i don't think it's worth overbloating user capabilities for gaining a
>few cycles. Let's wait what our expert in ME says, c'mon syskin.
>  
>

sysKin replied to me in great detail on IRC, and unfortunately what he 
was telling me was not at all motivating, as it seems MPEG4 is not 
really suitable to use black bars for the picture. I cant repeat all of 
his explanations, as i naturally only understood a small part of it ;-), 
but basically it seems that MPEG4 Motion Estimation has a hard time 
detecting motion if there is an edge, or even two of them, in the 
picture. sysKin mentioned that MPEG4 in theory offers the possibility to 
'partition' a picture, but this is neither implemented in XviD nor 
planned nor does anybody know anything about that.


>Concerning the resolutions, i've heard  that DVD could use a newer video
>codec  in  near  future.  If  it's  MPEG4, you  should  stick  to  their
>recomandation no ? 
>
Well, from sysKin's explanation i learned that my considerations are 
maybe completely wrong. If its true that MPEG4 cant handle black bars 
very well, it makes more than sense that any hardware decoder HAS to 
offer much better resizing capabilities to be able to handle various 
different resolutions, and also interlaced, than the old MPEG1/2 decoder 
chips would have ( that was the main reason why DVD/SVCD/VCD would only 
support a couple of resolutions and aspect ratios at the beginning ). I 
still feel that its a good idea to leave the normal 1:1 Pixel Aspect 
Ratio scenario behind, my latest test encodings have shown that a 560 x 
352 anamorphic encoding ( Starwars EP2, 136 mins, VHQ 4, 2 b frames, 
dx50 vop, h.263 quant ) was looking much better to my eyes than a 
'normal' 696 x 288 encoding with square pixels, while number of pixels 
is almost the same for both. No idea if the codec will have a 
'preference' for a picture that is more 'square', or if its just the 
visual perception of a higher vertical resolution, sysKin or you guys 
may answer this better i guess.

Different to MP4, the matroska container allows basically any float to 
describe the output AR, but its recommended to describe it as 2 
integers, one being the preferred width and the other the height of the 
output picture. For the example given above, i would set

w/h = 832/352

in mkvmerge, while 352 x 2,35 = 827,2 , with a remaining aspect error of 
about 0.5 %. A software player supporting matroska would resize the 
picture to 832 x 352 on playback, thus the full vertical resolution 
would be preserved while the horizontal res is stretched accordingly. 
DirectShow players with full matroska support, like TCMP with the 
matroska CDL ( it can read the w/h from the track header *BEFORE* 
calling the graph ), will of course use DirectShow and thus the hardware 
overlay for that, so its mainly neutral in terms of CPU power. All other 
players can do it using latest ffdshow-alpha ( activate 'use overlay' in 
the config window ), and in this case it will be ffdshow's internal 
resizing filter that will first stretch the picture to the bigger width 
accordingly, before DirectShow will expand it to fullscreen using 
hardware, so this version is not completely free of using some 
additional CPU power but i guess its almost neglectible. In principal 
this means that the encoding resolution can be chosen completely free, 
as the output resolution will be *ALWAYS* determined by the w/h as set 
in the track header, and its the job of the player/decoder filter to 
make sure this output AR is achieved, no matter what the input 
resolution is.

Now, for a hardware player this is of course more difficult to support, 
and for this very reason we would like to try to standardize certain 
picture resolutions and output resolutions for those users that believe 
that matroska may be suported on standalone units one day in future ( 
actually, i have email contact with 2 Asian companies about this right 
now, but to be honest, i guess they are more polite than really 
interested ;-) ). On the example above, with a 560 x 352 encoded res, on 
a PC this could be outputted as

560 x 420 = 4 : 3   ( vertical stretch, +20% )
656 x 352 = 16 : 9  ( horizontal stretch, +17% )
832 x 352 = 21 : 9  ( horizontal stretch, +48% )

or for fullscreen from the hardware output on normal TVs this would be

PAL , 768 x 576

768 x 576 = 4 : 3    ( horizontal stretch, +37%, vertical stretch + 64% )
768 x 412 = 16 : 9  ( horizontal stretch, +37%, vertical stretch +17%,  
resizer to add black borders on top/bottom )
768 x 324 = 21 : 9  ( horizontal stretch +37%, vertical -8%, resizer to 
add ..... )

NTSC, 640 x 480

640 x 480 = 4 : 3    ( horizontal stretch, +14%, vertical stretch + 36% )
640 x 342 = 16 : 9  ( horizontal stretch, +14%, vertical stretch -3%,  
resizer to add black borders on top/bottom )
640 x 272 = 21 : 9  ( horizontal stretch +14%, vertical -23%, resizer to 
add ..... )


For another example, if the user decides to encode his movie in

640 x 576 ( another res from the old list ), here are the equivalent 
numbers, first for the PC

768 x 576 = 4 : 3  ( vertical stretch, +20% )
1024 x 576 = 16 : 9 ( vertical stretch, +60% )
1344 x 576 = 21 : 9 ( vertical stretch, + 110% )

PAL , 768 x 576

768 x 576 = 4 : 3    ( horizontal stretch, +20%, vertical stretch + 0% )
768 x 412 = 16 : 9  ( horizontal stretch, +20%, vertical stretch -28%,  
resizer to add black borders on top/bottom )
768 x 324 = 21 : 9  ( horizontal stretch +20%, vertical -44%, resizer to 
add ..... )

NTSC, 640 x 480

640 x 480 = 4 : 3    ( horizontal stretch, +0%, vertical stretch -17% )
640 x 342 = 16 : 9  ( horizontal stretch, +0%, vertical stretch -40%,  
resizer to add black borders on top/bottom )
640 x 272 = 21 : 9  ( horizontal stretch +0%, vertical -53%, resizer to 
add ..... )



As you can see from the 2 examples above, there is no regularity in the 
numbers above, very often the resizer would even have to stretch the 
picture by uneven numbers ( in % ), or to shrink it even ( bad ). Now, 
preferably our list of recommended encoding resolutions should be made 
such that there is a certain mathematical correlation between them, in 
order to allow using a limited number of resizing algorithms, if this is 
possible, and still meet at least with a MOD 8 criterium, preferably MOD 
16. As this is a new situation now ( adding black borders would have 
made the whole thing much much easier to handle ;-) ), i will have to 
sit down and try to find a number of different possible resolutions that 
will make the job for the hardware resizers as simply as possible. Of 
course, it would help a lot if somebody with a background in resizing 
algo's ( trbarry ? ) would give me some hints first about what makes a 
resizing job easy or not for a hardware device ( hint, hint :-) ). I 
will inform you guys if i manage to come up with something sensible .....

Sorry for the long email and the inevitable, imminent matroska 
advertising in it.

Regards

Christian





From chl at math.uni-bonn.de  Tue Jul 29 11:49:58 2003
From: chl at math.uni-bonn.de (Christoph Lampert)
Date: Tue, 29 Jul 2003 11:49:58 +0200 (CEST)
Subject: [Matroska-devel] Re: [XviD-devel] Dev-API-4 : Possibility to mark a
 defined area of
 the encoded picture as 'BLACK=0' , to encode BlackBars with absolute minimum
 of bitrate ?
In-Reply-To: <3F2639FB.9090307@matroska.org>
Message-ID: <Pine.LNX.4.21.0307291136150.24134-100000@raum6.math.uni-bonn.de>

On Tue, 29 Jul 2003, Christian HJ Wiesner wrote:
> Edouard Gomez wrote:
> 
> >Syskin has  better skills  in ME  than I, but  afaik, as  soon as  a SAD
> >comparison is zero, the ME returns and that's all done. This implies not
> >so much  CPU time  for the borders  (unless they  are not 16px  sized in
> >height, one  MB line will take  a bit more of  CPU, but it  would be the
> >case with "bb" hints anyway)
> >So i don't think it's worth overbloating user capabilities for gaining a
> >few cycles. Let's wait what our expert in ME says, c'mon syskin.
> >  
> >
> 
> sysKin replied to me in great detail on IRC, and unfortunately what he 
> was telling me was not at all motivating, as it seems MPEG4 is not 
> really suitable to use black bars for the picture. I cant repeat all of 
> his explanations, as i naturally only understood a small part of it ;-), 
> but basically it seems that MPEG4 Motion Estimation has a hard time 
> detecting motion if there is an edge, or even two of them, in the 
> picture. 

There is no "MPEG4 Motion Estimation". How to implement ME is complete up
to the user. But maybe you mean Motion Compensation, and then it's
somewhat true, that especially if global motion is present (camera
movement), then with black bars, object will (dis)appears "behind a black
block" whereas without bars, they will (dis)appear behind image
boundaries, and the latter is easier to encode. 
But I doubt that this effect is responsible for more than 0.5% extra
bitrate or so if the bars themselves are sized a multiple of 16. 
My impression from many tests was: Remove black bars if possible. 
But if you have to keep them (e.g. for rendering subtitles), then size 
them a multiple of 16 and it's not that much of a problem, either. 

> sysKin mentioned that MPEG4 in theory offers the possibility to 
> 'partition' a picture, but this is neither implemented in XviD nor 
> planned nor does anybody know anything about that.

Do you mean to encode several video objects and overlay? Maybe even
arbitrarily shaped? That's not part of Simple or Advanced Simple
Profile... which maybe is good, because decoding that is an ugly process. 
It's surely not worth implementing just to encode black bars. 
Or do you mean something like "slices" to split encoding the one
rectangular pictures into more than one subset of macroblocks? That might
be related to error resilience, but again it's not in SP or ASP and 
I can't see why it would be helpful. 

> >Concerning the resolutions, i've heard  that DVD could use a newer video
> >codec  in  near  future.  If  it's  MPEG4, you  should  stick  to  their
> >recomandation no ? 
>
> Well, from sysKin's explanation i learned that my considerations are 
> maybe completely wrong. If its true that MPEG4 cant handle black bars 
> very well, it makes more than sense that any hardware decoder HAS to 
> offer much better resizing capabilities to be able to handle various 
> different resolutions, and also interlaced, than the old MPEG1/2 decoder 
> chips would have ( that was the main reason why DVD/SVCD/VCD would only 
> support a couple of resolutions and aspect ratios at the beginning ). I 
> still feel that its a good idea to leave the normal 1:1 Pixel Aspect 
> Ratio scenario behind, my latest test encodings have shown that a 560 x 
> 352 anamorphic encoding ( Starwars EP2, 136 mins, VHQ 4, 2 b frames, 
> dx50 vop, h.263 quant ) was looking much better to my eyes than a 
> 'normal' 696 x 288 encoding with square pixels, while number of pixels 
> is almost the same for both. No idea if the codec will have a 
> 'preference' for a picture that is more 'square', or if its just the 
> visual perception of a higher vertical resolution, sysKin or you guys 
> may answer this better i guess.

My impression is that if the DVD or whatever source is anamorphic, with
non-square pixels, then it should be beneficial to encode with the 
same non-square pixels, because DCT area stays the same. Best would be to 
crop only multiples of 16 (or at least 8), whereas the effect will surely
be smaller when any rescaling is done instead of just cropping. 

gruel