Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
 help / color / mirror / Atom feed
From: Diego Felix de Souza via ffmpeg-devel <ffmpeg-devel@ffmpeg.org>
To: Timo Rothenpieler <timo@rothenpieler.org>,
	FFmpeg development discussions and patches
	<ffmpeg-devel@ffmpeg.org>
Cc: Diego Felix de Souza <ddesouza@nvidia.com>
Subject: Re: [FFmpeg-devel] [PATCH] avcodec/nvenc: High bit depth encoding for HEVC
Date: Thu, 18 Apr 2024 10:43:21 +0000
Message-ID: <PH7PR12MB7188DD4E804DBFEC670D84A3BF0E2@PH7PR12MB7188.namprd12.prod.outlook.com> (raw)
In-Reply-To: <26df08ee-ee02-408a-98ea-ef5fe77c93c7@rothenpieler.org>

Hi Timo,

Thank you for your review. Please check my answers below.

Best regards,

Diego

On 17.04.24, 16:27, "Timo Rothenpieler" <timo@rothenpieler.org> wrote:

External email: Use caution opening links or attachments


On 15/04/2024 16:39, Diego Felix de Souza via ffmpeg-devel wrote:
> From: Diego Felix de Souza <ddesouza@nvidia.com>
>
> Adding 10-bit encoding support for HEVC if the input is 8-bit. In
> case of 8-bit input content, NVENC performs an internal CUDA 8 to
> 10-bit conversion of the input prior to encoding. Currently, only
> AV1 supports encoding 8-bit content as 10-bit.

I'm not sure about this one.
Since it's just "SW", or rather CUDA based, conversion, this job could
also be done by scale_cuda, outside of some niche formats it doesn't
support yet.
Which would also allow for more consistent command lines across versions.


Although it is a software-based solution, the conversion is integrated with other kernels
inside the driver. In this way, it will demand fewer memory accesses and better Streaming
Multiprocessor (SM) utilization, leading to a improved performance and a lower latency
compared to the scale_cuda approach. Moreover, the proposed approach overall consumes
less memory since it only requires an 8-bit per channel frame as input and no extra 10-bit frames.


> Signed-off-by: Diego Felix de Souza <ddesouza@nvidia.com>
> ---
>   libavcodec/nvenc.c      | 8 ++++----
>   libavcodec/nvenc_hevc.c | 1 +
>   2 files changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/libavcodec/nvenc.c b/libavcodec/nvenc.c
> index 794174a53f..c302cc7dc4 100644
> --- a/libavcodec/nvenc.c
> +++ b/libavcodec/nvenc.c
> @@ -514,7 +514,7 @@ static int nvenc_check_capabilities(AVCodecContext *avctx)
>       }
>
>       ret = nvenc_check_cap(avctx, NV_ENC_CAPS_SUPPORT_10BIT_ENCODE);
> -    if (IS_10BIT(ctx->data_pix_fmt) && ret <= 0) {
> +    if ((IS_10BIT(ctx->data_pix_fmt) || ctx->highbitdepth) && ret <= 0) {
>           av_log(avctx, AV_LOG_WARNING, "10 bit encode not supported\n");
>           return AVERROR(ENOSYS);
>       }
> @@ -1421,7 +1421,7 @@ static av_cold int nvenc_setup_hevc_config(AVCodecContext *avctx)
>       }
>
>       // force setting profile as main10 if input is 10 bit
> -    if (IS_10BIT(ctx->data_pix_fmt)) {
> +    if (IS_10BIT(ctx->data_pix_fmt) || ctx->highbitdepth) {

Won't this need guarded behind the NVENC_HAVE_NEW_BIT_DEPTH_API as well?
Or would this also work fine with older headers, by just setting this?

For older SDK versions, the HEVC main 10 profile would be selected, but the encoded bitstream
would be still 8-bits. For the sake of consistence and clarity, I will put it behind the
NVENC_HAVE_NEW_BIT_DEPTH_API as you suggested.

>           cc->profileGUID = NV_ENC_HEVC_PROFILE_MAIN10_GUID;
>           avctx->profile = AV_PROFILE_HEVC_MAIN_10;
>       }
> @@ -1435,8 +1435,8 @@ static av_cold int nvenc_setup_hevc_config(AVCodecContext *avctx)
>       hevc->chromaFormatIDC = IS_YUV444(ctx->data_pix_fmt) ? 3 : 1;
>
>   #ifdef NVENC_HAVE_NEW_BIT_DEPTH_API
> -    hevc->inputBitDepth = hevc->outputBitDepth =
> -        IS_10BIT(ctx->data_pix_fmt) ? NV_ENC_BIT_DEPTH_10 : NV_ENC_BIT_DEPTH_8;
> +    hevc->inputBitDepth = IS_10BIT(ctx->data_pix_fmt) ? NV_ENC_BIT_DEPTH_10 : NV_ENC_BIT_DEPTH_8;
> +    hevc->outputBitDepth = (IS_10BIT(ctx->data_pix_fmt) || ctx->highbitdepth) ? NV_ENC_BIT_DEPTH_10 : NV_ENC_BIT_DEPTH_8;
>   #else
>       hevc->pixelBitDepthMinus8 = IS_10BIT(ctx->data_pix_fmt) ? 2 : 0;
>   #endif
> diff --git a/libavcodec/nvenc_hevc.c b/libavcodec/nvenc_hevc.c
> index b949cb1bd7..02e9c9c8eb 100644
> --- a/libavcodec/nvenc_hevc.c
> +++ b/libavcodec/nvenc_hevc.c
> @@ -183,6 +183,7 @@ static const AVOption options[] = {
>       { "fullres",      "Two Pass encoding is enabled where first Pass is full resolution",
>                                                               0,                    AV_OPT_TYPE_CONST, { .i64 = NV_ENC_TWO_PASS_FULL_RESOLUTION },    0,                          0,                               VE, .unit = "multipass" },
>   #endif
> +    { "highbitdepth", "Enable 10 bit encode for 8 bit input",OFFSET(highbitdepth),AV_OPT_TYPE_BOOL,  { .i64 = 0 }, 0, 1, VE },

Same question as above, does this always work, even without the new bit
depth API?
If not, it also needs the #ifdef.

Same as above, it would give the wrong impression to the user. I will put it behind the NVENC_HAVE_NEW_BIT_DEPTH_API.

>   #ifdef NVENC_HAVE_LDKFS
>       { "ldkfs",        "Low delay key frame scale; Specifies the Scene Change frame size increase allowed in case of single frame VBV and CBR",
>                                                               OFFSET(ldkfs),        AV_OPT_TYPE_INT,   { .i64 = 0 }, 0, UCHAR_MAX, VE },
> --
> 2.34.1
>
> -----------------------------------------------------------------------------------
> NVIDIA GmbH
> Wuerselen
> Amtsgericht Aachen
> HRB 8361
> Managing Directors: Rebecca Peters, Donald Robertson, Janet Hall, Ludwig von Reiche
>
> -----------------------------------------------------------------------------------
> This email message is for the sole use of the intended recipient(s) and may contain
> confidential information.  Any unauthorized review, use, disclosure or distribution
> is prohibited.  If you are not the intended recipient, please contact the sender by
> reply email and destroy all copies of the original message.
> -----------------------------------------------------------------------------------
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fffmpeg.org%2Fmailman%2Flistinfo%2Fffmpeg-devel&data=05%7C02%7Cddesouza%40nvidia.com%7Cd750b65e093d40e8dd5508dc5eea7d53%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C0%7C638489608435687923%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=2F9CxnKyADs6zW1faiZhXQa1FzfcVRKxMJQ8ukoN0nY%3D&reserved=0<https://ffmpeg.org/mailman/listinfo/ffmpeg-devel>
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

-----------------------------------------------------------------------------------
NVIDIA GmbH
Wuerselen
Amtsgericht Aachen
HRB 8361
Managing Directors: Rebecca Peters, Donald Robertson, Janet Hall, Ludwig von Reiche

-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain
confidential information.  Any unauthorized review, use, disclosure or distribution
is prohibited.  If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------
_______________________________________________
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".

  reply	other threads:[~2024-04-18 10:44 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-15 14:39 Diego Felix de Souza via ffmpeg-devel
2024-04-17 14:27 ` Timo Rothenpieler
2024-04-18 10:43   ` Diego Felix de Souza via ffmpeg-devel [this message]
2024-04-18 12:29     ` Roman Arzumanyan
2024-04-18 13:33       ` Timo Rothenpieler
2024-04-19  7:39         ` Roman Arzumanyan
2024-04-19  8:33           ` Diego Felix de Souza via ffmpeg-devel
2024-04-19  8:38 ` [FFmpeg-devel] [PATCH v2] " Diego Felix de Souza via ffmpeg-devel
2024-04-19 11:29   ` Lynne
2024-04-19 11:55     ` Timo Rothenpieler
2024-04-24 22:43   ` 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=PH7PR12MB7188DD4E804DBFEC670D84A3BF0E2@PH7PR12MB7188.namprd12.prod.outlook.com \
    --to=ffmpeg-devel@ffmpeg.org \
    --cc=ddesouza@nvidia.com \
    --cc=timo@rothenpieler.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