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
