Re: [rtcweb] Asymmetric codecs

[cowwoc <[e-mail]>]

<cough> told you so <cough> :)

So folks, what happens when we try removing any mention of SDP from the 
2.0 spec? :) Are you saying this is no longer possible?

Gili

On 25/11/2013 2:43 AM, Christer Holmberg wrote:
>
> Hi,
>
> I'm afraid that SDP has become is a little more than an implementation 
> detail :)
>
> Regards,
>
> Christer
>
> *From:*rtcweb [mailto:[e-mail]] *On Behalf Of *cowwoc
> *Sent:* 25. marraskuuta 2013 9:35
> *To:* [e-mail]
> *Subject:* Re: [rtcweb] Asymmetric codecs
>
>
> SDP is supposed to be an implementation detail. Let's figure out 
> whether asymmetric codecs solve our problems and wedge it into SDP later.
>
> I suspect that this approach reduces the IPR risk, but H.264 royalties 
> still apply, do they not?
>
> Sadly this means we're stuck with: "MUST decode at least two of [VP8, 
> H.264, H.261] and MUST encode at least one of them".
>
> Gili
>
> On 25/11/2013 2:24 AM, Christer Holmberg wrote:
>
>     Hi,
>
>     First, from a pure MTI codec perspective, the question is whether
>     usage of asymmetric codecs would solve the issues that people have.
>
>     Second, from an SDP OA/BUNDLE perspective, I don't think we can
>     mandate *usage* of BUNDLE. And, even if we did, in the initial
>     Offer you still need to assign unique port values for each m- line
>     (as agreed in Vancouver).
>
>     ...unless, of course, you assign an SDP 'bundle-only' attribute to
>     all m- lines with asymmetric codecs.
>
>     Regards,
>
>     Christer
>
>     *From:*Mo Zanaty (mzanaty) [mailto:[e-mail]]
>     *Sent:* 25. marraskuuta 2013 4:11
>     *To:* Christer Holmberg; Martin Thomson; Paul Giralt (pgiralt)
>     *Cc:* [e-mail] <mailto:[e-mail]>
>     *Subject:* Asymmetric codecs
>
>     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.)
>
>     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]
>     <mailto:[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] <mailto:[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]
>     <mailto:[e-mail]>> wrote:
>
>     The bidirectional thing in O/A is the strange way to do things.
>      Two lines is pretty intuitive.
>
>
>
>
>     _______________________________________________
>
>     rtcweb mailing list
>
>     [e-mail]  <mailto:[e-mail]>
>
>     https://www.ietf.org/mailman/listinfo/rtcweb
>