[feature request] Implement AV1 support

First and foremost: Yes it is still a draft and you may of course reject this idea, but due to it already having player support (Kodi on FireTV Max), seeming relatively straight forward (is seems to be based on the already existing ITU-T T.35 Metadata/SMPTE ST 2094-40) and seeming relatively stable for a few months, I feel like this would be a great addition as it allows conversion of existing h265 content to AV1 (or back if needed, although currently it doesn't seem like there's a lot of content).

Specification (draft): https://aomediacodec.github.io/av1-hdr10plus/
Sample file I have verified working (HDR10+ metadata arriving at the TV) with Kodi (Nexus) on my FireTV Max: https://github.com/AOMediaCodec/av1-hdr10plus/blob/ecdafef3eaf104135a6b28aabd960552e8209c7d/HDR10_SIZZLE_PLUS_UP-FINAL_02_AV1.mp4
AV1 bitstream parser library: https://github.com/yohhoy/av1parser

The bitstream parser above seems to already support ITU-T T.35 metadata and your code already supports the parsing of the metadata from bytes from (hopefully) the same format. So in theory it should be as easy as "only" creating some conditions to support more than one codec and some verification that it works. One additional problem might arise from the seeming lack of a .av1 format or something similar, all the AV1 people seem to be using .ivf files (that also seem to be really low overhead over a raw bitstream), but luckily there seems to be a rust implementation from rav1e. I have considered trying to integrate it myself, but as I lack knowledge of the format of the metadata the chances of success would be pretty low.

See yohhoy/av1parser#14

I don't have any plan to support AV1 until the spec is finalized.
Ideally we also need an encoder with support as reference.

xiph/rav1e#3000 should be working fine to generate test streams.
I'm not sure when I'll get around to this.

Happy to test stuff, with Kodi, the FireTV and Panasonic OLED, I can actually test whether HDR10+ metadata is arriving at the TV (and it already works with AV1 & HDR10+).

Good to know. I can also test on a Samsung TV.

Any news about this?

Nope.

there is support to add hdr10+ to av1 see https://github.com/HandBrake/HandBrake/blob/master/NEWS.markdown

also any plans to extract hdr10plus from vp9?

the official spec has reached a state where i believe you can now implement it.
https://aomediacodec.github.io/av1-hdr10plus/

The complexity isn't in the HDR10+ spec but rather parsing AV1 bitstreams.
There aren't stateful parsers that are usable so I'd probably have to implement one from scratch.

https://gstreamer.freedesktop.org/documentation/gst-plugins-bad-codecparsers/gstav1parser.html?gi-language=c I think Gstreamer is also available in Rust. Could that be an option?

GStreamer implies an additionnal dependency at runtime and I'd rather avoid that since it's more complicated for end users.
I also can't seem to find Rust bindings to the codec parsers plugin, anyways.

handbrake seems to have a semi-functional system in place. my phone properly detects and decodes av1 hdr10+ videos, although mediainfo only reports hdr10.

my phone properly detects and decodes av1 hdr10+ videos

Do you have any good way to test that? In the past I've found you can't really tell well on the phone, except maybe with your eyes, although that's hard-ish to see.

The spec is finalized and Netflix is even shipping AV1 HDR10+ content now.

@quietvoid

The spec is finalized and Netflix is even shipping AV1 HDR10+ content now.

And how does Netflix inject hdr10+.json metadata into the AV1 stream? Do they use svt-av1-psy? AFAIK this is the only way for now with --hdr10plus-json option, using quietvoid's own hdr10plus lib.

@quietvoid why isn't --hdr10plus-json option pushed to main svt-av1 so everybody can use it with ffmpeg?

why isn't --hdr10plus-json option pushed to main svt-av1 so everybody can use it with ffmpeg?

do you volunteer to do it? patches welcome
either way the option requiring a file is incompatible with FFmpeg

either way the option requiring a file is incompatible with FFmpeg

ffmpeg's -x265-params dhdr10-info <filename> option of libx265 encoder can use external file for hdr10+ metadata. Why not the same with libsvtav1 and svtav1-params with ffmpeg? Can't svt-av1 add hdr10plus lib as well as ffmpeg for building?

do you volunteer to do it? patches welcome

Well, it seems you helped svt-av1-psy team with hdr10plus lib to implement it. Now that their repo is archived, and seeing you don't preview a parser from scratch, it would be nice to add it to main svt-av1 encoder in the meantime. I wish I could😌. Maybe svt-av1-psy team will push? You know parsing HEVC already.

I feel many are longing for hdr10+ metadata support to av1. If Netflix can do it, why not we?💪

At DRX-Lab, we are working on an experimental implementation related to HDR10+ support for AV1. There are still areas under development: the extract and remove functionalities are currently operational, while inject is still a work in progress.

The project was developed using hdr10plus_tool by quietvoid as a reference, adapting its approach to the specifics of the AV1 bitstream.

We hope this can serve as a reference or starting point for future implementations:
https://github.com/DRX-Lab/hdr10plus_tool-av1

It's been some time now. Is there any chance you'll be able to implement av1 bitstream parsing? Just being able to extract hdr10+ metadata from av1 sources without additional tools would be very helpful.

I have two open pull requests for this: #126 here, and quietvoid/dovi_tool#424 for dovi_tool. Following the feedback in #116, the AV1 parsing and I/O live in a separate crate, av1_parser.

Extraction and injection both work now. extract reads AV1 as an OBU stream, IVF, Matroska or piped input; inject writes into OBU streams and IVF files; remove works as well. dovi_tool does the same with extract-rpu, inject-rpu and remove.

Whether and in what form this lands here is up to quietvoid. If you'd rather not wait, you can build it from my fork:

git clone -b feat/av1-parser https://github.com/sven-pke/hdr10plus_tool
cd hdr10plus_tool
cargo build --release

dovi_tool builds the same way from sven-pke/dovi_tool, same branch.

As above, there is a fork.
I have no plans to merge the feature as is because it does not align with my future plans of unifying the I/O for multiple codecs support.

Thanks for the clear answer - understood, it's your call. And thanks for dovi_tool and hdr10plus_tool in the first place; the AV1 work builds directly on them.

In case it's useful for those plans: the parsing in av1_parser doesn't depend on its I/O, which sits behind the av1_io feature, so it could build on a shared I/O layer instead. If you settle on a design for that, I'm happy to adapt the crate or help with the AV1 side. Until then it stays available in my fork.

Should I close #126 and quietvoid/dovi_tool#424, or would you rather keep them open for reference?

One more thought, entirely without pressure: I know that larger outside contributions mean a lot of review and maintenance on your side. If it would be easier, I'd be glad to start something new together with you - for example the shared multi-codec I/O you mentioned, as a separate crate where you have the final say - and do the groundwork for the AV1 part. And if that isn't something you're interested in, no problem at all.

It's something I would rather figure out myself.

Navigation Menu

Repository navigation

[feature request] Implement AV1 support #50

8 remaining items

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

[feature request] Implement AV1 support #50

Description

Activity

quietvoid commented on May 7, 2022

quietvoid commented on Jan 18, 2023

cromefire commented on Jan 18, 2023

quietvoid commented on Jan 18, 2023

sven-pke commented on Jun 13, 2023

quietvoid commented on Jun 13, 2023

thePublicer commented on Aug 29, 2023

thePublicer commented on Aug 30, 2023

JaitinPrakash commented on Nov 8, 2023

quietvoid commented on Nov 8, 2023

sven-pke commented on Nov 9, 2023

quietvoid commented on Nov 9, 2023

JaitinPrakash commented on Dec 1, 2023

cromefire commented on Dec 1, 2023

8 remaining items

jonathanspw commented on Mar 30, 2025

wyup commented on Jul 15, 2025

quietvoid commented on Jul 15, 2025

wyup commented on Jul 15, 2025

DRX-Lab commented on Jan 4, 2026

Ironclad17 commented on Oct 20, 2026

sven-pke commented on Oct 20, 2026

quietvoid commented on Oct 20, 2026

sven-pke commented on Oct 20, 2026

sven-pke commented on Oct 20, 2026

quietvoid commented on Oct 20, 2026

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions