Was thought to be only flaky on Mac, but just failed on Win SyzyASan.
So, disabling until flakiness is fixed.
BUG=webrtc:4332
TBR=pbos@webrtc.org
NOTRY=True
Review-Url: https://codereview.webrtc.org/2104583002
Cr-Commit-Position: refs/heads/master@{#13303}
Reason for revert:
Reverting the revert. This change is not related to the failure on the Windows FYI bots. The cause of the failure has been reverted in Chromium:
https://codereview.chromium.org/2081653004/
Original issue's description:
> Revert of Split IncomingVideoStream into two implementations, with smoothing and without. (patchset #5 id:340001 of https://codereview.webrtc.org/2078873002/ )
>
> Reason for revert:
> Breaks chromium.webrtc.fyi
>
> https://uberchromegw.corp.google.com/i/chromium.webrtc.fyi/builders/Win7%20Tester/builds/4719
> https://uberchromegw.corp.google.com/i/chromium.webrtc.fyi/builders/Win10%20Tester/builds/3120
>
> Original issue's description:
> > Reland of IncomingVideoStream refactoring.
> > This reland does not contain the non-smoothing part of the original implementation. Instead, when smoothing is turned off, frame callbacks run on the decoder thread, as they did before. This code path is used in Chrome. As far as Chrome goes, the difference now is that there won't be an instance of IncomingVideoStream in between the decoder and the callback (i.e. fewer locks). Other than that, no change for Chrome.
> >
> > Original issue's description (with non-smoothing references removed):
> >
> > Split IncomingVideoStream into two implementations, with smoothing and without.
> >
> > * Added TODOs and documentation for VideoReceiveStream::OnFrame, where we today grab 6 locks.
> >
> > * Removed the Start/Stop methods from the IncomingVideoStream implementations. Now, when an instance is created, it should be considered to be "running" and when it is deleted, it's "not running". This saves on resources and also reduces the amount of locking required and I could remove one critical section altogether.
> >
> > * Changed the VideoStreamDecoder class to not depend on IncomingVideoStream but rather use the generic rtc::VideoSinkInterface<VideoFrame> interface. This means that any implementation of that interface can be used and the decoder can be made to just use the 'renderer' from the config. Once we do that, we can decouple the IncomingVideoStream implementations from the decoder and VideoReceiveStream implementations and leave it up to the application for how to do smoothing. The app can choose to use the Incoming* classes or roll its own (which may be preferable since applications often have their own scheduling mechanisms).
> >
> > * The lifetime of the VideoStreamDecoder instance is now bound to Start/Stop in VideoReceiveStream and not all of the lifetime of VideoReceiveStream.
> >
> > * Fixed VideoStreamDecoder to unregister callbacks in the dtor that were registered in the ctor. (this was open to a use-after-free regression)
> >
> > * Delay and callback pointers are now passed via the ctors to the IncomingVideoStream classes. The thread primitives in the IncomingVideoStream classes are also constructed/destructed at the same time as the owning object, which allowed me to remove one more lock.
> >
> > * Removed code in the VideoStreamDecoder that could overwrite the VideoReceiveStream render delay with a fixed value of 10ms on construction. This wasn't a problem with the previous implementation (it would be now though) but seemed to me like the wrong place to be setting that value.
> >
> > * Made the render delay value in VideoRenderFrames, const.
> >
> > BUG=chromium:620232
> > R=mflodman@webrtc.org, nisse@webrtc.org
> >
> > Committed: https://crrev.com/884c336c345d988974c2a69cea402b0fb8b07a63
> > Cr-Commit-Position: refs/heads/master@{#13219}
>
> TBR=nisse@webrtc.org,philipel@webrtc.org,mflodman@webrtc.org,tommi@webrtc.org
> # Skipping CQ checks because original CL landed less than 1 days ago.
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG=chromium:620232
>
> Committed: https://crrev.com/a536bfe70de38fe877245317a7f0b00bcf69cbd0
> Cr-Commit-Position: refs/heads/master@{#13229}
TBR=nisse@webrtc.org,philipel@webrtc.org,mflodman@webrtc.org,sakal@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:620232
Review-Url: https://codereview.webrtc.org/2089613002
Cr-Commit-Position: refs/heads/master@{#13230}
Reason for revert:
Breaks chromium.webrtc.fyi
https://uberchromegw.corp.google.com/i/chromium.webrtc.fyi/builders/Win7%20Tester/builds/4719https://uberchromegw.corp.google.com/i/chromium.webrtc.fyi/builders/Win10%20Tester/builds/3120
Original issue's description:
> Reland of IncomingVideoStream refactoring.
> This reland does not contain the non-smoothing part of the original implementation. Instead, when smoothing is turned off, frame callbacks run on the decoder thread, as they did before. This code path is used in Chrome. As far as Chrome goes, the difference now is that there won't be an instance of IncomingVideoStream in between the decoder and the callback (i.e. fewer locks). Other than that, no change for Chrome.
>
> Original issue's description (with non-smoothing references removed):
>
> Split IncomingVideoStream into two implementations, with smoothing and without.
>
> * Added TODOs and documentation for VideoReceiveStream::OnFrame, where we today grab 6 locks.
>
> * Removed the Start/Stop methods from the IncomingVideoStream implementations. Now, when an instance is created, it should be considered to be "running" and when it is deleted, it's "not running". This saves on resources and also reduces the amount of locking required and I could remove one critical section altogether.
>
> * Changed the VideoStreamDecoder class to not depend on IncomingVideoStream but rather use the generic rtc::VideoSinkInterface<VideoFrame> interface. This means that any implementation of that interface can be used and the decoder can be made to just use the 'renderer' from the config. Once we do that, we can decouple the IncomingVideoStream implementations from the decoder and VideoReceiveStream implementations and leave it up to the application for how to do smoothing. The app can choose to use the Incoming* classes or roll its own (which may be preferable since applications often have their own scheduling mechanisms).
>
> * The lifetime of the VideoStreamDecoder instance is now bound to Start/Stop in VideoReceiveStream and not all of the lifetime of VideoReceiveStream.
>
> * Fixed VideoStreamDecoder to unregister callbacks in the dtor that were registered in the ctor. (this was open to a use-after-free regression)
>
> * Delay and callback pointers are now passed via the ctors to the IncomingVideoStream classes. The thread primitives in the IncomingVideoStream classes are also constructed/destructed at the same time as the owning object, which allowed me to remove one more lock.
>
> * Removed code in the VideoStreamDecoder that could overwrite the VideoReceiveStream render delay with a fixed value of 10ms on construction. This wasn't a problem with the previous implementation (it would be now though) but seemed to me like the wrong place to be setting that value.
>
> * Made the render delay value in VideoRenderFrames, const.
>
> BUG=chromium:620232
> R=mflodman@webrtc.org, nisse@webrtc.org
>
> Committed: https://crrev.com/884c336c345d988974c2a69cea402b0fb8b07a63
> Cr-Commit-Position: refs/heads/master@{#13219}
TBR=nisse@webrtc.org,philipel@webrtc.org,mflodman@webrtc.org,tommi@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:620232
Review-Url: https://codereview.webrtc.org/2084873002
Cr-Commit-Position: refs/heads/master@{#13229}
This reland does not contain the non-smoothing part of the original implementation. Instead, when smoothing is turned off, frame callbacks run on the decoder thread, as they did before. This code path is used in Chrome. As far as Chrome goes, the difference now is that there won't be an instance of IncomingVideoStream in between the decoder and the callback (i.e. fewer locks). Other than that, no change for Chrome.
Original issue's description (with non-smoothing references removed):
Split IncomingVideoStream into two implementations, with smoothing and without.
* Added TODOs and documentation for VideoReceiveStream::OnFrame, where we today grab 6 locks.
* Removed the Start/Stop methods from the IncomingVideoStream implementations. Now, when an instance is created, it should be considered to be "running" and when it is deleted, it's "not running". This saves on resources and also reduces the amount of locking required and I could remove one critical section altogether.
* Changed the VideoStreamDecoder class to not depend on IncomingVideoStream but rather use the generic rtc::VideoSinkInterface<VideoFrame> interface. This means that any implementation of that interface can be used and the decoder can be made to just use the 'renderer' from the config. Once we do that, we can decouple the IncomingVideoStream implementations from the decoder and VideoReceiveStream implementations and leave it up to the application for how to do smoothing. The app can choose to use the Incoming* classes or roll its own (which may be preferable since applications often have their own scheduling mechanisms).
* The lifetime of the VideoStreamDecoder instance is now bound to Start/Stop in VideoReceiveStream and not all of the lifetime of VideoReceiveStream.
* Fixed VideoStreamDecoder to unregister callbacks in the dtor that were registered in the ctor. (this was open to a use-after-free regression)
* Delay and callback pointers are now passed via the ctors to the IncomingVideoStream classes. The thread primitives in the IncomingVideoStream classes are also constructed/destructed at the same time as the owning object, which allowed me to remove one more lock.
* Removed code in the VideoStreamDecoder that could overwrite the VideoReceiveStream render delay with a fixed value of 10ms on construction. This wasn't a problem with the previous implementation (it would be now though) but seemed to me like the wrong place to be setting that value.
* Made the render delay value in VideoRenderFrames, const.
BUG=chromium:620232
R=mflodman@webrtc.org, nisse@webrtc.org
Review URL: https://codereview.webrtc.org/2078873002 .
Cr-Commit-Position: refs/heads/master@{#13219}
This cl change so that VideoSendStream::Start adds the stream as a BitrateObserver and VideoSendStream::Stop removes the stream as observer.
That also means that start will trigger a VideoEncoder::SetRate call with the most recent bitrate estimate.
VideoSendStream::Stop will trigger a VideoEncoder::SetRate with bitrate = 0.
BUG=webrtc:5687 b/28636240
Review-Url: https://codereview.webrtc.org/2070343002
Cr-Commit-Position: refs/heads/master@{#13192}
Reason for revert:
Reverting again. The perf regression does not seem to be related to dropping frames.
Original issue's description:
> Reland of Split IncomingVideoStream into two implementations, with smoothing and without.
>
> Original issue's description:
>
> Split IncomingVideoStream into two implementations, with smoothing and without.
>
> This CL fixes an issue with the non-smoothing implementation where frames were delivered on the decoder thread. No-smoothing is now done in a separate class that uses a TaskQueue. The implementation may drop frames if the renderer doesn't keep up and it doesn't block the decoder thread.
>
> Further work done:
>
> * I added TODOs and documentation for VideoReceiveStream::OnFrame, where we today grab 5 locks.
>
> * I removed the Start/Stop methods from the IncomingVideoStream implementations. Now, when an instance is created, it should be considered to be "running" and when it is deleted, it's "not running". This saves on resources and also reduces the amount of locking required and I could remove one critical section altogether.
>
> * I changed the VideoStreamDecoder class to not depend on IncomingVideoStream but rather use the generic rtc::VideoSinkInterface<VideoFrame> interface. This means that any implementation of that interface can be used and the decoder can be made to just use the 'renderer' from the config. Once we do that, we can decouple the IncomingVideoStream implementations from the decoder and VideoReceiveStream implementations and leave it up to the application for how to do smoothing. The app can choose to use the Incoming* classes or roll its own (which may be preferable since applications often have their own scheduling mechanisms).
>
> * The non-smoothing IncomingVideoStream implementation currently allows only 1 outstanding pending frame. If we exceed that, the current frame won't be delivered to the renderer and instead we deliver the next one (since when this happens, the renderer is falling behind).
>
> * The lifetime of the VideoStreamDecoder instance is now bound to Start/Stop in VideoReceiveStream and not all of the lifetime of VideoReceiveStream.
>
> * Fixed VideoStreamDecoder to unregister callbacks in the dtor that were registered in the ctor. (this was open to a use-after-free regression)
>
> * Delay and callback pointers are now passed via the ctors to the IncomingVideoStream classes. The thread primitives in the IncomingVideoStream classes are also constructed/destructed at the same time as the owning object, which allowed me to remove one more lock.
>
> * Removed code in the VideoStreamDecoder that could overwrite the VideoReceiveStream render delay with a fixed value of 10ms on construction. This wasn't a problem with the previous implementation (it would be now though) but seemed to me like the wrong place to be setting that value.
>
> * Made the render delay value in VideoRenderFrames, const.
>
> BUG=chromium:620232
> TBR=mflodman
>
> Committed: https://crrev.com/e03f8787377bbc03a4e00184bb14b7561b108cbb
> Cr-Commit-Position: refs/heads/master@{#13175}
TBR=mflodman@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:620232
Review-Url: https://codereview.webrtc.org/2071093002
Cr-Commit-Position: refs/heads/master@{#13176}
Original issue's description:
Split IncomingVideoStream into two implementations, with smoothing and without.
This CL fixes an issue with the non-smoothing implementation where frames were delivered on the decoder thread. No-smoothing is now done in a separate class that uses a TaskQueue. The implementation may drop frames if the renderer doesn't keep up and it doesn't block the decoder thread.
Further work done:
* I added TODOs and documentation for VideoReceiveStream::OnFrame, where we today grab 5 locks.
* I removed the Start/Stop methods from the IncomingVideoStream implementations. Now, when an instance is created, it should be considered to be "running" and when it is deleted, it's "not running". This saves on resources and also reduces the amount of locking required and I could remove one critical section altogether.
* I changed the VideoStreamDecoder class to not depend on IncomingVideoStream but rather use the generic rtc::VideoSinkInterface<VideoFrame> interface. This means that any implementation of that interface can be used and the decoder can be made to just use the 'renderer' from the config. Once we do that, we can decouple the IncomingVideoStream implementations from the decoder and VideoReceiveStream implementations and leave it up to the application for how to do smoothing. The app can choose to use the Incoming* classes or roll its own (which may be preferable since applications often have their own scheduling mechanisms).
* The non-smoothing IncomingVideoStream implementation currently allows only 1 outstanding pending frame. If we exceed that, the current frame won't be delivered to the renderer and instead we deliver the next one (since when this happens, the renderer is falling behind).
* The lifetime of the VideoStreamDecoder instance is now bound to Start/Stop in VideoReceiveStream and not all of the lifetime of VideoReceiveStream.
* Fixed VideoStreamDecoder to unregister callbacks in the dtor that were registered in the ctor. (this was open to a use-after-free regression)
* Delay and callback pointers are now passed via the ctors to the IncomingVideoStream classes. The thread primitives in the IncomingVideoStream classes are also constructed/destructed at the same time as the owning object, which allowed me to remove one more lock.
* Removed code in the VideoStreamDecoder that could overwrite the VideoReceiveStream render delay with a fixed value of 10ms on construction. This wasn't a problem with the previous implementation (it would be now though) but seemed to me like the wrong place to be setting that value.
* Made the render delay value in VideoRenderFrames, const.
BUG=chromium:620232
TBR=mflodman
Review-Url: https://codereview.webrtc.org/2071473002
Cr-Commit-Position: refs/heads/master@{#13175}
1. It moves calculation of the needed padding to VideoSendStream instead of ViEEncoder and only does it once per send Stream instead of every time the network estimate changes.
2. The maximum amount of padding sent was prior to this cl calculated and updated based on network estimate changes. However, it can only change based on encoder configuration changes and if send streams are added or removed. This cl change the VideoSendStream/VieEncoder to notify the BitrateAllocator of changes to the needed padding bitrate and for BitrateAllocator to notify Call of these changes.
3. Fixed an issue in the SendPacer where it could send a padding packet before sending a real packet. This caused the test EndToEndTest.RestartingSendStreamPreservesRtpStatesWithRtx to fail with these refactorings since the pacer suddenly could send a padding packet before the encoder had produced its first frame.
BUG=webrtc:5687
Review-Url: https://codereview.webrtc.org/1993113003
Cr-Commit-Position: refs/heads/master@{#13149}
Reason for revert:
Reverting while we track down the issue on the Win10 bot.
Original issue's description:
> Split IncomingVideoStream into two implementations, with smoothing and without.
>
> This CL fixes an issue with the non-smoothing implementation where frames were delivered on the decoder thread. No-smoothing is now done in a separate class that uses a TaskQueue. The implementation may drop frames if the renderer doesn't keep up and it doesn't block the decoder thread.
>
> Further work done:
>
> * I added TODOs and documentation for VideoReceiveStream::OnFrame, where we today grab 5 locks.
>
> * I removed the Start/Stop methods from the IncomingVideoStream implementations. Now, when an instance is created, it should be considered to be "running" and when it is deleted, it's "not running". This saves on resources and also reduces the amount of locking required and I could remove one critical section altogether.
>
> * I changed the VideoStreamDecoder class to not depend on IncomingVideoStream but rather use the generic rtc::VideoSinkInterface<VideoFrame> interface. This means that any implementation of that interface can be used and the decoder can be made to just use the 'renderer' from the config. Once we do that, we can decouple the IncomingVideoStream implementations from the decoder and VideoReceiveStream implementations and leave it up to the application for how to do smoothing. The app can choose to use the Incoming* classes or roll its own (which may be preferable since applications often have their own scheduling mechanisms).
>
> * The non-smoothing IncomingVideoStream implementation currently allows only 1 outstanding pending frame. If we exceed that, the current frame won't be delivered to the renderer and instead we deliver the next one (since when this happens, the renderer is falling behind).
>
> * The lifetime of the VideoStreamDecoder instance is now bound to Start/Stop in VideoReceiveStream and not all of the lifetime of VideoReceiveStream.
>
> * Fixed VideoStreamDecoder to unregister callbacks in the dtor that were registered in the ctor. (this was open to a use-after-free regression)
>
> * Delay and callback pointers are now passed via the ctors to the IncomingVideoStream classes. The thread primitives in the IncomingVideoStream classes are also constructed/destructed at the same time as the owning object, which allowed me to remove one more lock.
>
> * Removed code in the VideoStreamDecoder that could overwrite the VideoReceiveStream render delay with a fixed value of 10ms on construction. This wasn't a problem with the previous implementation (it would be now though) but seemed to me like the wrong place to be setting that value.
>
> * Made the render delay value in VideoRenderFrames, const.
>
> BUG=
>
> Committed: https://crrev.com/1c7eef652b0aa22d8ebb0bfe2b547094a794be22
> Cr-Commit-Position: refs/heads/master@{#13129}
TBR=mflodman@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=
Review-Url: https://codereview.webrtc.org/2061363002
Cr-Commit-Position: refs/heads/master@{#13146}
This CL fixes an issue with the non-smoothing implementation where frames were delivered on the decoder thread. No-smoothing is now done in a separate class that uses a TaskQueue. The implementation may drop frames if the renderer doesn't keep up and it doesn't block the decoder thread.
Further work done:
* I added TODOs and documentation for VideoReceiveStream::OnFrame, where we today grab 5 locks.
* I removed the Start/Stop methods from the IncomingVideoStream implementations. Now, when an instance is created, it should be considered to be "running" and when it is deleted, it's "not running". This saves on resources and also reduces the amount of locking required and I could remove one critical section altogether.
* I changed the VideoStreamDecoder class to not depend on IncomingVideoStream but rather use the generic rtc::VideoSinkInterface<VideoFrame> interface. This means that any implementation of that interface can be used and the decoder can be made to just use the 'renderer' from the config. Once we do that, we can decouple the IncomingVideoStream implementations from the decoder and VideoReceiveStream implementations and leave it up to the application for how to do smoothing. The app can choose to use the Incoming* classes or roll its own (which may be preferable since applications often have their own scheduling mechanisms).
* The non-smoothing IncomingVideoStream implementation currently allows only 1 outstanding pending frame. If we exceed that, the current frame won't be delivered to the renderer and instead we deliver the next one (since when this happens, the renderer is falling behind).
* The lifetime of the VideoStreamDecoder instance is now bound to Start/Stop in VideoReceiveStream and not all of the lifetime of VideoReceiveStream.
* Fixed VideoStreamDecoder to unregister callbacks in the dtor that were registered in the ctor. (this was open to a use-after-free regression)
* Delay and callback pointers are now passed via the ctors to the IncomingVideoStream classes. The thread primitives in the IncomingVideoStream classes are also constructed/destructed at the same time as the owning object, which allowed me to remove one more lock.
* Removed code in the VideoStreamDecoder that could overwrite the VideoReceiveStream render delay with a fixed value of 10ms on construction. This wasn't a problem with the previous implementation (it would be now though) but seemed to me like the wrong place to be setting that value.
* Made the render delay value in VideoRenderFrames, const.
BUG=
Review-Url: https://codereview.webrtc.org/2035173002
Cr-Commit-Position: refs/heads/master@{#13129}
Instead of the default copy constructor, the Copy() method has to be used. In this CL, the number of copies has been reduced significantly in production code. One case in the video engine remains, where we need to restart a video stream. Even in that case, I'm sure we could avoid it, but for this particular CL, I decided against it to keep things simple (and it's also an edge case). Most importantly, creating copies is made harder and the interface encourages ownership transfers.
R=mflodman@webrtc.org, pbos@webrtc.org
Review URL: https://codereview.webrtc.org/2042603002 .
Cr-Commit-Position: refs/heads/master@{#13102}
Currently there are two structs that are identical and track extension details:
webrtc::RtpExtension
cricket::RtpHeaderExtension
The use of the structs is mixed in the code to track the extensions being
supported. This results in duplicate definition of
the URI constants and there is code to convert between the two structs.
Clean up to use a single RtpHeader throughout the codebase. The actual location
of RtpHeader may change in future (perhaps to be located in api/). Additionally,
this CL renames some of the constants to clarify Uri and Id use.
BUG= webrtc:5895
Review-Url: https://codereview.webrtc.org/1984983002
Cr-Commit-Position: refs/heads/master@{#12924}
Updated tests to use the default implementation and removed the test implementation (webrtc/test/histograms.h).
BUG=
Review-Url: https://codereview.webrtc.org/1915523002
Cr-Commit-Position: refs/heads/master@{#12829}
Remove ViEEncoder::SetNetworkStatus.
Original cl description:
This cl removed ViEEncoder::SetNetworkStatus. Instead the PacedSender will report that frames can not be sent when the network is down and the BitrateController will report an estimated available bandwidth of 0 bps.
Patchset #1 is a pure reland.
Patchset #2 change the bitrate allocator to always return an initial bitrate >0 regardless of the estimates. The observer will be notified though if the network is down.
BUG=webrtc:5687
Review-Url: https://codereview.webrtc.org/1972183004
Cr-Commit-Position: refs/heads/master@{#12743}
Wires up existing libvpx_build_vp9==0 GYP flag into WebRTC and makes VP9
optional. Change is GYP only for now since libvpx's GN files build VP9
unconditionally.
BUG=webrtc:5884
R=kjellander@webrtc.org
Review URL: https://codereview.webrtc.org/1970343002 .
Cr-Commit-Position: refs/heads/master@{#12741}
- "WebRTC.Video.SendDelayInMs"
Change so that PacketOption packet id is always set in RtpSender (if having a TransportSequenceNumberAllocator).
Add SendDelayStats class for computing delays.
Add SendPacketObserver to RtpRtcp config and register SendDelayStats as observer.
Wire up OnSentPacket to SendDelayStats.
BUG=webrtc:5215
Review-Url: https://codereview.webrtc.org/1478253002
Cr-Commit-Position: refs/heads/master@{#12600}
The problem with gmock is worked around by commenting out any other override declarations in classes using gmock.
NOPRESUBMIT=True
BUG=webrtc:3970
Review-Url: https://codereview.webrtc.org/1921653002
Cr-Commit-Position: refs/heads/master@{#12563}
This fix a potential race where the rotation information of a sent frame does not match the encoded frame.
BUG=webrtc:5783
TEST= Run ApprtcDemo on IOs and Android with and without capture to texture and both VP8 and H264.
R=magjed@webrtc.org, pbos@webrtc.org, tkchin@webrtc.org
TBR=tkchin_webrtc // For IOS changes.
Review URL: https://codereview.webrtc.org/1886113003 .
Cr-Commit-Position: refs/heads/master@{#12426}
Used only by tests. Deleted the EndToEndTest.UsesFrameCallbacks, which
modified pixel data. Change callback from in EndToEndTest.GetStats to call SleepMs, rath than
modifying the timestamp.
BUG=
Review URL: https://codereview.webrtc.org/1891733002
Cr-Commit-Position: refs/heads/master@{#12406}
Reason for revert:
The delay stats are high.
Original issue's description:
> Update histogram "WebRTC.Video.OnewayDelayInMs" to use the estimated one-way delay.
> Previous logged delay was: network delay (rtt/2) + jitter delay + decode time + render delay.
>
> Make capture time in local timebase available for decoded VP9 video frames (propagate ntp_time_ms from EncodedImage to decoded VideoFrame).
>
> BUG=
>
> Committed: https://crrev.com/5249599a9b69ad9c2d513210d694719f1011f977
> Cr-Commit-Position: refs/heads/master@{#11901}
TBR=stefan@webrtc.org,pbos@webrtc.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=chromium:603838
Review URL: https://codereview.webrtc.org/1893543003
Cr-Commit-Position: refs/heads/master@{#12400}
We can (and should) use std::vector<std::unique_ptr<T>> instead.
Because it's standard, and because it's safer since callers have to
manually wrap elements in std::unique_ptr before inserting them and
manually unwrap them after inserting them.
Review URL: https://codereview.webrtc.org/1839603002
Cr-Commit-Position: refs/heads/master@{#12182}
To replace the SmoothsRenderedFrames method, added a corresponding
flag to VideoReceiveStream::Config instead.
BUG=webrtc:5426
Review URL: https://codereview.webrtc.org/1818023002
Cr-Commit-Position: refs/heads/master@{#12102}
This change enables voice-only calls to keep track of the network state.
This is only a partial fix - the last modality to change state controls
the state for the entire call, so a call with a failed video transport
will also stop sending audio packets. Handling this condition correctly
would require the call to keep track of network state for each media
type separately, and take care of conditions such as a failed video
channel getting removed, while a functioning audio channel remains.
BUG=webrtc:5307
Review URL: https://codereview.webrtc.org/1757683002
Cr-Commit-Position: refs/heads/master@{#12093}
webrtc::VideoRenderer class, replacing it by rtc::VideoSinkInterface.
The next step is to convert all places where a renderer is attached to
rtc::VideoSourceInterface, and at that point, the
SmoothsRenderedFrames method can be replaced by a flag
rtc::VideoSinkWants::smoothed_frames.
Delete unused method IsTextureSupported.
Delete unused time argument to RenderFrame.
Let webrtc::VideoRenderer inherit rtc::VideoSinkInterface. Rename RenderFrame --> OnFrame.
TBR=kjellander@webrtc.org
BUG=webrtc:5426
Review URL: https://codereview.webrtc.org/1814763002
Cr-Commit-Position: refs/heads/master@{#12070}
Previous logged delay was: network delay (rtt/2) + jitter delay + decode time + render delay.
Make capture time in local timebase available for decoded VP9 video frames (propagate ntp_time_ms from EncodedImage to decoded VideoFrame).
BUG=
Review URL: https://codereview.webrtc.org/1688143003
Cr-Commit-Position: refs/heads/master@{#11901}
Also move some stats reporting from vie_channel to send stats proxy
BUG=
Review URL: https://codereview.webrtc.org/1669623004
Cr-Commit-Position: refs/heads/master@{#11688}
Prevents allocating sequence numbers for packets that go out on the
network even though sending media is disabled.
This race caused a replay of sequence numbers when GetRtpState() on a
stopped stream would not return the last sequence number sent, since the
pacer thread could request and send padding on a later sequence number
before the modules are disconnected from the pacer.
BUG=webrtc:5543
R=stefan@webrtc.org
TEST=Repeating EndToEndTest.RestartingSendStreamPreservesRtpState 1000 times under TSan.
Review URL: https://codereview.webrtc.org/1715703002 .
Cr-Commit-Position: refs/heads/master@{#11685}
Makes DecodesRetransmittedFrame not flake/fail due to sent padding when
probing, which is correct behavior. Also removes hack that accepted this
only during the first n packets.
BUG=
R=stefan@webrtc.org
Review URL: https://codereview.webrtc.org/1698343003 .
Cr-Commit-Position: refs/heads/master@{#11648}
This started flaking due to allowing probes to restart if they were aborted due to insufficient packets. This is reasonable behavior.
TBR=pbos@webrtc.org
Review URL: https://codereview.webrtc.org/1701033002 .
Cr-Commit-Position: refs/heads/master@{#11638}
Reason for revert:
Disabling tests on memcheck that time out due to using real VP8 encoders.
Original issue's description:
> Revert of Don't send FEC for H.264 with NACK enabled. (patchset #5 id:80001 of https://codereview.webrtc.org/1687303002/ )
>
> Reason for revert:
> Broke the VerifyHistogramStatsWithRed test on the Windows DrMemory Full bot and Linux Memcheck bot. Please fix the test and reland.
>
> Original issue's description:
> > Don't send FEC for H.264 with NACK enabled.
> >
> > The H.264 does not contain picture IDs and are not sufficient to
> > determine that a packet may be skipped. This causes retransmission
> > requests for FEC that are currently dropped by the sender (since they
> > should be redundant).
> >
> > The receiver is then unable to continue without having the packet gap
> > filled (unlike VP8/VP9 which moves on since it has a consecutive stream
> > of picture IDs).
> >
> > Even if FEC retransmission did work it's a huge waste of bandwidth,
> > since it just adds additional overhead that has to be unconditionally
> > transmitted. This bandwidth is better used to send higher-quality
> > frames.
> >
> > BUG=webrtc:5264
> > R=stefan@webrtc.org
> >
> > Committed: https://crrev.com/25558ad819b4df41ba51537e26a77480ace1e525
> > Cr-Commit-Position: refs/heads/master@{#11601}
>
> TBR=stefan@webrtc.org,pbos@webrtc.org
> # Skipping CQ checks because original CL landed less than 1 days ago.
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG=webrtc:5264
>
> Committed: https://crrev.com/29ffdc1a15e31bd81e806ff135c2100d811714f0
> Cr-Commit-Position: refs/heads/master@{#11607}
TBR=stefan@webrtc.org,deadbeef@webrtc.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=webrtc:5264
Review URL: https://codereview.webrtc.org/1697093002 .
Cr-Commit-Position: refs/heads/master@{#11621}
Reason for revert:
Broke the VerifyHistogramStatsWithRed test on the Windows DrMemory Full bot and Linux Memcheck bot. Please fix the test and reland.
Original issue's description:
> Don't send FEC for H.264 with NACK enabled.
>
> The H.264 does not contain picture IDs and are not sufficient to
> determine that a packet may be skipped. This causes retransmission
> requests for FEC that are currently dropped by the sender (since they
> should be redundant).
>
> The receiver is then unable to continue without having the packet gap
> filled (unlike VP8/VP9 which moves on since it has a consecutive stream
> of picture IDs).
>
> Even if FEC retransmission did work it's a huge waste of bandwidth,
> since it just adds additional overhead that has to be unconditionally
> transmitted. This bandwidth is better used to send higher-quality
> frames.
>
> BUG=webrtc:5264
> R=stefan@webrtc.org
>
> Committed: https://crrev.com/25558ad819b4df41ba51537e26a77480ace1e525
> Cr-Commit-Position: refs/heads/master@{#11601}
TBR=stefan@webrtc.org,pbos@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:5264
Review URL: https://codereview.webrtc.org/1692783005
Cr-Commit-Position: refs/heads/master@{#11607}
The H.264 does not contain picture IDs and are not sufficient to
determine that a packet may be skipped. This causes retransmission
requests for FEC that are currently dropped by the sender (since they
should be redundant).
The receiver is then unable to continue without having the packet gap
filled (unlike VP8/VP9 which moves on since it has a consecutive stream
of picture IDs).
Even if FEC retransmission did work it's a huge waste of bandwidth,
since it just adds additional overhead that has to be unconditionally
transmitted. This bandwidth is better used to send higher-quality
frames.
BUG=webrtc:5264
R=stefan@webrtc.org
Review URL: https://codereview.webrtc.org/1687303002 .
Cr-Commit-Position: refs/heads/master@{#11601}
Permits measuring encoding time even when performed on another thread,
typically for hardware encoding, instead of assuming that encoding is
blocking the calling thread.
Permitted encoding time is increased for hardware encoders since they
can be timed to keep 30fps, for instance, without indicating overload.
Merges EncodingTimeObserver into EncodedFrameObserver to have one post-encode
callback.
BUG=webrtc:5042, webrtc:5132
R=asapersson@webrtc.org, mflodman@webrtc.org
Review URL: https://codereview.webrtc.org/1569853002 .
Cr-Commit-Position: refs/heads/master@{#11499}
This adds negotiation of both transport sequence number and transport
feedback. Only offers transport seq num if the
WebRTC-Audio-SendSideBwe finch experiment is enabled.
TBR=mflodman@webrtc.org
BUG=webrtc:5263
Review URL: https://codereview.webrtc.org/1604563002
Cr-Commit-Position: refs/heads/master@{#11487}
Adds negotiation of rtx codecs for red and vp9. To keep backwards
compatibility with older Chrome versions, this change includes two
hacks:
1. Red packets will be retransmitted over the rtx codec associated with
vp8 if no rtx codec is associated with red. This is how Chrome does
it today and ensures that we still can send red over rtx to older
versions.
2. If rtx packets associated with the media codec (vp8/vp9 etc) are
received and red has been negotiated, we will assume that the sender
incorrectly has packetized red inside the rtx header associated with
media. We will therefore restore it with the red payload type
instead, which ensures that we can still receive rtx associated with
red from old versions.
Offering multiple rtx codecs to older versions should not be a problem
since old versions themselves only try to negotiate rtx for vp8.
R=pbos@webrtc.orgTBR=mflodman@webrtc.org
BUG=webrtc:4024
TEST=Verified by running apprtc and emulating packet loss between Chrome with and without the patch.
Review URL: https://codereview.webrtc.org/1649493004 .
Cr-Commit-Position: refs/heads/master@{#11472}
