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.
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 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.
Sometimes it is useful to know this information on the
server side. Other popular implementations (vlc, ffmpeg, ...)
also send this header on every message.
This includes a new "user-agent" property that the user
can set to use a custom User-Agent string. The default
is "GStreamer/<version>"
https://bugzilla.gnome.org/show_bug.cgi?id=750101
Use constantDuration to calculate the timestamp of non-first AU in the
RTP packet.
If constantDuration is not present in the MIME parameters, its value
must be calculated based on the timing information from two consecutive
RTP packets with AU-Index equal to 0.
https://bugzilla.gnome.org/show_bug.cgi?id=747881
The payloader didn't copy anything so far, the depayloader copied every
possible meta. Let's make it consistent and just copy all metas without
tags or with only the video tag.
https://bugzilla.gnome.org/show_bug.cgi?id=751774
