Re: [rtcweb] Offer/answer for heterogeneous encode/decode

On 11/26/2013 11:07 PM, Derek Pang wrote:
> I am new to rtcweb community. Was there any proposal on making both
> Vp8 and H264 decoders MTI in webrtc, but VP8 or H264 encoder to be
> optional ? Does this offer a better option for the marketplace, while
> allowing interoperability.

I appreciate that the amount of reading you have to do in order to catch
up with the archives is enormous, but it is definitely a good thing to
do at this juncture.

This is alternative 12 on http://tools.ietf.org/wg/rtcweb/trac/wiki,
where the current alternatives that the chairs are considering proposing
a vote to choose between have been listed.

>
>
> On Sun, Nov 24, 2013 at 8:38 AM, Harald Alvestrand
> <harald@alvestrand.no <mailto:harald@alvestrand.no>> wrote:
>
>     On 11/23/2013 01:20 AM, Paul Giralt (pgiralt) wrote:
>
>         On Nov 22, 2013, at 7:06 PM, Martin Thomson
>         <martin.thomson@gmail.com <mailto:martin.thomson@gmail.com>>
>         wrote:
>
>             On 22 November 2013 15:44, Paul Giralt (pgiralt)
>             <pgiralt@cisco.com <mailto:pgiralt@cisco.com>> wrote:
>
>                 While you’re right that it would work for this
>                 scenario, my point was really
>                 that Offer/Answer is not really asymmetric as implied
>                 earlier. Take for
>                 example the hypothetical case where you are only able
>                 to decode VP8 but only
>                 able to encode H.264. If I offer VP8 as my only codec
>                 (because it’s the only
>                 thing I’m able to decode therefore I never want anyone
>                 to send me anything
>                 other than VP8) I cannot send H.264 in the offer
>                 because that implies I’m
>                 able to decode it. The other side then wants to say it
>                 can only receive
>                 H.264 so it would have to send back an answer with
>                 only H.264. I guess
>                 there’s nothing really inherently stopping you from
>                 doing this because as
>                 far as I can tell, 3264 only says the answer has to be
>                 a subset of the offer
>                 for multicast streams, however how would the answering
>                 side know that the
>                 offering side is even capable to receiving H.264?
>                 Perhaps Offer/Answer can
>                 technically be asymmetric, but it doesn’t seem
>                 practical to use it this way
>                 because you cannot really indicate your send and
>                 receive capabilities
>                 independent of each other.
>
>             Judicious application of a=sendonly or a=recvonly avoids
>             this issue.
>             If you want to send H.264, try a=sendonly on a line with
>             H.264.  If
>             you want to receive VP8, try a=recvonly on a line with VP8.
>
>         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.
>
>
>     An application that can't talk to itself is kind of bizarre too.
>
>     I think this is a corner case.
>
>
>     _______________________________________________
>     rtcweb mailing list
>     rtcweb@ietf.org <mailto:rtcweb@ietf.org>
>     https://www.ietf.org/mailman/listinfo/rtcweb
>
>

-- 
Surveillance is pervasive. Go Dark.