Otherwise we end up considering the values did not change and we wrongly
work with the old video format (which will lead to wrong
behaviour/segfaults).
https://bugzilla.gnome.org/show_bug.cgi?id=755621
eceb2ccc73 broke segment seeks by always
accumulating segments manually when activating a segment. This is only
needed when handling edit lists, not when activating a segment because of a
seek. Do the accumulation when switching edit list segments instead.
This fixes segment seeks again, while keeping edit lists playback working.
https://bugzilla.gnome.org/show_bug.cgi?id=755471
* use g_list_free_full(), don't iterate elements maually when freeing
* call gst_rtp_*_pay_clear_packet(), don't duplicate its code
* use gst_buffer_unref() to clarify that it is buffers being released,
instead of refering directly to gst_mini_object_unref()
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=755277
It's normal when dropping into the middle of a stream to
not always have the config available immediately, so skip LOAS
until a valid config is seen without either setting invalid
caps or erroring out.
https://bugzilla.gnome.org/show_bug.cgi?id=751386
flac contains the sample offset in the frame header, so after a seek
without index flacparse will know the exact position we landed on and
timestamp buffers accordingly. It only set the pts though, which means
the baseparse-set dts which was set to the seek position prevails, and
since the seek was based on an estimate, there's likely a discrepancy
between where we wanted to land and where we did land, so from here on
that dts/pts difference will be maintained, with dts possibly multiple
seconds ahead of pts, which is just wrong. The easiest way to fix this
is to just set both pts and dts based on the sample offset, but perhaps
parsed audio should just not have dts set at all.
https://bugzilla.gnome.org/show_bug.cgi?id=752106
One-line removal of tags_written++
This should fix rtmp output to crtmpserver, and hopefully
noone is expecting that the element count includes the end
element, as different bits of documentation say different
things about whether it should or not.
https://bugzilla.gnome.org/show_bug.cgi?id=661624
Apparently the Microsoft Azure RTMP server requires that the
videodatarate and audiodatarate metadata be provided, so
set those, even if it's to 0. Use the actual input bitrate
tags if available.
In parse_keymgmt(), don't mutate the input string that's been passed
as const, especially since we might need the original value again if
the same key info applies to multiple streams (RTX, for example).
When a resource is 404, and we have auth info - retry with the auth
info the same as if we had receive unauthorised, in case the resource
isn't even visible until credentials are supplied.
Fix a memory leak handling Mikey data.
When generating a random keystring, don't overrun the 30 byte
buffer by generating 32 bytes into it.
The time of the first RTCP packet is semi-random, so
sometimes it was produced before enough packets from
the second SSRC were received. First drop queued RTCP
packets, then advance the clock enough to ensure
that at least one new RTCP packet is produced.
https://bugzilla.gnome.org/show_bug.cgi?id=750731
In gst_smpte_collected(), check upfront if input formats are same
or not. This avoids allocation of in1 and in2 buffers and
subsequent memory leak when input formats do not match.
https://bugzilla.gnome.org/show_bug.cgi?id=754153
When passing the taglist to gst_audio_decoder_merge_tags, the reference is increased
by audiodecoder and the caller should free the taglist being passed.
https://bugzilla.gnome.org/show_bug.cgi?id=753903
When we haven't started yet, set the start_index when we set the index property,
so that we start at the right index position after the initial seek. The index
property was never really meant to be for writing, but it used to work, so let's
support it for backwards compatibility.
https://bugzilla.gnome.org/show_bug.cgi?id=739472
Commit 7d7e54ce68 added support for
DASH common encryption, however commit
bb336840c0 that went onto master
shortly before the CENC commit caused the calculation of the CENC
aux info offset to be incorrect.
The base_offset was being added if present, but if the base_offset
is relative to the start of the moof, the offset was being added twice.
The correct approach is to calculate the offset from the start of the
moof and use that offset when parsing the CENC aux info.
Should just compare with what can be immediatelly accepted by
the element. flacenc can't renegotiate so if it has a caps already
it should only accept if it is that caps otherwise just use the
template caps
