The caps put into the stream topology by decodebin are the caps at the
moment the pads are exposed on it. This is usually before decoders
received any buffers.
In discoverer we however wait for pre-roll, which ensures that each
decoder handled buffers already. At this point, there might be more
information known about the caps already that we could make use of.
One example here is extra information stored in the SEI of H264, like
the multiview-mode. This will be known if there is a SEI before the
first keyframe, but decodebin won't put this into the topology as it
only waits for the initial caps of h264parse (which come directly after
SPS/PPS).
With this change, the multiview-mode is in the caps reported by
discoverer in many cases.
The caps might not be fixated (which is required by GstVideoInfo) and we
would assert otherwise. However the caps often contain useful
information in the already-fixed parts that we can use here.
https://github.com/mesonbuild/meson
With contributions from:
Tim-Philipp Müller <tim@centricular.com>
Jussi Pakkanen <jpakkane@gmail.com> (original port)
Highlights of the features provided are:
* Faster builds on Linux (~40-50% faster)
* The ability to build with MSVC on Windows
* Generate Visual Studio project files
* Generate XCode project files
* Much faster builds on Windows (on-par with Linux)
* Seriously fast configure and building on embedded
... and many more. For more details see:
http://blog.nirbheek.in/2016/05/gstreamer-and-meson-new-hope.htmlhttp://blog.nirbheek.in/2016/07/building-and-developing-gstreamer-using.html
Building with Meson should work on both Linux and Windows, but may
need a few more tweaks on other operating systems.
parsed, framed, stream-format and alignment are only relevant for parsers and
should not matter here. We still want to be able to use an encoder that can
only output byte-stream if the input was avc.
https://bugzilla.gnome.org/show_bug.cgi?id=768566
Caps are cleaned up for missing plugins, and for creating encoding profiles
and caps descriptions.
Fields like streamheader, parsed, framed, stream-format and alignment are not
relevant here. The last ones all because a parser will take care of them.
https://bugzilla.gnome.org/show_bug.cgi?id=768566
If we e.g. have AVI with DV container with video/audio inside the DV
container, we can't handle this at this point with an encoding profile.
Instead of erroring out, flatten the container hierarchy.
https://bugzilla.gnome.org/show_bug.cgi?id=765708
When converting discoverer output to an encoding profile, it makes sense to
omit these. It's very very unlikely that our encoder is going to produce bit
by bit the same codec_data or streamheader.
https://bugzilla.gnome.org/show_bug.cgi?id=765534
The function gst_discoverer_info_copy doesn't copy the data members seekable
and result of the source GstDiscovererInfo.
In the case of copying a GstDiscovererInfo for later use, the seekbale will be
undefined, which in practice usually will be false, even though the seekable of
the original GstDiscovererInfo is true.
https://bugzilla.gnome.org/show_bug.cgi?id=762710
Base class type name should not reference libvisual since not all child
elements use this. This was an oversight when merging audiovisualizers into
a common base class.
When we run the loop for another time and do not have a preset name, we would
try to print the preset name of a previous iteration that is already freed.
Also move some other variables into the block where they are actually used
to prevent similar mistakes in the future.
CID 1346536
Some Opus files found on the wild have 0 in the version field of the
OpusHead header, instead of the correct value of 1. The files still
play, don't make this error fatal.
https://bugzilla.gnome.org/show_bug.cgi?id=758754
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
[API] gst_discoverer_info_to_variant
[API] gst_discoverer_info_from_variant
[API] GstDiscovererSerializeFlags
+ Serializes as a GVariant
+ Adds a test
+ Does not serialize potential GstToc (s)
https://bugzilla.gnome.org/show_bug.cgi?id=748814
gst_message_parse_toc() returns a reffed GstToc which is owned by the
GstDiscovererInfo. But we have to make sure we unref its previous value before
setting the new one.
https://bugzilla.gnome.org/show_bug.cgi?id=747103
This reverts commit 19b9356680.
These two "profiles" are actually a complete set of profiles, which we will
need to handle separately. Unfortunately it seems like we need information
from the SPS to detect the exact profile.
The new gst_install_plugins_context_set_confirm_search() API can be used
to pass a hint to modify the behaviour of the external installer
process.
https://bugzilla.gnome.org/show_bug.cgi?id=744465
The new gst_install_plugins_context_set_desktop_id() and
gst_install_plugins_context_set_startup_notification_id() API can be
used to pass extra details to the external installer process.
https://bugzilla.gnome.org/show_bug.cgi?id=744465
These values are for now taken from x265 and need to be checked against
the spec. Especially we need to check if information from other fields
need to be taken into consideration too, e.g. the bit depth and chroma
index from the SPS.
This however makes 4:4:4 output of x265enc actually work.
The gst_discoverer_info_get_missing_elements_installer_details()
documentation and annotation says that the return value should be freed
with g_strfreev(), but actually it's owned by the GstDiscovereInfo
object and should definitely not get freed by the caller as well.
https://bugzilla.gnome.org/show_bug.cgi?id=742006
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
This avoids a race where we would get new tag but we are already
prerolled and analyzing results.
It is the way it is supposed to be handled as stated in comment:
"If preroll is complete, drop these tags - the collected information is
possibly already being processed and adding more tags would be racy"
Otherwize the pipeline would be in an wrong state and on the next
iteration any kind of error could happen
Everytime an error happens in a pipeline the application has to set the
pipeline back to NULL instead of READY.
https://bugzilla.gnome.org/show_bug.cgi?id=733976
Recognize H.264 Level 5.2, as exposed by modern 2160p30+ streams,
i.e. commonly known as 4K. Also add initial support for handling
Annex.G (SVC) profiles.
https://bugzilla.gnome.org/show_bug.cgi?id=732269
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
Currently the API is far from optimal and the user has to work around
our badly defined API to simply install missing plugins.
API:
new:
gst_discoverer_info_get_missing_elements_installer_details
deprecated:
gst_discoverer_info_get_misc
gst_discoverer_stream_info_get_misc
https://bugzilla.gnome.org/show_bug.cgi?id=720596
