When seeking back to restore the mdat position a flush is pushed
through and it resets downstream segment information. Make sure
that after the flush (that does a soft reset) a segment will
be pushed again
Fixes regressions spotted at
https://ci.gstreamer.net/job/GStreamer-master-validate/2100/
10 FourCCs generated with GST_MAKE_FOURCC() in gstqtmux.c and atoms.c
already exist in fourcc.h. Don't duplicate these and use them directly.
Plus moving 6 to fourcc.h, to centralize them all.
This fixes seeking if the first entries in the samples table are negative. The
binary search would always fail on this as the array would not be sorted if
interpreting the negative numbers as huge positive numbers. This caused us to
always output buffers from the beginning after a seek instead of close to the
seek position.
Also add a case to the comparison function for equality.
It would be unusual to have the header segment with an 'edts' atom
indicating gaps at the beginning when handling fragmented streams.
The header usually doesn't contain any timestamping information, this
should come from the playlist/manifest and the segments with media
in those scenarios.
https://bugzilla.gnome.org/show_bug.cgi?id=758171
In push-mode it is hard to support qt segments overall but it is
possible to support when the file isn't heavily edited but just contain
a segment to indicate a gap at the beginning. This also allows properly
timestamping data that has negative DTS in push-mode.
It is relevant to support those for 2 scenarios:
1) fragmented streaming
2) HTTP playback of 'regular' mp4
https://bugzilla.gnome.org/show_bug.cgi?id=753484
If the QtDemuxStream are re-used they may already have caps which used
to be leaked.
Reproduced using the
validate.dash.playback.seek_forward.dash_exMPD_BIP_TC1 validate
scenario.
https://bugzilla.gnome.org/show_bug.cgi?id=756561
Negotiation to audio/x-raw,format=S8 was not possible because S8 does
not have a bit order so we ended up doing `if (!entry.fourcc) goto refuse_caps;`
https://bugzilla.gnome.org/show_bug.cgi?id=756387
If seeking targets an empty segment skip it as there is no media
offset to get from it. Instead look for the next one.
This doesn't make seeking in push-mode work if you seek to an
empty segment but at least won't get you to wrong offsets.
https://bugzilla.gnome.org/show_bug.cgi?id=753484
eceb2ccc73 broke segment seeks by always
accumulating segments manually when activating a segment. This is only
needed when handling edit lists, not when activating a segment because of a
seek. Do the accumulation when switching edit list segments instead.
This fixes segment seeks again, while keeping edit lists playback working.
https://bugzilla.gnome.org/show_bug.cgi?id=755471
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.
This commit adds support for ISOBMFF Common Encryption (cenc), as
defined in ISO/IEC 23001-7. It uses a GstProtection event to
pass the contents of PSSH boxes to downstream decryptor elements
and attached GstProtectionMeta to each sample.
https://bugzilla.gnome.org/show_bug.cgi?id=705991
When a new time segment is received upstream is going to restart
with a new atom. Make the neededbytes and todrop variables
reflect that to avoid waiting too much or dropping the
initial bytes that contain the header.
The adapter might have data remaining from the previous segment,
push it all before clearing the adapter and starting a new segment.
It can accumulate data if it had pushed and got not-linked, returning
immediately without processing all the data. Before starting a new
segment this data should be handled.
Avoids accumulating all samples from a fragmented stream that could
lead to a 'index-too-big' error once it goes over 50MB of data. It
could reach that before 2h of playback so it doesn't take that long.
As upstream elements are providing data in time format they should
be the ones that have more information about the full media index
and should be able to seek if possible.
upstream_newsegment isn't really clear on what it means, it is set
to TRUE when the upstream element sends a segment in TIME format, so
rename it to be more clear about it.
It is important to know this because it means that upstream has
a notion of time and qtdemux is likely being driven by an upstream
element that is reading from a higher level abstraction than a file,
such as a DASH, MSS or DLNA element.
In fragmented streaming, multiple moov/moof will be parsed and their
previously stored samples array might leak when new values are parsed.
The parse_trak and callees won't free the previously stored values
before parsing the new ones.
In step-by-step, this is what happens:
1) initial moov is parsed, traks as well, streams are created. The
trak doesn't contain samples because they are in the moof's trun
boxes. n_samples is set to 0 while parsing the trak and the samples
array is still NULL.
2) moofs are parsed, and their trun boxes will increase n_samples and
create/extend the samples array
3) At some point a new moov might be sent (bitrate switching, for example)
and parsing the trak will overwrite n_samples with the values from
this trak. If the n_samples is set to 0 qtdemux will assume that
the samples array is NULL and will leak it when a new one is
created for the subsequent moofs.
This patch makes qtdemux properly free previous sample data before
creating new ones and adds an assert to catch future occurrences of
this issue when the code changes.
Most files don't contain the values for transposing the coordinates
back to the positive quadrant so qtdemux was ignoring the rotation
tag. To be able to properly handle those files qtdemux will also ignore
the transposing values to only detect the rotation using the values
abde from the transformation matrix:
[a b c]
[d e f]
[g h i]
https://bugzilla.gnome.org/show_bug.cgi?id=738681
The media start has nothing to do with the shift we have applied
but with the value of the first PTS. This is defined as:
Dt(0) = 0
Ct(0) = Dt(0) + CTTS(0)
So the media start is always the first CTTS.
https://bugzilla.gnome.org/show_bug.cgi?id=751361
