[triage]: hbos@, can you triage and help find an owner?

Sounds like what magjed@ is working on.

WebRTC right now ignores profile-level-id. We will always use '42e01f' no matter what. I'm working on adding support for High profile, i.e. profile-level-id starting with '64' here: https://bugs.chromium.org/p/webrtc/issues/detail?id=6337.

Is the expected behavior for this case really that we should negotiate VP8? The profile-level-ids (42e00a and 42e01f) differ only in level_idc, and level-asymmetry-allowed=1, so this negotiation is actually correct?

Sorry I was saying VP8 because I've assumed that you were not supporting the profile-level-id.

Assuming that you support profile-level-id, I think that the correct behavior is to negotiate in H264 with 42e00a since in this case the level_idc 0x0a is the lower/common/shared supported by both clients.

level-asymmetry-allowed is not present in the offer, so the net result is that level asymmetry is *not* allowed. We should probably not set it in the answer, but the RFC doesn't seem to forbid sending it - it's just not affecting anything.

Until we support real level negotiation, we should reject codecs that don't have level-asymmetry-allowed and don't have the same level-id we use.

Yes I think that is the best choice for now. At least it will ensure a correct behavior until level-id is supported.

The following revision refers to this bug:
  https://chromium.googlesource.com/external/webrtc.git/+/68979ab7dd971ab6e983b23c83154ba05e183fb8

commit 68979ab7dd971ab6e983b23c83154ba05e183fb8
Author: magjed <magjed@webrtc.org>
Date: Thu Oct 06 09:15:49 2016

H264 codec: Check profile-level-id when matching

For the H264 video codec, comparing the codec name is not enough
for determining a match. The profile-level-id must also match.
This CL:
 - Specializes the VideoCodec::Matches function with extra logic for
   matching H264 codecs.
 - Adds unittests for matching H264 video codecs.
 - Removes the unnecessary CodecTest fixture class.

BUG= webrtc:6337 , chromium:645599 

Review-Url: https://codereview.webrtc.org/2347863003
Cr-Commit-Position: refs/heads/master@{#14546}

[modify] https://crrev.com/68979ab7dd971ab6e983b23c83154ba05e183fb8/webrtc/media/base/codec.cc
[modify] https://crrev.com/68979ab7dd971ab6e983b23c83154ba05e183fb8/webrtc/media/base/codec.h
[modify] https://crrev.com/68979ab7dd971ab6e983b23c83154ba05e183fb8/webrtc/media/base/codec_unittest.cc
[modify] https://crrev.com/68979ab7dd971ab6e983b23c83154ba05e183fb8/webrtc/media/base/mediaconstants.cc
[modify] https://crrev.com/68979ab7dd971ab6e983b23c83154ba05e183fb8/webrtc/media/base/mediaconstants.h

tvcsantos@ - Can you verify the fix once the CL reaches Canary?

magjed@ Sure I will check it, thanks for the fix.

magjed@ I've tested with Chromium Version 56.0.2884.0 (64-bit) and it is working as expected. 

I will test again when it reached Canary

Thanks once again for the fix

The following revision refers to this bug:
  https://chromium.googlesource.com/external/webrtc.git/+/06c8e1eaa7eb35c519c499f1d22d718213f71cc0

commit 06c8e1eaa7eb35c519c499f1d22d718213f71cc0
Author: Magnus Jedvert <magjed@webrtc.org>
Date: Tue Oct 25 07:53:52 2016

Revert of H264 codec: Check profile-level-id when matching (patchset #2 id:60001 of https://codereview.webrtc.org/2347863003/ )

Reason for revert:
Breaks H264 for external encoders in WebRTC as well as breaking H264 interop with e.g. Edge.

Original issue's description:
> H264 codec: Check profile-level-id when matching
>
> For the H264 video codec, comparing the codec name is not enough
> for determining a match. The profile-level-id must also match.
> This CL:
>  - Specializes the VideoCodec::Matches function with extra logic for
>    matching H264 codecs.
>  - Adds unittests for matching H264 video codecs.
>  - Removes the unnecessary CodecTest fixture class.
>
> BUG= webrtc:6337 , chromium:645599 
>
> Committed: https://crrev.com/68979ab7dd971ab6e983b23c83154ba05e183fb8
> Cr-Commit-Position: refs/heads/master@{#14546}

TBR=kthelgason@webrtc.org,hta@webrtc.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG= webrtc:6337 , chromium:645599 , webrtc:6552 , webrtc:6402 

Review URL: https://codereview.webrtc.org/2440123002 .

Cr-Commit-Position: refs/heads/master@{#14759}

[modify] https://crrev.com/06c8e1eaa7eb35c519c499f1d22d718213f71cc0/webrtc/media/base/codec.cc
[modify] https://crrev.com/06c8e1eaa7eb35c519c499f1d22d718213f71cc0/webrtc/media/base/codec.h
[modify] https://crrev.com/06c8e1eaa7eb35c519c499f1d22d718213f71cc0/webrtc/media/base/codec_unittest.cc
[modify] https://crrev.com/06c8e1eaa7eb35c519c499f1d22d718213f71cc0/webrtc/media/base/mediaconstants.cc
[modify] https://crrev.com/06c8e1eaa7eb35c519c499f1d22d718213f71cc0/webrtc/media/base/mediaconstants.h

Reopening since I had to revert the fix.

Ok, I will be waiting for news on this. Thanks

I relanded H264 profile-level-id negotiation yesterday here: https://codereview.webrtc.org/2483173002/

We do real level negotiation now, so instead of rejecting H264 we should answer profile-level-id=42e00a now.

tvcsantos@ - Can you verify this once the CL reaches Canary?

magjed@ Ok I will check it. Thanks once again for the fix

magjed@

I've downloaded the last build from

http://chromium.woolyss.com/download/

and the negotiation seems ok, since we can now negotiate in H264 with 42e00a

but there is no video in chrome side. I can see using a wireshark in my end that I'm sending and receiving video in H264. It is just in chrome that I can't see the video that I'm sending to it.

Thanks

Ok, too bad that Chrome doesn't show the video, but I hope that's not a regression? I.e. did we show video previously when we incorrectly returned 42e01f? That would be strange since I have only touched negotiation and the rest of the code should behave the same regardless the answer H264 level.

Since we don't support 42e01f we could not check for that case in our system, hence the need for us to either ignore the h264 and negotiate in VP8 or follow the correct behaviour of negotiating with the lower common profile. 

We support 42e00a, 42e00c and 42e01e and in these case I don't see video in chrome. Maybe there is some problem in the decoding process with this new profile-level-id

Thanks

The decoding process should be unaffected. Have you ever been able to successfully send H264 video from your system that showed up in Chrome?

As I've mentioned we don't support the previous negotiation:

"level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42e01f"

in our system so we cannot test the original behaviour before this fix. I've turned on the logs in Chromium and I'm seeing that it is failing to decode packates. Logs attached, thanks again

Deleted: chrome_debug.log 2.4 MB

chrome_debug.log 2.4 MB View Download

> As I've mentioned we don't support the previous negotiation:
> "level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42e01f"
> in our system so we cannot test the original behaviour before this fix.
Yeah, I wanted to make sure this wasn't a regression caused by the negotiation change. I'm going to keep this issue closed.

Maybe the decode failure problem is the same as  issue 653434 ?

Ok I'll move to the thread of the  issue 653434 

Thanks for the negotiation fix

Hi again @magjed when chrome receives the following sdp

v=0
o=OneSipConnector 50 3 IN IP4 10.200.11.5
s=OneSIPConnector
c=IN IP4 10.200.11.5
t=0 0
m=audio 19084 RTP/SAVPF 8 110
a=rtpmap:8 PCMA/8000
a=ptime:20
a=rtpmap:110 telephone-event/8000
a=fmtp:110 0-15
a=candidate:1 1 udp 2130706431 10.200.11.5 19084 typ host
a=candidate:2 1 ssltcp 2130706431 10.200.11.5 443 typ host
a=ice-ufrag:3a9e797d5f490ddcf20047
a=ice-pwd:60322c3b15a154222dbaa2
a=fingerprint:sha-1 BA:87:0C:6B:E5:1C:3F:3E:21:C6:56:AF:18:4C:0B:1B:FF:17:A8:18
a=setup:actpass
a=rtcp-mux
m=video 19920 RTP/SAVPF 127
a=rtpmap:127 H264/90000
a=fmtp:127 packetization-mode=0;profile-level-id=42e00a
a=candidate:1 1 udp 2130706431 10.200.11.5 19920 typ host
a=candidate:2 1 ssltcp 2130706431 10.200.11.5 443 typ host
a=ice-ufrag:692c4a80187e16c550acf6
a=ice-pwd:0fbf2f146ad6047ec6f9ff
b=AS:2000
a=fingerprint:sha-1 BA:87:0C:6B:E5:1C:3F:3E:21:C6:56:AF:18:4C:0B:1B:FF:17:A8:18
a=setup:actpass
a=rtcp-mux

it answers with the sdp

v=0
o=- 8834504571245762454 2 IN IP4 127.0.0.1
s=-
t=0 0
a=msid-semantic: WMS 27A1NUh47GhnGUEScEleVqUuTpCFHIXNN0QT
m=audio 60091 RTP/SAVPF 8 110
c=IN IP4 172.24.42.34
a=rtcp:9 IN IP4 0.0.0.0
a=candidate:1399690726 1 udp 2122260223 172.24.42.34 60091 typ host generation 0 network-id 1 network-cost 10
a=candidate:502163734 1 tcp 1518280447 172.24.42.34 9 typ host tcptype active generation 0 network-id 1 network-cost 10
a=ice-ufrag:eqDJ
a=ice-pwd:NTFDugg2ZL7Bg0F/SpVTPVC5
a=fingerprint:sha-256 64:C5:29:09:01:54:3B:C5:F1:7F:4B:9D:93:9E:34:98:DF:9B:FC:C3:AC:08:0C:7B:72:56:AE:FF:4F:F6:0C:78
a=setup:active
a=mid:audio
a=sendrecv
a=rtcp-mux
a=rtpmap:8 PCMA/8000
a=rtpmap:110 telephone-event/8000
a=ssrc:2621151715 cname:LKWoNZJpMRSd7xhw
a=ssrc:2621151715 msid:27A1NUh47GhnGUEScEleVqUuTpCFHIXNN0QT a32a56aa-426c-4009-893d-c14c237d683f
a=ssrc:2621151715 mslabel:27A1NUh47GhnGUEScEleVqUuTpCFHIXNN0QT
a=ssrc:2621151715 label:a32a56aa-426c-4009-893d-c14c237d683f
m=video 60092 RTP/SAVPF 127
c=IN IP4 172.24.42.34
a=rtcp:9 IN IP4 0.0.0.0
a=candidate:1399690726 1 udp 2122260223 172.24.42.34 60092 typ host generation 0 network-id 1 network-cost 10
a=candidate:502163734 1 tcp 1518280447 172.24.42.34 9 typ host tcptype active generation 0 network-id 1 network-cost 10
a=ice-ufrag:vIh/
a=ice-pwd:QCE0Q+hPOoeBaPeujVYGLc2Q
a=fingerprint:sha-256 64:C5:29:09:01:54:3B:C5:F1:7F:4B:9D:93:9E:34:98:DF:9B:FC:C3:AC:08:0C:7B:72:56:AE:FF:4F:F6:0C:78
a=setup:active
a=mid:video
a=sendrecv
a=rtcp-mux
a=rtpmap:127 H264/90000
a=fmtp:127 packetization-mode=1;profile-level-id=42e00a
a=ssrc:3429610720 cname:LKWoNZJpMRSd7xhw
a=ssrc:3429610720 msid:27A1NUh47GhnGUEScEleVqUuTpCFHIXNN0QT dfb14149-bb56-471b-b5f8-2ea931c621a7
a=ssrc:3429610720 mslabel:27A1NUh47GhnGUEScEleVqUuTpCFHIXNN0QT
a=ssrc:3429610720 label:dfb14149-bb56-471b-b5f8-2ea931c621a7

bottom line it receives 

a=rtpmap:127 H264/90000
a=fmtp:127 packetization-mode=0;profile-level-id=42e00a

and answers with

a=rtpmap:127 H264/90000
a=fmtp:127 packetization-mode=1;profile-level-id=42e00a

is this the correct approach? we do not support packetization-mode in our system hence the packetization-mode=0 from our end

Can you check this please

Thanks

Nope, it's not a correct answer from WebRTC. Support for 'packetization-mode=0' is tracked in  issue 600254 . I'm keeping this issue closed since profile-level-id was answered correctly.