When the frame buffer is AYUV writing all zeros does not set it to
black, in YUV colorspace 0x10 is the black level for luminance and 0x80
is the black level for chrominance.
Fix setting the background to black when the out_frame format is AYUV;
in all the other supported formats zeroing the data with memset is still
the right thing to do.
https://bugzilla.gnome.org/show_bug.cgi?id=710392
Flushing the decoder invalidates all buffers, so it should be done
after quiting the decoding loop. Otherwise we can jump into
"failed_release" and stop everything
https://bugzilla.gnome.org/show_bug.cgi?id=711156
the initial par_n = par_d = 0; was always overwritten since the switch/case
handles all values
And remove the 0 case (it's the same handling as default)
This patch fixes three memory leaks in hlsdemux, one that occurs
during normal operation and two that occur during error conditions.
The gst_hls_demux_get_next_fragment function calls
gst_fragment_get_buffer which increments the reference count
on the buffer but gst_hls_demux_get_next_fragment never calls unref on
the buffer. This means that the reference count for each downloaded
fragment never gets to zero and so its memory is never released.
This patch adds a call to gst_buffer_unref after the flags have been
updated on the buffer.
There is a leak-on-error in gst_hls_demux_decrypt_fragment if it fails
to download the key file. If the key fails to download, null is
returned without doing an unref on the encrypted fragment. The
semantics of gst_hls_demux_decrypt_fragment is that it takes ownership
of the encrypted fragment and releases it before returning.
There is a leak-on-error in gst_hls_src_buf_to_utf8_playlist in the
unlikely event that the gst_buffer_map fails. In the "happy path"
operation of gst_hls_src_buf_to_utf8_playlist the buffer gets an unref
before the function returns, therefore the error condition must do the
same.
https://bugzilla.gnome.org/show_bug.cgi?id=710881
Fixed up the error-handling code when downloading fragments.
Modifed the error-handling code to use positive logic when
testing for cancellation of the download loop.
https://bugzilla.gnome.org/show_bug.cgi?id=701404
There is an issue for live streams where download_loop will keep
downloading segments until it gets a 404 error for a segment
that has not yet been published. This is a problem because this
request for a segment that doesn't exist will propagate all the
way back to the origin server(s). This means that dashdemux causes
extra load on the origin server(s) for segments that aren't yet
available.
This patch uses availabilityStartTime, period
and the host's idea of UTC to decide if a fragment is available to
be requested from an HTTP server and filter out requests for fragments
that are not yet available.
https://bugzilla.gnome.org/show_bug.cgi?id=701404
liveadder sometimes calculates the offsets incorrectly before adding. The
resulting errors can easily be heard when mixing silence with a sine.
I'm not sure what the exact conditions are to trigger this, but it definitively
happens when the buffers of two streams have a different duration and buffer
length and duration don't match exactly for one stream because of rounding
errors (e.g. duration=0:00:00.021333333)
I have to admit, I got lost in the math somewhere but it seems that not
rounding in gst_live_adder_length_from_duration() causes 1 sample overlaps in
consecutive buffers from the same stream.
When using gst_util_uint64_scale_int_round() instead of just truncating the
sine sound correctly again.
https://bugzilla.gnome.org/show_bug.cgi?id=708345
