gstfreeverb.c:781:29: error: using integer absolute value function 'abs' when
argument is of floating point type [-Werror,-Wabsolute-value]
if (abs (out_l2) > 0 || abs (out_r2) > 0)
They are very confusing for people, and more often than not
also just not very accurate. Seeing 'last reviewed: 2005' in
your docs is not very confidence-inspiring. Let's just remove
those comments.
This should not harm regular files, since those are the last 4 bytes of
a normal file.
This allows to handle playback of concatenated mpeg-ps files. Seeking and
duration reporting is still wrong though.
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.
Detect resolution changes on key frames, and propagate the resulting
caps to the src pad. Only the uncompressed data chunk is decoded, so
avoid using the new VP8 bitstream parsing library for now.
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
Avoid possible division-by-zero while deriving the presentation timestamp
of the buffer. The base class will take care of any interpolation needs.
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
* Search in current pending values first. For CBR streams we can very
easily end up having just one initial observations and then nothing
else (since the bitrate doesn't change).
* Use one group whether we are in that group *OR* if there is only
one group.
* If the group to use isn't closed (points are being accumulated in the
PCROffsetCurrent), use the latest data available for calculation
* If in the unlikelyness that all of this *still* didn't produce more
than one data point, just return the initial offset
While the calculation done in these macros will work with 64bit
integers, they will fail if working with 32bit integers.
Force the scaling up to solve that.
This amazingly didn't introduce major issues up to now, but resulted
in bogus values in debug logs.
Doing a hard flush on the packetizer will drop all observations, which
will eventually break push-based seeking (with BYTES segment) since
we won't know where to seek to anymore (new data would always be
considered as the beginning of the stream).
