This avoids (for all practical cases) the issue of reusing
the same UDP port as for an earlier connection. If the remote
doesn't know the previous session was closed, he might keep
on sending packets to that port. If we always start off trying
to open the same UDP port, we might get those packets intermixed
with the new ones.
This is occasionally an issue when testing RTSP stuff with
DSS, perhaps also with other servers.
Signed-off-by: Martin Storsjö <martin@martin.st>
This check isn't relevant in the way the code currently works.
Also change a case of if (x == 0) into if (!x).
Signed-off-by: Martin Storsjö <martin@martin.st>
Original commit:
commit 2473a45c85
Author: Janne Grunau <janne-libav@jannau.net>
Date: Wed Jan 18 10:53:41 2012 +0100
threads: change the default for threads back to 1
Using threaded decoding by default breaks backward compatibility if
AVHWAccel is used or if an appliction sets threadunsafe callbacks.
Avconv and avplay still use -threads auto if not specified.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* qatar/master:
rtpdec: Use our own SSRC in the SDES field when sending RRs
Finalize changelog for 0.8 Release
Prepare for 0.8 Release
threads: change the default for threads back to 1
threads: update slice_count and slice_offset from user context
aviocat: Remove useless includes
doc/APIChanges: fill in missing dates and hashes
Revert "avserver: fix build after the next bump."
mpegaudiodec: switch error detection check to AV_EF_BUFFER
lavf: rename fer option and document resulting (f_)err_detect options
lavc: rename err_filter option to err_detect and document it
mpegvideo: fix invalid memory access for small video dimensions
movenc: Reorder entries in the MOVIentry struct, for tigheter packing
rtsp: Remove extern declarations for variables that don't exist
aviocat: Flush the output before closing
Conflicts:
Changelog
RELEASE
libavcodec/mpegaudiodec.c
libavcodec/pthread.c
libavformat/options.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
The s->ssrc field is the sender's SSRC, we use ssrc + 1 to get
a collision free "unique" SSRC for ourselves in the RR part.
The SDES block in the RTCP packet should describe ourselves,
not the sender.
This was fixed for the RR part in 952139a322, but wasn't
fixed for the SDES part until now.
This could cause some Axis cameras to send RTCP BYE packets
to us due to the SSRC collision.
Signed-off-by: Martin Storsjö <martin@martin.st>
Using threaded decoding by default breaks backward compatibility if
AVHWAccel is used or if an appliction sets threadunsafe callbacks.
Avconv and avplay still use -threads auto if not specified.
This temporarily (until 0.8 is released) reverts commit
8e1340abc3. That commit breaks shared
builds because of symbol hiding. Reverting it will enable shared builds
for 0.8
When either video dimension is only one macroblock, subtractions
based on v_edge_pos and the macroblock size may be negative. In
that situation, an unsigned comparison isn't sufficent to test for
MV overruns, because a limit of (unsigned)-1 will let any other
value pass.
Signed-off-by: Anton Khirnov <anton@khirnov.net>
That way all mix levels as exported by the parser
will have the same meaning.
Previously the 3bit center mix level for eac3 was
used to index in a 4 entry table leading to out of array reads.
this change removes the table and offsets the ac3 variable by 4
so it matches the meanings for eac3 except the reserved case.
The reserved case is then explicitly handled.
Idea-by: Justin Ruggles <justin.ruggles@gmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Sometimes the scan finds nothing that qualifies for addition to
the array and pos is zero after the loops. The code forces pos to
1 and the array is then processed as if it had one valid element in it,
producing some amusing but not very useful results.
I don't see the rationale for this. If pos is zero coming out of the
loops, the only appropriate thing to do is set t->angle to zero. The
attached patch does that. It's worked properly in several tests so far.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
As the test is run during fate and the benchmark is useless for fate
this very slightly speeds up fate. Its also consistent with the other
tests.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* qatar/master:
Add a tool that uses avio to read and write, doing a plain copy of data
ARM: fix build with FFT enabled and MDCT disabled
lavf: force single-threaded decoding in avformat_find_stream_info
avidec: migrate last of lavf from FF_ER_* to AV_EF_*
avserver: fix build after the next bump.
Conflicts:
libavformat/Makefile
libavformat/avidec.c
libavformat/utils.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
Originally, sizeof(struct MOVIentry) was 48, after the reordering,
it is 40 in my build configuration.
When writing really long mov/mp4 files, this can make a difference
- this saves a bit over 2 MB of memory per hour of video (down to
10.3 MB per hour from 12.3 MB per hour initially) for a video with
75 packets per second - 25 fps + 50 audio packets (which is the
case for AMR audio).
Signed-off-by: Martin Storsjö <martin@martin.st>
