- 24 Feb, 2015 6 commits
-
-
Martin Storsjö authored
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>
-
Martin Storsjö authored
Signed-off-by: Martin Storsjö <martin@martin.st>
-
Martin Storsjö authored
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>
-
Martin Storsjö authored
The free function of a depacketizer won't be called if data is NULL. Signed-off-by: Martin Storsjö <martin@martin.st>
-
Martin Storsjö authored
Signed-off-by: Martin Storsjö <martin@martin.st>
-
Martin Storsjö authored
This avoids implementing a full function just to set this one field. Signed-off-by: Martin Storsjö <martin@martin.st>
-
- 18 Dec, 2014 1 commit
-
-
Martin Storsjö authored
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>
-
- 30 Aug, 2013 1 commit
-
-
Thilo Borgmann authored
-
- 05 May, 2013 1 commit
-
-
Diego Biurrun authored
-
- 20 Jan, 2013 1 commit
-
-
Martin Storsjö authored
This gets rid of almost all the codec specific details from the generic rtpdec code. Signed-off-by: Martin Storsjö <martin@martin.st>
-
- 21 Dec, 2012 1 commit
-
-
Martin Storsjö authored
This allows depacketizers to figure out if packets have been lost. Signed-off-by: Martin Storsjö <martin@martin.st>
-
- 02 Nov, 2012 1 commit
-
-
Anton Khirnov authored
-
- 07 Aug, 2012 1 commit
-
-
Anton Khirnov authored
-
- 14 Jun, 2012 1 commit
-
-
Martin Storsjö authored
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>
-
- 18 Feb, 2012 1 commit
-
-
Martin Storsjö authored
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>
-
- 14 Feb, 2012 1 commit
-
-
Martin Storsjö authored
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>
-