| Message ID | 20230517102029.541-22-anton@khirnov.net |
|---|---|
| State | Accepted |
| Commit | 5fa00b38e6627578a95af9ed0cc6cd441f0903c6 |
| Headers | show |
| Series | [FFmpeg-devel,01/36] fftools/ffmpeg: shorten a variable name | expand |
| Context | Check | Description |
|---|---|---|
| yinshiyou/make_loongarch64 | success | Make finished |
| yinshiyou/make_fate_loongarch64 | fail | Make fate failed |
On Wed, 2023-05-17 at 12:20 +0200, Anton Khirnov wrote: > This special handling for decoder flushing has not been needed since > af1761f7b5, as the filtergraph actually is drained after that commit. > --- > fftools/ffmpeg.c | 11 ----------- > 1 file changed, 11 deletions(-) > > diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c > index 9d554e2fb0..49313edebc 100644 > --- a/fftools/ffmpeg.c > +++ b/fftools/ffmpeg.c > @@ -1418,17 +1418,6 @@ static int process_input_packet(InputStream > *ist, const AVPacket *pkt, int no_eo > if (!got_output) > break; > > - // During draining, we might get multiple output frames in > this loop. > - // ffmpeg.c does not drain the filter chain on configuration > changes, > - // which means if we send multiple frames at once to the > filters, and > - // one of those frames changes configuration, the buffered > frames will > - // be lost. This can upset certain FATE tests. > - // Decode only 1 frame per call on EOF to appease these FATE > tests. > - // The ideal solution would be to rewrite decoding to use > the new > - // decoding API in a better way. > - if (!pkt) > - break; > - Hi, This will drain out HW filter's output frames if it uses fixed number which is less than frame threads of decoder. Decoded frame keep sending to filter in flushing while filtered frames can't be reaped. An example cmd: ffmpeg -threads 20 -v verbose -init_hw_device vaapi=hw:/dev/dri/renderD128 -hwaccel_output_format vaapi -hwaccel vaapi -i avc.mp4 -vf 'scale_va api=w=720:h=480' -f null - ... Error while filtering: Cannot allocate memory Failed to inject frame into filter network: Cannot allocate memory Error while processing the decoded data for stream #0:0 Thanks > repeating = 1; > } >
diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c index 9d554e2fb0..49313edebc 100644 --- a/fftools/ffmpeg.c +++ b/fftools/ffmpeg.c @@ -1418,17 +1418,6 @@ static int process_input_packet(InputStream *ist, const AVPacket *pkt, int no_eo if (!got_output) break; - // During draining, we might get multiple output frames in this loop. - // ffmpeg.c does not drain the filter chain on configuration changes, - // which means if we send multiple frames at once to the filters, and - // one of those frames changes configuration, the buffered frames will - // be lost. This can upset certain FATE tests. - // Decode only 1 frame per call on EOF to appease these FATE tests. - // The ideal solution would be to rewrite decoding to use the new - // decoding API in a better way. - if (!pkt) - break; - repeating = 1; }