When input buffer timestamps are invalid, next timestamp are used for
audio. Then, the next out timestamp is updated with the used timestamp
and the calculated duration. However, if the used timestamp is invalid,
it should not be used. Otherwise, the next buffer will use a wrong
timestamp that is not in the clipped segment, making the buffer to be
dropped.
This fixes playback with SBTVD MPEG TS streams, using AAC LATM.
A keyframe may be quite a while in the future, and the decoder
has no way of knowing this. A poor decision could mean quite some
time with no video output.
This decision should be left to the upstream element: a demuxer
might know about incoming keyframes, or some other element might
be able to request a keyframe.
Fixes bug #649372.
Previously autoconf appended too many additional quotes
to parameters like --with-ffmpeg-extra-configure=" --target-os=linux
--extra-cflags='-mfpu=neon -mfloat-abi=softfp'".
Fixes bug #648816.
Right now it doesn't use any of the extra fields AVPacket provides.
It might be wise to investigate the pts/dts ones to see if we can finally
get rid of the timing-related cruft we have.
Set the caps right after allocation of the buffer because we know the buffer is
writable then and we are correctly negotiated. Since ffmpeg keeps around
references to frames, making the buffer metadata writable where it was done
before pushing will always end up with a copy and that makes the sink do a slow
memcpy all the time.
Set caps on buffers right after we allocate them to avoid refcounting problems
and having to make the buffer metadata writable for no good reason.
Don't unmap the memory with a 0 size or we would modify the memory size when
it's not needed.
FFMpeg parsing and decoding calls require to additionally allocate bytes
at the end of the input bitstream and this padding must be initialized
to zero.
https://bugzilla.gnome.org/show_bug.cgi?id=595590
