Due to libvpx we were restricted to always turning the low simulcast
stream on, or else the encoder would always label the active streams'
encoded frames as key frames. Now that libvpx has been updated and
rolled in, this change updates tests to reflect that it is working.
Bug: webrtc:8653
Change-Id: I065ef817ace2292605e27e135802cf4a3e90647e
Reviewed-on: https://webrtc-review.googlesource.com/46340
Reviewed-by: Taylor Brandstetter <deadbeef@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Seth Hampson <shampson@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#21831}
This fix the mismatch of resolution VP9 wrapper set for coded frame with
its actual resolution.
Bug: webm:1485, webrtc:5749
Change-Id: Ie1225d8f3a3d00e66229a1a79858d0a89b3d5fae
Reviewed-on: https://webrtc-review.googlesource.com/46040
Reviewed-by: Åsa Persson <asapersson@webrtc.org>
Reviewed-by: Rasmus Brandt <brandtr@webrtc.org>
Commit-Queue: Sergey Silkin <ssilkin@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#21819}
This is a reland of bbdabe50db.
Original change's description:
> Rename stereo video codec to multiplex
>
> This CL only does the rename from"stereo" to multiplex". With this we have a
> better name that doesn't clash with audio's usage of stereo.
>
> Bug: webrtc:7671
> Change-Id: Iebc3fc20839025f1bc8bcf0e16141bf9744ef652
> Reviewed-on: https://webrtc-review.googlesource.com/43242
> Commit-Queue: Emircan Uysaler <emircan@webrtc.org>
> Reviewed-by: Niklas Enbom <niklas.enbom@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#21769}
TBR=niklas.enbom@webrtc.org
Bug: webrtc:7671
Change-Id: I6f38dc46126f279f334d52b56339b40acdc30511
Reviewed-on: https://webrtc-review.googlesource.com/45820
Reviewed-by: Emircan Uysaler <emircan@webrtc.org>
Commit-Queue: Emircan Uysaler <emircan@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#21794}
This reverts commit 4954a77cf8.
Reason for revert: Breaks downstream build which was depending on the name "kVideoCodecStereo". Will need to do some sort of trickery to make this change without breaking the relevant code. Sorry. :(
Original change's description:
> Reland "Rename stereo video codec to multiplex"
>
> This is a reland of bbdabe50db.
> This was reverted because of breaking internal build. I contacted sheriff
> and looked at logs but cannot find anything related to this CL. This was landed
> with #3850 build which caused exception, but 3847-3855 seem to all have failed.
> I am relanding to see if it will work this time or it will give some related
> error message that can guide me.
>
> Original change's description:
> > Rename stereo video codec to multiplex
> >
> > This CL only does the rename from"stereo" to multiplex". With this we have a
> > better name that doesn't clash with audio's usage of stereo.
> >
> > Bug: webrtc:7671
> > Change-Id: Iebc3fc20839025f1bc8bcf0e16141bf9744ef652
> > Reviewed-on: https://webrtc-review.googlesource.com/43242
> > Commit-Queue: Emircan Uysaler <emircan@webrtc.org>
> > Reviewed-by: Niklas Enbom <niklas.enbom@webrtc.org>
> > Cr-Commit-Position: refs/heads/master@{#21769}
>
> TBR=niklas.enbom@webrtc.org
>
> Bug: webrtc:7671
> Change-Id: I5934abad1ce28acf02842ea8ee2af7768a826eb8
> Reviewed-on: https://webrtc-review.googlesource.com/44520
> Reviewed-by: Emircan Uysaler <emircan@webrtc.org>
> Commit-Queue: Emircan Uysaler <emircan@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#21780}
TBR=sprang@webrtc.org,niklas.enbom@webrtc.org,qiangchen@chromium.org,emircan@webrtc.org
Change-Id: I0a71327c2ddfdd030b1e058cd6a41b1689836719
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: webrtc:7671
Reviewed-on: https://webrtc-review.googlesource.com/44621
Reviewed-by: Taylor Brandstetter <deadbeef@webrtc.org>
Commit-Queue: Taylor Brandstetter <deadbeef@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#21783}
This is a reland of bbdabe50db.
This was reverted because of breaking internal build. I contacted sheriff
and looked at logs but cannot find anything related to this CL. This was landed
with #3850 build which caused exception, but 3847-3855 seem to all have failed.
I am relanding to see if it will work this time or it will give some related
error message that can guide me.
Original change's description:
> Rename stereo video codec to multiplex
>
> This CL only does the rename from"stereo" to multiplex". With this we have a
> better name that doesn't clash with audio's usage of stereo.
>
> Bug: webrtc:7671
> Change-Id: Iebc3fc20839025f1bc8bcf0e16141bf9744ef652
> Reviewed-on: https://webrtc-review.googlesource.com/43242
> Commit-Queue: Emircan Uysaler <emircan@webrtc.org>
> Reviewed-by: Niklas Enbom <niklas.enbom@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#21769}
TBR=niklas.enbom@webrtc.org
Bug: webrtc:7671
Change-Id: I5934abad1ce28acf02842ea8ee2af7768a826eb8
Reviewed-on: https://webrtc-review.googlesource.com/44520
Reviewed-by: Emircan Uysaler <emircan@webrtc.org>
Commit-Queue: Emircan Uysaler <emircan@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#21780}
This reverts commit bbdabe50db.
Reason for revert: This breaks the internal build.
Original change's description:
> Rename stereo video codec to multiplex
>
> This CL only does the rename from"stereo" to multiplex". With this we have a
> better name that doesn't clash with audio's usage of stereo.
>
> Bug: webrtc:7671
> Change-Id: Iebc3fc20839025f1bc8bcf0e16141bf9744ef652
> Reviewed-on: https://webrtc-review.googlesource.com/43242
> Commit-Queue: Emircan Uysaler <emircan@webrtc.org>
> Reviewed-by: Niklas Enbom <niklas.enbom@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#21769}
TBR=sprang@webrtc.org,niklas.enbom@webrtc.org,qiangchen@chromium.org,emircan@webrtc.org
Change-Id: Icf019cb09e07de45821d31d7d8ea7707d01346ee
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: webrtc:7671
Reviewed-on: https://webrtc-review.googlesource.com/44360
Commit-Queue: Ivo Creusen <ivoc@webrtc.org>
Reviewed-by: Ivo Creusen <ivoc@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#21774}
This reverts commit 4dc891f5e3.
Reason for revert: Reverting this CL to make it possible to revert https://webrtc-review.googlesource.com/c/src/+/43242
Original change's description:
> Add unit tests covering MultiplexImageComponent
>
> This CL changes some types in MultiplexImage and MultiplexImageComponent. Also,
> adds unit test coverage in TestMultiplexAdapter for these structs.
>
> Bug: webrtc:7671
> Change-Id: I832d0466dc67d3b6b7fa0d3fb76f02c0190e474f
> Reviewed-on: https://webrtc-review.googlesource.com/44081
> Commit-Queue: Emircan Uysaler <emircan@webrtc.org>
> Reviewed-by: Qiang Chen <qiangchen@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#21770}
TBR=qiangchen@chromium.org,emircan@webrtc.org
Change-Id: I9cce6ed5f2990a2f443e04a9e5913cbd296242e4
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: webrtc:7671
Reviewed-on: https://webrtc-review.googlesource.com/44341
Reviewed-by: Ivo Creusen <ivoc@webrtc.org>
Commit-Queue: Ivo Creusen <ivoc@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#21773}
This CL changes some types in MultiplexImage and MultiplexImageComponent. Also,
adds unit test coverage in TestMultiplexAdapter for these structs.
Bug: webrtc:7671
Change-Id: I832d0466dc67d3b6b7fa0d3fb76f02c0190e474f
Reviewed-on: https://webrtc-review.googlesource.com/44081
Commit-Queue: Emircan Uysaler <emircan@webrtc.org>
Reviewed-by: Qiang Chen <qiangchen@chromium.org>
Cr-Commit-Position: refs/heads/master@{#21770}
This CL only does the rename from"stereo" to multiplex". With this we have a
better name that doesn't clash with audio's usage of stereo.
Bug: webrtc:7671
Change-Id: Iebc3fc20839025f1bc8bcf0e16141bf9744ef652
Reviewed-on: https://webrtc-review.googlesource.com/43242
Commit-Queue: Emircan Uysaler <emircan@webrtc.org>
Reviewed-by: Niklas Enbom <niklas.enbom@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#21769}
This is in preparation for
https://webrtc-review.googlesource.com/c/src/+/36340
With these changes we can avoid some strange #ifdefs in the code
that uses temporal layers.
Bug: webrtc:7925
Change-Id: I472210738ccc9f73812b8863951befeabec56f15
Reviewed-on: https://webrtc-review.googlesource.com/41280
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Anders Carlsson <andersc@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#21759}
This CL is a followup to https://webrtc-review.googlesource.com/c/src/+/38481.
With the new approach we can just use the generic RTP packetizer to pass frames
over the wire as the specific info is contained within the bitstream. This makes
the new codec more modular and reduces its footprint.
Bug: webrtc:7671
Change-Id: Ib07f72a9d338e3cbfdbf39cba9891a959b5f7552
Reviewed-on: https://webrtc-review.googlesource.com/43220
Reviewed-by: Niklas Enbom <niklas.enbom@webrtc.org>
Commit-Queue: Emircan Uysaler <emircan@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#21753}
This reverts commit d756fd06fe.
Original change's description:
> Revert "Wrap Alpha and YUV frame into one EncodedImage for transmission"
>
> This reverts commit 5670c86aec.
>
> Reason for revert: Breaks downstream build. Need to add "#include <cstring>" to stereo_encoder_adapter.cc to use std::memcpy.
>
> Original change's description:
> > Wrap Alpha and YUV frame into one EncodedImage for transmission
> >
> > With alpha channel, we observe the artifacts on the receiver side, and
> > the reason is that when YUV channel has a key frame, it gives frame_buffer2
> > a chance to drop some previous frames. Then it is possible that some alpha
> > frames got dropped, which break the alpha frame dependence chain.
> >
> > In this CL, we pack the YUV frame and alpha encoded frame together as one
> > entity to solve the issue.
> >
> > Bug: webrtc:8773
> > Change-Id: Ibe746a46cb41fd92b399a7069e1d89f02f292af7
> > Reviewed-on: https://webrtc-review.googlesource.com/38481
> > Commit-Queue: Qiang Chen <qiangchen@chromium.org>
> > Reviewed-by: Emircan Uysaler <emircan@webrtc.org>
> > Cr-Commit-Position: refs/heads/master@{#21737}
>
> TBR=qiangchen@chromium.org,emircan@webrtc.org
>
> Change-Id: I11eff814ce093bf6db327ebcd21b1b71a1929849
> No-Presubmit: true
> No-Tree-Checks: true
> No-Try: true
> Bug: webrtc:8773
> Reviewed-on: https://webrtc-review.googlesource.com/43260
> Reviewed-by: Taylor Brandstetter <deadbeef@webrtc.org>
> Commit-Queue: Taylor Brandstetter <deadbeef@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#21739}
TBR=deadbeef@webrtc.org,qiangchen@chromium.org,emircan@webrtc.org
Change-Id: I0d64b7e7a62e4f35aa012270d3826a23b3fb2337
Bug: webrtc:8773
Reviewed-on: https://webrtc-review.googlesource.com/43440
Commit-Queue: Qiang Chen <qiangchen@chromium.org>
Reviewed-by: Qiang Chen <qiangchen@chromium.org>
Cr-Commit-Position: refs/heads/master@{#21749}
Each simulcast stream requires dedicated decoder for decoding. SVC
can be decoded by single decoder. But in prod each receiver has its
decoder. We want to replicate this and also use one decoder per
spatial layer.
Also we create one frame writer per simulcast/spatial layer to dump
encoded/decoded frames of different layers to separate files.
Note that videoprocessor is still initialized with single
decoder/writer. It will be updated in next CL and start using
separate decoder/writer per layer.
Bug: webrtc:8524
Change-Id: I3bb3de77f97d51138b8b7675dd01bc281a078b2f
Reviewed-on: https://webrtc-review.googlesource.com/43280
Commit-Queue: Sergey Silkin <ssilkin@webrtc.org>
Reviewed-by: Åsa Persson <asapersson@webrtc.org>
Reviewed-by: Rasmus Brandt <brandtr@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#21744}
These parameters allow to configure number of simulcast/spatial layers
in video codec tests.
Bug: webrtc:8524
Change-Id: Iad1332732758a8297abcf740c24c483e5fccec9a
Reviewed-on: https://webrtc-review.googlesource.com/43020
Commit-Queue: Sergey Silkin <ssilkin@webrtc.org>
Reviewed-by: Rasmus Brandt <brandtr@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#21741}
This reverts commit 5670c86aec.
Reason for revert: Breaks downstream build. Need to add "#include <cstring>" to stereo_encoder_adapter.cc to use std::memcpy.
Original change's description:
> Wrap Alpha and YUV frame into one EncodedImage for transmission
>
> With alpha channel, we observe the artifacts on the receiver side, and
> the reason is that when YUV channel has a key frame, it gives frame_buffer2
> a chance to drop some previous frames. Then it is possible that some alpha
> frames got dropped, which break the alpha frame dependence chain.
>
> In this CL, we pack the YUV frame and alpha encoded frame together as one
> entity to solve the issue.
>
> Bug: webrtc:8773
> Change-Id: Ibe746a46cb41fd92b399a7069e1d89f02f292af7
> Reviewed-on: https://webrtc-review.googlesource.com/38481
> Commit-Queue: Qiang Chen <qiangchen@chromium.org>
> Reviewed-by: Emircan Uysaler <emircan@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#21737}
TBR=qiangchen@chromium.org,emircan@webrtc.org
Change-Id: I11eff814ce093bf6db327ebcd21b1b71a1929849
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: webrtc:8773
Reviewed-on: https://webrtc-review.googlesource.com/43260
Reviewed-by: Taylor Brandstetter <deadbeef@webrtc.org>
Commit-Queue: Taylor Brandstetter <deadbeef@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#21739}
With alpha channel, we observe the artifacts on the receiver side, and
the reason is that when YUV channel has a key frame, it gives frame_buffer2
a chance to drop some previous frames. Then it is possible that some alpha
frames got dropped, which break the alpha frame dependence chain.
In this CL, we pack the YUV frame and alpha encoded frame together as one
entity to solve the issue.
Bug: webrtc:8773
Change-Id: Ibe746a46cb41fd92b399a7069e1d89f02f292af7
Reviewed-on: https://webrtc-review.googlesource.com/38481
Commit-Queue: Qiang Chen <qiangchen@chromium.org>
Reviewed-by: Emircan Uysaler <emircan@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#21737}
Try to use frame timestamps first if they look reasonable, otherwise
use realtime clock.
Also, lower limit from 90% of target to 85%.
Bug: webrtc:4172, chromium:802290
Change-Id: Iad489be7c7cf637345be4795e5089936ab9fab07
Reviewed-on: https://webrtc-review.googlesource.com/41041
Commit-Queue: Erik Språng <sprang@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#21729}
This feature is not needed in video codec testing framework. In WebRTC
video codecs never deal with packet loss. Packet loss is handled by
jitter buffer which prevents passing of incomplete frames to decoder.
Bug: webrtc:8768
Change-Id: I211cf51d913bec6a1f935e30691661d428ebd3b6
Reviewed-on: https://webrtc-review.googlesource.com/40740
Commit-Queue: Sergey Silkin <ssilkin@webrtc.org>
Reviewed-by: Stefan Holmer <stefan@webrtc.org>
Reviewed-by: Rasmus Brandt <brandtr@webrtc.org>
Reviewed-by: Åsa Persson <asapersson@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#21722}
No stats is logged in this format any longer.
Bug: none
Change-Id: I5f91e93636b6d03ebd91c3b2518857275fb94de7
Reviewed-on: https://webrtc-review.googlesource.com/40700
Reviewed-by: Sergey Silkin <ssilkin@webrtc.org>
Reviewed-by: Rasmus Brandt <brandtr@webrtc.org>
Commit-Queue: Åsa Persson <asapersson@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#21690}
This is a reland of 18c4261339
Original change's description:
> Enables/disables simulcast streams by allocating a bitrate of 0 to the spatial layer.
>
> Creates VideoStreams & VideoCodec.simulcastStreams with an active field, and then allocates 0 bitrate to simulcast streams that are inactive. This turns off the encoder for specific simulcast streams.
>
> Bug: webrtc:8653
> Change-Id: Id93b03dcd8d1191a7d3300bd77882c8af96ee469
> Reviewed-on: https://webrtc-review.googlesource.com/37740
> Reviewed-by: Stefan Holmer <stefan@webrtc.org>
> Reviewed-by: Taylor Brandstetter <deadbeef@webrtc.org>
> Reviewed-by: Erik Språng <sprang@webrtc.org>
> Commit-Queue: Seth Hampson <shampson@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#21646}
TBR=sprang@webrtc.org,stefan@webrtc.org,deadbeef@webrtc.org
Bug: webrtc:8630
Change-Id: Ib3df6f9b7158bff362a7ec66fc57e368682c5846
Reviewed-on: https://webrtc-review.googlesource.com/40980
Reviewed-by: Seth Hampson <shampson@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Seth Hampson <shampson@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#21688}
This is a reland of 1880c7162b
Original change's description:
> Updated analysis in videoprocessor.
>
> - Run analysis after all frames are processed. Before part of it was
> done at bitrate change points;
> - Analysis is done for whole stream as well as for each rate update
> interval;
> - Changed units from number of frames to time units for some metrics
> and thresholds. E.g. 'num frames to hit tagret bitrate' is changed to
> 'time to reach target bitrate, sec';
> - Changed data type of FrameStatistic::max_nalu_length (renamed to
> max_nalu_size_bytes) from rtc::Optional to size_t. There it no need to
> use such advanced data type in such low level data structure.
>
> Bug: webrtc:8524
> Change-Id: Ic9f6eab5b15ee12a80324b1f9c101de1bf3c702f
> Reviewed-on: https://webrtc-review.googlesource.com/31901
> Commit-Queue: Sergey Silkin <ssilkin@webrtc.org>
> Reviewed-by: Stefan Holmer <stefan@webrtc.org>
> Reviewed-by: Åsa Persson <asapersson@webrtc.org>
> Reviewed-by: Rasmus Brandt <brandtr@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#21653}
TBR=brandtr@webrtc.org, stefan@webrtc.org
Bug: webrtc:8524
Change-Id: Ie0ad7790689422ffa61da294967fc492a13b75ae
Reviewed-on: https://webrtc-review.googlesource.com/40202
Commit-Queue: Sergey Silkin <ssilkin@webrtc.org>
Reviewed-by: Sergey Silkin <ssilkin@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#21668}
This reverts commit 1880c7162b.
Reason for revert: breaks internal tests
Original change's description:
> Updated analysis in videoprocessor.
>
> - Run analysis after all frames are processed. Before part of it was
> done at bitrate change points;
> - Analysis is done for whole stream as well as for each rate update
> interval;
> - Changed units from number of frames to time units for some metrics
> and thresholds. E.g. 'num frames to hit tagret bitrate' is changed to
> 'time to reach target bitrate, sec';
> - Changed data type of FrameStatistic::max_nalu_length (renamed to
> max_nalu_size_bytes) from rtc::Optional to size_t. There it no need to
> use such advanced data type in such low level data structure.
>
> Bug: webrtc:8524
> Change-Id: Ic9f6eab5b15ee12a80324b1f9c101de1bf3c702f
> Reviewed-on: https://webrtc-review.googlesource.com/31901
> Commit-Queue: Sergey Silkin <ssilkin@webrtc.org>
> Reviewed-by: Stefan Holmer <stefan@webrtc.org>
> Reviewed-by: Åsa Persson <asapersson@webrtc.org>
> Reviewed-by: Rasmus Brandt <brandtr@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#21653}
TBR=brandtr@webrtc.org,asapersson@webrtc.org,sprang@webrtc.org,stefan@webrtc.org,ssilkin@webrtc.org
Change-Id: Id0b7d387bbba02e71637b229aeed6f6cf012af46
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: webrtc:8524
Reviewed-on: https://webrtc-review.googlesource.com/40220
Reviewed-by: Sergey Silkin <ssilkin@webrtc.org>
Commit-Queue: Sergey Silkin <ssilkin@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#21656}
This reverts commit 16beea7c90.
Reason for revert: breaks internal tests.
Original change's description:
> Set encodedWidth/encodedHeight to actual coded resolution.
>
> This fixes mismatch between resolution of coded frame indicated by VP9
> encoder wrapper and actual coded resolution. If internal resize is
> enabled VP9 encoder might downscale input frame when bitrate is too low
> to keep good spatial quality. Before this fix VP9 wrapper always set
> coded resolution equal to input resolution. Now it sets it to actual
> coded resolution which it reads from frame pkt.
>
> Bug: webrtc:5749
> Change-Id: I7dc8ba89947e99213a3b4c3cd4d974b662f090c4
> Reviewed-on: https://webrtc-review.googlesource.com/39661
> Reviewed-by: Åsa Persson <asapersson@webrtc.org>
> Reviewed-by: Rasmus Brandt <brandtr@webrtc.org>
> Commit-Queue: Sergey Silkin <ssilkin@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#21651}
TBR=brandtr@webrtc.org,asapersson@webrtc.org,ssilkin@webrtc.org
Change-Id: I32cb1271c863cf435f3fc3b465e11232cbd6a888
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: webrtc:5749
Reviewed-on: https://webrtc-review.googlesource.com/40161
Reviewed-by: Sergey Silkin <ssilkin@webrtc.org>
Commit-Queue: Sergey Silkin <ssilkin@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#21655}
- Run analysis after all frames are processed. Before part of it was
done at bitrate change points;
- Analysis is done for whole stream as well as for each rate update
interval;
- Changed units from number of frames to time units for some metrics
and thresholds. E.g. 'num frames to hit tagret bitrate' is changed to
'time to reach target bitrate, sec';
- Changed data type of FrameStatistic::max_nalu_length (renamed to
max_nalu_size_bytes) from rtc::Optional to size_t. There it no need to
use such advanced data type in such low level data structure.
Bug: webrtc:8524
Change-Id: Ic9f6eab5b15ee12a80324b1f9c101de1bf3c702f
Reviewed-on: https://webrtc-review.googlesource.com/31901
Commit-Queue: Sergey Silkin <ssilkin@webrtc.org>
Reviewed-by: Stefan Holmer <stefan@webrtc.org>
Reviewed-by: Åsa Persson <asapersson@webrtc.org>
Reviewed-by: Rasmus Brandt <brandtr@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#21653}
This fixes mismatch between resolution of coded frame indicated by VP9
encoder wrapper and actual coded resolution. If internal resize is
enabled VP9 encoder might downscale input frame when bitrate is too low
to keep good spatial quality. Before this fix VP9 wrapper always set
coded resolution equal to input resolution. Now it sets it to actual
coded resolution which it reads from frame pkt.
Bug: webrtc:5749
Change-Id: I7dc8ba89947e99213a3b4c3cd4d974b662f090c4
Reviewed-on: https://webrtc-review.googlesource.com/39661
Reviewed-by: Åsa Persson <asapersson@webrtc.org>
Reviewed-by: Rasmus Brandt <brandtr@webrtc.org>
Commit-Queue: Sergey Silkin <ssilkin@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#21651}
This reverts commit 18c4261339.
Reason for revert: Broke internal tests
Original change's description:
> Enables/disables simulcast streams by allocating a bitrate of 0 to the spatial layer.
>
> Creates VideoStreams & VideoCodec.simulcastStreams with an active field, and then allocates 0 bitrate to simulcast streams that are inactive. This turns off the encoder for specific simulcast streams.
>
> Bug: webrtc:8653
> Change-Id: Id93b03dcd8d1191a7d3300bd77882c8af96ee469
> Reviewed-on: https://webrtc-review.googlesource.com/37740
> Reviewed-by: Stefan Holmer <stefan@webrtc.org>
> Reviewed-by: Taylor Brandstetter <deadbeef@webrtc.org>
> Reviewed-by: Erik Språng <sprang@webrtc.org>
> Commit-Queue: Seth Hampson <shampson@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#21646}
TBR=deadbeef@webrtc.org,sprang@webrtc.org,stefan@webrtc.org,shampson@webrtc.org
Change-Id: I0aeb743cbd2e8d564aa732c937587c25a4c49b09
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: webrtc:8653
Reviewed-on: https://webrtc-review.googlesource.com/39883
Reviewed-by: Lu Liu <lliuu@webrtc.org>
Commit-Queue: Lu Liu <lliuu@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#21647}
Creates VideoStreams & VideoCodec.simulcastStreams with an active field, and then allocates 0 bitrate to simulcast streams that are inactive. This turns off the encoder for specific simulcast streams.
Bug: webrtc:8653
Change-Id: Id93b03dcd8d1191a7d3300bd77882c8af96ee469
Reviewed-on: https://webrtc-review.googlesource.com/37740
Reviewed-by: Stefan Holmer <stefan@webrtc.org>
Reviewed-by: Taylor Brandstetter <deadbeef@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Seth Hampson <shampson@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#21646}
This is a reland of https://webrtc-review.googlesource.com/34380
The main problem with that CL was that we used frame timestamps as basis
for frame dropping, but those might not be continuous or even populated
in some circumstances.
Additionally, I found that the bitrate was off since the encoder does
not not take the dropped frames into account, so if we drop every other
frame continiusoly, the bitrate sent will be around half of the target.
Patch set 1 is the original CL, subsequent patch sets cotains fixes.
Bug: webrtc:4172
Change-Id: I8ec8dddcebf4ce44f28dd9055cf9c46bbd68e4a6
Reviewed-on: https://webrtc-review.googlesource.com/39201
Commit-Queue: Erik Språng <sprang@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#21601}
We currently use raw jobject in our code mixed with sporadic
ScopedLocalRefFrame. This CL moves every jobject into a scoped object,
either local, global, or a parameter. Also, this CL uses the JNI
generation script to generate declaration stubs for the Java->C++
functions so that it no longer becomes possible to mistype them
without getting compilation errors.
TBR=brandt@webrtc.org
Bug: webrtc:8278,webrtc:6969
Change-Id: Ic7bac74a89c11180177d65041086d7db1cdfb516
Reviewed-on: https://webrtc-review.googlesource.com/34655
Commit-Queue: Magnus Jedvert <magjed@webrtc.org>
Reviewed-by: Sami Kalliomäki <sakal@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#21387}
This reverts commit 28a06b16cc.
Reason for revert: Causes some unexpected perf changes.
Original change's description:
> Smoother frame dropping when screenshare_layers limits fps
>
> Currently, when input fps is higher than the configured target fps in
> screenshare_layers, we drop frames with the help of a rate tracker using
> a one second sliding window. This is not optimal.
> For instance, given a 5fps limit and a 30fps capturer, the window will
> not be saturated until we have added the first 5 frames. Then we will
> drop all frames until the oldest one drops out, at which point we can
> immediately fill it's place. This results in quick 5 frame bursts every
> second.
>
> In addition to rate tracker, also set a limit on minimum interval
> required between input frames, based on target frame rate.
>
> Bug: webrtc:4172
> Change-Id: I49f0abf4d549673cc6b3fafe580b529ea3feaf57
> Reviewed-on: https://webrtc-review.googlesource.com/34380
> Commit-Queue: Erik Språng <sprang@webrtc.org>
> Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#21325}
TBR=ilnik@webrtc.org,sprang@webrtc.org
Change-Id: I7ca5b0c847310dbb11dce28773082eac946c0ba4
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: webrtc:4172
Reviewed-on: https://webrtc-review.googlesource.com/34780
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#21354}
Currently, when input fps is higher than the configured target fps in
screenshare_layers, we drop frames with the help of a rate tracker using
a one second sliding window. This is not optimal.
For instance, given a 5fps limit and a 30fps capturer, the window will
not be saturated until we have added the first 5 frames. Then we will
drop all frames until the oldest one drops out, at which point we can
immediately fill it's place. This results in quick 5 frame bursts every
second.
In addition to rate tracker, also set a limit on minimum interval
required between input frames, based on target frame rate.
Bug: webrtc:4172
Change-Id: I49f0abf4d549673cc6b3fafe580b529ea3feaf57
Reviewed-on: https://webrtc-review.googlesource.com/34380
Commit-Queue: Erik Språng <sprang@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#21325}
TBR=brandtr@webrtc.org,stefan@webrtc.org
Currently |bw_resolutions_disabled| is set per VP8EncoderImpl instance and reported via
OnEncodedImage callback.
Instead move logic to SendStatisticsProxy to determine if resolution is bw limited or not based
on info that is reported to SendStatisticsProxy::OnEncodedImage.
Bug: webrtc:8643
Change-Id: I553cea30dcda34b753b5224f15094a1b7b70a750
Reviewed-on: https://webrtc-review.googlesource.com/31460
Reviewed-by: Rasmus Brandt <brandtr@webrtc.org>
Reviewed-by: Stefan Holmer <stefan@webrtc.org>
Commit-Queue: Åsa Persson <asapersson@webrtc.org>
Cr-Original-Commit-Position: refs/heads/master@{#21249}
Reviewed-on: https://webrtc-review.googlesource.com/33360
Reviewed-by: Åsa Persson <asapersson@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#21319}
This reverts commit 59283e4c66.
Reason for revert: This CL is preventing rolls into Chromium because it fails to compile with MSVC.
Sample error log:
[13258/43857] CXX obj/third_party/webrtc/video/video/send_statistics_proxy.obj
FAILED: obj/third_party/webrtc/video/video/send_statistics_proxy.obj
ninja -t msvc -e environment.x64 -- E:\b\c\goma_client/gomacc.exe "e:\b\c\win_toolchain\vs_files\a9e1098bba66d2acccc377d5ee81265910f29272\vc\tools\msvc\14.11.25503\bin\hostx64\x64/cl.exe" /nologo /showIncludes @obj/third_party/webrtc/video/video/send_statistics_proxy.obj.rsp /c ../../third_party/webrtc/video/send_statistics_proxy.cc /Foobj/third_party/webrtc/video/video/send_statistics_proxy.obj /Fd"obj/third_party/webrtc/video/video_cc.pdb"
../../third_party/webrtc/video/send_statistics_proxy.cc(217): error C2220: warning treated as error - no 'object' file generated
../../third_party/webrtc/video/send_statistics_proxy.cc(217): warning C4267: 'initializing': conversion from 'size_t' to 'int', possible loss of data
../../third_party/webrtc/video/send_statistics_proxy.cc(632): warning C4267: '=': conversion from 'size_t' to 'uint32_t', possible loss of data
Original change's description:
> googBandwidthLimitedResolution stat is not always set depending on configuration.
>
> Currently |bw_resolutions_disabled| is set per VP8EncoderImpl instance and reported via
> OnEncodedImage callback.
>
> Instead move logic to SendStatisticsProxy to determine if resolution is bw limited or not based
> on info that is reported to SendStatisticsProxy::OnEncodedImage.
>
> Bug: webrtc:8643
> Change-Id: I6c148e3507a0f04a793775b9f84ce54028b64d0f
> Reviewed-on: https://webrtc-review.googlesource.com/31460
> Reviewed-by: Rasmus Brandt <brandtr@webrtc.org>
> Reviewed-by: Stefan Holmer <stefan@webrtc.org>
> Commit-Queue: Åsa Persson <asapersson@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#21249}
TBR=brandtr@webrtc.org,asapersson@webrtc.org,stefan@webrtc.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: webrtc:8643
Change-Id: Ib9ef55b8894ea72236a5dc1e9a839adecd401afb
Reviewed-on: https://webrtc-review.googlesource.com/33100
Reviewed-by: Guido Urdaneta <guidou@webrtc.org>
Commit-Queue: Guido Urdaneta <guidou@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#21284}
Currently |bw_resolutions_disabled| is set per VP8EncoderImpl instance and reported via
OnEncodedImage callback.
Instead move logic to SendStatisticsProxy to determine if resolution is bw limited or not based
on info that is reported to SendStatisticsProxy::OnEncodedImage.
Bug: webrtc:8643
Change-Id: I6c148e3507a0f04a793775b9f84ce54028b64d0f
Reviewed-on: https://webrtc-review.googlesource.com/31460
Reviewed-by: Rasmus Brandt <brandtr@webrtc.org>
Reviewed-by: Stefan Holmer <stefan@webrtc.org>
Commit-Queue: Åsa Persson <asapersson@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#21249}
FFMpeg H264 decoder uses YUVJ420 when video_full_range_flag=1 in
bitstream.
Information about color range might be useful for color converter
and renderer. But currently there is no way to extract it from
the wrapper.
Bug: webrtc:8185
Change-Id: Ifd1113f0eee3d7b5906d0cefbc29b4a1061262f6
Reviewed-on: https://webrtc-review.googlesource.com/32000
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Sergey Silkin <ssilkin@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#21246}
The problem was that the encoder was feeded with frames that had 0 as
a timestamp. This confused the encoder. H264 high profile support
clause was also wrong and is corrected.
Bug: webrtc:8601
Change-Id: Ic5a893b4b7573e694f865b63620843b2c9aa489f
Reviewed-on: https://webrtc-review.googlesource.com/32300
Reviewed-by: Magnus Jedvert <magjed@webrtc.org>
Reviewed-by: Rasmus Brandt <brandtr@webrtc.org>
Commit-Queue: Sami Kalliomäki <sakal@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#21234}
Concealment is never used in WebRTC since we never feed decoders with
broken bitstream. If so, there is no need to evaluate concealment
quality.
But if we still want to evaluate it then the tests should be
redesigned: recovery frames should be generated with reasonable
interval and quality thresholds should be set to acceptable level.
Bug: webrtc:8524
Change-Id: Ie7197e0a5a88aafcb3b2698185edcb43b71fae3b
Reviewed-on: https://webrtc-review.googlesource.com/32303
Commit-Queue: Sergey Silkin <ssilkin@webrtc.org>
Reviewed-by: Rasmus Brandt <brandtr@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#21230}
- Defines stereo codec case, similar to RTX, that adds stereo codec to the SDP
negotiation. The underlying codec's payload type is similarly defined by "apt".
- If this negotiation is successful, codec name is included in sdp line via
"acn".
- Adds codec setting initializers for these specific stereo cases.
- Introduces new Stereo*Factory classes as optional convenience wrappers that
inserts stereo codec to the existing set of supported codecs on demand.
This CL is the step 5 for adding alpha channel support over the wire in webrtc.
Design Doc: https://goo.gl/sFeSUT
Bug: webrtc:7671
Change-Id: Ie12c56c8fcf7934e216135d73af33adec5248f76
Reviewed-on: https://webrtc-review.googlesource.com/22901
Commit-Queue: Niklas Enbom <niklas.enbom@webrtc.org>
Reviewed-by: Niklas Enbom <niklas.enbom@webrtc.org>
Reviewed-by: Magnus Jedvert <magjed@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#21210}
Using fully qualified paths to include libyuv headers allows WebRTC to
avoid to rely on the //third_party/libyuv:libyuv_config target to
set the -I compiler flag.
Today some WebRTC targets depend on //third_party/libyuv only to
include //third_party/libyuv:libyuv_config but with fully qualified
paths this should not be needed anymore.
A follow-up CL will remove //third_party/libyuv from some targets that
don't need it because they are not including libyuv headers.
Bug: webrtc:8605
Change-Id: Icec707ca761aaf2ea8088e7f7a05ddde0de2619a
No-Try: True
Reviewed-on: https://webrtc-review.googlesource.com/28220
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Magnus Flodman <mflodman@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#21209}
WebRTC standalone tests show 24% speed up on foreman_cif, 16% speed up
on a 240p clip and 11% speed up on Bridge_r180.
Bug: None
Change-Id: I433b7a8841bd9df2402575f72dd1984cc5e011a9
Reviewed-on: https://webrtc-review.googlesource.com/29260
Commit-Queue: Jerome Jiang <jianj@google.com>
Reviewed-by: Magnus Flodman <mflodman@webrtc.org>
Reviewed-by: Rasmus Brandt <brandtr@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#21096}
This will also cause us to use the new Android HardwareVideoEncoder,
instead of the deprecated MediaCodecVideoEncoderFactory. Unfortunately,
the new HW encoder does not seem to work as good as the old (or the new
encoder is more strict with return values or something). I don't think
it adds much value to continue testing the deprecated encoder, so I
filed a bug for fixing the new encoder, and in this CL I disabled the
tests on Android. I want to remove as many places as possible where we
use the old WebRtcVideoEncoderFactory interface, because it makes it
more difficult to migrate to the new interface.
Bug: webrtc:7925
Change-Id: If8e34752148a5e5139944d2dfbe7e231fe58aeb9
Reviewed-on: https://webrtc-review.googlesource.com/27540
Commit-Queue: Magnus Jedvert <magjed@webrtc.org>
Reviewed-by: Sami Kalliomäki <sakal@webrtc.org>
Reviewed-by: Rasmus Brandt <brandtr@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#21037}
Changes places where we explicitly construct an Optional to instead use
nullopt or the requisite value type only.
This CL was uploaded by git cl split.
R=sprang@webrtc.org
Bug: None
Change-Id: Ic429f28a8610ca798e29c45ec1f64604d6f9687f
Reviewed-on: https://webrtc-review.googlesource.com/23603
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Oskar Sundbom <ossu@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#20955}
This is a reland of 20f2133d5d
Original change's description:
> Add stereo codec header and pass it through RTP
>
> - Defines CodecSpecificInfoStereo that carries stereo specific header info from
> encoded image.
> - Defines RTPVideoHeaderStereo that carries the above info to packetizer,
> see module_common_types.h.
> - Adds an RTPPacketizer and RTPDepacketizer that supports passing specific stereo
> header.
> - Uses new data containers in StereoAdapter classes.
>
> This CL is the step 3 for adding alpha channel support over the wire in webrtc.
> See https://webrtc-review.googlesource.com/c/src/+/7800 for the experimental
> CL that gives an idea about how it will come together.
> Design Doc: https://goo.gl/sFeSUT
>
> Bug: webrtc:7671
> Change-Id: Ia932568fdd7065ba104afd2bc0ecf25a765748ab
> Reviewed-on: https://webrtc-review.googlesource.com/22900
> Reviewed-by: Emircan Uysaler <emircan@webrtc.org>
> Reviewed-by: Erik Språng <sprang@webrtc.org>
> Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
> Reviewed-by: Niklas Enbom <niklas.enbom@webrtc.org>
> Commit-Queue: Emircan Uysaler <emircan@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#20920}
TBR=danilchap@webrtc.org, sprang@webrtc.org, niklas.enbom@webrtc.org
Bug: webrtc:7671
Change-Id: If8f0c7e6e3a2a704f19161f0e8bf1880906e7fe0
Reviewed-on: https://webrtc-review.googlesource.com/27160
Reviewed-by: Emircan Uysaler <emircan@webrtc.org>
Commit-Queue: Emircan Uysaler <emircan@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#20946}
This reverts commit 20f2133d5d.
Reason for revert: Breaks downstream project.
Original change's description:
> Add stereo codec header and pass it through RTP
>
> - Defines CodecSpecificInfoStereo that carries stereo specific header info from
> encoded image.
> - Defines RTPVideoHeaderStereo that carries the above info to packetizer,
> see module_common_types.h.
> - Adds an RTPPacketizer and RTPDepacketizer that supports passing specific stereo
> header.
> - Uses new data containers in StereoAdapter classes.
>
> This CL is the step 3 for adding alpha channel support over the wire in webrtc.
> See https://webrtc-review.googlesource.com/c/src/+/7800 for the experimental
> CL that gives an idea about how it will come together.
> Design Doc: https://goo.gl/sFeSUT
>
> Bug: webrtc:7671
> Change-Id: Ia932568fdd7065ba104afd2bc0ecf25a765748ab
> Reviewed-on: https://webrtc-review.googlesource.com/22900
> Reviewed-by: Emircan Uysaler <emircan@webrtc.org>
> Reviewed-by: Erik Språng <sprang@webrtc.org>
> Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
> Reviewed-by: Niklas Enbom <niklas.enbom@webrtc.org>
> Commit-Queue: Emircan Uysaler <emircan@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#20920}
TBR=danilchap@webrtc.org,sprang@webrtc.org,stefan@webrtc.org,niklas.enbom@webrtc.org,emircan@webrtc.org
Change-Id: I57f3172ca3c60a84537d577a574dc8018e12d634
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: webrtc:7671
Reviewed-on: https://webrtc-review.googlesource.com/26940
Reviewed-by: Philip Eliasson <philipel@webrtc.org>
Commit-Queue: Philip Eliasson <philipel@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#20931}
- Defines CodecSpecificInfoStereo that carries stereo specific header info from
encoded image.
- Defines RTPVideoHeaderStereo that carries the above info to packetizer,
see module_common_types.h.
- Adds an RTPPacketizer and RTPDepacketizer that supports passing specific stereo
header.
- Uses new data containers in StereoAdapter classes.
This CL is the step 3 for adding alpha channel support over the wire in webrtc.
See https://webrtc-review.googlesource.com/c/src/+/7800 for the experimental
CL that gives an idea about how it will come together.
Design Doc: https://goo.gl/sFeSUT
Bug: webrtc:7671
Change-Id: Ia932568fdd7065ba104afd2bc0ecf25a765748ab
Reviewed-on: https://webrtc-review.googlesource.com/22900
Reviewed-by: Emircan Uysaler <emircan@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Niklas Enbom <niklas.enbom@webrtc.org>
Commit-Queue: Emircan Uysaler <emircan@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#20920}
