1
0
mirror of https://github.com/FFmpeg/FFmpeg.git synced 2024-12-02 03:06:28 +02:00
Commit Graph

6 Commits

Author SHA1 Message Date
Martin Storsjö
d594dbecce rtpdec: Rename the free method to close
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>
2015-02-24 23:07:50 +02:00
Martin Storsjö
199fb40278 rtpdec: Use ffio_free_dyn_buf
Signed-off-by: Martin Storsjö <martin@martin.st>
2015-02-24 23:07:44 +02:00
Martin Storsjö
bb4a310bb8 rtpdec: Don't free the payload context in the .free function
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>
2015-02-24 23:07:35 +02:00
Martin Storsjö
5d8cae4573 rtpdec: Get rid of all trivial .alloc/.free functions
Signed-off-by: Martin Storsjö <martin@martin.st>
2015-02-24 16:24:19 +02:00
Martin Storsjö
2b982e92f4 rtpdec: Set need_parsing via a handler field
This avoids implementing a full function just to set this one
field.

Signed-off-by: Martin Storsjö <martin@martin.st>
2015-02-24 16:22:41 +02:00
Thomas Volkert
a505c0d737 rtp: Initial H.261 support
The packetizer only supports splitting at GOB headers - if
such aren't available frequently enough, it splits at any
random byte offset (not at a macroblock boundary either, which
would be allowed by the spec) and sends a payload header pretend
that it starts with a GOB header.

As long as a receiver doesn't try to handle such cases cleverly
but just drops broken frames, this shouldn't matter too much
in practice.

Signed-off-by: Martin Storsjö <martin@martin.st>
2014-12-18 23:11:37 +02:00