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

On 8/1/2015 6:32 AM, Alexandre GOUAILLARD wrote:
> 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.

Ok, in that case (in the infrastructure) offer H.264 first, and when 
answering a call from the browser, select H.264 if available.  If you 
don't control the infrastructure, but do control the browser, you may in 
fact want to control the order of codecs in the offer (or codec to 
answer with).

> - 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, ...)

Well again the endpoint with this requirement can select that, instead 
of requiring the browser+app to somehow know what the other side would 
work better with (of course, since clients are fairly tightly tied to 
their services now, some of these old-style telecom concerns about "How 
should I know" in interop cases fall away, though not all of them).

> - mobile would avoid opus if not powerful enough, or even chose the 
> best codec depending on the hardware it is being run on.

Perhaps, though those aren't the normal cases.

> 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.

Of course that's normal for H.264, I'm afraid.  Mode 1 is generally 
preferred, and Mode 0 is required for interop in a few odd cases and by 
the spec.  And you can have more variants (such as if the other side 
supports >baseline).  However, in most cases a payload preference/order 
will cover the need.  (Of course, one needs to know which one to prefer.)

Note: Exposing all this to the application and throwing up our hands and 
saying "not our problem" really doesn't help anything - applications 
will generally have even less idea how to deal with this, and most who 
try to would likely make mis-steps.  This is one of my concerns with 
some aspects of ORTC; much like the old proposals to simply make a 
UDP-like single datachannel and leave everything else to the apps.  N 
developers trying to implement TCP-equivalents over UDP would be a 
nightmare -- and more to the point lead to tons of buggy implementations 
when they hit environments the author didn't test.  Not to mention tons 
of wasted dev time.

>
> 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.

Yes - though it's a SHOULD IIRC, and in some usecases (per above) 
selecting the non-preferred codec from the offer is better - and it's 
totally allowed.  For example, when VP9 is added, and you decide the CPU 
vs bitrate tradeoff leans towards burning bits to save CPU (tons of 
bandwidth, but on a low-end CPU) you may select VP8 over VP9; while on a 
bandwidth-constrained channel you might do the opposite.

> 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), ....

Yup - and this is where adding some way to control this provides the 
abilities in those unusual use-cases.  In general, though, most of these 
can be handled at the server/embedded-device end, as I mention.  But 
some I'm sure can't (and an example was the low-spec-phone that prefers 
not to do Opus - though overall the overhead from Opus isn't large).

>
> 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.

My webrtc-landing test page in fact mangles the SDP, though we also have 
a hidden about:config pref for testing that gives preference to a 
specific payload type.

>
> 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 :-)

Good.

-- 
Randell Jesup -- rjesup a t mozilla d o t com
Please please please don't emailrandell-ietf@jesup.org!  Way too much spam

Received on Wednesday, 5 August 2015 21:56:20 UTC