Subject: [MMUSIC] Incoming liaison statement from MMUSIC

From: Stephan Wenger <[email-masked]>
Date: Wed, 07 Dec 2011 08:08:40 -0800

Hi all,
mmusic has received an incoming liaison from MPEG, indicating that they have
started on "codec independent media description code points".  My
understanding of this work is that these code points may be represented in
SDP.
My personal viewpoint is that this may well be sound architectural work, but
it may be better conducted here in mmusic, at least when it comes to SDP
representations and the related IANA work.  However, I know nothing about
this work beyond what's written in the statement, which is why I used "soft"
language.  Perhaps some of you can shed light into what's really going on.
The assorted avt WGs are probably also affected, as some of the proposed
code points sound like they are being described in payload formats, RTP
extensions and perhaps even in xrblock.  Let me suggest to use only the
music list for discussions, as only mmusic is being addressed in the
statement.
As it is short, I have attached the statement in word format to this email.
It will also appear shortly in the IETF liaison database.
Regards,
Stephan

---

From: David Singer <[email-masked]>
Date: Wed, 07 Dec 2011 09:29:20 -0800

Hi Stephan

I can explain a bit.  We noticed in systems work at MPEG two things
a) we wanted to say something about the signal that was being compressed (audio or video) that was nothing to do with the compression, and we ended up having to 'pick' a codec document and point at it, because the codes we wanted were always documented with codecs.
b) the codes are also copied from spec. to spec. in many cases (so they happen to have values having the same meanings); in a few cases, each codec has 'invented its own' and the codes needlessly differ from spec. to spec.

Examples: the 'classic three' values used to describe video color: color_primaries, transfer_characteristics, matrix_coefficients.  These are copied from spec. to spec., with the more recent specs having more values. Recently there was a mistake noticed in an equation, and I think it had to be corrected in several places.  Another example is 'frame packing' (stereo packed into a mono video stream); the specs actually don't always align on the definitions here.

The variation of semantics for some points could be a problem; different values for the same semantics is a nuisance, e.g. when wanting to be codec-independent or when transcoding. Different numbers of values for the same code in different specs is a nuisance, and raises questions, and so on.

The basic idea is to collect a whole bunch of these, document them in one place, and remove the definitions from a whole bunch of specs.  So, for example, in a video spec. one might be able to say "this 8-bit field carries a color_primaries value as defined in [[this new spec]]; if absent, the default value is 23".  Correspondingly, in say SDP, one might be able to say "if this field is 0, the video is mono; otherwise, it carries a frame_packing values as defined in [[this new spec]]".

Makes sense?

On Dec 7, 2011, at 8:08 , Stephan Wenger wrote:

> Hi all,
> mmusic has received an incoming liaison from MPEG, indicating that they have started on "codec independent media description code points".  My understanding of this work is that these code points may be represented in SDP.
> My personal viewpoint is that this may well be sound architectural work, but it may be better conducted here in mmusic, at least when it comes to SDP representations and the related IANA work.  However, I know nothing about this work beyond what's written in the statement, which is why I used "soft" language.  Perhaps some of you can shed light into what's really going on.
> The assorted avt WGs are probably also affected, as some of the proposed code points sound like they are being described in payload formats, RTP extensions and perhaps even in xrblock.  Let me suggest to use only the music list for discussions, as only mmusic is being addressed in the statement.
> As it is short, I have attached the statement in word format to this email.  It will also appear shortly in the IETF liaison database.
> Regards,
> Stephan
> <29n124561.doc>_______________________________________________
> Audio/Video Transport Core Maintenance
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt

David Singer
Multimedia and Software Standards, Apple Inc.