From hlprasu at gmail.com  Thu Nov  3 20:45:02 2011
From: hlprasu at gmail.com (Prasad H. L.)
Date: Fri, 4 Nov 2011 01:15:02 +0530
Subject: [Matroska-devel] New video format support in mkv
Message-ID: <CAKJORkh8SFbN_yaSXZkP7PQNiUza9xiDSrqfqnHPBus2MSxNXQ@mail.gmail.com>

Hi,

How easy or difficult is to add support for a new video format in the
mkv container? I am experimenting with a video codec and wish the
bit-stream generated by it for regular playback. Please let me know
whether this is possible or what needs to be done for this.

Regards,
Prasad


From park00245 at gmail.com  Fri Nov  4 04:11:27 2011
From: park00245 at gmail.com (=?ks_c_5601-1987?B?udrIrb+t?=)
Date: Fri, 4 Nov 2011 12:11:27 +0900
Subject: [Matroska-devel] V_MJPEG supported?
Message-ID: <5464BB616C0E4C4A989956232093BF74@hypark>

how are you.

I'd like to use, MJPEG video codec codec MKV files.

Please contact support for that.

If you do not support currently support MJPEG What are the plans?

Please answer.

Thank you.

--------------------------------------------------------
Hwa-youl  Park
Waytotec,Inc
 
Staff Research Engineer
 
Tel: 031-706-6546
H.P: 010-7238-1537
Fax: 02-762-2490
Email : hypark at waytotec.com
--------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.matroska.org/pipermail/matroska-devel/attachments/20111104/67368ee3/attachment.html>

From moritz at bunkus.org  Fri Nov  4 10:27:04 2011
From: moritz at bunkus.org (Moritz Bunkus)
Date: Fri, 4 Nov 2011 10:27:04 +0100
Subject: [Matroska-devel] V_MJPEG supported?
In-Reply-To: <5464BB616C0E4C4A989956232093BF74@hypark>
References: <5464BB616C0E4C4A989956232093BF74@hypark>
Message-ID: <CANPayMRq1skzra+At3HJ55D4ofqCWr_6Z-+PYtyJKD2neDfcUg@mail.gmail.com>

Hey,

2011/11/4 ??? <park00245 at gmail.com>:

> I'd like to use, MJPEG video codec codec MKV files.

There's currently no support for MJPEG that I'm aware of, nor are
there any plans in that direction. At least not from my end.

Kind regards,
mosu


From slhomme at matroska.org  Mon Nov  7 10:58:44 2011
From: slhomme at matroska.org (Steve Lhomme)
Date: Mon, 7 Nov 2011 10:58:44 +0100
Subject: [Matroska-devel] V_MJPEG supported?
In-Reply-To: <CANPayMRq1skzra+At3HJ55D4ofqCWr_6Z-+PYtyJKD2neDfcUg@mail.gmail.com>
References: <5464BB616C0E4C4A989956232093BF74@hypark>
	<CANPayMRq1skzra+At3HJ55D4ofqCWr_6Z-+PYtyJKD2neDfcUg@mail.gmail.com>
Message-ID: <CAOXsMFKSyVWfAnV_xDqtESiKSB=gMvni0ArAwotawVAjM2dVvA@mail.gmail.com>

It should work with the AVI compatibility codec ID: V_MS/VFW/FOURCC

On Fri, Nov 4, 2011 at 10:27 AM, Moritz Bunkus <moritz at bunkus.org> wrote:
> Hey,
>
> 2011/11/4 ??? <park00245 at gmail.com>:
>
>> I'd like to use, MJPEG video codec codec MKV files.
>
> There's currently no support for MJPEG that I'm aware of, nor are
> there any plans in that direction. At least not from my end.
>
> Kind 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 smeulf at gmx.fr  Tue Nov 15 02:17:36 2011
From: smeulf at gmx.fr (smeulf at gmx.fr)
Date: Tue, 15 Nov 2011 02:17:36 +0100
Subject: [Matroska-devel] Question about tags
Message-ID: <6E366B79A95C442099287FC9D3928778@Smeulfi>

Hi,

I need to tag videos with genres, but I can?t find the right syntax.

The tag specifications page says it folow the ?infamous TCON tag in ID3? format, but this format don?t seems to provide genres as ?Drama? or Science-Fiction?.

Also, I need both genres in my tags.

So my question is : ?Is the tag should be like this :?

<Simple>
    <Name>GENRE</Name>
    <String>Drama</String>
</Simple>
<Simple>
<Name>GENRE</Name>
<String>Science-Fiction</String>
</Simple>

Or should it be an another format ? If so, can someone add some examples maybe in the ?Simpson? example page, and point me to the right way (ie the ID3-Movie genre definition) ?

Thanks in advance.

Smeulf.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.matroska.org/pipermail/matroska-devel/attachments/20111115/35daf391/attachment.html>

From matthewjheaney at gmail.com  Thu Nov 17 19:37:24 2011
From: matthewjheaney at gmail.com (Matthew Heaney)
Date: Thu, 17 Nov 2011 13:37:24 -0500
Subject: [Matroska-devel] Representation of payload for SeekHead entries
Message-ID: <CAAjfm8aYepUjMR3eZM1yB3p-Y90+eaFCjRxo4i3Cw+nd24Zvdg@mail.gmail.com>

I had a question about the representation of the payload for SeekHead
entry items.

The payload for a SeekHead entry has an ID and a position, each
wrapped in their own little container.  It looks something like this:

<ID = SeekID> = type uint = 0x13AB = [53[AB]
<id payload size> = type uint
<id payload> = type ???
<ID = SeekPos> = type uint = 0x13AC = [53][AC]
<pos payload size> = type uint
<pos payload> = ???

I'm not clear about how the <id payload> and <pos payload> items are
represented in the stream.

The spec says that the SeekID has type "binary".  Does this mean that
this is a normal, 2's complement integer, in network byte order?  Or
is this an unsigned integer having a "matroska representation"?  Are
there any constraints on the range of values?

The spec says that the SeekPos has type "unsigned int".  Does this
also mean that this is a normal, 2's complement integer, in network
byte order?  Does it have the same representation as the SeekID
payload value, or some different representation?  How is "uint"
different from "binary"?

I ask because each payload value is listed as having a different type
("binary" vs. "uint").  I'm not sure whether this means that they each
have a different representation, or that they have the same
representation in the stream, but a different range of possible
values.

Thanks,
Matt


From moritz at bunkus.org  Fri Nov 18 09:37:13 2011
From: moritz at bunkus.org (Moritz Bunkus)
Date: Fri, 18 Nov 2011 09:37:13 +0100
Subject: [Matroska-devel] Representation of payload for SeekHead entries
In-Reply-To: <CAAjfm8aYepUjMR3eZM1yB3p-Y90+eaFCjRxo4i3Cw+nd24Zvdg@mail.gmail.com>
References: <CAAjfm8aYepUjMR3eZM1yB3p-Y90+eaFCjRxo4i3Cw+nd24Zvdg@mail.gmail.com>
Message-ID: <CANPayMStLU+NLpVSh=KKxyfSw=KRyj+Ny3Wes8eyoX+Yv4Tkqg@mail.gmail.com>

Hey,

On Thu, Nov 17, 2011 at 19:37, Matthew Heaney <matthewjheaney at gmail.com> wrote:

> I had a question about the representation of the payload for SeekHead
> entry items.
>
> The payload for a SeekHead entry has an ID and a position, each
> wrapped in their own little container. ?It looks something like this:

Each seekhead is a container (an EBML master), but the SeekID and the
position are simple elements, not themselves containers/masters.
Though I guess you're using the term "container" in a different way
than I would in this context: for me a container in the Matroska/EBML
context is an element that contains more EBML/Matroska elements = an
EBML master.

Each EBML element consists of the holy trinity: ID, content size,
content. ID and content can be read as EBML variable-length unsigned
integers, that is true. How the content is read and interpreted
depends on the ID. That much you probably know.

For the SeekID element the type is a binary, hence you do a dumb
"read(buffer, element_size)" call on the file and slurp in a number of
bytes. If the buffer contains e.g. the bytes "0x1F 43 B6 75" then you
know that this seek head refers to a cluster element.

> The spec says that the SeekPos has type "unsigned int". ?Does this
> also mean that this is a normal, 2's complement integer, in network
> byte order?

The specs say ( http://www.matroska.org/technical/specs/index.html ):

> Data

>> Integers are stored in their standard big-endian form (no UTF-like encoding), only the size may differ from their usual form (24 or 40 bits for example).

>> The Signed Integer is just the big-endian representation trimmed from some 0x00 and 0xFF where they are not meaningful (sign). For example -2 can be coded as 0xFFFFFFFFFFFFFE or 0xFFFE or 0xFE and 5 can be coded 0x000000000005 or 0x0005 or 0x05.

It translates into "in big endian notation, omit the leading 0x00
bytes, and store the rest". Upon reading read it as a big endian
integer, e.g.

val = 0
"size" times:
  val = (val << 8) | read_byte

Note that the value you get by reading this is relative to the start
of the current segment.

>?Does it have the same representation as the SeekID
> payload value, or some different representation? ?How is "uint"
> different from "binary"?

The reason a binary is used is because the storage of an EBML ID is
different than the storate of an unsigned integer (UTF-8 like variable
length encoding vs known length, omit leading 0s). However, in
practice an the storage of both look the same.

Also you cannot read a uint like "read(&value, size)".

Kind regards,
mosu


From matthewjheaney at gmail.com  Fri Nov 18 19:54:23 2011
From: matthewjheaney at gmail.com (Matthew Heaney)
Date: Fri, 18 Nov 2011 13:54:23 -0500
Subject: [Matroska-devel] Representation of payload for SeekHead entries
In-Reply-To: <CANPayMStLU+NLpVSh=KKxyfSw=KRyj+Ny3Wes8eyoX+Yv4Tkqg@mail.gmail.com>
References: <CAAjfm8aYepUjMR3eZM1yB3p-Y90+eaFCjRxo4i3Cw+nd24Zvdg@mail.gmail.com>
	<CANPayMStLU+NLpVSh=KKxyfSw=KRyj+Ny3Wes8eyoX+Yv4Tkqg@mail.gmail.com>
Message-ID: <CAAjfm8Yq1n8kPGacfEOFG4ZZPGQUxvuqKvt_+EeM6YfZw8uk0w@mail.gmail.com>

On Fri, Nov 18, 2011 at 3:37 AM, Moritz Bunkus <moritz at bunkus.org> wrote:
>
> For the SeekID element the type is a binary, hence you do a dumb
> "read(buffer, element_size)" call on the file and slurp in a number of
> bytes. If the buffer contains e.g. the bytes "0x1F 43 B6 75" then you
> know that this seek head refers to a cluster element.

But that's exactly what I'm asking about.  You're saying that the
payload ("content") has the "Matroska unsigned integer
representation".  This is not the same as simply "slurping bytes from
the stream".

To follow through using your example, the question is specifically
whether the content for the SeekID element is represented as "0x0F 43
B6 75" vs. "0x1F 43 B6 75" (both assuming the size field of the
element has the value 4).


> The reason a binary is used is because the storage of an EBML ID is
> different than the storage of an unsigned integer (UTF-8 like variable
> length encoding vs known length, omit leading 0s). However, in
> practice an the storage of both look the same.

I think what you're saying here is that, for the SeekID element, its
content must have "matroska unsigned int" representation, the same as
for the ID field and the size field.  The size of the integer value
implied by the first byte of the content (because the value in the
stream has "Matroska representation") must match the size specified in
the size field of the SeekID element.  Can you confirm whether this is
the case?

Can the content of the SeekID element have any of these values?

<SeekID>
<size=5>
0x08 0F 43 B6 75

-or-

<SeekID>
<size=6>
0x04 00 0F 43 B6 75

-or-

<SeekID>
<size=7>
0x02 00 00 0F 43 B6 75

-or-

<SeekID>
<size=8>
0x01 00 00 00 0F 43 B6 75

I also think that you're saying that for the SeekPos element, its
content must have plain "unsigned int" representation, in network byte
order.  Can you confirm whether this is the case?

Thanks,
Matt


From moritz at bunkus.org  Fri Nov 18 20:21:38 2011
From: moritz at bunkus.org (Moritz Bunkus)
Date: Fri, 18 Nov 2011 20:21:38 +0100
Subject: [Matroska-devel] Representation of payload for SeekHead entries
In-Reply-To: <CAAjfm8Yq1n8kPGacfEOFG4ZZPGQUxvuqKvt_+EeM6YfZw8uk0w@mail.gmail.com>
References: <CAAjfm8aYepUjMR3eZM1yB3p-Y90+eaFCjRxo4i3Cw+nd24Zvdg@mail.gmail.com>
	<CANPayMStLU+NLpVSh=KKxyfSw=KRyj+Ny3Wes8eyoX+Yv4Tkqg@mail.gmail.com>
	<CAAjfm8Yq1n8kPGacfEOFG4ZZPGQUxvuqKvt_+EeM6YfZw8uk0w@mail.gmail.com>
Message-ID: <CANPayMR_qKN4BdB++QOfXu12hQFxtZOS06QvMenJy4Gf5GHZBw@mail.gmail.com>

Hey,

> You're saying that the
> payload ("content") has the "Matroska unsigned integer
> representation". ?This is not the same as simply "slurping bytes from
> the stream".

I'm saying that ONLY about the "position" element, not about the "seek
ID" element. Please read carefully what I'm referring to in each case.

> To follow through using your example, the question is specifically
> whether the content for the SeekID element is represented as "0x0F 43
> B6 75" vs. "0x1F 43 B6 75" (both assuming the size field of the
> element has the value 4).

seek ID content in the file = the bytes you see in the Matroska spec.
Meaning four bytes, "0x1f 34 b6 75", in that order.

Same is true for the "cluster" element's ID itself (the "cluster"
element, not the "seek ID" element). After having read an element ID
into memory you compare it with the bytes "0x1f 34 b5 75" in order to
know whether or not you've just read a cluster.

> I think what you're saying here is that, for the SeekID element, its
> content must have "matroska unsigned int" representation, the same as
> for the ID field and the size field.

No. The leading 1 is actually part of the ID and not only a marker for
the length of the ID. If this were "Matroska unsigned int
representation" then you would have to look for the byte sequence
"0x0f 34 b6 75" in the specs, but you won't find an element there.
Also note that the specs have a field in the EBML header called "max
ID length". Quote from the specs: "The maximum length of the IDs
you'll find in this file (4 or less in Matroska)." Therefore any of
the other representations you've listed are not valid.

>?The size of the integer value
> implied by the first byte of the content (because the value in the
> stream has "Matroska representation") must match the size specified in
> the size field of the SeekID element. ?Can you confirm whether this is
> the case?

For the "seek ID" element this is true. But why do you insist on
reading or treating the "seek ID"'s content as an integer?

> I also think that you're saying that for the SeekPos element, its
> content must have plain "unsigned int" representation, in network byte
> order. ?Can you confirm whether this is the case?

The "Seek position" element is what the specs call "a basic EBML type
'unsigned integer'": (quote) "Unsigned Integer - Big-endian, any size
from 1 to 8 octets". The very same as e.g. the "cluster timecode"
element, the "track number" element, the "pixel width" element etc
etc.

Kind regards,
mosu


From matthewjheaney at gmail.com  Fri Nov 18 21:25:58 2011
From: matthewjheaney at gmail.com (Matthew Heaney)
Date: Fri, 18 Nov 2011 15:25:58 -0500
Subject: [Matroska-devel] Representation of payload for SeekHead entries
In-Reply-To: <CANPayMR_qKN4BdB++QOfXu12hQFxtZOS06QvMenJy4Gf5GHZBw@mail.gmail.com>
References: <CAAjfm8aYepUjMR3eZM1yB3p-Y90+eaFCjRxo4i3Cw+nd24Zvdg@mail.gmail.com>
	<CANPayMStLU+NLpVSh=KKxyfSw=KRyj+Ny3Wes8eyoX+Yv4Tkqg@mail.gmail.com>
	<CAAjfm8Yq1n8kPGacfEOFG4ZZPGQUxvuqKvt_+EeM6YfZw8uk0w@mail.gmail.com>
	<CANPayMR_qKN4BdB++QOfXu12hQFxtZOS06QvMenJy4Gf5GHZBw@mail.gmail.com>
Message-ID: <CAAjfm8adrV6d8yCEBAOWdLcWaUcnePvRWhXUz5YDiak9vLwqrQ@mail.gmail.com>

On Fri, Nov 18, 2011 at 2:21 PM, Moritz Bunkus <moritz at bunkus.org> wrote:
>
> I'm saying that ONLY about the "position" element, not about the "seek
> ID" element. Please read carefully what I'm referring to in each case.

Well now I'm doubly confused.  I think you're saying that:

(1) The content of the SeekID is represented as a "Matroska unsigned
int" (but with a fixed length).

(2) The content of the SeekPos element is represented as a "basic EBML
type unsigned int".


>> To follow through using your example, the question is specifically
>> whether the content for the SeekID element is represented as "0x0F 43
>> B6 75" vs. "0x1F 43 B6 75" (both assuming the size field of the
>> element has the value 4).
>
> seek ID content in the file = the bytes you see in the Matroska spec.
> Meaning four bytes, "0x1f 34 b6 75", in that order.

I think you're saying that yes, the content of the SeekID element is
represented in the stream as a "Matroska unsigned int".

Can the value for a Cluster ID to be represented in the stream using
more than 4 bytes?  Forget about what the Matroska spec says.  Is it
valid, for example, for a Cluster ID to be represented as 0x01 00 00
00 0F 34 B6 75", if the EBML header says that element IDs are 8 bytes
or less?


> Same is true for the "cluster" element's ID itself (the "cluster"
> element, not the "seek ID" element). After having read an element ID
> into memory you compare it with the bytes "0x1f 34 b5 75" in order to
> know whether or not you've just read a cluster.

But IDs are represented in the stream using "Matroska unsigned int"
representation.  Is it valid to use more bytes in the stream than the
values specified in the Matroska spec?

For example, are any of these equally valid ways of representing a
Void element ID?

0xEC
0x40 6C
0x20 00 6C
0x10 00 00 6C
0x08 00 00 00 6C
0x04 00 00 00 00 6C
0x02 00 00 00 00 00 6C
0x01 00 00 00 00 00 00 6C

?

> No. The leading 1 is actually part of the ID and not only a marker for
> the length of the ID.

But that's my very question.

You are not only saying an ID value is an integer with "Matroska
unsigned int" representation.  You're making a stronger claim: that
this is a Matroska unsigned int" and it has a representation whose
size matches the EBML IDs listed in the Matroska spec.

Let's make another example.  Suppose we have a SeekID whose content is
a Void element.  (Weird but accept my premise for now.)  Which of
these element values are valid?  All of them, or only the first?

<SeekID>
<size=1>
0xEC

<SeekID>
<size=2>
0x40 6C

<SeekID>
<size=3>
0x20 00 6C

<SeekID>
<size=4>
0x10 00 00 6C

?


> If this were "Matroska unsigned int
> representation" then you would have to look for the byte sequence
> "0x0f 34 b6 75" in the specs,

Yes, that's what I do already.  The Google parser for WebM
canonicalizes all Matroska integer values, irrespective of whether
they happen to be IDs or size fields (and, apparently, the content of
a SeekID element).

Certainly I write IDs using the values listed in the Matroska spec.
("Be conservative about what you write, but liberal about what you
read.")  The question is how liberal a reader needs to be.  As long as
the EBML header says that the max length of an EBML ID is 8 bytes or
less, then I'll parse any ID as if it could be represented using 8
bytes.

You seem to be saying that a ClusterID represented any way other than
as 0x1F 34 B6 75 is not valid.  But that's not my reading of the spec.
 (Hence this post.)


> but you won't find an element there.

You will if you canonicalize the value you read from the stream.


> Also note that the specs have a field in the EBML header called "max
> ID length". Quote from the specs: "The maximum length of the IDs
> you'll find in this file (4 or less in Matroska)." Therefore any of
> the other representations you've listed are not valid.

But does that apply to the values in the spec itself, or to any file?

If the file says in the EBML header that the max length of the IDs is
"8 or less", then does make the values in the file valid, if they
happen to be represented using a longer stream of bytes than the
values listed in the spec?

Consider the example for Void element above.  Let's also assume that
the max length of the IDs is 4 or less.  Then are all of the first 4
representations valid?


> For the "seek ID" element this is true. But why do you insist on
> reading or treating the "seek ID"'s content as an integer?

Because it's an integer -- the same as all IDs!

But I'm confused about what the spec says about the representation of
the SeekID content.

The reason I'm confused is because the SeekID element has redundant
information.  The size field of the SeekID element must match the size
implied by the value of the content field.  There are no conditions
under which they could be different, n'est-ce pas?

But again you are saying something more, in the sense of an additional
constraint: not only does the SeekID content have a Matroska unsigned
int representation, but also that its size matches the values listed
in the Matroska spec.  (My parser relaxes this constraint, but that is
a separate matter.)


> The "Seek position" element is what the specs call "a basic EBML type
> 'unsigned integer'": (quote) "Unsigned Integer - Big-endian, any size
> from 1 to 8 octets". The very same as e.g. the "cluster timecode"
> element, the "track number" element, the "pixel width" element etc
> etc.

OK, so the content for a SeekPos element does not have "Matroska
unsigned int" representation.  I figured as such.  My question is
mostly about the content of the SeekID element.


From moritz at bunkus.org  Fri Nov 18 21:39:02 2011
From: moritz at bunkus.org (Moritz Bunkus)
Date: Fri, 18 Nov 2011 21:39:02 +0100
Subject: [Matroska-devel] Representation of payload for SeekHead entries
In-Reply-To: <CAAjfm8adrV6d8yCEBAOWdLcWaUcnePvRWhXUz5YDiak9vLwqrQ@mail.gmail.com>
References: <CAAjfm8aYepUjMR3eZM1yB3p-Y90+eaFCjRxo4i3Cw+nd24Zvdg@mail.gmail.com>
	<CANPayMStLU+NLpVSh=KKxyfSw=KRyj+Ny3Wes8eyoX+Yv4Tkqg@mail.gmail.com>
	<CAAjfm8Yq1n8kPGacfEOFG4ZZPGQUxvuqKvt_+EeM6YfZw8uk0w@mail.gmail.com>
	<CANPayMR_qKN4BdB++QOfXu12hQFxtZOS06QvMenJy4Gf5GHZBw@mail.gmail.com>
	<CAAjfm8adrV6d8yCEBAOWdLcWaUcnePvRWhXUz5YDiak9vLwqrQ@mail.gmail.com>
Message-ID: <CANPayMRfdn+HHXeoGYy3JaKZ=rnEGrQUNcUCSm0i=EGz=5T-cw@mail.gmail.com>

Hey,

Well, I'm giving up because I honestly don't have the answer. Maybe
Steve Lhomme does.

The only thing that still comes to mind is that reading an element ID
and an element size is not the same, nor is the result the same from
the application's perspective (the "application" being the layer above
EBML, in this case Matroska). If an EBML parser reads a single byte
"0x81" as an element ID then it has to pass "0x81" to the layer above.
If it reads that same single byte "0x81" as the element's size then it
only passes "0x01" to the layer above.

Therefore there can only be two cases:

a) The byte sequence "0x40 01" represents a different EBML ID than the
byte sequence "0x81" does or
b) An EBML parser has to normalize element IDs to their shortest
possible representation before passing it upstream in which case "0x40
01" and "0x81" would be the same ID.

I guess b) is the intended case, but like I said I don't actually have
a definitive answer.

If the WebM parser already normalizes upon reading then I'd say just
leave it like it is. Accept as much weird cases as possible but only
write the byte sequences explicitly listed in the specs.

Oh and BTW:

> Can the value for a Cluster ID to be represented in the stream using
> more than 4 bytes? ?Forget about what the Matroska spec says. ?Is it
> valid, for example, for a Cluster ID to be represented as 0x01 00 00
> 00 0F 34 B6 75", if the EBML header says that element IDs are 8 bytes
> or less?

Valid to what? Either I should forget about the specs in which case I
don't have any basis to decide whether or not something is valid or I
can say it is valid (or not) according to the specs ;) Just
nitpicking.

Kind regards,
mosu


From agriffin at reflectsystems.com  Fri Nov 18 21:31:44 2011
From: agriffin at reflectsystems.com (Aaron Griffin)
Date: Fri, 18 Nov 2011 14:31:44 -0600
Subject: [Matroska-devel] Matroska Splitter
Message-ID: <00b201cca631$16f5fd50$44e1f7f0$@reflectsystems.com>

Hello,

 

My name is Aaron Griffin.  We are using your product along with the Core AVC Codec.  We are getting a Splitter Crash that is taking place.  I wanted to speak with someone concerning this.  In addition, I would like to verify the version of the Haali Splitter that I have.  How would I proceed with verifying that information?  I have just received version 1.11.288.0.  I would like to verify if this is different from the version I currently have installed.  Below is some information associated with the crash.

 

Alert Description: A Critical Error has occurred.

Alert Condition:  

 Alert subject: Advanced Event

Log: application

Type: error

Event ID: 32972

Alert Group:      RAC Managed Svc

Generated:        11/17/2011 10:21 PM

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

Computer:  RAC-110907-8328

Date/Time: 2011-11-17 22:20:48

 

Event Log: application

Type:      Error

Source:    RP_PlayerSvc2

Category:  

Event:     32972

 

Message:

 

Critical Error Information:

Application:        c:\Program Files\Reflect Systems\ReflectPlayer\RP_PlayerSvc2.exe

  File Size:        1777152

  File Version:     5.6.50.0

  Product Version:  5.6.50.0

Exception code:     0xC0000005

Exception desc:     Attempt to read from an invalid address (0x00000111).

Address:            0x08047F3B

Last Win32 Err:     0x00000006

Description:        The handle is invalid.

 

Time:               11/17/2011 22:20:48.529 

GMTime:             11/18/2011 03:20:48.529 

Run time:           3 days 8 hours 57 minutes 40 seconds.

Process Handles:    15882

System Handles:     26107

System Threads:     581

System Processes:   49

Physical Memory:    521518

Memory Available:   377103

Display Devices:

  NVIDIA GeForce 210 ( <file:///\\.\DISPLAY1> \\.\DISPLAY1)

  NVIDIA GeForce 210 ( <file:///\\.\DISPLAY2> \\.\DISPLAY2)

 

 

Stack Trace:

(0x08047F3B) [0001:00016F3B] c:\Program Files\Haali\MatroskaSplitter\splitter.ax

(0x08081F27) [0001:00050F27] c:\Program Files\Haali\MatroskaSplitter\splitter.ax

(0x08083141) [0001:00052141] c:\Program Files\Haali\MatroskaSplitter\splitter.ax

(0x08083BBB) [0001:00052BBB] c:\Program Files\Haali\MatroskaSplitter\splitter.ax

(0x0806D997) [0001:0003C997] c:\Program Files\Haali\MatroskaSplitter\splitter.ax

(0x77C237F5) [0001:000627F5] C:\Windows\SYSTEM32\ntdll.dll

(0x77C237C8) [0001:000627C8] C:\Windows\SYSTEM32\ntdll.dll

 

If you would please follow up with me at your convenience, I would greatly appreciate it.  I look forward to hearing from you.  Have a great day!

 

Thank you,

 

 

Aaron Griffin | Support Engineer | Reflect Systems, Inc.

9400 N. Central Expressway, Suite 550 | Dallas, TX 75231

Office:  214-413-3219  ?  Cell:  469-487-8550

 <mailto:agriffin at reflectsystems.com> agriffin at reflectsystems.com |  <http://www.reflectsystems.com/> www.reflectsystems.com

Description: Description: cid:_2_078AFCC4078AFA7000485DC986257781

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.matroska.org/pipermail/matroska-devel/attachments/20111118/8aee6312/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 16253 bytes
Desc: not available
URL: <http://lists.matroska.org/pipermail/matroska-devel/attachments/20111118/8aee6312/attachment.png>

From matthewjheaney at gmail.com  Fri Nov 18 21:58:44 2011
From: matthewjheaney at gmail.com (Matthew Heaney)
Date: Fri, 18 Nov 2011 15:58:44 -0500
Subject: [Matroska-devel] Representation of payload for SeekHead entries
In-Reply-To: <CANPayMRfdn+HHXeoGYy3JaKZ=rnEGrQUNcUCSm0i=EGz=5T-cw@mail.gmail.com>
References: <CAAjfm8aYepUjMR3eZM1yB3p-Y90+eaFCjRxo4i3Cw+nd24Zvdg@mail.gmail.com>
	<CANPayMStLU+NLpVSh=KKxyfSw=KRyj+Ny3Wes8eyoX+Yv4Tkqg@mail.gmail.com>
	<CAAjfm8Yq1n8kPGacfEOFG4ZZPGQUxvuqKvt_+EeM6YfZw8uk0w@mail.gmail.com>
	<CANPayMR_qKN4BdB++QOfXu12hQFxtZOS06QvMenJy4Gf5GHZBw@mail.gmail.com>
	<CAAjfm8adrV6d8yCEBAOWdLcWaUcnePvRWhXUz5YDiak9vLwqrQ@mail.gmail.com>
	<CANPayMRfdn+HHXeoGYy3JaKZ=rnEGrQUNcUCSm0i=EGz=5T-cw@mail.gmail.com>
Message-ID: <CAAjfm8YuJOTga-KLV3bic5ibMbc6zJFuxJaBmXxzJJzF6OVYQA@mail.gmail.com>

On Fri, Nov 18, 2011 at 3:39 PM, Moritz Bunkus <moritz at bunkus.org> wrote:
>
> The only thing that still comes to mind is that reading an element ID
> and an element size is not the same, nor is the result the same from
> the application's perspective (the "application" being the layer above
> EBML, in this case Matroska). If an EBML parser reads a single byte
> "0x81" as an element ID then it has to pass "0x81" to the layer above.
> If it reads that same single byte "0x81" as the element's size then it
> only passes "0x01" to the layer above.

Well in my case, it passes 0x01 to the layer above.


> a) The byte sequence "0x40 01" represents a different EBML ID than the
> byte sequence "0x81" does or

> b) An EBML parser has to normalize element IDs to their shortest
> possible representation before passing it upstream in which case "0x40
> 01" and "0x81" would be the same ID.

This (b) is my assumption.  (The WebM parser passes 0x01 upstream.)


> If the WebM parser already normalizes upon reading then I'd say just
> leave it like it is. Accept as much weird cases as possible but only
> write the byte sequences explicitly listed in the specs.

Agreed.


>> Can the value for a Cluster ID to be represented in the stream using
>> more than 4 bytes? ?Forget about what the Matroska spec says. ?Is it
>> valid, for example, for a Cluster ID to be represented as 0x01 00 00
>> 00 0F 34 B6 75", if the EBML header says that element IDs are 8 bytes
>> or less?
>
> Valid to what? Either I should forget about the specs in which case I
> don't have any basis to decide whether or not something is valid or I
> can say it is valid (or not) according to the specs ;) Just
> nitpicking.

There is no such thing as "according to the specs".  Specs don't exist
in some Platonic realm: they are written and interpreted by humans,
and so there can be ambiguity in their meaning and interpretation.

My argument (perhaps incorrect) is that the values listed in the spec
itself are non-normalized, and that in an actual file, an ID having
any representation consistent with the max length value in the EBML
header is valid.  IMHO it would be dangerous for a parser to make any
other assumption, but that's just me.  8^)

Thanks for the info.

Regards,
Matt

<mailto:matthewjheaney at google.com>


From slhomme at matroska.org  Sat Nov 19 14:17:15 2011
From: slhomme at matroska.org (Steve Lhomme)
Date: Sat, 19 Nov 2011 14:17:15 +0100
Subject: [Matroska-devel] Representation of payload for SeekHead entries
In-Reply-To: <CAAjfm8YuJOTga-KLV3bic5ibMbc6zJFuxJaBmXxzJJzF6OVYQA@mail.gmail.com>
References: <CAAjfm8aYepUjMR3eZM1yB3p-Y90+eaFCjRxo4i3Cw+nd24Zvdg@mail.gmail.com>
	<CANPayMStLU+NLpVSh=KKxyfSw=KRyj+Ny3Wes8eyoX+Yv4Tkqg@mail.gmail.com>
	<CAAjfm8Yq1n8kPGacfEOFG4ZZPGQUxvuqKvt_+EeM6YfZw8uk0w@mail.gmail.com>
	<CANPayMR_qKN4BdB++QOfXu12hQFxtZOS06QvMenJy4Gf5GHZBw@mail.gmail.com>
	<CAAjfm8adrV6d8yCEBAOWdLcWaUcnePvRWhXUz5YDiak9vLwqrQ@mail.gmail.com>
	<CANPayMRfdn+HHXeoGYy3JaKZ=rnEGrQUNcUCSm0i=EGz=5T-cw@mail.gmail.com>
	<CAAjfm8YuJOTga-KLV3bic5ibMbc6zJFuxJaBmXxzJJzF6OVYQA@mail.gmail.com>
Message-ID: <CAOXsMFJfys=2LdXwj5zrGFcq3g36xLh1_-KN67kYbo9ZoY9Piw@mail.gmail.com>

OK, here I am. I haven't read the whole thread but I think I
understand where the confusion is about the Seek ID.

It's in binary, so the content format has nothing to do with how you
interpret an integer, even though by some stretching you know it
represents an integer.

But in Matroska and EBML in general, Element IDs are not exactly
integers. They are 1, 2, 3 or 4 bytes. Unlike integers you can't use a
"4 bytes" to represent a "2 bytes" ID. I think most parsers would not
be able to cope with it.

So in the end the ID is stored in the exact same binary form it
appears in the file/stream. That makes it a lot easier to compare.

On Fri, Nov 18, 2011 at 9:58 PM, Matthew Heaney
<matthewjheaney at gmail.com> wrote:
> On Fri, Nov 18, 2011 at 3:39 PM, Moritz Bunkus <moritz at bunkus.org> wrote:
>>
>> The only thing that still comes to mind is that reading an element ID
>> and an element size is not the same, nor is the result the same from
>> the application's perspective (the "application" being the layer above
>> EBML, in this case Matroska). If an EBML parser reads a single byte
>> "0x81" as an element ID then it has to pass "0x81" to the layer above.
>> If it reads that same single byte "0x81" as the element's size then it
>> only passes "0x01" to the layer above.
>
> Well in my case, it passes 0x01 to the layer above.
>
>
>> a) The byte sequence "0x40 01" represents a different EBML ID than the
>> byte sequence "0x81" does or
>
>> b) An EBML parser has to normalize element IDs to their shortest
>> possible representation before passing it upstream in which case "0x40
>> 01" and "0x81" would be the same ID.
>
> This (b) is my assumption. ?(The WebM parser passes 0x01 upstream.)
>
>
>> If the WebM parser already normalizes upon reading then I'd say just
>> leave it like it is. Accept as much weird cases as possible but only
>> write the byte sequences explicitly listed in the specs.
>
> Agreed.
>
>
>>> Can the value for a Cluster ID to be represented in the stream using
>>> more than 4 bytes? ?Forget about what the Matroska spec says. ?Is it
>>> valid, for example, for a Cluster ID to be represented as 0x01 00 00
>>> 00 0F 34 B6 75", if the EBML header says that element IDs are 8 bytes
>>> or less?
>>
>> Valid to what? Either I should forget about the specs in which case I
>> don't have any basis to decide whether or not something is valid or I
>> can say it is valid (or not) according to the specs ;) Just
>> nitpicking.
>
> There is no such thing as "according to the specs". ?Specs don't exist
> in some Platonic realm: they are written and interpreted by humans,
> and so there can be ambiguity in their meaning and interpretation.
>
> My argument (perhaps incorrect) is that the values listed in the spec
> itself are non-normalized, and that in an actual file, an ID having
> any representation consistent with the max length value in the EBML
> header is valid. ?IMHO it would be dangerous for a parser to make any
> other assumption, but that's just me. ?8^)
>
> Thanks for the info.
>
> Regards,
> Matt
>
> <mailto:matthewjheaney at google.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 slhomme at matroska.org  Sat Nov 19 14:23:36 2011
From: slhomme at matroska.org (Steve Lhomme)
Date: Sat, 19 Nov 2011 14:23:36 +0100
Subject: [Matroska-devel] Representation of payload for SeekHead entries
In-Reply-To: <CAOXsMFJfys=2LdXwj5zrGFcq3g36xLh1_-KN67kYbo9ZoY9Piw@mail.gmail.com>
References: <CAAjfm8aYepUjMR3eZM1yB3p-Y90+eaFCjRxo4i3Cw+nd24Zvdg@mail.gmail.com>
	<CANPayMStLU+NLpVSh=KKxyfSw=KRyj+Ny3Wes8eyoX+Yv4Tkqg@mail.gmail.com>
	<CAAjfm8Yq1n8kPGacfEOFG4ZZPGQUxvuqKvt_+EeM6YfZw8uk0w@mail.gmail.com>
	<CANPayMR_qKN4BdB++QOfXu12hQFxtZOS06QvMenJy4Gf5GHZBw@mail.gmail.com>
	<CAAjfm8adrV6d8yCEBAOWdLcWaUcnePvRWhXUz5YDiak9vLwqrQ@mail.gmail.com>
	<CANPayMRfdn+HHXeoGYy3JaKZ=rnEGrQUNcUCSm0i=EGz=5T-cw@mail.gmail.com>
	<CAAjfm8YuJOTga-KLV3bic5ibMbc6zJFuxJaBmXxzJJzF6OVYQA@mail.gmail.com>
	<CAOXsMFJfys=2LdXwj5zrGFcq3g36xLh1_-KN67kYbo9ZoY9Piw@mail.gmail.com>
Message-ID: <CAOXsMF+09tNRPLPzzCMhTGz3C7Txzwmae2GLp=oPo11uynQoAQ@mail.gmail.com>

PS: Also as you can see in the specs, IDs are only supported up to 4
bytes and not 8.

IDs are not to be seen as integer but as a whole "marker". The UTF-8
like encoding is just there to tell the size of the ID. There is no
reason to use more bytes for a given ID. Even though some smart
parsers may be able to handle it (libebml can do it but up to 4 bytes
only).

Now to confuse you even more, all IDs have been chosen so that their
"integer value" (like you use in your code) do not collide with
another element of a different size.

On Sat, Nov 19, 2011 at 2:17 PM, Steve Lhomme <slhomme at matroska.org> wrote:
> OK, here I am. I haven't read the whole thread but I think I
> understand where the confusion is about the Seek ID.
>
> It's in binary, so the content format has nothing to do with how you
> interpret an integer, even though by some stretching you know it
> represents an integer.
>
> But in Matroska and EBML in general, Element IDs are not exactly
> integers. They are 1, 2, 3 or 4 bytes. Unlike integers you can't use a
> "4 bytes" to represent a "2 bytes" ID. I think most parsers would not
> be able to cope with it.
>
> So in the end the ID is stored in the exact same binary form it
> appears in the file/stream. That makes it a lot easier to compare.
>
> On Fri, Nov 18, 2011 at 9:58 PM, Matthew Heaney
> <matthewjheaney at gmail.com> wrote:
>> On Fri, Nov 18, 2011 at 3:39 PM, Moritz Bunkus <moritz at bunkus.org> wrote:
>>>
>>> The only thing that still comes to mind is that reading an element ID
>>> and an element size is not the same, nor is the result the same from
>>> the application's perspective (the "application" being the layer above
>>> EBML, in this case Matroska). If an EBML parser reads a single byte
>>> "0x81" as an element ID then it has to pass "0x81" to the layer above.
>>> If it reads that same single byte "0x81" as the element's size then it
>>> only passes "0x01" to the layer above.
>>
>> Well in my case, it passes 0x01 to the layer above.
>>
>>
>>> a) The byte sequence "0x40 01" represents a different EBML ID than the
>>> byte sequence "0x81" does or
>>
>>> b) An EBML parser has to normalize element IDs to their shortest
>>> possible representation before passing it upstream in which case "0x40
>>> 01" and "0x81" would be the same ID.
>>
>> This (b) is my assumption. ?(The WebM parser passes 0x01 upstream.)
>>
>>
>>> If the WebM parser already normalizes upon reading then I'd say just
>>> leave it like it is. Accept as much weird cases as possible but only
>>> write the byte sequences explicitly listed in the specs.
>>
>> Agreed.
>>
>>
>>>> Can the value for a Cluster ID to be represented in the stream using
>>>> more than 4 bytes? ?Forget about what the Matroska spec says. ?Is it
>>>> valid, for example, for a Cluster ID to be represented as 0x01 00 00
>>>> 00 0F 34 B6 75", if the EBML header says that element IDs are 8 bytes
>>>> or less?
>>>
>>> Valid to what? Either I should forget about the specs in which case I
>>> don't have any basis to decide whether or not something is valid or I
>>> can say it is valid (or not) according to the specs ;) Just
>>> nitpicking.
>>
>> There is no such thing as "according to the specs". ?Specs don't exist
>> in some Platonic realm: they are written and interpreted by humans,
>> and so there can be ambiguity in their meaning and interpretation.
>>
>> My argument (perhaps incorrect) is that the values listed in the spec
>> itself are non-normalized, and that in an actual file, an ID having
>> any representation consistent with the max length value in the EBML
>> header is valid. ?IMHO it would be dangerous for a parser to make any
>> other assumption, but that's just me. ?8^)
>>
>> Thanks for the info.
>>
>> Regards,
>> Matt
>>
>> <mailto:matthewjheaney at google.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
>



-- 
Steve Lhomme
Matroska association Chairman


From slhomme at matroska.org  Sat Nov 19 14:27:18 2011
From: slhomme at matroska.org (Steve Lhomme)
Date: Sat, 19 Nov 2011 14:27:18 +0100
Subject: [Matroska-devel] Matroska Splitter
In-Reply-To: <00b201cca631$16f5fd50$44e1f7f0$@reflectsystems.com>
References: <00b201cca631$16f5fd50$44e1f7f0$@reflectsystems.com>
Message-ID: <CAOXsMFKnS95QWpvhGcnXa4aOfveZR+2h0YgK_eVDKq35mEbkag@mail.gmail.com>

You may contact CoreCodec for that, as they keep developping CoreAVC I
think they are also updating Haali's Splitter accordingly.

On Fri, Nov 18, 2011 at 9:31 PM, Aaron Griffin
<agriffin at reflectsystems.com>wrote:

> Hello,****
>
> ** **
>
> My name is Aaron Griffin.  We are using your product along with the Core
> AVC Codec.  We are getting a Splitter Crash that is taking place.  I wanted
> to speak with someone concerning this.  In addition, I would like to verify
> the version of the Haali Splitter that I have.  How would I proceed with
> verifying that information?  I have just received version 1.11.288.0.  I
> would like to verify if this is different from the version I currently have
> installed.  Below is some information associated with the crash.****
>
> ** **
>
> Alert Description: A Critical Error has occurred.****
>
> Alert Condition:  ****
>
>  Alert subject: Advanced Event****
>
> Log: application****
>
> Type: error****
>
> Event ID: 32972****
>
> Alert Group:      RAC Managed Svc****
>
> Generated:        11/17/2011 10:21 PM****
>
> ----------------------------------------------------------------------****
>
> Computer:  RAC-110907-8328****
>
> Date/Time: 2011-11-17 22:20:48****
>
> ** **
>
> Event Log: application****
>
> Type:      Error****
>
> Source:    RP_PlayerSvc2****
>
> Category:  ****
>
> Event:     32972****
>
> ** **
>
> Message:****
>
> ** **
>
> Critical Error Information:****
>
> Application:        c:\Program Files\Reflect
> Systems\ReflectPlayer\RP_PlayerSvc2.exe****
>
>   File Size:        1777152****
>
>   File Version:     5.6.50.0****
>
>   Product Version:  5.6.50.0****
>
> Exception code:     0xC0000005****
>
> Exception desc:     Attempt to read from an invalid address (0x00000111).*
> ***
>
> Address:            0x08047F3B****
>
> Last Win32 Err:     0x00000006****
>
> Description:        The handle is invalid.****
>
> ** **
>
> Time:               11/17/2011 22:20:48.529 ****
>
> GMTime:             11/18/2011 03:20:48.529 ****
>
> Run time:           3 days 8 hours 57 minutes 40 seconds.****
>
> Process Handles:    15882****
>
> System Handles:     26107****
>
> System Threads:     581****
>
> System Processes:   49****
>
> Physical Memory:    521518****
>
> Memory Available:   377103****
>
> Display Devices:****
>
>   NVIDIA GeForce 210 (\\.\DISPLAY1)****
>
>   NVIDIA GeForce 210 (\\.\DISPLAY2)****
>
> ** **
>
> ** **
>
> Stack Trace:****
>
> (0x08047F3B) [0001:00016F3B] c:\Program Files\Haali\MatroskaSplitter\
> splitter.ax****
>
> (0x08081F27) [0001:00050F27] c:\Program Files\Haali\MatroskaSplitter\
> splitter.ax****
>
> (0x08083141) [0001:00052141] c:\Program Files\Haali\MatroskaSplitter\
> splitter.ax****
>
> (0x08083BBB) [0001:00052BBB] c:\Program Files\Haali\MatroskaSplitter\
> splitter.ax****
>
> (0x0806D997) [0001:0003C997] c:\Program Files\Haali\MatroskaSplitter\
> splitter.ax****
>
> (0x77C237F5) [0001:000627F5] C:\Windows\SYSTEM32\ntdll.dll****
>
> (0x77C237C8) [0001:000627C8] C:\Windows\SYSTEM32\ntdll.dll****
>
> ** **
>
> If you would please follow up with me at your convenience, I would greatly
> appreciate it.  I look forward to hearing from you.  Have a great day!****
>
> ** **
>
> Thank you,****
>
> ** **
>
> ** **
>
> *Aaron Griffin** *| *Support Engineer | Reflect Systems, Inc.*****
>
> *9400 N. Central Expressway, Suite** **550 | Dallas, TX 75231*****
>
> *Office:  214-413-3219  ?  Cell:  469-487-8550*****
>
> *agriffin at reflectsystems.com | www.reflectsystems.com*****
>
> [image: Description: Description: cid:_2_078AFCC4078AFA7000485DC986257781]
> ****
>
> ** **
>



-- 
Steve Lhomme
Matroska association Chairman
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.matroska.org/pipermail/matroska-devel/attachments/20111119/0a642465/attachment.html>

From slhomme at matroska.org  Sat Nov 19 14:47:07 2011
From: slhomme at matroska.org (Steve Lhomme)
Date: Sat, 19 Nov 2011 14:47:07 +0100
Subject: [Matroska-devel] Question about tags
In-Reply-To: <6E366B79A95C442099287FC9D3928778@Smeulfi>
References: <6E366B79A95C442099287FC9D3928778@Smeulfi>
Message-ID: <CAOXsMFJZOzpC92Y7QCHbvvG8J9dvTGkZwY2rGFi2UD9kUFgkwA@mail.gmail.com>

As the specs say "Multiple items should never be stored as a list in a
single TagString. If there is more than one tag of a certain type to
be stored, then more than one SimpleTag should be used. "

So you should use as many items you need for the same type of element.

If some genre are missing, you can add your own.

On Tue, Nov 15, 2011 at 2:17 AM,  <smeulf at gmx.fr> wrote:
> Hi,
>
> I need to tag videos with genres, but I can?t find the right syntax.
>
> The tag specifications page says it folow the ?infamous TCON tag in ID3?
> format, but this format don?t seems to provide genres as ?Drama? or
> Science-Fiction?.
>
> Also, I need both genres in my tags.
>
> So my question is : ?Is the tag should be like this :?
>
> <Simple>
> ??? <Name>GENRE</Name>
> ??? <String>Drama</String>
> </Simple>
> <Simple>
> <Name>GENRE</Name>
> <String>Science-Fiction</String>
> </Simple>
>
> Or should it be an another format ? If so, can someone add some examples
> maybe in the ?Simpson? example page, and point me to the right way (ie the
> ID3-Movie genre definition) ?
>
> Thanks in advance.
>
> Smeulf.
> _______________________________________________
> 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 Nov 19 14:59:18 2011
From: slhomme at matroska.org (Steve Lhomme)
Date: Sat, 19 Nov 2011 14:59:18 +0100
Subject: [Matroska-devel] New video format support in mkv
In-Reply-To: <CAKJORkh8SFbN_yaSXZkP7PQNiUza9xiDSrqfqnHPBus2MSxNXQ@mail.gmail.com>
References: <CAKJORkh8SFbN_yaSXZkP7PQNiUza9xiDSrqfqnHPBus2MSxNXQ@mail.gmail.com>
Message-ID: <CAOXsMFLQxKFLpW6RLZ_Psi2YytqMpPW64yNfgt8bFkHJGSFsJw@mail.gmail.com>

It all depends on what framework you want to use your codec in. I
would suggest adding your codec in libav/ffmpeg. In that case adding
Matroska support is just adding the mapping of your codec ID/to your
codec code. That should be a single line addition.

If you want to use more features available for codecs, you may need
more than that.

On Thu, Nov 3, 2011 at 8:45 PM, Prasad H. L. <hlprasu at gmail.com> wrote:
> Hi,
>
> How easy or difficult is to add support for a new video format in the
> mkv container? I am experimenting with a video codec and wish the
> bit-stream generated by it for regular playback. Please let me know
> whether this is possible or what needs to be done for this.
>
> Regards,
> Prasad
> _______________________________________________
> 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 Nov 19 14:59:50 2011
From: slhomme at matroska.org (Steve Lhomme)
Date: Sat, 19 Nov 2011 14:59:50 +0100
Subject: [Matroska-devel] Please contact the JPEG codec support in MKV
	files.
In-Reply-To: <BLU0-SMTP184583B63F9414AD6005101F4ED0@phx.gbl>
References: <BLU0-SMTP184583B63F9414AD6005101F4ED0@phx.gbl>
Message-ID: <CAOXsMFK9b0X1vuiT8PjrxsBG275rOwST4erqHe2RC9gpg0kgew@mail.gmail.com>

Look at libav. It can probably do what you want already.

2011/10/26 ??? <park00245 at hotmail.com>:
>
> Hello
>
> I have JPEG files using MJPEG Codec MKV files I want to create.
> The development environment is linux.
> Please assist me with sample code, or please support the document.
> Thank you.
>
> --------------------------------------------------------
> Hwa-youl  Park
> Waytotec,Inc
>
> Staff Research Engineer
>
> Tel: 031-706-6546
> H.P: 010-7238-1537
> Fax: 02-762-2490
> Email : hypark at waytotec.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 smeulf at gmx.fr  Sun Nov 20 13:32:09 2011
From: smeulf at gmx.fr (smeulf at gmx.fr)
Date: Sun, 20 Nov 2011 13:32:09 +0100
Subject: [Matroska-devel] Question about tags
In-Reply-To: <CAOXsMFJZOzpC92Y7QCHbvvG8J9dvTGkZwY2rGFi2UD9kUFgkwA@mail.gmail.com>
References: <6E366B79A95C442099287FC9D3928778@Smeulfi>
	<CAOXsMFJZOzpC92Y7QCHbvvG8J9dvTGkZwY2rGFi2UD9kUFgkwA@mail.gmail.com>
Message-ID: <28E3DA1E06C444E9BBE625EFFA00E289@Smeulfi>

Hello Steve, Hello all,

Thanks for this answer, it's now all clear. I have a last (I hope) extra 
question about tags.

For the following tag, does the summary for TargetTupeValue=70 is replaced 
by the summary for TargetTypeValue=50 ?

I expect I can have a summary for each TargetTypeLevel, but I'm not sure if 
it's valid or not. Can you confirm how it will work ?

Rgds.

<Tags>
  <Tag>
    <Targets>
      <TargetTypeValue>70</TargetTypeValue>
    </Targets>
    <Simple>
      <Name>TITLE</Name>
      <String>Serie Name</String>
    </Simple>
    <Simple>
      <Name>SUMMARY</Name>
      <String>Serie summary</String>
    </Simple>
    <Simple>
      <Name>TOTAL_PARTS</Name>
      <String>4</String>
    </Simple>
  </Tag>
  <Tag>
    <Targets>
      <TargetTypeValue>60</TargetTypeValue>
    </Targets>
    <Simple>
      <Name>PART_NUMBER</Name>
      <String>2</String>
    </Simple>
    <Simple>
      <Name>TOTAL_PARTS</Name>
      <String>13</String>
    </Simple>
  </Tag>
  <Tag>
    <Targets>
      <TargetTypeValue>50</TargetTypeValue>
    </Targets>
    <Simple>
      <Name>TITLE</Name>
      <String>Episode Title</String>
    </Simple>
        <Simple>
            <Name>SUMMARY</Name>
            <String>Episode summary</String>
        </Simple>
    <Simple>
      <Name>PART_NUMBER</Name>
      <String>5</String>
    </Simple>
  </Tag>
</Tags>

-----Message d'origine----- 
From: Steve Lhomme
Sent: Saturday, November 19, 2011 2:47 PM
To: Discussion about the current and future development of Matroska
Subject: Re: [Matroska-devel] Question about tags

As the specs say "Multiple items should never be stored as a list in a
single TagString. If there is more than one tag of a certain type to
be stored, then more than one SimpleTag should be used. "

So you should use as many items you need for the same type of element.

If some genre are missing, you can add your own.

On Tue, Nov 15, 2011 at 2:17 AM,  <smeulf at gmx.fr> wrote:
> Hi,
>
> I need to tag videos with genres, but I can?t find the right syntax.
>
> The tag specifications page says it folow the ?infamous TCON tag in ID3?
> format, but this format don?t seems to provide genres as ?Drama? or
> Science-Fiction?.
>
> Also, I need both genres in my tags.
>
> So my question is : ?Is the tag should be like this :?
>
> <Simple>
>     <Name>GENRE</Name>
>     <String>Drama</String>
> </Simple>
> <Simple>
> <Name>GENRE</Name>
> <String>Science-Fiction</String>
> </Simple>
>
> Or should it be an another format ? If so, can someone add some examples
> maybe in the ?Simpson? example page, and point me to the right way (ie the
> ID3-Movie genre definition) ?
>
> Thanks in advance.
>
> Smeulf.
> _______________________________________________
> 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
_______________________________________________
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 agriffin at reflectsystems.com  Wed Nov 23 20:56:41 2011
From: agriffin at reflectsystems.com (Aaron Griffin)
Date: Wed, 23 Nov 2011 13:56:41 -0600
Subject: [Matroska-devel] Matroska Splitter
In-Reply-To: <CAOXsMFKnS95QWpvhGcnXa4aOfveZR+2h0YgK_eVDKq35mEbkag@mail.gmail.com>
References: <00b201cca631$16f5fd50$44e1f7f0$@reflectsystems.com>
	<CAOXsMFKnS95QWpvhGcnXa4aOfveZR+2h0YgK_eVDKq35mEbkag@mail.gmail.com>
Message-ID: <01fe01ccaa1a$05b54860$111fd920$@reflectsystems.com>

Hello Steve,

 

It appears CoreAVC is not updating the Haali Splitter.  The informed me that they are still using 1.11.288.0 in their latest release of their product.  We have reason to believe there may be a memory leak in the codec or possibly the splitter.ax  This crash is intermittently taking place.  Is there an updated version of the Splitter available?  If so, is there a change log available as well.  How do we troubleshoot the splitter?  Is there a way to enable to logging for the splitter?  We have a possible 3000 node project on the table which would require the codec and the splitter.  We would like to possible resolution prior to the deployment.  Can the technical staff for the both Matroska and Core AVC link up and possible provide a resolution or possible root cause for the issue at hand?  Attached is crash information for the issue at hand.  If you would please follow up with me at your earliest convenience, I would greatly appreciate it.  Have a great Thanksgiving!

 

Thank you,

 

Aaron Griffin | Support Engineer | Reflect Systems, Inc.

9400 N. Central Expressway, Suite 550 | Dallas, TX 75231

Office:  214-413-3219  ?  Cell:  469-487-8550

agriffin at reflectsystems.com | www.reflectsystems.com <http://www.reflectsystems.com/> 

Description: Description: cid:_2_078AFCC4078AFA7000485DC986257781

 

From: Steve Lhomme [mailto:slhomme at matroska.org] 
Sent: Saturday, November 19, 2011 7:27 AM
To: Aaron Griffin
Cc: matroska-users at lists.matroska.org; matroska-general at lists.matroska.org; matroska-devel at lists.matroska.org; matroska-cvs at lists.matroska.org; contact at matroska.org
Subject: Re: Matroska Splitter

 

You may contact CoreCodec for that, as they keep developping CoreAVC I think they are also updating Haali's Splitter accordingly. 

On Fri, Nov 18, 2011 at 9:31 PM, Aaron Griffin <agriffin at reflectsystems.com> wrote:

Hello,

 

My name is Aaron Griffin.  We are using your product along with the Core AVC Codec.  We are getting a Splitter Crash that is taking place.  I wanted to speak with someone concerning this.  In addition, I would like to verify the version of the Haali Splitter that I have.  How would I proceed with verifying that information?  I have just received version 1.11.288.0.  I would like to verify if this is different from the version I currently have installed.  Below is some information associated with the crash.

 

Alert Description: A Critical Error has occurred.

Alert Condition:  

 Alert subject: Advanced Event

Log: application

Type: error

Event ID: 32972

Alert Group:      RAC Managed Svc

Generated:        11/17/2011 10:21 PM

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

Computer:  RAC-110907-8328

Date/Time: 2011-11-17 22:20:48

 

Event Log: application

Type:      Error

Source:    RP_PlayerSvc2

Category:  

Event:     32972

 

Message:

 

Critical Error Information:

Application:        c:\Program Files\Reflect Systems\ReflectPlayer\RP_PlayerSvc2.exe

  File Size:        1777152

  File Version:     5.6.50.0

  Product Version:  5.6.50.0

Exception code:     0xC0000005

Exception desc:     Attempt to read from an invalid address (0x00000111).

Address:            0x08047F3B

Last Win32 Err:     0x00000006

Description:        The handle is invalid.

 

Time:               11/17/2011 22:20:48.529 

GMTime:             11/18/2011 03:20:48.529 

Run time:           3 days 8 hours 57 minutes 40 seconds.

Process Handles:    15882

System Handles:     26107

System Threads:     581

System Processes:   49

Physical Memory:    521518

Memory Available:   377103

Display Devices:

  NVIDIA GeForce 210 (\\.\DISPLAY1 <file:///\\.\DISPLAY1> )

  NVIDIA GeForce 210 (\\.\DISPLAY2 <file:///\\.\DISPLAY2> )

 

 

Stack Trace:

(0x08047F3B) [0001:00016F3B] c:\Program Files\Haali\MatroskaSplitter\splitter.ax

(0x08081F27) [0001:00050F27] c:\Program Files\Haali\MatroskaSplitter\splitter.ax

(0x08083141) [0001:00052141] c:\Program Files\Haali\MatroskaSplitter\splitter.ax

(0x08083BBB) [0001:00052BBB] c:\Program Files\Haali\MatroskaSplitter\splitter.ax

(0x0806D997) [0001:0003C997] c:\Program Files\Haali\MatroskaSplitter\splitter.ax

(0x77C237F5) [0001:000627F5] C:\Windows\SYSTEM32\ntdll.dll

(0x77C237C8) [0001:000627C8] C:\Windows\SYSTEM32\ntdll.dll

 

If you would please follow up with me at your convenience, I would greatly appreciate it.  I look forward to hearing from you.  Have a great day!

 

Thank you,

 

 

Aaron Griffin | Support Engineer | Reflect Systems, Inc.

9400 N. Central Expressway, Suite 550 | Dallas, TX 75231

Office:  214-413-3219  ?  Cell:  469-487-8550

agriffin at reflectsystems.com | www.reflectsystems.com <http://www.reflectsystems.com/> 

 




-- 
Steve Lhomme
Matroska association Chairman

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.matroska.org/pipermail/matroska-devel/attachments/20111123/55ea9ed1/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 16253 bytes
Desc: not available
URL: <http://lists.matroska.org/pipermail/matroska-devel/attachments/20111123/55ea9ed1/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Crash.zip
Type: application/x-zip-compressed
Size: 88992 bytes
Desc: not available
URL: <http://lists.matroska.org/pipermail/matroska-devel/attachments/20111123/55ea9ed1/attachment.bin>

From dmarlin at corecodec.com  Wed Nov 23 23:55:17 2011
From: dmarlin at corecodec.com (Dan Marlin)
Date: Wed, 23 Nov 2011 17:55:17 -0500
Subject: [Matroska-devel] Matroska Splitter
In-Reply-To: <01fe01ccaa1a$05b54860$111fd920$@reflectsystems.com>
References: <00b201cca631$16f5fd50$44e1f7f0$@reflectsystems.com>
	<CAOXsMFKnS95QWpvhGcnXa4aOfveZR+2h0YgK_eVDKq35mEbkag@mail.gmail.com>
	<01fe01ccaa1a$05b54860$111fd920$@reflectsystems.com>
Message-ID: <-2331167042075335646@unknownmsgid>

Aaron,

   Taking this out of the matroska ML. I have CC'd Haali to assist.

Dan Marlin
CEO/CoreCodec



On Nov 23, 2011, at 2:57 PM, Aaron Griffin <agriffin at reflectsystems.com>
wrote:

Hello Steve,



It appears CoreAVC is not updating the Haali Splitter.  The informed me
that they are still using 1.11.288.0 in their latest release of their
product.  We have reason to believe there may be a memory leak in the codec
or possibly the splitter.ax  This crash is intermittently taking place.  Is
there an updated version of the Splitter available?  If so, is there a
change log available as well.  How do we troubleshoot the splitter?  Is
there a way to enable to logging for the splitter?  We have a possible 3000
node project on the table which would require the codec and the splitter.
We would like to possible resolution prior to the deployment.  Can the
technical staff for the both Matroska and Core AVC link up and possible
provide a resolution or possible root cause for the issue at hand?
Attached is crash information for the issue at hand.  If you would please
follow up with me at your earliest convenience, I would greatly appreciate
it.  Have a great Thanksgiving!



Thank you,



*Aaron Griffin** *| *Support Engineer | Reflect Systems, Inc.*

*9400 N. Central Expressway, Suite** **550 | Dallas, TX 75231*

*Office:  214-413-3219  ?  Cell:  469-487-8550*

*agriffin at reflectsystems.com | www.reflectsystems.com*

<image001.png>



*From:* Steve Lhomme [mailto:slhomme at matroska.org]
*Sent:* Saturday, November 19, 2011 7:27 AM
*To:* Aaron Griffin
*Cc:* matroska-users at lists.matroska.org; matroska-general at lists.matroska.org;
matroska-devel at lists.matroska.org; matroska-cvs at lists.matroska.org;
contact at matroska.org
*Subject:* Re: Matroska Splitter



You may contact CoreCodec for that, as they keep developping CoreAVC I
think they are also updating Haali's Splitter accordingly.

On Fri, Nov 18, 2011 at 9:31 PM, Aaron Griffin <agriffin at reflectsystems.com>
wrote:

Hello,



My name is Aaron Griffin.  We are using your product along with the Core
AVC Codec.  We are getting a Splitter Crash that is taking place.  I wanted
to speak with someone concerning this.  In addition, I would like to verify
the version of the Haali Splitter that I have.  How would I proceed with
verifying that information?  I have just received version 1.11.288.0.  I
would like to verify if this is different from the version I currently have
installed.  Below is some information associated with the crash.



Alert Description: A Critical Error has occurred.

Alert Condition:

 Alert subject: Advanced Event

Log: application

Type: error

Event ID: 32972

Alert Group:      RAC Managed Svc

Generated:        11/17/2011 10:21 PM

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

Computer:  RAC-110907-8328

Date/Time: 2011-11-17 22:20:48



Event Log: application

Type:      Error

Source:    RP_PlayerSvc2

Category:

Event:     32972



Message:



Critical Error Information:

Application:        c:\Program Files\Reflect
Systems\ReflectPlayer\RP_PlayerSvc2.exe

  File Size:        1777152

  File Version:     5.6.50.0

  Product Version:  5.6.50.0

Exception code:     0xC0000005

Exception desc:     Attempt to read from an invalid address (0x00000111).

Address:            0x08047F3B

Last Win32 Err:     0x00000006

Description:        The handle is invalid.



Time:               11/17/2011 22:20:48.529

GMTime:             11/18/2011 03:20:48.529

Run time:           3 days 8 hours 57 minutes 40 seconds.

Process Handles:    15882

System Handles:     26107

System Threads:     581

System Processes:   49

Physical Memory:    521518

Memory Available:   377103

Display Devices:

  NVIDIA GeForce 210 (\\.\DISPLAY1 <file:///\\.\DISPLAY1>)

  NVIDIA GeForce 210 (\\.\DISPLAY2 <file:///\\.\DISPLAY2>)





Stack Trace:

(0x08047F3B) [0001:00016F3B] c:\Program Files\Haali\MatroskaSplitter\
splitter.ax

(0x08081F27) [0001:00050F27] c:\Program Files\Haali\MatroskaSplitter\
splitter.ax

(0x08083141) [0001:00052141] c:\Program Files\Haali\MatroskaSplitter\
splitter.ax

(0x08083BBB) [0001:00052BBB] c:\Program Files\Haali\MatroskaSplitter\
splitter.ax

(0x0806D997) [0001:0003C997] c:\Program Files\Haali\MatroskaSplitter\
splitter.ax

(0x77C237F5) [0001:000627F5] C:\Windows\SYSTEM32\ntdll.dll

(0x77C237C8) [0001:000627C8] C:\Windows\SYSTEM32\ntdll.dll



If you would please follow up with me at your convenience, I would greatly
appreciate it.  I look forward to hearing from you.  Have a great day!



Thank you,





*Aaron Griffin** *| *Support Engineer | Reflect Systems, Inc.*

*9400 N. Central Expressway, Suite** **550 | Dallas, TX 75231*

*Office:  214-413-3219  ?  Cell:  469-487-8550*

*agriffin at reflectsystems.com | www.reflectsystems.com*






-- 
Steve Lhomme
Matroska association Chairman

<Crash.zip>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.matroska.org/pipermail/matroska-devel/attachments/20111123/b60be776/attachment.html>

From agriffin at reflectsystems.com  Mon Nov 28 15:47:49 2011
From: agriffin at reflectsystems.com (Aaron Griffin)
Date: Mon, 28 Nov 2011 08:47:49 -0600
Subject: [Matroska-devel] Matroska Splitter
In-Reply-To: <-2331167042075335646@unknownmsgid>
References: <00b201cca631$16f5fd50$44e1f7f0$@reflectsystems.com>
	<CAOXsMFKnS95QWpvhGcnXa4aOfveZR+2h0YgK_eVDKq35mEbkag@mail.gmail.com>
	<01fe01ccaa1a$05b54860$111fd920$@reflectsystems.com>
	<-2331167042075335646@unknownmsgid>
Message-ID: <022f01ccaddc$b4735750$1d5a05f0$@reflectsystems.com>

Thank you Dan.  I will be on standby.

 

Aaron Griffin | Support Engineer | Reflect Systems, Inc.

9400 N. Central Expressway, Suite 550 | Dallas, TX 75231

Office:  214-413-3219  ?  Cell:  469-487-8550

agriffin at reflectsystems.com | www.reflectsystems.com <http://www.reflectsystems.com/> 

Description: Description: cid:_2_078AFCC4078AFA7000485DC986257781

 

From: Dan Marlin [mailto:dmarlin at corecodec.com] 
Sent: Wednesday, November 23, 2011 4:55 PM
To: Aaron Griffin
Cc: Steve Lhomme; CC - Andrew Dunstan; mallmon at corecodec.com; matroska-users at lists.matroska.org; matroska-general at lists.matroska.org; matroska-devel at lists.matroska.org; matroska-cvs at lists.matroska.org; contact at matroska.org; arivera at reflectsystems.com; haali at corecodec.com
Subject: Re: Matroska Splitter

 


Aaron,

 

   Taking this out of the matroska ML. I have CC'd Haali to assist.

 

Dan Marlin

CEO/CoreCodec

 

 


On Nov 23, 2011, at 2:57 PM, Aaron Griffin <agriffin at reflectsystems.com> wrote:

Hello Steve,

 

It appears CoreAVC is not updating the Haali Splitter.  The informed me that they are still using 1.11.288.0 in their latest release of their product.  We have reason to believe there may be a memory leak in the codec or possibly the splitter.ax  This crash is intermittently taking place.  Is there an updated version of the Splitter available?  If so, is there a change log available as well.  How do we troubleshoot the splitter?  Is there a way to enable to logging for the splitter?  We have a possible 3000 node project on the table which would require the codec and the splitter.  We would like to possible resolution prior to the deployment.  Can the technical staff for the both Matroska and Core AVC link up and possible provide a resolution or possible root cause for the issue at hand?  Attached is crash information for the issue at hand.  If you would please follow up with me at your earliest convenience, I would greatly appreciate it.  Have a great Thanksgiving!

 

Thank you,

 

Aaron Griffin | Support Engineer | Reflect Systems, Inc.

9400 N. Central Expressway, Suite 550 | Dallas, TX 75231

Office:  214-413-3219  ?  Cell:  469-487-8550

agriffin at reflectsystems.com | www.reflectsystems.com <http://www.reflectsystems.com/> 

<image001.png>

 

From: Steve Lhomme [mailto:slhomme at matroska.org] 
Sent: Saturday, November 19, 2011 7:27 AM
To: Aaron Griffin
Cc: matroska-users at lists.matroska.org; matroska-general at lists.matroska.org; matroska-devel at lists.matroska.org; matroska-cvs at lists.matroska.org; contact at matroska.org
Subject: Re: Matroska Splitter

 

You may contact CoreCodec for that, as they keep developping CoreAVC I think they are also updating Haali's Splitter accordingly. 

On Fri, Nov 18, 2011 at 9:31 PM, Aaron Griffin <agriffin at reflectsystems.com> wrote:

Hello,

 

My name is Aaron Griffin.  We are using your product along with the Core AVC Codec.  We are getting a Splitter Crash that is taking place.  I wanted to speak with someone concerning this.  In addition, I would like to verify the version of the Haali Splitter that I have.  How would I proceed with verifying that information?  I have just received version 1.11.288.0.  I would like to verify if this is different from the version I currently have installed.  Below is some information associated with the crash.

 

Alert Description: A Critical Error has occurred.

Alert Condition:  

 Alert subject: Advanced Event

Log: application

Type: error

Event ID: 32972

Alert Group:      RAC Managed Svc

Generated:        11/17/2011 10:21 PM

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

Computer:  RAC-110907-8328

Date/Time: 2011-11-17 22:20:48

 

Event Log: application

Type:      Error

Source:    RP_PlayerSvc2

Category:  

Event:     32972

 

Message:

 

Critical Error Information:

Application:        c:\Program Files\Reflect Systems\ReflectPlayer\RP_PlayerSvc2.exe

  File Size:        1777152

  File Version:     5.6.50.0

  Product Version:  5.6.50.0

Exception code:     0xC0000005

Exception desc:     Attempt to read from an invalid address (0x00000111).

Address:            0x08047F3B

Last Win32 Err:     0x00000006

Description:        The handle is invalid.

 

Time:               11/17/2011 22:20:48.529 

GMTime:             11/18/2011 03:20:48.529 

Run time:           3 days 8 hours 57 minutes 40 seconds.

Process Handles:    15882

System Handles:     26107

System Threads:     581

System Processes:   49

Physical Memory:    521518

Memory Available:   377103

Display Devices:

  NVIDIA GeForce 210 (\\.\DISPLAY1 <file:///\\.\DISPLAY1> )

  NVIDIA GeForce 210 (\\.\DISPLAY2 <file:///\\.\DISPLAY2> )

 

 

Stack Trace:

(0x08047F3B) [0001:00016F3B] c:\Program Files\Haali\MatroskaSplitter\splitter.ax

(0x08081F27) [0001:00050F27] c:\Program Files\Haali\MatroskaSplitter\splitter.ax

(0x08083141) [0001:00052141] c:\Program Files\Haali\MatroskaSplitter\splitter.ax

(0x08083BBB) [0001:00052BBB] c:\Program Files\Haali\MatroskaSplitter\splitter.ax

(0x0806D997) [0001:0003C997] c:\Program Files\Haali\MatroskaSplitter\splitter.ax

(0x77C237F5) [0001:000627F5] C:\Windows\SYSTEM32\ntdll.dll

(0x77C237C8) [0001:000627C8] C:\Windows\SYSTEM32\ntdll.dll

 

If you would please follow up with me at your convenience, I would greatly appreciate it.  I look forward to hearing from you.  Have a great day!

 

Thank you,

 

 

Aaron Griffin | Support Engineer | Reflect Systems, Inc.

9400 N. Central Expressway, Suite 550 | Dallas, TX 75231

Office:  214-413-3219  ?  Cell:  469-487-8550

agriffin at reflectsystems.com | www.reflectsystems.com <http://www.reflectsystems.com/> 

 




-- 
Steve Lhomme
Matroska association Chairman

<Crash.zip>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.matroska.org/pipermail/matroska-devel/attachments/20111128/055de9ef/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 16253 bytes
Desc: not available
URL: <http://lists.matroska.org/pipermail/matroska-devel/attachments/20111128/055de9ef/attachment.png>