OpenH264 1.8.1 occasionally generates a size of 0x01000000. This is a magic
value in the NAL which should be replaced with a valid size, but for some
reason this is not always happening. If we return early here, encoding will
continue to work as expected. This workaround can be removed once this issue is
addressed upstream, although that may require a new release of OpenH264.
Differential Revision: https://phabricator.services.mozilla.com/D25468
--HG--
extra : moz-landing-system : lando
We've hit a number of problems with handling of RGB24 video capture on
Windows. This adds a check that will ignore any RGB24 capture capabilities
when determining a best match if there are other capabilities available to
workaround the problems.
Differential Revision: https://phabricator.services.mozilla.com/D25449
--HG--
extra : moz-landing-system : lando
This is no longer used.
Differential Revision: https://phabricator.services.mozilla.com/D25057
--HG--
extra : rebase_source : 8ee009d508db3e340a77e4afe0efb16a1743ddca
extra : source : c7cd1b79da381624f2c17207662d0ba6a8ddc670
extra : histedit_source : 432816435e01238f733af17ae1857ebd3cd1b3e7
To prevent new buffer object from being created per frame, either
Sample.CREATOR has to keep track of all buffers from every remote codec,
or the client must memorize seen buffers and avoid asking for them again
and again. The former saves client code from modifications but complicates
the implementation of Sample, a data structure class, while the latter
requires changes to client code but avoid overcomplicating Sample.CREATOR
implementation.
The 2nd approach is taken:
- move SampleBuffer out of Sample, and update clients accordingly
- add a new IPC method for clients to get the buffers only when needed
Differential Revision: https://phabricator.services.mozilla.com/D24590
--HG--
extra : moz-landing-system : lando
This makes the shutdown behaviour of AudioConduit consistent with
VideoConduit which should make the conduit code easier to read and
reason about.
Differential Revision: https://phabricator.services.mozilla.com/D25055
--HG--
extra : moz-landing-system : lando
This was added during the branch 64 update, but was not documented at that time.
Differential Revision: https://phabricator.services.mozilla.com/D25054
--HG--
extra : moz-landing-system : lando
While not required in the two examples provided, should those streams change resolution and continue to use the same type of bytstreams we would miss the changes as the keyframe never contains the new SPS/PPS NALs.
So we add an option to handle this case, so we can separate the cases where this could be needed without regressing bug 1469257
Differential Revision: https://phabricator.services.mozilla.com/D24854
--HG--
extra : moz-landing-system : lando
This removes all the unimplemented RTCStats types from RTCStatsReport.webidl and deletes the related code
Differential Revision: https://phabricator.services.mozilla.com/D23276
--HG--
extra : moz-landing-system : lando
Adds a pref to turn off WebRTC RTCP reception for tests, and an associated mochitest.
Once fixed the RTCP regression should cause the mochitest to unexpectedly pass
Differential Revision: https://phabricator.services.mozilla.com/D14518
--HG--
extra : moz-landing-system : lando
realigning the RTP stats types to match spec. This involves breaking out the remote dictionary types. This shouldn't create user space visible changes.
Differential Revision: https://phabricator.services.mozilla.com/D20432
--HG--
extra : moz-landing-system : lando
VideoSegments still have durations, and they are still needed by the
MediaStreamGraph as it shuffles MediaSegments around.
They do not have a say in the wall-clock duration of video frames however.
Removing this should prevent any producers starting to add video chunks with
durations in the future.
Differential Revision: https://phabricator.services.mozilla.com/D22914
--HG--
extra : moz-landing-system : lando
The webrtc-pc spec says:
> If track is ended, or if the track's output is disabled, i.e. the track is
> disabled and/or muted, the RTCRtpSender MUST send silence (audio),
> black frames (video) or a zero-information-content equivalent.
> In the case of video, the RTCRtpSender SHOULD send one black frame per second.
This patch covers the case when the output is disabled, and the case when no
frames reach the MediaPipeline, for both direct and non-direct video listeners.
Differential Revision: https://phabricator.services.mozilla.com/D22898
--HG--
extra : moz-landing-system : lando