| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
| |
Signed-off-by: Diego Biurrun <diego@biurrun.de>
|
| |
|
|
|
|
|
|
|
| |
Many of these functions were named foo_free_context, and since
the functions no longer should free the context itself, only
allocated elements within it, the previous naming was slightly
misleading.
Signed-off-by: Martin Storsjö <martin@martin.st>
|
| |
|
|
| |
Signed-off-by: Martin Storsjö <martin@martin.st>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This makes it more consistent with depacketizers that don't have any
.free function at all, where the payload context is freed by the
surrounding framework. Always free the context in the surrounding
framework, having the individual depacketizers only free any data
they've specifically allocated themselves.
This is similar to how this works for demuxer/muxers/codecs - a
component shouldn't free the priv_data that the framework has
allocated for it.
Signed-off-by: Martin Storsjö <martin@martin.st>
|
| |
|
|
|
|
| |
The free function of a depacketizer won't be called if data is NULL.
Signed-off-by: Martin Storsjö <martin@martin.st>
|
| |
|
|
| |
Signed-off-by: Martin Storsjö <martin@martin.st>
|
| |
|
|
|
|
|
| |
This avoids implementing a full function just to set this one
field.
Signed-off-by: Martin Storsjö <martin@martin.st>
|
| |
|
|
|
|
|
|
|
| |
If we throw away the buffered incomplete frame, make sure to also
throw away the buffered bits of an incomplete byte at the same
time.
CC: libav-stable@libav.org
Signed-off-by: Martin Storsjö <martin@martin.st>
|
| | |
|
| |
|
|
|
|
|
| |
This gets rid of almost all the codec specific details from the
generic rtpdec code.
Signed-off-by: Martin Storsjö <martin@martin.st>
|
| |
|
|
|
|
| |
This allows depacketizers to figure out if packets have been lost.
Signed-off-by: Martin Storsjö <martin@martin.st>
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
While there is no reason for starting a frame with anything else
than a Mode A packet, some senders seem to consistently use Mode B
packets for everything. This fixes depacketization of such streams.
Signed-off-by: Martin Storsjö <martin@martin.st>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
H263 in RTP can be packetized in two formats (RFC 2190, RFC
2429/4629). The former normally uses the static payload type 34,
while the latter normally uses dynamic payload types with the
SDP format names H263-1998 or H263-2000.
Look for packets that don't look like proper RFC 2190 packets and
switch to depacketizing them according to the new format if they
match some heuristic criteria.
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>
|
