This prevents insane memory usage in case of insane input values.
Untested due to lack of a testcase that causes such insane allocation
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
"analyzeduration" is not used to detect the input duration, but to
specify the max probe data duration. Fix option description and related
doc entry accordingly.
* commit 'abae27ed3acd0a7c54f11760c5be2d2653c4edf8':
rtpdec: Fix the calculation of expected number of packets
fate: vp3: Fix fate-vp3-coeff-level64 test dependencies
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '4d3b144c5ea824193019019d33740a1ae9e0bb69':
fate: cosmetics: Order some test entries
Conflicts:
tests/fate/lossless-video.mak
tests/fate/microsoft.mak
Merged-by: Michael Niedermayer <michaelni@gmx.at>
Previously, we always signalled a zero time since the last RTCP
SR, which is dubious.
The code also suggested that this would be the difference in
RTP NTP time units (32.32 fixed point), while it actually is
in in 1/65536 second units. (RFC 3550 section 6.4.1)
Signed-off-by: Martin Storsjö <martin@martin.st>
This brings back some code that was added originally in 4a6cc061
but never was used, and was removed as unused in 4cc843fa. The
code is updated to actually work and is tested to return sane
values.
Signed-off-by: Martin Storsjö <martin@martin.st>
The base_seq variable is set to first_seq - 1 (in
rtp_init_sequence), so no + 1 is needed here.
This avoids reporting 1 lost packet from the start.
Signed-off-by: Martin Storsjö <martin@martin.st>
If nb_samples divide sample_rate and if nb_samples allow it, aevalsrc
should generate the exact amount of samples according to duration.
Example:
aevalsrc=0::n=480:s=48000:d=5.21 should generate 250080 samples.
Signed-off-by: Stefano Sabatini <stefasab@gmail.com>
* qatar/master:
Add version bump and APIchanges entry for Add AV_PIX_FMT_VDPAU.
pixfmt: add picture format for VDPAU
Conflicts:
doc/APIchanges
libavutil/pixfmt.h
libavutil/version.h
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '54cb096ee4558b3bfc28c2fcd6418ce82dc39fe1':
rtsp: Remove an outdated comment
rtsp: Remove references to weirdly named variables in other files
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'c44784c9bb9d0ddf5d39d0dfa640816a57b8f457':
rtp: Rename a static variable to normal naming conventions
rtp: Cosmetic cleanup
Merged-by: Michael Niedermayer <michaelni@gmx.at>
The paragraph is about what ffserver is not and where to look for other
information, but is pretty redundant and distracting, especially
considering the new organization of the documentation.
The question can be answered: No, we do not know the initial sequence
number from the SDP. In certain cases, it can be known from the
RTP-Info response header in RTSP though. (In that case, we use it as
timestamp origin, but not for rtp receiver statistics.)
Signed-off-by: Martin Storsjö <martin@martin.st>
It is unclear what the bug exactly was and if it ever was fixed,
and we don't even support decoding via faad any longer. The
comment has been present since d0deedcb in 2006.
Signed-off-by: Martin Storsjö <martin@martin.st>
Michael Niedermayer
Stefano Sabatini
Paul B Mahol
Martin Storsjö
Matthieu Bouron
Diego Biurrun
Luca Barbato
Rémi Denis-Courmont