From slhomme at matroska.org  Thu Jun  2 13:24:48 2011
From: slhomme at matroska.org (Steve Lhomme)
Date: Thu, 2 Jun 2011 13:24:48 +0200
Subject: [Matroska-devel] FW: Simply exapmle for libmatroshka
In-Reply-To: <!&!AAAAAAAAAAAYAAAAAAAAANUp7W53VBNAuuHzTEpoQtjCgAAAEAAAAHaoHrHc581GkjGjMMGuYXkBAAAAAA==@gmail.com>
References: <Acwblm+bmzadUAmFT1WZQuvOz62PUAAABGGw>
	<!&!AAAAAAAAAAAYAAAAAAAAANUp7W53VBNAuuHzTEpoQtjCgAAAEAAAAHaoHrHc581GkjGjMMGuYXkBAAAAAA==@gmail.com>
Message-ID: <BANLkTinxwq-Yr=Lti-R=MkRaTzLu4rvgBw@mail.gmail.com>

Hello,

2011/5/26 Dmitry Alexeeff <dmitryalexeeff at gmail.com>:
> Hello!
> I researched MKV format and libraries for him.
> Where can I find a simple example of using "libmatroska", which demonstrate
> the creation of mkv-file with a simple structure, including "EBML Header",
> "Meta Seek", "Segment info" and the segments of video.

For now there is no documentation. You may try to look at mkclean
which is in C and reads/writes Matroska files. In general the matroska
libraries (we provide) do not have much documentation. And they
require a bit of knowledge of how Matroska works to be used.

Steve

> ? ?????????,
> ???????? ??????? ??????????
> e-mail: dmitryalexeeff at gmail.com
>
>
>
> _______________________________________________
> 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



-- 
Steve Lhomme
Matroska association Chairman


From dave at avpreserve.com  Wed Jun  8 17:29:49 2011
From: dave at avpreserve.com (Dave Rice)
Date: Wed, 8 Jun 2011 11:29:49 -0400
Subject: [Matroska-devel] matroska and process/history metadata tags
In-Reply-To: <3EA50DDD-DB5A-423F-A627-CCB1B158048A@avpreserve.com>
References: <3EA50DDD-DB5A-423F-A627-CCB1B158048A@avpreserve.com>
Message-ID: <25796CE3-E8DB-4B31-A7D1-5B4BB556BAE9@avpreserve.com>

Hi all,
	I've been working on utilizing metadata tags to document the creation process of the file in more detail (especially in environments where the source material is analog tape). I uploaded a sample MKV using these kinds of tags here: http://www.avpreserve.com/pres_metadata_sample_20110608.mkv. Official tags are in ALL CAPS and unofficial tags for documenting creation process metadata are lowercase. For now I added initial_source_timecode as a metadata tag to enable the possibility to relate frames within the MKV to frame of the source analog tape since there doesn't seem to be a better way to do this. Any feedback on the arrangement of metadata tags or this type of use of Matroska is appreciated.

Best Regards,

Dave Rice
avpreserve.com

On May 23, 2011, at 10:51 AM, Dave Rice wrote:

> Hi all,
> 
> I'm working in a project that is considering the use of Matroska within a digital preservation environment. One of the goals is to enable the files to be highly self-descriptive noting the relationships to source material (in this case analog tapes digitized to Matroska files), technical aspects of the source material itself, and metadata about the process that created the Matroska file (digitization using which hardware, software, etc).
> 
> This material is useful when using the content. For instance this data would allow information on the source object, it's condition, and the setup of the digitization process itself to be documented within the Matroska file, similar to how Broadcast Wave Format uses codingHistory.
> 
> To help enable use of Matroska within video preservation and archival environments, we'd like to propose additional Matroska tags for the following two purposes:
> 
> - Source Object Metadata: allowing more granular details about the source tape (beyond ORIGINAL_MEDIA_TYPE)
> - Process Metadata: allowing a description of the digitization process (especially relevant to working with non-file-based source material).
> 
> To describe the source material, it seems the best use of current nested tags is:
> ORIGINAL_MEDIA_TYPE - to say "CD" or "Betacam"
> ORIGINAL_MEDIA_TYPE/BARCODE - to provide the barcode of the source media ORIGINAL_MEDIA_TYPE/LABEL - to document the labeling of the source media ORIGINAL_MEDIA_TYPE/DATE_RECORDED - date original source media was recorded, if known ORIGINAL_MEDIA_TYPE/MANUFACTURER - manufacturer of source media format
> 
> Since the quality or condition of the source tape affects the resulting file and provides context, these fields could be added:
> ORIGINAL_MEDIA_TYPE/QUALITY - for qualitative statements about the conditions of the source media ORIGINAL_MEDIA_TYPE/QUALITY/TYPE (example: Physical, Picture, Audio, RF Level, Drop Out Activity)
> 
> To document the process that created the file we started with a combination of the 'environment' and 'event' metadata structures from PREMIS (http://www.loc.gov/standards/premis/).
> 
> EVENT="clean, transfer, signal process, edit, physical restoration, etc"
> EVENT/DATE
> EVENT/SOFTWARE - name of software used
> EVENT/SOFTWARE/ROLE - role of software, e.g. capture, edit, driver, operating system, etc
> EVENT/SOFTWARE/VERSION - version number of software
> EVENT/HARDWARE - name of hardware used, e.g. playback deck
> EVENT/HARDWARE/ROLE - role of hardware, e.g. analog-to-digital conversion, playback, processor, etc
> EVENT/HARDWARE/MANUFACTURER - manufacturer of hardware
> EVENT/HARDWARE/SERIAL_NO - identifier of hardware
> EVENT/TRANSFER_METHOD - protocol used to transfer audiovisual data, e.g. composite, component, ieee 1394
> EVENT/ACTIONS - description of actions performed within event, e.g. trim silence, normalize
> EVENT/COMMENTS - notes about the event such as noted errors or untypical outcomes
> 
> Another approach is to list more fields without the nested structure.
> 
> SOURCE OBJECT CONDITION (Comments on the condition of the source, any preparation for playback of the source tape, if relevant): Tape had minor exterior damage. Tape was cleaning with an XYZ machine.
> DATE DIGITIZED (Date and time of the file creation process. Enter in ISO 8601 format): 2011-01-13T19:20:30-05:00
> DIGITIZATION EVENTS (Comments about the digitization process including notable time-based events, if relevant): Damage to the source tape prevented digitization of the first ~10 minutes of content
> ENCODED BY (Name of the technician or organization   responsible for the encoding and file creation process): Vendor ABC, Inc.
> CAPTURE DEVICE SETTINGS (Describe the settings or configuration of the capture device)
> PLAYBACK DECK SETTINGS (Describe settings of the playback device)
> PLAYBACK DEVICE MANUFACTURER (Name of the company that manufactured the tape player used to play the tape): Sony
> PLAYBACK DEVICE MODEL (Model name and number of the tape player used to play the tape): SVO-5800
> PLAYBACK DEVICE SERIALNO (Serial number of the tape player used to play the tape): Xyz1234
> CAPTURE DEVICE MANUFACTURER (Name of the company that manufactured the A/D card used to capture the digital file): Blackmagic Design
> CAPTURE DEVICE MODEL (Model name and number of the A/D card used to capture the digital file): Decklink Studio
> CAPTURE DEVICE SERIALNO (Serial number of the A/D card used to capture the digital file): Abc1324
> CAPTURE DEVICE SOFTWARE (Software used to operate the A/D card): Media Express
> OPERATING SYSTEM (Name and version of the operating system running the computer used to scan and/or process the image): Ubuntu 10.10
> PLAYBACK SIGNAL PATH (Protocols used to transfer audiovisual data between the playback deck and the capture device): Component
> PROCESSING ACTIONS (Description of any actions performed during processing, such as trimming silence)
> SOURCE OBJECT TRACK CONFIGURATION (Describe the intended audio track presentation of the source object): Four track mono
> 
> We're sending these notes along for the consideration of the Matroska-devel group. If this initial draft and the scope of the tags used here look okay, then we can document them more formally with definitions and links to external authorities of these terms.
> 
> Best Regards,
> 
> Dave Rice
> avpreserve.com
> 
> _______________________________________________
> 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 Phillip.Maness at dts.com  Fri Jun 10 03:14:50 2011
From: Phillip.Maness at dts.com (Phillip Maness)
Date: Thu, 9 Jun 2011 18:14:50 -0700
Subject: [Matroska-devel] Support for DTS and DTS-HD formats in the mkv
	container
Message-ID: <CC969E2A3C4C87448263E65F8C9878DD10EF2D9E73@EXCHANGE2K7.dts.local>

Hi,

I work for DTS in the standards group and handle most of our media formats definitions work.

I would like to add support for some additional DTS-HD audio configurations to the mkv format. Currently we have A_DTS defined, which seems to have been used somewhat successfully with DTS-HD formats that include the DTS core substream (e.g. DTS-HD Master Audio), in that DTS-HD decoders will process the complete substream, and most DTS decoders will process the core substream portion and discard the remainder, but I think there are some decoders that choke on the DTS-HD streams.

We have two additional configurations of DTS-HD that we would like to support, and these formats will definitely not play on older DTS decoders, so they need be signaled differently than the other DTS format. One of these formats is DTS Express, a.k.a. DTS LBR, the other is DTS-HD Lossless without a core substream. (we don't have a marketing name for this yet).

We have also have registered a code for the original DTS format with MPEG4RA, which is 'dtsc'. I don't know if it would be problematic to have a redundant definition or to switch over from the old FOURCCMap (0x2001) and CodecID (A_DTS)? It might make life easier for our partners starting with MPEG-4 ISO media files and embedding them into the Matroska container. I realize the existing codes for DTS were defined prior to our registration in MPEG4RA.

I would suggest we mirror what we've defined in MPEG4RA, which would be to signal our codecs as follows :

CodecID

CodecPrivate format

DirectShow mediatype format

Comment

A_DTSL
DTS Lossless

None

Subtype

FOURCCMap('dtsl')

DTS-HD Lossless audio streams

Format

WaveFormatEx



A_DTSE
DTS Express

None

Subtype

FOURCCMap('dtse')

DTS Express audio streams

Format

WaveFormatEx



A_DTSH
DTS-HD

None

Subtype

FOURCCMap('dtsh')

DTS-HD audio streams that include a core substream, including lossless streams, e.g. DTS-HD Master Audio
DTS-HD High Resolution Audio

Format

WaveFormatEx



A_DTSC
DTS

None

Subtype

FOURCCMap('dtsc')

DTS core audio streams, e.g.
DTS, DTS-ES, DTS-96/24

Format

WaveFormatEx





Does this seem reasonable or is there another approach that would work better for the format?

Best regards,
Phil Maness


DTS, Inc.
5220 Las Virgenes Road
Calabasas, CA 91302
Tel: (818) 436-1361
Fax: (818) 436-1861
email: phillip.maness at dts.com
Check out my company's latest award winning video on YouTube: http://www.youtube.com/watch?v=9BANqbtl2D4

Notice:
This message and any included attachments are intended only for the use of the addressee, and may contain information that is privileged or confidential. If you are not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please destroy the original message and any copies or printouts hereof.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.matroska.org/pipermail/matroska-devel/attachments/20110609/2237468e/attachment.html>

From moritz at bunkus.org  Fri Jun 10 09:56:42 2011
From: moritz at bunkus.org (Moritz Bunkus)
Date: Fri, 10 Jun 2011 09:56:42 +0200
Subject: [Matroska-devel] Support for DTS and DTS-HD formats in the mkv
	container
In-Reply-To: <CC969E2A3C4C87448263E65F8C9878DD10EF2D9E73@EXCHANGE2K7.dts.local>
References: <CC969E2A3C4C87448263E65F8C9878DD10EF2D9E73@EXCHANGE2K7.dts.local>
Message-ID: <201106100956.43886.moritz@bunkus.org>

Hey,

On Friday 10 June 2011 03:14:50 Phillip Maness wrote:

> I would like to add support for some additional DTS-HD audio
> configurations to the mkv format. Currently we have A_DTS defined,
> which seems to have been used somewhat successfully with DTS-HD
> formats that include the DTS core substream (e.g. DTS-HD Master
> Audio), in that DTS-HD decoders will process the complete substream,
> and most DTS decoders will process the core substream portion and
> discard the remainder, but I think there are some decoders that choke
> on the DTS-HD streams.

That is indeed the case. A_DTS is used for DTS-HD as well with the
assumption that DTS decoders must skip unknown content if they don't
support it -- meaning the HD extensions. This was done in order not to
require existing demuxers to be updated for DTS-HD as they mapped DTS
and DTS-HD to the same codecs/media types at that time.

> We have two additional configurations of DTS-HD that we would like to
> support, and these formats will definitely not play on older DTS
> decoders, so they need be signaled differently than the other DTS
> format. One of these formats is DTS Express, a.k.a. DTS LBR, the other
> is DTS-HD Lossless without a core substream. (we don't have a
> marketing name for this yet).

If they're that incompatible then they do indeed need their own codec ID
in Matroska, yes.

> We have also have registered a code for the original DTS format with
> MPEG4RA, which is 'dtsc'. I don't know if it would be problematic to
> have a redundant definition or to switch over from the old FOURCCMap
> (0x2001) and CodecID (A_DTS)? It might make life easier for our
> partners starting with MPEG-4 ISO media files and embedding them into
> the Matroska container. I realize the existing codes for DTS were
> defined prior to our registration in MPEG4RA.

I don't like renaming codec IDs for existing formats just to fit with a
new naming scheme. There are tons of hardware and software devices out
there that use the existing A_DTS and that would be incompatible for no
good reason. Therefore I'd veto renaming A_DTS to anything else (neither
A_DTSC nor anything else).

I'm undecided about splitting HD from A_DTS ( -> A_DTS). I'd argue that
there are so few problems (in fact I haven't heard of a single problem
on doom9 or in private mails) that I again think that breaking
compatibility with existing devices is not worth it.

For the other types: the current naming scheme for codec IDs is a bit
more verbose than what you're proposing. Also we don't aim to name codec
ID the same as they're named in registries for other formats. Therefore
what about...

> A_DTSL
> DTS Lossless

A_DTS/LOSSLESS or A_DTS/HD/LOSSLESS, depending on the marketing name

> A_DTSE
> DTS Express

A_DTS/EXPRESS

> A_DTSH
> DTS-HD

Like I said above, but if we split it up then it would be probably be
A_DTS/HD.

> A_DTSC
> DTS

Like I said above, I don't want this unless you can convince me of a
technical necessity for it.

Regards,
mosu
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.matroska.org/pipermail/matroska-devel/attachments/20110610/b8cff2e8/attachment.pgp>

From Phillip.Maness at dts.com  Wed Jun 15 19:53:45 2011
From: Phillip.Maness at dts.com (Phillip Maness)
Date: Wed, 15 Jun 2011 10:53:45 -0700
Subject: [Matroska-devel] Support for DTS and DTS-HD formats in the
	mkv	container
In-Reply-To: <201106100956.43886.moritz@bunkus.org>
References: <CC969E2A3C4C87448263E65F8C9878DD10EF2D9E73@EXCHANGE2K7.dts.local>
	<201106100956.43886.moritz@bunkus.org>
Message-ID: <CC969E2A3C4C87448263E65F8C9878DD10EF54F6D6@EXCHANGE2K7.dts.local>

Hi Moritz,

I checked with our certification department and they are fine with your proposal. We actually test the digital media players to properly decode the core when they receive Master Audio or High Res., so adding ADTS/EXPRESS and ADTS/LOSSLESS seems like the best approach. Would these still use the same codec ID, (0x2001) or will new ones be assigned to the new profiles?

Thanks,
Phil

-----Original Message-----
From: matroska-devel-bounces at lists.matroska.org [mailto:matroska-devel-bounces at lists.matroska.org] On Behalf Of Moritz Bunkus
Sent: Friday, June 10, 2011 12:57 AM
To: matroska-devel at lists.matroska.org
Subject: Re: [Matroska-devel] Support for DTS and DTS-HD formats in the mkv container

* PGP Signed by an unknown key

Hey,

On Friday 10 June 2011 03:14:50 Phillip Maness wrote:

> I would like to add support for some additional DTS-HD audio 
> configurations to the mkv format. Currently we have A_DTS defined, 
> which seems to have been used somewhat successfully with DTS-HD 
> formats that include the DTS core substream (e.g. DTS-HD Master 
> Audio), in that DTS-HD decoders will process the complete substream, 
> and most DTS decoders will process the core substream portion and 
> discard the remainder, but I think there are some decoders that choke 
> on the DTS-HD streams.

That is indeed the case. A_DTS is used for DTS-HD as well with the assumption that DTS decoders must skip unknown content if they don't support it -- meaning the HD extensions. This was done in order not to require existing demuxers to be updated for DTS-HD as they mapped DTS and DTS-HD to the same codecs/media types at that time.

> We have two additional configurations of DTS-HD that we would like to 
> support, and these formats will definitely not play on older DTS 
> decoders, so they need be signaled differently than the other DTS 
> format. One of these formats is DTS Express, a.k.a. DTS LBR, the other 
> is DTS-HD Lossless without a core substream. (we don't have a 
> marketing name for this yet).

If they're that incompatible then they do indeed need their own codec ID in Matroska, yes.

> We have also have registered a code for the original DTS format with 
> MPEG4RA, which is 'dtsc'. I don't know if it would be problematic to 
> have a redundant definition or to switch over from the old FOURCCMap
> (0x2001) and CodecID (A_DTS)? It might make life easier for our 
> partners starting with MPEG-4 ISO media files and embedding them into 
> the Matroska container. I realize the existing codes for DTS were 
> defined prior to our registration in MPEG4RA.

I don't like renaming codec IDs for existing formats just to fit with a new naming scheme. There are tons of hardware and software devices out there that use the existing A_DTS and that would be incompatible for no good reason. Therefore I'd veto renaming A_DTS to anything else (neither A_DTSC nor anything else).

I'm undecided about splitting HD from A_DTS ( -> A_DTS). I'd argue that there are so few problems (in fact I haven't heard of a single problem on doom9 or in private mails) that I again think that breaking compatibility with existing devices is not worth it.

For the other types: the current naming scheme for codec IDs is a bit more verbose than what you're proposing. Also we don't aim to name codec ID the same as they're named in registries for other formats. Therefore what about...

> A_DTSL
> DTS Lossless

A_DTS/LOSSLESS or A_DTS/HD/LOSSLESS, depending on the marketing name

> A_DTSE
> DTS Express

A_DTS/EXPRESS

> A_DTSH
> DTS-HD

Like I said above, but if we split it up then it would be probably be A_DTS/HD.

> A_DTSC
> DTS

Like I said above, I don't want this unless you can convince me of a technical necessity for it.

Regards,
mosu

* Unknown Key
* 0xB6571FCA

Notice:
This message and any included attachments are intended only for the use of the addressee, and may contain information that is privileged or confidential. If you are not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please destroy the original message and any copies or printouts hereof.

Notice:
This message and any included attachments are intended only for the use of the addressee, and may contain information that is privileged or confidential. If you are not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please destroy the original message and any copies or printouts hereof.


From slhomme at matroska.org  Wed Jun 15 21:45:26 2011
From: slhomme at matroska.org (Steve Lhomme)
Date: Wed, 15 Jun 2011 21:45:26 +0200
Subject: [Matroska-devel] Support for DTS and DTS-HD formats in the mkv
	container
In-Reply-To: <201106100956.43886.moritz@bunkus.org>
References: <CC969E2A3C4C87448263E65F8C9878DD10EF2D9E73@EXCHANGE2K7.dts.local>
	<201106100956.43886.moritz@bunkus.org>
Message-ID: <BANLkTinE5-Hdo0zx_U+Z8o-6Amvxp5TWvQ@mail.gmail.com>

On Fri, Jun 10, 2011 at 9:56 AM, Moritz Bunkus <moritz at bunkus.org> wrote:
> On Friday 10 June 2011 03:14:50 Phillip Maness wrote:
> I'm undecided about splitting HD from A_DTS ( -> A_DTS). I'd argue that
> there are so few problems (in fact I haven't heard of a single problem
> on doom9 or in private mails) that I again think that breaking
> compatibility with existing devices is not worth it.

I think it's better not to break what we have today. But we could mark
HD and non-HD with the codec private. It should be discarded by
existing players adn DTS decoders don't expect to be passed external
codec data. And it would be possible to spot which one are actually HD
without breaking anything. (non-HD ones will simply have no codec
private data set).

-- 
Steve Lhomme
Matroska association Chairman


From office at it-riegler.at  Thu Jun 16 14:57:13 2011
From: office at it-riegler.at (Riegler Markus)
Date: Thu, 16 Jun 2011 14:57:13 +0200
Subject: [Matroska-devel] SImple Block Header
Message-ID: <4DF9FDA9.7010109@it-riegler.at>

Hi,

I'm working with WebM so I have to understand Matroska. But I have a 
problem with the Simple Block header. I don't understand that.
I have some questions about that:
Where do I get the Header Size of a Simple Block?
Where I can get the Frame Size or the data amount from the simple block.
And what is meant with


        Block Structure

Size = 1 + (1-8) + 4 + (4 + (4)) octets. So from 6 to 21 octets.
???

Can anywone help me?
Thx a lot.


-- 
______________________________________________
INFORMATIONSTECHNOLOGIE RIEGLER MARKUS


BSc. Riegler Markus
Information Security

Traisnerstra?e 22
3170 Hainfeld
Mobil: 0664 49 60 585
E: office at it-riegler.at
I: www.it-riegler.at

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.matroska.org/pipermail/matroska-devel/attachments/20110616/6bb3f75d/attachment.html>

From moritz at bunkus.org  Thu Jun 16 15:13:40 2011
From: moritz at bunkus.org (Moritz Bunkus)
Date: Thu, 16 Jun 2011 15:13:40 +0200
Subject: [Matroska-devel] SImple Block Header
In-Reply-To: <4DF9FDA9.7010109@it-riegler.at>
References: <4DF9FDA9.7010109@it-riegler.at>
Message-ID: <201106161513.40352.moritz@bunkus.org>

Hey,

a simple block element, like every other EBML element, begins with its
ID and its total size.

> Size = 1 + (1-8) + 4 + (4 + (4)) octets. So from 6 to 21 octets.

Here: The ID of the simple block element is one byte long (0xA3), hence
the "1".

The total size of the element can be anywhere from 6 to several million
bytes. The size is encoded the same everywhere: as a variable length
integer. Hence the "(1-8)", meaning it is coded with at least 1 but at
most 8 bytes.

The next element is the track number etc. This is usually one byte long,
but can be longer; again it's a variable length integer.

Then there's the relative timecode stored as a two-byte signed integer.

Well... I don't understand the 4 + (4 + (4)) part either ;) Follow
http://www.matroska.org/technical/specs/index.html#simpleblock_structure
How to calculate lacing is shown right above that section.

Regards,
mosu
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.matroska.org/pipermail/matroska-devel/attachments/20110616/e62abf6c/attachment.pgp>

From slhomme at matroska.org  Sat Jun 18 14:04:50 2011
From: slhomme at matroska.org (Steve Lhomme)
Date: Sat, 18 Jun 2011 14:04:50 +0200
Subject: [Matroska-devel] SImple Block Header
In-Reply-To: <201106161513.40352.moritz@bunkus.org>
References: <4DF9FDA9.7010109@it-riegler.at>
	<201106161513.40352.moritz@bunkus.org>
Message-ID: <BANLkTinB34TdCFvMtpQ5Sx4_SGrBGfi0Xw@mail.gmail.com>

Yes the (4 + (4+4) seem odd, but it's very likely to take care of
different ways of lacing the content.

On Thu, Jun 16, 2011 at 3:13 PM, Moritz Bunkus <moritz at bunkus.org> wrote:
> Hey,
>
> a simple block element, like every other EBML element, begins with its
> ID and its total size.
>
>> Size = 1 + (1-8) + 4 + (4 + (4)) octets. So from 6 to 21 octets.
>
> Here: The ID of the simple block element is one byte long (0xA3), hence
> the "1".
>
> The total size of the element can be anywhere from 6 to several million
> bytes. The size is encoded the same everywhere: as a variable length
> integer. Hence the "(1-8)", meaning it is coded with at least 1 but at
> most 8 bytes.
>
> The next element is the track number etc. This is usually one byte long,
> but can be longer; again it's a variable length integer.
>
> Then there's the relative timecode stored as a two-byte signed integer.
>
> Well... I don't understand the 4 + (4 + (4)) part either ;) Follow
> http://www.matroska.org/technical/specs/index.html#simpleblock_structure
> How to calculate lacing is shown right above that section.
>
> Regards,
> mosu
>
> _______________________________________________
> 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
>



-- 
Steve Lhomme
Matroska association Chairman


From slhomme at matroska.org  Sat Jun 18 14:28:19 2011
From: slhomme at matroska.org (Steve Lhomme)
Date: Sat, 18 Jun 2011 14:28:19 +0200
Subject: [Matroska-devel] [Matroska-users] question about MKV test suite
In-Reply-To: <BANLkTikTKSWeD8nUvHjWKTTMxS4V4ZKGfg@mail.gmail.com>
References: <BANLkTikTKSWeD8nUvHjWKTTMxS4V4ZKGfg@mail.gmail.com>
Message-ID: <BANLkTimrNkwp5QGHR6PpPC2QHsk2UqnqnQ@mail.gmail.com>

Anyone ? I don't know much about codec details but surely some of you know ?

On Wed, Jun 8, 2011 at 12:12 PM, Cunsuo Guo <cunsuo.guo at gmail.com> wrote:
> Hi everybody,
> I'm currently working on a project related to MKV demux. But when I
> analyse the test1.mkv form the MKV test suite using AVI-Mux GUI, I
> found that the video data is not what I expected. The video CodecID of
> test file test1.mkv is V_MS/VFW/FOURCC, and AVI-Mux GUI shows that its
> FOURCC is MP42. Then the video data should be a MPEG4 stream, right?
> But the video data does not begin with 0x000001 (which all MPEG4 video
> stream begin with), instead it begins with 0x0978fe1f. I know the test
> suite must be OK, so there's must be something wrong with my
> understanding. Could you please let me know where I'm wrong? And I'm
> not familiar with V_MS/VFW/FOURCC, does it have something to do with
> the video data not beginning with 0x000001?
>
> Thanks for your time,
> Cunsuo
> _______________________________________________
> Matroska-users mailing list
> Matroska-users at lists.matroska.org
> http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-users
> Read Matroska-Users on GMane: http://dir.gmane.org/gmane.comp.multimedia.matroska.user
>



-- 
Steve Lhomme
Matroska association Chairman


From heaven.hunter at yahoo.com  Sun Jun 19 11:21:12 2011
From: heaven.hunter at yahoo.com (Heaven Hunter)
Date: Sun, 19 Jun 2011 02:21:12 -0700 (PDT)
Subject: [Matroska-devel] [request] load external (separated) chapter file
Message-ID: <201534.73335.qm@web46212.mail.sp1.yahoo.com>

DirectVobSub/VSFilter can take external subtitle file (.ass / .srt) to be
rendered to video. This external file is separated from the main media file.

Is it possible for Haali Media Splitter to also able to take external chapter
file (i.e. txt, xml) ?
so we can dynamicly add/edit chapter information without modify the main media file.

Sometimes there are needs for adding chapter to "unchaptered media", but somehow
we need to maintain original file. We shouldn't do any modification to the file,
and make the backup of the file isn't a choice since the size is huge.

Thanks in advance.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.matroska.org/pipermail/matroska-devel/attachments/20110619/d6c44c2f/attachment.html>

From jigar32_e at yahoo.co.in  Tue Jun 21 07:17:14 2011
From: jigar32_e at yahoo.co.in (patel jigar)
Date: Tue, 21 Jun 2011 10:47:14 +0530 (IST)
Subject: [Matroska-devel] multiple happning of level-0 & level-1 ebml
	element issue
Message-ID: <1308633434.11295.YahooMailNeo@web137304.mail.in.yahoo.com>

Hi, 


i am working on project of? Matroska demuxer library. So should i make support of mkv file with multiple segment ,multiple header or in one segment multiple tracks ,multiple segment info,multiple tags are there.?

still yet? i have not find any file with such multiple element.
please reply.


?


JIGAR PATEL
B.TECH EC?
+91 9898193850
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.matroska.org/pipermail/matroska-devel/attachments/20110621/29a54a72/attachment.html>

From dndungnguyen at gmail.com  Wed Jun 22 11:47:54 2011
From: dndungnguyen at gmail.com (DUNG NGUYEN)
Date: Wed, 22 Jun 2011 02:47:54 -0700
Subject: [Matroska-devel] Hello Matroska Group
Message-ID: <BANLkTikLewi1tX9zTVLZRcVT63S7C0Fa_w@mail.gmail.com>

Dear Everyone,

I had read MKVToolnix 4.8 release project. I was download all
libraries need for this project. I don't understand why i can't
running this project. I hope so, I receive support from everyone as
soon as possible.

Best regards
Dung Nguyen From VietNam
-------------- next part --------------
A non-text attachment was scrubbed...
Name: The My Bug.bmp
Type: image/bmp
Size: 3145782 bytes
Desc: not available
URL: <http://lists.matroska.org/pipermail/matroska-devel/attachments/20110622/37fce14b/attachment.bin>

From Phillip.Maness at dts.com  Wed Jun 22 21:53:32 2011
From: Phillip.Maness at dts.com (Phillip Maness)
Date: Wed, 22 Jun 2011 12:53:32 -0700
Subject: [Matroska-devel] Support for DTS and DTS-HD formats in the
	mkv	container
In-Reply-To: <BANLkTinE5-Hdo0zx_U+Z8o-6Amvxp5TWvQ@mail.gmail.com>
References: <CC969E2A3C4C87448263E65F8C9878DD10EF2D9E73@EXCHANGE2K7.dts.local>
	<201106100956.43886.moritz@bunkus.org>
	<BANLkTinE5-Hdo0zx_U+Z8o-6Amvxp5TWvQ@mail.gmail.com>
Message-ID: <CC969E2A3C4C87448263E65F8C9878DD10EF794235@EXCHANGE2K7.dts.local>

Thanks everyone for your input. It sounds like the following should be acceptable:

1. A_DTS is used for and DTS content that contains a core substream. It might be helpful to explicitly state this in the specification, e.g. "A_DTS supports DTS, DTS-ES, DTS-96/26, DTS-HD High Resolution Audio and DTS-HD Master Audio".

2. A_DTS/EXPRESS will be used for DTS Express (a.k.a. LBR) audio streams

3. A_DTS/LOSSLESS will be used for DTS Lossless audio that does not have a core substream

Is there any other component of the MKV spec that needs to be modified to support the two new applications of DTS codecs?

Is there anything else that needs to be taken into consideration?

Thanks,
Phil Maness

-----Original Message-----
From: matroska-devel-bounces at lists.matroska.org [mailto:matroska-devel-bounces at lists.matroska.org] On Behalf Of Steve Lhomme
Sent: Wednesday, June 15, 2011 12:45 PM
To: Discussion about the current and future development of Matroska
Subject: Re: [Matroska-devel] Support for DTS and DTS-HD formats in the mkv container

On Fri, Jun 10, 2011 at 9:56 AM, Moritz Bunkus <moritz at bunkus.org> wrote:
> On Friday 10 June 2011 03:14:50 Phillip Maness wrote:
> I'm undecided about splitting HD from A_DTS ( -> A_DTS). I'd argue that
> there are so few problems (in fact I haven't heard of a single problem
> on doom9 or in private mails) that I again think that breaking
> compatibility with existing devices is not worth it.

I think it's better not to break what we have today. But we could mark
HD and non-HD with the codec private. It should be discarded by
existing players adn DTS decoders don't expect to be passed external
codec data. And it would be possible to spot which one are actually HD
without breaking anything. (non-HD ones will simply have no codec
private data set).

-- 
Steve Lhomme
Matroska association Chairman
_______________________________________________
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

Notice:
This message and any included attachments are intended only for the use of the addressee, and may contain information that is privileged or confidential. If you are not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please destroy the original message and any copies or printouts hereof.


From moritz at bunkus.org  Wed Jun 22 22:41:38 2011
From: moritz at bunkus.org (Moritz Bunkus)
Date: Wed, 22 Jun 2011 22:41:38 +0200
Subject: [Matroska-devel]
 =?utf-8?q?Support_for_DTS_and_DTS-HD_formats_in_?=
 =?utf-8?q?the_mkv=09container?=
In-Reply-To: <CC969E2A3C4C87448263E65F8C9878DD10EF794235@EXCHANGE2K7.dts.local>
References: <CC969E2A3C4C87448263E65F8C9878DD10EF2D9E73@EXCHANGE2K7.dts.local>
	<201106100956.43886.moritz@bunkus.org>
	<BANLkTinE5-Hdo0zx_U+Z8o-6Amvxp5TWvQ@mail.gmail.com>
	<CC969E2A3C4C87448263E65F8C9878DD10EF794235@EXCHANGE2K7.dts.local>
Message-ID: <92c36ccaf16b6c70b19e00bf6b94a5b5@www.bunkus.org>

Hey,

On Wed, 22 Jun 2011 12:53:32 -0700, Phillip Maness wrote:

> Thanks everyone for your input. It sounds like the following should
> be acceptable:

Sounds good from my point of view. We'll update the specs (Steve can 
you do it? Otherwise I'll try to do it this weekend along with the 
libamtroska release).

> Is there any other component of the MKV spec that needs to be
> modified to support the two new applications of DTS codecs?

I don't think so -- unless they introduce some radical new concept that 
is relevant on the container level (e.g. track X contains only the 
differences to track Y and cannot be decoded without it -- completely 
hypothetical feature).

Regards,
mosu



From Phillip.Maness at dts.com  Fri Jun 24 20:45:59 2011
From: Phillip.Maness at dts.com (Phillip Maness)
Date: Fri, 24 Jun 2011 11:45:59 -0700
Subject: [Matroska-devel] Support for DTS and DTS-HD formats in the
	mkv	container
In-Reply-To: <92c36ccaf16b6c70b19e00bf6b94a5b5@www.bunkus.org>
References: <CC969E2A3C4C87448263E65F8C9878DD10EF2D9E73@EXCHANGE2K7.dts.local>
	<201106100956.43886.moritz@bunkus.org>
	<BANLkTinE5-Hdo0zx_U+Z8o-6Amvxp5TWvQ@mail.gmail.com>
	<CC969E2A3C4C87448263E65F8C9878DD10EF794235@EXCHANGE2K7.dts.local>
	<92c36ccaf16b6c70b19e00bf6b94a5b5@www.bunkus.org>
Message-ID: <CC969E2A3C4C87448263E65F8C9878DD10EF794B85@EXCHANGE2K7.dts.local>

Thanks

-----Original Message-----
From: matroska-devel-bounces at lists.matroska.org [mailto:matroska-devel-bounces at lists.matroska.org] On Behalf Of Moritz Bunkus
Sent: Wednesday, June 22, 2011 1:42 PM
To: Discussion about the current and future development of Matroska
Subject: Re: [Matroska-devel] Support for DTS and DTS-HD formats in the mkv container

Hey,

On Wed, 22 Jun 2011 12:53:32 -0700, Phillip Maness wrote:

> Thanks everyone for your input. It sounds like the following should
> be acceptable:

Sounds good from my point of view. We'll update the specs (Steve can 
you do it? Otherwise I'll try to do it this weekend along with the 
libamtroska release).

> Is there any other component of the MKV spec that needs to be
> modified to support the two new applications of DTS codecs?

I don't think so -- unless they introduce some radical new concept that 
is relevant on the container level (e.g. track X contains only the 
differences to track Y and cannot be decoded without it -- completely 
hypothetical feature).

Regards,
mosu

_______________________________________________
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

Notice:
This message and any included attachments are intended only for the use of the addressee, and may contain information that is privileged or confidential. If you are not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please destroy the original message and any copies or printouts hereof.


From blwarburton at btconnect.com  Sat Jun 25 17:43:15 2011
From: blwarburton at btconnect.com (BLW@BT)
Date: Sat, 25 Jun 2011 16:43:15 +0100
Subject: [Matroska-devel] Bug report: Merging SRT subtitles into MKV with 6
	channel AAC
Message-ID: <F19DBF87E5D84E30BA8E5E9DCA6675EC@nd0>

Just came across this one.

I created an MKV with AVC video and 6 channel AAC-LC 256Kbps audio using 
latest MeGUI 2028 (svn) fully updated with built-in mkvmerge 4.8.0
Duration was 59 minutes.

After checking the SRT sync I then merged in the SRT file into MKV using 
standalone version of mkvmerge GUI 4.8.0
Duration was now 69 minutes.
On playback sound stops about 10 minutes from the end.

The way around the problem is to merge the video, audio and subtitle files 
together within MeGUI and avoid using the standalone version of mkvmerge GUI 
4.8.0

I haven't tried an older version of mkvtoolnix. I suspect the 6 channel AAC 
is causing the problem as this is the first time I've used the "Nero 
Mult-channel 256Kbps" profile in MeGUI.