Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
 help / color / mirror / Atom feed
From: Soft Works <softworkz@hotmail.com>
To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
Subject: Re: [FFmpeg-devel] Enhancement layers in FFmpeg
Date: Mon, 1 Aug 2022 13:17:12 +0000
Message-ID: <DM8P223MB03652357059A5B176B29C88CBA9A9@DM8P223MB0365.NAMP223.PROD.OUTLOOK.COM> (raw)
In-Reply-To: <20220801132452.GB41618@haasn.xyz>



> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
> Niklas Haas
> Sent: Monday, August 1, 2022 1:25 PM
> To: ffmpeg-devel@ffmpeg.org
> Subject: [FFmpeg-devel] Enhancement layers in FFmpeg
> 
> Hey,
> 
> We need to think about possible ways to implement reasonably-
> transparent
> support for enhancement layers in FFmpeg. (SVC, Dolby Vision, ...).
> There are more open questions than answers here.
> 
> From what I can tell, these are basically separate bitstreams that
> carry
> some amount of auxiliary information needed to reconstruct the
> high-quality bitstream. That is, they are not independent, but need
> to
> be merged with the original bitstream somehow.
> 
> How do we architecturally fit this into FFmpeg? Do we define a new
> codec
> ID for each (common/relevant) combination of base codec and
> enhancement
> layer, e.g. HEVC+DoVi, H.264+SVC, ..., or do we transparently handle
> it
> for the base codec ID and control it via a flag? Do the enhancement
> layer packets already make their way to the codec, and if not, how do
> we
> ensure that this is the case?
> 
> Can the decoder itself recursively initialize a sub-decoder for the
> second bitstream? And if so, does the decoder apply the actual
> transformation, or does it merely attach the EL data to the AVFrame
> somehow in a way that can be used by further filters or end users?

From my (rather limited) angle of view, my thoughts are these:

When decoding these kinds of sources, a user would typically not only
want to do the processing in hardware but the decoding as well.

I think we cannot realistically expect that any of the hw decoders
will add support for this in the near future. As we cannot modify 
those ourselves, the only way to do such processing would be a 
hardware filter. I think, the EL data would need to be attached 
to frames as some kind of side data (or similar) and get uploaded 
by the hw filter (internally) which will apply the EL data.


(I have no useful thoughts for sw decoding) 


> (What about the case of Dolby Vision, which iirc requires handling
> the
> DoVi RPU metadata before the EL can be applied? What about instances
> where the user wants the DoVi/EL application to happen on GPU, e.g.
> via
> libplacebo in mpv/vlc?)

IMO it would be desirable when both of these things would/could be
done in a single operation.

> How does this metadata need to be attached? A second AVFrame
> reference
> inside the AVFrame? Raw data in a big side data struct?

As long as it doesn't have its own format, its own start time,
resolution, duration, color space/transfer/primaries, etc..
I wouldn’t say that it's a frame.

Best regards,
softworkz
_______________________________________________
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-01 13:17 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-01 11:24 Niklas Haas
2022-08-01 13:17 ` Soft Works [this message]
2022-08-01 13:58   ` Niklas Haas
2022-08-01 14:26     ` Soft Works
2022-08-01 13:45 ` Hendrik Leppkes

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=DM8P223MB03652357059A5B176B29C88CBA9A9@DM8P223MB0365.NAMP223.PROD.OUTLOOK.COM \
    --to=softworkz@hotmail.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