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

Re: Transport related API need

From: Roman Shpount <roman@telurix.com>
Date: Sun, 11 Aug 2013 20:57:22 -0400
Message-ID: <CAD5OKxu4H2os068kMScTOc33K+abBxrTVGROB5J6K-Xkt5O9mg@mail.gmail.com>
To: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
Cc: "public-webrtc@w3.org" <public-webrtc@w3.org>
On Sat, Aug 10, 2013 at 8:38 AM, Stefan Håkansson LK <
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 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. 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 00:57:52 UTC

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