When working in push mode, we need to be able to evaluate the duration
based on a single group of observations.
To do that we use the current group values
When handling the PTS/DTS conversion in new groups, there's a possibility
that the PTS might be smaller than the first PCR value observed, due to
re-ordering.
When using the current group, only apply the wraparound correction when we
are certain it is one (i.e. differs by more than a second) and not when it's
just a small difference (like out-of-order PTS).
https://bugzilla.gnome.org/show_bug.cgi?id=731088
When we receive sticky events from upstream, always return TRUE.
Fixes the issue where we receive custom sticky events (such as "uri")
and no pads are created yet.
This can happen if the playlists have moved due to the variant playlist
now being redirected to another target. This currently only works as long
as the referenced playlists don't change in relation to the variant
playlist, and the new location is purely due to a new path triggered by a
new redirection target of the variant playlist, or a new redirection
target of the playlist itself.
https://bugzilla.gnome.org/show_bug.cgi?id=731164
New approach attempts to be more accurate by measuring
the elapsed time by iteration. Also:
* Use a 10 seconds default timeout and a half a second
polling step. New values should better match the tuning
process on real-life scenarios.
* Correct elapsed_time computation.
* Add _retry_ioctl() to avoid bailing out on temporary
ioctl EINTR failures (no need to check for EAGAIN cause
we are opening the frontend on blocking mode)
* Small corrections to fail condition handling
Currently, GstGLWindowWaylandEGL holds the wayland display connection
If we create the EGLDisplay at the GstDisplay creation time, then
libEGL will internally open another connection to the wayland server.
These two display connections are unable to communicate resulting in
no window output/display and hangs inside libEGL.
Eventually we will move the wl_display from GstGLWindow to GstGLDisplay.
Since all the other timestamp tracking now gets reset on a discont,
it makes sense to wait for a PCR and timestamp buffers like when
playback first starts
We add a new signal, get-rollover-counter, to the SRTP encoder. Given a
ssrc the signal will return the currently internal SRTP rollover counter
for the given stream.
For the SRTP decoder we have a new SRTP caps parameter "roc" that needs
to be set when a new SRTP stream is created for a given SSRC.
https://bugzilla.gnome.org/show_bug.cgi?id=726861
Fixes the case where _perform_with_buffer() is called without
intervening calls to _release_buffer() as is the case on start up
with glimagesink.
Also release the buffer when reseting the upload.
https://bugzilla.gnome.org/show_bug.cgi?id=731107
Check if libnativehelper is loaded in the process and if
it has these awful wrappers for JNI_CreateJavaVM and
JNI_GetCreatedJavaVMs that crash the app if you don't
create a JniInvocation instance first. If it isn't we
just fail here and don't initialize anything.
See this code for reference:
https://android.googlesource.com/platform/libnativehelper/+/master/JniInvocation.cpp
(same as 744c58d71b but for the
position query)
It was only querying in time, but then trying to use dead bytes
to time conversion code.
Coverity 1139677
(Identical to commit 612cdeec80 which
was for resindvd)
When we'd see an unknown stream type, then a SDDS stream.
Then we'd get to the end of the switch with a NULL temp stream
pointer, and dereference it.
Coverity 1139708
* Drop remaining sleep() logic in favor of polling
* Use best guess delivery system if none is set
* Make tuning/locking timeout configurable
* Add signals for tuning start, done and fail
* Drop gst_dvbsrc_frontend_status(). It was used only
for signal LOCK checking. This is now part of the
tuning/locking loop
* Break up frontend configuration and tuning
on separate functions
Plus:
* Add some more useful DEBUG/TRACE messages
* Move over misplaced DVB API message
* Fix wrong comment for default DVB buffer size (http://linuxtv.org/downloads/v4l-dvb-apis/dmx_fcalls.html#DMX_SET_BUFFER_SIZE)
This patch builds up on previous work done by
Fabrizio (Misto) Milo <mistobaan@gmail.com>
https://bugzilla.gnome.org/show_bug.cgi?id=641204
On Samsung Galaxy S4 it is impossible to have more than one
hardware decoder at the same time. If we do not release it
explicitly the GC only releases it whenever the whole application
is finished not whenever the activity is finished and thus a player
will not be able to work correctly
