Two request - not sure if we are talking about a bug or a features about webrtc-java HOT 3 CLOSED

1. The native implementation of WebRTC has indeed two different approaches for audio and video. I don't know why they did this way. I've written JNI wrappers around the native code. That's why webrtc-java has the same different approaches for audio and video.
   
   The entry point to audio streaming is the AudioDeviceModule.
   
   If you want to stream audio from any connected input device, e.g. a microphone, you can simply set the device name in the AudioDeviceModule. Same for playback.
   
   To stream your custom audio input, e.g. from a file, you can provide a custom source to the AudioDeviceModule which will pull the audio frames from the source when a peer-connection has been established.
2. Adding a sink to a VideoTrack:

   webrtc-java/webrtc-demo/webrtc-demo-api/src/main/java/dev/onvoid/webrtc/demo/net/PeerConnectionClient.java

   Line 225 in 9e31c27

   videoTrack.addSink(frame -> publishFrame(peerConnectionContext.onRemoteFrame, frame));

Why does the receiving track also has VideoSource in the constructor

What do you mean?

3. As I mentioned this library mainly consists of JNI wrappers for the native WebRTC code. The tests have only one purpose, to check that there are no null pointers and the Java objects are correctly converted to the native implementation and vice versa.
   
   You can control creation of offers/answers with RTCOfferOptions and RTCAnswerOptions.
   
   SDP Munging is not part of official WebRTC. It's up to the users/developers to customly change the session descriptions. You can to that with webrtc-java as well.

This library does not (yet) implement a higher level abstraction around the native WebRTC implementation, it wraps the WebRTC code as it is implemented.

from webrtc-java.

Thanx for the answers, just to clarify the question about the Track :
Something which is not clear too me, in order to create a track there is only option through the factory for getting a new Track from the factory by add description, and source. But what if the track is for the remote peer and not the local. I think you answered that with the sample, as long as the transceiver is not empty there when the streaming starts.
It is just that something looks incomplete within those methods, as track "abstraction" should support source track as well as destination track the way I see it.
There should have been ability to read track from the disk and send it, and to "write" it as well on the remote side.
I'll look at the native implementation, cause something is weird there, as you noted about the difference between audio and video.

from webrtc-java.

Closing this. Please use the discussions section.

from webrtc-java.