现象：进入视频房间，点开摄像头按钮，不显示对方视频，过了一会儿才有可能显示，显示后有时还卡顿。

定位过程：一开始以为是服务器未能把所有的RTP包传输给APP，或者传输过程中有丢包，后来对照log和抓包，发现并没有丢包，而且RTP负载的VP8的包内容也正确（通过VP8的picture id序号的严格递增来判断的）。

image

接着邓剑继续调试，看显示APP窗口收到的RTP包是否有丢失或者其它问题，过程中发现在卡顿时输出以下log：

E/ACodec  (28520): [OMX.hisi.video.decoder.vp8] setPortMode on output to DynamicANWBuffer failed w/ err -2147483648I/ACodec  (28520): [OMX.hisi.video.decoder.vp8] using color aspects (R:2(Limited), P:4(BT601_6_525), M:3(BT601_6), T:3(SMPTE170M)) and dataspace 0x103

setPortMode出现了0x8000000的错误，查android原生代码，这个错误是在ACodec里打印的：

status_t ACodec::setPortMode(int32_t portIndex, IOMX::PortMode mode) {
    status_t err = mOMXNode->setPortMode(portIndex, mode);
    if (err != OK) {
        ALOGE("[%s] setPortMode on %s to %s failed w/ err %d",
                mComponentName.c_str(),
                portIndex == kPortIndexInput ? "input" : "output",
                asString(mode),
                err);
        return err;
    }

    mPortMode[portIndex] = mode;
    return OK;
}

于是怀疑传输过来的视频格式或者本地的解码器试图解码的格式配置不匹配，查SDP协商过程发现SDP协商过程如下：

1）APP端提供的offer SDP如下，APP支持的RTP Payload Type是96，以H264为视频的编码格式；

v=0
o=- 6205246468786774154 2 IN IP4 1.1.1.1
s=-
t=0 0
m=audio 9 UDP/TLS/RTP/SAVPF 111 103 104 9 102 0 8 106 105 13 110 112 113 126
c=IN IP4 1.1.1.1
a=sendrecv
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=extmap:2 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=extmap:3 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01
a=rtpmap:111 opus/48000/2
a=rtcp-fb:111 transport-cc
a=fmtp:111 minptime=10;useinbandfec=1
a=rtpmap:103 ISAC/16000
a=rtpmap:104 ISAC/32000
a=rtpmap:9 G722/8000
a=rtpmap:102 ILBC/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:106 CN/32000
a=rtpmap:105 CN/16000
a=rtpmap:13 CN/8000
a=rtpmap:110 telephone-event/48000
a=rtpmap:112 telephone-event/32000
a=rtpmap:113 telephone-event/16000
a=rtpmap:126 telephone-event/8000
m=video 9 UDP/TLS/RTP/SAVPF 96 98 100
c=IN IP4 1.1.1.1
a=sendrecv
a=extmap:14 urn:ietf:params:rtp-hdrext:toffset
a=extmap:2 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=extmap:13 urn:3gpp:video-orientation
a=extmap:3 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01
a=extmap:5 http://www.webrtc.org/experiments/rtp-hdrext/playout-delay
a=extmap:6 http://www.webrtc.org/experiments/rtp-hdrext/video-content-type
a=extmap:7 http://www.webrtc.org/experiments/rtp-hdrext/video-timing
a=extmap:8 http://tools.ietf.org/html/draft-ietf-avtext-framemarking-07
a=extmap:9 http://www.webrtc.org/experiments/rtp-hdrext/color-space
a=rtpmap:96 H264/90000
a=rtcp-fb:96 goog-remb
a=rtcp-fb:96 transport-cc
a=rtcp-fb:96 ccm fir
a=rtcp-fb:96 nack
a=rtcp-fb:96 nack pli
a=fmtp:96 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=640c34
a=rtpmap:97 rtx/90000
a=fmtp:97 apt=96
a=rtpmap:98 H264/90000
a=rtcp-fb:98 goog-remb
a=rtcp-fb:98 transport-cc
a=rtcp-fb:98 ccm fir
a=rtcp-fb:98 nack
a=rtcp-fb:98 nack pli
a=fmtp:98 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42e034
a=rtpmap:99 rtx/90000
a=fmtp:99 apt=98
a=rtpmap:100 VP8/90000
a=rtcp-fb:100 goog-remb
a=rtcp-fb:100 transport-cc
a=rtcp-fb:100 ccm fir
a=rtcp-fb:100 nack
a=rtcp-fb:100 nack pli
a=rtpmap:101 rtx/90000
a=fmtp:101 apt=100
a=rtpmap:127 red/90000
a=rtpmap:124 rtx/90000
a=fmtp:124 apt=127
a=rtpmap:125 ulpfec/90000

2）服务器协商的answer如下，服务器仅支持VP8和VP9的编码，于是服务器选择了RTP Payload Type为100，即VP8为视频的编码格式

o=- 6205246468786774154 2 IN IP4 106.52.182.190
s=VideoRoom 151587126473916416
t=0 0
a=group:BUNDLE audio video
a=msid-semantic: WMS janus
m=audio 9 UDP/TLS/RTP/SAVPF 111
c=IN IP4 106.52.182.190
a=recvonly
a=mid:audio
a=rtcp-mux
a=ice-ufrag:NUm5
a=ice-pwd:ecGFMtni8gD+inVPrXFbKR
a=ice-options:trickle
a=fingerprint:sha-256 06:42:E6:1E:62:3D:31:84:70:C2:7E:40:79:C8:69:B3:B1:D4:16:DE:61:FC:15:99:70:B8:E7:91:DB:87:4B:7F
a=setup:active
a=rtpmap:111 opus/48000/2
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=extmap:3 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01
a=candidate:1 1 udp 2013266431 10.0.19.8 7265 typ host
a=candidate:2 1 udp 2013266430 10.244.1.0 41646 typ host
a=candidate:3 1 udp 1677722111 106.52.182.190 51673 typ srflx raddr 10.244.1.0 rport 41646
a=candidate:4 1 udp 1677722110 106.52.182.190 7265 typ srflx raddr 10.0.19.8 rport 7265
a=candidate:5 1 udp 503316991 106.52.182.190 59473 typ relay raddr 10.0.19.8 rport 7265
a=candidate:6 1 udp 503316990 106.52.182.190 54303 typ relay raddr 10.244.1.0 rport 41646
a=msid:janus janusa0
a=ssrc:2099989244 cname:janus
a=ssrc:2099989244 msid:janus janusa0
a=ssrc:2099989244 mslabel:janus
a=ssrc:2099989244 label:janusa0
a=end-of-candidates
m=video 9 UDP/TLS/RTP/SAVPF 100
c=IN IP4 106.52.182.190
a=recvonly
a=mid:video
a=rtcp-mux
a=ice-ufrag:NUm5
a=ice-pwd:ecGFMtni8gD+inVPrXFbKR
a=ice-options:trickle
a=fingerprint:sha-256 06:42:E6:1E:62:3D:31:84:70:C2:7E:40:79:C8:69:B3:B1:D4:16:DE:61:FC:15:99:70:B8:E7:91:DB:87:4B:7F
a=setup:active
a=rtpmap:100 VP8/90000
a=rtcp-fb:100 ccm fir
a=rtcp-fb:100 nack
a=rtcp-fb:100 nack pli
a=rtcp-fb:100 goog-remb
a=rtcp-fb:100 transport-cc
a=extmap:13 urn:3gpp:video-orientation
a=extmap:3 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01
a=extmap:5 http://www.webrtc.org/experiments/rtp-hdrext/playout-delay
a=extmap:8 http://tools.ietf.org/html/draft-ietf-avtext-framemarking-07
a=candidate:1 1 udp 2013266431 10.0.19.8 7265 typ host
a=candidate:2 1 udp 2013266430 10.244.1.0 41646 typ host
a=candidate:3 1 udp 1677722111 106.52.182.190 51673 typ srflx raddr 10.244.1.0 rport 41646
a=candidate:4 1 udp 1677722110 106.52.182.190 7265 typ srflx raddr 10.0.19.8 rport 7265
a=candidate:5 1 udp 503316991 106.52.182.190 59473 typ relay raddr 10.0.19.8 rport 7265
a=candidate:6 1 udp 503316990 106.52.182.190 54303 typ relay raddr 10.244.1.0 rport 41646
a=msid:janus janusv0
a=ssrc:3025202178 cname:janus
a=ssrc:3025202178 msid:janus janusv0
a=ssrc:3025202178 mslabel:janus
a=ssrc:3025202178 label:janusv0
a=end-of-candidates

3）APP pusher端上传的video的RTP PT是96（见上面的截图）

通过以上过程发现SDP协商是没有问题的，但是APP端却十分可能以H264初始化了解码器，导致VP8的视频无法解码，但是之后又能显示，到网上搜了下，android支持解码port mode的切换（没有深入研究这个切换的条件了）。

Root cause ：app 端选择了H264的解码器

Solution ： APP端在create room的时候应该指定音频和视频的编码格式，即以下两个参数：

audiocodec = "opus"

videocodec = "vp8"

APP提供的SDP offer里PT=96的编码应该是VP8非H264，修改create room的参数，打包继续测试，问题不再复现。

BTW ：

1）我们有好几个环境，在线上和dev环境，怎么就很流畅呢？从服务器的log来看，在以上两个环境SDP offer里PT=96的是VP8，那为什么在测试环境上SDP内容却是PT=96的是H264编码，这就要APP端去继续调查下去，两个不同的环境的代码是否严格一致。

2）服务器协商的answer SDP里选择了PT=100的VP8编码，但是APP为什么还选择PT=96去push视频内容，这个问题也还需要APP端去查，倾向于flutter-webrtc插件存在BUG或者我们对其接口调用尚不熟悉，调用欠当。

@jack.deng邓剑 以上如果有不严谨的地方，pls feel free to modify it (原谅我秀英语，实际上英语不怎么滴，见笑，但是感觉英语很准确地表达了我的意思)。