GitLab

It's never going to be 0 if we first increment and then check.

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.

The encoder fails to initialise when we try to set GST_TAG_PREVIEW_IMAGEs
sent to use by qtdemux from iTunes-generated m4a files. We should
not just blindly translate the PREVIEW tag to file icon image types,
but check if the specific conditions required are met (i.e. image
type 1 must be a 32x32 PNG icon, and what we're getting is 500x500).

https://bugzilla.gnome.org/show_bug.cgi?id=776962

If this option is given, it will calculate the next split point based on
timecode difference.

https://bugzilla.gnome.org/show_bug.cgi?id=774209

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

Statistics about the total number of retransmission requests
and the actual number of retransmitted packets can be helpful
at application-level.

https://bugzilla.gnome.org/show_bug.cgi?id=777182

'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

https://bugzilla.gnome.org/show_bug.cgi?id=736752

Calculate clean aperture dimensions by first guessing
display aspect ratio based on pixel aspect ratio and
frame size.

https://bugzilla.gnome.org/show_bug.cgi?id=777100

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>

Only output WARNING messages for atoms we don't know how to handle
instead of for padding/known atoms we don't need to do any processing
on

https://bugzilla.gnome.org/show_bug.cgi?id=777095

rtpjitterbuffer.c:592:3: error: ‘for’ loop initial declarations are only allowed in C99 mode

Otherwise some messages that are emitted by the element on NULL->READY
will not reach the application.

https://bugzilla.gnome.org/show_bug.cgi?id=764947

The DASH spec requires that tfdt atoms be present, so
write one out. ISO/IEC 23009-1:2014 6.3.4.2

https://bugzilla.gnome.org/show_bug.cgi?id=708221

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

https://bugzilla.gnome.org//show_bug.cgi?id=776789

Splitmuxsink might be called with a custom bin as a sink. If it has a
"location" property, it can be used.

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)

time in segment should be PTS based (not DTS).

https://bugzilla.gnome.org/show_bug.cgi?id=765498

Pass all seek flags when activating a part
based on a seek, so that SNAP flags are preserved.

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