- 22 Feb, 2015 1 commit
-
-
Thomas Volkert authored
(tested with live555 RTSP server) Signed-off-by: Martin Storsjö <martin@martin.st>
-
- 21 Feb, 2015 19 commits
-
-
Gilles Chanteperdrix authored
Signed-off-by: Martin Storsjö <martin@martin.st>
-
Gilles Chanteperdrix authored
Signed-off-by: Martin Storsjö <martin@martin.st>
-
Gilles Chanteperdrix authored
Signed-off-by: Martin Storsjö <martin@martin.st>
-
Gilles Chanteperdrix authored
Signed-off-by: Martin Storsjö <martin@martin.st>
-
Gilles Chanteperdrix authored
Signed-off-by: Martin Storsjö <martin@martin.st>
-
Gilles Chanteperdrix authored
Signed-off-by: Martin Storsjö <martin@martin.st>
-
Gilles Chanteperdrix authored
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>
-
Martin Storsjö authored
Signed-off-by: Martin Storsjö <martin@martin.st>
-
Peter Meerwald authored
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>
-
Thomas Volkert authored
With significant changes by Martin Storsjö, to use the shared function instead of reimplementing it. Signed-off-by: Martin Storsjö <martin@martin.st>
-
Martin Storsjö authored
For some reason, clang didn't warn about this prior to using the shared function. Signed-off-by: Martin Storsjö <martin@martin.st>
-
Martin Storsjö authored
Signed-off-by: Martin Storsjö <martin@martin.st>
-
Martin Storsjö authored
Signed-off-by: Martin Storsjö <martin@martin.st>
-
Martin Storsjö authored
This fixes builds with -DDEBUG after f0a87479. Signed-off-by: Martin Storsjö <martin@martin.st>
-
Martin Storsjö authored
Add a parameter for skipping a number of bytes at the start of each nal. Signed-off-by: Martin Storsjö <martin@martin.st>
-
Martin Storsjö authored
Don't write directly into an AVCodecContext, write into given pointers. Signed-off-by: Martin Storsjö <martin@martin.st>
-
Clément Bœsch authored
We already have a dependency on awk and bc is sometimes not found in the base system. Signed-off-by: Martin Storsjö <martin@martin.st>
-
Anton Khirnov authored
This prevents using a wrong (first thread's) AVCodecContext if decoding a frame in the first pass over all threads fails.
-
Anton Khirnov authored
It may be empty if the previous thread's decode call did not contain a valid frame.
-
- 20 Feb, 2015 14 commits
-
-
Peter Meerwald authored
Signed-off-by: Peter Meerwald <pmeerw@pmeerw.net> Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
-
Peter Meerwald authored
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>
-
Peter Meerwald authored
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>
-
Hendrik Leppkes authored
Signed-off-by: Martin Storsjö <martin@martin.st>
-
Hendrik Leppkes authored
Its only used in one function, having it in the context serves no purpose. Signed-off-by: Martin Storsjö <martin@martin.st>
-
Peter Meerwald authored
Signed-off-by: Peter Meerwald <pmeerw@pmeerw.net> Signed-off-by: Martin Storsjö <martin@martin.st>
-
Peter Meerwald authored
Signed-off-by: Peter Meerwald <pmeerw@pmeerw.net> Signed-off-by: Martin Storsjö <martin@martin.st>
-
Martin Storsjö authored
Signed-off-by: Martin Storsjö <martin@martin.st>
-
Martin Storsjö authored
If src_len is too small for nal_size, we already print a warning above, and the next step is to check the while loop condition anyway, so this one serves no purpose. Signed-off-by: Martin Storsjö <martin@martin.st>
-
Martin Storsjö authored
Previously, errors were only logged but the code kept on trying, and never actually returning the error as a return value. Signed-off-by: Martin Storsjö <martin@martin.st>
-
Martin Storsjö authored
Signed-off-by: Martin Storsjö <martin@martin.st>
-
Martin Storsjö authored
This is similar to what was done for rtpdec_hevc in ced7238c. Signed-off-by: Martin Storsjö <martin@martin.st>
-
Martin Storsjö authored
Including libavcodec/get_bits.h is superfluous for AV_RB16 - nothing in this file uses any actual bitstream reader. Signed-off-by: Martin Storsjö <martin@martin.st>
-
Martin Storsjö authored
This allows the output to be used with stream copy, which discards packet from the start until the first keyframe. Signed-off-by: Martin Storsjö <martin@martin.st>
-
- 19 Feb, 2015 6 commits
-
-
Vittorio Giovara authored
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com> Signed-off-by: Oleksij Rempel <linux@rempel-privat.de>
-
Oleksij Rempel authored
Signed-off-by: Oleksij Rempel <linux@rempel-privat.de> Signed-off-by: Luca Barbato <lu_zero@gentoo.org> Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
-
Oleksij Rempel authored
Signed-off-by: Oleksij Rempel <linux@rempel-privat.de> Signed-off-by: Luca Barbato <lu_zero@gentoo.org> Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
-
Anton Khirnov authored
-
Anton Khirnov authored
-
Anton Khirnov authored
Based on the code by Luca Barbato <lu_zero@gentoo.org> and Yukinori Yamazoe <drocon11@gmail.com>.
-