Re: Transport related API need

On 2013-08-12 02:57, Roman Shpount wrote:
> On Sat, Aug 10, 2013 at 8:38 AM, Stefan Håkansson LK
> <stefan.lk.hakansson@ericsson.com
> <mailto:stefan.lk.hakansson@ericsson.com>> wrote:
>
>     On 2013-08-08 19:31, Roman Shpount wrote:
>      > I should be able to specify which codecs are present and their codec
>      > preference order (I want H.264 if supported by the browser instead of
>      > VP8, if I know that remote party supports both but will need to
>      > transcode VP8).
>
>     In my ignorance, I thought SDP O/A did sort out which codec to use
>     really well. Isn't this handled by the other endpoint, in a response,
>     only says H.264, or puts H.264 before VP8 (if both were offered)?
>
>
> An example would be browser which implements both VP8 and H.264 and
> remote party which implements both codecs, but it is known to have much
> better quality for one vs another. If the offer lists VP8 first,
> answering party, if it follows RFC3264, it should pick VP8. If
> application wants to control, codec order will need to be changed.
>
>      > This should also include ability to specify the same
>      > codec multiple times with different parameters (for instance iLBC
>     with
>      > two different payloads for mode=20 and mode=30).
>
>     What parameters do you have in mind? And what use case are solved? And I
>     assume that you can only have one set of parameters for one
>     MediaStreamTrack (to be sent).
>
>
> What I am talking about is exactly the example I have  provided. If
> browser implements iLBC codec, it would most likely need to list iLBC
> codec twice, one with with codec format parameter mode=20 and another
> with format parameter mode=30. Here is an example:
>
> m=audio 49120 RTP/AVP 97 98
> a=rtpmap:97 iLBC/8000/1
> a=rtpmap:98 iLBC/8000/1
> a=fmtp:97 mode=20
> a=fmtp:98 mode=30

I haven't followed that discussion, so I don't understand why. Is this 
something specific to iLBC? And what is the use case.

>
>
>      > I should be able to control ptime and maxptime (including getting
>     rid of
>      > ptime all together) per m-line.
>
>     Could this (from an application point of view) be expressed in terms
>     like "low delay"?
>
>
>   In cases where I would want to save bandwidth at the expense of delay,
> I would set a higher ptime. If I prefer lower delay at the expense of
> higher bandwidth, I will set lower ptime.
>
> P.S. I have mentioned this before, but if needed I will come up with a
> use for every single setting in SDP.

Of course, but just as we're doing in the Media Capture TF regarding 
Constraints for MediaStreamTracks I see us distilling out the most 
important ones. The the more exotic ones would in my thinking (given 
that we keep SDP) still require SDP mangling.


> So I would think that spending time
> creating a set of constraints to modify SDP is complete waste of time.
> This time would be much better spent creating a normal API.
> _____________
> Roman Shpount

Received on Monday, 12 August 2013 06:39:17 UTC