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
https://github.com/mesonbuild/meson
With contributions from:
Tim-Philipp Müller <tim@centricular.com>
Jussi Pakkanen <jpakkane@gmail.com> (original port)
Highlights of the features provided are:
* Faster builds on Linux (~40-50% faster)
* The ability to build with MSVC on Windows
* Generate Visual Studio project files
* Generate XCode project files
* Much faster builds on Windows (on-par with Linux)
* Seriously fast configure and building on embedded
... and many more. For more details see:
http://blog.nirbheek.in/2016/05/gstreamer-and-meson-new-hope.htmlhttp://blog.nirbheek.in/2016/07/building-and-developing-gstreamer-using.html
Building with Meson should work on both Linux and Windows, but may
need a few more tweaks on other operating systems.
When a frame's duration is too low, calling gst_util_uint64_scale()
to scale its value can result into it being truncated to zero, which
will cause the vpx encoder to return an VPX_CODEC_INVALID_PARAM error
when trying to encode.
To prevent this from happening, we simply ignore the duration when
encoding if it becomes zero after scaling, logging a warning message.
https://bugzilla.gnome.org/show_bug.cgi?id=765391
All code paths for handle_frame() must somehow take ownership of the frame, be
it by actually unreffing, forwarding the frame elsewhere or storing it for
later.
http://bugzilla.gnome.org/show_bug.cgi?id=760666
With the VPX decoders it's not simple to use downstream buffer pool,
because we don't know the image size and alignment when buffers get
allocated. We can though use GstAllocator (for downstream, or the system
allocator) to avoid a copy before pushing if downstream supports
GstVideoMeta. This would still cause a copy for sink that requires
specialized memory and does not have a GstAllocator for that, though
it will greatly improve performance for sink like glimagesink and
cluttersink. To avoid allocating for every buffer, we also use a
internal buffer pool.
https://bugzilla.gnome.org/show_bug.cgi?id=745372
This adds an automatic mode to the threads property of vpxdec in order to
use as many threads as there is CPU on the platform. This brings back
GStreamer VPX decoding performance closer to what is achieved by other
players, including Chromium.
https://bugzilla.gnome.org/show_bug.cgi?id=758195
Some files may provide different caps insight of one stream. Since
vp9enc support caps reinit, we should support cache reinit too.
If more then file cache file will be created, the naming will be:
cache cache.1 cache.2 ...
Based on patch by: Oleksij Rempel <linux@rempel-privat.de>
https://bugzilla.gnome.org/show_bug.cgi?id=747728
