Michael Henrik Bodenhoff via ffmpeg-devel:
> Hi Andrey ,
>
> "when the decoder is set up to ignore B frames"
>
> How do you do that ?
>
> We must have missed something while we tried using FFmpeg, because we
> couldn't find a way of telling the decoder to ignore B frames, we actually
> got
evelopment discussions and patches
Subject: Re: [FFmpeg-devel] Flushing while decoding , but need already decoded
frames
[You don't often get email from andrey.tur...@gmail.com. Learn why this is
important at https://aka.ms/LearnAboutSenderIdentification ]
Have to say, this issue has been a long
Quoting Andrey Turkin (2024-05-24 13:39:15)
> 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;
This only holds for pre-h264 codecs.
--
Anton Khirnov
Hi,
On Fri, May 24, 2024 at 7:39 AM Andrey Turkin
wrote:
> 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
>
Frame threading?
Ronald
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
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
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 )
