Also make the ReadCloser an Controllable allows to uncouple
the controller implementation from the encoder.
This is not needed for the 2 codec controller already implemented (openh264 and vpx)
but is more future proof in case it required for other codecs.
There's been a long-standing TODO comment in the bridge for OpenH264 to
remove hardcoding for the set of configurable parameters exposed by that
library. That patch does exactly that.
The golang image.YCbCr struct can contain fields of arbitrary stride
lengths, which don't necessarily match the field widths. This
patch passes the stride values from the image.YCbCr struct into
the OpenH264 encode calls.
* Fix VPX_CODEC_INVALID_PARAM on resolution change
- When chaning resolution to a larger one,
vpx_codec_enc_config_set fails with VPX_CODEC_INVALID_PARAM.
- Creating a new codec object seems to be necessary.
* Address PR comments
- Free encoder old codec.
By switching to Makefile, parallel builds and single build are now
possible.
Examples:
Parallel Build:
make -j
Single Build:
make opus-darwin-x64
Also, since Makefile has a dependency change detection feature, the
build time is reduced significantly when there are only a few things that
change, Makefile will not rebuild everything unnecessarily.
With webrtc v3, users no longer need to bind or unbind manually anymore.
Changes:
* Switch from webrtc.RTPCodec to webrtc.RTPCodecParameters
* Fix broken examples after the upgrade
* NewRTPReader now accepts ssrc as a parameter
* Track interface now fulfills webrtc.TrackLocal requirements
VPX doesn't allow 0 duration. If 0 is given, vpx_codec_encode will fail with VPX_CODEC_INVALID_PARAM.
0 duration is possible because mediadevices first gets the frame meta data by reading from the source,
and consequently the codec will read the first frame from the buffer. This means the first frame won't
have a pause to the second frame, which means if the delay is <1 ms (vpx duration resolution), duration
is going to be 0.
Using mmal significantly boosts video fps by offloading the encoding
work from CPU to GPU. On a Raspberry Pi 3, libx264 only gives 480p18,
whereas mmal can give 720p30.
Previous reference frame update sequence was borrowed from
an example in libva-utils, however the quality of the output
was not good (block noised).
This commit disables alternate frame and updates golden frame only
on keyframe. It doesn't enable full referencing feature of VP8, but
ffmpeg vaapi encoder looks also not fully using golden frame and
alternate frame.
Resolves https://github.com/pion/mediadevices/issues/114
* Remove codec registrar
* Completely redesign how codec is being discovered, tuned, and built
* Update examples
* Update unit tests
Jingyang Kang