Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
 help / color / mirror / Atom feed
From: James Almer <jamrial@gmail.com>
To: ffmpeg-devel@ffmpeg.org
Subject: Re: [FFmpeg-devel] [PATCH] avcodec: add D3D12VA hardware accelerated H264, HEVC, VP9, and AV1 decoding
Date: Thu, 13 Oct 2022 13:04:21 -0300
Message-ID: <58ed0f9c-5c1d-885a-ba12-c6a9afeefdf1@gmail.com> (raw)
In-Reply-To: <OSZP286MB21733DFD32E20AEAB7457E98CA259@OSZP286MB2173.JPNP286.PROD.OUTLOOK.COM>

On 10/13/2022 12:48 PM, Wu Jianhua wrote:
>> Lynne<mailto:dev@lynne.ee> wrote:
> 
>> Oct 12, 2022, 13:09 by toqsxw@outlook.com:
> 
>>> [PATCH] avcodec: add D3D12VA hardware accelerated H264, HEVC, VP9, and AV1 decoding
>>>
>>> Patch attached.
>>>
> 
>> The Sync locking functions and the queue locking functions should
>> be a function pointer in the device/frame context. Vulkan has
>> the same issue, and that's how I did it there. This allows for
>> API users to plug their own locking primitives in, which they need
>> to in case they initialize their own contexts.
> 
> I don’t need to follow your design.
> 
>> You should also document which fields API users have to set
>> themselves if they plan to use their own context.
> 
> Where should I document them? Doesn’t the comments enough?
> 
>> Also, struct names in the public context lack an AV prefix.
> Will fix. And which struct? Could you add the reference?
> 
>> D3D12VA_MAX_SURFACES is a terrible hack. Vendors should
>> fix their own drivers rather than users running out of memory.
> 
> Not my responsibility as a personal developer. I know nothing
> about the drivers. You can ask those vendors to fix them. I don’t
> think it’s a `terrible hack`. On my test, The MAX_SURFACES is
> enough for the decoder. If there are any docs or the drivers fixed
> it, just simply remove it. Why user will run out of memory?
> 
>> Also, you have code style issues, don't wrap one-line if statements
>> or loops in brackets.
> Will fix. And which loop? Could you add the reference?
> 
>> ff_d3d12dec_get_suitable_max_bitstream_size is an awful function.
>> It does float math for sizes and has a magic mult factor of 1.5.
>> You have to calculate this properly.
> It simply calculate the size of NV12 and P010. Will add comment.

Then you should probably use imgutils.h functions for that, and/or 
AVPixFmtDescriptor from pixdesc.h.

> 
>> On a first look, this is what stands out. Really must be split apart
>> in patches.
> 
> Already claim that I will split it.
> 
> 
> _______________________________________________
> 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".

  reply	other threads:[~2022-10-13 16:04 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <OSZP286MB2173BE661B9E9F1FDBAB4D1DCA229@OSZP286MB2173.JPNP286.PROD.OUTLOOK.COM>
2022-10-12 11:09 ` Wu Jianhua
2022-10-12 15:12   ` Jean-Baptiste Kempf
2022-10-12 15:25     ` James Almer
2022-10-12 16:25       ` Wu Jianhua
2022-10-13 12:37   ` Lynne
2022-10-13 15:48     ` Wu Jianhua
2022-10-13 16:04       ` James Almer [this message]
2022-10-13 16:08         ` Wu Jianhua
2022-10-13 22:28       ` Lynne
2022-10-14 12:32         ` Wu Jianhua
2022-10-15  5:16           ` Lynne
2022-11-11 16:41             ` Wu Jianhua
2022-11-11 16:50             ` Wu Jianhua

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=58ed0f9c-5c1d-885a-ba12-c6a9afeefdf1@gmail.com \
    --to=jamrial@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