Re: [AVT] AVT Charter update

[Colin Perkins <[e-mail]>]

Michael,

On Tuesday, Sep 2, 2003, at 15:17 Europe/London, Michael A. Ramalho 
wrote:
...
> My question regards the RGL freeware codec (see www.vovida.org or 
> draft-ramalho-rgl-desc-01.txt).
>
> As the AVT chairs know, RGL is really a LOSSLESS COMPRESSION technique 
> (which I
> now wished that I named "RGL compression" instead of "RGL codec"). RGL 
> performs NO
> SIGNAL PROCESSING on the underlying G.711 PCM frame provided as input 
> to it.
>
> Therefore the rationale provided in the proposed AVT Charter for not 
> codifying "new codecs" does not apply:
>
> "The group continues to be precluded from work on codecs themselves 
> because of overlap with the other standards bodies, and because the 
> IETF does not have the ability to effectively review new codecs."
>
> As AVT specifies other compression techniques (e.g., Compressed RTP 
> framework), the
> necessary expertise to review RGL clearly exists in AVT.
>
> Questions:
> Could RGL be explicitly included? Should I re-name RGL to "RGL 
> compression"?
> Could the Charter specifically include compression techniques on codec 
> output
> frames themselves (as RGL does for G.711)?

It is appropriate for AVT to work on the payload format for RGL, and to 
provide advice on aspects of the codec design which might impact 
performance with RTP and UDP/IP. The compression algorithm is outside 
our scope, and we will not accept that work.

Other organisations have experience in audio/visual compression 
algorithms, and we feel it more appropriate that codec work occur 
there. If, however, you consider it important that the IETF has a codec 
design activity, you should consider raising the issue with the 
Applications Area Directors, as a potential new working group.

> [As you know, other lossy codecs will normally attempt to remove 
> payload redundancy
> and render the resulting lossy codec output relatively random ... so 
> this issue is moot for iLBC, BV8, G.729, etc.]
>
> Lastly, I note that it is a reasonable expectation that other 
> "lossless payload compression" techniques may use similar techniques. 
> For example:
>
> 1 - streaming of real-time MRI images - where the medical 
> professionals want "lossless" frames or "no" image frames (you don't 
> want to diagnose off of a lossy compression created artifact), or
>
> 2 - satellite imaging from outer space probes where you desire 
> lossless compression
> (one of Professor Rice's - of Rice coding fame - initial applications).
>
> [One could argue traditional IETF reliable transports for 1, but not 
> for 2].

In both these examples, I would regard the compression as being outside 
the scope of AVT. Again, we would be happy to provide advice on the 
properties of the compression and on appropriate strategies for mapping 
such data onto RTP, but we would leave the definition of the 
compression to the domain experts.

-- 
Colin Perkins
http://csperkins.org/


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