Coverity found missing break in parse_frame_header_advanced() when
determining PTYPE from FPTYPE for interlaced streams.
https://bugzilla.gnome.org/show_bug.cgi?id=688626
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
Right now decodebin will concider the pad template caps as fixed and if a decoder
has restriction on for example height/width it won't be autoplugged because
gst_caps_is_subset fails as those fields are missing from the pad template caps.
We fix the issue here making sure that the pad caps are fixed using data from
the stream.
Also reset segment info and drop the segment event when demuxer is
flushed.
Restore demuxer segment with the info stored in base when demuxer is
going to push data again if needed.
Drop code to recover the segment info from base in the initial program
becauses it's superseded by the new code.
Ensure the chain is not running before reset the state to avoid race
conditions and random corruptions downstream.
Also fixes segfaults in the packetizer due wrong available values that
causes gst_adapter_map to return a NULL pointer.
This reverts commit e14e310f71.
Would be better move the packetizer flushing to FLUSH_STOP and avoid
the race that way. Without introducing a memory barrier that could
have impact in the performance.
When dealing with non-time based push-mode streams, we need to revert
to using the offset-based PCR/PTS estimation logic of packetizer.
This solves uses cases such as:
pushfile:// ! tsdemux
src ! queue ! tsdemux
https://bugzilla.gnome.org/show_bug.cgi?id=687178
gstpyramidsegment.c: In function 'gst_pyramid_segment_chain':
gstpyramidsegment.c:307:3: error: implicit declaration of function
'cvPyrSegmentation' [-Werror=implicit-function-declaration]
gstpyramidsegment.c:307:3: error: nested extern declaration of
'cvPyrSegmentation' [-Werror=nested-externs]
https://bugzilla.gnome.org/show_bug.cgi?id=687237
The OpenSL ES spec defines:
An implementation shall enable creation of at least one such object, but
attempting to create more instances (either by a single application or by
several different applications) may fail.
