Re: [rtcweb] Asymmetric codecs

[Basil Mohamed Gohar <[e-mail]>]

On 11/25/2013 11:13 AM, Mo Zanaty (mzanaty) wrote:
> Re: MTI, I don’t think asymmetric codecs will solve all the MTI issues.
> However, it may solve some practical deployment issues regardless of MTI
> decisions. If products have a decoder but no encoder, it may help to
> express that. For example, Chrome can expose its H.264 decoder for
> webrtc despite no encoder. Hardware products can expose their VP8
> decoder for webrtc despite no encoder.
> 
> Re: SDP, if you want asymmetric codecs over the same port, is it ok to
> mandate bundle to achieve this? I started with a single sendrecv m-line
> with all payload types that can be decoded but not necessarily encoded,
> as Justin suggested. That would not require bundle. However, it gets
> ugly when adding extra signaling for which payload types can’t be
> encoded and multiple O/A rounds for interop with arbitrary peers. The
> complexity approached bundle, so I ended up with separate
> sendonly/recvonly m-lines, as Martin suggested.

For what it's worth, if it doesn't muddy things up, having *support* for
a different codec being sent from both sides, doesn't sound like a
terribly bad idea.  Maybe a lower-end device, say, a watch or something,
can encode to a simpler codec but decode a more advanced one.  However,
this should be weighed on its own merits, and really shouldn't factor in
at all to the MTI discussion in my opinion.
-- 
Libre Video
http://librevideo.org