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
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>
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
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>
This always happens with GstByteReader/Writer and friends when
not taking into account returned boolean of the _read/_write functions
(which is actually wrong).
Make use of the *_unchecked variant as much as possible, or take the
returned value into account.
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
When vui->timing_info_present is 0, vui->fixed_frame_rate_flag and others
cannot be accessed since they have not been set.
It was also possible that sps->fps_{num,den} end up initialized here.
