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
