According to S377-1-2009c 9.2 the local tags must not be resolved from the
primer pack, which as a result means that there can't be any other tags than
statically assigned ones.
0x04 signifies a MPEG elementary stream but according to RP2008, 0x10 should
be used for a h264 byte-stream. This also fixes compatibility of our files
with ffmpeg.
Free the existing descriptor array, if any, before replacing it.
Fix leaks with the
validate.file.playback.scrub_forward_seeking.test-mpeg2-mp3_mxf scenario.
https://bugzilla.gnome.org/show_bug.cgi?id=748580
Reset the internal segment before freeing it.
mxf_index_table_segment_parse() allocates data inside the segment
(like segment->delta_entries) which have to be freed using
mxf_index_table_segment_reset().
https://bugzilla.gnome.org/show_bug.cgi?id=746803
Value stored in ret will be ovewritten in the next iteration of the loop. Which
means it is never used.
Plus a style issue to make gst-indent happy and allow the commit.
There are unnecessary definitions for disabling deprecation warnings.
Since GLIB_DISABLE_DEPRECATION_WARNINGS is not needed anymore in these files,
removing the same.
https://bugzilla.gnome.org/show_bug.cgi?id=737559
Testing mpegversion when mpegaudioversion was likely meant.
Similar tests in sys/androidmedia/gstamcaudiodec.c also test
mpegaudioversion with the same conditional code.
Coverity 206071
This component is dereferenced, and later code checking for
NULL in particular cases implies it can be NULL. This likely
does not fix the coverity warning as it was seeing another
path setting component to NULL explicitely, but this was
spotted by looking at:
Coverity 1139736
Which is actually OK from what I can see since the actual
dereference of the explicit NULL pointer will not happen
if the condition that led to the NULL pointer assignment
is met, since the assignment and defeference have mutually
exclusive tests.
Fixes multiple seeking issues. When doing ACCURATE or normal
non-KEYUNIT seeks, mxfdemux would just send data from the
edit unit that covered the seek position, whether that's
a keyframe or not. Decoders would only output things from
the next keyframe then, which means there's a gap between
the start of the segment and the first decoded data in
some cases. In combination with gst-editing-services this
might result in a frozen picture for the duration of that
gap at the beginning (if videorate fixes up the first
buffer's start timestamp to cover the entire gap), or
a black frame (if no videorate is used and videomixer
fills the gap). Also fixes A/V sync issue when requesting
a KEYUNIT seek.
