Directly setting audio/x-raw caps leads to problems when the delivered
data blocks do not align properly at sample boundaries (for example, a
data block with 391 bytes). So, instead, set audio/x-unaligned-raw to
let a parser be autoplugged.
https://bugzilla.gnome.org/show_bug.cgi?id=689460
Non-blocking read will return the amount of data available without
blocking to wait for the full requested size.
The downside is that now it souphttpsrc needs to have a waiting
mechanism in case there is no data available yet to avoid busy
looping arond the inputstream.
The previous ones resulted in odd display aspect ratios and were different
from the ones used by e.g. ffmpeg. The new ones now result in display aspect
ratios of 4:3 and 16:9.
https://bugzilla.gnome.org/show_bug.cgi?id=765946
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
Fix syntax errors when compiling against cerbero-provided libmpg123
headers. We do the same as the libmpg123 internal visual studio
build here.
mpg123.h(1378): error C2143: syntax error: missing ')' before '('
mpg123.h(1378): error C2081: 'ssize_t': name in formal parameter list illegal
mpg123.h(1378): error C2143: syntax error: missing ')' before '*'
mpg123.h(1378): error C2091: function returns function
mpg123.h(1378): error C2143: syntax error: missing '{' before '*'
mpg123.h(1378): error C2059: syntax error: ')'
mpg123.h(1379): error C2143: syntax error: missing ')' before '*'
mpg123.h(1379): error C2365: 'off_t': redefinition; previous definition was 'typedef'
...
This reverts commit 0dd46accf6.
With some audiosinks, starting the ringbuffer on the first commit
causes audio glitches at startup by starting to output segments
from the ringbuffer before it has been filled / fully prerolled. This
doesn't usually happen with pulsesink because we map the pulseaudio
ringbuffer directly, but we should keep things consistent with
other sinks with regards to startup latency, plus it gives more
headway to avoid glitching, should the initial 2nd segment take
more than 10ms to generate.
https://bugzilla.gnome.org/show_bug.cgi?id=657076
Remove calls to gst_pad_has_current_caps() which then go on to call
gst_pad_get_current_caps() as the caps can go to NULL in between. Instead just
use gst_pad_get_current_caps() and check for NULL.
https://bugzilla.gnome.org/show_bug.cgi?id=759539
rename gst-launch --> gst-launch-1.0
replace old elements with new elements(ffmpegcolorspace -> videoconvert, ffenc_** -> avenc_**)
fix caps in examples
https://bugzilla.gnome.org/show_bug.cgi?id=759432
The old code was using gst_caps_normalize() and was generally overly
complex. Simplify by picking sample rate and number of channels from
upstream and the sample format from the allowed caps. If the format caps
is a list of strins, just pick the first one. And if the srcpad isn't
linked yet, use the default format (S16).
https://bugzilla.gnome.org/show_bug.cgi?id=740195
It's possible that the sink element will be freed before the widget is
destroyed. When the widget was eventually destroyed, it was attempting to
access member variables of the freed sink struct which resulted in undefined
behaviour.
Fix by disconnecting our signal on finalize.
https://bugzilla.gnome.org/show_bug.cgi?id=762098
CPU waits are more expensive and are only required if the CPU is ever going to
access the data. GPU waits perform inter-context synchronisation and are cheaper
as they don't require CPU intervention.
We already pass the entire frame to the decoder. If the decoder ask for
more data, don't pass the same data again as this leads to infinit loop.
Instead, simply fail the fill function to signal the problem with that
frame. It will then be skipped properly.
https://bugzilla.gnome.org/show_bug.cgi?id=761670
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
We don't directly link to GL in the element, though we use GL headers.
For this reason we need to include the proper GL headers path. This
prevent this element from using a different GL header then libgstgl.
The base class is useful for having multiple backing memory types other
than the default. e.g. IOSurface, EGLImage, dmabuf?
The PBO transfer logic is now inside GstGLMemoryPBO which uses GstGLBuffer
to manage the PBO memory.
This also moves the format utility functions into their own file.
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
The scene graph can be initialized when the we receive window handle change
notification and so we will not receive a scenegraph initialization
notification. Initialize ourself in this case.
https://bugzilla.gnome.org/show_bug.cgi?id=758337
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
When jpeg_finish_decompress is called, output state reference is being created.
But if there is any failures in finishing decompress, it jumps to setjmp,
and at that point state was not referenced. Resulting in leak of output state.
Hence adding another setjmp after output state is referenced.
Similarly adding another setjmp to unmap the frame in case error happens before
finish_decompress
https://bugzilla.gnome.org/show_bug.cgi?id=753087
There is a possibility that the _get_caps impl will be called with the
feature in the filter caps which when interecting with the template,
will return EMPTY and therefore fail negotiation.
https://bugzilla.gnome.org/show_bug.cgi?id=757854
A GstGLShader is now simply a collection of stages that are
compiled and linked together into a program. The uniform/attribute
interface has remained the same.
The problem is that the filesrc and souphttpsrc are behaving
differently regarding the calculation of the segment boundaries. The
filesrc is using a non-inclusive boundaries, while the souphttpsrc
uses inclusive. Currently the hlsdemux calculates the boundaries as
inclusive, so for this reason there is no problem with the souphttpsrc,
but there is an issue in the filesrc.
The GstSegment is non-inclusive, so the proposed solution is to use
non-inclusive boundaries in the hlsdemux in order to be consistent.
Make the change in the hlsdemux, will break the souphttpsrc, which
will expect inclusive boundaries, but the hlsdemux will offer
non-inclusive. This change makes sure that the non-inclusive
boundaries are converted to inclusive.
https://bugzilla.gnome.org/show_bug.cgi?id=748316
These allow a failed request to be retried after the given number of seconds
instead of failing the pipeline. Take account of the Retry-After header if
present. Add retries parameter that controls the number of times an HTTP
request will be retried before failing.
https://bugzilla.gnome.org/show_bug.cgi?id=756318
If soup message is not created then the same should not be passed
on, which is resulting in segfault. Hence throwing a warning message
and returning
https://bugzilla.gnome.org/show_bug.cgi?id=755326
We don't necessarily have full control over the input tags, so
it's possible that the ISRC tag contains a longer string than
expected, in which case we'd write over the end of the static-size
13 byte buffer that is FLAC__StreamMetadata_CueSheet_Track::isrc.
Make sure to only copy the ISRC if it's not too long, and make
sure the buffer we write to is always NUL-terminated by using
g_strlcpy().
CID 1324931.
In case the format changed fast and the pending format is different
than the currently set but the currently set is equal to the pending
one we could end up having mismatch between the finally set format
and the data stream format.
https://bugzilla.gnome.org/show_bug.cgi?id=755542
When passing the taglist to gst_audio_decoder_merge_tags, the reference is increased
by audiodecoder and the caller should free the taglist being passed.
https://bugzilla.gnome.org/show_bug.cgi?id=753903
Should just compare with what can be immediatelly accepted by
the element. flacenc can't renegotiate so if it has a caps already
it should only accept if it is that caps otherwise just use the
template caps
Removes the need for custom caps query handling and makes it more
correct from the beginning on the template. It is a bit uglier
to read because there is 1 entry per channel but makes code easier
to maintain.
We need to keep the active buffer (the one we have retreive a
texture id from) otherwise it's racy and upstream may upload
new content before we have rendered or during later redisplay.
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
Some files may provide different caps insight of one stream. Since vp8enc
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
...
https://bugzilla.gnome.org/show_bug.cgi?id=747728
To allow souphttpsrc to be use HTTP methods other than GET
(e.g. HEAD), add a "method" property that is a string. If this
property is not set, GET is used.
https://bugzilla.gnome.org/show_bug.cgi?id=752413
1) If the system http_proxy environment variable is not set
or set to an empty string, we must not set proxy to avoid
http connection error.
2) In case of proxy property setting, if user want to clear
the proxy setting, they should be able to set it to NULL or
an empty string again, so this is fixed too.
3) Check if the proxy string was parsed correctly.
https://bugzilla.gnome.org/show_bug.cgi?id=752866
They require to get_proc_address some functions through the
platform specific {glX,egl}GetProcAddress rather than the default
GL library symbol lookup.
They require to get_proc_address some functions through the
platform specific {glX,egl}GetProcAddress rather than the default
GL library symbol lookup.
Document that "widget" property must be accessed from the
main thread (where GTK is running). This is the same for
state transition on these elements. It is very natural to
do so un GTK applications.
This is a "pseudo" base class. Basically it's a shared instance
and class structure and a shared set of function between the
two widget. It cannot have it's own type like normal base class
since the one instance will implement GtkGLArea while the other
implements GtkDrawingAreay. To workaround this, the parent instance
and class is a union of both.
https://bugzilla.gnome.org/show_bug.cgi?id=752441
Move back the default property at the same place they are in the
other sink. This helps when using a diff viewer to synchronized
this unfortunate copy paste.
https://bugzilla.gnome.org/show_bug.cgi?id=751104
In GTK dispose can be called before the last ref is reached. This
happens when you close the container window. The dispose will be
explicitly called, and destroyed notify will be fired. This patch
fixes this race by properly tracking the widget state.
In the sink, we now set the widget pointer to NULL, so the widget
will properly get created again if you set your pipeline to NULL
state after the widget was destroy, and set it back to PLAYING.
https://bugzilla.gnome.org/show_bug.cgi?id=751104
Very much in the same spirit as the Gtk GL sink
Two things are provided
1. A QQuickItem subclass that renders out RGBA filled GstGLMemory
buffers that is instantiated from qml.
2. A sink element that will push buffers into (1)
To use
1. Declare the GstGLVideoItem in qml with an appropriate
objectName property set.
2. Get the aforementioned GstGLVideoItem from qml using something like
QQmlApplicationEngine engine;
engine.load(QUrl(QStringLiteral("qrc:/main.qml")));
QObject *rootObject = engine.rootObjects().first();
QQuickItem *videoItem = rootObject->findChild<QQuickItem *> ("videoItem");
3. Set the videoItem on the sink
https://bugzilla.gnome.org/show_bug.cgi?id=752185
Checking for a parent is not enough, it must have a toplevel one.
If widget has no toplevel parent then add it in a GtkWindow, that
make it usable from gst-launch-1.0.
https://bugzilla.gnome.org/show_bug.cgi?id=751104
for files which have corrupted header, libflac is not able to
process the metadata properly. We just try to ignore the error
and continue with the processing, since metadata parsing is not
making much of a difference to libflac
https://bugzilla.gnome.org/show_bug.cgi?id=751334
Getting the current viewport and modifying it relatively will produce an
interesting feedback loop during widget resizing. Over a few frames we
will gradually move the viewport a bit until it converged again, adding
unnecessary additional borders at the top and left.
This patch allow going gst-inspect-1.0 on these elements removing
ugly crash that was previously occurring. The method consist of
making the widget creation as lazy as possible. This way we don't
endup doing gtk_init() before the application. We also ref_sink()
the widget, so we don't crash if the parent widget is discarded,
and cleanly error out with GL if the widget has no parent window,
because calling gtk_widget_realized() can only be done if the widget
has been parented to a window).
The framerate very often is just an indication of the ideal framerate, not the
actual framerate of the stream. By just using the framerate, we confuse the
rate control algorithm algorithm as multiple frames will map to the same PTS
or have durations of 0.
https://bugzilla.gnome.org/show_bug.cgi?id=749122
handle_frame() is supposed to consume @frame, so if we don't call
gst_video_decoder_drop_frame() or gst_video_decoder_finish_frame() we have to
release it manually.
https://bugzilla.gnome.org/show_bug.cgi?id=748909
... instead of just counting frames. The values are supposed to be in timebase
units, not frame units. This fixes various quality problems with VP8/VP9
encoding and in general makes the encoder behave better.
Thanks to Nirbheek Chauhan for noticing this bug.
In pulsesink_query function, we use a switch for the query
type. In the CAPS case, there is no 'break', instead we
return right away. Use a break and return at the end of
the function instead for better code readability.
https://bugzilla.gnome.org/show_bug.cgi?id=744461
If we can not create probe stream in query_getcaps function, it will appear
memory leakage from format info.
The following patch prevent memory leakage in pulsesink.
https://bugzilla.gnome.org/show_bug.cgi?id=743178
basesrc assumes that we don't return a buffer if
something else than OK is returned. It will just
leak any buffer we might accidentially provide
here.
This can potentially happen during flushing.
Maybe fixes https://bugzilla.gnome.org/show_bug.cgi?id=741993
Set positioning-mode=pixels-absolute to allow positioning with
absolute coordinates, meaning negative x/y offsets will be
interpreted as being to the left/above the video frame instead
of being interpreted as relative to the right/bottom edge of
the video frame (which is a silly default, but that's how it is).
This means we can nicely slide images into and out of the frame,
see gdkpixbufoverlay-test.
https://bugzilla.gnome.org/show_bug.cgi?id=739566
http://www.wavpack.com/file_format.txt:
"Both the APEv2 tags and/or ID3v1 tags must come at the end of the
WavPack file, with the ID3v1 coming last if both are present."
WavPack files that contain APEv2 tags at the beginning of the files
are unplayable on players that use FFmpeg (like VLC) and most other
software (except Banshee). Players that use libwavpack directly can
play the files because it skips the tags, but does not recognize the
tag data at that location.
https://bugzilla.gnome.org/show_bug.cgi?id=711437
This avoids _set_format setting the unpositioned flag when passed
NULL as channel positions, as it would not be cleared when setting
actual channel positions later.
ARNR type control in libvpx has been deprecated so this commit mark the
vp8enc and vp9enc associated properties as deprecated and change their
behavior to just display a warning message.
https://bugzilla.gnome.org/show_bug.cgi?id=739476
Right now in parse logic the signature is checked every time the parse function
is called, and the whole data is the scanned each and every time, even though the
data is scanned in the previous instance. Changing the logic such that, we skip
the bytes which are already scanned in the previous instances of parse. This
helps in avoiding multiple scan of already scanned data/signature.
https://bugzilla.gnome.org/show_bug.cgi?id=737708
We need a mechanism in PulseAudio to allow running code outside the
mainloop lock. Then we'd be able to post to the bus (taking the
GST_OBJECT_LOCK), without worrying about locking order with the mainloop
lock, which is the current cause of deadlocks while trying to post the
stream status messages.
https://bugzilla.gnome.org/show_bug.cgi?id=736071
Stream headers are updated whenever ::set_caps is called, so we can't assume
they'll be valid before the message body is written out. We *can* assume that
for queued buffers, but SOUP_MEMORY_STATIC is still wrong for those.
Also, add some debug logging for stream header interactions.
https://bugzilla.gnome.org/show_bug.cgi?id=737771
::render sets a new callback for writing out new buffers only if there aren't
already buffers queued for writing with a previously-scheduled callback.
However, if the previously-scheduled callback is interrupted by a state change
(either manually or due to an error) and there are still buffers in the queue,
restarting the pipeline will result in buffers being queued forever, and no
callbacks will ever be scheduled, and no buffers will be written out.
https://bugzilla.gnome.org/show_bug.cgi?id=737739
This gives a quick introduction to how the pulsesink/pulsesrc code
interacts with the pa_threaded_mainloop that we start up to communicate
with the server.
The stream status messages are emitted in the PA mainloop thread, which
means the mainloop lock is taken, followed by the Gst object lock (by
gst_element_post_message()). In all other locations, the order of
locking is reversed (this is unavoidable in a bunch of cases where the
object lock is taken by GstBaseSink or GstAudioBaseSink, and then we get
control to take the mainloop lock).
The only way to guarantee that the defer callback for stream status
messages doesn't deadlock is to either stop posting those messages, or
make sure that the message emission is completed before we proceed to
any point that might take the object lock before the mainloop lock
(which is what we do after this patch).
https://bugzilla.gnome.org/show_bug.cgi?id=736071
