I used a command like this to update the paths:
perl -pi -e "s/webrtc\/base/webrtc\/rtc_base/g" `find webrtc/rtc_base -name "*.cc" -o -name "*.h"`
BUG=webrtc:7634
NOPRESUBMIT=True # cpplint errors that aren't caused by this CL.
Review-Url: https://codereview.webrtc.org/2969623003
Cr-Commit-Position: refs/heads/master@{#18870}
After profiling, sakal@ found that this method was taking very long,
and causing the bitstream parsing to take up to 1ms per frame. The
culprit proved to be rtc::Buffer::AppendData, which was called for
every byte and subsequently calls memcpy.
BUG=webrtc:7293
Review-Url: https://codereview.webrtc.org/2728093002
Cr-Commit-Position: refs/heads/master@{#17051}
Bulk of the changes were done using
git grep -l '#include "webrtc/base/common.h"' | \
xargs sed -i '\,^#include.*webrtc/base/common\.h,d'
followed by adding back the include in the few places where it is
still needed, and in one case (pseudotcp.cc) instead deleting its use
of RTC_UNUSED.
BUG=webrtc:6424
Review-Url: https://codereview.webrtc.org/2644103002
Cr-Commit-Position: refs/heads/master@{#16263}
The VUI part an SPS may specify max_num_reorder_frames and
max_dec_frame_buffering. These may cause a decoder to buffer a number
of frame prior allowing decode, leading to delays, even if no frames
using such references (ie B-frames) are sent.
Because of this we update any SPS block emitted by the encoder.
Also, a bunch of refactoring of H264-related code to reduce code
duplication.
BUG=
Review-Url: https://codereview.webrtc.org/1979443004
Cr-Commit-Position: refs/heads/master@{#13010}
