Subject: RE: [AVT] I-D ACTION:draft-ietf-avt-rtp-hdrext-03.txt

From: "Even, Roni" <[email-masked]>
Date: Thu, 20 Jul 2006 10:14:04 +0300

Hi,
I still am not convinced. All the examples are for proprietary
extensions. 

I can think of a different solution of defining a payload type for
generic data and multiplexing it with the standard stream (like your
second example). A receiver who will not support this payload type will
still can receive the main payload type. 

Roni Even

> -----Original Message-----
> From: lazzaro [mailto:[email-masked]]
> Sent: Wednesday, July 19, 2006 8:10 PM
> To: [email-masked]
> Cc: lazzaro
> Subject: RE: [AVT] I-D ACTION:draft-ietf-avt-rtp-hdrext-03.txt
> 
> 
> On Jul 19, 2006, at 7:01 AM, Roni Even wrote:
> >
> > I saw your answer and re-read the text in the draft. I am a bit
> > worried
> > about this approach. Since you define here extension mechanism that
> > has
> > semantics that should be known between heterogeneous
> > implementations and
> > could be negotiated yet it is not clear how developer will know the
> > meaning of theses header extensions. I would prefer to see those as
> > RFCs.
> 
> 
> If an application doesn't know the meaning of the header extension,
> it would want to negotiate to not receive it, I would think.  That one
> piece of information -- here is the name of the extension, which you
> can use to figure out if you are aware of the extension or not -- is
> enough.
> 
> ---
> 
> There is a track record of this sort of extension philosophy
(extensions
> with a known syntax but potentially unknown semantics, apart from
> fields that let one skip over it) working well in media standards.
> Two examples:
> 
> [1] MIDI System Exclusive messages.  Manufacturers define them,
> and are encouraged to document them in their product manuals, but
> do not register them with the MMA.
> 
> [2] AIFF and WAV metadata chunks.  Manufacturers with special
> metadata needs for audio can use these chunks to annotate the
> audio in a file, while keeping basic file compatibility with the huge
> base of programs that read and write AIFF and WAV.
> 
> In both of these cases, if the old standards didn't have ways to allow
> the creation of new time-lined metadata (which is what these
extensions
> really are) without interaction with a standards process,
manufacturers
> with a new idea that required new metadata to work would have broken
> compatibility and defined a new media format.
> 
> Indeed, in the case of AIFF/WAV, we've reached the point where the
> built-in flexibility isn't enough, and we've seen new files formats
> like CAF
> files from Apple that make a clean break with AIFF and WAV.  I think
we
> need to maintain a pragmatic mindset to safeguard RTP from this
outcome,
> which is why I've been chiming in in favor of hdrext so often ...
> 
> ---
> John Lazzaro
> http://www.cs.berkeley.edu/~lazzaro
> lazzaro [at] cs [dot] berkeley [dot] edu
> ---
> 
> 
> 
> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/avt

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: lazzaro <[email-masked]>
Date: Thu, 20 Jul 2006 10:46:01 -0700

> I still am not convinced. All the examples are for proprietary

In the MMA and AIFF/WAV world's, today's proprietary extensions
often become (1) tomorrow's MMA-standardized extensions, or
(2) new de-facto standards everyone reverse engineers and supports.

Examples:

[1] Logic Control (a protocol for a mixing desk to control a digital
audio workstation (DAW)) implemented the control protocol layered on
top of MIDI, using a mix of SysEx extensions and a remapping
of some standard MIDI commands.  Originally it was proprietary
to Emagic (who wrote the DAW named Logic) and Mackie (who
designed the first Logic Control console).  Logic Control was so
proprietary the console initialization included cryptographic handshake
to prevent interoperability.

Times changed, Apple bought Emagic, now the Logic Control
Protocol is documented by Apple, and many DAWs and many
hardware manufacturers support it.

If there wasn't a way to do SysEx commands in MIDI, Logic
and Emagic probably would have abandoned MIDI for
their controller project, and DAW console control standardization
would have taken more years to converge to stability.

[2] Sonic Foundry's ACID program was the first program that
let users make music by time-stretching and pitch-shifting
audio files as loops.  It's file format for loops were WAV files
that used the metadata to encode the time-stretch and pitch-shift
hints.  By using WAV files, it let users use their favorite audio
editors for making the WAV files -- these programs know to
preserve WAV metadata they don't understand on input and
output.  Once ACID was successful, other programs came
on line, and they were able to "import" ACIDized WAV file
libraries because the were legal wavefiles (some competitors
reversed engineered the hints, other competitors just replaced
them with their own hinting systems).  And so, at the beginning
ACID benefited from extending WAV (program editor support
came for free) and later on competitors did (ACID users did not have
to throw away expensive content libraries in order to switch).

So, there's historical evidence that a heathy ecosystem can
be based on this type of extension philosophy.

> still can receive the main payload type.

And a receiver who doesn't support a header extension can simply
skip past it, or negotiate not to receive it.  If an extension is adding
5 or 10 octets per packet, the overheads of sending a separate stream --
in a bandwidth sense, a port sense, a sender and receiver overhead
sense -- is significant.

---
John Lazzaro