It generally makes not much sense to configure it for all pads/traks at
once as this value is usually different for each of them. As such, add a
new property on the pads in addition to the existing property on the
whole muxer.
https://bugzilla.gnome.org/show_bug.cgi?id=792649
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.
If a reserved-max-duration is set, we should always track
and update the reserved-duration-remaining estimate, even
if we're not sending periodic moov updates downstream for
full robust muxing.
It is possible that the mdat has more data than what was stored in the
headers file. If we put that to the output the file will have bogus data
at the end and some players will complain.
https://bugzilla.gnome.org/show_bug.cgi?id=784258
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.
The last entry will most likely get new samples added to it in "robust"
muxing mode, changing the samples_per_chunk and thus making it wrong to
keep the last two entries merged. It will run into an assertion later
when adding a new sample to the chunk.
Thanks to gdiener@cardinalpeak.com for the analysis of the bug and
proposal for a solution.
Timecode trak is only supported for mov right now, not for mp4. That
code would otherwise create an invalid trak if the muxed video contained
timecode metadata.
https://bugzilla.gnome.org/show_bug.cgi?id=782684
We only accept new caps if they are basically the same. We don't want to
reset anything as if the caps are new, otherwise various state could get
out of sync with the current run.
We have some padding added after the initial moov, so a bigger updated
moov can be handled to some degree and is expected. Previously we just
ignored the padding and errored out in cases when the padding would've
just been enough.
This sets up a moov with the correct sample positions beforehand and
only works with constant framerate, I-frame only streams.
Currently only support for ProRes and raw audio is implemented but
adding new codecs is just a matter of defining appropriate maximum frame
sizes.
https://bugzilla.gnome.org/show_bug.cgi?id=781447
When muxing raw audio, we have no way of storing timestamps but are just
storing a continuous stream of audio samples. If the difference between
the expected and the real timestamp becomes to big, we should error out
instead of silently creating files with wrong A/V sync.
https://bugzilla.gnome.org/show_bug.cgi?id=780679
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
They should have ideally the same timescale of the video track, which we
can't guarantee here as in theory timecode configuration and video
framerate could be different. However we should set a correct timescale
based on the framerate given in the timecode configuration, and not just
use the framerate numerator.
