From: Andrey Turkin <andrey.turkin@gmail.com>
To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
Subject: Re: [FFmpeg-devel] Flushing while decoding , but need already decoded frames
Date: Fri, 24 May 2024 14:39:15 +0300
Message-ID: <CAA7-ZooQkhzdRaktyKFhA-1WQ2kD3WsJ_LY-b+-grNBjL5=nNg@mail.gmail.com> (raw)
In-Reply-To: <GV1P250MB07378DBBE20E65BE44881A6D8FF52@GV1P250MB0737.EURP250.PROD.OUTLOOK.COM>
Have to say, this issue has been a long grievance of mine. There is no
reason to delay frames when the decoder is set up to ignore B frames
as there is no reordering to be done; ideally this should be
zero-delay case (packet goes in, frame goes out) yet the most common
decoders delay frames anyway, as if to decode B frames. Moreover, with
the "new" send/receive API I think there is no reason to delay frames
at all - a single send_packet could decode and queue multiple frames
to be received, so it makes sense to send frames as soon as possible -
yet that is not the case as well.
пт, 24 мая 2024 г. в 13:17, Andreas Rheinhardt <andreas.rheinhardt@outlook.com>:
>
> Michael Henrik Bodenhoff via ffmpeg-devel:
> > Hi ,
> >
> > my team recently had to abandon switching to using FFmpeg from specific decoder implementations (NvDEC, Intel Media SDK , IPP and quite a few codec specific decoders) because of big performance issues because of the way FFmpeg works….. or at least we think it is (we’re FFmpeg noobs 😃 )
> >
> > It's actually an issue we also had with Intel Media SDK, leading us to pay Intel to extend Media SDK to do what we needed.
> >
> > Our product is a video surveillance system, and that means we have to decode a LOT of video streams simultaneously.
> >
> > For motion detection we want to only decode keyframes, and skip P and B frames , and that works fine with FFmpeg most of the time, except for when the video stream contains B frames.
> > Without B-Frames it’s really simple (simplified pseudocode) :
> >
> > while(true)
> > {
> > receiveStreamCompleteFrame();
> > If(KeyFrame)
> > {
> > avcodec_send_packet();
> > if(avcodec_receive_frame()==0)
> > {
> > // do motion detection
> > }
> > }
> > }
> >
> > But! with B Frames FFmpeg doesn’t return keyframes when they are decoded, they are kept, and we can’t seem to flush them out. avcodec_flush_buffers allow us to continue to next keyframe, but it doesn’t seem to give us the keyframe we just gave to FFmpeg with avcodec_send_packet.
> >
> > while(true)
> > {
> > receiveStreamCompleteFrame();
> > If(KeyFrame)
> > {
> > avcodec_send_packet();
> > if(avcodec_receive_frame()==0)
> > {
> > // do motion detection
> > }
> > Else
> > {
> > avcodec_flush_buffers();
> > if(avcodec_receive_frame()==0)
> > {
> > // do motion detection
> > }
> > }
> > }
> > }
> >
> > Calling avcodec_receive_frame after calling avcodec_flush_buffer results in -11 and no frame
> >
> > is there anyway around this ? And if not, could FFmpeg be made to have this functionality ?
> >
> > I tried contacting one of the FFmpeg consultants from https://ffmpeg.org/consulting.html but never got a response
> >
>
> Send your packet with the keyframe, send a NULL packet (to signal EOF),
> then the internally stored frames should be output by
> avcodec_receive_frame(). Then flush the decoder (to be able to send new
> packets to it).
>
> - Andreas
>
> _______________________________________________
> 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 prev parent reply other threads:[~2024-05-24 11:39 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-24 9:35 Michael Henrik Bodenhoff via ffmpeg-devel
2024-05-24 10:02 ` Andreas Rheinhardt
2024-05-24 11:39 ` Andrey Turkin [this message]
2024-05-24 12:20 ` Ronald S. Bultje
2024-05-24 12:52 ` Anton Khirnov
2024-05-24 13:16 ` Michael Henrik Bodenhoff via ffmpeg-devel
2024-05-24 13:35 ` Andreas Rheinhardt
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='CAA7-ZooQkhzdRaktyKFhA-1WQ2kD3WsJ_LY-b+-grNBjL5=nNg@mail.gmail.com' \
--to=andrey.turkin@gmail.com \
--cc=ffmpeg-devel@ffmpeg.org \
/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