This is disabled by default as it unnecessarily creates bigger headers
but it is something that is required by some applications and most
notably the Apple ProRes spec.
Even if timecode trak is officially unsupported in non-mov flavors,
some software still supports it, e.g. Final Cut Pro X:
https://developer.apple.com/library/archive/technotes/tn2174/_index.html
The user might still expect to see the timecode information in the
non-mov file despite it being officially unsupported , because other
software e.g. QuickTime will create a timecode trak even in mp4 files.
Furthermore, software that supports timecode trak in non-mov flavors
will also display the file duration in "timecode units" instead of real
clock time, which is not necessarily the same for 29.97 fps and friends.
This might confuse users, who see a different duration for the same
framerate and amount of frames depending on whether the container is mp4
or mov.
Fixes https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/issues/512
By the time sink_event is called, the pad's current caps have
already been updated. To address this, implement sink_event_pre_queue,
and check if the pad can be renegotiated there.
Fixes#707
The memory leak occurs in the case when the buffer has been
added to the fragment_buffers array of the current pad and
never been sent because of the push failure of the previous
buffers: moof or mdat header or fragmented buffer(s).
It must be accurate for all samples to work in Final Cut properly, so
the best we can do is to assume that all samples are the same as the
first. Bigger samples are truncated, smaller samples are padded.
Recent changes in ccextractor were attaching timecode meta to the closed
caption track. We shouldn't write timecode information for the closed
caption trak.
This fixes a bug where in some files mehd.fragment_duration is one unit
less than the actual duration of the fragmented movie, as explained below:
mehd.fragment_duration is computed by scaling the end timestamp of
the last frame of the movie in (in nanoseconds) by the movie timescale.
In some situations, the end timestamp is innacurate due to lossy conversion to
fixed point required by GstBuffer upstream.
Take for instance a movie with 3 frames at exactly 3 fps.
$ gst-launch-1.0 -v videotestsrc num-buffers=3 \
! video/x-raw, framerate="(fraction)3/1" \
! x264enc \
! fakesink silent=false
dts: 999:59:59.333333334, pts: 1000:00:00.000000000, duration: 0:00:00.333333333
dts: 999:59:59.666666667, pts: 1000:00:00.666666666, duration: 0:00:00.333333334
dts: 1000:00:00.000000000, pts: 1000:00:00.333333333, duration: 0:00:00.333333333
The end timestamp is calculated by qtmux in this way:
end timestamp = last frame DTS + last frame DUR - first frame DTS =
= 1000:00:00.000000000 + 0:00:00.333333333 - 999:59:59.333333334 =
= 0:00:00.999999999
qtmux needs to round this timestamp to the declared movie timescale, which can
ameliorate this distortion, but it's important that round-neareast is used;
otherwise it would backfire badly.
Take for example a movie with a timescale of 30 units/s.
0.999999999 s * 30 units/s = 29.999999970 units
A round-floor (as it was done before this patch) would set fragment_duration to
29 units, amplifying the original distorsion from 1 nanosecond up to 33
milliseconds less than the correct value. The greatest distortion would occur
in the case where timescale = framerate, where an entire frame duration would
be subtracted.
Also, rounding is added to tkhd duration computation too, which
potentially has the same problem.
https://bugzilla.gnome.org/show_bug.cgi?id=793959
For 59.94 FPS, it's common to set 60000 as timescale. For that
timescale, if the audio is late by as little as 0:00:00.000016666
(definitely less than one audio sample), lateness gets rounded to 1.
Added a safeguard that allows lateness up to 1 sample with the specific
trak's timescale, to make sure that values less than e.g. one audio
sample won't break the prefill mode. What will happen in this case is
that the audio will get squeezed back to the video's timestamp, which in
practice means that the audio will be 0.000016666 seconds early (with
the patch).
https://bugzilla.gnome.org/show_bug.cgi?id=797133
Supports CEA 608 and CEA 708 CC streams
Also supports usage in "Robust Prefill" mode if the incoming caption
stream is constant (i.e. there is one incoming CC buffer for each
video frame).
https://bugzilla.gnome.org/show_bug.cgi?id=606643
gst_qt_mux_can_renegotiate () gets called everywhere following
that pattern:
return gst_qt_mux_can_renegotiate (ref(self));
This means the reference must be released both in the success
and failure cases, it was only done in the success case.
If codec_data is changed, the stream is no longer valid.
Rather than keeping running when refusing new caps,
this patch send a warning to the bus.
Also fix up splitmuxsink to ignore this warning while changing caps.
https://bugzilla.gnome.org/show_bug.cgi?id=790000
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 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.
