Re: [MMUSIC] [clue] Incoming liaison statement from MPEG

Thomas Stockhammer <stockhammer@nomor.de> Fri, 01 June 2012 19:12 UTC

Return-Path: <stockhammer@nomor.de>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1659311E80A0; Fri, 1 Jun 2012 12:12:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LZMjwAydT3v6; Fri, 1 Jun 2012 12:12:10 -0700 (PDT)
Received: from mo6-p00-ob.rzone.de (mo6-p00-ob.rzone.de [IPv6:2a01:238:20a:202:5300::1]) by ietfa.amsl.com (Postfix) with ESMTP id 18C8E11E80A3; Fri, 1 Jun 2012 12:12:09 -0700 (PDT)
X-RZG-AUTH: :P3gLdkugevKirJkjH/RoTtk5THWq6nlFgKpnuMPeiu1/8loZf+4JHTB1Fvz/6Kg9
X-RZG-CLASS-ID: mo00
Received: from [192.168.1.14] (188-192-153-251-dynip.superkabel.de [188.192.153.251]) by smtp.strato.de (jorabe mo54) (RZmta 29.10 DYNA|AUTH) with ESMTPA id N05b47o51H6usr ; Fri, 1 Jun 2012 21:12:05 +0200 (CEST)
Mime-Version: 1.0 (Apple Message framework v1278)
Content-Type: multipart/alternative; boundary="Apple-Mail=_E2C8A1A9-2ABC-4340-A679-78E5A7240025"
From: Thomas Stockhammer <stockhammer@nomor.de>
In-Reply-To: <CBEE45B1.87915%stewe@stewe.org>
Date: Fri, 01 Jun 2012 21:12:04 +0200
Message-Id: <533FED60-A1DC-4E26-B487-5A90EDDEA163@nomor.de>
References: <CBEE45B1.87915%stewe@stewe.org>
To: Stephan Wenger <stewe@stewe.org>
X-Mailer: Apple Mail (2.1278)
Cc: "clue@ietf.org" <clue@ietf.org>, "mmusic@ietf.org" <mmusic@ietf.org>
Subject: Re: [MMUSIC] [clue] Incoming liaison statement from MPEG
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 01 Jun 2012 19:12:12 -0000

Stephan, all,

a bit more background.

MPEG is NOT defining the mapping of the code points to any specific syntax, such as XML or SDP or a bitstream format. However, it provides common code points (generally unsigned integers) and common definitions of the code points.

One of the relevant code points for IETF SDP are the frame-compatible video formats such as SbS or TaB. Others may relate to audio properties such as the number and configuration of audio channels.

One of the main motivations is to avoid copying such code points from one specification to the next as it happens today for example in video coding standards. 

The IETF is encouraged to support the unification of such code points and by providing input to MPEG and by using references to the MPEG specification in IETF documents.

Thomas

On Jun 1, 2012, at 7:17 PM, Stephan Wenger wrote:

> Hi Roni,
> The statement was sitting in my inbox for a few days, and I have forwarded it to the secretariat for posting only this morning.  Therefore, it is not yet on the tracker, but should be on the tracker sometime soon.
> Color primaries, as one example, can actually being sent in SDP today, as part of the VUI in the sequence parameter set of H.264.  And, color primaries are an interoperability point, at least for high quality applications (such as video contribution).  If your receiving box does not understand, or cannot meaningfully process color primaries as sent, then you may get a picture but it will look odd…  There is also other stuff in the MPEG doc that is even more needed for interoperability; for example, association of audio channels inside the codec bitstream with a speaker location.
> The key point of the MPEG doc is that they are out farming generic codec things from the audio/video specs into this MPEG-A format, and we (as we are not using MPEG-A) will probably have to find a way to either encapsulate MPEG-A XML for cap exchange, or translate the code points to SDP-ish things.
> Stephan
> 
> 
> 
> 
> From: Roni Even <ron.even.tlv@gmail.com>
> Date: Friday, 1 June, 2012 10:00 
> To: Stephan Wenger <stewe@stewe.org>, "mmusic@ietf.org" <mmusic@ietf.org>, "clue@ietf.org" <clue@ietf.org>
> Subject: RE: [clue] Incoming liaison statement from MPEG
> 
> Stephan,
> I did not see the liaison statement yet in MMUSIC, so I hope it will be available in time for us to review.
> From the example of color primaries I am not sure why we need to have this in SDP. if this is something that is sent as part of the payload do we need to send it also in SDP?
>  
> Roni
>  
> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Stephan Wenger
> Sent: Friday, June 01, 2012 7:29 PM
> To: mmusic@ietf.org; clue@ietf.org
> Subject: [clue] Incoming liaison statement from MPEG
>  
> Hi all,
> MPEG is working towards codec independent code points, and has sent to MMUSIC a liaison statement asking for our input.  Especially the audio stuff may also be relevant to CLUE, so I copy CLUE here as well.  No deadline is provided, but I note that MPEG meets two weeks before the Vancouver IETF meeting and the text they sent us is already a CD, so our time to influence their decisions (if we choose to do so) is limited.
> MPEG has observed that many code points relevant for audio and video are generic in the sense that they can be applicable to many video or audio codecs.  Recent MPEG (and joint MPEG/ITU) video coding standards have occasionally copy-pasted whole sections of code points concerning things like color primaries.  They want to avoid this in the future.  So they farm out stuff that is historically located in video/audio codec specs, but are likely to be common between different codecs.
> My hunch is that the code point in their draft standard could be translated to SDP-ish syntax.  At this point, it is XML-ish.
> Stephan
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic

---
Dr. Thomas Stockhammer (CEO) || stockhammer@nomor.de || phone +49 89 978980 02 || cell +491725702667 || http://www.nomor-research.com
Nomor Research GmbH  -  Sitz der Gesellschaft: München - Registergericht: München, HRB 165856 – Umsatzsteuer-ID: DE238047637 - Geschäftsführer: Dr. Thomas Stockhammer, Dr. Ingo Viering.