W3C home > Mailing lists > Public > public-webrtc@w3.org > August 2013

Re: Transport related API need

From: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
Date: Mon, 12 Aug 2013 06:38:53 +0000
To: Roman Shpount <roman@telurix.com>
CC: "public-webrtc@w3.org" <public-webrtc@w3.org>
Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B1C35CCDA@ESESSMB209.ericsson.se>
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

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:35 UTC