In the spirit of commit 8199908fdf, likely
typo originally.
Found by enabling -Wparentheses on clang 3.7 and running a manual audit.
To the best of my knowledge, no such instances remain.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
This fixes an oversight in 96084251, in a refactoring done on top
of Gilles' original patch.
Pointed out by Gilles Chanteperdrix.
Signed-off-by: Martin Storsjö <martin@martin.st>
Commit 96084251e5 introduced a change in
the parser implementation which broke it. Restore the original
implementation.
Signed-off-by: Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'bb4a310bb85f43e62240145a656b1e5285b14239':
rtpdec: Don't free the payload context in the .free function
Conflicts:
libavformat/rtpdec_latm.c
libavformat/rtpdec_mpeg4.c
libavformat/rtpdec_mpegts.c
libavformat/rtpdec_xiph.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '5d8cae45737bed6239bd6b6e0698802dbe1463c8':
rtpdec: Get rid of all trivial .alloc/.free functions
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'b651c9139e1ab222d5aab9151dcd7d6e40e49885':
rtpdec_mpa_robust: Move .enc_name to the start of the struct
Merged-by: Michael Niedermayer <michaelni@gmx.at>
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>
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>
