[devopvoid]

A PeerConnectionFactory can now be given its own video encoder and decoder factories, which decide what video codecs it sends and receives. Until now the codecs were hard-coded in JNI_PeerConnectionFactory.cpp.

PeerConnectionFactory factory = PeerConnectionFactory.builder()
        .setAudioDeviceModule(adm)
        .setVideoEncoderFactory(new MyEncoderFactory())
        .setVideoDecoderFactory(new MyDecoderFactory())
        .build();

API

• PeerConnectionFactory.builder() sets the codec factories along with everything the constructors take (field trials, audio device module, audio processing). The constructors are unchanged.
• New package dev.onvoid.webrtc.media.video.codec, modelled on the Android SDK:
  • VideoEncoder and VideoDecoder, for codecs implemented in Java
  • VideoEncoderFactory and VideoDecoderFactory
  • EncodedImage, VideoCodecInfo and VideoCodecStatus
  • DefaultVideoEncoderFactory and DefaultVideoDecoderFactory, which provide the built-in codecs. A factory can add its own codec and delegate the rest to them. The NativeVideoEncoder and NativeVideoDecoder they hand out make WebRTC create the built-in codec natively, with no detour through Java.
• A codec name WebRTC does not know (e.g. X-MYCODEC) is negotiated and sent with the generic RTP packetization.

Native side

• Wrappers ported from the Android SDK run the Java codecs.
• Frames reach a Java encoder without a copy. Encoded images reach a Java decoder as a read-only view.
• The callback a codec hands its output to reaches the wrapper only until the codec is released, so late output cannot touch a destroyed wrapper.
• Whatever a Java codec or factory throws is logged and treated as an error, and never propagates into WebRTC.
• Decoded frames may use any I420Buffer with direct buffers, not only NativeI420Buffer.
• The built-in factory setup moved to media/video/codec/DefaultVideoCodecFactories.cpp, with the macOS VideoToolbox path unchanged.

Log sink fix (separate commit)

Found while testing: the Java log sink bridge let a C++ exception escape into WebRTC. This happened when a sink threw, or when a message was logged while a Java exception was pending. WebRTC calls sinks under its global logging lock and is built without unwinding, so the lock stayed held and the next thread to log blocked forever, typically in RTCPeerConnection.close(). Because a log sink cannot be removed, a sink installed by one test class made this appear in later ones. The bridge now sets a pending exception aside, restores it afterwards, and never throws. VideoCodecFactoryTests.failingEncoderFactoryDoesNotCrash hangs without the fix.

Testing

• VideoCodecFactoryTests (10 tests):
  • a full call through a Java encoder and decoder, including a decoder that returns a plain Java buffer
  • delegation to the built-in codecs
  • factories that throw
  • codec advertisement
• mvn -pl webrtc test: 194 tests pass.
• mvn -pl webrtc test -Pjni-check: 194 tests pass, with no FATAL ERROR in native method.
• Built and tested on Windows only. macOS and Linux will first be checked by CI.

Docs

New guide docs/guide/advanced/video-codecs.md, linked from the sidebar, the guide index, the README and the landing page. The field trials guide mentions the builder.

Not included

• Hardware encoders for Windows and Linux (NVENC, Media Foundation). They can now plug in through this API, but none ship yet.
• Android's getEncoderSelector().