---
As noted by Diego when I fixed NSV earlier.
Sorry for dragging my feet on this one.
Question: do I actually need to unref the packet here?
It seems like we are really inconsistent on how to handle errors from
av_get_packet().
Sometimes we just return the result of the call, other times we force
AVERROR(EIO).
Should this be revisited?
---
libavformat/rmdec.c | 25 ++++++++++++++++++++-----
1 file changed, 20 insertions(+), 5 deletions(-)
diff --git a/libavformat/rmdec.c b/libavformat/rmdec.c
index 2e93f1d..662056a 100644
--- a/libavformat/rmdec.c
+++ b/libavformat/rmdec.c
@@ -722,6 +722,7 @@ ff_rm_parse_packet (AVFormatContext *s, AVIOContext *pb,
int *seq, int flags, int64_t timestamp)
{
RMDemuxContext *rm = s->priv_data;
+ int ret;
if (st->codecpar->codec_type == AVMEDIA_TYPE_VIDEO) {
rm->current_stream= st->id;
@@ -778,11 +779,19 @@ ff_rm_parse_packet (AVFormatContext *s, AVIOContext *pb,
} else
return -1;
} else {
- av_get_packet(pb, pkt, len);
+ ret = av_get_packet(pb, pkt, len);
+ if (ret < 0) {
+ av_packet_unref(pkt);
+ return ret;
+ }
rm_ac3_swap_bytes(st, pkt);
}
} else
- av_get_packet(pb, pkt, len);
+ ret = av_get_packet(pb, pkt, len);
+ if (ret < 0) {
+ av_packet_unref(pkt);
+ return ret;
+ }
pkt->stream_index = st->index;
@@ -798,14 +807,20 @@ ff_rm_retrieve_cache (AVFormatContext *s, AVIOContext *pb,
AVStream *st, RMStream *ast, AVPacket *pkt)
{
RMDemuxContext *rm = s->priv_data;
+ int ret;
assert (rm->audio_pkt_cnt > 0);
if (ast->deint_id == DEINT_ID_VBRF ||
- ast->deint_id == DEINT_ID_VBRS)
- av_get_packet(pb, pkt, ast->sub_packet_lengths[ast->sub_packet_cnt -
rm->audio_pkt_cnt]);
+ ast->deint_id == DEINT_ID_VBRS) {
+ ret = av_get_packet(pb, pkt,
ast->sub_packet_lengths[ast->sub_packet_cnt - rm->audio_pkt_cnt]);
+ if (ret < 0) {
+ av_packet_unref(pkt);
+ return ret;
+ }
+ }
else {
- int ret = av_new_packet(pkt, st->codecpar->block_align);
+ ret = av_new_packet(pkt, st->codecpar->block_align);
if (ret < 0)
return ret;
memcpy(pkt->data, ast->pkt.data + st->codecpar->block_align * //FIXME
avoid this
--
2.7.4
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel