From slhomme at matroska.org  Sun Dec  4 20:31:41 2011
From: slhomme at matroska.org (Steve Lhomme)
Date: Sun, 4 Dec 2011 20:31:41 +0100
Subject: [Matroska-devel] Apple ProRes
Message-ID: <CAOXsMFK5cEvG_rGA9Li7gMQTMyioOdHSVV4abwi1B9Ew=HnH8w@mail.gmail.com>

Here is a proposal on how to store Apple's ProRes in Matroska. The
technical info on the codec can be found here:
http://wiki.multimedia.cx/index.php?title=Apple_ProRes#Frame_layout

The IDs are as follows:
    Apple ProRes 422 High Quality: V_PRORES422_HQ
    Apple ProRes 422 Standard Definition: V_PRORES422_SD
    Apple ProRes 422 LT: V_PRORES422_LT
    Apple ProRes 422 Proxy: V_PRORES422_PROXY
    Apple ProRes 4444: V_PRORES4444

Each Frame (in the Matroska sense) is composed of the Frame Header,
the Picture 1 and Picture 2 (when necessary).
If these data are always the same, the header compression in Matroska
can be used to strip it and save a little space.

-- 
Steve Lhomme
Matroska association Chairman


From slhomme at matroska.org  Sun Dec  4 20:58:27 2011
From: slhomme at matroska.org (Steve Lhomme)
Date: Sun, 4 Dec 2011 20:58:27 +0100
Subject: [Matroska-devel] Apple ProRes
In-Reply-To: <CAOXsMFK5cEvG_rGA9Li7gMQTMyioOdHSVV4abwi1B9Ew=HnH8w@mail.gmail.com>
References: <CAOXsMFK5cEvG_rGA9Li7gMQTMyioOdHSVV4abwi1B9Ew=HnH8w@mail.gmail.com>
Message-ID: <CAOXsMFK+z6EVP42mWdc+fc2CM-6fz4R5Wif1+U+PPiLjd6Q76A@mail.gmail.com>

After discussion the best is to use one codec ID for all : V_PRORES
And the fourcc in use in MOV for each profile will be the codec
private. This way new profiles can be added and existing codec mapping
will work without changes.

The content of each Frame remains as described below.

On Sun, Dec 4, 2011 at 8:31 PM, Steve Lhomme <slhomme at matroska.org> wrote:
> Here is a proposal on how to store Apple's ProRes in Matroska. The
> technical info on the codec can be found here:
> http://wiki.multimedia.cx/index.php?title=Apple_ProRes#Frame_layout
>
> The IDs are as follows:
> ? ?Apple ProRes 422 High Quality: V_PRORES422_HQ
> ? ?Apple ProRes 422 Standard Definition: V_PRORES422_SD
> ? ?Apple ProRes 422 LT: V_PRORES422_LT
> ? ?Apple ProRes 422 Proxy: V_PRORES422_PROXY
> ? ?Apple ProRes 4444: V_PRORES4444
>
> Each Frame (in the Matroska sense) is composed of the Frame Header,
> the Picture 1 and Picture 2 (when necessary).
> If these data are always the same, the header compression in Matroska
> can be used to strip it and save a little space.
>
> --
> Steve Lhomme
> Matroska association Chairman



-- 
Steve Lhomme
Matroska association Chairman


From huzefa.siyamwala at sibridgetech.com  Thu Dec  8 07:16:29 2011
From: huzefa.siyamwala at sibridgetech.com (Huzefa Siyamwala)
Date: Thu, 8 Dec 2011 11:46:29 +0530
Subject: [Matroska-devel] Gstreamer Matroska muxer plugin
Message-ID: <CAMZopuqdONmR-Q0SxO-1dLJNCqEvkuF_LeFKXAveBvqK6wT+pg@mail.gmail.com>

Hi,
i have been implementing plugin for gstreamer and got to used matroska mux
as one of the element in pipeline. But i found that for mpeg video streams
it cannot mux all the frames and it simply muxes the first frame with zero
timecode and discards all other frames.i am using mpegvideo parse for mpeg
version1,2 video files and and mpeg4videoparse for mpeg4 video files.I am
not able to figure out that whether issue is created by parser element or
matroska muxer element. If issue is created by parser element kindly let me
know the parser gstreamer element which can work correctly with matroskamux
element for mpeg files.

Regards,
*Huzefa Siyamwala*
huzefa.siyam <huzefa.siyamwala at sibridgetech.com>wala at sibridgetech.com<huzefa.siyamwala at sibridgetech.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.matroska.org/pipermail/matroska-devel/attachments/20111208/4856c749/attachment.html>

From moritz at bunkus.org  Thu Dec  8 09:15:51 2011
From: moritz at bunkus.org (Moritz Bunkus)
Date: Thu, 8 Dec 2011 09:15:51 +0100
Subject: [Matroska-devel] Gstreamer Matroska muxer plugin
In-Reply-To: <CAMZopuqdONmR-Q0SxO-1dLJNCqEvkuF_LeFKXAveBvqK6wT+pg@mail.gmail.com>
References: <CAMZopuqdONmR-Q0SxO-1dLJNCqEvkuF_LeFKXAveBvqK6wT+pg@mail.gmail.com>
Message-ID: <CANPayMSdfHstjt4YpF-FF==KDj-mcRCVgty74nDrmuwMUE4aYw@mail.gmail.com>

Hey,

we're not working on gstreamer at all, and as far as I know none of
the gstreamer developers read this list. So it would be better if you
could ask such questions on their channels (mailing lists/bug
tracker/IRC channel... I don't know what their official contact
options include).

Kind regards,
mo


From huzefa.siyamwala at sibridgetech.com  Thu Dec  8 10:30:48 2011
From: huzefa.siyamwala at sibridgetech.com (Huzefa Siyamwala)
Date: Thu, 8 Dec 2011 15:00:48 +0530
Subject: [Matroska-devel] Gstreamer Matroska muxer plugin
In-Reply-To: <CANPayMSdfHstjt4YpF-FF==KDj-mcRCVgty74nDrmuwMUE4aYw@mail.gmail.com>
References: <CAMZopuqdONmR-Q0SxO-1dLJNCqEvkuF_LeFKXAveBvqK6wT+pg@mail.gmail.com>
	<CANPayMSdfHstjt4YpF-FF==KDj-mcRCVgty74nDrmuwMUE4aYw@mail.gmail.com>
Message-ID: <CAMZopup26cTtvYNK56cTHn9-=4RwgGZQiXqfv_UFXA9+o=st+Q@mail.gmail.com>

Thanks. I would definately try to get mine issue resolved using either
gstreamer IRC or their official mailing list.

On Thu, Dec 8, 2011 at 1:45 PM, Moritz Bunkus <moritz at bunkus.org> wrote:

> Hey,
>
> we're not working on gstreamer at all, and as far as I know none of
> the gstreamer developers read this list. So it would be better if you
> could ask such questions on their channels (mailing lists/bug
> tracker/IRC channel... I don't know what their official contact
> options include).
>
> Kind regards,
> mo
> _______________________________________________
> 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
>



-- 
Regards,
*Huzefa Siyamwala*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.matroska.org/pipermail/matroska-devel/attachments/20111208/3fa53cfc/attachment.html>

From slhomme at matroska.org  Thu Dec  8 15:37:53 2011
From: slhomme at matroska.org (Steve Lhomme)
Date: Thu, 08 Dec 2011 15:37:53 +0100
Subject: [Matroska-devel] Apple ProRes
In-Reply-To: <CAOXsMFK+z6EVP42mWdc+fc2CM-6fz4R5Wif1+U+PPiLjd6Q76A@mail.gmail.com>
References: <CAOXsMFK5cEvG_rGA9Li7gMQTMyioOdHSVV4abwi1B9Ew=HnH8w@mail.gmail.com>
	<CAOXsMFK+z6EVP42mWdc+fc2CM-6fz4R5Wif1+U+PPiLjd6Q76A@mail.gmail.com>
Message-ID: <4EE0CBC1.2030903@matroska.org>

Nobody seems to disagree, so this has been pushed on the website:
http://www.matroska.org/technical/specs/codecid/index.html

Le 04/12/2011 20:58, Steve Lhomme a ?crit :
> After discussion the best is to use one codec ID for all : V_PRORES
> And the fourcc in use in MOV for each profile will be the codec
> private. This way new profiles can be added and existing codec mapping
> will work without changes.
>
> The content of each Frame remains as described below.
>
> On Sun, Dec 4, 2011 at 8:31 PM, Steve Lhomme<slhomme at matroska.org>  wrote:
>> Here is a proposal on how to store Apple's ProRes in Matroska. The
>> technical info on the codec can be found here:
>> http://wiki.multimedia.cx/index.php?title=Apple_ProRes#Frame_layout
>>
>> The IDs are as follows:
>>     Apple ProRes 422 High Quality: V_PRORES422_HQ
>>     Apple ProRes 422 Standard Definition: V_PRORES422_SD
>>     Apple ProRes 422 LT: V_PRORES422_LT
>>     Apple ProRes 422 Proxy: V_PRORES422_PROXY
>>     Apple ProRes 4444: V_PRORES4444
>>
>> Each Frame (in the Matroska sense) is composed of the Frame Header,
>> the Picture 1 and Picture 2 (when necessary).
>> If these data are always the same, the header compression in Matroska
>> can be used to strip it and save a little space.
>>
>> --
>> Steve Lhomme
>> Matroska association Chairman
>
>
>




From misc03 at blueyonder.co.uk  Fri Dec  9 14:50:43 2011
From: misc03 at blueyonder.co.uk (jack)
Date: Fri, 9 Dec 2011 13:50:43 +0000 (UTC)
Subject: [Matroska-devel] AAC in .TS files bug
References: <loom.20111028T051650-388@post.gmane.org>
Message-ID: <loom.20111209T144501-448@post.gmane.org>

jack <misc03 <at> blueyonder.co.uk> writes:

> 
> Using MPC for playback I cant get any files with AAC in to work
> If I remove Haali and install LAVI filters the same files play (but with 
video 
> problems) No other changes were required.
>

Sorry to put this here but I cant find a status page or anything.

Can anyone say whether the issue I raised is being looked at or
if/when it would be likely to be resolved?

As almost all the files I use now have this form of AAC I need to
decide whether I can keep Haali (I'd like to - it is otherwise the best 
splitter I've seen) or if I must use an alternative.

Also I noticed a red tick against the original message - presumably this means
something - is there a key for such marks somewhere?

thanks
jack





From moritz at bunkus.org  Fri Dec  9 15:14:31 2011
From: moritz at bunkus.org (Moritz Bunkus)
Date: Fri, 9 Dec 2011 15:14:31 +0100
Subject: [Matroska-devel] AAC in .TS files bug
In-Reply-To: <loom.20111209T144501-448@post.gmane.org>
References: <loom.20111028T051650-388@post.gmane.org>
	<loom.20111209T144501-448@post.gmane.org>
Message-ID: <CANPayMSGPj0D=Ot0X+bg_3TBVdHCMWYantHMs6y4e2ajK_TVPA@mail.gmail.com>

Hey,

as Haali is almost never responding to emails here I highly doubt that
your issue will be looked at. It's his product alone that no one else
has access to.

I strongly advise you give the rather new but actively developed
project "LAV filters" a try. It's a DirectShow splitter that is based
on the "avfilter" library, part of the well-known ffmpeg project. See
the ongoing discussion over at doom9 for details:
http://forum.doom9.org/showthread.php?t=156191

Kind regards,
mo


From misc03 at blueyonder.co.uk  Mon Dec 12 16:25:26 2011
From: misc03 at blueyonder.co.uk (jack616)
Date: Mon, 12 Dec 2011 15:25:26 +0000 (UTC)
Subject: [Matroska-devel] AAC in .TS files bug
References: <loom.20111028T051650-388@post.gmane.org>
	<loom.20111209T144501-448@post.gmane.org>
	<CANPayMSGPj0D=Ot0X+bg_3TBVdHCMWYantHMs6y4e2ajK_TVPA@mail.gmail.com>
Message-ID: <loom.20111212T162029-905@post.gmane.org>

> I strongly advise you give the rather new but actively developed
> project "LAV filters" a try. It's a DirectShow splitter that is based
> on the "avfilter" library, part of the well-known ffmpeg project. See
> the ongoing discussion over at doom9 for details:
> http://forum.doom9.org/showthread.php?t=156191
> 
>

Thanks for the reply Moritz.
I now have the LAV filters installed but they seem a bit unreliable when 
seeking 
leaving breakups and for a second or so a sync error on my machine. 
(Otherwise it seems to work fine and does play back the AAC audio)
I also seem to have lost the ability to play back some types of mpeg1 and mpeg2
files. It just feels a bit clunky for that reason.
I will check out your link though - if it is being actively supported such 
things will probably get sorted out sooner or later.

thanks again.

 



From giles at thaumas.net  Wed Dec 14 21:27:49 2011
From: giles at thaumas.net (Ralph Giles)
Date: Wed, 14 Dec 2011 12:27:49 -0800
Subject: [Matroska-devel] Opus audio codec
Message-ID: <CAEW_RkvszGdnaR9Jtfp81fjcfh5j_LfVeZ-Y+QjEZy1r5+qAXA@mail.gmail.com>

Hi,

I'm interested in adding support for the IETF Opus audio codec in Matroska.

Significant features, from the container point of view:

- Opus codes everything at 48 kHz
- The decoder can generate either mono or stereo from any stream
- Compressed frames are variable length, and the length of each frame
must be signaled to the decoder
- There's a 'multistream' extension for doing surround.

Since there's little extra signalling necessary, a simple approach would be:

  CodecID is V_OPUS
  SamplingFrequency is always 48000
  Channels is 1 or 2, based on what the muxer thinks is most
appropriate. When in doubt, use 2?
  CodecPrivate is void

That works great if you don't want more than two channels. The
'multistream' mode packs multiple mono/stereo streams into each frame,
but requires the container signal the number of streams and how
they're coupled. I can see two ways to make that work:

1) Define a new channel mapping element. The spec mentions a
ChannelPositions element, but doesn't define the format for it.
However we need more than just speaker positions. To decode
multistream Opus we need to know, for each stream packed into the
frames, whether to decode it as a coupled stereo pair (e.g.
REAR_LEFT+REAR_RIGHT) or as an isolated mono channel (e.g. LFE) and
how those map to the actual output channels.

The multistream packing is designed so a single mono or coupled-stereo
multistream frame is the same as a non-multistream frame, so for
non-surround uses, this element can just be omitted.

Pros: straightforward?
Cons: probably not useful for other codecs

2) Copy the headers used in the Ogg encapsulation into CodecPrivate,
similar to what is done for A_VORBIS and V_THEORA. This already
defines a binary format for the channel mapping, along with a bunch of
other things.

Pros: Lossless transmux between Ogg and Matroska, possible code sharing
Cons: more complex, codec specific code

For example, the Ogg header has a required gain field the demuxer is
supposed to pass down the decode pipeline to where it can applied,
similar to ReplayGain tags. I worry that supporting those fields
correctly will be painful.

Draft specs, for reference:

http://tools.ietf.org/html/draft-ietf-codec-opus
https://wiki.xiph.org/OggOpus

Comments? Alternate proposals?

 -r


From moritz at bunkus.org  Wed Dec 14 21:42:39 2011
From: moritz at bunkus.org (Moritz Bunkus)
Date: Wed, 14 Dec 2011 21:42:39 +0100
Subject: [Matroska-devel] Opus audio codec
In-Reply-To: <CAEW_RkvszGdnaR9Jtfp81fjcfh5j_LfVeZ-Y+QjEZy1r5+qAXA@mail.gmail.com>
References: <CAEW_RkvszGdnaR9Jtfp81fjcfh5j_LfVeZ-Y+QjEZy1r5+qAXA@mail.gmail.com>
Message-ID: <CANPayMR28Apm0c9dax4RGvmytjr3sU1hev3YCM+zs9xdDObnSA@mail.gmail.com>

Hey,

the "normal case" mapping looks straight forward, I agree.

First thing that came to my mind about the multichannel thingy was
that either way we implement it requires Opus-dependent code both in
the muxer and in the demuxer. It just looks slightly different.

If you get right down to it each and every codec that needs some kind
of special data (channel mapping, quantizers, whatever) also needs
special code in _some_ muxer -- even if e.g. mkvmerge only copies that
stuff from the AVIs BITMAPINFOHEADER to the Matroska file. Even in
that case the muxer creating the AVI would have had to contain
codec-specific code (or the system in general would have to provide
facilities to let the codec itself create that data and pass it on).
So: it's not unusual and completely OK.

I'm very busy until the weekend and I'll write more then.

Kind regards,
mo


From moritz at bunkus.org  Wed Dec 14 22:11:25 2011
From: moritz at bunkus.org (Moritz Bunkus)
Date: Wed, 14 Dec 2011 22:11:25 +0100
Subject: [Matroska-devel] Opus audio codec
In-Reply-To: <CAEW_RkvszGdnaR9Jtfp81fjcfh5j_LfVeZ-Y+QjEZy1r5+qAXA@mail.gmail.com>
References: <CAEW_RkvszGdnaR9Jtfp81fjcfh5j_LfVeZ-Y+QjEZy1r5+qAXA@mail.gmail.com>
Message-ID: <CANPayMTAFFKRDds-Fcd3euGx9zQTDDB2R-+F5-VvoYWvQDSeKw@mail.gmail.com>

Hey,

OK I've taken a look at Xiph's mapping of Opus in Ogg. The ID header
they describe looks nearly fine to me: nothing that's too Ogg-centric
apart from the "OpusHead" string. I'd rather skip this as a
distinguishing feature between CodecPrivate and some other Matroska
element is simply not necessary in Matroska (I'm referring to the part
"The magic signature "OpusHead" allows codec identification and is
human readable. Starting with 'Op' helps distinguish it from data
packets, as this is an invalid TOC sequence." We also already have a
human-readable CodecID for the first part.

So what I'd propose would be your solution 2 (no new Matroska channel
mapping element only for this codec) with a slight modification.
CodecPrivate should consist of (copy & paste from Xiph.org):

- Version number (8 bits): zero for this spec
- Channel count 'c' (8 bits unsigned): MUST be > 0
- Pre-skip (16 bits unsigned)
- Input sample rate (32 bits, little endian): informational only
- Output gain (16 bits, little endian, signed Q7.8 in dB) to apply when decoding
- Channel mapping family (8 bits)
 --  0 = one stream, RTP order, 1 = channels in order as stated below,
2..254 reserved (treat as 255), 255 = no defined channel meaning
If channel mapping family > 0
- Stream count 'N' (8 bits unsigned): MUST be > 0
- Two-channel stream count 'M' (8 bits unsigned): MUST satisfy M <= N,
M+N <= 255
- Channel mapping (8*c bits)
  -- one stream index (8 bits unsigned) per channel (255 means silent
throughout the file)

Then we only have to define the channel mapping family 1 somewhere
which should match Vorbis' channel mapping (I just don't like the
Matroska specs referring to the Vorbis specs for something like this).

Kind regards,
mo


From giles at thaumas.net  Thu Dec 15 01:24:55 2011
From: giles at thaumas.net (Ralph Giles)
Date: Wed, 14 Dec 2011 16:24:55 -0800
Subject: [Matroska-devel] Opus audio codec
In-Reply-To: <CANPayMTAFFKRDds-Fcd3euGx9zQTDDB2R-+F5-VvoYWvQDSeKw@mail.gmail.com>
References: <CAEW_RkvszGdnaR9Jtfp81fjcfh5j_LfVeZ-Y+QjEZy1r5+qAXA@mail.gmail.com>
	<CANPayMTAFFKRDds-Fcd3euGx9zQTDDB2R-+F5-VvoYWvQDSeKw@mail.gmail.com>
Message-ID: <CAEW_RktJ0deALvGM0eZW==rKWhHd_EF_zpt2aZ=-s3uUQK3ycw@mail.gmail.com>

Hey Moritz. Thanks for taking a look. Some comments:

On 14 December 2011 13:11, Moritz Bunkus <moritz at bunkus.org> wrote:

>                      The ID header
> they describe looks nearly fine to me: nothing that's too Ogg-centric
> apart from the "OpusHead" string.

I agree this is completely unnecessary in Matroska, but if we go this
route I think we might as well keep it. The extra eight bytes aren't
significant overhead and it's easier if the two encapsulations use
exactly the same format. I mean, the number of channels and sample
rate fields aren't necessary here either.

> So what I'd propose would be your solution 2 (no new Matroska channel
> mapping element only for this codec) with a slight modification.

The Ogg encapsulation also has a second vorbis-style comment header
with tag data. These are also redundant of course, but including both
headers exactly as they are in Ogg would match what's done for vorbis,
theora, and flac.

> Then we only have to define the channel mapping family 1 somewhere
> which should match Vorbis' channel mapping (I just don't like the
> Matroska specs referring to the Vorbis specs for something like this).

That's fine. For the record, the channel ordering for mapping family 1 is:

one channel: mono
two channels: (stereo) left, right
three channels: left, centre, right
four channels: front left, front right, rear left, rear right
five channels: front left, centre, front right, rear left, rear right
six channels: (5.1) front left, centre, front right, rear left, rear right, LFE
seven channels: front left, centre, front right, side left, side
right, rear center, LFE
eight channels: (7.1) front left, centre, front right, side left, side
right, rear left, rear right, LFE

More than eight channels doesn't have a defined ordering and should be
treated like channel mapping 255.

 -r


From moritz at bunkus.org  Thu Dec 15 09:12:45 2011
From: moritz at bunkus.org (Moritz Bunkus)
Date: Thu, 15 Dec 2011 09:12:45 +0100
Subject: [Matroska-devel] Opus audio codec
In-Reply-To: <CAEW_RktJ0deALvGM0eZW==rKWhHd_EF_zpt2aZ=-s3uUQK3ycw@mail.gmail.com>
References: <CAEW_RkvszGdnaR9Jtfp81fjcfh5j_LfVeZ-Y+QjEZy1r5+qAXA@mail.gmail.com>
	<CANPayMTAFFKRDds-Fcd3euGx9zQTDDB2R-+F5-VvoYWvQDSeKw@mail.gmail.com>
	<CAEW_RktJ0deALvGM0eZW==rKWhHd_EF_zpt2aZ=-s3uUQK3ycw@mail.gmail.com>
Message-ID: <CANPayMQeKN2NVreySR4rnYDjYWzijhDPfNByNdum2nWuRkM6yg@mail.gmail.com>

Hey,

On Thu, Dec 15, 2011 at 01:24, Ralph Giles <giles at thaumas.net> wrote:

> I agree this is completely unnecessary in Matroska, but if we go this
> route I think we might as well keep it. The extra eight bytes aren't
> significant overhead and it's easier if the two encapsulations use
> exactly the same format. I mean, the number of channels and sample
> rate fields aren't necessary here either.

True enough, so let's just keep it.

> The Ogg encapsulation also has a second vorbis-style comment header
> with tag data. These are also redundant of course, but including both
> headers exactly as they are in Ogg would match what's done for vorbis,
> theora, and flac.

Well, Vorbis, Theora and FLAC are codecs that originated from Xiph and
were usually delivered in Ogg encapsulation. It's different with OPUS
if I understood that correctly -- it doesn't originate from the Xiph
organisation. What I don't like is having a comment header in
CodecPrivate as it circumvents Matroska's tagging system.

> More than eight channels doesn't have a defined ordering and should be
> treated like channel mapping 255.

Agreed.

Kind regards,
mo


From giles at thaumas.net  Thu Dec 15 22:41:47 2011
From: giles at thaumas.net (Ralph Giles)
Date: Thu, 15 Dec 2011 13:41:47 -0800
Subject: [Matroska-devel] Opus audio codec
In-Reply-To: <CANPayMQeKN2NVreySR4rnYDjYWzijhDPfNByNdum2nWuRkM6yg@mail.gmail.com>
References: <CAEW_RkvszGdnaR9Jtfp81fjcfh5j_LfVeZ-Y+QjEZy1r5+qAXA@mail.gmail.com>
	<CANPayMTAFFKRDds-Fcd3euGx9zQTDDB2R-+F5-VvoYWvQDSeKw@mail.gmail.com>
	<CAEW_RktJ0deALvGM0eZW==rKWhHd_EF_zpt2aZ=-s3uUQK3ycw@mail.gmail.com>
	<CANPayMQeKN2NVreySR4rnYDjYWzijhDPfNByNdum2nWuRkM6yg@mail.gmail.com>
Message-ID: <CAEW_RktrAsMuo7mdJT6iXwpU+pq3rWz5jhFJNx3pTb8Ac+GbSg@mail.gmail.com>

On 15 December 2011 00:12, Moritz Bunkus <moritz at bunkus.org> wrote:

>> [keep 'OpusHead' string in matroska]
> True enough, so let's just keep it.

Ok, sounds good.

> What I don't like is having a comment header in
> CodecPrivate as it circumvents Matroska's tagging system.

I'm fine with leaving the comment header out of CodecPrivate.

A more detailed question: how does the 'preskip' value in the header
interact with timestamps?

The idea with the pre-skip is that the decoder has exponentially
decaying filters, meaning if you feed a freshly allocated decoder
frames from the middle of a stream, after a seek for example, the
first few hundred milliseconds of output will be different than if the
decoder had been feed the previous audio frames.

The OpusHead 'pre-skip' field lets a muxer prepend extra data to help
the decoder converge before samples are output. For example, when
cropping a stream, a muxer can prepend ~500ms of data from before the
cut point, and then set the pre-skip field to 24000 samples, asking
the playback engine to discard those samples. This also allows
lossless sample-accurate cropping, since the pre-skip can indicate
playback start in the middle of a frame.

My question is, how do we timestamp those initial clusters, if some of
the samples from them are to be discarded? If playback starts with
e.g. sample 24000, what TimeStamp to I put on the first block? It
should really be negative, but the element takes an unsigned value.

 -r


From giles at thaumas.net  Fri Dec 16 20:41:40 2011
From: giles at thaumas.net (Ralph Giles)
Date: Fri, 16 Dec 2011 11:41:40 -0800
Subject: [Matroska-devel] Opus audio codec
In-Reply-To: <CAEW_RktrAsMuo7mdJT6iXwpU+pq3rWz5jhFJNx3pTb8Ac+GbSg@mail.gmail.com>
References: <CAEW_RkvszGdnaR9Jtfp81fjcfh5j_LfVeZ-Y+QjEZy1r5+qAXA@mail.gmail.com>
	<CANPayMTAFFKRDds-Fcd3euGx9zQTDDB2R-+F5-VvoYWvQDSeKw@mail.gmail.com>
	<CAEW_RktJ0deALvGM0eZW==rKWhHd_EF_zpt2aZ=-s3uUQK3ycw@mail.gmail.com>
	<CANPayMQeKN2NVreySR4rnYDjYWzijhDPfNByNdum2nWuRkM6yg@mail.gmail.com>
	<CAEW_RktrAsMuo7mdJT6iXwpU+pq3rWz5jhFJNx3pTb8Ac+GbSg@mail.gmail.com>
Message-ID: <CAEW_RkubZDQR2Hf26NB7GKky3gvs_mp4Vc2MmXAK=KnyjfbXYg@mail.gmail.com>

On 15 December 2011 13:41, Ralph Giles <giles at thaumas.net> wrote:

> My question is, how do we timestamp those initial clusters, if some of
> the samples from them are to be discarded? If playback starts with
> e.g. sample 24000, what TimeStamp to I put on the first block? It
> should really be negative, but the element takes an unsigned value.

It's been pointed out to me that while the Cluster>Timecode element is
unsigned, the per-block timestamp is a signed short. So we can make
the presentation time of the initial frames negative, up to about half
the range of the pre-skip header field (which is unsigned short).

I also noticed a TrackOffset element, which is a signed integer. Could
we use this to handle larger pre-skip?

Greg also raised the question of how we tell players to let the
decoder setting after a seek. Opus is a little like open-gop or
rolling-intra video codecs; after a certain time, the decoder will
always converge, but you don't necessarily get correct output if you
start presenting the output immediately after a seek.

How is that pre-roll requirement signaled for video?

 -r


From slhomme at matroska.org  Sat Dec 17 10:52:34 2011
From: slhomme at matroska.org (Steve Lhomme)
Date: Sat, 17 Dec 2011 10:52:34 +0100
Subject: [Matroska-devel] Opus audio codec
In-Reply-To: <CAEW_RkvszGdnaR9Jtfp81fjcfh5j_LfVeZ-Y+QjEZy1r5+qAXA@mail.gmail.com>
References: <CAEW_RkvszGdnaR9Jtfp81fjcfh5j_LfVeZ-Y+QjEZy1r5+qAXA@mail.gmail.com>
Message-ID: <4EEC6662.5000804@matroska.org>

Le 14/12/2011 21:27, Ralph Giles a ?crit :
> Hi,

Hello,

> I'm interested in adding support for the IETF Opus audio codec in Matroska.

Great.

> Significant features, from the container point of view:
>
> - Opus codes everything at 48 kHz
> - The decoder can generate either mono or stereo from any stream

I suppose that's for using mono when stereo separation is lost in 
compression (ie save bandwidth/quality). In that case it should be 
marked as having 2 channels. If a stream is known to only be mono, then 
it can have 1 channel.

> - Compressed frames are variable length, and the length of each frame
> must be signaled to the decoder
> - There's a 'multistream' extension for doing surround.
>
> Since there's little extra signalling necessary, a simple approach would be:
>
>    CodecID is V_OPUS
>    SamplingFrequency is always 48000
>    Channels is 1 or 2, based on what the muxer thinks is most
> appropriate. When in doubt, use 2?
>    CodecPrivate is void

Very good, a major improvement over Vorbis.

> That works great if you don't want more than two channels. The
> 'multistream' mode packs multiple mono/stereo streams into each frame,
> but requires the container signal the number of streams and how
> they're coupled. I can see two ways to make that work:
>
> 1) Define a new channel mapping element. The spec mentions a
> ChannelPositions element, but doesn't define the format for it.
> However we need more than just speaker positions. To decode
> multistream Opus we need to know, for each stream packed into the
> frames, whether to decode it as a coupled stereo pair (e.g.
> REAR_LEFT+REAR_RIGHT) or as an isolated mono channel (e.g. LFE) and
> how those map to the actual output channels.
>
> The multistream packing is designed so a single mono or coupled-stereo
> multistream frame is the same as a non-multistream frame, so for
> non-surround uses, this element can just be omitted.
>
> Pros: straightforward?
> Cons: probably not useful for other codecs
>
> 2) Copy the headers used in the Ogg encapsulation into CodecPrivate,
> similar to what is done for A_VORBIS and V_THEORA. This already
> defines a binary format for the channel mapping, along with a bunch of
> other things.
>
> Pros: Lossless transmux between Ogg and Matroska, possible code sharing
> Cons: more complex, codec specific code

Matroska has a channel mapping but it's mostly for codec that don't have 
an internal representation like raw PCM data. In the case of Opus I 
suppose the mapping is mostly fixed and the channel coupling is done 
accordingly. Also playback would not be correct if the playback didn't 
match what Opus uses internally. So I would put that channel mapping in 
the CodecPrivate at least (or in frames, depending how it works 
internally), not at the Matroska level. The decoder should be able to 
understand how Opus uses it.

Steve



From slhomme at matroska.org  Sat Dec 17 10:54:57 2011
From: slhomme at matroska.org (Steve Lhomme)
Date: Sat, 17 Dec 2011 10:54:57 +0100
Subject: [Matroska-devel] Opus audio codec
In-Reply-To: <CANPayMTAFFKRDds-Fcd3euGx9zQTDDB2R-+F5-VvoYWvQDSeKw@mail.gmail.com>
References: <CAEW_RkvszGdnaR9Jtfp81fjcfh5j_LfVeZ-Y+QjEZy1r5+qAXA@mail.gmail.com>
	<CANPayMTAFFKRDds-Fcd3euGx9zQTDDB2R-+F5-VvoYWvQDSeKw@mail.gmail.com>
Message-ID: <4EEC66F1.7070200@matroska.org>

Le 14/12/2011 22:11, Moritz Bunkus a ?crit :
> Hey,
>
> OK I've taken a look at Xiph's mapping of Opus in Ogg. The ID header
> they describe looks nearly fine to me: nothing that's too Ogg-centric
> apart from the "OpusHead" string. I'd rather skip this as a
> distinguishing feature between CodecPrivate and some other Matroska
> element is simply not necessary in Matroska (I'm referring to the part
> "The magic signature "OpusHead" allows codec identification and is
> human readable. Starting with 'Op' helps distinguish it from data
> packets, as this is an invalid TOC sequence." We also already have a
> human-readable CodecID for the first part.
>
> So what I'd propose would be your solution 2 (no new Matroska channel
> mapping element only for this codec) with a slight modification.
> CodecPrivate should consist of (copy&  paste from Xiph.org):
>
> - Version number (8 bits): zero for this spec
> - Channel count 'c' (8 bits unsigned): MUST be>  0
> - Pre-skip (16 bits unsigned)
> - Input sample rate (32 bits, little endian): informational only
> - Output gain (16 bits, little endian, signed Q7.8 in dB) to apply when decoding
> - Channel mapping family (8 bits)
>   --  0 = one stream, RTP order, 1 = channels in order as stated below,
> 2..254 reserved (treat as 255), 255 = no defined channel meaning
> If channel mapping family>  0
> - Stream count 'N' (8 bits unsigned): MUST be>  0
> - Two-channel stream count 'M' (8 bits unsigned): MUST satisfy M<= N,
> M+N<= 255
> - Channel mapping (8*c bits)
>    -- one stream index (8 bits unsigned) per channel (255 means silent
> throughout the file)

Sounds good to me.

Steve