The n_frames field (frames per second) should follow the nominal frame
rate for drop-frame timecodes.
Also, the trak's timescale (and duration, accordingly) should follow the
STSD entry's timescale and frame duration (fps_n and fps_d accordingly),
not the other way around.
https://bugzilla.gnome.org/show_bug.cgi?id=777832
In case wavparse receives a manually injected FLUSH_STOP event
while operating in pull mode we get criticals because we'd try
to clear a NULL adapter.
https://bugzilla.gnome.org/show_bug.cgi?id=777123
Insert VPS/SPS/PPS before the first NAL unit containing an I-frame in an
access unit only. If an access unit consists of several such NAL units
(tiles) VPS/SPS/PPS should only be inserted before the first of them so
that parameters are only updated between frames.
Do not insert VPS/SPS/PPS before P-frames when config-interval is -1.
https://bugzilla.gnome.org/show_bug.cgi?id=775817
qtdemux_handle_xmp_taglist() requires a writable taglist,
but qtdemux->tag_list can become non-writable, specifically
after sending global tags (qtdemux.c:958), which adds a
second reference. Ensure the list is made writable before
calling (make_writable will copy the list if necessary).
https://bugzilla.gnome.org/show_bug.cgi?id=766177
These are usually much bigger than icon size and required by
iTunes to be certain fairly large sizes. In qtmux it is also
the IMAGE tags which we write out as 'covr' atoms.
When reset, don't restart request pad numberings, as
request pads can survive across state changes. Only
restart at 0 if all request pads are handed back first.
https://bugzilla.gnome.org/show_bug.cgi?id=777174
'stream-format' and 'alignment' are defined in pad template caps so
there is no need to check them again here. Also remove bitrate parsing from
caps as bitrate in caps doesn't make sense but from tags, which is
actually the case.
https://bugzilla.gnome.org/show_bug.cgi?id=777181
Needed for QuickTime 7 to properly play files.
Also write the clap atom for MOV files always, not only when ProRes is
used as a video codec. It's mandatory for MOV.
https://bugzilla.gnome.org/show_bug.cgi?id=777100
The seqh buffer allocated in qtdemux_parse_svq3_stsd_data() needs to
be freed by the caller after use.
https://bugzilla.gnome.org/show_bug.cgi?id=777157
Signed-off-by: Andre McCurdy <armccurdy@gmail.com>
If a fragmented stream doesn't have a tfdt, don't
reset the output timestamps at each fragment boundary
by erroneously using the default value of 0. Introduced
by commit 69fc48
https://bugzilla.gnome.org/show_bug.cgi?id=754230
Majorly change the way that splitmuxsink collects
incoming data and sends it to the output, so that it
makes all decisions about when / where to split files
on the input side.
Use separate queues for each stream, so they can be
grown individually and kept as small as possible.
This removes raciness I observed where sometimes
some data would end up put in a different output file
over multiple runs with the same input.
Also fixes hangs with input queues getting full
and causing muxing to stall out.
Add a new signal for formatting the filename, which receives
a GstSample containing the first buffer from the reference
stream that will be muxed into that file.
Useful for creating filenames that are based on the
running time or other attributes of the buffer.
To make it work, opening of files and setting filenames is
now deferred until there is some data to write to it,
which also requires some changes to how async state changes
and gap events are handled.
When performing a key-unit seek, always snap to the start ts
of the keyframe buffer we landed on so that the keyframe is
entirely within the resulting outgoing segment. That seems
the most sensible result, since the user requested snapping
to the keyframe position.
Segments times and seek requests are stored and handled
in raw 'PTS' time, without the cslg_shift - which only applies
to outgoing samples. Omit the cslg_shift portion when
extracting PTS to compare for internal seek snaps.
If the cslg_shift is included, then keyframe+snap-before seeks
generate a segment start/stop time that already includes the
cslg_shift, and it's then added a 2nd time, causing the
first buffer(s) to have timestamps that are out of segment.
Remove an old check from atom_stsc_add_new_entry() that
extends the last entry in the STSC if the samples per chunk
matches, as the new interleave merging logic requires that
the final entry by updateable. There's already code
below which simply merges the final entry into the previous
one when needed, so rely on that instead.
Fixes asserts like:
ERROR:atoms.c:2940:atom_stsc_update_entry: assertion failed:
(atom_array_index (&stsc->entries, len - 1).first_chunk == first_chunk)
Make sure the state of the parser is set to
collecting streams before chaining up to the
parent change_state() method, to close a
small window that can cause playback to
never commence.
Use GQueue instead of a GSList so we don't have to traverse
the whole list to append something every time. And it also
keeps track of the number of items in it for us.
Add a function to add filenames to the list of old files and
use it in more places, so that memory doesn't build up in
other modes either if no max_files limit is specified.
https://bugzilla.gnome.org/show_bug.cgi?id=766991
Technically we weren't leaking the memory, just storing it internally
and never using it until the element is freed. But we'd still use more
and more memory over time, so this is not good over longer periods
of time. Only keep track of files if there's actually a limit set,
so that we will prune the list from time to time.
https://bugzilla.gnome.org/show_bug.cgi?id=766991
Previously, seeking to position y where y is (strictly) within a keyframe
would seek to that keyframe both with SNAP_BEFORE and SNAP_AFTER,
where the latter is now adjusted to really snap to the next keyframe.
Rather amazingly (and equally unnoticed), keyunit seeking resulted in segments
where start != time (which is bogus for simple avi timeline). So, properly
adjust the segment (start) rather than fiddling with segment time (only).
... by using the original seek event's flags rather than the corresponding
segment flags, which do not have such counterpart flags (and
do no longer have them covertly sneaking in nowadays).
With Xiph codecs the stream header buffers are both in the caps and are
usually also at the beginning of each input stream, but it's perfectly
possible that the input stream does not have the stream header buffers
inline in the data. Matroskamux would drop the first N buffers assuming
they're stream headers, but this meant it would drop actual payload data
when the stream didn't contain the stream headers inline. Fix this by
only dropping leading buffers if they're flagged as stream headers. This
fixes issues with streams that are being tapped into after streaming
has started.
https://bugzilla.gnome.org/show_bug.cgi?id=749098
That is, whenever we go through start/stop we have to ensure that on the
next opportunity the buffers are reallocated again. Otherwise the
buffers might be NULL because the element was reused with the same
configuration as before (i.e. set_caps() wouldn't have reinited the
buffers).
https://bugzilla.gnome.org/show_bug.cgi?id=775898
Redirect on PLAY wasn't doing the necessary session cleanup. Fixed by
removing code from gst_rtspsrc_send that changed the state varable upon
encountering a redirect. Better to let the redirect handlers in
gst_rtspsrc_retrieve_sdp and gst_rtspsrc_play do their own
state-dependent cleanup.
https://bugzilla.gnome.org/show_bug.cgi?id=775543
When providing items with a seqnum, there is a (very small) probability
that an element with the same seqnum already exists. Don't forget
to free that item if it wasn't inserted.
And avoid returning undefined values when dealing with duplicate items
We can't simply assume that the length of the tag value as given
inside the stream is correct but should also check against the amount of
data we have actually available.
https://bugzilla.gnome.org/show_bug.cgi?id=775451
qtdemux.c: In function ‘qtdemux_parse_trak’:
qtdemux.c:10184:38: error: format ‘%lu’ expects argument of type ‘long unsigned int’, but argument 9 has type ‘gint {aka const int}’ [-Werror=format=]
GST_DEBUG_OBJECT (qtdemux, "Found jpeg: len %u, need %lu", len,
^
If an element queries the number of retransmission buffers pushed
*while* the push is still taking place (and before the object lock
is taken just after) it would end up with the wrong statistic
being reported.
Increment it just before the push, avoids races when getting statistics
https://bugzilla.gnome.org/show_bug.cgi?id=768723
39f7e52266 was setting the buffer duration
to 0 if is not valid, under the assumption that this is "the last"
buffer and no others are coming next. This is wrong, last_buf is the
previous buffer and not the very last one.
4e3c13c87c was setting DTS to 0 if there
was none. This will set DTS to 0 for all e.g. audio streams, completely
messing up calculations if streams don't start at 0.
https://bugzilla.gnome.org/show_bug.cgi?id=774840
Solves overreading/writing the given arrays and will error out if the
streams asks to do that.
Also does more error checking that the stream is valid and won't
overrun any allocated arrays. Also mitigate integer overflow errors
calculating allocation sizes.
https://bugzilla.gnome.org/show_bug.cgi?id=774859
After finding a cluster id in the byte reader, we skip ahead the reader
position by one further byte to be able to continue searching from there
inside the same chunk if the cluster candidate was a false positive.
We have to accomodate for that additional byte when resuming the search,
otherwise all following pulls are off-by-one for every resume and we run
into an assertion.
bf43f44fcf was comparing an unsigned
expression to be < 0 which was always false.
gstflxdec.c: In function ‘flx_decode_brun’:
gstflxdec.c:322:33: warning: comparison of unsigned expression < 0 is always false [-Wtype-limits]
if ((glong) row - count < 0) {
^
gstflxdec.c:332:33: warning: comparison of unsigned expression < 0 is always false [-Wtype-limits]
if ((glong) row - count < 0) {
^
https://bugzilla.gnome.org/show_bug.cgi?id=774834
| ../../../git/gst/isomp4/qtdemux.c: In function 'qtdemux_parse_tree':
| ../../../git/gst/isomp4/qtdemux.c:10224:24: error: 'size' may be used uninitialized in this function [-Werror=maybe-uninitialized]
| offset += size;
| ^~
| ../../../git/gst/isomp4/qtdemux.c:10197:25: note: 'size' was declared here
| guint32 size, tag;
| ^~~~
https://bugzilla.gnome.org/show_bug.cgi?id=774747
Always write an edit list for the whole track. In general this is not
necessary except for the case of having a gap or DTS adjustment but
it allows to give the whole track's duration in the usually more
accurate media timescale.
https://bugzilla.gnome.org/show_bug.cgi?id=774403
splitmuxsink requests pad from element using pad template like "video_%u", "audio_%u" and "sink_%d". This is true for most of the muxers.
But splitmuxsink not able to request pad to flvmux as flvmux has "audio" and "video" as pad templates.
fix: splitmuxsink should fallback to "audio" and "video" when template not found.
https://bugzilla.gnome.org/show_bug.cgi?id=774507
A new signal named on-bundled-ssrc is provided and can be
used by the application to redirect a stream to a different
GstRtpSession or to keep the RTX stream grouped within the
GstRtpSession of the same media type.
https://bugzilla.gnome.org/show_bug.cgi?id=772740
aacparse resizes input buffer while converting ADTS stream to RAW,
During buffer resize buffer write permission is not checked.
This throws gst_buffer_is_writable assertion and leads to AV sync issue some times.
It is corrected by making buffer writeable using gst_buffer_make_writable
https://bugzilla.gnome.org/show_bug.cgi?id=774129
TIME segment implies that stream/running time is being handled by upstream.
So, we shouldn't override it without any clue.
This patch is for fixing seek in DASH streaming.
https://bugzilla.gnome.org/show_bug.cgi?id=774196
The accumulator is filled by intersecting with all the pad caps, as such
it must be initialized with ANY (like it is before the iteration is
started) and not to EMPTY.
Fixes the CAPS query always returning EMPTY caps when resyncing happened
during the query, e.g. because pads were added/removed.
The g_object_unref (saddr) before receiving message seems to be redundant as it
is done just before jumping to retry
Though not directly related, part of
https://bugzilla.gnome.org/show_bug.cgi?id=772841
Control messages are used only in multicast mode - to detect if the destination
address is not ours and possibly drop the packet. However in non-multicast
modes the messages are still allocated and freed even if not used. Therefore
request control messages from g_socket_receive_message() only in multicast
mode.
https://bugzilla.gnome.org/show_bug.cgi?id=772841
Do not use last buffer TS + buffer duration because buffer duration
might be inaccurate, especially for frame rates like 30fps where a
rounding error is observed.
https://bugzilla.gnome.org/show_bug.cgi?id=773785
When doing rtx, the jitterbuffer will always add an rtx-timer for the next
sequence number.
In the case of the packet corresponding to that sequence number arriving,
that same timer will be reused, and simply moved on to wait for the
following sequence number etc.
Once an rtx-timer expires (after all retries), it will be rescheduled as
a lost-timer instead for the same sequence number.
Now, if this particular sequence-number now arrives (after the timer has
become a lost-timer), the reuse mechanism *should* now set a new
rtx-timer for the next sequence number, but the bug is that it does
not change the timer-type, and hence schedules a lost-timer for that
following sequence number, with the result that you will have a very
early lost-event for a packet that might still arrive, and you will
never be able to send any rtx for this packet.
Found by Erlend Graff - erlend@pexip.comhttps://bugzilla.gnome.org/show_bug.cgi?id=773891
The lost-event was using a different time-domain (dts) than the outgoing
buffers (pts). Given certain network-conditions these two would become
sufficiently different and the lost-event contained timestamp/duration
that was really wrong. As an example GstAudioDecoder could produce
a stream that jumps back and forth in time after receiving a lost-event.
The previous behavior calculated the pts (based on the rtptime) inside the
rtp_jitter_buffer_insert function, but now this functionality has been
refactored into a new function rtp_jitter_buffer_calculate_pts that is
called much earlier in the _chain function to make pts available to
various calculations that wrongly used dts previously
(like the lost-event).
There are however two calculations where using dts is the right thing to
do: calculating the receive-jitter and the rtx-round-trip-time, where the
arrival time of the buffer from the network is the right metric
(and is what dts in fact is today).
The patch also adds two tests regarding B-frames or the
“rtptime-going-backwards”-scenario, as there were some concerns that this
patch might break this behavior (which the tests shows it does not).
The new timeout is always going to be (timeout + delay), however, the
old behavior compared the current timeout to just (timeout), basically
being (delay) off.
This would happen if rtx-delay == rtx-retry-timeout, with the result that
a second rtx attempt for any buffers would be scheduled immediately instead
of after rtx-delay ms.
Simply calculate (new_timeout = timeout + delay) and then use that instead.
https://bugzilla.gnome.org/show_bug.cgi?id=773905
Commit 83e718 added a pad template to splitmux request
pads, which means that GstElement now releases the pads on
dispose, but after having removed all elements in the bin
and unlinked them. Make sure we can handle cleanup in that case
without throwing assertions.
https://bugzilla.gnome.org/show_bug.cgi?id=773784
qtdemux.c: In function ‘qtdemux_parse_tree’:
qtdemux.c:10139:16: error: ‘color_table_id’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
if (color_table_id != 0) {
^
qtdemux.c:10121:19: note: ‘color_table_id’ was declared here
guint16 color_table_id;
^~~~~~~~~~~~~~
The ProRes guidelines suggest an interleave of 0.5s is common, but
specifies that for ProRes at most 2MB (for SD) and 4MB (for HD) should
be used per chunk.
It might also make sense to use similar numbers in general.
https://bugzilla.gnome.org/show_bug.cgi?id=773217
Previously we were switching from one chunk to another on every single
buffer. This wastes some space in the headers and, depending on the
software, might depend in more reads (e.g. if the software is reading
multiple samples in one go if they're in the same chunk).
The ProRes guidelines suggest an interleave of 0.5s is common, but
specifies that for ProRes at most 2MB (for SD) and 4MB (for HD) should
be used per chunk. This will be handled in a follow-up commit.
https://bugzilla.gnome.org/show_bug.cgi?id=773217
It's required for ProRes to work with other software.
It is also in the MP4 standard, but inventing values here seems a bit
tricky for the general case and it does not really give any extra
information.
https://bugzilla.gnome.org/show_bug.cgi?id=769048
