Re: [rtcweb] Asymmetric codecs

[cowwoc <[e-mail]>]

Okay, glad to hear it :)

Thanks,
Gili

On 25/11/2013 3:21 PM, Justin Uberti wrote:
> SDP is just a serialization format, a clumsy yet somehow popular one.
>
> Nothing we decide here on codecs will impose any mandate on what 
> serialization format is used in WebRTC 2.0.
>
>
> On Mon, Nov 25, 2013 at 9:26 AM, cowwoc <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>
>     <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] <mailto:[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
>>
>
>
>     _______________________________________________
>     rtcweb mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/rtcweb
>
>