From: "Miller, Adrian" <adrian.miller@warnermedia.com>
To: "ffmpeg-devel@ffmpeg.org" <ffmpeg-devel@ffmpeg.org>
Subject: [FFmpeg-devel] Proposed change to NVDEC ulNumOutputSurfaces initialization
Date: Tue, 14 Feb 2023 17:27:39 +0000
Message-ID: <SN6PR07MB785337AE523D282F6D714686E0DD9@SN6PR07MB7853.namprd07.prod.outlook.com> (raw)
Hi,
I'm considering a proposing a change to libavcodec/nvdec.c but wanted to run it by you first as I'm new to FFmpeg development to make sure I've gotten things right (this is not a patch).
We use the NVDEC decoder as part of our live transcoder. This means that new decoders may be spun up to accommodate switching sources but the frames_ctx->initial_pool_size is calculated based on values from the source's initial SPS and the decoder's "extra_hw_frames" option, so it's possible that a new source will result in an SPS+extra_hw_frames value greater than the max supported by the NVDEC decoder, 32.
The current behavior is to return if the NVDEC decoder fails to initialize and return a warning (nvdec.c:413). I'm sure this is fine in the interactive use case where the user can simply provide a smaller value for extra_hw_frames and try again. In the unattended case this isn't possible, and our application fails.
I was thinking something along the lines of in nvdec.c to handle this case:
- params.ulNumDecodeSurfaces = frames_ctx->initial_pool_size;
- params.ulNumOutputSurfaces = frames_ctx->initial_pool_size;
+ const int kMaxSurfaces = 32;
+ params.ulNumDecodeSurfaces = (frames_ctx->initial_pool_size <= kMaxSurfaces) ? frames_ctx->initial_pool_size : kMaxSurfaces;
+ params.ulNumOutputSurfaces = params.ulNumDecodeSurfaces;
+ if (frames_ctx->initial_pool_size > kMaxSurfaces) {
+ av_log(avctx, AV_LOG_WARNING, "Requested %d decode surfaces, which is more than %d. Condifuring decoder with %d surfaces.\n",
+ (int)frames_ctx->initial_pool_size, kMaxSurfaces, (int)params.ulNumDecodeSurfaces);
+ }
Plus, probably rewording the original warning that handles the case where the decoder still fails.
Thoughts? If this seems like a reasonable approach I'll put together a formal patch email after going through the rest of your submission process and the stuff I have to do for my employer.
Thanks,
Ade Miller
_______________________________________________
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:[~2023-02-14 17:27 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-14 17:27 Miller, Adrian [this message]
2023-02-14 18:37 ` Timo Rothenpieler
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=SN6PR07MB785337AE523D282F6D714686E0DD9@SN6PR07MB7853.namprd07.prod.outlook.com \
--to=adrian.miller@warnermedia.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