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
A deadlock can happen when the source sends EOS when
being put to NULL as the object lock is being held by the
thread that sets the element to NULL and is needed by
the event handler.
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>
While it was a great idea, various g-i based bindings don't support
GArray with entries greater than sizeof(gpointer) :(
So let's just make everybody happy by just using GPtrArray.
And since we're breaking the API, also rename the various descriptor fields
to no longer have the descriptor_ prefix.
It does cost a bit more in terms of memory/cpu usage, but makes it usable
from bindings.
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.
* Avoid repeating code everywhere, and instead provide all parsing
information in one go.
* Add BAT support
* Refine BAT/CAT identification (by adding PID checks)
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
Cancelled is a 'permanent' state of the uridownloader and is only
removed by a call to _reset. When a download fails we just want to
return NULL on the fetch function and leave the downloader ready
for another fetch, otherwise the user has to call _reset after
failed downloader, even when it didn't call _cancel.
Due to the variety of section types out there, we need to add
some checks when identifying section types.
We check here that the PID is also consistent with the table_id.
The size checks were wrong. The smallest size for a NIT is 16 bytes
(12 for the smallest content + 4 for crc) and the smallest size for
a inner stream loop is 6 bytes (without any descriptors).
Also remove FIXME that has already moved elsewhere
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>
