Re: Proposal for a way to set the send codec on an RtpSender.

In our specific case, there were three main use cases that resulted in
interest for that:
- some users wanted to connect through to a (264 based) VoIP
infrastructure, and wanted to avoid transcoding as much as possible, while
still supporting VP8.
- some non-browser clients (drones, ipcamera, and plugin mainly) would also
have 264 and VP8 capacity, but would prefer to go for H264 in some very
specific cases (support for HW encoding/decoding, ...)
- mobile would avoid opus if not powerful enough, or even chose the best
codec depending on the hardware it is being run on.

the problem comes more from the different flavors of H264 met. Firefox,
last time we tested had mode 0 and mode 1, with some specific parameters
that needed to appear in the SDP for it to work (
level_asymmetry_allowed, packetization_mode, profile_level_id), with
hardcoded values (0x42e01f), and some specific codec number mapping. You
can end up with two h264 entries in your rtpmap mapping to different
parameters set / mode for 264. So just offering a codec, or a codec order
would not be enough, you have t check the associated parameters, and make
an educated choice.

Firefox is the only browser supporting both today, so I will take it as an
example, however, I do think it will apply at one point when most browser
propose multiple codecs, and possibly, multiple variations around a given
codec (how many temporal layers for VP9 SVC ...). If Firefox starts the
negotiation, by default (unless you change a magic flag) VP8 is going to be
proposed first, and then, optionally, two versions of h264 will be
proposed. If you have a client that supports both VP8 and 264, but would
prefer 264, you are still supposed to honor the order of the offer. If
you're working from a browser, you will honor the order unless you manually
modify the SDP. It is not documented, it can and will change from one
version of the browser to the next (or even a subversion when one realize
it is not compatible with cisco own client), ....

At one point we had a version of chrome modified to support H264 in webrtc
as a milestone in porting firefox's H264-enabled webrtc to the temasys
plugin. Once we passed the packetized / fragmenter problems, and the NALU
parsing issues, we were surprised to find how difficult it was to test it
without mangling the SDP.

If there were a more structured way to deal with this, it would be great
and I see what peter proposed as exactly what I need to make my life easier
:-)

Alex.


On Sat, Aug 1, 2015 at 7:22 AM, Adam Roach <adam@nostrum.com> wrote:

> On 7/31/15 17:01, Alexandre GOUAILLARD wrote:
>
>> I confirm there is a lot of interest in being able to do this without
>> touching the SDP.
>>
>
> I'm not saying it's wrong for an application to want to be able to tweak
> codec preferences, but I'm curious about the reasons developers have for
> wanting this. Do you have any insight here?
>
> /a
>



-- 
Alex. Gouaillard, PhD, PhD, MBA
------------------------------------------------------------------------------------
CTO - Temasys Communications, S'pore / Mountain View
President - CoSMo Software, Cambridge, MA
------------------------------------------------------------------------------------
sg.linkedin.com/agouaillard

   -