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:mzanaty@cisco.com]
> *Sent:* 25. marraskuuta 2013 4:11
> *To:* Christer Holmberg; Martin Thomson; Paul Giralt (pgiralt)
> *Cc:* rtcweb@ietf.org
> *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 
> <christer.holmberg@ericsson.com 
> <mailto:christer.holmberg@ericsson.com>> 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) <pgiralt@cisco.com 
> <mailto:pgiralt@cisco.com>> 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 <martin.thomson@gmail.com 
> <mailto:martin.thomson@gmail.com>> wrote:
>
> The bidirectional thing in O/A is the strange way to do things.  Two 
> lines is pretty intuitive.
>
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb