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
- The shader was outputing the wrong values compared with raw
videotestsrc.
- deal with the texture edge properly.
- properly sample the 2x1 rectangle for the u and v values
- don't double sample the y value
The previous implementation kept accumulating GSources,
slowing down the iteration and leaking memory.
Instead of trying to fix the main context flushing, replace
it with a GAsyncQueue which is simple to flush and has
less overhead.
https://bugzilla.gnome.org/show_bug.cgi?id=736782
The aggregator.segment is not to be initialized by the subclasses but
by the aggregator itself. Moreover, initializing it on start would make
us loose the information coming from the initial seek.
Without a lock that is taken in FLUSH_START we had a rare race where we
end up aggregating a buffer that was before the whole FLUSH_START/STOP
dance. That could lead to very wrong behaviour in subclasses.
GST_BASE_PARSE_FRAME_FLAG_PARSING value is wrong, and the same flag is
not being used presently. Hence changing the value and commenting it out.
This needs to be included in baseparse.h later on
https://bugzilla.gnome.org/show_bug.cgi?id=737411
Previously known as DMB-T/H, this is the
terrestial DTV broadcast standard currently
used by the People's Republic of China,
Hong Kong, Laos and Macau (officially),
and by Malaysia, Iraq, Jordan, Syria and
Lebanon (experimentally).
These apply to ISDB-T, DVB-T2 and DTMB
Order of the enum values (new rates after _AUTO)
has been kept congruent with the one in the v4l
API for consistency.
According to the v4l-dvb API docs, these are only
used for DVB-T2 at the moment.
Order of the enum values (new rates after _AUTO)
has been kept congruent with the one in the v4l
API for consistency.
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.
