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

Re: Transport related API need

From: Wolfgang Beck <wolfgang.beck01@googlemail.com>
Date: Sat, 10 Aug 2013 19:22:17 +0200
Message-ID: <520676C9.7070207@googlemail.com>
To: public-webrtc@w3.org
On 08/10/13 14:38, Stefan Håkansson LK 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)?
RfC 3264:
    Although the answerer MAY list the formats in their desired order of
    preference, it is RECOMMENDED that unless there is a specific reason,
    the answerer list formats in the same relative order they were
    present in the offer.  In other words, if a stream in the offer lists
    audio codecs 8, 22 and 48, in that order, and the answerer only
    supports codecs 8 and 48, it is RECOMMENDED that, if the answerer has
    no reason to change it, the ordering of codecs in the answer be 8,
    48, and not 48, 8.  This helps assure that the same codec is used in
    both

So if you want to control the codec choice, you have to mangle SDP. At 
least on the offerer side.

> 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).
>
>>
>> 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"?

If we really want to pursue the 'tickle the captain to steer the ship' 
way of doing things, I'd like to have an API that tells me the outcome 
of my highlevel constraints. Like, the estimated bandwidth and 
serialization/coding delay of the connection described by my 
constraints, before the RTP stream has started.

Just like I can query the width of a DOM element that the browser has 
formatted for me.

--
Wolfgang Beck
Received on Saturday, 10 August 2013 17:22:52 UTC

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