Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
 help / color / mirror / Atom feed
From: Philip Langdale <philipl@overt.org>
To: "Xiang, Haihao" <haihao.xiang@intel.com>
Cc: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
Subject: Re: [FFmpeg-devel] [PATCH 1/3] lavu/pixfmt: Add Y216, Y410, and Y416 formats
Date: Mon, 15 Aug 2022 16:06:55 -0700
Message-ID: <20220815160655.6476444d@app.nyansa.com> (raw)
In-Reply-To: <20220815104211.573ed7ef@app.nyansa.com>

On Mon, 15 Aug 2022 10:42:11 -0700
Philip Langdale <philipl@overt.org> wrote:

> On Mon, 15 Aug 2022 06:12:20 +0000
> "Xiang, Haihao" <haihao.xiang-at-intel.com@ffmpeg.org> wrote:
> 
> > 
> > Hi Philip,
> > 
> > May we add new formats P012, Y212 and Y412 for 12bit contents ? I
> > agree with Mark's comment in 
> > https://patchwork.ffmpeg.org/project/ffmpeg/patch/20200619015248.21873-1-fei.w.wang@intel.com/
> >  
> > 
> > "
> > Tracking it separately does not seem fun - it looks to me like it
> > would require adding a new bit depth field to AVFrame.
> > 
> > FFmpeg has always used pixfmt as defining both the memory layout and
> > which bits are used in that (so, for example, ARGB and 0RGB are not
> > the same thing), unlike most of the graphics APIs which tend to 
> > define those two separately.
> > "  
> 
> I went through this same conversation a few years ago around the
> behaviour of nvdec, which uses p016 and yuv444p16 for 12bit content.
> All the same arguments were made about not introducing new pixel
> formats to just indicate stream depth and how we could add a new
> attribute but it would be a bunch of work, and to avoid bogging down
> and doing nothing, I just had nvdec/nvenc work with P016 (and
> honestly, nvidia don't even use P010 internally, it's P016 for >=
> 10bit) and it was fine. On the decoder side, there's no real problem,
> and on the encoder side, I think the key insight is that the encoder
> doesn't encoder to the frame's pixel format depth, it encodes to the
> depth _specified by the profile_. So even if you give it real 16bit
> frames in P016, if you are encoding Main12, you are going to get
> 12bit. Same for any future Main14. I'd argue this is the most correct
> way to handle it anyway. If the default profile we guess based on
> format isn't right, specify the one you actually want.

Hi Hai Hao,

So, Mark has pointed out to me that this isn't the same situation as
nvidia, because the driver is actually exposing support for specific
P012, Y212, Y412 formats. I didn't realise this, which is why I took
the approach I did.

With this new information, I will redo it to add those formats instead
of the 16bit ones (which don't have a reason to exist in ffmpeg for
now).

Thanks!

--phil
_______________________________________________
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-08-15 23:07 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-14 21:33 [FFmpeg-devel] [PATCH 0/3] V2: VAAPI: Add high bit depth encode/decode support Philip Langdale
2022-08-14 21:33 ` [FFmpeg-devel] [PATCH 1/3] lavu/pixfmt: Add Y216, Y410, and Y416 formats Philip Langdale
2022-08-15  6:12   ` Xiang, Haihao
2022-08-15 17:42     ` Philip Langdale
2022-08-15 23:06       ` Philip Langdale [this message]
2022-08-14 21:33 ` [FFmpeg-devel] [PATCH 2/3] lavc/vaapi: Add support for remaining 10/12bit profiles Philip Langdale
2022-08-15 22:10   ` Michael Niedermayer
2022-08-15 22:23     ` Philip Langdale
2022-08-16 17:29       ` Michael Niedermayer
2022-08-16 19:52         ` Philip Langdale
2022-08-16 19:55           ` Philip Langdale
2022-08-17 14:34             ` Michael Niedermayer
2022-08-14 21:33 ` [FFmpeg-devel] [PATCH 3/3] lavu/hwcontext_[vaapi|vulkan]: support mapping VUYA and Y416 Philip Langdale

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=20220815160655.6476444d@app.nyansa.com \
    --to=philipl@overt.org \
    --cc=ffmpeg-devel@ffmpeg.org \
    --cc=haihao.xiang@intel.com \
    /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