1685671 - Use reconfigure() instead of start() and stop() where possible in the VideoConduit

Status: RESOLVED DUPLICATE of bug 1654112

(Core :: WebRTC, enhancement, P2)

Description

[Nico Grunbaum [:ng, @chew:mozilla.org]]

"We are currently doing Stop(); Start(); whenever we update conduits, but the Streams in upstream support Reconfigure. It would make sense to switch us over to that to avoid resetting a bunch of internal state. Looks like this would need a bit of refactor in TransceiverImpl/RTCRtpReceiver so might be best suited in a followup - also to have some tracking on regressions."
-- Pehrsons

Comment 1

[Andreas Pehrson [:pehrsons]]

I noticed this while looking at AudioSendStream and AudioReceiveStream. The corresponding video streams appear to not have Reconfigure methods. There's a VideoSendStream::ReconfigureVideoEncoder that might be helpful in some cases.

Comment 2

[Andreas Pehrson [:pehrsons]]

In upstream bug 9106 they removed FrameBuffer::Start, making VideoReceiveStream::Stop final. After such a Stop, VideoReceiveStream::Start would not again start the FrameBuffer, so once that happens the FrameBuffer ends up blocking any received frames from being decoded.

Best would be to rework the Transceiver so that we never have to restart the receive stream. Should we still need to restart it we'd have to recreate it. All the implications of that I'm not sure of, but for one we'd drop all the frames currently waiting in the jitter buffer (aka FrameBuffer).

Possibly we could undelete FrameBuffer::Start but one would assume it was removed for good reasons.

Comment 3

[Andreas Pehrson [:pehrsons]]

I have done what I can in bug 1654112 to address this: D123222

Future libwebrtc merges may allow us to improve further, as not all things that could be reconfigurable are so yet.

Comment 4

[Andreas Pehrson [:pehrsons]]

Bug 1654112 landed.