> Speculative revert of 8631 "Remove lock from Bitrate() and FrameRate() in Video..."
>
> We ran into the alignment problem on Mac 10.9 debug again. This is the only CL I see in the range that adds an rtc::CriticalSection, so I'm trying out reverting it before attempting another roll.
>
> > Remove lock from Bitrate() and FrameRate() in VideoSender.
> > These methods are called on the VideoSender's construction thread, which is the same thread as modifies the value of _encoder. It's therefore safe to not require a lock to access _encoder on this thread.
> >
> > I'm making access to the rate variables from VCMGenericEncoder, thread safe, by using a lock that's not associated with the encoder. There should be little to no contention there. While modifying VCMGenericEncoder, I noticed that a couple of member variables weren't needed, so I removed them.
> >
> > The reason for this change is that getStats is currently contending with the encoder when Bitrate() is called. On my machine, this means that getStats can take about 25-30ms instead of ~1ms.
> >
> > Also adding some documentation for other methods and a suggestion for how we could avoid contention between the encoder and the network thread.
> >
> > BUG=2822
> > R=mflodman@webrtc.org
> >
> > Review URL: https://webrtc-codereview.appspot.com/43479004
>
> TBR=tommi@webrtc.org
>
> Review URL: https://webrtc-codereview.appspot.com/45529004TBR=tommi@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/46519004
Cr-Commit-Position: refs/heads/master@{#8645}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8645 4adac7df-926f-26a2-2b94-8c16560cd09d
558dc40c88