Whenever got new moov or new stream-start,
demux will try to expose new pad by following rule.
Comparing stream-id in the current moov with previous one, then
* If matched stream-id is found from previous one,
reuse existing pad (most common case)
* Otherwise, expose new pad with new stream-start
* No more used stream will be freed
https://bugzilla.gnome.org/show_bug.cgi?id=684790
Whenever demux got moov, demux will create new stream. Only exception is
duplicated track-id in a moov box. In that case the first stream
will be accepted. This patch is pre-work for rework of moov handling.
https://bugzilla.gnome.org/show_bug.cgi?id=684790
Corrupted files could potentially have multiple cdat/cdt2 atoms in
a sample entry, which is unclear how to handle.
Ignore repeated ones.
CID #1434162
CID #1434159
The value stored in cenc_aux_sample_count wasn't in sync with the
parsing code that followed which checks whether all entries are
valid and present.
Only write the actual sample count when we know for sure.
CID #1427087
The samples table is sorted by DTS, not PTS. As such we can only get the
correct result when using a binary search on it, if we search for the
DTS.
Also if we only ever search for the frame, where the following frame is
the first one with a PTS after the search position, we will generally
stop searching too early if frames are reordered.
In forwards playback this is not really a problem (after the decoder
reordered the frames, clipping is happening), in reverse playback
it means that we can output one or more frames too few as we stop too
early and the decoder would never receive it.
https://bugzilla.gnome.org/show_bug.cgi?id=782118
If we saw empty segments, we previously unconditionally pushed a
GAP event downstream regardless of the duration of that empty
segment.
In order to avoid issues with initial negotiation of downstream elements
(which would negotiate to something before receiving any data due to
that initial GAP event), check if there's at least a second of difference
(like we do for other GAP-related checks in qtdemux) before
deciding to push a GAP event downstream.
qtdemux.c: In function ‘gst_qtdemux_configure_stream’:
qtdemux.c:7764:34: error: suggest parentheses around ‘&&’ within ‘||’ [-Werror=parentheses]
if ((stream->n_samples == 1) && (stream->first_duration == 0)
~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Avoid computing frame rate when a stream contain moof with only one
sample, to avoid an assert. The moof is considered as still picture.
The same is already done for one sample given in the moov.
https://bugzilla.gnome.org/show_bug.cgi?id=782217
... which no longer worked due to unconditionally clearing sample info and
ending up in inconsistent state. Let's tread a bit more carefully and also
allow for the old seek handling that resorts to scanning if no mfra info
is available.
In push mode we process as much as possible in the adapter. When we receive
a DISCONT buffer which we can't match to an actual sample (based on the existing
sample table) and there is still data remaining in the incoming adapter,there is
one of two cases happening:
1) We are doing reverse playback, in which case we should flush out all pending
data
2) We have leftover data from the previous incoming buffer... which we can't do
anything about.
For the second case, make sure we flush out the remaining data so that we can start
parsing again from scratch.
https://bugzilla.gnome.org/show_bug.cgi?id=781319
Make sure offset and neededbytes are properly resetted when all
streams are EOS in push-mode.
Avoids cases when some data might still be pushed by upstream (because
it didn't yet see the resulting GST_FLOW_EOS yet) and qtdemux gets
completely lost.
https://bugzilla.gnome.org/show_bug.cgi?id=781266
Before pushing a sample, check if there was a change in the current
stsd entry. This patch also assumes that the first stsd entry is
used as default for the first sample. It might cause an uneeded
caps renegotiation when this isn't the case.
stsd can have multiple format entries, parse them all.
This is required to play DVB DASH profile that uses multiple entries
to identify the different available bitrates/options on dash streams
The stream format-specific data is not stored into QtDemuxStreamStsdEntry
Instead of using the stsd as a base pointer, use the actual stsd
entry as the stsd can have multiple entries. This is rarely used
for file playback but is a possible profile with in DVB DASH specs.
This still doesn't support stsd with multiple entries but makes it
easier to do so.
This is an update of d78d589627
We still exit as early as possible in case of non-ok/non-unlinked combined
flow, but we first make sure that we update the internal position variables.
This ensures that if upstreams "ignores" the flow return (and carries on pushing),
we don't end up processing data with completely bogus variables/positions.
TFDTs with time 0 are being ignored since commit 1fc3d42f. They're
mistaken with the case of not having TFDT, but those two cases
must be distinguished in some way.
This patch passes an extra boolean flag when the TFDT is present.
This is now the condition being evaluated, instead of checking for
0 time.
https://bugzilla.gnome.org/show_bug.cgi?id=780410
Similar to what was done in adaptivedemux, ignore seek
events we've already handled - such as when they are received
on every srcpad of files with lots of streams.
Otherwise mdatleft will have a value calculated from the initial
mdatsize minus the parts of the stream that we saw, which is not
including all the parts of the stream that might've been skipped.
We parse the next moof in advance of having pushed
all samples from the previous one in some cases, and
we'll still need the crypto info from the previous
fragment so keep around any unused crypto info entries
when adding new ones
qtdemux.c: In function ‘qtdemux_parse_samples’:
qtdemux.c:8450:39: error: ‘*’ in boolean context, suggest ‘&&’ instead [-Werror=int-in-bool-context]
if (stream->samples_per_frame * stream->bytes_per_frame) {
~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~
This reverts commit 107902ec51.
This commit intended to ensure that keyframe seeks land at the
start timestamp of a keyframe, rather than in the middle of one,
but they cause trouble on files with sparse streams, or with
JPEG 'cover art' tracks that have only one or a few JPEG samples
with very long durations.
That's still desirable for doing seamless cutting of videos,
but needs a rethink for implementation.
https://bugzilla.gnome.org/show_bug.cgi?id=778690
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
No variables were added/removed. This was just a good excuse to:
* Comment what most variables are used for (and when)
* Order them in such a way as to show first the common variables used
in all cases, followed by those only used in push-mode
We shouldn't go through segment activation as we will only have a limited
understanding of how the whole stream timeline looks like from the moof. We
only know about the current fragment, while upstream knows about the whole
stream.
This fixes seeking in DASH streams, both for seeks after the current moof and
for seeks into the current moof. The former would fail because the moof ends
and we can't activate any segment, the latter would cause a segment that stops
at the moof end, and no further fragments would be played because we end up
being EOS.
https://bugzilla.gnome.org/show_bug.cgi?id=767071
segment_duration and media_time should be parsed based on version
of elst box. Specification defines that an elst box with version 1
has uint64 and int64 values for segment_duration and media_time,
respectively.
https://bugzilla.gnome.org/show_bug.cgi?id=766301
Properly handle edts segments for push-based operation seeking.
We only support edts that a single segment that has media at the end,
being preceeded by any number of gap segments.
This also allows the qt segment rate to be respected after seeks
https://bugzilla.gnome.org/show_bug.cgi?id=765669
timescale/1 is unreliable value for framerate. Due to downstream
element usually use framerate generated by qtdemux, let it be omitted
until the framerate can be reliably calculated.
https://bugzilla.gnome.org/show_bug.cgi?id=764733
When playing a stream that has been protected by DASH CENC, playback
will fail if a seek is performed. Qtdemux produces the error "stream
is protected using cenc, but no cenc protection system information
has been found" and playback stops.
The problem is that gst_qtdemux_reset() gets called as part of the
FLUSH during a seek. This function frees the protection_system_ids
array. When gst_qtdemux_configure_protected_caps() is called after the
seek has completed, the protection_system_ids array is empty and
qtdemux is unable to create the correct output caps for the protected
stream.
This commit changes it to only free the protection_system_ids on
hard resets.
https://bugzilla.gnome.org/show_bug.cgi?id=761787
qtdemux->streams is an array, it will never evaluate to true when comparing
to NULL. Instead we want to check the number of streams to make sure the
stream is available.
https://bugzilla.gnome.org/show_bug.cgi?id=753614
CID 1358389
The PIFF data is stored in a custom UUID box which is parsed and the
crypto_info of the element is updated accordingly. This allows
downstream decryptors to process and decrypt the protected content.
https://bugzilla.gnome.org/show_bug.cgi?id=753614
If we don't find the index of the sample correctly in src_convert function,
we have to unref about the qtdemux before returning value.
So, I have modify it about instead pass qtdemux as a parameter into
src_convert function.
https://bugzilla.gnome.org/show_bug.cgi?id=763973
Currently, get_duration function always return the TRUE even though
it can't be set duration correctly. So, we need to add the else condition
about the fail case. Also, we already set the GST_CLOCK_TIME_NONE
in this function. So I have modify it which is related code in some
function.
https://bugzilla.gnome.org/show_bug.cgi?id=763968
When upstream is running in bytes in push-mode, qtdemux will
convert seeks from time to bytes and send it upstream. Upstream
element will perform a byte seek and send a byte segment to qtdemux
that will convert it to time and push it downstream.
There is, however, the pending_segment variable that stores a new
segment event to be pushed before the next data. When handling seeks
as mentioned above this variable was being ignored and, if it contained
some segment event, it would override the one resulting from the seek.
This would restore a previous segment and would cause the seek segment
to be discarded downstream.
This patch fixes this issue by unrefing any pending segment as the
seek from upstream should contain the latest one that should be
used, as requested by the application.
https://bugzilla.gnome.org/show_bug.cgi?id=763165
In some cases the stream configuration can fail, for instance if the
stream is protected and no decryptor was found. For those situations
the demuxer shouldn't emit any data on the corresponding source pad of
the stream and bail out.
https://bugzilla.gnome.org/show_bug.cgi?id=762516
