We need different export decorators for the different libs.
For now no actual change though, just rename before the release,
and add prelude headers to define the new decorator to GST_EXPORT.
Those fields have been introduced in version 2 and later to define new
profiles like the format range extensions profiles (A.3.5).
NOTE: This patch breaks the parser ABI, rebuild needed.
https://bugzilla.gnome.org/show_bug.cgi?id=793876
We used to have the same enum to represent H265 profiles and idc values.
Those are no longer the same with extension profiles defined from
version 2 of the spec.
Split those enums so the semantic of each is clearer and we'll be able
to add extension profiles to GstH265Profile.
Also add gst_h265_profile_tier_level_get_profile() to retrieve the
GstH265Profile from the GstH265ProfileTierLevel. It will be used to
implement the detection of extension profiles.
https://bugzilla.gnome.org/show_bug.cgi?id=793876
There is nothing in the spec that state that framerate is not valid in
that case. This aligns GStreamer with FFMPEG behaviour for similar
streams.
https://bugzilla.gnome.org/show_bug.cgi?id=793284
According to the vp8 spec, the first partition (size can be derived from
the frame header) should have all compressed header information and we
implemented gst codecparser based on that. But it doesn't seem to be the
case with some of the streams (#792773) and libvpx
works fine because it uses the whole frame size (not the first partition
size) to initialize the bool decoder.
https://bugzilla.gnome.org/show_bug.cgi?id=792773
Libraries in -bad are not covered by our API/ABI stability
guarantees, and to the best of our knowledge everyone using
this API has moved to the replacement APIs ages ago.
'extern inline' was added in 2fb76c89 for MSVC (it was just
'inline' before), but all of this doesn't really make sense,
the functions are not going to be inlined anyway, and what
'extern inline' means exactly also appears to depend on the
Cxx standard targetted. Let's just remove the 'extern inline'
entirely. At least gcc6 still emits the exact same code as
before anyway. Fixes compilation/linking with gcc 4.8 as
used on L4T on the TK1.
https://github.com/mesonbuild/meson
With contributions from:
Tim-Philipp Müller <tim@centricular.com>
Matej Knopp <matej.knopp@gmail.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.
The subsampling_x, subsampling_y, bit_depth, color_space and color_range
fileds are moved from GstVp9FrameHdr to the global GstVp9Parser structure.
These fields are only present in keyframe or intra-only frame, no need to
duplicate them for inter-frames. This is an ABI change.
https://bugzilla.gnome.org/show_bug.cgi?id=764370
This is a regression from since mpegvideoparser was switched to
use the codecparsing library.
The problem is that the high bit of the profile_and_level is used
to specify non-hierarchical profiles and levels. Unfortunately we
were discarding that information.
Expose that escape bit, and use it in the element
https://bugzilla.gnome.org/show_bug.cgi?id=763220
H.265 7.4.7.1 says:
> When slice_deblocking_filter_disabled_flag is not present, it is
> inferred to be equal to pps_deblocking_filter_disabled_flag.
https://bugzilla.gnome.org/show_bug.cgi?id=762351
Initialize to 0 these parse structures before filling them: GstH264SEIMessage,
GstH264NalUnit, GstH264PPS, GstH264SPS and GstH264SliceHdr.
When calling the functions which fill those structures, they may fail, leaving
unitialized those structures. This situation may lead to future problems, such
as a segmentation fault when freeing, for example.
This patch initializes to zero these structures, before filling them.
https://bugzilla.gnome.org/show_bug.cgi?id=755161
Initialize to 0 these parse structures before filling them: GstH265SEIMessage,
GstH265NalUnit, GstH265VPS, GstH265PPS, GstH265SPS and GstH265SliceHdr.
When calling the functions which fill those structures, they may fail, leaving
unitialized those structures. This situation may lead to future problems, such
as a segmentation fault when freeing, for example.
This patch initializes to zero these structures, before filling them.
https://bugzilla.gnome.org/show_bug.cgi?id=755161
If short_term_ref_pic_set_sps_flag is FALSE, the ShortTermRefPicSet
structure is supposed to derive from slice header. Which means,
CurrRpsIdx is equal to num_short_term_ref_pic_sets. But the number
of refpicsets communicated via sps header is only num_short_term_ref_pic_sets - 1.
And we are using slice_header structure to reference the last entry, which is
ShortTermRefPicSet[num_short_term_ref_pic_sets].
https://bugzilla.gnome.org/show_bug.cgi?id=754834
