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>
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>
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.
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
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>
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
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>
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
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
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>
Some hardware video decode acceleration API (VA-API, DXVA) require
a bit count to the first macroblock, minus the number of emulation
prevention bytes. So, instead of having the consumer of the library
scan the slice_header() again, just record that number while parsing.
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=671203
The entries were not filled in linearly and the termination was not
recorded either. Now, the actual number of modifications is recorded
similarly to dec_ref_pic_marking(). i.e. an explicit counter instead
of storing the termination value in the array.
https://bugzilla.gnome.org/show_bug.cgi?id=668192
This is useful for cases where the caller *knows* that the provided
input contains a whole NALU and can therefore avoid:
* the expensive checks for the next start code (which won't be present)
* delaying the input parsing (since we would need the next incoming NALU
in order for the parsing code to detect the next start code)
https://bugzilla.gnome.org/show_bug.cgi?id=665584
