Expose SEI data in the H.264 bitstream parser API and
extract closed captions and other things that are not
specified in the H.264 spec itself in the videoparser.
Based on patch by: Mathieu Duponchelle <mathieu@centricular.com>
https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/issues/940
* Add FIXME for future correction of HRDParames parsing.
Spec. defines that the number of HRDParames could be up to
"vps_num_layer_sets_minus1 + 1" (i.e., 1024).
* Add parsing vps_base_layer_{internal,available}_flag.
* Fix possible invalid vps_extension parsing.
Fixes#798
For each lib we build export its own API in headers when we're
building it, otherwise import the API from the headers.
This fixes linker warnings on Windows when building with MSVC.
The problem was that we had defined all GST_*_API decorators
unconditionally to GST_EXPORT. This was intentional and only
supposed to be temporary, but caused linker warnings because
we tell the linker that we want to export all symbols even
those from externall DLLs, and when the linker notices that
they were in external DLLS and not present locally it warns.
What we need to do when building each library is: export
the library's own symbols and import all other symbols. To
this end we define e.g. BUILDING_GST_FOO and then we define
the GST_FOO_API decorator either to export or to import
symbols depending on whether BUILDING_GST_FOO is set or not.
That way external users of each library API automatically
get the import.
While we're at it, add new GST_API_EXPORT in config.h and use
that for GST_*_API decorators instead of GST_EXPORT.
The right export define depends on the toolchain and whether
we're using -fvisibility=hidden or not, so it's better to set it
to the right thing directly than hard-coding a compiler whitelist
in the public header.
We put the export define into config.h instead of passing it via the
command line to the compiler because it might contain spaces and brackets
and in the autotools scenario we'd have to pass that through multiple
layers of plumbing and Makefile/shell escaping and we're just not going
to be *that* lucky.
The export define is only used if we're compiling our lib, not by external
users of the lib headers, so it's not a problem to put it into config.h
Also, this means all .c files of libs need to include config.h
to get the export marker defined, so fix up a few that didn't
include config.h.
This commit depends on a common submodule commit that makes gst-glib-gen.mak
add an #include "config.h" to generated enum/marshal .c files for the
autotools build.
https://bugzilla.gnome.org/show_bug.cgi?id=797185
It is completely legal to have packets with zero sizes.
Zero-sized packet indicates header with only Start Code.
One eg: is user data packet. The patch allows having
GstMpegVideoPacket with zero sizes.
https://bugzilla.gnome.org/show_bug.cgi?id=796477
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
Section 6.5.1: Coding tree block raster and tile scanning conversion process
Follow the equations 6-3 and 6-4
This will provide correct offset_max in slice_header for parsing
num_entry_point_offsets.
https://bugzilla.gnome.org/show_bug.cgi?id=754024
Signed-off-by: Sreerenj Balachandran <sreerenj.balachandran@intel.com>
As per 7-42 and 7-43 the ScalingFactor's scanIdx is 0,
which is "up-right-diagonal" scan. Add APIs for converting
up-right-diagonal to raster and vise versa.
https://bugzilla.gnome.org/show_bug.cgi?id=754024
Being more strict on specification, According to 7.4.7.3,
delta_chroma_log2_weight_denom should be in the range of
[(0 - luma_log2_weight_denom), (7 - luma_log2_weight_denom)]
https://bugzilla.gnome.org/show_bug.cgi?id=754024
The SPS struct might be filled out by a call to
gst_h264_parser_parse_subset_sps, which fills out
dynamically allocated data and requires a call
to gst_h264_sps_clear() to free it. Also make sure
to clear out any allocated SPS data when returning
an error.
https://bugzilla.gnome.org/show_bug.cgi?id=753306
ChromaLog2WeightDenom = luma_log2_weight_denom + delta_chroma_log2_weight_denom
The value of ChromaLog2WeightDenom should be in the range of 0 to 7 and
the value luma_log2_weight_denom should be also in the range of 0 to 7.
Which means , delta_chroma_log2_weight_denom can have values in the range
between -7 and 7.
https://bugzilla.gnome.org/show_bug.cgi?id=753552
- add data pointer to GstJpegSegment and pass segment
to all parsing functions, rename accordingly
- shorten GstJpegMarkerCode enum type name to GstJpegMarker
- move function gtk-doc blurbs into .c file
- add since markers
- flesh out docs for SOF markers
https://bugzilla.gnome.org/show_bug.cgi?id=673925
Fix scan for next marker code when there is an odd number of filler
(0xff) bytes before the actual marker code. Also optimize the loop
to execute with fewer instructions (~10%).
This fixes parsing for Spectralfan.mov.
The size of a marker segment is defined to be exclusive of any initial
marker code. So, fix the size for SOI, EOI and APPn segments but also
the size of any possible segment that is usually "reserved" or not
explicitly defined.
https://bugzilla.gnome.org/show_bug.cgi?id=707447
Switch the increment of markersize from when it is used to when it is
returned from compute_resync_marker_size.
This also makes the CHECK_REMAINING in gst_mpeg4_parse_video_packet_header
check for the actually required number of bits now and not one too few.
https://bugzilla.gnome.org/show_bug.cgi?id=739345
This reverts commit 916b954315.
Clearly something else was intended, and it also makes
more sense to add the extra bit. The resync marker is
N zero bits plus a 1 bit, and the pattern/mask needs to
be run on N+1 bits too.
(Even after the rever the code doesn't do that of course, so
it still needs to be fixed differently.)
https://bugzilla.gnome.org/show_bug.cgi?id=739345
The EOS and EOB nals have the size 2 which is the size of
nal unit header itself. The gst_h265_parser_identify_nalu()
is not required to scan start code again in this case.
In other cases, for a valid nalunit the minimum required size
is 3 bytes (2 byte header and at least 1 byte RBSP payload)
Skip the byte alignment bits as per the logic of byte_alignment()
provided in hevc specification. This will fix the calculation of
slice header size.
https://bugzilla.gnome.org/show_bug.cgi?id=747613
READ_UE_ALLOWED was almost exclusively used with min == 0, which doesn't
make much point for unsigned integers.
Add a READ_UE_MAX variant and use that instead. Also replaced two usages
of CHECK_ALLOWED (a,0,something) by CHECK_ALLOWED_MAX (a, something)
Ensure that we do not trust the bitstream when filling a table
with a fixed max size.
Additionally, the code was not quite matching what the spec says:
- a value of 3 broke from the loop before adding an entry
- an unhandled value did not add an entry
The reference algorithm does these things differently (7.3.3.1
in ITU-T Rec. H.264 (05/2003)).
This plays (apparently correctly) the original repro file, with
no stack smashing.
Based on a patch and bug report by André Draszik <git@andred.net>
Identify SVC NAL units and tag them as such. This is necessary for
gst_h264_parser_parse_slice_hdr() to fail gracefully, if the user
did not perform the check himself.
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
Fix copy-paste error in gst_h264_sps_mvc_copy() where num_anchor_refs_l0
and num_non_anchor_refs_l0 were incorrectly initialized from list1.
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
Always set a default NALU extension type, and override it
when we find a supported extension, to avoid having it unset/random
for unsupported NALU extensions
This parses the frame_packing_arragement() payload in SEI message.
This information can be used by decoders to appropriately rearrange the
samples which belong to Stereoscopic and Multiview High profiles.
https://bugzilla.gnome.org/show_bug.cgi?id=685215
Signed-off-by: Sreerenj Balachandran <sreerenj.balachandran@intel.com>
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
In simple profile, level set to 0 or 2 indicate low and medium level
respectively. In main profile, level set to 0, 2 or 4 indicate low,
medium and high level respectively.
Level values are defined in Annex J.1.2 of the SMPTE 421M.
https://bugzilla.gnome.org/show_bug.cgi?id=738230
sequence-layer is serialized in little-endian byte order except for
STRUCT_C which is serialized in big-endian byte order.
But since STRUCT_A and STRUCT_B fields are defined as unsigned int msb
first, we have to pass them as big-endian to their parsing function. So
we basically use temporary buffers to convert them in big-endian.
See SMPTE 421M Annex J and L.
https://bugzilla.gnome.org/show_bug.cgi?id=736871
Otherwise pic timing structure can have invalid cpb_removal_delay,
dpb_output_delay or pic_struct_present_flag which are blindly retrieved
in h264parse.
https://bugzilla.gnome.org/show_bug.cgi?id=734124
The vlc table members cbits, cword and values were assigned in the wrong
order, causing the mpeg4 parser to fail when handling sprite
trajectories.
https://bugzilla.gnome.org/show_bug.cgi?id=733322
Fix documentation for GstH264NalUnit. The @ref_idc part was totally
unbalanced. Also add a note about @offset and @size fields to remind
that this is relative to the start of the NAL unit, thus including
the header bytes.
An end_of_seq() [EOSEQ] or end_of_stream() [EOS] NAL unit is really
one byte long because this shall include the NalHeaderBytes (1) too.
The NALU.offset starts from the first byte of the header.
This is the proper fix to commit d37f842. In practice, this fixes
parsing of FRExt1_Panasonic_D and FRExt2_Panasonic_C, that include
additional frames after an EOSEQ.
https://bugzilla.gnome.org/show_bug.cgi?id=732553
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
The gst_h264_parse_pps() function dynamically allocates the slice
group ids map array, so that needs to be cleared before parsing a
new PPS NAL unit again, or when it is no longer needed.
Likewise, a clean copy to the internal NAL parser state needs to be
performed so that to avoid a double-free corruption.
https://bugzilla.gnome.org/show_bug.cgi?id=707282
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
The recovery point SEI message helps a decoder in determining if the
decoding process would produce acceptable pictures for display after
the decoder initiates random access or after the encoder indicates
a broken link in the coded video sequence.
This is not used in the h264parse element, but it could help debugging.
https://bugzilla.gnome.org/show_bug.cgi?id=723380
Add nal_reader_skip_long() helper function to allow an arbitrary number
of bits to be skipped. The former nal_reader_skip() function is too
limited to the actual cache size.
Use this new function to simplify gst_h264_parser_parse_sei_message()
default case, that skips unsupported payloads.
v2: made args consistent from header to source file.
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
Use the first _gst_reserved[] slot to hold the built-in range decoder
private data. The first slot was formerly the buffer size, which was
then promoted to semi-public namespace when it got integrated as git
commit 2940ac6.
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
Fix routine names for zigzag/raster scan order conversion routines for
quantization matrices. This ought to use the gst_h264_quant_matrix_*()
naming convention instead of gst_h264_video_quant_matrix_*(), which
derived from the MPEG-2 function names.
https://bugzilla.gnome.org/show_bug.cgi?id=731524
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
Fix MPEG-4 and VP8 APIs to export their external symbols as pure C
symbols, i.e. un-mangled for C++.
https://bugzilla.gnome.org/show_bug.cgi?id=731522
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
Add a new function to calculate video stream framerate which rely on
SPS, slice header and pic timing using formula:
time_scale 1 1
fps = ----------------- x --------------- x ------------------------
num_units_in_tick DeltaTfiDivisor (field_pic_flag ? 2 : 1)
See section E2.1 of H264 specification for definition of variables.
https://bugzilla.gnome.org/show_bug.cgi?id=723352
When parsing slice groups information for slice_group_map_type = 2, we
should only be reading up to num_slice_groups_minus1 groups since there
is always a "leftover" slice group and as many "foreground" slice groups
as needed.
This fixes parsing for SVCBMT-5 and SVCBMT-12 whereby the base layer would
have incorrectly been parsed to have up to 38 reference frames in list0,
which is not possible.
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
When useDefaultScalingMatrixFlag is computed to be 1 while parsing
scaling_list(), then the scaling list shall be inferred to be equal
to the default list (7.4.2.1.1.1). That default list is really one
of Default_4x4_{Intra,Inter} or Default_8x8_{Intra,Inter} and not
one from fall-back rule sets A or B.
This fixes parsing for FRExt1_Panasonic_D, FRExt2_Panasonic_C,
FRExt3_Panasonic_E and FRExt4_Panasonic_B.
https://bugzilla.gnome.org/show_bug.cgi?id=724518
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
Import libvpx 1.3.0 range decoder files (dboolhuff.[ch]) to implement
the VP8 utilities native interface. Likewise, copy and use the default
libvpx generated entropy probabilities tables.
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
The idr_pic_id syntax element depends on IdrPicFlag, which is a calculated
value that does not only depend on NAL unit type (IDR), but possibly also
on MVC non_idr_flag syntax element.
The computed idr_pic_flag is already stored in GstH264NalUnit structure.
https://bugzilla.gnome.org/show_bug.cgi?id=721772
Signed-off-by: Li Xiaowei <xiaowei.a.li@intel.com>
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
Split seq_parameter_set_data() parsing off gst_h264_parse_sps() so
that it could be re-used later on.
https://bugzilla.gnome.org/show_bug.cgi?id=685215
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
Add missing NAL unit types. They are mostly related to alpha blending,
scalable video coding extensions (SVC, Annex.G), and multiview video
coding extensions (MVC, Annex.H).
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
Fix build when GST_DISABLE_GST_DEBUG is not defined. Use a switch
statement to dispatch to the various SEI payload handlers.
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
The payloadSize does not account for emulation prevention bytes. So,
just use nal_reader_skip() for skipping payload_size bits. It should
be possible to further optimize this code since the NAL reader shall
be aligned to byte boundary already.
Kill the now unused nal_reader_skip_to_next_byte() function.
https://bugzilla.gnome.org/show_bug.cgi?id=726829
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
Fix parsing of buffering_period() SEI messages. The number of bits
used to express {nal,vcl}_initial_cpb_removal_delay{,_offset} syntax
elements is not 5 but 1 + initial_cpb_removal_delay_length_minus1.
https://bugzilla.gnome.org/show_bug.cgi?id=726828
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
Account for trailing zero bits when checking for rbsp_more_data().
In particular, fix an hypothetical stream whereby rbsp_more_data()
is called in the following conditions for PPS header: NalReader
reached position 20, 12 bits are remaining and trailing data at
current byte position is c8 00.
rbsp_more_data() used to return TRUE whereas it should obviously
return FALSE because x8 00 represents a valid rbsp_trailing_bits()
structure.
https://bugzilla.gnome.org/show_bug.cgi?id=685890
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
An SEI RBSP could contains more than one SEI message as specified in
7.4.2.3.1.
This commit change the parser API: the gst_h264_parser_parse_sei()
function now create and fill a GArray containing GstH264SEIMessage.
https://bugzilla.gnome.org/show_bug.cgi?id=721715
