When outputting fragmented mp4, with a seekable downstream, we rewrite
the moov to maybe add a duration to the mvex. If we start by not
writing the initial moov->mvex->mhed duration and then overwrite with a
moov containing mhed atom, the moov's will have different sizes and
could overwrite subsequent data and result in an unplayable file.
e.g. The initial moov would be of size 842 and the final moov would have
a size of 862.
Fix by always pushing out the mhed duration in the moov when
fragmenting.
Fixes https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/898
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/1060>
qtmux attempts to choose between writing a 32-bit stco chunk offset table
when it can, but switch to a 64-bit co64 table when file offsets go over
4GB.
This patch fixes a problem where the atom handling code was checking
mdat-relative offsets instead of the final file offset (computed by
adding the mdat position plus the mdat-relative offset) - leading to
problems where files with a size between 4GB and 4GB+offset-of-the-mdat
would write incorrect STCO tables with some samples having truncated
32-bit offsets.
Smaller files write STCO correctly, larger files would switch to
co64 and also output correctly.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/970>
Used by some proprietary software for their fragmented files.
Adds some support for multi-stream fragmented files
Flow is as follows.
1. The first 'fragment' is written as a self-contained fragmented
mdat+moov complete with an edit list and durations, tags, etc.
2. Subsequent fragments are written with a mdat+moof and each stream is
interleaved as data arrives (currently ignoring the interleave-*
properties). data-offsets in both the traf and the trun ensure
data is read from the correct place on demuxing. Data/chunk offsets
are also kept for writing out the final moov.
3. On finalisation, the initial moov is invalidated to a hoov and the
size of the first mdat is extended to cover the entire file contents.
Then a moov is written as regularly would in moov-at-end mode (the
default).
This results in a file that is playable throughout while leaving a
finalised file on completion for players that do not understand
fragmented mp4.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/643>
Move the SVMI stereoscopic atom parsing out to a helper
function to shrink qtdemux_parse_trak a bit.
Add a bounds check that the received atom is large enough
before parsing it.
Add a note to the atom parser that svmi comes from the
MPEG-A spec 23000-11.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/634>
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
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
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
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.
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
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.
The n_frames field (frames per second) should follow the nominal frame
rate for drop-frame timecodes.
Also, the trak's timescale (and duration, accordingly) should follow the
STSD entry's timescale and frame duration (fps_n and fps_d accordingly),
not the other way around.
https://bugzilla.gnome.org/show_bug.cgi?id=777832
Needed for QuickTime 7 to properly play files.
Also write the clap atom for MOV files always, not only when ProRes is
used as a video codec. It's mandatory for MOV.
https://bugzilla.gnome.org/show_bug.cgi?id=777100
Remove an old check from atom_stsc_add_new_entry() that
extends the last entry in the STSC if the samples per chunk
matches, as the new interleave merging logic requires that
the final entry by updateable. There's already code
below which simply merges the final entry into the previous
one when needed, so rely on that instead.
Fixes asserts like:
ERROR:atoms.c:2940:atom_stsc_update_entry: assertion failed:
(atom_array_index (&stsc->entries, len - 1).first_chunk == first_chunk)
Previously we were switching from one chunk to another on every single
buffer. This wastes some space in the headers and, depending on the
software, might depend in more reads (e.g. if the software is reading
multiple samples in one go if they're in the same chunk).
The ProRes guidelines suggest an interleave of 0.5s is common, but
specifies that for ProRes at most 2MB (for SD) and 4MB (for HD) should
be used per chunk. This will be handled in a follow-up commit.
https://bugzilla.gnome.org/show_bug.cgi?id=773217
It's required for ProRes to work with other software.
It is also in the MP4 standard, but inventing values here seems a bit
tricky for the general case and it does not really give any extra
information.
https://bugzilla.gnome.org/show_bug.cgi?id=769048
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.
Remove a custom specialized version of gst_buffer_new_wrapped by
using gst_buffer_new_wrapped_full inside a macro to simplify
parameters and give it a more meaningful name.
It is only used to create temporary buffers to have its data copied.
Adds AC-3 muxing support. It is defined for mp4 and 3gp formats.
One extra feature that was added was the ability to add extension
atoms after set_caps as the AC-3 extension atom needs some data
that has to be extracted from the stream itself and is not
present on caps.
