From: "tanwei (D)" <tanwei123@hisilicon.com>
To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
Cc: "Wujian\(Chin\)" <wujian2@huawei.com>,
Lingzezhi <steven.ling@hisilicon.com>
Subject: [FFmpeg-devel] [PATCH] libavformat/rtspdec.c: flush pes buffer while rtsp seek
Date: Thu, 29 Dec 2022 03:43:24 +0000
Message-ID: <ecaa3df57d1c40c495d8113241f55797@hisilicon.com> (raw)
>>
>> + if (rt->cur_transport_priv && rt->transport ==
>> + RTSP_TRANSPORT_RTP) {
>>
>> + ff_rtp_seek_flush(rt->cur_transport_priv);
>>
>> + } else if (CONFIG_RTPDEC && rt->ts) {
>>
>> + av_freep(&rt->recvbuf);
>Is it necessary to free rt->recvbuf?
The recvbuf must be released. Otherwise, data before seek may be read in the RTSP+TS scenario.
>>
>> + rt->recvbuf_pos = 0;
>>
>> + rt->recvbuf_len = 0;
>>
>> + ff_mpegts_seek_flush(rt->ts);
>>
>> + }
-----邮件原件-----
发件人: ffmpeg-devel [mailto:ffmpeg-devel-bounces@ffmpeg.org] 代表 "zhilizhao(赵志立)"
发送时间: 2022年12月23日 10:34
收件人: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
抄送: Wujian(Chin) <wujian2@huawei.com>; Lingzezhi <steven.ling@hisilicon.com>
主题: Re: [FFmpeg-devel] [PATCH] libavformat/rtspdec.c: flush pes buffer while rtsp seek
> On Dec 22, 2022, at 11:32, tanwei (D) <tanwei123@hisilicon.com> wrote:
>
> Fixes ticket #9949.
>
>
> Signed-off-by: t00660896 <tanwei123@hisilicon.com>
>
> ---
>
> libavformat/mpegts.c | 20 ++++++++++++++++++++
>
> libavformat/mpegts.h | 1 +
>
> libavformat/rtpdec.c | 7 +++++++
>
> libavformat/rtpdec.h | 2 ++
>
> libavformat/rtpdec_mpegts.c | 11 +++++++++++
>
> libavformat/rtspdec.c | 11 +++++++++++
>
> 6 files changed, 52 insertions(+)
>
>
Please check the patch format (a lot of empty lines).
> diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
>
> index d97702fcd7..c82971af87 100644
>
> --- a/libavformat/mpegts.c
>
> +++ b/libavformat/mpegts.c
>
> @@ -3419,6 +3419,26 @@ int avpriv_mpegts_parse_packet(MpegTSContext
> *ts, AVPacket *pkt,
>
> return len1 - len;
>
> }
>
> +void ff_mpegts_seek_flush(MpegTSContext *ts)
>
> +{
>
> + int i;
>
> + /* flush pes buffer */
>
> + for (i = 0; i < NB_PID_MAX; i++) {
>
> + if (ts->pids[i]) {
>
> + if (ts->pids[i]->type == MPEGTS_PES) {
>
> + PESContext *pes = ts->pids[i]->u.pes_filter.opaque;
>
> + av_buffer_unref(&pes->buffer);
>
> + pes->data_index = 0;
>
> + pes->state = MPEGTS_SKIP; /* skip until pes header */
>
> + } else if (ts->pids[i]->type == MPEGTS_SECTION) {
>
> + ts->pids[i]->u.section_filter.last_ver = -1;
>
> + }
>
> + ts->pids[i]->last_cc = -1;
>
> + ts->pids[i]->last_pcr = -1;
>
> + }
>
> + }
>
> +}
>
> +
Please don’t just duplicate the source code.
>
> void avpriv_mpegts_parse_close(MpegTSContext *ts)
>
> {
>
> mpegts_free(ts);
>
> diff --git a/libavformat/mpegts.h b/libavformat/mpegts.h
>
> index a48f14e768..ea6b5106a4 100644
>
> --- a/libavformat/mpegts.h
>
> +++ b/libavformat/mpegts.h
>
> @@ -170,6 +170,7 @@ MpegTSContext
> *avpriv_mpegts_parse_open(AVFormatContext *s);
>
> int avpriv_mpegts_parse_packet(MpegTSContext *ts, AVPacket *pkt,
>
> const uint8_t *buf, int len);
>
> void avpriv_mpegts_parse_close(MpegTSContext *ts);
>
> +void ff_mpegts_seek_flush(MpegTSContext *ts);
>
> typedef struct SLConfigDescr {
>
> int use_au_start;
>
> diff --git a/libavformat/rtpdec.c b/libavformat/rtpdec.c
>
> index fa7544cc07..d688afd1c1 100644
>
> --- a/libavformat/rtpdec.c
>
> +++ b/libavformat/rtpdec.c
>
> @@ -954,6 +954,13 @@ int ff_rtp_parse_packet(RTPDemuxContext *s,
> AVPacket *pkt,
>
> return rv ? rv : has_next_packet(s);
>
> }
>
> +void ff_rtp_seek_flush(RTPDemuxContext *s)
>
> +{
>
> + ff_rtp_reset_packet_queue(s);
>
> + if (s->handler && s->handler->seek_flush)
>
> + s->handler->seek_flush(s->dynamic_protocol_context);
>
> +}
>
> +
>
> void ff_rtp_parse_close(RTPDemuxContext *s)
>
> {
>
> ff_rtp_reset_packet_queue(s);
>
> diff --git a/libavformat/rtpdec.h b/libavformat/rtpdec.h
>
> index 5a02e72dc2..8d6d857e28 100644
>
> --- a/libavformat/rtpdec.h
>
> +++ b/libavformat/rtpdec.h
>
> @@ -52,6 +52,7 @@ int ff_rtp_parse_packet(RTPDemuxContext *s, AVPacket
> *pkt,
>
> void ff_rtp_parse_close(RTPDemuxContext *s);
>
> int64_t ff_rtp_queued_packet_time(RTPDemuxContext *s);
>
> void ff_rtp_reset_packet_queue(RTPDemuxContext *s);
>
> +void ff_rtp_seek_flush(RTPDemuxContext *s);
>
> /**
>
> * Send a dummy packet on both port pairs to set up the connection
>
> @@ -135,6 +136,7 @@ struct RTPDynamicProtocolHandler {
>
> /** Parse handler for this dynamic packet */
>
> DynamicPayloadPacketHandlerProc parse_packet;
>
> int (*need_keyframe)(PayloadContext *context);
>
> + void (*seek_flush)(PayloadContext *protocol_data);
>
> };
>
> typedef struct RTPPacket {
>
> diff --git a/libavformat/rtpdec_mpegts.c b/libavformat/rtpdec_mpegts.c
>
> index 405271f744..46c1d36021 100644
>
> --- a/libavformat/rtpdec_mpegts.c
>
> +++ b/libavformat/rtpdec_mpegts.c
>
> @@ -47,6 +47,16 @@ static av_cold int mpegts_init(AVFormatContext
> *ctx, int st_index,
>
> return 0;
>
> }
>
> +static void mpegts_seek_flush(PayloadContext *data)
>
> +{
>
> + if (!data)
>
> + return;
Is it possible for data being NULL? It’s better to depends on a clear lifecycle management rather than NULL pointer check everywhere.
>
> + memset(data->buf, 0, data->read_buf_size);
>
> + data->read_buf_size = 0;
What about data->read_buf_index ?
>
> + if (data->ts)
>
> + ff_mpegts_seek_flush(data->ts);
>
> +}
>
> +
>
> static int mpegts_handle_packet(AVFormatContext *ctx, PayloadContext
> *data,
>
> AVStream *st, AVPacket *pkt, uint32_t
> *timestamp,
>
> const uint8_t *buf, int len, uint16_t
> seq,
>
> @@ -94,6 +104,7 @@ const RTPDynamicProtocolHandler
> ff_mpegts_dynamic_handler = {
>
> .priv_data_size = sizeof(PayloadContext),
>
> .parse_packet = mpegts_handle_packet,
>
> .init = mpegts_init,
>
> + .seek_flush = mpegts_seek_flush,
>
> .close = mpegts_close_context,
>
> .static_payload_id = 33,
>
> };
>
> diff --git a/libavformat/rtspdec.c b/libavformat/rtspdec.c
>
> index bbabec7db8..22b08a4c56 100644
>
> --- a/libavformat/rtspdec.c
>
> +++ b/libavformat/rtspdec.c
>
> @@ -36,6 +36,7 @@
>
> #include "rdt.h"
>
> #include "tls.h"
>
> #include "url.h"
>
> +#include "mpegts.h"
>
> #include "version.h"
>
> static const struct RTSPStatusMessage {
>
> @@ -982,6 +983,16 @@ static int rtsp_read_seek(AVFormatContext *s, int
> stream_index,
>
> rt->state = RTSP_STATE_IDLE;
>
> break;
>
> }
>
> +
>
> + if (rt->cur_transport_priv && rt->transport ==
> + RTSP_TRANSPORT_RTP) {
>
> + ff_rtp_seek_flush(rt->cur_transport_priv);
>
> + } else if (CONFIG_RTPDEC && rt->ts) {
>
> + av_freep(&rt->recvbuf);
Is it necessary to free rt->recvbuf?
>
> + rt->recvbuf_pos = 0;
>
> + rt->recvbuf_len = 0;
>
> + ff_mpegts_seek_flush(rt->ts);
>
> + }
>
> +
>
> return 0;
>
> }
>
> --
>
> 2.25.1
>
>
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
next reply other threads:[~2022-12-29 3:43 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-29 3:43 tanwei (D) [this message]
2022-12-29 5:34 ` "zhilizhao(赵志立)"
2022-12-29 8:06 ` tanwei (D)
-- strict thread matches above, loose matches on Subject: below --
2022-12-22 3:32 tanwei (D)
2022-12-23 2:34 ` "zhilizhao(赵志立)"
2022-11-15 12:23 [FFmpeg-devel] [PATCH] libavformat/rtspdec.c:flush " tanwei (D)
2022-11-14 7:46 tanwei (D)
2022-11-14 8:17 ` "zhilizhao(赵志立)"
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ecaa3df57d1c40c495d8113241f55797@hisilicon.com \
--to=tanwei123@hisilicon.com \
--cc=ffmpeg-devel@ffmpeg.org \
--cc=steven.ling@hisilicon.com \
--cc=wujian2@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
This inbox may be cloned and mirrored by anyone:
git clone --mirror https://master.gitmailbox.com/ffmpegdev/0 ffmpegdev/git/0.git
# If you have public-inbox 1.1+ installed, you may
# initialize and index your mirror using the following commands:
public-inbox-init -V2 ffmpegdev ffmpegdev/ https://master.gitmailbox.com/ffmpegdev \
ffmpegdev@gitmailbox.com
public-inbox-index ffmpegdev
Example config snippet for mirrors.
AGPL code for this site: git clone https://public-inbox.org/public-inbox.git