It was not working properly and the implementation of the smartencoder
element was weird. This introduce a number of changes (which are all
in one single commit because they basically all work together and lead
to basically reimplementing the element):
* Make smartencoder a bin so that the reencoding chain of elements are
inside of it instead of not having any parent. Those elements were not
be visible when dumping the pipeline which was very confusing.
* Make encodebin create the right encoder with a capsfilter (and parser)
to properly enforce the format specified by the user, and so that the
encoder properties specified in the encoding profile are respected.
* Use `decodebin` to do the decoding instead of selecting a decoder
ourself and not plug any parser etc...
* Ensure that negotiated format in the sinkpad of smart encoder is fixed
through time when the user requested a non dynamic output
* Add a parser at the beginning of the smart encoder
* Handle errors when reencoding
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/751>
the old manner does not consider the profile idc. The profile idc should
play an more important role in recognizing the profile than the other
information. And there is no need to mix profiles of different extensions
together to find the closest profile when the bits stream is not standard,
different extensions support different features and should not be mixed.
The correct way should be recognize the extension category by profile idc
firstly, and then find the closest profile.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/645>
GstH265FormatRangeExtensionProfile declares the common bits used
for not only format range extensions profiles, but also for several
different h265 extension profiles, such as high throughput, screen
content coding extensions, etc. And So the old name is not proper.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/645>
Following the [design document] encodebin needs to handle sources that
output multiple streams, for that purpose and to make it simpler,
we ensure that a single segment is outputted to the encoders by using
an `identity single-segment=true` at the beginning of streams chains.
Added API to enable or disable the use of that new feature.
Added support for the encoding profile parser for that new property,
keeping backward compatibility
[design document]: https://gstreamer.freedesktop.org/documentation/additional/design/encoding.html?gi-language=c#rendering-timelines
By passing NULL to `g_signal_new` instead of a marshaller, GLib will
actually internally optimize the signal (if the marshaller is available
in GLib itself) by also setting the valist marshaller. This makes the
signal emission a bit more performant than the regular marshalling,
which still needs to box into `GValue` and call libffi in case of a
generic marshaller.
Note that for custom marshallers, one would use
`g_signal_set_va_marshaller()` with the valist marshaller instead.
Since we started depending on GLib 2.44, we can be sure this macro is
defined (it will be a no-op on compilers that don't support it). For
plugins we should just start using `G_DECLARE_FINAL_TYPE` which means we
no longer need the macro there, but for most types in base/gst-libs we
don't want to break ABI, which means it's better to just keep it like it
is (and use the `#ifdef` instead).
Fix the following warnings by adding casts.
gstdiscoverer.c:1801:17: error: format specifies type 'unsigned long' but the argument has type 'off_t' (aka 'long long') [-Werror,-Wformat]
location, file_status.st_size, file_status.st_mtime);
^~~~~~~~~~~~~~~~~~~
gstdiscoverer.c:1801:38: error: format specifies type 'long long' but the argument has type '__darwin_time_t' (aka 'long') [-Werror,-Wformat]
location, file_status.st_size, file_status.st_mtime);
https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/issues/570
g_source_remove() works only for a GSource which was attached
to default GMainContext, but the GSource might be attached to
custom context depending on how gst_discoverer_start() was called.
Whatever the attached context was, g_source_destroy() can clean it up.
ISO 14496-3 defines that audioObjectType 5 is a special case that
indicates SBR is present and that an additional field has to be
parsed to find the true audioObjectType.
There are two ways of signaling SBR within an AAC stream - implicit
and explicit (see [1] section 4.2). When explicit signaling is used,
the presence of SBR data is signaled by means of the SBR
audioObjectType in the AudioSpecificConfig data.
Normally the sample rate is specified by an index into a
table of common sample rates. However index 0x0f is a special case
that indicates that the next 24 bits contain the real sample rate.
[1] https://www.telosalliance.com/support/A-closer-look-into-MPEG-4-High-Efficiency-AACFixes#39
