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
The spec states that the last byte of a NAL 'shall not' be 0x00
and it is allowed for byte-stream format to add padding 0x00 for
alignment.
So our parser should strip any trailling 0x00.
https://bugzilla.gnome.org/show_bug.cgi?id=721384
The parser assumes that every time there is a 0 before the startcode,
it is part of the startcode. But that's not true.
From the specification
Byte stream NAL unit syntax
zero_byte is a single byte equal to 0x00.
When any of the following conditions are fulfilled, the zero_byte syntax
element shall be present.
– the nal_unit_type within the nal_unit( ) is equal to 7 (sequence parameter
set) or 8 (picture parameter set)
– the byte stream NAL unit syntax structure contains the first NAL unit of an
access unit in decoding order, as specified by subclause 7.4.1.2.3.
The problem with doing this for all startcodes is that a trailing zero can mess
up timestamps. The trailing zero gets prepended to the startcode, which will
carry the PTS and DTS of previous buffer.
https://bugzilla.gnome.org/show_bug.cgi?id=664443
Fix picture level scaling lists derivation from fall-back rule set B,
as specified in 7.4.2.2. More precisely, the sequence level scaling
lists need to be used but intra and inter lists arguments were swapped.
This fixes FRExt/freh5.264 from conformance testing.
https://bugzilla.gnome.org/show_bug.cgi?id=720099
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
We only check input from the API user with g_return_*_if_fail().
Internal sanity checks should use g_assert() instead, which is
disabled by default for releases.
Fix calculation of the frame cropping rectangle, and more precisely
the actual cropped height. The frame_crop_top_offset subtraction
was not scaled up with SubHeightC.
Also clean-up variables to align more with (7-18) to (7-21).
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
Assign the un-cropped width/height to sps->width/sps->height
during sps header parsing. Added new fields to SPS header structure
to provide the crop-rectangle dimensions.
https://bugzilla.gnome.org/show_bug.cgi?id=694068
Add API to parse the Slice header. This also calculates the macroblock
position as specified in 6.3.16.
https://bugzilla.gnome.org/show_bug.cgi?id=664274
Signed-off-by: Sreerenj Balachandran <sreerenj.balachandran@intel.com>
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
Add new interface to MPEG-2 video parser that takes GstMpegVideoPacket
arguments instead of data, size, and offset. New functions are called
after gst_mpeg_video_packet_*() and provide the default implementation.
Older API is moved to the deprecated namespace and uses the new functions.
https://bugzilla.gnome.org/show_bug.cgi?id=692933
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
Ignore the display_extension values if they are greater than the width/height
values provided by seqhdr and calculate the PAR based on the seqhdr values.T
his is what DVD players are doing.
Thanks to "David Schleef <ds@schleef.org>"
https://bugzilla.gnome.org/show_bug.cgi?id=685103
This can be used by parsers to provide pre-parsed information to
downstream elements that would require it (so they can avoid having
to parse the bitstream again).
Add utility functions to convert quantization matrices from zigzag scan
order (as encoded in the bitstream) into raster scan order. Also provide
another function to reverse the operation.
https://bugzilla.gnome.org/show_bug.cgi?id=693000
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
Quantizer matrices are encoded in zigzag scan order in the bitstream,
but they are stored in raster scan order when they are parsed. However,
default matrices were also prepared in zigzag scan order, hence the
mismatch. i.e. the matrices were presented either in raster scan order
if they are explicitly present in the bitstream, or they were presented
in zigzag scan order if the default definitions were to be used instead.
One way to solve this problem is to always expose the quantization
matrices in zigzag scan order, since this is the role of the parser to
not build up stories from the source bitstream and just present what
is in there.
Utility functions will be provided to convert quantization matrices in
either scan order.
https://bugzilla.gnome.org/show_bug.cgi?id=693000
Signed-off-by: Cong Zhong <congx.zhong@intel.com>
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
Fix parsing of residual bytes. This is a two-step process. First,
remaining colums of full vertical resolution (<height>) need to be
processed. Next, remaining bytes in the first row can be processed,
while taking into account the fact that we may have filled in the
first columns already. So, this is not full horizontal resolution.
The following figure helps in understanding the expected order of
operations, for a 8x5 MBs bitplane.
5 5 6 6 6 6 6 6
5 5 1 1 1 2 2 2
5 5 1 1 1 2 2 2
5 5 3 3 3 4 4 4
5 5 3 3 3 4 4 4
So, after tiles 1 to 4 are decoded, vertical tile 5 needs to be
processed (2x5 MBs) and then the horizontal tile 6 (6x1 MBs).
https://bugzilla.gnome.org/show_bug.cgi?id=692461
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
Fix decoding of DIFF6 or NORM6 bitplanes with an odd number of lines
(3x2 "horizontal" tiles). In this case, we have to skip the first line
of macroblocks but <width> number of bytes was used to do so, instead
of the actual <stride> size.
This fixes decoding for the video sample attached to:
https://bugzilla.gnome.org/show_bug.cgi?id=668565https://bugzilla.gnome.org/show_bug.cgi?id=692461
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
Add gst_vc1_parse_slice_header() function to parse slice headers as
described in 7.1.2. Slice layers are optional and allowed in advanced
profile mode only. Picture header, if available (PIC_HEADER_FLAG),
is parsed but not recorded because it shall be the same as that was
previously parsed with gst_vc1_parse_frame_header().
This fixes SA00049.vc1 conformance test.
https://bugzilla.gnome.org/show_bug.cgi?id=692388
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
Fix decoding of DIFF2 or NORM2 bitplanes with an odd number of macroblocks.
In particular, account for the first bit that was already parsed so that to
avoid a buffer overflow after all pairs are parsed.
This fixes SA00040.vc1 conformance test.
https://bugzilla.gnome.org/show_bug.cgi?id=692312
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
Rename dqsbedge to dqbedge. The intent is that we can only have a single
boundary edge selector, depending on the value of dqprofile. So, dqbedge
represents DQSBEDGE if dqprofile == GST_VC1_DQPROFILE_SINGLE_EDGE, or
DQDBEDGE if dqprofile == GST_VC1_DQPROFILE_DOUBLE_EDGE.
The former dqbedge field is marked as unused and can be removed on the
next gst-plugins-bad version that allows ABI changes.
https://bugzilla.gnome.org/show_bug.cgi?id=692272
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
Fix parsing of VOPDQUANT when DQUANT == 2. In particular, DQUANTFRM is
not present in the bitstream in this case and it shall be derived to
the default value of zero (7.1.1.31.1).
https://bugzilla.gnome.org/show_bug.cgi?id=692271
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
Fix calculation of ALTPQUANT when DQUANT == 1. PQDIFF alters ALTPQUANT
in any case. See 7.1.1.31.6.
https://bugzilla.gnome.org/show_bug.cgi?id=692270
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
Fix parse_vopdquant() to correctly parse DQPROFILE, which is 2 bits
instead of a single bit.
https://bugzilla.gnome.org/show_bug.cgi?id=692267
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
The standard specifies that when slice_beta_offset_div2 is not present
in the slice header, then the value of slice_beta_offset_div2 shall be
inferred to be equal to 0.
https://bugzilla.gnome.org/show_bug.cgi?id=692265
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
Coverity found missing break in parse_frame_header_advanced() when
determining PTYPE from FPTYPE for interlaced streams.
https://bugzilla.gnome.org/show_bug.cgi?id=688626
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
gst_h264_parse_sps() returned FALSE if it parsed invalid (negative)
size components. Now make it gracefully return GST_H264_PARSER_ERROR
instead of GST_H264_PARSER_OK (FALSE).
https://bugzilla.gnome.org/show_bug.cgi?id=684568
Change the way the pixel-aspect-ratio is computed by
interpreting the sequence header aspect ratio info
as MPEG-1 values until a sequence extension or
sequence display extension is seen, and then updating
the sequence header struct accordingly.
Fixes incorrect anamorphic display on some MPEG-2 (DVD)
sequences.
ASPECT_HORIZ_SIZE and ASPECT_VERT_SIZE are syntax elements that hold
binary encodings of sizes ranging from 1 to 256. Thus, the calculated
pixel-aspect-ratio was off by one.
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=683858
Anonymous union is an ISO C (2011) feature that is not exposed in
compilers strictly conforming to the previous standard.
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
... to allow for more efficient parsing and (more) consistent parsing API
among various codec parsers.
Fixes#672701.
Conflicts:
gst/videoparsers/gstmpegvideoparse.c
