NOTREACHED() and NOTREACHED_IN_MIGRATION() are both CHECK-fatal now.
The former is [[noreturn]] so this CL also performs dead-code removal
after the NOTREACHED().
This CL does not attempt to do additional rewrites of any surrounding
code, like:
if (!foo) {
NOTREACHED();
}
to CHECK(foo);
Those transforms take a non-trivial amount of time (and there are
thousands of instances). Cleanup can be left as an exercise for the
reader.
Bug: 40580068
Low-Coverage-Reason: OTHER Should-be-unreachable code
Change-Id: I8cd87f774e5fec8ec893dcc7286b0979643ea627
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5873742
Reviewed-by: Joe Downing <joedow@chromium.org>
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Commit-Queue: Daniel Cheng <dcheng@chromium.org>
Auto-Submit: Peter Boström <pbos@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1357911}
This was generated by replacing " NOTREACHED()" with
" NOTREACHED_IN_MIGRATION()" and running git cl format.
This prepares for making NOTREACHED() [[noreturn]] alongside
NotReachedIsFatal migration of existing inventory.
Bug: 40580068
Change-Id: I57cfd1b2a4e6c91529ab221cf7a7da622be26913
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5540125
Commit-Queue: Lei Zhang <thestig@chromium.org>
Owners-Override: Lei Zhang <thestig@chromium.org>
Commit-Queue: Peter Boström <pbos@chromium.org>
Auto-Submit: Peter Boström <pbos@chromium.org>
Reviewed-by: Lei Zhang <thestig@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1300942}
The canonical bug format is TODO(crbug.com/<id>). TODOs of the
following forms will all be migrated to the new format:
- TODO(crbug.com/<old id>)
- TODO(https://crbug.com/<old id>)
- TODO(crbug/<old id>)
- TODO(crbug/monorail/<old id>)
- TODO(<old id>)
- TODO(issues.chromium.org/<old id>)
- TODO(https://issues.chromium.org/<old id>)
- TODO(https://issues.chromium.org/u/1/issues/<old id>)
- TODO(bugs.chromium.org/<old id>)
Bug id mapping is sourced from go/chrome-on-buganizer-prod-issues.
See go/crbug-todo-migration for details.
#crbug-todo-migration
Bug: b/321899722
Change-Id: I050f2f811b9f50e8aa29d2474da33746d17d59fb
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5494188
Owners-Override: Alison Gale <agale@chromium.org>
Auto-Submit: Alison Gale <agale@chromium.org>
Reviewed-by: Peter Boström <pbos@chromium.org>
Commit-Queue: Peter Boström <pbos@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1293300}
The active_map feature provides a way for us to tell the encoder
which regions of a frame have changed so it doesn't need to check
the entire frame for changes. With VP8 this was a neccesity and VP9
also benefits from having this feature enabled however our impl
for AV1 still shows a performance hit when enabling it.
I would like to add a Client toggle to allow for testing and
tuning of the feature to see if we can further improve performance
for AV1 in CRD using an active_map.
Example output:
Creating AV1 encoder - Profile: 0, Speed: 11, ActiveMap: 1
Creating AV1 encoder - Profile: 1, Speed: default, ActiveMap: default
Change-Id: I675b4b6cd7668a69d32f87e6af07c72c8b794b85
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5360244
Reviewed-by: Lambros Lambrou <lambroslambrou@chromium.org>
Auto-Submit: Joe Downing <joedow@chromium.org>
Commit-Queue: Lambros Lambrou <lambroslambrou@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1271130}
I'm adding a deterministic crash to the CRD host when a specific,
invalid encoder speed value is passed. I am going to use this for
release build testing and will remove it before branch point.
Change-Id: Ia1e8134e45b22309d502e7dc5cf70bda2ac1cd28
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4528915
Reviewed-by: Lambros Lambrou <lambroslambrou@chromium.org>
Commit-Queue: Joe Downing <joedow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1145337}
The current implementation uses SDP format parameters to adjust
the framerate. This works well for VP8 and VP9 but is not the
supported way of adjusting the AV1 framerate and isn't possible
for H.264. Also we've seen that other browsers occasionally
mangle the SDP (or even set their own max-fr values) which further
complicates this logic.
I'd like to have a consistent way to set the target framerate for
the host, one which will work regardless of the currently
selected encoder so my new approach is to use a control message.
I will likely extend this in the future to control the encoder
speed as well though that is not in scope for this CL.
Bug: 217468304
Change-Id: I690420f5af02c5ed11f96bad5a7646cf9eb2cc95
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4448768
Code-Coverage: Findit <findit-for-me@appspot.gserviceaccount.com>
Commit-Queue: Joe Downing <joedow@chromium.org>
Reviewed-by: Jamie Walch <jamiewalch@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1135337}
This CLs moves media::BindToCurrentLoop() to base/ and renames it to
BindPostTaskToCurrentDefault() to be consistent with BindPostTask().
It calls BindPostTask() with the current default SequencedTaskRunner
which is convenient in many cases (as can be seen in media/ code).
Note that BindPostTask() was also moved/renamed/modified previously
from media::BindToLoop(). So this is the continuation of that move.
Bug: 1140582, 1411753
Change-Id: I1ca6fe33ea2898c7e220b97bc18944d98d9b47bb
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3088279
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Owners-Override: Daniel Cheng <dcheng@chromium.org>
Reviewed-by: Simeon Anfinrud <sanfin@chromium.org>
Owners-Override: Gabriel Charette <gab@chromium.org>
Reviewed-by: Gabriel Charette <gab@chromium.org>
Commit-Queue: Xiaohan Wang <xhwang@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1100826}
This CL allows the client to set a new encoder speed (via
AOME_SET_CPUUSED) by adding a field in the SessionOptions when it
connects to the host. At the moment there isn't a better way to
do this as SDP does not define any method of switching encoder
speeds.
This CL also updates the default encoder speed for AV1 to '9'. This
is because I have noticed some quality issues when using 10 and I
think the quality improvement is worth the performance trade-off.
Bug: b:217468304
Change-Id: I0644fe68abef437862bfafee2bca4e9d2e2f152c
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4189362
Commit-Queue: Joe Downing <joedow@chromium.org>
Reviewed-by: Lambros Lambrou <lambroslambrou@chromium.org>
Commit-Queue: Lambros Lambrou <lambroslambrou@chromium.org>
Auto-Submit: Joe Downing <joedow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1095953}
Turns out there's a lot of includes, so these will have to be removed
before deleting the implementation of the task runner handles.
To allow the deletion of the task runner handle headers, add
the sequenced/thread task runner handles where they are used in
the codebase with scripts.
This was done with an automated change, with a few touchups afterwards.
The code for the mass-refactor changes are here:
python:
https://paste.googleplex.com/5534570878337024
shell:
https://paste.googleplex.com/6466750748033024
In terms of touchups:
- add sequenced/thread task runner handles to
the third_party/blink/public/DEPS, because multiple files were using
it transitively anyways.
- rewrite certain parts of the codebase which used
ThreadTaskRunnerHandles instead of CurrentDefaultHandles.
- fix a compile issue with forward-declaration in
extensions/browser/extension_file_task_runner.h.
AX-Relnotes: n/a.
Bug: 1026641
Change-Id: I737ef32aee4e77c21eaa3a2bdc403a28322cf1b7
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4133323
Owners-Override: Gabriel Charette <gab@chromium.org>
Commit-Queue: Sean Maher <spvw@chromium.org>
Commit-Queue: Gabriel Charette <gab@chromium.org>
Reviewed-by: Gabriel Charette <gab@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1090532}
WebRTC creates encoders as needed using a factory we provide but it does
not provide any sort of mapping or context to those encoders to indicate
which video stream the encoder is producing frames for. Interestingly,
the SDP params are provided to the encoders but not the video streams so
in the past we have provided a WeakPtr to the VideoStream so the encoder
factory can pass a copy to each encoder as it is created so the encoder
can provide stats and pass on interesting SDP format info to the stream.
This worked fine when in single stream mode as no mapping was nneded,
however with the introduction of multi-stream mode, there are now N
video streams and no way to map an encoder to a stream (also we have a
problem where the 'last' video stream becomes the registered event sink
and all N encoders end up sending stats and SDP param info to the same
stream which messes the stats up and prevents framerate selection from
working).
This CL adds an event router class which uses the screen_id of the
display being captured to route events to the proper video stream. The
screen id should be stable as it is used in ClientSession to track each
video stream's lifetime.
Bug: b:24933048
Change-Id: I33285c47c61d6a744be8bb720f38b53d114c0ae1
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4103904
Commit-Queue: Joe Downing <joedow@chromium.org>
Reviewed-by: Lambros Lambrou <lambroslambrou@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1083176}
This interface has a few methods which are no longer required. I am
removing them as that simplifies the multi-threaded dance for the
classes involved. It also means less work in a follow-up CL where I add
a map for screen_id <-> VideoStream so that framerates and video stats
are delivered to the correct video stream instance.
Bug: b:249330480
Change-Id: I1a22a7510af8552877925ca3712a25f4cbcca8cc
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4098491
Reviewed-by: Lambros Lambrou <lambroslambrou@chromium.org>
Commit-Queue: Joe Downing <joedow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1082217}
The current method of using session-options to set the target framerate
works OK but it does not allow for changing the framerate within a
session w/o restarting it. Instead we should use the SDP format params
(the 'a=fmtp: ...' line in the SDP) to define the framerate as then
the client can request a renegotiation and allow the value to be
changed dynamically.
Bug: b:217468304
Change-Id: I327c18f5563ce6f015114b1acaadd8c25a7f8413
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3861027
Reviewed-by: Lambros Lambrou <lambroslambrou@chromium.org>
Commit-Queue: Joe Downing <joedow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1041220}
This is a follow-up CL to crrev.com/c/3706198 where I started running
the PostEncodeTask synchronously to prevent large gaps between encoded
frames. One issue I noticed with the synchronous approach was that
we could accumulate a large queue of tasks on slower machines since
the capture thread would keep queueing new frames and the encoder
wrapper wouldn't drop them.
In this CL I take the same idea as before but instead of running the
encoder on the same sequence as the encoder wrapper, I create a
dedicated encoder thread. Now the encoder thread can be saturated
(I've only noticed small gaps (50-100us) between the encode tasks at
high frame rates) and the encoder wrapper will accumulate changes in a
|pending_frame_| which is then scheduled as soon as the previous encode
task has completed.
Bug: b:217468304
Change-Id: I75bc81a321b21396177a31417e6b29773fc9f213
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3714797
Reviewed-by: Lambros Lambrou <lambroslambrou@chromium.org>
Commit-Queue: Joe Downing <joedow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1017270}
Per the thread with the WebRTC folks, it looks like there isn't a
preferred way to set the encoder speed from the client using an existing
mechanism. While the discussion continues on whether to update an
existing standard to allow this, I'm adding a SessionOption to configure
it for testing/performance tuning purposes.
Bug: b:217468304
Change-Id: If7a950b56853734f49c091532b7b56d865002ff5
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3712242
Reviewed-by: Jamie Walch <jamiewalch@chromium.org>
Commit-Queue: Joe Downing <joedow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1015581}
This CL adds on to a previous CL which added a SessionOption for
controlling the target framerate. I missed a usage of the constant
target value so I need to provide SessionOptions to that class.
Along they way I realized that the SessionOptions class has a GetInt
method which already does what I did in the WebrtcTransport CL I landed
so I cleaned up that callsite.
Bug: b:217468304
Change-Id: Ia81c43c8cb2a9f3dcbda3ccc15bd889ab07b79ac
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3712148
Reviewed-by: Jamie Walch <jamiewalch@chromium.org>
Commit-Queue: Joe Downing <joedow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1015577}
While digging into our capture/encode implementation, I noticed that
after each Encode() call, WebRTC would call the encoder wrapper again
which would drop the frame because encode_pending_ was true, then the
PostEncode task would run and the next encode request would occur after
a successful capture. In the graphs, this was represented by gaps in
between each encode call.
Existing code (w/ gaps): http://shortn/_obGooZhdR8
My change (no gaps): http://shortn/_zlaL1UHxYe
I tracked this down to some code which wraps the PostEncode callback
in a wrapper which ensures the task in executed on the current sequence.
This was added last year as there was some concern that the underlying
encoder could run on a different sequence. AFAICT, this is not the case
as |encoder_| is a remoting::WebrtcVideoEncoder which our team owns. The
VPX and AV1 encoders both execute synchronously and the H.264 encoder
already wraps the callback in a sequence bound PostTask a second time.
Bug: b:217468304
Change-Id: I5efd5f3362f4d91b01008d4bde56d018ecf6f8f3
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3706198
Reviewed-by: Lambros Lambrou <lambroslambrou@chromium.org>
Commit-Queue: Joe Downing <joedow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1014604}
This CL sets a number of encoder parameters tht we suggested by the WebM
folks. Initial testing with these values indicates a ~2X increase in
framerate and makes the codec usable (though it still seems a tad slower
than VP9 in my initial testing). I've also removed a NOTIMPL log from the
encoding path as it is way too chatty when using AV1.
Change-Id: Ieccc2a2e2f96e94f6dd5137c5ccb22492da3c878
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3687980
Reviewed-by: Lambros Lambrou <lambroslambrou@chromium.org>
Commit-Queue: Joe Downing <joedow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1010661}
This is a minor cleanup CL which replaces some hard-coded strings with
webrtc equivalents. I'm looking to land a webrtc change with some AV1
variations of the VP9 profile constants/function so I wanted to land
this first while I'm waiting for that CL to land.
Change-Id: I5a6032ba01534f1614ed0c4fefeaa2104b7766e3
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3671381
Auto-Submit: Joe Downing <joedow@chromium.org>
Reviewed-by: Lambros Lambrou <lambroslambrou@chromium.org>
Commit-Queue: Lambros Lambrou <lambroslambrou@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1008060}
This is a simple CL which adds a do-nothing impl and the integration
points needed for instantiating an AV1 encoder instance from the
client. I'm splitting this up as there is a fair amount of overlap
in the logic needed for VPX and AV1 (perhaps not surprising) so I
wanted to get this piece in first and then refactor the VPX encoder
so more of it can be shared between these two SW encoders.
Bug: b:217468304
Change-Id: I51f0cf6248f091332389cc9ddc3d0faa84f59a68
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3633114
Commit-Queue: Joe Downing <joedow@chromium.org>
Reviewed-by: James Zern <jzern@google.com>
Reviewed-by: Lambros Lambrou <lambroslambrou@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1002876}
This CL fixes WebrtcVideoEncoderWrapper to never drop empty frames if
WebRTC requested encoding of a key frame.
Additionally, if a frame is dropped due to the encoder being busy with
a previous frame, any key-frame request will be remembered and applied
to the next (non-dropped) frame.
Bug: 1310116
Change-Id: I6a01b4c8735c5e636ed978a31368f814d059be8c
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3556668
Auto-Submit: Lambros Lambrou <lambroslambrou@chromium.org>
Reviewed-by: Joe Downing <joedow@chromium.org>
Commit-Queue: Lambros Lambrou <lambroslambrou@chromium.org>
Cr-Commit-Position: refs/heads/main@{#986235}
This simplifies handling of some per-frame stats:
* rtt_estimate
* bandwidth_estimate
* send_pending_delay
Instead of the encoder-wrapper passing these stats to the scheduler
(via the WebrtcVideoStream), it writes them directly into the encoded
frame (EncodedFrame::stats).
WebrtcVideoStream has code to generate and send the per-frame stats
(via video_stats_dispatcher_). It got the stats above from the
scheduler, but after this CL, it no longer needs the scheduler - it
gets everything it needs from the EncodedFrame.
This means that the stats-sending code can be decoupled from the
WebrtcVideoStream, which gives more flexibility for sending the
per-frame stats for multiple video-streams.
Change-Id: I4374de49ec024b7b17d9896a473513501d9993fd
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3263654
Auto-Submit: Lambros Lambrou <lambroslambrou@chromium.org>
Reviewed-by: Joe Downing <joedow@chromium.org>
Commit-Queue: Lambros Lambrou <lambroslambrou@chromium.org>
Cr-Commit-Position: refs/heads/main@{#939677}
This removes unneeded code from the scheduler:
* Encoding parameters are no longer needed (WebrtcVideoStream no
longer uses them as it no longer creates encoders).
* Top-off encoding for empty frames is no longer handled by the
scheduler. The scheduler sends all empty frames to the output sink,
then WebRTC sends them to the encoder-wrapper which decides whether
to encode or drop them (according to whether top-off is active).
* Large-frame detection for VP8 is handled by the encoder-wrapper.
Bug: 1192865
Change-Id: I9e45b4efb80e26bbe6e6010a7a2d09ec412f11db
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3251888
Auto-Submit: Lambros Lambrou <lambroslambrou@chromium.org>
Commit-Queue: Joe Downing <joedow@chromium.org>
Reviewed-by: Joe Downing <joedow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#936119}
This CL was generated by using tools/git/move_source_file.py to change
the includes for those files:
base/bind_post_task.h
base/deferred_sequenced_task_runner.h
base/post_task_and_reply_with_result_internal.h
base/sequenced_task_runner.h
base/sequenced_task_runner_helpers.h
base/single_thread_task_runner.h
base/task_runner.h
base/task_runner_util.h
base/updateable_sequenced_task_runner.h
Then formatted using "git cl format". DEPS files were fixed with a
simple search and replace script.
Bug: 1255932
Change-Id: I0d9b5ddd9260fde5e4581e6c6e0080bdb0ed2c44
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3209175
Reviewed-by: Gabriel Charette <gab@chromium.org>
Owners-Override: Gabriel Charette <gab@chromium.org>
Commit-Queue: Gabriel Charette <gab@chromium.org>
Cr-Commit-Position: refs/heads/main@{#929867}
The scheduler's OnCapturedFrame() method returns a boolean to signal
whether the captured frame should be sent to the encoder or dropped.
This turns out to be incompatible with the standard encoding pipeline,
because WebRTC (or the encoder-wrapper) may have dropped the prior
non-empty frame. So this CL moves the empty-frame-dropping logic into
the encoder-wrapper, and the scheduler never drops frames.
This also removes some logging of dropped frames, which can become
very spammy because the encoder-wrapper can now receive frames at 33ms
intervals (30FPS).
Bug: 1226184
Change-Id: I7c006e54dbb1c888a9fd437083b37ea9c79389b4
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3018058
Commit-Queue: Lambros Lambrou <lambroslambrou@chromium.org>
Auto-Submit: Lambros Lambrou <lambroslambrou@chromium.org>
Reviewed-by: Joe Downing <joedow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#900616}
This adds an incrementing id to each DesktopFrame, and updates the
encoder-wrapper to detect if WebRTC dropped any frames. If the
encoder-wrapper receives consecutive frames (without any drops in
between), it will use the DesktopFrame's original updated-region
instead of the VideoFrame's update-rectangle that WebRTC provided to
Encode().
This means that, most of the time, the encoder will receive an
accurate updated-region instead of a bounding rectangle, which may
result in faster encode times. And the large-frame-detection logic
should be more accurate for these frames.
Bug: 1192865
Change-Id: If53e0df50c39615258ed620312fb25131b6c8fc2
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3002682
Auto-Submit: Lambros Lambrou <lambroslambrou@chromium.org>
Commit-Queue: Joe Downing <joedow@chromium.org>
Reviewed-by: Joe Downing <joedow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#898216}
This copies the large-frame-detection logic from the scheduler into
the new encoder. After the switch to standard-encoding-pipeline, the
scheduler's large-frame-detection no longer had any effect.
This is only used for VP8 (though in future, similar logic may be
used for H264). The VP9 encoder already has this feature: it
re-encodes the frame at lower quality if it detects overshoot of
target FPS.
Bug: 1192865
Change-Id: I6f7d1143182e2bd984a4bdda32de9da4bdf0b00e
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2987254
Commit-Queue: Lambros Lambrou <lambroslambrou@chromium.org>
Reviewed-by: Joe Downing <joedow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#897210}
This sets each VideoFrame's update-rectangle to match the wrapped
DesktopFrame's update-region. This ensures WebRTC knows about each
frame's update-rect so it can combine these rectangles in case it
drops a frame.
The encoder-wrapper may also drop frames itself, so this CL also
ensures that any dropped frames' update-rects are accumulated into the
next frame sent to the encoder.
Bug: 1192865
Change-Id: I3eab5119588b042730a9e93d9e7f3a01aad38c95
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2941965
Commit-Queue: Lambros Lambrou <lambroslambrou@chromium.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@chromium.org>
Cr-Commit-Position: refs/heads/master@{#891438}
With the standard encoding pipeline, the scheduler may start capturing
a new frame before the current frame has been encoded and sent. This
means that storing the stats in WebrtcVideoStream::current_frame_stats_
is inadequate. This CL enables the frame stats to be attached to each
frame, before sending it to WebRTC's output sink. The stats will be
extracted from the frame by the new encoder, then re-attached to the
corresponding EncodedFrame after encoding.
In the current legacy code, the stats are attached manually in
WebrtcVideoStream::OnFrameEncoded(). In the new code, the stats
will be attached in WebrtcVideoStream::OnCapturedFrame().
Because the stats are attached via std::unique_ptr, this CL makes
EncodedFrame into a movable-but-not-copyable type, which makes
sense anyway since the frame data can be very large.
Bug: 1192865
Change-Id: Ie8eaa03e0912009d407eafca2f90de92a1f52845
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2911526
Commit-Queue: Lambros Lambrou <lambroslambrou@chromium.org>
Reviewed-by: Joe Downing <joedow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#886533}
With the standard encoding pipeline, WebRTC will occasionally try to
encode another frame while a frame is being encoded (before the
registered encode-complete callback is run).
The remoting/codec encoders have not been developed or tested for
multiple parallel encodes. The frame-scheduler currently waits for
encode-complete before scheduling a new capture, but this will
change with standard-encoding-pipeline. So this CL protects this by
dropping any Encode() requests while a frame is still pending.
This will also ensure that the stored RTP timestamp, and per-frame
stats (when this is implemented) are valid for the frame, as there
can now be only 1 frame encoded at a time.
Bug: 1192865
Change-Id: I31cff4aea119d32e23aa7a130f43e759cf5510a6
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2911514
Auto-Submit: Lambros Lambrou <lambroslambrou@chromium.org>
Commit-Queue: Joe Downing <joedow@chromium.org>
Reviewed-by: Joe Downing <joedow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#885796}
This is a replacement for the current WebrtcDummyVideoEncoder, to be
used for the standard encoding pipeline. This class will be
instantiated by WebRTC via the VideoEncoderFactory implementation, and
it lives on whatever thread WebRTC uses internally for video-encoding.
Status notifications are passed to the VideoStream and frame-scheduler
via a VideoChannelStateObserver on the main thread.
This class handles the logic for setting encode parameters which is
currently managed by the video-scheduler (such as clear_active_map).
Bug: 1192865
Change-Id: I33b1decafdcba23870a69dbd68e835fbbac5f53f
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2878558
Reviewed-by: Ilya Nikolaevskiy <ilnik@chromium.org>
Reviewed-by: Joe Downing <joedow@chromium.org>
Commit-Queue: Lambros Lambrou <lambroslambrou@chromium.org>
Cr-Commit-Position: refs/heads/master@{#883623}
