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.
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
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.
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,
^
| ../../../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
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
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;
^~~~~~~~~~~~~~
We consider there's a sifnificant difference when it's larger than on second
or than half the duration of the last processed fragment in case the latter is
larger.
https://bugzilla.gnome.org/show_bug.cgi?id=754230
And don't just reset everything. This makes sure that we can continue to
handle data in the following scenario:
moov: discont
moof: discont
mdat: continuous
Previously this would fail because the offset would be the accumulated offset
from moov and moof at the mdat position, while the buffer offset might be
something completely different.
As seen in the parent switch for object_type_id, the 4 possible values are
0x40, 0x66, 0x67 and 0x68. Fixing the nested switch to match these values.
Looks like it was a typo making them decimal instead of hexadecimal.
CID 1363328
Without, raw AAC can't be handled and we have some information available in
the decoder that most likely allows us to decode the stream in one way or
another. This is the same code already used by matroskademux for the same
reasons, and ffmpeg/vlc play such files just fine too by guesswork.
This is to handle cases where upstream handles the fragmented streaming in TIME
segments and sends us data with gaps within fragments. This would happen when dealing
with trick-modes.
When upstream (push-based, TIME SEGMENT) wishes to send discontinuous samples,
it must obey the following rules:
* The buffer containing the [moof] must have a valid GST_BUFFER_OFFSET
* The buffers containing the first sample after a gap:
* MUST start at the beginning of a sample,
* MUST have the DISCONT flag set,
* MUST have a valid GST_BUFFER_OFFSET relative to the beginning of the fragment.
https://bugzilla.gnome.org/show_bug.cgi?id=767354
