| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=758205
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=757895
|
|
|
|
|
|
|
|
| |
If tsdemux never receives data for a stream, the corresponding pad will never
be added and stream->active will remain FALSE. When the stream is removed, the
pad will not be unreffed and will be leaked.
https://bugzilla.gnome.org/show_bug.cgi?id=757873
|
|
|
|
|
|
|
|
| |
Otherwise, gst_vtenc_negotiate_profile_and_level will double-release as
it checks for profile_level != NULL. This caused crashes when the
vtenc instance is stopped and then restarted.
https://bugzilla.gnome.org/show_bug.cgi?id=757935
|
|
|
|
|
|
| |
Output caps being got from video info is not getting freed
https://bugzilla.gnome.org/show_bug.cgi?id=757929
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
It is up to the element handling the seek to send flush events
downstream, otherwise we end up with a situation where upstream
would get unexpected GST_FLOW_FLUSHING
|
|
|
|
|
|
|
|
|
|
| |
It's for the upstream element driving the pipeline to
handle seeks and send flush events or not, filters
should not interfere here, otherwise downstream pads
could be flushing before upstream pads are flushing,
which can result in GST_FLOW_ERROR being sent instead
of GST_FLOW_FLUSHING when trying to forward sticky
events at just the wrong moment.
|
|
|
|
|
|
|
|
| |
This reverts commit 6101fc57b8afac4f4e4aa742892f0d9c99d38a8c.
GstVideoEncoder assumes that the input buffer is available until _finish_frame.
https://bugzilla.gnome.org/show_bug.cgi?id=756951
|
|
|
|
| |
For all the other sample rates the encoder will have to resample internally.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
Differentiate the vp8/vp9 bitstream based on fourcc.
https://bugzilla.gnome.org/show_bug.cgi?id=757251
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This wl_display proxy is temporary only until waylandsink goes NULL,
at which point the connection to the display is disposed. Unfortunately,
if this is advertised as a GstContext, playbin will cache it and re-feed
it to the sink when it goes PLAYING again, but the wl_display pointer
will at that point be invalid and cause a crash.
Another solution to the problem would be to also cache the GstWlDisplay
object inside the GstContext, which would automatically ref-count
the display connection, but I see no reason in doing that at the moment,
as there are no known users of this GstContext outside waylandsink.
It's probably better to avoid chasing hidden refcounts.
https://bugzilla.gnome.org/show_bug.cgi?id=756567
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If a (master) playlist contains a variant list entry without a
URI then during parsing of the next variant list entry we are
a) leaking the entry we're currently parsing (new_list), and
b) free'ing the pointer to the previous list entry (list) without
updating the pointer.
Hence when then adding the URI for the latest parsed entry, incorrect
information is stored, as the information is used from 'list' which
is not valid memory anymore, also leading to crashes.
Fix this by correctly storing the new variant list entry pointer
as needed.
https://bugzilla.gnome.org/show_bug.cgi?id=756861
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=756876
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=756653
|
|
|
|
|
|
|
| |
The value is optional in the range, and if it is absent it means we should
download until the end of stream. Not until position 0.
https://bugzilla.gnome.org/show_bug.cgi?id=748316
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=756578
|
|
|
|
|
|
| |
COLOR_QCOM_FormatYVU420SemiPlanar32mMultiView for decoding
https://bugzilla.gnome.org/show_bug.cgi?id=756578
|
|
|
|
|
|
|
| |
SetWindowLong works only for 32 bit systems, thus windows events (move/resize)
where not interpreted on 64 bit systems
https://bugzilla.gnome.org/show_bug.cgi?id=756617
|
|
|
|
|
|
|
|
|
|
| |
In order to ensure the sequence_position will always be consistently updated,
store the current file duration.
This way, when we advance, we can always increment the position based on what
was previously outputted.
https://bugzilla.gnome.org/show_bug.cgi?id=752132
|
|
|
|
|
|
|
|
| |
Allows baseclass to handle it from there
Related to:
https://bugzilla.gnome.org/show_bug.cgi?id=756563
|
|
|
|
|
|
|
|
|
|
| |
Store and copy input state fields when setting the
output state of the decoder. Avoids problems like
the framerate set by an upstream element being ignored
Related to:
https://bugzilla.gnome.org/show_bug.cgi?id=756563
|
|
|
|
|
|
|
| |
Makes sure the mngr struct reflects a clean state
for the next frame, avoiding failures like:
https://bugzilla.gnome.org/show_bug.cgi?id=756563
|
|
|
|
|
|
|
| |
Fixes assertion due to the sink_finalize() being run before the widget destroy
callback.
https://bugzilla.gnome.org/show_bug.cgi?id=755969
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=756592
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For live streams, we want to make sure there's a certain distance
between the sequence to play and the last (earliest) fragment.
The problem is that it assumes there are at least 3 fragments in
the playlist, which might not always be the case (like in the case
of a server restarting and gradually adding fragments).
In order to avoid ending up with negative sequence numbers (which
will just loop forever), limit the new target sequence number to
the highest of:
* either the first sequence number of the playlist (fallback)
* or 3 fragments from the last one (standard behaviour)
|
|
|
|
|
|
| |
Found with gst-inspect-1.0 -b in gst-uninstalled env.
https://bugzilla.gnome.org/show_bug.cgi?id=756383
|
|
|
|
|
|
| |
When getting sample from taglist, the memory is not being freed resulting in memory leak.
https://bugzilla.gnome.org/show_bug.cgi?id=756070
|
|
|
|
| |
Identical to how the z-order property is proxied
|
|
|
|
|
|
|
|
| |
Build error due to wrong argument type in debug message
aagg->priv->offset and next_offset are of type int64, but uint64
formatter is being used in logs. Changing all those to int64
https://bugzilla.gnome.org/show_bug.cgi?id=756065
|
|
|
|
|
|
|
| |
gst_mpd_client_has_next_period now calls gst_mpd_client_setup_media_presentation
to refresh the period information.
https://bugzilla.gnome.org/show_bug.cgi?id=756186
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=756001
|
| |
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=755892
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=755981
|
|
|
|
|
|
| |
offset
https://bugzilla.gnome.org/show_bug.cgi?id=755824
|
|
|
|
|
|
|
| |
instead of always using 0. Otherwise we might output a lot of silence in the
beginning instead of outputting from the relevant position.
https://bugzilla.gnome.org/show_bug.cgi?id=755623
|
| |
|
|
|
|
|
|
|
| |
segment.time and segment.start can stay the same, and were always the same
before anyway because of a mistake.
https://bugzilla.gnome.org/show_bug.cgi?id=755623
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=752230
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=752230
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=752230
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=752230
|
|
|
|
|
|
|
|
|
|
|
| |
The same has to be done for AdaptationSet and SegmentList nodes still.
Also this does not correctly implement the semantics: by default Period (and
other nodes) should only be loaded when needed, not in the very beginning. We
need to implement lazy loading for them, which means adjusting
gst_mpd_client_setup_media_presentation().
https://bugzilla.gnome.org/show_bug.cgi?id=752230
|
|
|
|
|
|
| |
MPD resources if needed
https://bugzilla.gnome.org/show_bug.cgi?id=752230
|