This fixes the echo program so it works properly on Safari
and Firefox, where the preferred offered dynamic media type
is not 96/VP8. It loads MediaEngine with codecs found in the
offer and then uses the payload type of the offer's preferred
video codec in the answer.
This commit has breaking changes. This API change means we
can no longer support an arbitrary number of receivers. For every track
you want to receive you MUST call PeerConnection.AddTransceiver
We do now support sending an multiple audio/video feeds. You can see
this behavior via gstreamer-receive and gstreamer-send currently.
Resolves#54
Fixes#515
This includes a few small and closely related changes:
1. All occurrences of the build tag `+build js` have been changed to the
more precise `+build js,wasm`. This will exclude the files from being
included by third-party compilers like GopherJS, with which they are
incompatible.
2. Some files which are incompatible with JavaScript/Wasm now have the
correct build tag (`+build -js`) so they will be excluded from Wasm
builds.
3. Some configuration options which are incompatible with
JavaScript/Wasm (or at least the current bindings) will now no longer
appear in Wasm builds. This meant creating new files with new struct
definitions and the appropriate build tags.
Syntax could be better but works in a standards-compliant way.
```
codec := webrtc.NewRTPH264Codec(webrtc.DefaultPayloadTypeH264, 90000)
codec.RTPCodecCapability.RTCPFeedback = []webrtc.RTCPFeedback{{
Type: "nack",
}, {
Type: "nack",
Parameter: "pli",
}}
```
Let's pull off the bandaid!
* Reduces studdering: webrtc.RTCTrack -> webrtc.Track
* Makes it easier to find types by editor autocomplete
* Makes code read more fluently (less repetition)
Since we're breaking the API in 2.0, our only chance to
do this is now.
Relates to #408
* allow GST examples to use g722
* Assume G722 is mono -- that's what chrome likes,
and i don't know if anyone's doing stereo g722 anyway
Relates to #283
