GitLab

https://bugzilla.gnome.org/show_bug.cgi?id=648004

Refuse h264 caps without stream-format and codec_data fields for
now, to avoid creating broken files. This might cause some pipelines
that worked previously to fail. However, the move from -bad to -good
is our only chance to fix this up, so make it strict for now. We can
always change it back to be less strict in future.

https://bugzilla.gnome.org/show_bug.cgi?id=647919

https://bugzilla.gnome.org/show_bug.cgi?id=636699

https://bugzilla.gnome.org/show_bug.cgi?id=606662

This is needed for automatic transcoding using encodebin. Our typefinder
does not always add a variant to the found caps, and encodebin needs
an *exact* match to the caps on the source pad template, so we need
to add the variant-less video/quicktime caps to the template as well
for encodebin to be able to find it. Add unit test for this as well.

https://bugzilla.gnome.org/show_bug.cgi?id=642879

Fixes #646256.

Adds GstTagXmpWriter interface support to qtmux

See also #432612.

... and not only when sort-of feeling like it.
In any case, if it turns out all really is in order,
and presumably DTS == PTS, then no ctts will be produced anyway.

This reverts commit 6d8740476ccd3a3498dc4f18c19733643825c7b8.

Depends on a core commit that was reverted

The core now calls release pad from finalize, at which point
the collectpads might have already been freed.

... rather than at _init time, so they are also available following a
pad (de)activation cycle.

https://bugzilla.gnome.org/show_bug.cgi?id=639338

That is, all sorts of problems arise with re-ordered input timestamps that
tend to defy automagic handling for every case, so allow for a few variations
that can be tried depending on circumstances.

Also try to document accordingly.

Also fixes #638288.

Signed-off-by: Felipe Contreras <felipe.contreras@nokia.com>

In particular, only write a ctts atom if and only if ever a non-zero offset.

Rather, auto-determine if 64-bits fields are needed for a valid result, and
stick to plain 32-bits if not needed.

API: GstQTMux:large-file (removed)

Fixes #636185.

Avoid negative overflow by checking the order of operands
on subtraction of unsigned integers.

https://bugzilla.gnome.org/show_bug.cgi?id=635878

This is mainly because Smoothstreaming client are broken and don't
take the TimeScale property into account.

Based on patch by Marc-André Lureau <mlureau@flumotion.com>

Based on patch by Marc-André Lureau <mlureau@flumotion.com>

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.

Based on patch by Marc-André Lureau <mlureau@flumotion.com>

Also check a bit more for possible errors, and free proper items in such case.

... which keeps qtmux simpler.