Summary:
So that the user can easily use the same encoding profile to render
with/without audio/video stream.
API:
gst_encoding_profile_is_disabled
gst_encoding_pofile_set_enabled
https://bugzilla.gnome.org/show_bug.cgi?id=749056
In some cases, the user might want the stream outputted by encodebin to
be in the exact same format during all the stream. We should let the
user specify when this is the case. This commit add some API in the
GstEncodingProfile to determine whether the format can be renegotiated
after the encoding started or not.
API:
gst_encoding_profile_set_allow_dynamic_output
gst_encoding_profile_get_allow_dynamic_output
https://bugzilla.gnome.org/show_bug.cgi?id=740214
Set up a fakesink with a pad probe to replace the missing encoder to detect
if encoding was really required and only error out in this case. Otherwise
just let passthrough branch work.
This delays the error posting from the set_state function to when buffers
are really flowing. Unit test updated accordingly
https://bugzilla.gnome.org/show_bug.cgi?id=650652
This allows getting a pad for a specific encoding profile, which can
be useful when there are several stream profiles of the same type.
Also update the encodebin unit tests so that we check that the returned
pad has the right caps.
https://bugzilla.gnome.org/show_bug.cgi?id=689845
This ensures the ghost pad will not stay in flushing mode
when it receives a flush stop event, and generally behave
badly.
This fixes at least one case of a dynamic decodebin2 + encodebin
pipeline finding a source that has not prerolled when it should
have been (due to the ghostpad staying in flushing mode).
The behaviour is sensibly changed here. Instead of purely falling when a
preset is set on the #GstEncodingProfile, we now make sure that the
element that is plugged corresponds to the one specified as preset. Then,
if we have a preset_name, we use it, if it fails, we fail (we might rather
just keep working even without setting the element properties?)
+ Add tests that it behave correctly
GstId3Mux sink pad is an always (static) pad. Thus releasing it
as if a request pad triggers:
(sound-juicer:11826): GStreamer-CRITICAL **:
gst_element_release_request_pad: assertion `GST_PAD_PAD_TEMPLATE (pad)
== NULL || GST_PAD_TEMPLATE_PRESENCE (GST_PAD_PAD_TEMPLATE (pad)) ==
GST_PAD_REQUEST' failed
https://bugzilla.gnome.org/show_bug.cgi?id=685110
Re-enable parsers in encodebin to allow more passthrough scenarios
to work. Specially the ones that require changing 'stream formats'.
i.e. h264 in mkv to mpegts.
The condition is if the muxer doesn't have tag setter *and* isn't
a formatter itself. Any of those two conditions makes the muxer
good enough to not need a formatter.
Sort muxers based on their caps and ranking before iterating to
find one that fits the profile.
Sorting is done by putting the elements that have a pad template
that can produce the exact caps that is on the profile. For example:
when asking for "video/quicktime, variant=iso", muxers that
have this exact caps on their pad templates will be put first on
the list than ones that have only "video/quicktime".
https://bugzilla.gnome.org/show_bug.cgi?id=651496
As encodebin doesn't connect to the queue signals, it can set
queues to silent mode to make queue not emit them.
Check https://bugzilla.gnome.org/show_bug.cgi?id=621299 for
more info on queue's silent property.
Add a flags property and two flags to allow one to disable the
conversion elements within encodebin. Doing so insists that the
uncompressed input to encodebin for the appropriate stream type is
sufficient to meet the caps requirements of the encoders, muxers and
encodebin target.
This is mostly beneficial to bypass slow caps negotiations in the
conversion elements.
Autoplug formatters for streams if a formatter with secondary or
higher rank is found. Formatters are autoplugged when there is no
muxer or when the muxer doesn't implement the tagsetter interface.
Currently only the first formatter found is plugged, this might
help in lots of cases, but it doesn't solve the
'lamemp3 ! xingmux ! id3mux'
case.
https://bugzilla.gnome.org/show_bug.cgi?id=649841
