gst_gl_context_finalize() is calling gst_gl_window_win32_quit()
which was posting a message. But then window_proc takes window's
context and get a NULL.
Now that we've got a GMainLoop we can do like other backends and
simply call g_main_loop_quit().
This also remove duplicated code to release the parent window and
potential crash there because parent_proc could be NULL if we never
created the internal window. That could happen for example if setting
state to READY then setting a window_handle, and go back to NULL state.
https://bugzilla.gnome.org/show_bug.cgi?id=749601
gst_gl_window_win32_send_message_async() could be called before the
internal window is created so we cannot use PostMessage there.
x11 and wayland backends both create a custom GSource for this,
so there is no reason to not do that for win32.
https://bugzilla.gnome.org/show_bug.cgi?id=749601
Like SPS/PPS they do contain information which will be needed to
decode the following data (as per definition of the flag)
Also ensures that the series of SPS/PPS/SEI NALU before a keyframe
can be considered as one contiguous header
In the same way we do it for the DELTA_UNIT flag
This allows downstream elements to know whether a given mpeg-ts
packet contains a corresponding HEADER elementary unit
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.
Otherwise it could stay client side without being submitted to the GL
server resulting in another context waiting on a Fence that will never
become signalled causing a deadlock.
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
Timestamps should start at the segment start, rather than 0, so
we need to not subtract the first timestamp. This makes the sink
correctly account for running time when switching PMTs where a
stream starts not quite at zero, causing timing offsets that can
become noticeable and causing dropped frames after a few times.
A new program object is created to replace an existing one
in the programs hash table, so its refcount needs to match.
With the default of 0 refcount on creation, the next PAT
change will cause that refcount to be both incremented and
decremented (assuming the new PAT references that stream too),
which will cause the program to be destroyed.
https://bugzilla.gnome.org/show_bug.cgi?id=748412
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.
