Re: [rtcweb] Asymmetric codecs

[Stefan Håkansson LK <[e-mail]>]

On 2013-11-25 03:11, Mo Zanaty (mzanaty) wrote:
> I started a draft on how to standardize support for asymmetric codecs
> back in September. The primary motivation was decoding H.264 and H.265
> while only encoding H.264. A secondary motivation, for rtcweb, was
> decoding H.264 and VP8 while only encoding one of them, as Stefan
> mentioned. I thought it would be a trivial thing to write up by the Oct.
> 6 deadline for MTI proposals. The draft is still incomplete and
> unpublished because all solutions are ugly and overly complex for
> something so seemingly trivial, just like bundle and unified plan. I now
> sympathize with Christer and Adam for how they arrived at those (not
> exactly elegant) solutions, and agree with Martin that a pair of
> (bundled) m-lines is the most viable (although not exactly elegant)
> solution for asymmetric codecs.
>
> RFC 4317 drafts originally included asymmetric codecs until they were
> removed in draft 02:
> http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-mmusic-offer-answer-examples-02.txt
>
> They were removed for fear of issues with shared ports:
> http://www.ietf.org/mail-archive/text/mmusic/2003-09.mail
>
> Now that we (almost) have bundle, can we resurrect asymmetric codecs
> with separate sendonly and recvonly m-lines? Are folks ok with a
> dependency on bundle? I would be happy to complete a draft in that
> direction. (That is, a general mmusic draft on asymmetric codecs, not a
> rtcweb draft on MTI asymmetric codecs. I will move the discussion to
> mmusic after getting rtcweb opinions first.)

I've in the past been arguing that the WebRTC API, which is geared 
towards sending tracks, fits best with separate m-lines per direction. 
So I'm all for this (naturally the browser must be able to understand a 
sendrecv m-line if some legacy equipment signals that).

I'm not sure what you mean by the dependency on bundle. Do you mean that 
if bundle is not used the result would be that twice the number of ports 
would be needed for a symmetrical session?

>
> Some may consider this a bizarre corner case. However, for hardware
> codecs, it is the norm not the exception to have asymmetric encoder and
> decoder formats. Especially for new formats, which usually appear in
> hardware decoders well before hardware encoders are available. This
> happened for H.264, H.265, VP8, and virtually every popular codec format
> in virtually every popular chipset.
>
> Mo
>
> On 11/23/13, 9:09 AM, Christer Holmberg <[e-mail]>
> wrote:
> Like some others, I think the must-decode-both-must-endcode-one
> alternative as such sounds interesting (whether it has any impact on the
> licence/IPR issues I'll leave to others to speak for). However, I have
> big concerns over the proposal to indicate sendrecv for a codec even if
> an entity is only able to receive/decode it. … Usage of unidirectional,
> sendonly/recvonly, m- line would of course solve this, and you might
> know that it is one option we are discussing in CLUE (for other reasons
> than MTI codec, though).
> On 22 November 2013 16:20, Paul Giralt (pgiralt) <[e-mail]> wrote:
> I gave this as an example of a possible way to do it, but that means you
> need two separate m= lines - one for send and one for receive. Seems
> strange to do this for something that you really want to be a single
> bi-directional stream.
>
> On 11/22/13, 8:03 PM, Martin Thomson <[e-mail]> wrote:
> The bidirectional thing in O/A is the strange way to do things.  Two
> lines is pretty intuitive.
>