Thanks for the report. Request you to provide sample html or jsfiddle file which reproduces the above issue.

I really appreciate your help.

Thank you!

Thank you for the detailed bug report! FWIW, I mostly used https://webrtc.github.io/samples/src/content/peerconnection/munge-sdp/ when investigating this report.

Your offer says:
m=video 9 UDP/TLS/RTP/SAVPF 100

and

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

so I'm assuming you're trying to indicate that you only want to receive VP8 video. 

However, your offer also includes 
a=rtcp-fb:101 ccm fir
a=rtcp-fb:101 nack
a=rtcp-fb:101 nack pli
a=rtcp-fb:101 goog-remb
a=rtcp-fb:101 transport-cc

but rtp payload number 101 isn't mentioned in the m=video line. Removing those five "a=rtcp-fb:101" lines from the offer eliminated the "Failed to parse video codecs correctly" error when attempting to set the offer. 

jansson@ and hta@ - is it correct that Chrome throws an error while parsing an offer that references "a=rtcp-fb:101" without "a=rtpmap:101 VP9/90000" or a mention of payload 101 in the m=video line?


(And FYI to the reporter - even after removing the "a=rtcp-fb:101" lines from the offer, I still wasn't able to establish a connection because when I tried to set an answer, Chrome threw this error:
Failed to set session description: OperationError: Failed to set remote answer sdp: Failed to push down transport description: Offerer must use actpass value for setup attribute. 
A possibly relevant discussion of that error is in https://bugs.chromium.org/p/webrtc/issues/detail?id=2782)

Thank you for answer!
I'm don't mangle offer and answer. It's pure generated by Chrome on renegotiation without change DTLS roles. This is holding operation. OfferToRecive set to false and no media streams added as local streams.

Directly assigning to hta@ since I'm getting the feeling that I'm missing something here...

The offer generated has the brokenness. It seems that we're leaving in some stuff that belongs to VP9, but somehow leave VP9 out of the offer.

It also has a=setup:active, which I am not sure it should (but seems to make sense - "keep the current role").
A test case is needed; according to the description, it should be easy to repro.

Is someone in Kirkland able to pick this up?

Archiving this because it was reported several Chrome versions ago, and I think it's unlikely to still be a problem.

Please comment if you still see this, and I'll reopen and investigate further.

I'm still can reproduce this bug on 57.0.2987.133 (64-bit) Linux and Mac

I wasn't able to reproduce the originally reported issue (extra "rtcp-fb" lines). But what I did find is that, after adding the new stream, the stream ID in the new offer didn't change. As a result, though the offer/answer exchange completed successfully, audio wasn't flowing end-to-end audio. Is this what you saw?

If so, I believe that issue will be fixed by this CL: https://codereview.webrtc.org/2810733003

The CL linked above landed in webrtc; can you test next week with Chrome Canary?