Re: [rtcweb] Asymmetric codecs

[Justin Uberti <[e-mail]>]

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]> 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] <[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] <[e-mail]>]
>
> *Sent:* 25. marraskuuta 2013 4:11
> *To:* Christer Holmberg; Martin Thomson; Paul Giralt (pgiralt)
> *Cc:* [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]>
> 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.
>
>
>
>
>
>
>  _______________________________________________
>
> rtcweb mailing list
>
> [e-mail]
>
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>
>
>
>
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>