When receiving an RTCP packet, the difference between the last RTCP
timestamp and the base timestamp may be negative. As these timestamps
are of the uint32_t type, the result becomes a large integer. Cast
the difference to int32_t to avoid this issue.
The result of this issue is very large start times for RTSP
streams, and difficulty to restart correctly after a pause.
Signed-off-by: Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>
Signed-off-by: Martin Storsjö <martin@martin.st>
modelled after aarch64 code
on Cortex-A8, s16 and s32 code is about 2x faster,
float code about 7x faster
Signed-off-by: Peter Meerwald <pmeerw@pmeerw.net>
Signed-off-by: Martin Storsjö <martin@martin.st>
Based on patch by Francisco Blas Izquierdo Riera
Commit message partly taken from carl
fixes a compilation
error in mlpdsp_init.c with -fstack-check and some gcc compilers (I
reproduced the issue with gcc 4.7.3) by simplifying the code.
See also https://bugs.gentoo.org/show_bug.cgi?id=471756
$ make libavcodec/x86/mlpdsp_init.o
libavcodec/x86/mlpdsp_init.c: In function ‘mlp_filter_channel_x86’:
libavcodec/x86/mlpdsp_init.c:142:5: error: can’t find a register in
class ‘GENERAL_REGS’ while reloading ‘asm’
libavcodec/x86/mlpdsp_init.c:142:5: error: ‘asm’ operand has impossible
constraints
4551 -> 4509 dezicycles
Reviewed-by: Ramiro Polla <ramiro.polla@gmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Signed-off-by: Supraja Meedinti <supraja0493@gmail.com>
Reviewed-by: Nicolas George <george@nsup.org>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
When receiving an RTCP packet, the difference between the last RTCP
timestamp and the base timestamp may be negative. As these timestamps
are of the uint32_t type, the result becomes a large integer. Cast
the difference to int32_t to avoid this issue.
The result of this issue is very large start times for RTSP
streams, and difficulty to restart correctly after a pause.
Signed-off-by: Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* commit '10e2d8b5562d8729e4eefbcec63a11eb8a0c502c':
rtpdec_hevc: Use a shared function for parsing parameter sets
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'a982c5d74fbc7ff5bd2f2f73af61ae48e9b1bcc6':
tests: drop bc dependency
Conflicts:
tests/fate-run.sh
See: d47eeff274
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '0dea4c77ccf5956561bb8991311b3d834bb5fa40':
h264: only ref cur_pic in update_thread_context if it is initialized
Conflicts:
libavcodec/h264_slice.c
See: 0fc01ae33c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '9abc80f1ed673141326341e26a05c3e1f78576d0':
libavcodec: Make use of av_clip functions
Conflicts:
libavcodec/takdec.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '3fe26bb60858951710a42065c8183cce100d632a':
hlsenc: write playlist into a temp file and replace the original atomically
Conflicts:
libavformat/hlsenc.c
See: da97e4c64a
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'ff48ae94f90f6862dbe5b1e7397a1bda3150e200':
hlsenc: remove the AVIOContext for the playlist from the muxer context
Conflicts:
libavformat/hlsenc.c
See: 28bf05e7b5
Merged-by: Michael Niedermayer <michaelni@gmx.at>
add ARM code for implementing av_clip_intp2 using the ssat instruction
on Cortex-A8, av_clip_intp2_arm() is faster than av_clip_intp2_c() and
the generic av_clip(), about -19%
Signed-off-by: Peter Meerwald <pmeerw@pmeerw.net>
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
there already is a function, av_clip_uintp2() that clips a signed integer
to an unsigned power-of-two range, i.e. 0,2^p-1
this patch adds a function av_clip_intp2() that clips a signed integer
to a signed power-of-two range, i.e. -(2^p),(2^p-1)
the new function can be used as a special case for av_clip(), e.g.
av_clip(x, -8192, 8191) can be rewritten as av_clip_intp2(x, 13)
there are ARM instructions, usat and ssat resp., which map nicely to these
functions (see next patch)
Signed-off-by: Peter Meerwald <pmeerw@pmeerw.net>
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
