Av1an does not keep source colorspace, primaries, or pix_fmt

[FlyingWombat]

Av1an does not keep the source colorspace,primaries, or pix_fmt in the output. For example, here is mkvinfo output for an HDR video before and after encoding with av1an. Any source that doesn't use the standard HD bt709 colorspace, will be encoded wrong.
Input:

|  + Video track
|   + Pixel width: 3840
|   + Pixel height: 2160
|   + Video color information
|    + Color transfer: 16
|    + Color matrix coefficients: 9
|    + Color primaries: 9
|    + Color range: 1
|    + Horizontal chroma siting: 1
|    + Vertical chroma siting: 1
|  + Codec's private data: size 2618 (HEVC profile: Main 10 @L5.1)

Output:

|  + Video track
|   + Pixel width: 3840
|   + Pixel height: 2160
|   + Display width: 3840
|   + Display height: 2160
|  + Codec's private data: size 18

ffprobe shows:
Input:

Video: hevc (Main 10), yuv420p10le(tv, bt2020nc/bt2020/smpte2084), 3840x2160, SAR 1:1 DAR 16:9, 23.98 fps, 23.98 tbr, 1k tbn (default)

Output:

Video: av1 (Main), yuv420p10le(tv), 3840x2160, SAR 1:1 DAR 16:9, 23.98 fps, 23.98 tbr, 1k tbn (default)

These values should always be the same in the encode as in the source. If the user wants to change it, using the --ffmpeg parameter to setup an ffmpeg filter pipe that does this should suffice.

---

Also there is no way to keep source pixel format, because the default option yuv420p10le.
While I agree that the majority of people will probably want 420 subsampling (simply because most sources are already subsampled), anyone with a full chroma source will likely want to keep it that way. With the default setting of yuv420p10le, users that have full chroma sources will unwittingly subsample their encodes.

I propose having --depth and --yuv arguments, similar to libavif's avifenc, that each default to the source's value (e.g. a yuv420p10le source would result in --depth 10 and --yuv 420 set automatically). These can be used independently, and together will select the pixel format sent to ffmpeg. If a user wants to always have 10-bit encoding, simply setting --depth 10 in their av1an parameters will accomplish this.

This part is similar to an old issue, #186 , and it seems like that was only closed because the OP lost interest.

[pat-e]

When you are using AomEnc as encoder (-e aom) you must add the following parameters in the "-v" (video parameters) - section:

" --bit-depth=10 --color-primaries=bt2020 --transfer-characteristics=smpte2084 --matrix-coefficients=bt2020ncl "

[trixoniisama]

When you are using AomEnc as encoder (-e aom) you must add the following parameters in the "-v" (video parameters) - section:

" --color-primaries=bt2020 --transfer-characteristics=smpte2084 --matrix-coefficients=bt2020ncl "

If you read carefully I believe OP is asking for automatic detection and application ^^

[pat-e]

When you are using AomEnc as encoder (-e aom) you must add the following parameters in the "-v" (video parameters) - section:
" --color-primaries=bt2020 --transfer-characteristics=smpte2084 --matrix-coefficients=bt2020ncl "

If you read carefully I believe OP is asking for automatic detection and application ^^

Sorry, I did not read through the lines ... I thought the user did not understand that av1an is not an encoder, more just a "tool" to split the source file into multiple parts and then send each parts to the selected encoder to allow "multi-core-processing" by just using more encoder-processes ...

Or I just misunderstand the tool completely...

[trixoniisama]

No you are right, but under the hood, av1an does a lot of detection to automatically provide parameters to the encoders depending on the source characteristics, but color primaries is not one of them. I agree that it would be pretty convenient to have that added at some point.

[pat-e]

It should be a switchable "default":

• if no parameters is given, it will "copy" the color-data from the source to the destination-encoder
• with a parameter, you can disable the "color-data-transfer" (for example if you use a ffmpeg - parameters to do a HDR to SDR - conversion)

[FlyingWombat]

The problem is that these properties are not automatically kept between source and encode with av1an. ffmpeg on its own, automagically makes sure all such things are kept between source and encode, but because av1an breaks up the encoding pipeline (for chunked encoding), av1an needs to make sure everything is set properly. Otherwise some users will have no idea they making bad encodes.