In this mode, an initial empty moov (containing only stream metadata) is written,
followed by fragments containing actual data (along with required metadata).
New fragments are started either at keyframe (if such are sparse) or when
property configured duration exceeded.
Based on patch by Marc-André Lureau <mlureau@flumotion.com>
Fixes#632911.
This writes out the optional 'btrt' atom (MPEG4BitrateBox) for H.264
media if either or both of average and maximum bitrate are available for
the stream.
https://bugzilla.gnome.org/show_bug.cgi?id=623678
This collects the 'bitrate' and 'maximum-bitrate' tags on the
corresponding pad and uses these to populate these fields in the ESDS
where applicable.
https://bugzilla.gnome.org/show_bug.cgi?id=623678
Write uint tags that have complements (e.g. track-number/
track-count) even when we only have one of them available
and set the other one to 0.
Fixes#622484
Previously we would end up with the collectpaddata structure already freed.
This would result in a bogus iteration of mux->sinkpads (all the
GstQTPad being freed) and it wouldn't be removed from that list.
Finally, due to it not being removed from that list, we would end up
calling a bogus gst_qt_mux_pad_reset on those structures => SEGFAULT
Due to GstCollectPads sink pads list being not reliably
iteratable (when not inside the collected function) this
patch adds a sink pads list to qtmux to be used when iterating
sink pads on reset function.
Fixes#609055
Adds a new property to qtmux that sets a path to a file to write
and update data about the moov atom (that is not writen till the
end of the file). If the pipeline/app crashes during execution it
might be possible to recover the movie using the qtmoovrecover element.
qtmoovrecover is an element that is also a pipeline. It is not
meant to be used with other elements (it has no pads). It is merely
a tool/utilitary to recover unfinished qtmux files.
Fixes#601576
Following the previous qtmux commit, this patch tries
to use the new info added to the caps to fill the 'trak'
atom's fields and children atoms. This way qtmux will
use the late added 'codec_data' when h264parse adds
it in the following pipeline:
videotestsrc num-buffers=200 ! x264enc byte-stream=true ! \
h264parse output-format=0 ! qtmux ! \
filesink location=test.mov
Qtmux can accept caps renegotiation if the new caps is a
superset of the old one, meaning upstream added new info to
the caps. This patch still doesn't make qtmux update any
atoms info from the new info, but at least it doesn't
reject the new caps anymore.
A pipeline that reproduces this use case is:
videotestsrc num-buffers=200 ! x264enc byte-stream=true ! \
h264parse output-format=0 ! qtmux ! \
filesink location=test.mov
Reads the new caps added to qtdemux by commit
c917d65e6d
and adds its corresponding atoms.
Also adds support for image/x-jpc as it is the same
as image/x-jp2, except that the buffers need to be
boxed inside a jp2c isom box before muxing. To solve
this the QTPads now have a function that (if
not NULL) is called when a buffer is collected. This
function returns a replacement to the current collected
buffer.
Fixes#598916
Adds the mapping of 'classification' tags to writing of
'clsf' atoms for gppmux.
Based on a patch by: Lasse Laukkanen <ext-lasse.2.laukkanen@nokia.com>
Use the rounding version for improved sync between streams.
Small variations in the duration when muxing might lead to
cumullative wrong timestamping when demuxing.
Fixes#602936
Try to use timestamps even when the stream has out of order
timestamps, only fall back to durations when we detect an
out of order buffer. Improves sync between streams.
Adds support for muxing SVQ3 content. Usually this format
has decoder info that must be passed in the 'seqh' field
in the caps. It is also good to add the gama atom to make
quicktime not crash.
Fixes#587922
Do not wrongly add the result of the function to the
pointer to the buffer size. Instead, check the result
to see if the serialization was ok.
Based on a patch by: "Carsten Kroll <car@ximidi.com>"
Fixes#602106
When muxing streams, some can start later than others. qtmux
now handle this by adding an empty edts entry with the
duration of the 'lateness' to the stream's trak.
It tolerates a stream to be up to 0.1s late.
Fixes#586848
Keep track of the chunk durations to be able to add 3gr6
brand if it is a faststart file and the longest chunk is
smaller than a sec. Implemented according to 3gpp
TS 26.244 v6.4.0 (2005-09)
Fixes#584361
In faststart mode, there is no need to send the ftyp
right at the beginning of the stream. Waiting and sending it
only later (when the moov atom is ready to be sent) provides
us with more information about the stream and we can better
select the compatible brands.
