From gouldukat.o at gmail.com  Thu Jun  5 22:35:16 2008
From: gouldukat.o at gmail.com (Goul_duKat)
Date: Thu, 05 Jun 2008 22:35:16 +0200
Subject: [Matroska-devel] [Bug pop and crack] from .m2ts PCM 6 channel
 (reply to my mail too i'm not subscribed)
Message-ID: <48484E04.6090102@gmail.com>

release:
a) 1.8.122.18
b) 1.7.401.3

ill updated today to release B to A and got strange problem of pop and 
crack on PCM stream from films revert to version B and that problem go 
away, so its a bug inside the new one or some problem ?

i can say i'm playing Pirates of Carribean (ita version) in MPC using 
Haali media splitter to read the file and passing only to ffdshow for 
the rest.

tnx to all


From woulfenberg at gmx.net  Sat Jun 14 12:03:13 2008
From: woulfenberg at gmx.net (Peter Woulfenberg)
Date: Sat, 14 Jun 2008 12:03:13 +0200
Subject: [Matroska-devel] Assertion `bTimecodeScaleIsSet' failed
Message-ID: <48539761.20509@gmx.net>

Dear development team,
there is a bug in libmatroska, which causes VLC to crash when scrolling 
through a video:
http://trac.videolan.org/vlc/ticket/1110

Unfortunately this bug was not fixed in a year and it is very annoying. 
I can reproduce it with several different mkv files:

vlc: 
/build/buildd/libmatroska-0.8.1/make/linux/../../matroska/KaxCluster.h:131: 
uint64 libmatroska::KaxCluster::GlobalTimecodeScale() const: Assertion 
`bTimecodeScaleIsSet' failed.

This is even in the latest unstable 0.9.0 release of VLC. Is there a 
possibility that someone is going to fix this? That would be very nice.

Thanks for your time.
Bye,
Peter




From k.gurney at shaw.ca  Mon Jun 16 04:46:00 2008
From: k.gurney at shaw.ca (Kevin Gurney)
Date: Sun, 15 Jun 2008 22:46:00 -0400
Subject: [Matroska-devel] Important message
Message-ID: <7BF61ADD04FA46E79BDEE9F5188769F3@KevinPC>

Hi, first off, I hope I'm in the right place. :) 

I just wanted to mention that I've been using Haali (29/12/2007) for a while now for watching my Blu-ray movies through Media Player Classic (by far my favorite media player). It's been working flawlessly. All video and all audio formats decode with no problems. But your new updated version (29/03/2008) does not work at all. I had to revert back to the previous version (29/12/2007)then everything was fine again. I just thought the developers would like to know as I'm sure there are a lot more people like me out there who use your software filter for this purpose. If you want my filter list I use in MPC please let me know.

Thanks,
Kevin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.matroska.org/pipermail/matroska-devel/attachments/20080615/ff2a2171/attachment.html>

From chris at matroska.org  Sun Jun 22 02:20:16 2008
From: chris at matroska.org (Christian Wiesner)
Date: Sun, 22 Jun 2008 02:20:16 +0200
Subject: [Matroska-devel] Access to the Java source code
In-Reply-To: <481A287D.2070408@datacrow.net>
References: <481A287D.2070408@datacrow.net>
Message-ID: <21e2294b0806211720s55c2b94emcc47a845d59033a7@mail.gmail.com>

Hi, have a loook here : http://mediainfo.sourceforge.net/ru/Support/Tags

2008/5/1 Robert Jan van der Waals <rwaals at datacrow.net>:

> Hi,
>
> I am running a fairly successful open source Java project called Data Crow
> (http://www.datacrow.net or http://sourceforge.net/projects/datacrow).
> Data Crow is an all rounder when it comes to cataloging media. It allows,
> amog other things, to parse file information.
> For the movie and music module I would like to add the ability to parse mkv
> file information.
>
> It would like access to your svn repository (
> http://svn.matroska.org/svn/matroska/trunk/) for the Java source code.
> Is this possible?
>
> Cheers,
> Robert Jan van der Waals
> _______________________________________________
> Matroska-devel mailing list
> Matroska-devel at lists.matroska.org
> http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel
> Read Matroska-Devel on GMane:
> http://dir.gmane.org/gmane.comp.multimedia.matroska.devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.matroska.org/pipermail/matroska-devel/attachments/20080622/9943ad99/attachment.html>

From antonrhoden at yahoo.com  Sun Jun 22 01:47:45 2008
From: antonrhoden at yahoo.com (anton rhoden)
Date: Sat, 21 Jun 2008 16:47:45 -0700 (PDT)
Subject: [Matroska-devel] question
Message-ID: <813131.2463.qm@web39805.mail.mud.yahoo.com>

i downloaded some mkv files and i played them using
perian to play them in quicktime, but there is no
audio coming out from the video i dowloaded. What
happen? and what should i do?

ps- i am using a mac book pro


      


From chris at matroska.org  Sun Jun 22 11:39:43 2008
From: chris at matroska.org (Christian Wiesner)
Date: Sun, 22 Jun 2008 11:39:43 +0200
Subject: [Matroska-devel] question
In-Reply-To: <813131.2463.qm@web39805.mail.mud.yahoo.com>
References: <813131.2463.qm@web39805.mail.mud.yahoo.com>
Message-ID: <21e2294b0806220239j2da573e6v5160aa9c0520611e@mail.gmail.com>

Try to use the MAC version of VLC player from http://www.videlan.org

Christian
matroska project admin

2008/6/22 anton rhoden <antonrhoden at yahoo.com>:

> i downloaded some mkv files and i played them using
> perian to play them in quicktime, but there is no
> audio coming out from the video i dowloaded. What
> happen? and what should i do?
>
> ps- i am using a mac book pro
>
>
>
> _______________________________________________
> Matroska-devel mailing list
> Matroska-devel at lists.matroska.org
> http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel
> Read Matroska-Devel on GMane:
> http://dir.gmane.org/gmane.comp.multimedia.matroska.devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.matroska.org/pipermail/matroska-devel/attachments/20080622/cc12c95f/attachment.html>

From sebastian.droege at collabora.co.uk  Tue Jun 24 15:11:23 2008
From: sebastian.droege at collabora.co.uk (Sebastian =?ISO-8859-1?Q?Dr=F6ge?=)
Date: Tue, 24 Jun 2008 15:11:23 +0200
Subject: [Matroska-devel] [Fwd: Re:  Dirac mapping for Matroska]
Message-ID: <1214313083.3084.9.camel@asgard.lan>

Hi,
after reading all the discussion about how to best put Dirac into
Matroska I would propose the following plan, which includes all aspects
mentioned in the previous mails and goes in line with how other codecs
are handled.

In Dirac there exist 4 different types of "packets":
- Sequence header
- Picture
- Auxiliary data
- Padding data

The sequence header contains information that is important for the
decoder to actually decode the pictures (aka frames). After a sequence
header a I frame must follow. For one stream all sequence headers must
be bit identical.

The auxiliary data contains "metadata", which is not strictly needed for
anything and could in theory be dropped. See
http://www.diracvideo.org/wiki/index.php/DiracAuxiliaryData for the list
of defined auxiliary data types. Auxiliary data packets are associated
with the following picture packet.

The padding data contains nothing useful.

See the Dirac spec for more on this:
http://dirac.sourceforge.net/specification.html



Now my idea for putting Dirac into Matroska would be the following:

- CodecID would be "V_DIRAC"
- The sequence header would be stored in CodecPrivate and
  should be stripped from the stream
- The actual content of a block/lace would be one picture and only
  pictures are stored there
?- Any existing auxiliary data should be stored in BlockAdditions in
  the block of the picture it is associated with. All auxiliary data
  packets for one picture should be stored in a single BlockAdditional
  as there could be zero to infinite auxiliary packets for one
  picture and a maximum can't be known before and put into
  MaxBlockAdditionID.
  
  All these auxiliary data packets for one picture are stored in a
  row and if a demuxer wants to parse them it can step through the
  packets by looking the parse info at the start of every packet,
  see section 9.6 of the Dirac 2.2 spec for this.

  Of course muxers can also decide to simply drop auxiliary data packets
  as they're not needed for decoding
- As for MPEG1/2 the muxer must write ReferenceBlock for every
  block that doesn't contain I frames

When demuxing a "V_DIRAC" stream it is important that the demuxer
outputs the sequence header from CodecPrivate before any pictures. After
seeking the demuxer should also output the sequence header just before
the first I frame after seeking.
This would be similar to what is done for MPEG1/2 video right now.

Any comments? Is there something that needs to be clarified?
If not it would be nice if this could be added to the Matroska spec.

If everybody is fine with this I'll implement it in the GStreamer
Matroska muxer and demuxer.



From sebastian.droege at collabora.co.uk  Tue Jun 24 20:48:27 2008
From: sebastian.droege at collabora.co.uk (Sebastian =?ISO-8859-1?Q?Dr=F6ge?=)
Date: Tue, 24 Jun 2008 20:48:27 +0200
Subject: [Matroska-devel] [Fwd: Re:  Dirac mapping for Matroska]
In-Reply-To: <1214313083.3084.9.camel@asgard.lan>
References: <1214313083.3084.9.camel@asgard.lan>
Message-ID: <1214333308.3084.22.camel@asgard.lan>

Ok, after talking to one of the Dirac developers I'd like to change the
previous proposal completely ;)

The plan would now be:
- CodecID is "V_DIRAC"
- No CodecPrivate, no changing of the stream
- A Matroska block/lace contains all Dirac packets up to and
  including a picture. This means, all padding, maybe a sequence
  header and maybe auxiliary data and then the picture for which
  all this previous data was. This makes demuxing much easier
  and prevents broken streams created by a muxer or demuxer.
- A block is a keyframe whenever it contains a sequence header.
  Sequence headers are added to the stream by the encoder at
  places that are meant as "seek points" and on which decoding
  could start. There's no easy way of detecting whether a picture
  can be decoded on it's own in any other way.

The Track elements can contain the video width/depth, aspect ratio,
framerate etc but that's not required. Also setting the ReferenceBlock
element is not necessary.

What do you think? This is rather easy to implement, allows all
flexibility and makes sure that the Dirac streams are not damaged ;)



From kenoh.sama at gmail.com  Wed Jun 25 02:09:56 2008
From: kenoh.sama at gmail.com (Mike Green)
Date: Tue, 24 Jun 2008 19:09:56 -0500
Subject: [Matroska-devel] Libmatroska and Libebml
Message-ID: <6eabacb40806241709y79d63206r6402918299cb8886@mail.gmail.com>

Hi, I am currently writting some software that will work with MKV files. The
project will be written in VB.Net and on a Windows platform.  I was trying
to find a COM Object that I could import into Visual Studio.Net 2005 that
would allow me to read the contents of an MKV file programmically.  Most of
the searches on the Internet talked about the two files in the title of this
email.  I went to your site and tried to figure out how to get the source
code into a compiled DLL, but I am not that strong at doing this.
Libmatroska and Libebml also come with MKVExtract but I had no luck trying
to import those versions into VS.Net as it said they were invalid files.  Do
you know of anyway I could do this or have knowledge of existing code in
VB.Net (even C#) that works with MKV files.

Thank you for your time.  The project I that I am working on is open source
and can be found below:
https://sourceforge.net/projects/tshed
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.matroska.org/pipermail/matroska-devel/attachments/20080624/eec8b974/attachment.html>

From moritz at bunkus.org  Fri Jun 27 00:03:45 2008
From: moritz at bunkus.org (Moritz Bunkus)
Date: Fri, 27 Jun 2008 00:03:45 +0200
Subject: [Matroska-devel] [Fwd: Re:  Dirac mapping for Matroska]
In-Reply-To: <1214333308.3084.22.camel@asgard.lan>
References: <1214313083.3084.9.camel@asgard.lan>
	<1214333308.3084.22.camel@asgard.lan>
Message-ID: <200806270003.45268.moritz@bunkus.org>

Hey,

On Tuesday 24 June 2008 20:48, Sebastian Dr?ge wrote:

> Ok, after talking to one of the Dirac developers I'd like to change
> the previous proposal completely ;)

;)

> The Track elements can contain the video width/depth, aspect ratio,
> framerate etc but that's not required. Also setting the ReferenceBlock
> element is not necessary.

The track headers MUST contain the video width and depth at least. They
SHOULD contain the aspect ratio if it is not the same as video width /
video height. This is because most players initialize their decoding
pipelines and displays according to this information.

I'm OK with the rest as it is indeed easy to implement.

Regards,
Mosu

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

-------------- 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/20080627/799e469d/attachment.pgp>

From niemayer at isg.de  Fri Jun 27 19:18:51 2008
From: niemayer at isg.de (Peter Niemayer)
Date: Fri, 27 Jun 2008 19:18:51 +0200
Subject: [Matroska-devel] DivX 7 to use Matroska as container format
Message-ID: <g437dq$l3i$1@ger.gmane.org>

Hi,

according to http://forum.doom9.org/showthread.php?p=1152183#post1152183
DivX intends to use Matroska as container format with their release 7.

I wondered to not see that interesting news mentioned here, so...

Regards,

Peter Niemayer



From slhomme at matroska.org  Sun Jun 29 01:05:48 2008
From: slhomme at matroska.org (Steve Lhomme)
Date: Sat, 28 Jun 2008 17:05:48 -0600
Subject: [Matroska-devel] Codec ID namespace and adding a new one
In-Reply-To: <ccbc6dd90803270618g5077b4f8me09a7c86dd756633@mail.gmail.com>
References: <ccbc6dd90803270408q4c0b3f9cj879c62a554a779ab@mail.gmail.com>	<47EB971F.6070200@matroska.org>
	<ccbc6dd90803270618g5077b4f8me09a7c86dd756633@mail.gmail.com>
Message-ID: <4866C3CC.3080308@matroska.org>

ogg.k.ogg.k at googlemail.com wrote:
> Hi,
> 
>> Sending a mail to this list is probably the best way to make it public.
>> We can add it on matroska.org and Haali can add it to his own page.
>> Matroska.org being the reference anyway.
> 
> OK, then the ID is "S_KATE", as mentioned, and used for the Kate text
> codec, described at http://wiki.xiph.org/index.php/OggKate.
> 
> I'll add there a section about the Matroska embedding (essentially the
> same as Theora, all headers xiph-laced together in the private data).
> 
>> Given the S_KATE name, I assume it's a subtitle codec ? Otherwise for
>> audio it should start with A_ and for video with V_.
> 
> Yes, streamed text, along with other info (style, regions, etc).

Better late than never, I added the S_KATE ID on the website, with a 
link to the wiki.

Steve


From slhomme at matroska.org  Sun Jun 29 01:11:59 2008
From: slhomme at matroska.org (Steve Lhomme)
Date: Sat, 28 Jun 2008 17:11:59 -0600
Subject: [Matroska-devel] on ssa/ass
In-Reply-To: <9B49D7D7290.00000B38jaab43@inbox.com>
References: <9B49D7D7290.00000B38jaab43@inbox.com>
Message-ID: <4866C53F.8030905@matroska.org>

Jeff wrote:
> some links don't work  here examples:http://www.eswat.demon.co.uk/  on 
> http://www.matroska.org/technical/specs/subtitles/ssa.html

Fixed
Steve


From slhomme at matroska.org  Sun Jun 29 01:20:43 2008
From: slhomme at matroska.org (Steve Lhomme)
Date: Sat, 28 Jun 2008 17:20:43 -0600
Subject: [Matroska-devel] Access to the Java source code
In-Reply-To: <481A287D.2070408@datacrow.net>
References: <481A287D.2070408@datacrow.net>
Message-ID: <4866C74B.8090701@matroska.org>

Robert Jan van der Waals wrote:
> Hi,
> 
> I am running a fairly successful open source Java project called Data 
> Crow (http://www.datacrow.net or http://sourceforge.net/projects/datacrow).
> Data Crow is an all rounder when it comes to cataloging media. It 
> allows, amog other things, to parse file information.
> For the movie and music module I would like to add the ability to parse 
> mkv file information.
> 
> It would like access to your svn repository 
> (http://svn.matroska.org/svn/matroska/trunk/) for the Java source code.
> Is this possible?

You can access some outdated Java classes here:
https://svn.matroska.org/svn/matroska/trunk/JEBML

Steve


From slhomme at matroska.org  Sun Jun 29 01:25:46 2008
From: slhomme at matroska.org (Steve Lhomme)
Date: Sat, 28 Jun 2008 17:25:46 -0600
Subject: [Matroska-devel] How can I concatenate / append / combine
 segments of Matroska files programatically?
In-Reply-To: <465a4ad00805121014k3fa79d94wfb2a0d14a85dd34d@mail.gmail.com>
References: <465a4ad00805121014k3fa79d94wfb2a0d14a85dd34d@mail.gmail.com>
Message-ID: <4866C87A.4030004@matroska.org>

Peter Romba wrote:
> Hi guys,
> 
> I'm trying to write a class that will concatenate parts of two Matroska 
> files together.  I've seen examples of this in the mkvmerge program in 
> the mkvtoolnix toolkit.  However, that tool only appends complete 
> files.  I'd like to just append over *parts* of a source file onto the 
> end of a destination file.
> 
> Can anyone recommend the basic ways to do this?  The sample applications 
> included with the library illustrate muxing and reading/writing header 
> data, but it's not clear how to interact with the clusters and move them 
> around and still end up with an intelligible file.

You need to create all the basic parts yourself. Even if you get 
separate clusters, you still need to manage the timecode inside each. 
The other option is to use segment linking.

> As a side note, I haven't had much luck parsing any of the mkv files 
> from the matroska site with the test8 sample application--it seems like 
> it just loops through the files, finds no useful elements, and exits.  
> So that's made it a bit difficult to examine the structure of a known 
> good file.

We are in the process of rewriting the libs (and some better examples) 
in C. The test samples in libmatroska are from early versions of 
libmatroska. The best way to see how to mux matroska is to look at the 
mkvmerge sources. Although it may need a bit of time/work. It is not a 
simple task to concatenate files.

Steve


From slhomme at matroska.org  Sun Jun 29 02:30:03 2008
From: slhomme at matroska.org (Steve Lhomme)
Date: Sat, 28 Jun 2008 18:30:03 -0600
Subject: [Matroska-devel] Libmatroska and Libebml
In-Reply-To: <6eabacb40806241709y79d63206r6402918299cb8886@mail.gmail.com>
References: <6eabacb40806241709y79d63206r6402918299cb8886@mail.gmail.com>
Message-ID: <4866D78B.605@matroska.org>

Mike Green wrote:
> Hi, I am currently writting some software that will work with MKV files. 
> The project will be written in VB.Net and on a Windows platform.  I was 
> trying to find a COM Object that I could import into Visual Studio.Net 
> 2005 that would allow me to read the contents of an MKV file 
> programmically.  Most of the searches on the Internet talked about the 
> two files in the title of this email.  I went to your site and tried to 
> figure out how to get the source code into a compiled DLL, but I am not 
> that strong at doing this.  Libmatroska and Libebml also come with 
> MKVExtract but I had no luck trying to import those versions into VS.Net 
> as it said they were invalid files.  Do you know of anyway I could do 
> this or have knowledge of existing code in VB.Net (even C#) that works 
> with MKV files.

It depends on what your COM objects should do. But you may just use 
Haali's splitter and muxer.

Steve


From slhomme at matroska.org  Sun Jun 29 02:45:59 2008
From: slhomme at matroska.org (Steve Lhomme)
Date: Sat, 28 Jun 2008 18:45:59 -0600
Subject: [Matroska-devel] [Fwd: Re:  Dirac mapping for Matroska]
In-Reply-To: <1214333308.3084.22.camel@asgard.lan>
References: <1214313083.3084.9.camel@asgard.lan>
	<1214333308.3084.22.camel@asgard.lan>
Message-ID: <4866DB47.7090403@matroska.org>

Sebastian Dr?ge wrote:
> Ok, after talking to one of the Dirac developers I'd like to change the
> previous proposal completely ;)
> 
> The plan would now be:
> - CodecID is "V_DIRAC"
> - No CodecPrivate, no changing of the stream
> - A Matroska block/lace contains all Dirac packets up to and
>   including a picture. This means, all padding, maybe a sequence
>   header and maybe auxiliary data and then the picture for which
>   all this previous data was. This makes demuxing much easier
>   and prevents broken streams created by a muxer or demuxer.

I liked the previous proposal better. Is there a reason why you to store 
metadata in the "playback blocks" ? Only data needed for decoding should 
be put in a cluster. There is room for plenty of metadata elsewhere 
(tracks, tags, chapters and more can be added if necessary). Does it 
also include padding ???

> - A block is a keyframe whenever it contains a sequence header.
>   Sequence headers are added to the stream by the encoder at
>   places that are meant as "seek points" and on which decoding
>   could start. There's no easy way of detecting whether a picture
>   can be decoded on it's own in any other way.

That means only those frames with a sequence header should be marked as 
keyframes in SimpleBlock. I'm not use using the other "reference system" 
is necessary.

> The Track elements can contain the video width/depth, aspect ratio,
> framerate etc but that's not required. Also setting the ReferenceBlock
> element is not necessary.
> 
> What do you think? This is rather easy to implement, allows all
> flexibility and makes sure that the Dirac streams are not damaged ;)

You mean it's as close to the original as possible. Except it doesn't 
take of matroska to store the data in the appropriate place. Using VfW 
will give the same (bad) result.

Steve



From seelie at faireal.net  Sun Jun 29 06:15:41 2008
From: seelie at faireal.net (Liisachan)
Date: Sun, 29 Jun 2008 04:15:41 +0000
Subject: [Matroska-devel] on ssa/ass
In-Reply-To: <4866C53F.8030905@matroska.org>
References: <9B49D7D7290.00000B38jaab43@inbox.com>
	<4866C53F.8030905@matroska.org>
Message-ID: <48670C6D.9070303@faireal.net>

The page says "Timing is in h:mm:ss.mm (millisec)." but it should be
"h:mm:ss.cc (centisec)"

Steve Lhomme wrote:
> Jeff wrote:
>> some links don't work  here examples:http://www.eswat.demon.co.uk/  on 
>> http://www.matroska.org/technical/specs/subtitles/ssa.html
> 
> Fixed
> Steve
> _______________________________________________
> Matroska-devel mailing list
> Matroska-devel at lists.matroska.org
> http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel
> Read Matroska-Devel on GMane: http://dir.gmane.org/gmane.comp.multimedia.matroska.devel
> 



From jurgenwilma at telfort.nl  Fri Jun 27 19:24:07 2008
From: jurgenwilma at telfort.nl (jurgenwilma at telfort.nl)
Date: Fri, 27 Jun 2008 19:24:07 +0200
Subject: [Matroska-devel] Matroska to DVD
Message-ID: <48652237.8060709@telfort.nl>

I watch my movies on TV, not on my computer. And I want to safe space on 
my hard disk.
However my DVD-player cannot  play Matroska files.
Is there software that in one step can reliably turn Matroska files into 
DVD Video format?
Otherwise I will have to ask others not to upload Matroska files.


From mzleason at mtu.edu  Sat Jun 28 01:56:52 2008
From: mzleason at mtu.edu (Max Leason)
Date: Fri, 27 Jun 2008 18:56:52 -0500
Subject: [Matroska-devel] Java mkv header parser
Message-ID: <6d6b04580806271656w1f4b3dack84c62e4279d4b61@mail.gmail.com>

Hi,

I read in google group that the matroksa group has java mkv header parser,
I'm hoping that I could use it to read basic information. I would be very
appreciative if i could use the parser.

Thanks,
Max Leason
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.matroska.org/pipermail/matroska-devel/attachments/20080627/114f257f/attachment.html>

From slhomme at matroska.org  Sun Jun 29 14:36:41 2008
From: slhomme at matroska.org (Steve Lhomme)
Date: Sun, 29 Jun 2008 06:36:41 -0600
Subject: [Matroska-devel] on ssa/ass
In-Reply-To: <48670C6D.9070303@faireal.net>
References: <9B49D7D7290.00000B38jaab43@inbox.com>	<4866C53F.8030905@matroska.org>
	<48670C6D.9070303@faireal.net>
Message-ID: <486781D9.7070907@matroska.org>

Liisachan wrote:
> The page says "Timing is in h:mm:ss.mm (millisec)." but it should be
> "h:mm:ss.cc (centisec)"

Fixed too.Thanks Liisachan.

Steve

> Steve Lhomme wrote:
>> Jeff wrote:
>>> some links don't work  here examples:http://www.eswat.demon.co.uk/  on 
>>> http://www.matroska.org/technical/specs/subtitles/ssa.html
>> Fixed
>> Steve
>> _______________________________________________
>> Matroska-devel mailing list
>> Matroska-devel at lists.matroska.org
>> http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel
>> Read Matroska-Devel on GMane: http://dir.gmane.org/gmane.comp.multimedia.matroska.devel
>>
> 
> _______________________________________________
> Matroska-devel mailing list
> Matroska-devel at lists.matroska.org
> http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel
> Read Matroska-Devel on GMane: http://dir.gmane.org/gmane.comp.multimedia.matroska.devel



From davidf+nntp at woaf.net  Sun Jun 29 19:03:10 2008
From: davidf+nntp at woaf.net (David Flynn)
Date: Sun, 29 Jun 2008 17:03:10 +0000 (UTC)
Subject: [Matroska-devel] [Fwd: Re:  Dirac mapping for Matroska]
References: <1214313083.3084.9.camel@asgard.lan>
	<1214333308.3084.22.camel@asgard.lan>
	<4866DB47.7090403@matroska.org>
Message-ID: <slrng6fg2e.gf5.davidf+nntp@dog.thdo.woaf.net>

On 2008-06-29, Steve Lhomme <slhomme at matroska.org> wrote:
> Sebastian Dr?ge wrote:
>> - A Matroska block/lace contains all Dirac packets up to and
>>   including a picture. This means, all padding, maybe a sequence
>>   header and maybe auxiliary data and then the picture for which
>>   all this previous data was. This makes demuxing much easier
>>   and prevents broken streams created by a muxer or demuxer.
> I liked the previous proposal better. Is there a reason why you to store 
> metadata in the "playback blocks" ? Only data needed for decoding should 
> be put in a cluster. There is room for plenty of metadata elsewhere 
> (tracks, tags, chapters and more can be added if necessary). Does it 
> also include padding ???

Our general desire for a wrapping format is to provide muxing, substream
sync (eg, a/v), seeking, metadata and optionally end-to-end sync (eg, PCR
in mpegts).  What isn't really required is messing about with the
elementary stream itself.

There is no carraige of 'nonessential' metadata in a dirac elementary
stream.  A sequence header is essential.

Duplicating essential parameters contained in the sequence header
into well defined aspects of the wrapper's metadata structures is fine.
Eg, frame width, height, physical aspect ratio, sample aspect ratio,
frame rates, colour space, etc.,

If your experience is that decoders rely on some of this information
being in the wrapper, then by all means mandate duplicating it.

Things like copyright statements, authors, titles, etc., all belong with
the wrapper.  I'd even go so far to say timecodes belong there too -- as
long as they have a good definition.

However striping things out of the elementary stream (even padding data)
isn't a good idea.  If it is in the elementary stream, the coder has a
pretty good reason for it being there.  Temporal ordering of the data is
important, so hiding parts of it in private data sections and expecting
a demuxer to get it right when reconstructing it all just sounds like a
severe ammount of extra work.

Put slightly differently:

The only point we can give you guarantees on decodeability is when a
sequence header occurs.  It isn't wise to assume that any old 'I'frame
could have a sequence header (that has been stashed away somewhere in
the wrapper) inserted infront of it to make it into some form of random
access point.

> You mean it's as close to the original as possible. Except it doesn't 
> take of matroska to store the data in the appropriate place. Using VfW 
> will give the same (bad) result.

Please could you elaborate on 'appropriate place' and what the bad
result is?



From slhomme at matroska.org  Sun Jun 29 20:06:26 2008
From: slhomme at matroska.org (Steve Lhomme)
Date: Sun, 29 Jun 2008 12:06:26 -0600
Subject: [Matroska-devel] [Fwd: Re:  Dirac mapping for Matroska]
In-Reply-To: <slrng6fg2e.gf5.davidf+nntp@dog.thdo.woaf.net>
References: <1214313083.3084.9.camel@asgard.lan>	<1214333308.3084.22.camel@asgard.lan>	<4866DB47.7090403@matroska.org>
	<slrng6fg2e.gf5.davidf+nntp@dog.thdo.woaf.net>
Message-ID: <4867CF22.1040404@matroska.org>

David Flynn wrote:
> On 2008-06-29, Steve Lhomme <slhomme at matroska.org> wrote:
>> Sebastian Dr?ge wrote:
>>> - A Matroska block/lace contains all Dirac packets up to and
>>>   including a picture. This means, all padding, maybe a sequence
>>>   header and maybe auxiliary data and then the picture for which
>>>   all this previous data was. This makes demuxing much easier
>>>   and prevents broken streams created by a muxer or demuxer.
>> I liked the previous proposal better. Is there a reason why you to store 
>> metadata in the "playback blocks" ? Only data needed for decoding should 
>> be put in a cluster. There is room for plenty of metadata elsewhere 
>> (tracks, tags, chapters and more can be added if necessary). Does it 
>> also include padding ???
> 
> Our general desire for a wrapping format is to provide muxing, substream
> sync (eg, a/v), seeking, metadata and optionally end-to-end sync (eg, PCR
> in mpegts).  What isn't really required is messing about with the
> elementary stream itself.
> 
> There is no carraige of 'nonessential' metadata in a dirac elementary
> stream.  A sequence header is essential.
> 
> Duplicating essential parameters contained in the sequence header
> into well defined aspects of the wrapper's metadata structures is fine.
> Eg, frame width, height, physical aspect ratio, sample aspect ratio,
> frame rates, colour space, etc.,
> 
> If your experience is that decoders rely on some of this information
> being in the wrapper, then by all means mandate duplicating it.
> 
> Things like copyright statements, authors, titles, etc., all belong with
> the wrapper.  I'd even go so far to say timecodes belong there too -- as
> long as they have a good definition.
> 
> However striping things out of the elementary stream (even padding data)
> isn't a good idea.  If it is in the elementary stream, the coder has a
> pretty good reason for it being there.  Temporal ordering of the data is
> important, so hiding parts of it in private data sections and expecting
> a demuxer to get it right when reconstructing it all just sounds like a
> severe ammount of extra work.
> 
> Put slightly differently:
> 
> The only point we can give you guarantees on decodeability is when a
> sequence header occurs.  It isn't wise to assume that any old 'I'frame
> could have a sequence header (that has been stashed away somewhere in
> the wrapper) inserted infront of it to make it into some form of random
> access point.

I agree the elementary stream should keep all the information it needs, 
regardless of the container. If this is what you propose, then it's 
fine. I just had the impression that a lot more stuff was stored in such 
matroska blocks, where they don't belong.

>> You mean it's as close to the original as possible. Except it doesn't 
>> take of matroska to store the data in the appropriate place. Using VfW 
>> will give the same (bad) result.
> 
> Please could you elaborate on 'appropriate place' and what the bad
> result is?

Again, this is about all data that are not necessary for playback, that 
I don't want to end up in the blocks. If this is the case, then it's fine.

Steve



From davidf+nntp at woaf.net  Mon Jun 30 00:06:20 2008
From: davidf+nntp at woaf.net (David Flynn)
Date: Sun, 29 Jun 2008 22:06:20 +0000 (UTC)
Subject: [Matroska-devel] [Fwd: Re:  Dirac mapping for Matroska]
References: <1214313083.3084.9.camel@asgard.lan>
	<1214333308.3084.22.camel@asgard.lan>
	<4866DB47.7090403@matroska.org>
	<slrng6fg2e.gf5.davidf+nntp@dog.thdo.woaf.net>
	<4867CF22.1040404@matroska.org>
Message-ID: <slrng6g1qs.gf5.davidf+nntp@dog.thdo.woaf.net>

On 2008-06-29, Steve Lhomme <slhomme at matroska.org> wrote:
> Again, this is about all data that are not necessary for playback, that 
> I don't want to end up in the blocks. If this is the case, then it's fine.

Ok, we're in agreement here.

..david