Allows finer grain decisions about formats and features at each
stage of the pipeline.
Also provide propose_allocation for glupload besed on the supported
methods.
Make GstGLMemory hold the texture target (tex_target) the texture it represents
(tex_id) is bound to. Modify gst_gl_memory_wrapped_texture and
gst_gl_download_perform_with_data to take the texture target as an argument.
This change is needed to support wrapping textures created outside libgstgl,
which might be bound to a target other than GL_TEXTURE_2D. For example on OSX
textures coming from VideoToolbox have target GL_TEXTURE_RECTANGLE.
With this change we still keep (and sometimes imply) GL_TEXTURE_2D as the
target of textures created with libgstgl.
API: modify GstGLMemory
API: modify gst_gl_memory_wrapped_texture
API: gst_gl_download_perform_with_data
Depending on the platform, it was only ever implemented to 1) set a
default surface size, 2) resize based on the video frame or 3) nothing.
Instead, provide a set_preferred_size () that elements/applications
can use to request a certain size which may be ignored for
videooverlay/other cases.
Add more power to the chunk_received function (renamed to data_received)
and also to the fragment_finish function.
The data_received function must parse/decrypt the data if necessary and
also push it using the new push_buffer function that is exposed now. The
default implementation gets data from the stream adapter (all available)
and pushes it.
The fragment_finish function must also advance the fragment. The default
implementation only advances the fragment.
This allows the subsegment handling in dashdemux to continuously download
the same file from the server instead of stopping at every subsegment
boundary and starting a new request
gstdashdemux.c:1330:13: error: implicit conversion from enumeration type 'enum _GstAdaptiveDemuxFlowReturn' to different enumeration type
'GstFlowReturn' [-Werror,-Wenum-conversion]
ret = GST_ADAPTIVE_DEMUX_FLOW_SUBSEGMENT_END;
~ ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
gmyth seems to be unmaintained upstream, and no one has asked
for this to be ported for a very long time, so let's just
remove it. Neither debian nor Fedora seem to ship libgmyth
any longer, and in any case it's most likely deprecated by
the UPnP support in MythTV.
The segment start time is calculated as the offset into the current segment.
The old condition to detect the end of period (i.e. segment start time >
period start + period duration) failed when the period start was not 0 since
the segment start time does not take the period start time into account.
Fix this detection by only comparing the segment start to the period duration.
https://bugzilla.gnome.org/show_bug.cgi?id=733369
The ISOBMFF profile allows definind subsegments in a segment. At those
subsegment boundaries the client can switch from one representation to
another as they have aligned indexes.
To handle those the 'sidx' index is parsed from the stream and the
entries point to pts/offset of the samples in the stream. Knowing that
the entries are aligned in the different representation allows the client
to switch mid fragment. In this profile a single fragment is used per
representation and the subsegments are contained in this fragment.
To notify the superclass about the subsegment boundary the chunk_received
function returns a special flow return that indicates that. In this case,
the super class will check if a more suitable bitrate is available and will
change to the same subsegment in this new representation.
It also requires special handling of the position in the stream as the
fragment advancing is now done by incrementing the index of the subsegment.
It will only advance to the next fragment once all subsegments have been
downloaded.
https://bugzilla.gnome.org/show_bug.cgi?id=741248
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
Optimize loop by moving condition outside of it and reuse the
find_next_fragment function to check if there is next instead of
replicating the same loop
Duration queries can be done a few times per second and would cause
the segment list to be traversed for every one. Caching the duration
prevents that.
Variable hands is already checked to contain a value previously at the beginning
of the current block (in line 504). There is no need to check again. This is
logically dead code.
CID 1197693
The duration values in playlists are approximate only, and for
playlist versions 2 and older they are only rounded integer values.
They cannot be used to timestamp buffers. This resulted in playback
gaps and skips because the actual duration of fragments is slightly
different. The solution is to only set the pts of the very first
buffer processed, not for each fragment.
q->bitrate is a guint64, but G_TYPE_INT may read fewer bits
off the stack, and if we pass more then the NULL sentinel
may not be found at the right place, which in turn might
lead to crashes.
https://bugzilla.gnome.org/show_bug.cgi?id=741751
hlsdemux assumes that seeking is not allowed for live streams,
however seek is possible if there are sufficient fragments in the
manifest. For example the BBC have live streams that contain 2 hours
of fragments.
The seek code for both live and on-demand is common code. The
difference between them is that an offset has to be calculated
for the timecode of the first fragment in the live playlist.
When hlsdemux starts to play a live stream, the possible seek range
is between 0 and A seconds. After some time has passed, the beginning of
the stream will no longer be available in the playlist and the seek
range is between B and C seconds.
Seek range:
start 0 ........... A
later B ........... C
This commit adds code to keep a note of the B and C values
and the highest sequence number it has seen. Every time it updates the
media playlist, it walks the list of fragments, seeing if there is a
fragment with sequence number > highest_seen_sequence. If so, the values
of B and C are updated. The value of B is used when timestamping
buffers.
It also makes sure the seek range is never closer than three fragments
from the end of the playlist - see 6.3.3. "Playing the Playlist file"
of the HLS draft.
https://bugzilla.gnome.org/show_bug.cgi?id=725435
For small amounts some data might be mistyped and it would cause
the pipeline to fail. For example if you have AAC inside mpegts,
for small amounts, the AAC samples would cause the typefinder to
think it is AAC and not mpegts.
https://bugzilla.gnome.org/show_bug.cgi?id=736061
If typefind fails, check to see if the buffer is too short for typefind. If this is the case,
prepend the decrypted buffer to the pending buffer and try again the next time around.
https://bugzilla.gnome.org/show_bug.cgi?id=740458
Corrected the final boundary mechanism so that a final boundary is
added to each mail with multipart content that is sent,
not just to the last one.
https://bugzilla.gnome.org/show_bug.cgi?id=741553
This reverts commit 15394aa705.
The latest release (v1.1) does not have pkg-config support
yet, so this plugin won't be built with the latest release.
Cerbero uses the latest release, so this makes cerbero
builds fail, which expect the plugin to be built.
We can re-commit this once there's a release that includes
pkg-config support.
Rework reverse fragment traversing with repetition fields to prevent
NULL pointer deref and avoid never advancing a fragment as the variable
is unsigned and would always be non-negative.
CID #1257627
CID #1257628
Read the "r" attribute from fragments to support fragments nodes
that use repetition to have a shorter Manifest xml.
Instead of doing:
<c d="100" />
<c d="100" />
You can use:
<c d="100" r="2" />
According to the HLS spec the remainder of the line following
the comma on EXTINF tag is not required. This patch removes
the fake title and saves some bytes on the playlist.
https://bugzilla.gnome.org/show_bug.cgi?id=741096
A context can create a GLsync object that can be waited on in order
to ensure that GL resources created in one context are able to be
used in another shared context without any chance of reading invalid
data.
This meta would be placed on buffers that are known to cross from
one context to another. The receiving element would then wait
on the sync object to ensure that the data to be used is complete.
This gives more flexibility to the subclasses and permits to remove the
GstVideoAggregatorClass->disable_frame_conversion ugly API.
WARNING: This breaks the API as it removes the disable_frame_conversion
field
API:
+ GstVideoAggregatorClass->find_best_format
+ GstVideoAggregatorPadClass->set_format
+ GstVideoAggregatorPadClass->prepare_frame
+ GstVideoAggregatorPadClass->clean_frame
- GstVideoAggregatorClass->disable_frame_conversion
https://bugzilla.gnome.org/show_bug.cgi?id=740768
If we seek when media is in stop state, playback-test gives
critical error, since context of glimagesink is destroyed during stop.
But since context is not present, we need not handle send_event in glimagesink
Hence adding a condition to check if context is valid.
https://bugzilla.gnome.org/show_bug.cgi?id=740305
Otherwise e.g. videotestsrc ! openh264enc ! ... will drop every second frame
because otherwise the target bitrate can't be reached without loosing too
much quality.
gst_glimage_sink_handle_events can be called from the overlay interface and from
the main thread before GL is setup. Before this change, that would call
_ensure_gl_setup() and deadlock on OSX.
Change things so that it's always safe to call gst_glimage_sink_handle_events()
without stuff deadlocking.
Remove gst_glimage_sink_handle_events call in gst_glimage_sink_init. It was
unnecessary and when the element was instantiated from the main thread, caused a
deadlock in OSX creating the context (thread).
Both Firefox and Chrome uses OPUS as the encoding in their SDP.
Adding this now defacto standard name remove the need for special
case in SDP parsing code.
https://bugzilla.gnome.org/show_bug.cgi?id=737810
with force-aspect-ratio=true, if the width or height changed, the
viewport wasn't being updated to respect the new video width and height
until a resize occured.
Otherwise, it is only possible for the sink pads and the src pads to
have the exact same caps features. We can convert from any feature
to another feature so support that.
Otherwise, it is only possible for the sink pads and the src pads to
have the exact same caps features. We can convert from any feature
to another feature so support that.
Do not try to render a buffer that is already being rendered.
This happens typically during the initial rendering stage as the first
buffer is rendered twice: first by preroll(), then by render().
This commit avoids this assertion failure:
CRITICAL: gst_wayland_compositor_acquire_buffer: assertion
'meta->used_by_compositor == FALSE' failed
https://bugzilla.gnome.org/show_bug.cgi?id=738069
Signed-off-by: Fabien Dessenne <fabien.dessenne@st.com>
Signed-off-by: Benjamin Gaignard <benjamin.gaignard@linaro.org>
If waylandsink is the owner of the display then it is in charge
of catching input events on the surface.
https://bugzilla.gnome.org/show_bug.cgi?id=733682
Signed-off-by: Tifaine Inguere <tifaine.inguere@st.com>
Reviewed-by: Benjamin Gaignard <benjamin.gaignard@linaro.org>
There are two cases covered here:
1) The GstWlDisplay forces the release of the last buffer and the pool
gets destroyed in this context, which means it unregisters all the
other buffers from the GstWlDisplay as well and the display->buffers
hash table gets corrupted because it is iterating.
2) The pool and its buffers get destroyed concurrently from another
thread while GstWlDisplay is finalizing and many things get corrupted.
The main reason behind this is that when the video caps change and the video
subsurface needs to resize and change position, the wl_subsurface.set_position
call needs a commit in its parent in order to take effect. Previously,
the parent was the application's surface, over which there is no control.
Now, the parent is inside the sink, so we can commit it and change size smoothly.
As a side effect, this also allows the sink to draw its black borders on
its own, without the need for the application to do that. And another side
effect is that this can now allow resizing the sink when it is in top-level
mode and have it respect the aspect ratio.
Because we no longer have a custom buffer pool that holds a reference
to the display, there is no way for a cyclic reference to happen like
before, so we no longer need to explicitly call a function from the
display to release the wl_buffers.
However, the general mechanism of registering buffers to the display
and forcibly releasing them when the display is destroyed is still
needed to avoid potential memory leaks. The comment in wlbuffer.c
is updated to reflect the current situation.
This reduces the complexity of having a custom buffer pool, as
we don't really need it. We only need the custom allocation part.
And since the wl_buffer is no longer saved in a GstMeta, we can
create it and add it on the buffers in the sink's render()
function, which removes the reference cycle caused by the pool
holding a reference to the display and also allows more generic
scenarios (the allocator being used in another pool, or buffers
being allocated without a pool [if anything stupid does that]).
This commit also simplifies the propose_allocation() function,
which doesn't really need to do all these complicated checks,
since there is always a correct buffer pool available, created
in set_caps().
The other side effect of this commit is that a new wl_shm_pool
is now created for every GstMemory, which means that we use
as much shm memory as we actually need and no more. Previously,
the created wl_shm_pool would allocate space for 15 buffers, no
matter if they were being used or not.
This also removes the GstWlMeta and adds a wrapper class for wl_buffer
which is saved in the GstBuffer qdata instead of being a GstMeta.
The motivation behind this is mainly to allow attaching wl_buffers on
GstBuffers that have not been allocated inside the GstWaylandBufferPool,
so that if for example an upstream element is sending us a buffer
from a different pool, which however does not need to be copied
to a buffer from our pool because it may be a hardware buffer
(hello dmabuf!), we can create a wl_buffer directly from it and first,
attach it on it so that we don't have to re-create a wl_buffer every
time the same GstBuffer arrives and second, force the whole mechanism
for keeping the buffer out of the pool until there is a wl_buffer::release
on that foreign GstBuffer.
Header will be read each and everytime parse function will be called
which is not necessary since until we have complete data,
we need not parse the header again.
https://bugzilla.gnome.org/show_bug.cgi?id=737984
In gst_hls_demux_get_next_fragment() the next fragment URI gets
stored in next_fragment_uri, but the gst_hls_demux_updates_loop()
can at any time update the playlist, rendering this string invalid.
Therefore, any data (like key, iv, URIs) that is taken from a
GstM3U8Client needs to be copied. In addition, accessing the
internals of a GstM3U8Client requires locking.
https://bugzilla.gnome.org/show_bug.cgi?id=737793
As openh264 has no way to attach any IDs to input frames that we then get on
the output frames, we have to assume that the input has valid PTS. We just
take the frame with the oldest PTS, and if there is no PTS information we take
the one with the oldest DTS.
- update for shaders
- add alpha property
- image placement properties shamelessly borrowed from gdkpixbufoverlay
- image placement properties are GstController able
- use GstGLMemory for the overlay image data
- add support for gles2
Otherwise we could pass on a RGBA formatted buffer and downstream would
misinterpret that as some other video format.
Fixes pipelines of the form
gleffects ! tee ! xvimagesink
Allows callers to properly reference count the buffers used for
rendering.
Fixes a redraw race in glimagesink where the previous buffer
(the one used for redraw operations) is freed as soon as the next
buffer is uploaded.
1. glimagesink uploads in _prepare() to texture n
1.1 glupload holds buffer n
2. glimagesink _render()s texture n
3. glimagesink uploads texture n+1
3.1 glupload free previous buffer which deletes texture n
3.2 glupload holds buffer n+1
4. glwindow resize/expose
5. glimagesink redraws with texture n
The race is that the buffer n (the one used for redrawing) is freed as soon as
the buffer n+1 arrives. There could be any amount of time and number of
redraws between this event and when buffer n+1 is actually rendered and thus
replaces buffer n as the redraw source.
https://bugzilla.gnome.org/show_bug.cgi?id=736740
If EOS or ERROR happens before the download loop thread has reached its
g_cond_wait() call, then the g_cond_signal doesn't have any effect and
the download loop thread stucks later.
https://bugzilla.gnome.org/show_bug.cgi?id=735663
If EOS or ERROR happens before the download loop thread has reached its
g_cond_wait() call, then the g_cond_signal doesn't have any effect and
the download loop thread stucks later.
https://bugzilla.gnome.org/show_bug.cgi?id=735663
If EOS or ERROR happens before the download loop thread has reached its
g_cond_wait() call, then the g_cond_signal doesn't have any effect and
the download loop thread stucks later.
https://bugzilla.gnome.org/show_bug.cgi?id=735663
The internal pad still keeps its EOS flag and event as it can be assigned
after the flush-start/stop pair is sent. The EOS is assigned from the streaming
thread so this is racy.
To be sure to clear it, it has to be done after setting the source to READY to
be sure that its streaming thread isn't running.
https://bugzilla.gnome.org/show_bug.cgi?id=736012
The internal pad still keeps its EOS flag and event as it can be assigned
after the flush-start/stop pair is sent. The EOS is assigned from the streaming
thread so this is racy.
To be sure to clear it, it has to be done after setting the source to READY to
be sure that its streaming thread isn't running.
https://bugzilla.gnome.org/show_bug.cgi?id=736012
The internal pad still keeps its EOS flag and event as it can be assigned
after the flush-start/stop pair is sent. The EOS is assigned from the streaming
thread so this is racy.
To be sure to clear it, it has to be done after setting the source to READY to
be sure that its streaming thread isn't running.
https://bugzilla.gnome.org/show_bug.cgi?id=736012
packetized mode is being set when framerate is being set
which is not correct. Changing the same by checking the
input segement format. If input segment is in TIME it is
Packetized, and if it is in BYTES it is not.
https://bugzilla.gnome.org/show_bug.cgi?id=736252
Previously we only refetched the playlist if downloading a fragment
has failed once. We should also do that if it failed a second or third time,
chances are that the playlist was updated now and contains new URIs.
face detection will be performed only if image standard deviation is
greater that min-stddev. Default min-stddev is 0 for backward
compatibility. This property will avoid to perform face detection on
images with little changes improving cpu usage and reducing false
positives
https://bugzilla.gnome.org/show_bug.cgi?id=730510
* aspect should not be 0 on init
* rename fovy to fov
* add mvp to properties as boxed graphene type
* fix transformation order. scale first
* clear color with 1.0 alpha
https://bugzilla.gnome.org/show_bug.cgi?id=734223
If the language is not specified in the AdaptationSet, use the ContentComponent
node to get it. We only get it if there is only a single ContentComponent as
it doesn't seem clear on what to do if there are multiple entries
https://bugzilla.gnome.org/show_bug.cgi?id=732237
Dynamic pipelines that get and release the sink pads will finalize
the pad without going through gst_gl_mixer_stop() which is where the
upload object is usually freed. Don't leak objects in such case.
Instead always use the low bandwith playlist making things go smoother
as the current heuristic is rather set for normal playback, and
currently it does not behave properly.
https://bugzilla.gnome.org/show_bug.cgi?id=734445
When a seek with a negative rate is requested, find the target
segment where gstsegment.stop belongs in and then download from
this segment backwards until the first segment.
This allows proper reverse playback.
If window is resized, GstStructure pointer values have to be rescaled to
original geometry. A get_surface_dimensions GLWindow class method is added for
this purpose and used in the navigation send_event function.
https://bugzilla.gnome.org/show_bug.cgi?id=703486
When flushing, this will prevent dashdemux from trying to download more
fragments or more chunks of the same fragment before stopping.
Also improves the error handling to not transform everything non-ok into
an error.
https://bugzilla.gnome.org/show_bug.cgi?id=734014
templatematch operates on BGR data. In fact, OpenCV's IplImage always
stores color image data in BGR order -- this isn't documented at all in
the OpenCV source code, but there are hints around the web (see for
example
http://www.cs.iit.edu/~agam/cs512/lect-notes/opencv-intro/opencv-intro.html#SECTION00041000000000000000
and http://www.comp.leeds.ac.uk/vision/opencv/iplimage.html ).
gst_templatematch_load_template loads the template (the image to find)
from disk using OpenCV's cvLoadImage, so it is stored in an IplImage in
BGR order. But in gst_templatematch_chain, no OpenCV conversion
functions are used: the imageData pointer of the IplImage for the video
frame (the image to search in) is just set to point to the raw buffer
data. Without this fix, that raw data is in RGB order, so the call to
cvMatchTemplate ends up comparing the template's Blue channel against
the frame's Red channel, producing very poor results.
Previously changing the template property resulted in an exception
thrown from cvMatchTemplate, because "dist_image" (the intermediate
match-certainty-distribution) was the wrong size (because the
template image size had changed).
Locking has also been added to allow changing the properties (e.g. the
pattern to match) while the pipeline is playing.
* gst_element_post_message is moved outside of the lock, because it will
call into arbitrary user code (otherwise, if that user code calls into
gst_templatematch_set_property on this same thread it would deadlock).
* gst_template_match_load_template: If we fail to load the new template
we still unload the previous template, so this element becomes a no-op
in the pipeline. The alternative would be to keep the previous template;
I believe unloading the previous template is a better choice, because it
is consistent with the state this element would be in if it fails to
load the very first template at start-up.
Thanks to Will Manley for the bulk of this work; any errors are probably
mine.
The early return was bypassing the call to gst_pad_push. With no
filter->template (and thus no filter->cvTemplateImage) the rest of this
function is essentially a no-op (except for the call to gst_pad_push).
This (plus the previous commit) allows templatematch to be
enabled/disabled without removing it entirely from the pipeline, by
setting/unsetting the template property.
Delaying the segment event to when caps are decided can cause issues as
the first thing katedec does on its chain function it doing a segment clip.
It will lead to an assertion if the segment format is undefined
https://bugzilla.gnome.org/show_bug.cgi?id=733226
Properly handle the caps event by configuring the kate decoding lib using the
available streamheaders. This makes it possible to decode kate subtitles when
the stream is seeked before katedec gets the initial buffers that are usually
the streamheaders.
https://bugzilla.gnome.org/show_bug.cgi?id=733226
The headers were never getting reffed when being added to the headers
list, which is later unreffed-and-freed by the caller (e.g.
gst_opus_parse_parse_frame()).
https://bugzilla.gnome.org/show_bug.cgi?id=733013
The expected default behaviour for video sink is to maintain the
aspect ratio. Fix the default value to reflect this. The property
default was already TRUE, but the value was not initially TRUE.
First this is handle by base transform, hence this is a no-op, and if it wasn't it
would lead to a buffer copy being leaked, and then an unreffed buffer being
pushed downstream.
https://bugzilla.gnome.org/show_bug.cgi?id=732756
OpenNI2 makes no guarantees of timestamp starting from zero, just that
it will be a millisecond timestamp. Make timestamps start from zero
manually so things work correctly.
https://bugzilla.gnome.org/show_bug.cgi?id=732535
