From e3e3cb9af3bf8081eb6451951f7326a72621c857 Mon Sep 17 00:00:00 2001 From: Richard Fuchs Date: Wed, 31 Jan 2018 13:55:26 -0500 Subject: [PATCH] TT#28163 document transcoding control protocol options Change-Id: Idd679c754e89897426555b43457809c84c8e30db --- README.md | 18 +++++++++++++++++- 1 file changed, 17 insertions(+), 1 deletion(-) diff --git a/README.md b/README.md index 053b3f4ef..4082e52d4 100644 --- a/README.md +++ b/README.md @@ -1241,9 +1241,25 @@ Optionally included keys are: Contains a list of strings. Each string is the name of a codec that should be included in the list of codecs offered. This is primarily useful to block all codecs (`strip -> all`) except the ones given in the `offer` whitelist. - Currently codecs that were not present in the original list of codecs + Codecs that were not present in the original list of codecs offered by the client will be ignored. + * `transcode` + + Similar to `offer` but allows codecs to be added to the list of offered codecs + even if they were not present in the original list of codecs. In this case, + the transcoding engine will be engaged. Only codecs that are supported for both + decoding and encoding can be added in this manner. This also has the side effect + of automatically stripping all unsupported codecs from the list of offered codecs, + as *rtpengine* must expect to receive or even send in any codec that is present + in the list. + + Note that using this option does not necessarily always engage the transcoding + engine. If all codecs given in the `transcode` list were present in the original + list of offered codecs, then no transcoding will be done. Also note that if + transcoding takes place, in-kernel forwarding is disabled for this media stream + and all processing happens in userspace. + An example of a complete `offer` request dictionary could be (SDP body abbreviated):