Pull in video frame fields into local variables. Without this the
compiler must assume that they could've changed on every use and read
them from memory again.
This reduces the inner loop from 6 memory reads per pixels to 4, and the
number of writes stays at 3.
PulseAudio defines PA_RATE_MAX as the maximum sampling rate that it
supports. We were previously exposing a maximum rate of INT_MAX, which
is incorrect, but worked because nothing was really using a rate greater
than 384000 kHz.
While playing DSD data, we hit a case where there might be very high
sample rates (>1MHz), and pulsesink fails during stream creation with
such streams because it erroneously advertises that it supports such
rates.
Since PA_RATE_MAX is #define'd to (8*48000U), we can't just use it in
the caps string. Instead, we fix up the rate to what we actually support
whenever we use our macro caps.
This allows us to use the GstVideoOverlayComposition API and correctly
handle pre-multiplied alpha, while also only doing the alpha conversion
once instead of twice for the whole frame.
At a later point we can attach the meta to the buffer instead of
blending ourselves if downstream supports that.
https://bugzilla.gnome.org/show_bug.cgi?id=797091
The speex headers assume that WIN32 will always be defined when
building on Windows, but this is only true by default on MinGW.
Always set it explicitly.
We now have options for all plugins, so we will just disable these in
the cerbero recipe instead. These require external deps, so they won't
affect gst-build either.
This effectively (but optionally) requires libjpeg-turbo which
ships with a .pc file and is what pretty much everyone these days
uses anyway for libjpeg, so shouldn't be a problem hopefully.
https://bugzilla.gnome.org/show_bug.cgi?id=796947
Otherwise there may be no valid typedef of GLsync.
...
/usr/include/gstreamer-1.0/gst/gl/gstglfuncs.h:93:24: note: in definition of macro 'GST_GL_EXT_FUNCTION'
ret (GSTGLAPI *name) args;
^~~~
/usr/include/gstreamer-1.0/gst/gl/glprototypes/sync.h:33:23: error: 'GLsync' has not been declared
(GLsync sync))
^~~~~~
...
https://bugzilla.gnome.org/show_bug.cgi?id=796879
gst_structure_get() is declared with G_GNUC_NULL_TERMINATED, ie
__attribute__((__sentinel__)), which means gcc will generate a
warning if the last parameter passed to the function is not NULL
(where a valid NULL in this context is defined as zero with any
pointer type).
The C code callers to gst_structure_get() within gst-plugins-good
use the C NULL definition (ie ((void*)0)), which is a valid sentinel.
However gstid3v2mux.cc uses the C++ NULL definition (ie 0L), which
is not a valid sentinel without an explicit cast to a pointer type.
Upstream-Status: Pending
Signed-off-by: Andre McCurdy <armccurdy@gmail.com>
Note from Edward Hervey: Patch from git.yoctoproject.org
musl libc generates warnings if <sys/poll.h> is included directly.
Upstream-Status: Pending
Signed-off-by: Andre McCurdy <armccurdy@gmail.com>
Tested on linux with X11/wayland and semi-tested on Windows.
Windows crashes on item destruction however this is better than nothing.
Fix up some win32 build issues on the way with mismatched {} and
G_STMT_{START,END}
Like pngenc, automatically send an EOS message.
Example of bin:
appsrc ! jpegenc snapshot=true ! filesink location=out.jpg
This is especially useful for limited/slow hardware.
Otherwise calling gst_video_convert_sample() is a better option
(internally uses videoconvert and videoscale).
https://bugzilla.gnome.org/show_bug.cgi?id=755453
If a lot of seek method is called very quickly, sometimes data reading
and do_request occurs while seek flush event is occurring and error
occurs because retry_count
reaches to the max. Thus, reset retry_count if flush occurs after
do_request and read_buffer.
https://bugzilla.gnome.org/show_bug.cgi?id=790199
Some cameras fail to send an end-of-image marker (EOI)
and can't be properly decoded by either JPEG or libjpeg.
This commit parses the frame, making sure it has an EOI.
If there isn't one, the EOI gets added to the buffer.
A similar fixup is done in the rtpjpegdepay element,
and it makes sense to do it in jpegdec as well.
Signed-off-by: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
https://bugzilla.gnome.org/show_bug.cgi?id=791988
This reverts commit 47fd4d391e.
This patch is incorrect. It doesn't actually compile, and causes a crash
because the viv-fb window implementation needs a native EGL handle
to pass to fbCreateWindow, but the GstGLDisplayEGL handleis actually
an EGLDisplay now (and gets cast to the wrong type)
This is a regression introduced by "03db374 - souphttpsrc: retry
request on early termination from the server"
The problem was that when seeking back to 0, we would not end up calling
add_range_header() which in addition to adding range headers *ALSO* sets
the read_position to the requested one.
This would result in a wide variety of later failures, like reading
again and again instead of stopping properly.
This simplifies the code a lot without any functional changes apart from
not closing the display connection. Closing the display connection is
not safe to do as it is shared between all other code in the same
process and no reference counting or anything happens at the platform
layer.
Move the package defines for GST_PLUGIN_DEFINE from the
command line into the source file to avoid quoting issues
(-DPACKAGE_NAME="foo" means the quotes won't actually make
it to the compiler and then it no longer gets a string constant).
1. Propagate the GstGLDisplay we create
2. Add the created GstGLContext to the propagated GstGLDisplay
Otherwise with multi-branch GL pipelines involving gtkglsink, things
will fall apart and errors will be genarated somewhere.
Except for gst/gl/gstglfuncs.h
It is up to the client app to include these headers.
It is coherent with the fact that gstreamer-gl.pc does not
require any egl.pc/gles.pc. I.e. it is the responsability
of the app to search these headers within its build setup.
For example gstreamer-vaapi includes explicitly EGL/egl.h
and search for it in its configure.ac.
For example with this patch, if an app includes the headers
gst/gl/egl/gstglcontext_egl.h
gst/gl/egl/gstgldisplay_egl.h
gst/gl/egl/gstglmemoryegl.h
it will *no longer* automatically include EGL/egl.h and GLES2/gl2.h.
Which is good because the app might want to use the gstgl api only
without the need to bother about gl headers.
Also added a test: cd tests/check && make libs/gstglheaders.check
https://bugzilla.gnome.org/show_bug.cgi?id=784779
This is useful for autoplay for example. With autoplay, it is necessary to
wait until the scene graph is fully set up. This signal is emitted once the
QML item node is ready. So, inside a connected slot, the pipeline's state
can be set to PLAYING to automatically start playback as soon as the QML
script is loaded.
https://bugzilla.gnome.org/show_bug.cgi?id=786246
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
Instead of just sending a sticky event with them downstream. This allows
getting the HTTP headers easily in the application, and especially also
on errors.
QML can destroy the video widget at any time, leaving
us with a dangling pointer. Use a lock and a proxy
object to cope with that, and block in the widget
destructor if there are ongoing calls into the widget.
Soup allows only up to two connections per host in a session,
if we use default value. When session sharing is used, however,
more connections might be required in a session.
(e.g., multi-audio adaptive streaming case)
https://bugzilla.gnome.org/show_bug.cgi?id=784495
Currently we only allowed HTTP proxy. Don't filter for the scheme, just check
if it looks like an URI. Soup will warn if the URI is invalid or if
proxy protocol is not supported. This enables using SOCKS 4/5 which is
directly implemented into GIO.
https://bugzilla.gnome.org/show_bug.cgi?id=783012
This allows timing out on network errors much earlier
(currently it takes ~15min to timeout) and we can still
unlock and change state in the meantime.
https://bugzilla.gnome.org/show_bug.cgi?id=571722
Tags are pushed to "videosrcpad"/"audiosrcpad" in
gst_dvdemux_add_pad() method, however they will be NULL
in this method, hence tags are not pushed.
Instead, send tag event to "pad" created gst_dvdemux_add_pad().
Signal no-more-pads when both pads are created
https://bugzilla.gnome.org/show_bug.cgi?id=743657
souphttpsrc now shares its SoupSession with other elements in the
pipeline via GstContext if possible (session-wide settings are all the
defaults), or if the context was forced by the application.
This allows multiple souphttpsrcs to reuse connections, cookies, etc.
https://bugzilla.gnome.org/show_bug.cgi?id=780140
Let libsoup handle redirection automatically.
And then, to figure out redirection uri, extract it on "restarted"
callback which will be fired before soup_session_send() is returned.
https://bugzilla.gnome.org/show_bug.cgi?id=778428
Fix a regression introduced by commit 183695c61a (refactor to use
Soup's sync API). The code previously attempted to reconnect when the
server closed the connection early, for example when the stream was put
in pause for some time.
Reintroduce this feature by checking if EOS is received before the
expected content size is downloaded. In this case, do the request
starting at the previous read position.
https://bugzilla.gnome.org/show_bug.cgi?id=776720
This check must be done only when we are sure the request was
successfully sent. soup_session_send() might fail without setting the
status code. In this case status code is 0 so we would only catch the
error after the seek range check. In this case we would report an error
saying that the seek range was not respected, instead of reporting the
underlying error that triggered the soup_session_send() failure.
https://bugzilla.gnome.org/attachment.cgi?bugid=777222
... so as to allow one clearly defined (absolute) positioning mode
that can cater for a variety of absolute but also relative positioning
with respect to edge or center.
The flow return values was stored in the element before because the
result had to be set from callbacks. This is not the case anymore, we
can return the flow result directly from functions, making the code
easier to understand.
https://bugzilla.gnome.org/show_bug.cgi?id=777222
The current code configures libsoup to handle redirections
transparently, without informing the caller, thus preventing the element
to record the redirect code and location uri.
Fix this by always setting the SOUP_MESSAGE_NO_REDIRECT, preventing
libsoup from handling the redirection. When we receive a redirection
request and libsoup can safely handle it, return a custom error which
triggers a retry with the new URI.
https://bugzilla.gnome.org/show_bug.cgi?id=777222
The encoder fails to initialise when we try to set GST_TAG_PREVIEW_IMAGEs
sent to use by qtdemux from iTunes-generated m4a files. We should
not just blindly translate the PREVIEW tag to file icon image types,
but check if the specific conditions required are met (i.e. image
type 1 must be a 32x32 PNG icon, and what we're getting is 500x500).
https://bugzilla.gnome.org/show_bug.cgi?id=776962
Especially don't put them into GstStructures in one way or another, just
ignore them or error out cleanly depending on the importance of their
content.
1. Need set use-default-fbo to qquickwindow during set property
to support change render target on the fly.
2. Calculate qmlglsrc refresh frame rate in qtglwindow
https://bugzilla.gnome.org/show_bug.cgi?id=774035
While computing the x and y offsets, it's the video resolution and
resized overlay resolution to be used instead of actual overlay image
resoltuion. Due to this, the overlay image used to get wrongly overlayed
in undesired location
https://bugzilla.gnome.org/show_bug.cgi?id=757292
souphttpsrc maintains two variables for the position:
* 'request_position' is where we want to be
* 'read_position' is where we are
During Normal operations both are updated in sync when data arrives. A seek
changes 'request_position' but not 'read_position'.
When the two positions get out of sync, then a new request is send and the
'Range' header is adjusted to the current 'request_position'.
Without this patch, if reading fails, then the source is destroyed. This
triggers a new request, but the range remains unchanged. As a result, the
old range is used and old data will be read.
Changing the 'read_position' to -1 makes it explicitly different from
'request_position' and as a result the 'Range' header is updated correctly.
https://bugzilla.gnome.org/show_bug.cgi?id=773509
GstAudioRingBuffer doesn't needs us to have at least 2 segments. We make
sure that if our buffer parameters are such that the maxlength is not at
least 2x fragsize, we still request the ringbuffer to keep that much
space so it continues to work.
https://bugzilla.gnome.org/show_bug.cgi?id=770446
If jackd changes the buffer size or sample rate, jackaudiosink hangs
and can't be stopped. This also happens if jack is configured as slave
and a gstreamer pipeline is started on the slave machine while the jack
master isn't running yet. If the the jack master is started it changes
the buffer size / sample rate and jackaudiosink can't be stopped.
This fix calls jack_shutdown_cb when jack_sample_rate_cb or
jack_buffer_size_cb is called.
https://bugzilla.gnome.org/show_bug.cgi?id=771272
When start qmlglsink app, it will set NULL buffer to GstQSGTexture
in which case that qt_context_ will be a random value and cause
gst_gl_context_activate() fail.
https://bugzilla.gnome.org/show_bug.cgi?id=770925
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.
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.
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.
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.
At the end of a range request, we don't want to return GST_FLOW_EOS otherwise
the last bytes we just read will be dropped by basesrc.
Instead just return GST_FLOW_OK (which was set just before) and let basesrc
handle the fact we are at the end of the segment.
If we're at the end of a range request, read again to let libsoup
finalize the request. This allows to reuse the connection again later,
otherwise we would have to cancel the message and close the connection.
We have to get rid of the message on EOS when the complete stream is read to
remember that we successfully finished handling this specific message.
Otherwise we will cancel it later and close the connection instead of reusing
it at a later time.
It might also make sense to reuse connections if a non-200 response is
received. As long as there was no connection error, the HTTP connection should
be re-usable.
There's no real reason to avoid sending QOS/NAVIGATION events upstrea.
Some elements might want to have that information.
Also remove downstream-only CAPS event handling and minimize code
Compiler would complain about include directory that didn't
exist because QPA_INCLUDE_PATH gets subst-ed regardless
(and if it didn't we'd have just an empty -I argument).
https://bugzilla.gnome.org/show_bug.cgi?id=767553
Update the blocksize depending on how much is obtained from a read
of the input stream. This avoids doing too many reads in small chunks
when larger amounts of data are available and also prevents using
a very large memory area to read a small chunk of data.
https://bugzilla.gnome.org/show_bug.cgi?id=767833
The current state of c++ ABI's on Window's and Gst's/Qt's conflicting
mingw builds means that we cannot use mingw for building the qt plugin.
Instead, a qmake .pro file is provided that is expected to be used with the
msvc binaries provided by Qt like so:
(with the PATH environment variable containing the path to the qt biniaries
and PKG_CONFIG_PATH containing the path to GStreamer modules)
cd /path/to/sources/gst-plugins-bad/ext/qt
qmake -tp vc
Then open the resulting VS project and build the library. Then
cp debug/libgstqtsink.dll /path/to/prefix/lib/gstreamer-1.0/libgstqtsink.cll
https://bugzilla.gnome.org/show_bug.cgi?id=761260
The heuristic to choose between packetise or not was changed to use the
segment format. The problem is that this change is reading the segment
during the caps event handling. The segment event will only be sent
after. That prevented the decoder to go in packetize mode, and avoid
useless parsing.
https://bugzilla.gnome.org/show_bug.cgi?id=736252
The heuristic to choose between packetise or not was change to use the
segment format. The problem is that this change is reading the segment
during the caps event handling. The segment event will only be sent
after. That prevented the decoder to go in packetize mode, and avoid
useless parsing.
https://bugzilla.gnome.org/show_bug.cgi?id=736252
Previously the segment.time was wrong, and the position was not updated
correctly, resulting in seeks in PUSH mode with upstream providing a BYTES
segment to not work at all.
https://bugzilla.gnome.org/show_bug.cgi?id=767157
This fixes seeking in DV streams where upstream operates in PUSH mode with a
TIME segment (e.g. avidemux). Without this, we would generate wrong durations
and timestamps after a seek.
https://bugzilla.gnome.org/show_bug.cgi?id=767157
