Chrome WebRTC M37 Release Notes.

1,571 views
Skip to first unread message

Vikas Marwaha

unread,
Sep 18, 2014, 2:36:07 PM9/18/14
to discuss...@googlegroups.com
Hi,

Please find below Chrome WebRTC M37 release notes :- 

Features:-
  • Issue 1095:-  Added support for RTP Retransmission ( RTX ) and the additional payload type "apt" format parameter as per RFC 4588.
  • Issue 1672:- Enabled pacing by default. To disable pacing use googLeakyBucket: false in video constraints.
  • Issue 3103:-  Added functionality to report stats for the received Audio codec for a given stream, earlier we only reported stats for send codec.
  • issue 385304:- Enabled VP8 denoising by default. To turn it off use the googNoiseReduction constraint.
Bugs:-
  • Issue 2645:-  Fixed bug in SCTP data Channel. Now we close the datachannel when the send buffer is full or there are transport errors.
  • Issue 2749:-  Fixed issue, SCTP stack was not properly cleaned up when shutting down SCTPDataEngine.
  • Issue 2431:- Fixed issue in SCTP data Channel. Now we fire OnRenegotiationNeeded event only for the first SCTP data channel. The subsequent SCTP data channels don't need renegotiation since SCTP data streams are not negotiated through SDP.
  • Issue 2513:- Fixed issue, closing SCTP data Channel on one peer does not change the ReadyState of another peer. 
  • Issue 2646:- Fixed issue in SCTP data channels, Now we make sure that the stream id of the closed data channel is available for reuse as per spec.
  • Issue 2172:- Fixed issue, where PeerConnection was accepting ICE credentials longer than 256 characters.
  • Issue 3267:-  Fixed issue in setting bitrate for Opus codec, the member variable holding opus bitrate was overflowing for values above 65 kbps.
  • Issue 3537:-  Fixed issue, when TURN server was getting used as a STUN server then no server reflexive candidates were getting generated. To handle it, currently we temporarily disabled shared socket mode for TURN ports.
  • Issue 398080:- Improved handling of getUserMedia for cameras that might look good OS-wise but produce faulty frames. For instance we fixed problem for XSplitBroadcaster camera that produced 0 fps when configured/started.
  • Issue 373690:- Fixed issue, now PeerConnection should be garbage collected after calling close().
  • Issue 369855:- Fixed issue where DTLS negotiation would fail for fragmented DTLS packets coming out of order.
  • issue 346616:- Fixed issue with GetUserMedia, where 2 calls to GetUserMedia with different resolutions were resulting in same resolution.
Known issues/ Announcements:-
  • issue 387737:- In M37 we have moved the audio processing from peerconnection to GetUserMedia and the audio processing is turned on by default unless you specify the getUserMedia constraint "echoCancellation: false". Since the audio processing currently downsamples to mono, if you want stereo you would need to turn off echoCancellation constraint via GetUserMedia constraint. We are looking into handling this in a better way.
  • issue 347641:- The flag enable-usermedia-screen-capture from chrome://flags has been removed. The command-line switch enable-usermedia-screen-capturing will still work.
/Vikas

Philipp Hancke

unread,
Sep 18, 2014, 2:43:55 PM9/18/14
to discuss...@googlegroups.com
hey Vikas,

thanks!
  • issue 385304:- Enabled VP8 denoising by default. To turn it off use the googNoiseReduction constraint.

Can you make that public please? Also note that denoising can sometimes generate artifacts, see https://code.google.com/p/webrtc/issues/detail?id=3807

 
  • Issue 373690:- Fixed issue, now PeerConnection should be garbage collected after calling close().

It seems those are now removed from webrtc-internals which I find highly unfortunate. This makes it alot harder to snoop on other peoples usage of the peerconnection api!

  • issue 346616:- Fixed issue with GetUserMedia, where 2 calls to GetUserMedia with different resolutions were resulting in same resolution.

<3
 

https://code.google.com/p/webrtc/issues/detail?id=3249 seems to be missing from the list. Even more confusing, I still see lots of those kind of connections run into a timeout, but need to verify that with a proper test setup.

Vikas

unread,
Sep 18, 2014, 4:21:42 PM9/18/14
to discuss...@googlegroups.com


On Thursday, September 18, 2014 11:43:55 AM UTC-7, Philipp Hancke wrote:
hey Vikas,

thanks!
  • issue 385304:- Enabled VP8 denoising by default. To turn it off use the googNoiseReduction constraint.

Can you make that public please? Also note that denoising can sometimes generate artifacts, see https://code.google.com/p/webrtc/issues/detail?id=3807

 
Sure i will look into it.. That's right and issue 3807 is on track for M38. 
  • Issue 373690:- Fixed issue, now PeerConnection should be garbage collected after calling close().

It seems those are now removed from webrtc-internals which I find highly unfortunate. This makes it alot harder to snoop on other peoples usage of the peerconnection api!

Now PeerConnection object is destroyed after Close(), it's also removed from webrtc-internals, since it removes any PC on destruction.

  • issue 346616:- Fixed issue with GetUserMedia, where 2 calls to GetUserMedia with different resolutions were resulting in same resolution.

<3
 

https://code.google.com/p/webrtc/issues/detail?id=3249 seems to be missing from the list. Even more confusing, I still see lots of those kind of connections run into a timeout, but need to verify that with a proper test setup.

Thanks for bringing this up, checked with Mallinath that should have made to M37, feel free to respond on to that issue or file a new one if you still see the problem. 

Philipp Hancke

unread,
Sep 19, 2014, 2:42:49 PM9/19/14
to discuss...@googlegroups.com
2014-09-18 22:21 GMT+02:00 Vikas <vikasm...@webrtc.org>:


On Thursday, September 18, 2014 11:43:55 AM UTC-7, Philipp Hancke wrote:
hey Vikas,

thanks!
  • issue 385304:- Enabled VP8 denoising by default. To turn it off use the googNoiseReduction constraint.

Can you make that public please? Also note that denoising can sometimes generate artifacts, see https://code.google.com/p/webrtc/issues/detail?id=3807

 
Sure i will look into it.. That's right and issue 3807 is on track for M38. 


Yeah... and the workaround for M37 is pretty easy.
 
  • Issue 373690:- Fixed issue, now PeerConnection should be garbage collected after calling close().

It seems those are now removed from webrtc-internals which I find highly unfortunate. This makes it alot harder to snoop on other peoples usage of the peerconnection api!

Now PeerConnection object is destroyed after Close(), it's also removed from webrtc-internals, since it removes any PC on destruction.

I think that's pretty annoying. Do you have anything to hide in hangouts? :-p
https://code.google.com/p/webrtc/issues/detail?id=3249 seems to be missing from the list. Even more confusing, I still see lots of those kind of connections run into a timeout, but need to verify that with a proper test setup.

Thanks for bringing this up, checked with Mallinath that should have made to M37, feel free to respond on to that issue or file a new one if you still see the problem. 

That made it into M37 indeed. However, the impact seems to be way less than I had hoped for :-/
I'll file a new bug once I can reliably reproduce the case of the turn/tcp requests getting silently dropped.

thanks!

Philipp Hancke

unread,
Sep 23, 2014, 11:45:45 AM9/23/14
to discuss...@googlegroups.com
  • Issue 373690:- Fixed issue, now PeerConnection should be garbage collected after calling close().

It seems those are now removed from webrtc-internals which I find highly unfortunate. This makes it alot harder to snoop on other peoples usage of the peerconnection api!

Now PeerConnection object is destroyed after Close(), it's also removed from webrtc-internals, since it removes any PC on destruction.

I think that's pretty annoying. Do you have anything to hide in hangouts? :-p

Complained in https://code.google.com/p/chromium/issues/detail?id=416876 -- can you get that assigned as usual? :-)

Ajay Choudary

unread,
Sep 23, 2014, 12:07:08 PM9/23/14
to discuss...@googlegroups.com

Chrome Debug Logs are printing on Linux(CentOS-6.5) Console with M37.  see https://code.google.com/p/chromium/issues/detail?id=412650
with command line flags: --enable-logging=stderr --log-level=3 --vmodule=*libjingle/*=3,*=0

Is it known issue ? Then how do i get Chrome logs in Linux to Debug ?
Can we hope that this issue may fix with M38 ?

Vikas

unread,
Sep 24, 2014, 1:50:19 PM9/24/14
to discuss...@googlegroups.com
Hi,
Thanks for the feedback, i tried with Version 38.0.2125.66 beta (64-bit) and it seemed to work for me. Can you give it a try with Chrome 38?
/Vikas

Ajay Choudary

unread,
Oct 8, 2014, 2:12:10 AM10/8/14
to discuss...@googlegroups.com
Hi Vikas,

Tested with Latest Stable Release Version 38.0.2125.101 (64-bit), Still i was unable to get the Debug logs in Linux.

-Ajay

Vikas

unread,
Oct 9, 2014, 2:58:06 AM10/9/14
to discuss...@googlegroups.com
Thanks Ajay, i will look into it. 

/Vikas

Vikas

unread,
Oct 9, 2014, 5:22:15 PM10/9/14
to discuss...@googlegroups.com
That's kind of strange, it works for me. I downloaded chrome stable and then just ran the following command to launch chrome. 
 $ google-chrome-stable --enable-logging=stderr --log-level=3 --vmodule=*libjingle/*=3,*=0 
I ran apprtc demo and was able to see webrtc logging printed to console, do you see nothing on console? i have the same version as you do, tested on a ubuntu. Are there other people experiencing similar issue?

/VIkas

Ajay Choudary

unread,
Oct 10, 2014, 2:06:45 AM10/10/14
to discuss...@googlegroups.com
Hi Vikas,

I have three machines running with CentOS-6.5 where i could notice the issue while using Chrome (Version 38.0.2125.101 (64-bit))
Nothing is printed on Console even when i started chrome with  

exec -a "$0" "$HERE/chrome"  --user-data-dir="$PROFILE_DIRECTORY_FLAG"  --enable-logging=stderr --log-level=3 --vmodule=*libjingle/*=3,*=0 \
  "$@"

Still i was able to see the logs with this command in Chrome-35 (Version 35.0.1916.114) & Chrome-36

-Ajay 

Vikas

unread,
Oct 10, 2014, 2:51:02 PM10/10/14
to discuss...@googlegroups.com
Hi Ajay,

Are you not getting chrome logs at all or is the problem in getting webrtc logs in chrome? 

/Vikas

Ajay Choudary

unread,
Oct 11, 2014, 2:00:14 AM10/11/14
to discuss...@googlegroups.com
Hi vikas, 

No Log is printing on linux(CentOS-6.5) console.

-Ajay

Vikas

unread,
Oct 13, 2014, 5:34:35 PM10/13/14
to discuss...@googlegroups.com
Hi Ajay,

That sounds like a problem with chrome not webrtc. I would suggest you file an issue in the chomium tracker.

/Vikas

PhistucK

unread,
Oct 13, 2014, 5:38:06 PM10/13/14
to WebRTC-discuss
(Unless you are using some distribution of Chromium and not Chrome, in which case you will have to find the right channel to your distribution)


PhistucK

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Ajay Choudary

unread,
Oct 13, 2014, 7:27:21 PM10/13/14
to discuss...@googlegroups.com
Hi Vikas,

but i didn't get any response.

-Ajay
Reply all
Reply to author
Forward
0 new messages