- png: alloc size variable is a png type that's always 32-bit
- vpx: alloc size based on existing allocation
- wavpack: alloc size based on existing allocation
- icles: gdkpixbufoverlay: trusted and hard-coded input data
- rtp tests: rtp-payloading, vp8, vp9, h264, h265: trusted and/or static input data
g_memdup() is deprecated since GLib 2.68 and we want to avoid
deprecation warnings with recent versions of GLib.
Also use gst_buffer_new_memdup() instead of _wrapped(g_memdup(),..)
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/993>
- introduce two new properties:
* temporal-scalability-layer-flags:
Provide fine-grained control of layer encoding to the
outside world. The flags sequence should be a multiple of
the periodicity and is indexed by a running count of encoded
frames modulo the sequence length.
* temporal-scalability-layer-sync-flags:
Specify the pattern of inter-layer synchronisation (i.e.
which of the frames generated by the layer encoding
specification represent an inter-layer synchronisation).
There must be one entry per entry in
temporal-scalability-layer-flags.
- apply temporal scalability settings and expose as buffer
metadata.
This allows the codec to allocate a given frame to the correct
internal bitrate allocator. Additionally, all the
non-bitstream metadata needed to payload a temporally scaled
stream is now attached to each output buffer as a
GstVideoVP8Meta.
- add unit test for temporally scaled encoding.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/728>
With recent libvpx versions, multithreading can be enabled on
a per-tile basis, instead of on a per tile-column basis.
In combination with the new tile-rows property, this allows the
encoder to make much better use of the available CPU power.
Bump minimum libvpx version to 1.7.0
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/707>
As part of this also change the default bitrate value to 0. The default
value was 256000 previously. In reality, if the property was not set the
bitrate value would be scaled according to the resolution which is not
very intuitive behavior. It is better to use 0 for this purpose. Now
together with newly introduced property "bits-per-pixel" 0 means to
assign the bitrate according to resolution/framerate.
The default bitrates are now
- 1.2Mbps for VP8 720p@30fps
- 0.8Mbps for VP9 720p@30fps
and scaled accordingly for different resolutions/framerates.
Previously the default bitrate was also not scaled according to the
framerate but only took the resolution into account.
This also fixes the side effect of setting bitrate to 0. Previously
encoder would not produce any data at all.
Addition from Sebastian Dröge <sebastian@centricular.com> to assume
30fps if no framerate is given in the caps instead of not calculating
any bitrate at all.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/611>
For VP8 it's possible to signal width or height to be 0, but it does
not make sense to do so. For VP9 it's impossible. Hence, we most
likely have a corrupt stream. Trying to negotiate caps downstream with
either width or height as 0 will fail with something like
gst_video_decoder_negotiate_default: assertion 'GST_VIDEO_INFO_WIDTH (&state->info) != 0' failed
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/610>
In Google webrtc, the setting VP8E_SET_STATIC_THRESHOLD is set to 1
(except when the content is known to be static very often in which
case it is set to 100, i.e. when sharing screen with Google Hangouts).
The cpu usage drops a lot when using 1 for above setting because it
allows the encoder to skip static/low content blocks. The current
0 default value uses too much cpu and confuses the user regarding
the cpu usage expectations. User expects vp8enc to use low cpu by
default.
Documentation of VP8E_SET_STATIC_THRESHOLD:
https://github.com/webmproject/libvpx/blob/master/vpx/vp8cx.h#L188
chromium/webrtc:
b484ec0082/modules/video_coding/codecs/vp8/libvpx_vp8_encoder.cc (822)Closes#58
Used to print:
|Run-time dependency vpx found: YES 1.7.0
|Message: libvpx provides VP8 encoder interface (vpx_codec_vp8_cx_algo)
|Message: libvpx provides VP8 decoder interface (vpx_codec_vp8_dx_algo)
|Message: libvpx provides VP9 encoder interface (vpx_codec_vp9_cx_algo)
|Message: libvpx provides VP9 decoder interface (vpx_codec_vp9_dx_algo)
|Dependency vpx found: YES (cached)
|Dependency vpx found: NO found '1.7.0' but need: '>=1.8.0'
|Run-time dependency vpx found: NO (tried pkgconfig and cmake)
We can check the version of the found dep in a way that
doesn't produce this confusing output.
This fixes a memory leak. When dropframe-threshold has been set,
libvpx may output less frames than the input ones, which causes
some GstVideoCodecFrames to queue up in GstVideoEncoder's internal
frame queue with no chance of ever being all released. And because
the frames keep references to the input buffers, the input buffer
pool keeps allocating new buffers and memory usage grows very fast.
For example the following pipeline's memory usage grows at a rate
of about 1GB per minute!
videotestsrc ! capsfilter caps=video/x-raw,width=1920,height=1080,framerate=30/1,format=I420 ! \
vp8enc target-bitrate=1000000 end-usage=cbr dropframe-threshold=95 ! fakesink
https://bugzilla.gnome.org/show_bug.cgi?id=783086
