Currently, if WebRTC receives a CVO byte where the Camera or Flip bit is
set, then rotation is incorrectly parsed as 0. This CL fixes that issue.
The Camera and Flip bit is still unimplemented and will just be ignored
though.
BUG=webrtc:6120
R=danilchap@webrtc.org, pthatcher@webrtc.org, tommi@webrtc.org
Review URL: https://codereview.webrtc.org/2280703002 .
Cr-Commit-Position: refs/heads/master@{#14027}
Currently, the aec_debug_dump buildflag can and is used to store data in the whole of
the audio processing module. Therefore a more appropriate name is apm_debug_dump which
also matches the names of the data dumping functionality. This CL makes that name change.
The CL also changes the WEBRTC_AEC_DEBUG_DUMP define to
WEBRTC_APM_DEBUG_DUMP == 1
Furthermore, this CL moves the buildflag to a more appropriate place.
BUG=webrtc:5298
Review-Url: https://codereview.webrtc.org/2300813004
Cr-Commit-Position: refs/heads/master@{#14026}
WebRTC no longer has any restriction on what thread frames should be
delivered on. One possible problem with this CL is that NV21->I420
conversion and scaling is done on the thread that delivers frames, which
might cause fps regressions.
R=nisse@webrtc.org, perkj@webrtc.org, tkchin@webrtc.org
Review URL: https://codereview.webrtc.org/2137503003 .
Cr-Commit-Position: refs/heads/master@{#14021}
cl was originally reviewed here:
https://codereview.webrtc.org/2060403002/
- Add task queue to Call with the intent of replacing the use of one of the process threads.
- Split VideoSendStream in two. VideoSendStreamInternal is created and used on the new task queue.
- BitrateAllocator is now created on libjingle's worker thread but always used on the new task queue instead of both encoder threads and the process thread.
- VideoEncoderConfig and VideoSendStream::Config support move semantics.
- The encoder thread is moved from VideoSendStream to ViEEncoder. Frames are forwarded directly to ViEEncoder which is responsible for timestamping ? and encoding the frames.
TBR=mflodman@webrtc.org
BUG=webrtc:5687
Review-Url: https://codereview.webrtc.org/2250123002
Cr-Commit-Position: refs/heads/master@{#14014}
Users are updated to call libyuv functions directly. Also delete
related unit tests.
BUG=webrtc:5682
Review-Url: https://codereview.webrtc.org/2287233002
Cr-Commit-Position: refs/heads/master@{#14013}
The method is no longer used, since the jitter buffer delay is
obtained directly from AudioCodingModule instead of being calculated
and smoothed in VoiceEngine. Deleting a few obsolete member variables
as well.
BUG=webrtc:6237
Review-Url: https://codereview.webrtc.org/2290253002
Cr-Commit-Position: refs/heads/master@{#14007}
That is, rather than keeping a separate pointer and size.
This helps automate memory management in NetEq and will be useful in the
work to minimize the AudioDecoder interface as part of the injectable
audio codec work.
I'm planning a follow-up that will change the current management of Packet* to wrapping them in unique_ptr instead.
Review-Url: https://codereview.webrtc.org/2289093003
Cr-Commit-Position: refs/heads/master@{#14002}
The compiler optimization for Windows is O1 by default in GN, but O2 in GYP.
This might help explain the regression observed on neteq_performance_unittest.
NOTRY=True
BUG=641966
Review-Url: https://codereview.webrtc.org/2291253003
Cr-Commit-Position: refs/heads/master@{#13999}
Using a timestamp based on a timer that is monotonically increasing for
the cache, so that cache's freshness can be checked regardless of if
system clock is modified.
Using a system clock for the stats' timestamp, which needs to be
relative to UNIX epoch (Jan 1, 1970, UTC).
This CL removes the dependency on faketiming.h.
BUG=chromium:627816
NOTRY=True
Review-Url: https://codereview.webrtc.org/2299643002
Cr-Commit-Position: refs/heads/master@{#13997}
This test has been failing on TSan lately:
../../webrtc/media/base/videoengine_unittest.h:519: Failure
Value of: GetReceiverStats(i).frame_width
Actual: 0
Expected: DefaultCodec().width
Which is: 640
The root cause for the failure appears to be that the stats update
(https://cs.chromium.org/chromium/src/third_party/webrtc/video/video_receive_stream.cc?rcl=1472584967&l=353)
happens to be after the frame is passed to the renderer - while the test
is only waiting for the former.
The fix is to give it some extra time using EXPECT_EQ_WAIT instead.
Review-Url: https://codereview.webrtc.org/2299483002
Cr-Commit-Position: refs/heads/master@{#13991}
With this change, the value 0xFF is no longer used to flag that the RTP
type is unknown. Instead, an empty value for the rtc::Optional is used.
Review-Url: https://codereview.webrtc.org/2290153002
Cr-Commit-Position: refs/heads/master@{#13989}
Reason for revert:
Downstream apps should now be fixed.
Original issue's description:
> Revert of Remove the old AndroidVideoCapturer stack code. (patchset #2 id:20001 of https://codereview.webrtc.org/2235893003/ )
>
> Reason for revert:
> Breaks downstream.
>
> Original issue's description:
> > Remove the old AndroidVideoCapturer stack code.
> >
> > This code is no longer needed. Apps should be using the new API introduced here: https://codereview.webrtc.org/2127893002/
> >
> > Committed: https://crrev.com/1b365a8db070f9cdcbf35ec871f758dcd909e51d
> > Cr-Commit-Position: refs/heads/master@{#13950}
>
> TBR=magjed@webrtc.org,glaznev@webrtc.org,kjellander@webrtc.org
> # Skipping CQ checks because original CL landed less than 1 days ago.
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
>
> Committed: https://crrev.com/e39f251dacf66e50153bcda615f06b7c59e5856b
> Cr-Commit-Position: refs/heads/master@{#13958}
TBR=magjed@webrtc.org,glaznev@webrtc.org,kjellander@webrtc.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
Review-Url: https://codereview.webrtc.org/2298063003
Cr-Commit-Position: refs/heads/master@{#13988}
Also, make explicit that the GYP build has limited support.
BUG=webrtc:6281
NOTRY=True
Review-Url: https://codereview.webrtc.org/2298143002
Cr-Commit-Position: refs/heads/master@{#13984}
This is step 2 of the plan below.
The modified plan
1. First land unmodified task_queue.h into webrtc_override in Chrome
2. Modify build files in the webrtc repo to include the task_queue.h and task_queue.cc from webrtc_overrides. This will breaks webrtc Chrome FYI.
3. Combine a roll of webrtc to Chrome and a the cl in https://codereview.chromium.org/2293913003/ into one cl.
The combined cl will roll in build files from 2 and add task_queue.cc in webrtc_overrides and build task_queue_unittest.cc as part of content_unittests to test task_queue.cc in webrtc_overrides.
4... Start using task queues in webrtc........
BUG=webrtc:5687
Review-Url: https://codereview.webrtc.org/2289203002
Cr-Commit-Position: refs/heads/master@{#13983}
hbos and hta are webrtc/stats/ OWNERS. Public api headers relating to
rtcstats are placed in webrtc/api/ and implementations are placed in
webrtc/stats/. This ownership allows the rtcstats owners to own both .cc
and .h files.
For example, rtcstats.[h/cc] and rtcstatsreport.[h/cc].
(Soon there will also be rtcstats_objects.[h/cc] and more.)
BUG=chromium:627816
Review-Url: https://codereview.webrtc.org/2294693002
Cr-Commit-Position: refs/heads/master@{#13981}
