The property location has been changed in favor of vertex/fragment
string properties; the doc had not been updated and was still referring
to the previous property; also, now the #version header has become mandatory
https://bugzilla.gnome.org/show_bug.cgi?id=759902
No need to attempt splitting the RGB string in 255 tokens
if we only expect 3.
Left max_tokens at 4 to preserve the current logic (which
allows for extra stuff at the end) and added a warning on
parsing failure instead of silently discarding the value.
The URI attribute from the EXT-X-KEY tag and the URI attribute from the
EXT-X-I-FRAMES-ONLY tag are both quoted-string attibutes that have their
quotation marks removed during parsing. The CODECS attribute of the
EXT-X-STREAM-INF is also a quoted-string attribute, but this attribute
was not being un-quoted.
This commit changes the parser to always unquote all quoted-string
attributes and adjusts the unit tests to this new bevahiour for the
CODECS attribute.
An additional test is added to check that parsing of all of the fields
in the EXT-X-STREAM tag is correct, including those that contain comma
characters.
https://bugzilla.gnome.org/show_bug.cgi?id=758384
Clear error as soon as we determine that the download failed,
otherwise there are code paths where we might return without
clearing it ever, which would leak the GError then. Also, we
can pass a NULL GError pointer to _fetch_uri(), so just do that
instead of passing one that we're going to just free again
right away anyway.
Adds more meaningful error than
"Failed to convert multiview video buffer", which is always used
when prepare_next_buffer() fails in gst_glimage_sink_prepare().
https://bugzilla.gnome.org/show_bug.cgi?id=743345
Update opencvtextoverlay to inherit from GstOpencvVideoFilter instead of
from GstElement. This means less code and more uniformity with other OpenCV
elements. The chain/transform function is now a third of the size than
before.
Update pyramidsegment to inherit from GstOpencvVideoFilter instead of from
GstElement. This means less code and more uniformity with other OpenCV
elements.
Update pyramidsegment to inherit from GstOpencvVideoFilter instead of from
GstElement. This means less code and more uniformity with other OpenCV
elements.
Update motioncells to inherit from GstOpencvVideoFilter instead of from
GstElement. This means less code and more uniformity with other OpenCV
elements.
Add gst_gl_memory_allocator_get_default to get the default allocator based on
the opengl version. Allows us to stop hardcoding the PBO allocator which isn't
supported on gles2.
Fixes GL upload on iOS9 among other things.
Performing any GL function marshalling off the GL thread with glimagesink's
render lock is prone to deadlocks between the GL thread and the non-GL thread.
What can happen is this:
1. non-GL thread attempts to function marshal to the GL thread.
2. while 1 is happening, the winsys gives an event (say resize)
3. This calls back into glimagesink which taks the render lock.
4. As the GL function marshalling is attempting to run on the GL
and already has glimagesink's render lock locked. This deadlocks
as the threads are waiting for each other.
Update edgedetect to inherit from GstOpencvVideoFilter instead of from
GstElement. This means less code and more uniformity with other OpenCV
elements.
Adding the support for the two other OpenCV linear filters to smooth
images. The new API does support spatial sigma in the bilateral filter,
hence bringing that property back.
Adding reference to new documentation.
The OpenCV cvSmooth function is deprecated [0] and the documentation
recommends to use GaussianBlur (). This makes the spatial property go
unused. Marking it as deprecated, making it non-functional and will remove
in the next cycle.
[0] http://docs.opencv.org/2.4/modules/imgproc/doc/filtering.html
gst_mpdparser_parse_utctiming_node does not validate the parsed values completely. The following scenarios are incorrectly accepted:
- elements with no schemeIdUri property should be rejected
- elements with unrecognized UTCTiming scheme should be rejected
- elements with empty values should be rejected
The last one triggers a division by 0 in gst_dash_demux_poll_clock_drift:
clock_drift->selected_url = clock_drift->selected_url % g_strv_length (urls);
because it urls is a valid pointer to an empty array.
https://bugzilla.gnome.org/show_bug.cgi?id=759547
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.
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 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.
The opencv element includes were full of duplicates and uneeded headers.
For example a few elements that stopped using gstcvopencvutils still
included that header file.
Since commit 45ca8876b2 nobody is using
gst_opencv_get_ipl_depth_and_channels() or
gst_opencv_parse_iplimage_params_from_structure(). Remove this dead
code.
Setting the seek flags to GST_SEEK_FLAG_SNAP_* will change the seek
target time to a segment boundary.
Based on original work by Ben Willers <bwillers@digisoft.tv>.
https://bugzilla.gnome.org/show_bug.cgi?id=759108
Dashdemux has set the width and height information from MPD manifest.
Some embedded devices which are not insufficient H/W resources need more information such as framerate
to assign H/W resources. So I suggested that dashdemux also needs to set the framerate information from MDP manifest.
https://bugzilla.gnome.org/show_bug.cgi?id=758515
As HLS does not provide any way of knowing the server's clock, and we do
buffering of "live" streams, at some point we will fall behind the server in
many cases and would have to advance to a fragment that is not in the playlist
anymore.
Previously we would've just resynced to the next oldest fragment that is still
there, but this causes problems as from this point onwards we would always
fall off the playlist again all the time.
Instead we now resync and move to the 3rd newest fragment like we would do
when starting playback of a live stream.
https://bugzilla.gnome.org/show_bug.cgi?id=758987
If connection speed is set, playlist according
to connection speed is selected as current playlist.
Problem is that the current variant of main playlist still
points to previously set variant.
If previously set variant doesn't correspond to current
playlist, then it causes unnecessary change of playlist
to the same playlist after first fragment is downloaded,
because of not updated current variant.
To fix this, we need to make sure that current variant
of main playlist corresponds to the current playlist
https://bugzilla.gnome.org/show_bug.cgi?id=758946
Don't jump backward to 3 files from the end of the playlist
when switching variants - it just means we downloaded
fragments fast and caught up to the end of the playlist.
Disable that by treating a variant switch as a playlist
update, not a restart due to a seek or so.
If the stream is discont, we must provide a timestamp in any case. Elements
like tsdemux are not going to output anything if we give a NONE timestamp
after a discont.
Also marking a stream as discont if a playlist change was not successful would
lead to the above situation, but in that case we are not required at all to
mark the stream discont as we're still at the old playlist.
commit da5c41930c removed the two uses of the
new value of data:
channels = opus_packet_get_nb_channels (data);
bandwidth = opus_packet_get_bandwidth (data);
Since then, data isn't being used between incrementing it by packet_offset
and going out of scope. Removing this uneeded statement.
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
The result of the two expressions will be promoted to guint64 anyway,
perform all the arithmetic in 64 bits to avoid potential overflows.
CID 1338690, CID 1338691
sample_rate might be used uninitialized if !sink_caps is TRUE. Initialize
it to the default used in gst_codec_utils_opus_parse_caps () when there is
no rate defined in the caps.
CID 1338695
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'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.
No need to use G_GINT64_FORMAT for potentially negative values of
GstClockTimeDiff. Since 1.6 these can be handled with GST_STIME_FORMAT.
Plus it creates more readable values in the logs.
https://bugzilla.gnome.org/show_bug.cgi?id=757480
We always require the channel-mapping-field. If it's 0 we require nothing
else, otherwise we need channels, stream-count and coupled count to be
available.
oggdemux is outputting the meta now, and only outputs if it should really
apply to the current buffer. Previously we would skip N samples also if we
started the decoder in the middle of the stream.
https://bugzilla.gnome.org/show_bug.cgi?id=757153
It is doing the wrong thing because of the Opus pre-skip: while the timestamps
are shifted by the pre-skip, the granule positions are not shifted.
oggmux is doing the right thing here already.
https://bugzilla.gnome.org/show_bug.cgi?id=757153
The first frame has lookahead less samples, the last frame might have some
padding or we might have to encode another frame of silence to get all our
input into the encoded data.
This is because of a) the lookahead at the beginning of the encoding, which
shifts all data by that amount of samples and b) the padding needed to fill
the very last frame completely.
Ideally we would use LPC to calculate something better than silence for the
padding to make the encoding as smooth as possible.
With this we get exactly the same amount of samples again in an
opusenc ! opusdec pipeline.
https://bugzilla.gnome.org/show_bug.cgi?id=757153
Waylandsink needs exception code in gst_wayland_sink_set_window_handle().
After making sink->window, User can call
gst_wayland_sink_set_window_handle(). It is the user's fault, but
Waylandsink needs to handle the exception, if not then sink->window is
changed and rendering fails.
https://bugzilla.gnome.org/show_bug.cgi?id=747482
Waylandsink needs exception code in gst_wayland_sink_set_context(). After
calling gst_wayland_sink_set_context(), below code is set.
GST_ELEMENT_CLASS (parent_class)->set_context (element, context); but, If
user can call onemore. It is user's fault. but waylandsink need to
exception.
https://bugzilla.gnome.org/show_bug.cgi?id=747482
The stream->cur_seg_template is set to the lowest available segment
template (representation or adaptation or period, in this order).
Because the template elements are inherited, the lowest template will
have all the elements the parents had, so there is no need to check the
parent for an element that is not found in the child (eg initialisation
or index).
https://bugzilla.gnome.org/show_bug.cgi?id=752714
The standard does not seem to make any particular explicit not
implicit reference to the signedness of durations, and the code
does not rely on such, nor on the negativity of the -1 value
that's used as a placeholder when a duration property is not
present in the XML.
https://bugzilla.gnome.org/show_bug.cgi?id=750847
According to the standard:
"SegmentBase, SegmentTemplate and SegmentList shall inherit
attributes and elements from the same element on a higher level.
If the same attribute or element is present on both levels,
the one on the lower level shall take precedence over the one
on the higher level."
gst_mpdparser_parse_segment_list_node will now discard any inherited
segment URLs if the parsed element defines some too.
https://bugzilla.gnome.org/show_bug.cgi?id=751832
Solved with a simple shader templating mechanism and string replacements
of the necessary sampler types/texture accesses and texture coordinate
mangling for rectangular and external-oes textures.
Add the various tokens/strings for the differnet texture types (2D, rect, oes)
Changes the GLmemory api to include the GstGLTextureTarget in all relevant
functions.
Update the relevant caps/templates for 2D only textures.
If MPD@suggestedPresentationDelay is not present in the manifest,
dashdemux selects the fragment closest to the most recently generated
fragment. This causes a playback issue because this choice does not allow
the DASH client to build up any buffer of downloaded fragments without
pausing playback. This is because by definition new fragments appear on
the server in real-time (e.g. if segment duration is 4 seconds, a new
fragment will appear on the server every 4 seconds). If the starting
playback position was n*segmentDuration seconds behind "now", the DASH
client could download up to 'n' fragments faster than realtime before it
reached the point where it needed to wait for fragments to appear on the
server.
The MPD@suggestedPresentationDelay attribute allows a content publisher
to provide a suggested starting position that is behind the current
"live" position.
If the MPD@suggestedPresentationDelay attribute is not present, provide
a suitable default value as a property of the dashdemux element. To
allow the default presentation delay to be specified either using
fragments or seconds, the property is a string that contains a number
and a unit (e.g. "10 seconds", "4 fragments", "2500ms").
Corrected the parsing of a segment template string.
Added unit tests to test the segment template parsing.
All reported problems are now correctly handled.
https://bugzilla.gnome.org/show_bug.cgi?id=751735
When building the media segment list using a SegmentList node, the
gst_mpd_client_setup_representation function will iterate through the
list of S nodes and will expect to find a matching SegmentUrl node. If
one does not exist, the code made an illegal memory access.
https://bugzilla.gnome.org/show_bug.cgi?id=752496
These are used to apply restrictions on what the MPD file may
use, so no profile means no restrictions.
Besides, nothing actually uses the profiles (yet) anyway.
https://bugzilla.gnome.org/show_bug.cgi?id=750869
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
Nicer to read, two lines of code less, and also the callback
function should've been a GCompareFunc that returns a gint
and not a boolean (it did work correctly, was just confusing).
Currently float and int are supported by default. vec2, vec3, vec4
and mat4 are supported if graphene is used. Of course if one wants
to set custom uniforms they can also be set using the create-shader
signal.
We know that the gchar arrays contain at least one string. Furthermore,
g_strfreev() checks if the array is NULL and simply returns if it is.
Hence, there is no need to check if the array is empty before using
g_strfreev().
CID 1327412-1327415
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
One may not have an GstGLContext available or current in the thread where one
would need to update the shader. Support this by signalling create-shader
whenever the one-shot 'update-shader' is set to TRUE.
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.
Allows playlists that are missing the mediasequence information to
be correctly parsed. If the playlist was updated without reseting
the mediasequence it would constantly increase over subsequent updates,
leading to issues during playback.
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)
Change the gstcvdilate.c file extension to cpp and add it into Makefile for
consistency with other elements of opencv and because Opencv not support C
language in new API 2.4.11.
https://bugzilla.gnome.org/show_bug.cgi?id=754148
Change the file extension to cpp and add it into Makefile for consistency
with other elements of opencv and because Opencv not support C language in
new API 2.4.11.
https://bugzilla.gnome.org/show_bug.cgi?id=754148
Change the file extension to cpp and add it into Makefile for consistency
with other elements of opencv and because Opencv not support C language in
new API 2.4.11.
https://bugzilla.gnome.org/show_bug.cgi?id=754148
Change the gstretinex.c file to cpp and add it into Makefile.
It is necessary to migrate the retinex element to C++,
because new Opencv API leaves obsolete functions like cvSmooth.
This element uses this function.
You can see in this link:
http://docs.opencv.org/modules/imgproc/doc/filtering.html?
highlight=cvsmooth#void cvSmooth(const CvArr* src, CvArr* dst,
int smoothtype, int size1, int size2, double sigma1, double sigma2)
https://bugzilla.gnome.org/show_bug.cgi?id=754148
The cascade classifier changes its structure on new version of OpenCV 2.4.11.
It is need to migrate to C++ to utilize the new load method of OpenCV which
allows to load the old and new classifiers.
https://bugzilla.gnome.org/show_bug.cgi?id=752528
Change the gsthanddetect.c file to cpp and add it into Makefile.
It is necessary to migrate the handdetect plugin to C++,
in order to load new and old classifiers, to make handdetect work
with newer versions of Opencv.
https://bugzilla.gnome.org/show_bug.cgi?id=752528
This is mostly a copy/paste of the negotiation function in
basetextoverlay, which was improved recently to handle many more cases.
This will allow us to negotiate a window size with downstream.
https://bugzilla.gnome.org/show_bug.cgi?id=753824
Doing the contrary has no effect and the consequence is that playback
will start with the lowest bitrate even if we can already handle
higher bitrate.
https://bugzilla.gnome.org/show_bug.cgi?id=755108
Not doing this can lead the demuxer to attempt downloading fragments
for an invalid start time. The server would then send a HTTP
Precondition failed error, the demuxer would try some more times to
download the invalid fragment and eventually error out.
https://bugzilla.gnome.org/show_bug.cgi?id=754523
Move the TAG defines directly into the code, not sure what
their purposes is, these are printf format strings so having
them directly as literals in the code where they're used
makes the code easier to follow.
Remove playlist_str GString variable from GstM3U8Playlist struct,
since it's only used temporarily in playlist_render(). Might just
as well keep it local then.
Transform is set to be done in place in gstcvdilateerode.c, so the in-place
transform function is always used and the other is redundant. Removing it.
https://bugzilla.gnome.org/show_bug.cgi?id=753885
Transform is set to be done in place in gstcvdilateerode.c, so the in-place
transform function is always used and the other is redundant. Removing it.
https://bugzilla.gnome.org/show_bug.cgi?id=753885
When running GStreamer from uninstalled sources, the location of the haar
cascade files will be local. Check if running in uninstalled and set the
file paths accordingly.
Move handling of a GstSample in a separate function, and unref the
sample after calling it. libass copies the font data so we don't need to
keep it around.
https://bugzilla.gnome.org/show_bug.cgi?id=755759
Ignore the normal gap threshold for laggy streams and
immediately catch all streams up to the end of the segment
when processing gap updates for a segment during a
still frame sequence.
https://bugzilla.gnome.org/show_bug.cgi?id=755680
Create src pads for Representations that contain timed-text subtitles,
both when the subtitles are encapsulated in ISO BMFF (i.e., the
Representation has mimeType "application/mp4") and when they are
unencapsulated (i.e., the Representation has mimeType
"application/ttml+xml").
https://bugzilla.gnome.org/show_bug.cgi?id=747774
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
gst_uri_join_strings() will return the second parameter if it is an absolute
URI. No need to do a (wrong) check if the URI is absolute or not beforehand.
https://bugzilla.gnome.org/show_bug.cgi?id=755134
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
The spec defines these as signed in 5.3.9.6.1.
Since we don't support this behavior, warn and default to 0
(non repeating), which is the spec's default when the value
is not present.
https://bugzilla.gnome.org/show_bug.cgi?id=752480
Even if it doesn't actually advance the subfragment in the default way
for streams that have subfragments, it can help the base class to return
EOS when there is no more fragments instead of signaling it that it should
continue downloading.
https://bugzilla.gnome.org/show_bug.cgi?id=755042
This reverts commit 626a8f0a74.
This allows us to get the plain presentation offset and the period start time
separately. We have to adjust the timestamp by the presentation offset, but
the period start time should only adjust the stream time and running time.
https://bugzilla.gnome.org/show_bug.cgi?id=752409
This reverts commit e671ad25a9.
The timestamps should restart at 0 again for each period, but we have to
adjust the segment to map those timestamps to the actual stream time and
running time of that period.
Otherwise we would have timestamps that conflict with the ones from the tfdt
inside the MP4 container, which are restarting at 0 for each period.
https://bugzilla.gnome.org/show_bug.cgi?id=752409
In dash isombff profile the fragment is split into subframents where
bitrate switching is possible. Also take that into consideration
when checking if a stream has next fragments.
This GstStreamPeriod start value is expressed in nanoseconds,
and the glib time addition function expects microseconds.
There seems to have been a confusion with GstPeriodNode's start
field, which is expressed in milliseconds.
Additionally, add a warning if the timestamp modification did
not succeed, and NULL was returned.
The cvSmooth cvNot functions and do not have the correct input parameters.
Furthermore, cvSmooth function is not necessary for edge detection,
because the Canny function makes the step of smoothing the image.
And cvNot function is useless because there aren't changes if this
function is eliminated.
https://bugzilla.gnome.org/show_bug.cgi?id=754148
The cascade classifier changes its structure on new version of OpenCV 2.4.11.
It is need to migrate to C++ to utilize the new load method of OpenCV which
allows to load the old and new classifiers.
https://bugzilla.gnome.org/show_bug.cgi?id=753994
For PROP_PROFILE case that exist inside gst_face_blur_set_property
function loads the new XML file in the CvHaarClassifierCascade property
without first checking that it is released because maybe there is an XML
file previously loaded.
https://bugzilla.gnome.org/show_bug.cgi?id=753994
Changes inside the gst_face_blur_load_profile function, the number of
input parameters and in lines where it is used due to it cannot be used
generically.
https://bugzilla.gnome.org/show_bug.cgi?id=753994
Change the gstfaceblur.c file to cpp and add it into Makefile.
It is necessary to migrate the faceblur plugin to C++,
in order to load new and old classifiers, to make faceblur work
with newer versions of Opencv.
https://bugzilla.gnome.org/show_bug.cgi?id=753994
Fix some very dubious code. The class methods should always
be set, and the instance-specific check should then be done
inside the method. For data_received that's there already, for
finish_fragment we need to add it.
https://bugzilla.gnome.org/show_bug.cgi?id=753937
Some live streams (eg youtube) don't remove fragments in order to allow
seeking back in time (live + vod).
When gst_m3u8_client_has_next_fragment is called, we are getting wrong fragment
because current_file points in first file of the fragments list resulting in
watching the stream from the beginning again.
This patch sets current_file to nth fragment for live streams, then on
gst_m3u8_client_has_next_fragment will keep up with the live stream.
https://bugzilla.gnome.org/show_bug.cgi?id=753344
This allow properly copying selected meta, like the composition
overlay. Note that output buffer need to be readable, but GlUpload
keeps a ref. For now, simply drop GlUpload ref after perform,
leaving that ref has no purpose. The method shall be removed
in the future.
https://bugzilla.gnome.org/show_bug.cgi?id=754047
Use base class default method instead of only copying flags and
timestamp. This way, selected meta's like compostion overlay will
be passed downstream as expected.
https://bugzilla.gnome.org/show_bug.cgi?id=754047
During allocation query, when this element is not passthrough, it must
relay the overlay compostion meta and it's parameters. Fortunatly, base
transform can do this for us.
https://bugzilla.gnome.org/show_bug.cgi?id=753850
Previous patch did not handle the case where an encoding (e.g. UTF-8) is
specified in the <xml ?> element. Added an extra test for with and without
encoding.
https://bugzilla.gnome.org/show_bug.cgi?id=753813
When running on an STB, the function
gst_mpdparser_get_xml_node_as_string causes a segmentation fault. This
code works correctly on a Linux desktop.
Looking at the libxml documentation, the xmlNodeDump is deprecated.
Replacing the use of xmlNodeDump with xmlNodeDumpOutput fixes the
segfault on the STB and removes the use of the deprecated function.
Some distributions store OpenCV files in /usr/share/opencv and some others
(and default when building from source) install them in
/usr/share/OpenCV. Support both to find cascade files.
https://bugzilla.gnome.org/show_bug.cgi?id=753651
It is faster than doing a query that propagates downstream and
should be enough
Elements: faac, gsmenc, opusenc, sbcenc, voamrwbenc, adpcmenc, sirenenc
When seeking to the last second of a mpd it would reject the seek
because the comparison was < instead of <=
This fails the important use case of seeking to the end of a file
to play it back in reverse from the end
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.
The urn:mpeg:dash:utc:http-head:2014 method of time synchronisation
uses an HTTP HEAD request to a specified URL and then parses the
Date: HTTP response header.
This commit adds support to dashdemux for this method of time
synchronisation by making a HEAD request and then parsing the Date:
response.
This commit adds support to gstfragment to return the HTTP headers
and to uridownloader to support HEAD requests. To avoid creating a
new API, the RANGE get function is re-used (abused?) with start=-1
and end=-1 to indicate a HEAD request.
https://bugzilla.gnome.org/show_bug.cgi?id=752413
This commit addresses the following items from the code review:
use a portable way to define NTP_TO_UNIX_EPOCH,
fix memory leak on error, and
add documentation to UTCTiming parse functions
Using LL is not portable, so the G_GUINT64_CONSTANT needs to be instead.
If an error occurs during DNS resolution, the GError was not being
released, causing a memory leak.
https://bugzilla.gnome.org/show_bug.cgi?id=752413
Unless the DASH client can compensate for the difference between its
clock and the clock used by the server, the client might request
fragments that either not yet on the server or fragments that have
already been expired from the server. This is an issue because these
requests can propagate all the way back to the origin
ISO/IEC 23009-1:2014/Amd 1 [PDAM1] defines a new UTCTiming element to allow
a DASH client to track the clock used by the server generating the
DASH stream. Multiple UTCTiming elements might be present, to indicate
support for multiple methods of UTC time gathering. Each element can
contain a white space separated list of URLs that can be contacted
to discover the UTC time from the server's perspective.
This commit provides parsing of UTCTiming elements, unit tests of this
parsing and a function to poll a time server. This function
supports the following methods:
urn:mpeg:dash:utc:ntp:2014
urn:mpeg:dash:utc:http-xsdate:2014
urn:mpeg:dash:utc:http-iso:2014
urn:mpeg:dash:utc:http-ntp:2014
The manifest update task is used to poll the clock time server,
to save having to create a new thread.
When choosing the starting fragment number and when waiting for a
fragment to become available, the difference between the server's idea
of UTC and the client's idea of UTC is taken into account. For example,
if the server's time is behind the client's idea of UTC, we wait for
longer before requesting a fragment
[PDAM1]: http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=66068
dashdemux: support NTP time servers in UTCTiming elements
Use the gst_ntp_clock to support the use of an NTP server.
https://bugzilla.gnome.org/show_bug.cgi?id=752413
This reverts commit ff11a1a8a0.
It can't be assumed that all buffers in a buffer list have the same SSRC or
are RTP or RTCP only. It has to be checked for every single buffer, and one
basically has to do the processing that is done by the default chain_list
implementation.
The current code was ignoring the par/dar aspect when transforming
from window coordinates to stream coordinates resulting in incorrect
coordinates being sent upstream in the navigation events.
The payloader didn't copy anything so far, the depayloader copied every
possible meta. Let's make it consistent and just copy all metas without tags or
with only the audio tag.
https://bugzilla.gnome.org/show_bug.cgi?id=751774
Checking the vector is not empty and checking the vector size is greater
than zero are the same thing, this is a redundancy in the code. Only
checking the vector is not empty is sufficient, therefore removing the
other check.
https://bugzilla.gnome.org/show_bug.cgi?id=744763
Add a pivot vector for setting the origin of rotations and scales.
With the pivot point the rotation and scale operations can have
different origins. This adds the ability to rotate around different points.
Currently the default (0, 0) pivot point is possible,
a rotation around the center, and zooming into and out of the center.
With an pivot point this is optional.
I defined the following image coordinates for the pivot point:
(-1,1) ------------------------- (1,1)
| |
| |
| |
| (0,0) |
| |
| |
| |
(-1,-1) ------------------------- (1,-1)
Example:
Rotate the video at the bottom left corner
gst-launch-1.0 videotestsrc \
! gltransformation \
scale-x=0.5 \
scale-y=0.5 \
rotation-z=25.0 \
pivot-x=-1.0 \
pivot-y=-1.0 \
! glimagesink
The pivot-z option defines the pivot point in 3D space.
This only affects rotation, since we have no Z data to scale.
With this option a video can be rotated around a point in 3D space.
Example:
Rotate around point behind the video:
gst-launch-1.0 videotestsrc \
! gltransformation \
rotation-x=10.0 \
pivot-z=-4.0 \
! glimagesink
Since the profile gchar depends on DEFAULT_FACE_PROFILE, it should never be
NULL. Furthermore CascadeClassifier accepts any input, even
an empty one, but if the profile fails to load it returns an empty cascade.
Check for this instead, and inform the user if there was an Error.
The gst_dash_demux_stream_update_fragment_info function could call
gst_dash_demux_stream_update_headers_info function twice. The
gst_dash_demux_stream_update_headers_info function will set header_uri and
index_uri to some newly allocated strings. The values set by the first call of
gst_dash_demux_stream_update_headers_info will leak when the function is
called for a second time.
The solution is to call gst_adaptive_demux_stream_fragment_clear before the
second call of gst_dash_demux_stream_update_headers_info
https://bugzilla.gnome.org/show_bug.cgi?id=753188
Check if profile is NULL before dereferencing it with new. Also, new will
never return NULL; if allocation fails, a std::bad_alloc exception will be
thrown instead. Remove check for a NULL return.
CID #1315258
The ref_object and object parameters were the wrong way around.
For the typical use case where an application is setting a
GstControlBinding on the returned ghost pad:
1. our control binding would be removed when the new one was set
2. sync_values calls were not being forwarded from the internal
pad to the ghost pad.
If an application attempts to perform other control binding
operations (get_* family of functions) on the internal pad, they
will also be forwarded to the ghost pad where a possible
GstControlBinding will provide the necessary values.
Only copy the values from the parent if the current node doesn't
have that value, they were being copied from the parent and
then overwriten by the child node, leaking the parent's copy
With the switch of gstopencv.c to C++, all OpenCV elements are built with
g++. The template variable clashes with C++'s feature of the same name.
Rename template to templ to avoid any clash.
The cascade classifier changes its structure on new version of OpenCV.
The need to migrate to C++ to utilize the new load method of OpenCV which
allows to load the new classifiers.
https://bugzilla.gnome.org/show_bug.cgi?id=748377
This is used to proxy GstControlBinding to the pad on the
parent object. This avoid having to sync the values in the proxy pad,
this is too early if you have a queue between the pad and the actual
aggregation operation.
https://bugzilla.gnome.org/show_bug.cgi?id=734060
When the sink does not know the window size (e.g not created yet)
it will not add any param to the the composition meta. This is no
reason not to forward this meta API. Fixes issue where it could not
attach until we resize the window.
https://bugzilla.gnome.org/show_bug.cgi?id=745107
The coordinate are relative to the texture dimension and not
the window dimension now. There is no need to pass the window
dimension or to update the overlay if the dimension changes.
https://bugzilla.gnome.org/show_bug.cgi?id=745107
Adds an GST_VIDEO_OVERLAY_COMPOSITION_META_API_TYPE query to glupload
and glimagesink. Detects the query from the downstream elements, so
it is executed only when downstream supports the overlay API.
This makes pipelines with textoverlay ! glupload ! gldownload ! xvimagesink possible.
Uses allocation meta struct for passing the window size upstream.
https://bugzilla.gnome.org/show_bug.cgi?id=745107
Previously, PLC frames always had a length of 120ms, which caused audio
quality degradation and synchronization errors. Fix this by calculating an
appropriate length for the PLC frame.
The length must be a multiple of 2.5ms. Calculate a multiple of 2.5ms that
is nearest to the current PLC length. Any leftover PLC length that didn't
make it into this frame is accumulated for the next PLC frame.
https://bugzilla.gnome.org/show_bug.cgi?id=725167
If a ContentProtection element is present in an AdaptationSet element,
send Protection events on the source pad, so that qtdemux can use this
information to correctly generate its source caps for DASH CENC
encrypted streams.
This allows qtdemux to support CENC encrypted DASH streams where the
content protection specific information is carried in the MPD file
rather than in pssh boxes in the initialisation segments.
This commit adds a new function to the adaptivedemux base class to allow
a GstEvent to be queued for a stream. The queue of events are sent the
next time a buffer is pushed for that stream.
https://bugzilla.gnome.org/show_bug.cgi?id=705991
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
I notice that if you stop the pipeline during a renegotiation
the upload may be NULL while an allocation query is being run.
In that scenario, returning FALSE to the allocation query is the
best thing.
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
Moved gst_mpd_client_get_next_segment_availability_end_time and
gst_mpd_client_add_time_difference functions to be grouped with
functions from the same category.
https://bugzilla.gnome.org/show_bug.cgi?id=752027
Corrected the initialisation of mimeType in
gst_mpdparser_get_list_and_nb_of_audio_language: the variable is used
in a loop, so it must be set to NULL at the beginning of each iteration.
https://bugzilla.gnome.org/show_bug.cgi?id=751911
Before returning the next fragment duration value, the
gst_mpd_client_get_next_fragment_duration function tries to validate it.
But the condition was incorrect.
https://bugzilla.gnome.org/show_bug.cgi?id=751539
We're interested in the offset between the period start timestamp and the
actual media timestamp so that we can properly correct for it. The absolute
presentation offset to timestamp 0 is useless as the only thing we really
care about is the offset between the current fragment timestamp and the
media timestamp.
Otherwise we will look for segments after the period usually. The seek
timestamp is relative to the start of the first period and we have to
select a segment relative to the current period's start.
We didn't do this for fragments that are generated on demand from a template,
only for the other cases when they were all generated upfront. This caused
fragment timestamps to start from 0 again for each new period.
If not set, the timeShiftBufferDepth has a default value of -1.
The standard says that this should be interpreted as infinite.
The gst_mpd_client_check_time_position function incorrectly compares
timeShiftBufferDepth with 0 instead of -1 to determine if it was set.
https://bugzilla.gnome.org/show_bug.cgi?id=751500
The last parameter of gst_mpd_client_add_media_segment function is a
duration. But when called from gst_mpd_client_setup_representation, the
last argument was wrongly set to PeriodEnd
https://bugzilla.gnome.org/show_bug.cgi?id=751449
The period start information, calculated in gst_mpd_client_setup_media_presentation
function is stored in stream_period->start. The information read from
xml file and stored in stream_period->period->start is not changed.
If the xml file does not contain the period start information,
stream_period->period->start will be -1.
The function gst_mpd_client_get_next_segment_availability_end_time wants to
use period start time, but incorrectly uses stream_period->period->start
(value from xml file, which could be -1) instead of stream_period->start
(computed value)
https://bugzilla.gnome.org/show_bug.cgi?id=751465
According to ISO/IEC 23009-1:2014(E), chapter 5.3.2.1
"The Period extends until the PeriodStart of the next Period, or until
the end of the Media Presentation in the case of the last Period."
This means that a configured value for optional attribute period duration
should be ignored if the next period contains a start attribute or it is
the last period and the MPD contains a mediaPresentationDuration attribute.
https://bugzilla.gnome.org/show_bug.cgi?id=750797
Support video with multiview info in the caps, transform
it to mono anaglyph by default, but allow for configuring
other output modes and handoff to the app via
the draw signal.
https://bugzilla.gnome.org/show_bug.cgi?id=611157
Added some warning messages in gst_mpd_client_setup_streaming to help
debug situations when the function will return FALSE.
Renamed a wrongly spelled variable.
https://bugzilla.gnome.org/show_bug.cgi?id=751149
Corrected some comments in gstmpdparser.h file.
Moved gst_mpd_client_get_adaptation_sets function to be grouped with
other functions from AdaptationSet group
https://bugzilla.gnome.org/show_bug.cgi?id=751149
The gst_mpdparser_get_rep_idx_with_max_bandwidth function assumes
representations are ordered by bandwidth and incorrectly returns the
first one when wanting the one with minimum bandwidth.
Corrected gst_mpdparser_get_rep_idx_with_max_bandwidth function to get the
correct representation in case max_bandwidth parameter is 0.
https://bugzilla.gnome.org/show_bug.cgi?id=751153
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.
We now know that pool caching can cause renegotiation issues
when an element in the pipeline change from passthrough to not
passthrough. As it's not needed, don't cache existing pools.
https://bugzilla.gnome.org/show_bug.cgi?id=748344
Added a check for a_node->ns before accessing a_node->ns->href in
gst_mpdparser_get_xml_node_namespace. This could happen if the xml
is missing the default namespace.
https://bugzilla.gnome.org/show_bug.cgi?id=750866
If the presentationTimeOffset attribute of a DASH manifest contains
a value that is larger than 2^32, gstmpdparser incorrectly calculates
the stream's presentation time offset. This is due to two bugs:
1: Using gst_mpdparser_get_xml_prop_unsigned_integer rather than
gst_mpdparser_get_xml_prop_unsigned_integer_64 to parse the
attribute
2: gst_mpd_client_setup_representation multiplying the value by
GST_SECOND and then dividing by timescale
https://bugzilla.gnome.org/show_bug.cgi?id=750804
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).
This reverts commit 4ca3a22b6b.
The connection-speed=0 is used as a special value in the property
of hlsdemux to mean 'automatic' selection, m3u8.c doesn't need
to know about that as it should be as simple as possible.
So this patch hides this automatic selection documented in hlsdemux
into m3u8 logic and I think the gets harder to understand the code.
It also makes the hlsdemux unit tests work again
https://bugzilla.gnome.org/show_bug.cgi?id=749328
This reverts commit 37011e5198.
This change was actually completely unnecessary, the streams in question are
marked as static and are not considered live anyway.
Otherwise we'll only get half of its bits printed on 32 bit architectures.
For this, promote the %d-style format strings to something that accepts
64 bit integers with G_GINT64_MODIFIER.
Using format strings from an untrusted source without validation is
calling for problems, and at least allows to remotely crash your application.
If not worse.
In live situations, it is not uncommon for the current fragment to end
up out of the (updated) play range (lowest/highest sequence). But the next
fragment to play *is* present in the play range.
When advancing, if we can't find the current GstM3U8MediaFile, don't abort
straight away. Instead, look if a GstM3U8MediaFile with the next sequence value
is present, and if so switch to it.
https://bugzilla.gnome.org/show_bug.cgi?id=750028
Previously when compiling GstGL with both GL and GLES2,
GL_RGBA8 was picked from GL/gl.h. But a clash may happen at
runtime when one is selecting GLES2.
gst_gl_internal_format_rgba allows to check at runtime
if it should use GL_RGBA or GL_RGBA8.
The functions to get the next fragment, next fragment timestamp and to advance
to the next fragment need to work differently when stream->segments is NULL.
Use logic similar to that introduced by commit 2105a310 to perform these
functions.
https://bugzilla.gnome.org/show_bug.cgi?id=749684
Previously the VPS unit was detected and all next packets where copied
into the header buffer assuming only SPS and PPS would follow. This is
not always true, also other types of NAL units follow the VPS unit and
where copied to the header buffer. Now the VPS/SPS/PPS are explicitely
detected and copied in the header buffer.
1. Set the sync point after the (possible) upload has occured
2. Wait in the correct GL context (the draw context)
Note: We don't add the GL sync meta to the input buffer as it's not
writable and a copy would be expensive.
Similar to the change with the same name for glimagesink
1. Set the sync point after the (possible) upload has occured
2. Wait in the correct GL context (the draw context)
Note: We don't add the GL sync meta to the input buffer as it's not
writable and a copy would be expensive.
The property level has a minimum value of 0. But when we set the level as 0,
it gets an assertion error. The function icvPyrSegmentation8uC3R returns false
if level is set as 0, since the minimum level cant be 0 and thus results in error.
Hence changing the minimum value to 1.
https://bugzilla.gnome.org/show_bug.cgi?id=749525
When all fragments have already been downloaded on a live stream
dashdemux would busy loop as the default implementation of
has_next_fragment would return TRUE. Implement it to correctly
signal if adaptivedemux should wait for the manifest update before
trying to get new fragments.
When updating the manifest the timestamps on it might have changed a little
due to rounding and timescale conversions. If the change makes the timestamp
of the current segment to go up it makes dashdemux reposition to the previous
one causing one extra unnecessary download.
So when repositioning add an extra 10 microseconds to cover for that rounding
issues and increase the chance of falling in the same segment.
Additionally, also improve the time used when the client is already after the
last segment. Instead of using the last segment starting timestamp use the
final timestamp to make it reposition to the next one and not to the one that
has already been downloaded.
These functions of directly getting and setting segment indexes
are no longer useful as now we need 2 indexes: repeat and segment
index.
The only operations needed are advance_segment, going back to the
first one or seeking for a timestamp.
Segments are now stored with their repeat counts instead of spanding
them to multiple segments. This caused advancing to the next segment
using a single index to have to iterate over the whole list every time.
This commit addresses this by storing both the segment index as well
as the repeat index and makes advancing to next segment just an
increment of the repeat or the segment index.
Use a single segment to represent it internally to avoid using too
much memory. This has the drawback of issuing a linear search to
find the correct segment to play but this can be fixed by using
binary searches or caching the current position and just looking
for the next one.
https://bugzilla.gnome.org/show_bug.cgi?id=748369
The custom code is wrong as it ignores the templates, which leads to
missing fields in the result. Instead, simply use the default get_caps
implementation which does it correctly (get the template, intersect
with filter and return).
https://bugzilla.gnome.org/show_bug.cgi?id=749237
Without this, we will fixate weird pixel-aspect-ratios like 1/2147483647. But
in the end, all the negotiation code in videoaggregator needs a big cleanup
and videoaggregator needs to get rid of the software-mixer specific things
everywhere.
Upstream might not give us a caps event (dtlssrtpdec) because it might be an
RTP/RTCP mixed stream, but we split the two streams anyway and should report
proper caps downstream if possible.
Fixes "sticky event misordering" warnings with dtlssrtpdec.
And provide home-made fallback for older GLib versions,
so that we can later find these and remove them when
we bump the GLib requirement (which is certainly going
to happen before 2.0).
https://bugzilla.gnome.org/show_bug.cgi?id=748495
It's better to just select some random variant playlist instead of stopping,
chances are that it's still continuing to work and we might just have to
select a different variant again later.
We should only refresh the currently selected variant playlist (if any,
otherwise the main playlist), not the main playlist. And only try to
refresh the main playlist if updating the variant playlist fails.
Some servers (Wowza) use the request of the main playlist to create a
"session", which is then part of the URI of the variant playlist and
also the fragments. Refreshing the main playlist would generate a new
session, and the server rate limits that usually. And after a few retries
the server just kicks us out.
Also as a side effect we now use the same downloader for all playlists, so
that we only have 2 instead of 3 connections to the server. And also
previously we just ignored the downloaded data from the main playlist that
the base class gave to us.
When the segment is very short it might be the case that the
typefinding fails and when finishing the segment hlsdemux would
consider the remaining data (pending_buffer) as an encryption
leftover.
This patch fixes it and makes sure an error is properly posted
if typefind failed by refactoring buffer handling to a function
and using it from the data_received and finish_fragment functions.
We also have to update the current_file GList pointer in the M3U playlist
client, otherwise we are just continuing playback from the current position
instead of seeking.
Variable hands is already checked to contain a value previously at the beginning
of the current block. There is no need to check again. This is logically dead code.
CID 1197693
Caps refcounting was all wrong in this function. Rewrote it and add some
comments to make it clearer.
Fix caps leaks with the
validate.file.glvideomixer.simple.play_15s.synchronized scenario.
https://bugzilla.gnome.org/show_bug.cgi?id=747915
Signed-off-by: Guillaume Desmottes <guillaume.desmottes@collabora.co.uk>
If old opencv1-style legacy include directory is available,
this change becomes purely cosmetic (maybe will compile a bit faster).
It becomes an FTBFS fix when opencv1-style include directory is missing
(possibly because opencv package maintainer decided not to pack it).
https://bugzilla.gnome.org/show_bug.cgi?id=747705
Fix a caps leak with the
validate.file.glvideomixer.simple.play_15s.synchronized scenario.
https://bugzilla.gnome.org/show_bug.cgi?id=747915
Signed-off-by: Guillaume Desmottes <guillaume.desmottes@collabora.co.uk>
'array_buffers' contain borrowed GstBuffer and so shouldn't have a free
function. 'frames' is the one containing GstGLMixerFrameData and so should use
_free_glmixer_frame_data as free function.
Fix GstGLMixerFrameData leaks with the
validate.file.glvideomixer.simple.play_15s.synchronized scenario.
https://bugzilla.gnome.org/show_bug.cgi?id=747913
Signed-off-by: Guillaume Desmottes <guillaume.desmottes@collabora.co.uk>
Fix a simple buffer overflow - 16 bytes isn't enough to hold
the string representation of a gulong on x86_64. I guess the
intent was to generate a 32 bit random key, so let's do that.
Only matters if anyone ever ports the sink to 1.x
https://bugzilla.gnome.org/show_bug.cgi?id=676524
There is a playback error when trying to play a content that
has 'application' mimeType. This commit prevents an exception from
setup text streams.
https://bugzilla.gnome.org/show_bug.cgi?id=747525
As mentionned in release notes : Added new Sps/Pps strategies for real-time
video (replace the old setting variable 'bEnableSpsPpsIdAddition' with
'eSpsPpsIdStrategy')
upstream might send buffer lists instead of buffers and hlssink's
probe won't get called and a new segment won't be created when needed.
This patch fixes it by adding a chain_list function to the sink pad
that will just pass through the whole bufferlist if no segment needs
to be requested at the moment or convert the list into buffers to
check the proper timestamp to request the next key-unit that will
start the segment.
https://bugzilla.gnome.org/show_bug.cgi?id=746906
This way we let opusdec do the resampling if needed and don't carry
around buffers with a too high sample rate if not required.
While Opus always uses 48kHz internally, this information from the
header specifies which frequencies are safe to drop.
No need to ref/unref the connection every time we push something on the pool.
However we have to provide non-NULL data to the pool, so let's just give it
some coffee.
This way we will share threads with other DTLS connections if possible, and
don't have to start/stop threads for timeouts if there are many to be handled
in a short period of time.
Also use the system clock and async waiting on it for scheduling the timeouts.
GST_DTLS_USE_GST_LOG is not defined anywhere, so
we'd just log into the default category by accident.
We use the gst logging system unconditionally now,
so might just as well remove this #if #else.
gcc-4.9.2:
gstdtlsagent.c:114:1: error: old-style function definition
gstdtlsconnection.c:253:3: error: ISO C90 forbids mixed declarations and code
gstdtlsconnection.c:291:3: error: ISO C90 forbids mixed declarations and code
gstdtlsconnection.c:391:3: error: ISO C90 forbids mixed declarations and code
gstdtlsconnection.c:434:3: error: ISO C90 forbids mixed declarations and code
gstdtlsconnection.c:773:1: error: 'BIO_s_gst_dtls_connection' was used with no prototype before its definition
gstdtlsconnection.c:773:1: error: old-style function definition
gstdtlsconnection.c:128:32: error: passing 'const char [30]' to parameter of type 'void *'
discards qualifiers [-Werror,-Wincompatible-pointer-types-discards-qualifiers]
SSL_get_ex_new_index (0, "gstdtlsagent connection index", NULL, NULL,
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/usr/include/openssl/ssl.h:1981:43: note: passing argument to parameter 'argp' here
int SSL_get_ex_new_index(long argl, void *argp, CRYPTO_EX_new *new_func,
^
gstdtlsconnection.c:822:40: error: arithmetic on a pointer to void is a GNU extension
[-Werror,-Wpointer-arith]
memcpy (out_buffer, priv->bio_buffer + priv->bio_buffer_offset, copy_size);
~~~~~~~~~~~~~~~~ ^
In some upload implementations the out buffer has more than one references,
turning the buffer not writable, so it won't be possible to modify its
meta-data.
This patch moves the meta-data copy before increasing the reference of the out
buffer.
https://bugzilla.gnome.org/show_bug.cgi?id=746173
glupload ! glcolorconvert ! sink
Some properties are manually forwarded. The rest are available using
GstChildProxy.
The two signals are forwarded as well.
It encapsulates a confiurable GL processing element in the
upload/colorconvert/download dance required to transparently process
the majority of GstBuffer's.
GLImage does not use any kind of internal pool. There was some
remaining code and comment stating that it was managing the
pool, and it was in fact setting the active state when doing
to ready state.
* Only create the pool if requested and in propose_allocation
* Cache the pool to avoid reallocation on spurious reconfigure
* Don't try to deactivate the pool (we don't own it)
https://bugzilla.gnome.org/show_bug.cgi?id=745705
If searchIdx() doesn't find the id it returns -1, which breaks
motioncelssvector.at (idx). Check for it and return if not found.
Changing a few other lines for style consistency.
The max latency parameter is "the maximum time an element
synchronizing to the clock is allowed to wait for receiving all
data for the current running time" (docs/design/part-latency.txt).
https://bugzilla.gnome.org/show_bug.cgi?id=744338
LibJPEG uses macroblock of 8x8 sample. In this element we use RGB and
Y444, two 24bit formats that are stored in 32bit pixels. This mean we
have 32x32 bytes macroblocks. For this reason, we need to allocate
our buffer slightly larger. We also need to pass the line pointer in
the right order, otherwise the image endup upside-down.
https://bugzilla.gnome.org/show_bug.cgi?id=745109
Using mkstemp without setting the permission mask is potentially harmful.
POSIX specification of mkstemp() does not say anything about file modes, so we
need to make sure its file mode creation mask is set appropriately before
calling it.
This implements support for GstAllocationParams and memory alignments.
The parameters where simply ignored which could lead to crash on
certain platform when used with libav and no luck.
https://bugzilla.gnome.org/show_bug.cgi?id=744246
+ Split headers from source
+ Remove uneeded AM_CFLAGS, AM_LDFLAGS
+ Always set OBJCFLAGS
Due to the presence of a .m and regardless of the conditional values,
automake will promote the link command to OBJC using OBJCFLAGS. Only
the basic flags (like warnings and optimization) are going to make a
difference though.
This cleanup builds up the makefile with less specific files first
toward more specific file. FLAGS are built with the basic that unused
flags will have empty variable.
i686-apple-darwin11-llvm-gcc-4.2
gstglmixer.h:43: error: redefinition of typedef ‘GstGLMixer’
gstglmixerpad.h:32: error: previous declaration of ‘GstGLMixer’ was here
gstglmixer.h:46: error: redefinition of typedef ‘GstGLMixerFrameData’
gstglmixerpad.h:33: error: previous declaration of ‘GstGLMixerFrameData’ was here
The graphene-1.0 part should not be in the source code. This directory
is part of the cflags include. This is similar to gstreamer-1.0/
directory. This break compilation if the include directory where
graphene is installed is not in your include path.
Bitrate-limit is already available in the baseclass and, even though
the bandwidth-usage name is better, hls and mss already used
bitrate-limit. This patch deprecates the bandwidth-usage and maps
it to the baseclass bitrate-limite.
Move the property from subclasses to adaptivedemux, it allows
selecing the percentage of the measured bitrate to be used when
selecting stream bitrates
Allow the playlist-length to accept '0' as a value, indicating
that no segment should be removed from the playlist. This allows
generating playlists to be used as VOD when complete.
Allows to set a bitrate directly instead of measuring it internally
based on the received chunks. The connection-speed was removed from
mssdemux and hlsdemux as it is now in the base class
By implementing get_live_seek_range.
As shown by :
gst-validate-1.0 playbin \
uri=http://dev-iplatforms.kw.bbc.co.uk/dash/news24-avc3/news24.php
This patch handles live seeking, by setting a live seek range
comprised between now - timeShiftBufferDepth and now.
The inteersting thing with this stream is that one can actually
ask fragments up to availabilityStartTime, but it seems quite clear
in the spec that content is only guaranteed to exist up to
timeShiftBufferDepth.
One can test live seeking this way :
gst-validate-1.0 playbin \
uri=http://dev-iplatforms.kw.bbc.co.uk/dash/news24-avc3/news24.php \
--set-scenario seek_back.scenario
with scenario being:
description, seek=true
seek, playback-time=position+5.0, start="position-600.0",
flags=accurate+flush
This example will play the stream, wait for five seconds, then seek back
to a position 10 minutes earlier.
https://bugzilla.gnome.org/show_bug.cgi?id=744362
Add parsed/framed=true to allow negotiation with some
muxers that required parsed input. Encoders already provide
parsed/framed output so it should say so in caps.
Some variables are not initialized in the constructor. It is highly unlikely
they are used before being set, but it is safer to initialize them.
CID #1197704
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.
