Issue: video_receive_stream.cc includes transport_adapter.h which use to be inside call/ and call depends on video/ which caused circular dependency. We moved transport_adapter.h/.cc inside video/ and removed dependency of video/ on call/
BUG=webrtc:6412
NOTRY=True
Review-Url: https://codereview.webrtc.org/2470913004
Cr-Commit-Position: refs/heads/master@{#14907}
Reason for revert:
Flaky test has been fixed.
Original issue's description:
> Revert of Add path for recovered packets from internal::Call to RtpStreamReceiver. (patchset #2 id:60001 of https://codereview.webrtc.org/2390823009/ )
>
> Reason for revert:
> Speculative revert as it may be the cause of the DrMemory test failure:
> https://build.chromium.org/p/client.webrtc/builders/Win%20DrMemory%20Full/builds/5115
>
> Original issue's description:
> > Add path for recovered packets from internal::Call to RtpStreamReceiver.
> >
> > When the FlexfecReceiver recovers media packets, it inserts these into
> > internal::Call, which then distributes them to the appropriate
> > VideoReceiveStream/RtpStreamReceiver.
> >
> > BUG=webrtc:5654
> >
> > Committed: https://crrev.com/9c4b4b47f4325b48e1856566a30983f9e4e30dd0
> > Cr-Commit-Position: refs/heads/master@{#14642}
>
> TBR=stefan@webrtc.org,brandtr@webrtc.org
> # Skipping CQ checks because original CL landed less than 1 days ago.
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG=webrtc:5654
>
> Committed: https://crrev.com/862d74d0176fa762b3c96cf20bd36f27e7001a47
> Cr-Commit-Position: refs/heads/master@{#14652}
TBR=stefan@webrtc.org,honghaiz@webrtc.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=webrtc:5654
Review-Url: https://codereview.webrtc.org/2428303004
Cr-Commit-Position: refs/heads/master@{#14677}
Reason for revert:
Speculative revert as it may be the cause of the DrMemory test failure:
https://build.chromium.org/p/client.webrtc/builders/Win%20DrMemory%20Full/builds/5115
Original issue's description:
> Add path for recovered packets from internal::Call to RtpStreamReceiver.
>
> When the FlexfecReceiver recovers media packets, it inserts these into
> internal::Call, which then distributes them to the appropriate
> VideoReceiveStream/RtpStreamReceiver.
>
> BUG=webrtc:5654
>
> Committed: https://crrev.com/9c4b4b47f4325b48e1856566a30983f9e4e30dd0
> Cr-Commit-Position: refs/heads/master@{#14642}
TBR=stefan@webrtc.org,brandtr@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:5654
Review-Url: https://codereview.webrtc.org/2427733002
Cr-Commit-Position: refs/heads/master@{#14652}
When the FlexfecReceiver recovers media packets, it inserts these into
internal::Call, which then distributes them to the appropriate
VideoReceiveStream/RtpStreamReceiver.
BUG=webrtc:5654
Review-Url: https://codereview.webrtc.org/2390823009
Cr-Commit-Position: refs/heads/master@{#14642}
After calling Start(), doing a Stop() then Start() sequence should bring
the stream back to the original state.
BUG=webrtc:6501
Review-Url: https://codereview.webrtc.org/2407163002
Cr-Commit-Position: refs/heads/master@{#14597}
This CL removes (almost) the last RTP references in VideoReceiveStream.
There are still references to RTPFragmentationHeader and SSRCs, which
will be dealt with later.
There are also new GUARDED_BY and thred checker added to the
synchronization class.
When there are othre transports than RTP, there will instead be an
interface + inheritance for RtpStreamReceiver and
RtpStreamSynchronizattion in VideoReceiveStream. This work will be done
when we actually know how we want to make thee transport interface.
BUG=webrtc:5838
Review-Url: https://codereview.webrtc.org/2216533002
Cr-Commit-Position: refs/heads/master@{#13655}
Reason for revert:
broke browser_tests
Original issue's description:
> Add EncodedImageCallback::OnEncodedImage().
>
> OnEncodedImage() is going to replace Encoded(), which is deprecated now.
> The new OnEncodedImage() returns Result struct that contains frame_id,
> which tells the encoder RTP timestamp for the frame.
>
> BUG=chromium:621691
> R=niklas.enbom@webrtc.org, sprang@webrtc.org, stefan@webrtc.org
>
> Committed: https://crrev.com/4c7f4cd2ef76821edca6d773d733a924b0bedd25
> Committed: https://crrev.com/ad34dbe934d47f88011045671b4aea00dbd5a795
> Cr-Original-Commit-Position: refs/heads/master@{#13613}
> Cr-Commit-Position: refs/heads/master@{#13615}
TBR=pbos@webrtc.org,mflodman@webrtc.org,sprang@webrtc.org,stefan@webrtc.org,niklas.enbom@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:621691
Review-Url: https://codereview.webrtc.org/2203233002
Cr-Commit-Position: refs/heads/master@{#13616}
Reason for revert:
broke internal tests
Original issue's description:
> Add EncodedImageCallback::OnEncodedImage().
>
> OnEncodedImage() is going to replace Encoded(), which is deprecated now.
> The new OnEncodedImage() returns Result struct that contains frame_id,
> which tells the encoder RTP timestamp for the frame.
>
> BUG=chromium:621691
> R=niklas.enbom@webrtc.org, sprang@webrtc.org, stefan@webrtc.org
>
> Committed: https://crrev.com/ad34dbe934d47f88011045671b4aea00dbd5a795
> Cr-Commit-Position: refs/heads/master@{#13613}
TBR=pbos@webrtc.org,mflodman@webrtc.org,sprang@webrtc.org,stefan@webrtc.org,niklas.enbom@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:621691
Review-Url: https://codereview.webrtc.org/2206743002
Cr-Commit-Position: refs/heads/master@{#13614}
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}
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}
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}
EncodedFrameCallbackAdapter was used VideoSendStream and
VideoReceiveStream, but there is no reason to have it as these classes
can call EncodedFrameObserver directly.
Review-Url: https://codereview.webrtc.org/2068463004
Cr-Commit-Position: refs/heads/master@{#13145}
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}
There are still a few places in VideoReceiveStream where the RTP module
is explicitly used, e.g. setting up a/v sync, but it's a bigger task to
change and that will be done in a follow up instead of in this CL.
BUG=webrtc:5838
Review-Url: https://codereview.webrtc.org/1947913002
Cr-Commit-Position: refs/heads/master@{#12642}
ViEChannel is now called VideoStreamReceiver.
There will be a follow up CL removing all rtp references from VideoReceiveStream, but that made this CL to big and it will be done separately.
BUG=webrtc:5079
Review-Url: https://codereview.webrtc.org/1929313002
Cr-Commit-Position: refs/heads/master@{#12619}
Replaced by VideoSinkInterface instead.
Also delete stream_id property of IncomingVideoStream.
BUG=webrtc:5426
Review-Url: https://codereview.webrtc.org/1813173002
Cr-Commit-Position: refs/heads/master@{#12602}
This CL will be followed up with another CL removing everything related
to RTP from ViEChannel to RtpStreamReceiver, i.e. remove ViEChannel::rtp_stream_receiver_.
BUG=5838
Review-Url: https://codereview.webrtc.org/1917363005
Cr-Commit-Position: refs/heads/master@{#12553}
Also refactor GenericEncoder to use these file writers, and remove use
of preprocessor to enable file writing.
BUG=
Review URL: https://codereview.webrtc.org/1853813002
Cr-Commit-Position: refs/heads/master@{#12372}
Testing the nack module by implementing it into the current jitter buffer
under the experiment WebRTC-NewVideoJitterBuffer.
BUG=webrtc:5514
Review URL: https://codereview.webrtc.org/1778503002
Cr-Commit-Position: refs/heads/master@{#11969}
Remove hops into ViEChannel for calls directly into RtpRtcp and
ViEReceiver from VideoReceiveStream.
Some calls are more complex and will be removed later.
BUG=webrtc:5494
R=stefan@webrtc.org
Review URL: https://codereview.webrtc.org/1671893002 .
Cr-Commit-Position: refs/heads/master@{#11526}
Removes scoped_ptrs and resets, preventing some heap allocation but also
overall showing that these objects won't be reconstructed on the fly.
BUG=webrtc:5494
R=stefan@webrtc.org
Review URL: https://codereview.webrtc.org/1670123002 .
Cr-Commit-Position: refs/heads/master@{#11503}
Extracts shared members outside the two objects, removing PayloadRouter
from receivers and the VCM for ViEChannel from senders.
Removes Start/StopThreadsAndSetSharedMembers that was used to set the
shared state between them.
Also adding DCHECKs to document what's only used by the
sender/receiver side.
BUG=webrtc:5494
R=stefan@webrtc.org
Review URL: https://codereview.webrtc.org/1654913002 .
Cr-Commit-Position: refs/heads/master@{#11500}
To avoid breaking downstream, the "interface" directories were copied
into a new "common_video/include" dir. The old headers got pragma
warnings added about deprecation (a very short deprecation since I plan
to remove them as soon downstream is updated).
The header guards are also identical to avoid mixing them up in the transition.
BUG=webrtc:5095
TESTED=Passing compile-trybots with --clobber flag:
git cl try --clobber --bot=win_compile_rel --bot=linux_compile_rel --bot=android_compile_rel --bot=mac_compile_rel --bot=ios_rel --bot=linux_gn_rel --bot=win_x64_gn_rel --bot=mac_x64_gn_rel --bot=android_gn_rel -m tryserver.webrtc
Review URL: https://codereview.webrtc.org/1418913006
Cr-Commit-Position: refs/heads/master@{#10659}
