This also allows for removing some of the Vorbis-related hacks.

The binary doesn't change after this patch.
Signed-off-by: Martin Storsjö <martin@martin.st>

This is different from the "modern" RTP payload formats for H263
as defined by RFC 4629, 2429 and 3555. According to the newer RFCs,
this old one is to be considered deprecated and only be used for
interoperating with legacy systems.
Signed-off-by: Martin Storsjö <martin@martin.st>

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 952139a3, 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>

This requires using a separate init function, since there
isn't necessarily any fmtp lines for this codec, so
parse_sdp_a_line won't be called. Incorporating it with the
alloc function wouldn't do either, since it is called before
the full rtpmap line is parsed (where the sample rate is
extracted).
Signed-off-by: Martin Storsjö <martin@martin.st>

RTCP timestamps are only necessary to synchronize time between
multiple streams. For a single stream, the RTP packet timestamp
provides more reliable timing. As a result, single-stream RTP
sessions should now have accurate and monotonic PTS.
Signed-off-by: Martin Storsjö <martin@martin.st>

The timestamp field in RTPDemuxContext was unused before this.
Signed-off-by: Martin Storsjö <martin@martin.st>

Signed-off-by: Martin Storsjö <martin@martin.st>

Fixes Ticket611
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

All current usages of it are incompatible with localization.
For example strcasecmp("i", "I") != 0 is possible, but would
break many of the places where it is used.

Instead use our own implementations that always treat the data
as ASCII.
Signed-off-by: Martin Storsjö <martin@martin.st>

All current usages of it are incompatible with localization.
For example strcasecmp("i", "I") != 0 is possible, but would
break many of the places where it is used.
Instead use our own implementations that always treat the data
as ASCII.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>

Previous code could read 4 bytes past the end of the buffer on a RTCP_SR
packet or offset a pointer by an unchecked external value (payload_len),
though neither will reliably cause a crash or other misbehavior beyond
garbage timestamps.

Additionally, unknown RTCP packet types, even in compounded packets, are
now ignored as per RFC 3550 section 6.1, page 22, though currently this
only has any practical effect if a sender puts an unrecognized type
before RTCP_BYE in a compounded packet, or (incorrectly) does not put
RTCP_SR first.
Signed-off-by: John Brooks <john.brooks@bluecherry.net>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Signed-off-by: Martin Storsjö <martin@martin.st>

This allows skipping past unsupported RTCP packet types, as
RFC 3550 section 6.1 mandates.

Currently this only has any practical effect if a sender puts
an unrecognized type before RTCP_BYE in a compounded packet, or
(incorrectly) does not put RTCP_SR first.
Signed-off-by: Martin Storsjö <martin@martin.st>

We actually read 20 bytes of these packets.
Signed-off-by: Martin Storsjö <martin@martin.st>

Signed-off-by: Mans Rullgard <mans@mansr.com>

Most of these variables are only used in av_dlog statements, some
are required but not used by other macros.
Signed-off-by: Mans Rullgard <mans@mansr.com>

Adding _POSIX_C_SOURCE to CPPFLAGS globally produces all sorts of problems
since it causes certain system functions to be hidden on some (BSD) systems.
The solution is to only add the flag on systems that really require it, i.e.
glibc-based ones.

This change makes BSD systems compile out-of-the-box without the need for
adding specific flags manually.  It also allows dropping a number of flags
set manually on a file-per-file basis, but were only present to work around
breakage introduced by the presence of _POSIX_C_SOURCE.

Also add _XOPEN_SOURCE to CPPFLAGS for glibc systems.  We use XSI extensions
in several places already, so it is preferable to define it globally instead
of littering source files with individual #defines only needed for glibc.

It doesn't look fit to be a part of the public API.

Adding a temporary hack to ffserver to be able to use it, should be
cleaned up when somebody is up for it.

Signed-off-by: Mans Rullgard <mans@mansr.com>

Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>

In the name of consistency:
put_byte           -> avio_w8
put_<type>         -> avio_w<type>
put_buffer         -> avio_write

put_nbyte will be made private
put_tag will be merged with avio_put_str
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
(cherry picked from commit 77eb5504)

In the name of consistency:
put_byte           -> avio_w8
put_<type>         -> avio_w<type>
put_buffer         -> avio_write

put_nbyte will be made private
put_tag will be merged with avio_put_str
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>

Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
(cherry picked from commit ae628ec1)

Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>

dprintf clashes with POSIX.1-2008
(cherry picked from commit dfd2a005)

dprintf clashes with POSIX.1-2008

Signed-off-by: Mans Rullgard <mans@mansr.com>
(cherry picked from commit 119cc033)

Signed-off-by: Mans Rullgard <mans@mansr.com>
(cherry picked from commit 69ad22c7)

Signed-off-by: Mans Rullgard <mans@mansr.com>

Signed-off-by: Mans Rullgard <mans@mansr.com>

For MS-RTSP, we don't always get RTCP packets (never?), so the earlier
timestamping code never wrote anything into pkt->pts. The rtpdec_asf
depacketizer just sets the dts of the packet, so if the generic RTP
timestamping is used, too, we get inconsistent timestamps.

Therefore, skip the generic RTP timestamp algorithm if the depacketizer
already has set something.

This fixes "Invalid timestamps" warnings, present since SVN rev 26187.

Originally committed as revision 26241 to svn://svn.ffmpeg.org/ffmpeg/trunk

Emitted timestamps in each stream start from 0, for the first received
RTP packet. Once an RTCP packet is received, that one is used for
sync, emitting timestamps that fit seamlessly into the earlier ones.

Originally committed as revision 26187 to svn://svn.ffmpeg.org/ffmpeg/trunk

This also reverts SVN rev 26016, which incorrectly overwrote the time base
with 90 kHz for all streams, regardless of what was set by the SDP parsing.

The stream that triggered the fix in 26016 still works after this commit.

Originally committed as revision 26022 to svn://svn.ffmpeg.org/ffmpeg/trunk

The generic default is 0/0 and that obviously triggers once the value is used.

Originally committed as revision 26016 to svn://svn.ffmpeg.org/ffmpeg/trunk

This fixes cases where the RTP time base and the sample rate of the stream
differ. Previously, the AVStream time_base was unconditionally set to
the sample rate (which initially was set to one value when parsing the
rtpmap field in the SDP, but later overridden by an a=SampleRate field).

Additionally, this makes the code actually use the stream time base set
in rtpmap for video codecs, instead of hardcoding it to always be 90 kHz.

Originally committed as revision 25908 to svn://svn.ffmpeg.org/ffmpeg/trunk