MSVC warns about this because it's a C++ compiler, and this actually
results in useful things such as the incorrect 'gboolean' return value
for functions that return GstFlowReturn, so let's do explicit
conversions to reduce the noise and increase its efficacy.
When skipping data, check if they are filler bytes. If so, drop the
data instead of skipping. We don't want to output filler bytes, but they
shouldn't cause a discontinuity.
https://bugzilla.gnome.org/show_bug.cgi?id=768125
If the input alignment claims AU alignment, each received
buffer should contain a complete video frame, so never hold over parts
of buffers for later processing. Also reduces latency, as packets
are parsed/converted and output immediately instead of 1 buffer
later.
Fixes a problem where an (arguably disallowed) padding byte on the
end of a buffer is detected as an extra byte in the following
start code, and messes up the timestamping that should apply to
that start code.
We get into this code path if the profile is already constrained-baseline and
downstream does not support constrained-baseline. So we should try baseline
and the other compatible profiles.
https://bugzilla.gnome.org/show_bug.cgi?id=764448
The parser handles the downstream force-key-unit event incorrectly,
it tries to parse it as an upstream force-key-unit event, does not
check the return value, and then uses uninitialized memory in
"all_headers" boolean variable.
https://bugzilla.gnome.org/show_bug.cgi?id=763793
Enabling passthorugh mode is causing multiple issue:
For nal aligned multiresoluton streams, passthrough mode
make h264parse unable to advertise the new resoultions.
Also causing issues while parsing MVC streams which have two
separate layers (base-view and non-base-view).
This fix is only a temporary workaround.
For MVC, proper fixes needed in many places:
(handle prefix nal unit, handle non-base-view slice nal extension,
fix the picture_start detection for multi-layer-mvc streams etc)
https://bugzilla.gnome.org/show_bug.cgi?id=758656
Since commit b77f8e172a the new value
assigned to mview_mode hasn't been used. That commit changed the following
"if" check to an "else if", which means the original value of mview_mode
is used.
When converting from avc to byte-stream, there will not be any codec_data
in the src caps. Remove it before the equality check to avoid sending caps
events downstream on every SPS/PPS change.
https://bugzilla.gnome.org/show_bug.cgi?id=761014
If we have a stream that contains an unchanging SPS/PPS for every video frame,
we don't need to to constantly query downstream for it's supported caps if the
current caps are compatible with the negotiated caps.
https://bugzilla.gnome.org/show_bug.cgi?id=761014
This is to support byte-stream decoder that does not remember the
PPS/SPS after a flush. This is not needed by all decoders, but is
harmless for those that do remember.
https://bugzilla.gnome.org/show_bug.cgi?id=758405
As it's recursive, gst_pad_get_allowed_caps() may also return
empty for anything incompatible downstream. EMPTY is not valid caps
value for gst_caps_fixate(). This lead to assertion and then crash.
Ideally, the negotiate function should be re-factored to have a return
value, and we could make the negotiation fails earlier.
https://bugzilla.gnome.org/show_bug.cgi?id=754122
The SPS struct might be filled out by a call to
gst_h264_parser_parse_subset_sps, which fills out
dynamically allocated data and requires a call
to gst_h264_sps_clear() to free it. Also make sure
to clear out any allocated SPS data when returning
an error.
https://bugzilla.gnome.org/show_bug.cgi?id=753306
Don't throw away AU delimiter(s) that precede the SPS/PPS. Should
fix MPEG-TS playback on iOS/Quicktime when muxing streams that
already have AU delimiters.
See https://bugzilla.gnome.org/show_bug.cgi?id=736213 for getting
h264parse to insert AU delimiters when they don't already
exist.
Move the pixel-aspect-ratio calculations higher up in caps
determination, so the results are available for a call to
gst_video_multiview_guess_half_aspect() when stereoscopic video
is detected.
Wait until at least one keyframe has been parsed before
deciding to switch to passthrough mode, in case the
stream contains SEI messages that supplement the output
caps - for example by providing stereoscopic information
Like SPS/PPS they do contain information which will be needed to
decode the following data (as per definition of the flag)
Also ensures that the series of SPS/PPS/SEI NALU before a keyframe
can be considered as one contiguous header
Don't use the apis in codec-utils to extract the profile and level
syntax elements since it is wrong if there are emulation prevention
bytes existing in the byte-stream data.
https://bugzilla.gnome.org/show_bug.cgi?id=747613
The detection for missing format/alignment is done way before this
codepath is reached (at which point we have already decided of a
format and alignment).
CID #1232800
This prevents it from going into passthrough after receiving 2
byte-stream caps (different ones) as it would keep the have_pps and
have_sps set to true and would just go into passthrough without
updating its caps.
This patch makes it reset its stream information to restart properly
when new caps are received.
https://bugzilla.gnome.org/show_bug.cgi?id=745409
This patch calls gst_h264_parser_parse_subset_sps() when a
SPS subset NAL type is found.
All the bits required for parsing the SPS subset in NALs were
already there, just we need to call them when the this NAL type
is found.
With this parsing, the number of views (minus 1) attribute is
filled, which was a requirement for negotiating the stereo-high
profile.
https://bugzilla.gnome.org/show_bug.cgi?id=743174
Initial support for MVC NAL units. It is only needed to propagate the
complete set of NAL units downstream at this time.
https://bugzilla.gnome.org/show_bug.cgi?id=696135
Signed-off-by: Sreerenj Balachandran <sreerenj.balachandran@intel.com>
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
Some video bitstreams report a too restrictive set of profiles. If a video
decoder was to strictly follow the indicated profile, it wouldn't support that
stream, whereas it could in theory and in practice. So we should relax the
profile restriction for allowing the decoder to get connected with parser.
https://bugzilla.gnome.org/show_bug.cgi?id=739992
Some video bitstreams report a too restrictive set of profiles. If a video
decoder was to strictly follow the indicated profile, it wouldn't support that
stream, whereas it could in theory and in practice. So we should relax the
profile restriction for allowing the decoder to get connected with parser.
https://bugzilla.gnome.org/show_bug.cgi?id=739992
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>
Or not negotiated in the case we would be actually not negotiated
Currently we are getting assertions from
gst_pb_utils_add_codec_description_to_tag_list because of NULL
caps.
https://bugzilla.gnome.org/show_bug.cgi?id=737186
Do more elaborate validation of the input caps: what fields
are required and/or not allowed. Don't assume AVC3 format
input without codec_data field is byte-stream format. Fix
up some now-unreachable code (CID 1232800).
It should try to use bytestream in these cases that the format
is set to _FORMAT_NONE as it seems that is what the 'else' clause
for bytestream can handle (by defaulting to _FORMAT_BYTESTREAM).
Always use a GstAdapter when collecting access units (alignment="au")
in either byte-stream or avcC format. This is required to properly
preserve config headers like SPS and PPS when invalid or broken NAL
units are subsequently parsed.
More precisely, this fixes scenario like:
<SPS> <PPS> <invalid-NAL> <slice>
where we used to reset the output frame buffer when an invalid or
broken NAL is parsed, i.e. SPS and PPS NAL units were lost, thus
preventing the next slice unit to be decoded, should this also
represent any valid data.
https://bugzilla.gnome.org/show_bug.cgi?id=732203
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
