AV1 encoder producing incorrect timestamps

[oviano]

I modified hello_encode.cpp to output an AV1 bitstream instead and discovered that the timestamps produced by the encoder are incorrect.

For AV1, PTS and DTS should be the same since there is no re-ordering. I am using an ARC A770 with the latest driver 3820, and oneVPL 2022.2.5 release.

I am trying to solve this bug in FFmpeg, caused by the same issue:

https://trac.ffmpeg.org/ticket/10062

Any help appreciated.

Below is my modified file:

//==============================================================================
// Copyright Intel Corporation
//
// SPDX-License-Identifier: MIT
//==============================================================================

///
/// A minimal oneAPI Video Processing Library (oneVPL) encode application,
/// using 2.x API with internal memory management
///
/// @file

#include "util.h"

#define TARGETKBPS                 4000
#define FRAMERATE                  30
#define OUTPUT_FILE                "out.av1"
#define BITSTREAM_BUFFER_SIZE      2000000
#define MAJOR_API_VERSION_REQUIRED 2
#define MINOR_API_VERSION_REQUIRED 2

void Usage(void) {
    printf("\n");
    printf("   Usage  :  hello-encode\n");
    printf("     -hw        use hardware implementation\n");
    printf("     -sw        use software implementation\n");
    printf("     -i input file name (raw frames)\n");
    printf("     -w input width\n");
    printf("     -h input height\n\n");
    printf("   Example:  hello-encode -i in.i420 -w 320 -h 240\n");
    printf("   To view:  ffplay %s\n\n", OUTPUT_FILE);
    printf(" * Encode raw frames to AV1 elementary stream in %s\n\n", OUTPUT_FILE);
    printf("   CPU native color format is I420/yuv420p.  GPU native color format is "
           "NV12\n");
    return;
}

int main(int argc, char *argv[]) {
    // Variables used for legacy and 2.x
    bool isDraining                = false;
    bool isStillGoing              = true;
    bool isFailed                  = false;
    FILE *sink                     = NULL;
    FILE *source                   = NULL;
    mfxBitstream bitstream         = {};
    mfxFrameSurface1 *encSurfaceIn = NULL;
    mfxSession session             = NULL;
    mfxSyncPoint syncp             = {};
    mfxU32 framenum                = 0;
    mfxStatus sts                  = MFX_ERR_NONE;
    mfxStatus sts_r                = MFX_ERR_NONE;
    Params cliParams               = {};
    mfxVideoParam encodeParams     = {};

    // variables used only in 2.x version
    mfxConfig cfg[3];
    mfxVariant cfgVal[3];
    mfxLoader loader = NULL;

    // Parse command line args to cliParams
    if (ParseArgsAndValidate(argc, argv, &cliParams, PARAMS_ENCODE) == false) {
        Usage();
        return 1; // return 1 as error code
    }

    source = fopen(cliParams.infileName, "rb");
    VERIFY(source, "Could not open input file");

    sink = fopen(OUTPUT_FILE, "wb");
    VERIFY(sink, "Could not create output file");

    // Initialize VPL session
    loader = MFXLoad();
    VERIFY(NULL != loader, "MFXLoad failed -- is implementation in path?");

    // Implementation used must be the type requested from command line
    cfg[0] = MFXCreateConfig(loader);
    VERIFY(NULL != cfg[0], "MFXCreateConfig failed")

    sts =
        MFXSetConfigFilterProperty(cfg[0], (mfxU8 *)"mfxImplDescription.Impl", cliParams.implValue);
    VERIFY(MFX_ERR_NONE == sts, "MFXSetConfigFilterProperty failed for Impl");

    // Implementation must provide an AV1 encoder
    cfg[1] = MFXCreateConfig(loader);
    VERIFY(NULL != cfg[1], "MFXCreateConfig failed")
    cfgVal[1].Type     = MFX_VARIANT_TYPE_U32;
    cfgVal[1].Data.U32 = MFX_CODEC_AV1;
    sts                = MFXSetConfigFilterProperty(
        cfg[1],
        (mfxU8 *)"mfxImplDescription.mfxEncoderDescription.encoder.CodecID",
        cfgVal[1]);
    VERIFY(MFX_ERR_NONE == sts, "MFXSetConfigFilterProperty failed for encoder CodecID");

    // Implementation used must provide API version 2.2 or newer
    cfg[2] = MFXCreateConfig(loader);
    VERIFY(NULL != cfg[2], "MFXCreateConfig failed")
    cfgVal[2].Type     = MFX_VARIANT_TYPE_U32;
    cfgVal[2].Data.U32 = VPLVERSION(MAJOR_API_VERSION_REQUIRED, MINOR_API_VERSION_REQUIRED);
    sts                = MFXSetConfigFilterProperty(cfg[2],
                                     (mfxU8 *)"mfxImplDescription.ApiVersion.Version",
                                     cfgVal[2]);
    VERIFY(MFX_ERR_NONE == sts, "MFXSetConfigFilterProperty failed for API version");

    sts = MFXCreateSession(loader, 0, &session);
    VERIFY(MFX_ERR_NONE == sts,
           "Cannot create session -- no implementations meet selection criteria");

    // Print info about implementation loaded
    ShowImplementationInfo(loader, 0);

    // Initialize encode parameters
    encodeParams.mfx.CodecId                 = MFX_CODEC_AV1;
    encodeParams.mfx.TargetUsage             = MFX_TARGETUSAGE_BALANCED;
    encodeParams.mfx.TargetKbps              = TARGETKBPS;
    encodeParams.mfx.RateControlMethod       = MFX_RATECONTROL_VBR;
    encodeParams.mfx.FrameInfo.FrameRateExtN = FRAMERATE;
    encodeParams.mfx.FrameInfo.FrameRateExtD = 1;
    if (MFX_IMPL_SOFTWARE == cliParams.impl) {
        encodeParams.mfx.FrameInfo.FourCC = MFX_FOURCC_I420;
    }
    else {
        encodeParams.mfx.FrameInfo.FourCC = MFX_FOURCC_NV12;
    }
    encodeParams.mfx.FrameInfo.ChromaFormat = MFX_CHROMAFORMAT_YUV420;
    encodeParams.mfx.FrameInfo.CropW        = cliParams.srcWidth;
    encodeParams.mfx.FrameInfo.CropH        = cliParams.srcHeight;
    encodeParams.mfx.FrameInfo.Width        = ALIGN16(cliParams.srcWidth);
    encodeParams.mfx.FrameInfo.Height       = ALIGN16(cliParams.srcHeight);

    encodeParams.IOPattern = MFX_IOPATTERN_IN_SYSTEM_MEMORY;

    // Initialize encoder
    sts = MFXVideoENCODE_Init(session, &encodeParams);
    VERIFY(MFX_ERR_NONE == sts, "Encode init failed");

    // Prepare output bitstream
    bitstream.MaxLength = BITSTREAM_BUFFER_SIZE;
    bitstream.Data      = (mfxU8 *)calloc(bitstream.MaxLength, sizeof(mfxU8));

    printf("Encoding %s -> %s\n", cliParams.infileName, OUTPUT_FILE);

    printf("Input colorspace: ");
    switch (encodeParams.mfx.FrameInfo.FourCC) {
        case MFX_FOURCC_I420: // CPU input
            printf("I420 (aka yuv420p)\n");
            break;
        case MFX_FOURCC_NV12: // GPU input
            printf("NV12\n");
            break;
        default:
            printf("Unsupported color format\n");
            isFailed = true;
            goto end;
            break;
    }

    mfxU64 next_pts = 0;

    while (isStillGoing == true) {
        // Load a new frame if not draining
        if (isDraining == false) {
            sts = MFXMemory_GetSurfaceForEncode(session, &encSurfaceIn);
            VERIFY(MFX_ERR_NONE == sts, "Could not get encode surface");

            sts = ReadRawFrame_InternalMem(encSurfaceIn, source);
            if (sts != MFX_ERR_NONE)
                isDraining = true;
        }

        encSurfaceIn->Data.TimeStamp = next_pts;
        next_pts += 90000 / FRAMERATE;

        sts = MFXVideoENCODE_EncodeFrameAsync(session,
                                              NULL,
                                              (isDraining == true) ? NULL : encSurfaceIn,
                                              &bitstream,
                                              &syncp);

        if (!isDraining) {
            sts_r = encSurfaceIn->FrameInterface->Release(encSurfaceIn);
            VERIFY(MFX_ERR_NONE == sts_r, "mfxFrameSurfaceInterface->Release failed");
        }
        switch (sts) {
            case MFX_ERR_NONE:
                // MFX_ERR_NONE and syncp indicate output is available
                if (syncp) {
                    // Encode output is not available on CPU until sync operation
                    // completes
                    sts = MFXVideoCORE_SyncOperation(session, syncp, WAIT_100_MILLISECONDS);
                    VERIFY(MFX_ERR_NONE == sts, "MFXVideoCORE_SyncOperation error");

                    printf("bitsream.DecodeTimeStamp = %lld\n", bitstream.DecodeTimeStamp);
                    printf("bitsream.TimeStamp       = %lld\n", bitstream.TimeStamp);

                    WriteEncodedStream(bitstream, sink);
                    framenum++;
                }
                break;
            case MFX_ERR_NOT_ENOUGH_BUFFER:
                // This example deliberatly uses a large output buffer with immediate
                // write to disk for simplicity. Handle when frame size exceeds
                // available buffer here
                break;
            case MFX_ERR_MORE_DATA:
                // The function requires more data to generate any output
                if (isDraining == true)
                    isStillGoing = false;
                break;
            case MFX_ERR_DEVICE_LOST:
                // For non-CPU implementations,
                // Cleanup if device is lost
                break;
            case MFX_WRN_DEVICE_BUSY:
                // For non-CPU implementations,
                // Wait a few milliseconds then try again
                break;
            default:
                printf("unknown status %d\n", sts);
                isStillGoing = false;
                break;
        }
    }

end:
    printf("Encoded %d frames\n", framenum);

    // Clean up resources - It is recommended to close components first, before
    // releasing allocated surfaces, since some surfaces may still be locked by
    // internal resources.
    if (source)
        fclose(source);

    if (sink)
        fclose(sink);

    MFXVideoENCODE_Close(session);
    MFXClose(session);

    if (bitstream.Data)
        free(bitstream.Data);

    if (loader)
        MFXUnload(loader);

    if (isFailed) {
        return -1;
    }
    else {
        return 0;
    }
}

... and here is the output produced ...

C:\Users\Oliver\Desktop\oneAPI examples\hello\hello-encode\build>Release\hello-encode -hw -i ..\..\..\content\cars_320x240.i420 -w 320 -h 240
Implementation details:
  ApiVersion:           2.7
  Implementation type:  HW
  AccelerationMode via: D3D11
  Path: C:\WINDOWS\System32\DriverStore\FileRepository\iigd_dch_d.inf_amd64_dd60ec4161906c78\libmfx64-gen.dll

Encoding ..\..\..\content\cars_320x240.i420 -> out.av1
Input colorspace: NV12
bitsream.DecodeTimeStamp = -9000
bitsream.TimeStamp       = 0
bitsream.DecodeTimeStamp = -6000
bitsream.TimeStamp       = 24000
bitsream.DecodeTimeStamp = -3000
bitsream.TimeStamp       = 12000
bitsream.DecodeTimeStamp = 0
bitsream.TimeStamp       = 6000
bitsream.DecodeTimeStamp = 3000
bitsream.TimeStamp       = 3000
bitsream.DecodeTimeStamp = 6000
bitsream.TimeStamp       = 9000
bitsream.DecodeTimeStamp = 9000
bitsream.TimeStamp       = 18000
bitsream.DecodeTimeStamp = 12000
bitsream.TimeStamp       = 15000
bitsream.DecodeTimeStamp = 15000
bitsream.TimeStamp       = 21000
bitsream.DecodeTimeStamp = 18000
bitsream.TimeStamp       = 48000
bitsream.DecodeTimeStamp = 21000
bitsream.TimeStamp       = 36000
bitsream.DecodeTimeStamp = 24000
bitsream.TimeStamp       = 30000
bitsream.DecodeTimeStamp = 27000
bitsream.TimeStamp       = 27000
bitsream.DecodeTimeStamp = 30000
bitsream.TimeStamp       = 33000
bitsream.DecodeTimeStamp = 33000
bitsream.TimeStamp       = 42000
bitsream.DecodeTimeStamp = 36000
bitsream.TimeStamp       = 39000
bitsream.DecodeTimeStamp = 39000
bitsream.TimeStamp       = 45000
bitsream.DecodeTimeStamp = 42000
bitsream.TimeStamp       = 72000
bitsream.DecodeTimeStamp = 45000
bitsream.TimeStamp       = 60000
bitsream.DecodeTimeStamp = 48000
bitsream.TimeStamp       = 54000
bitsream.DecodeTimeStamp = 51000
bitsream.TimeStamp       = 51000
bitsream.DecodeTimeStamp = 54000
bitsream.TimeStamp       = 57000
bitsream.DecodeTimeStamp = 57000
bitsream.TimeStamp       = 66000
bitsream.DecodeTimeStamp = 60000
bitsream.TimeStamp       = 63000
bitsream.DecodeTimeStamp = 63000
bitsream.TimeStamp       = 69000
bitsream.DecodeTimeStamp = 66000
bitsream.TimeStamp       = 87000
bitsream.DecodeTimeStamp = 69000
bitsream.TimeStamp       = 81000
bitsream.DecodeTimeStamp = 72000
bitsream.TimeStamp       = 78000
bitsream.DecodeTimeStamp = 75000
bitsream.TimeStamp       = 75000
bitsream.DecodeTimeStamp = 78000
bitsream.TimeStamp       = 84000
Encoded 30 frames

[dvrogozh]

@xhaihao : fyi, please, comment

I posted a comment to ffmpeg ticket. Repeating it here: "This seems to be an issues a fix for which we have been waiting for awhile to actually land QSV AV1 encoding support in ffmpeg master branch. Please, provide details on the underlying stack, i.e. which version of media-driver, oneVPL, and most importantly oneVPL-intel-gpu are you using?

I hope that you might be missing the following fix in oneVPL-gpu runtime: https://github.com/oneapi-src/oneVPL-intel-gpu/commit/dc7fd15 which is available starting from intel-onevpl-22.6.0."

I also think that filing to https://github.com/oneapi-src/oneVPL-intel-gpu might be more appropriate since this is coming from runtime not dispatching library.

[oviano]

As far as I have figured out, the fix was made here in oneVPL-intel-gpu:

https://github.com/oneapi-src/oneVPL-intel-gpu/issues/206

But that was back in April, so it would be great if us Windows users could get access to a driver containing this fix so we can use the AV1 encode capability properly.

[mav-intel]

@oviano moving this to move this to oneVPL-intel-gpu

[xhaihao]

I can't reproduce this issue on Linux. It should be a Windows driver related issue.

Implementation details: ApiVersion: 2.8
Implementation type: HW AccelerationMode via: VAAPI Path: /usr/lib/x86_64-linux-gnu/libmfx-gen.so.1.2.8

Encoding out.nv12 -> out.av1 Input colorspace: NV12 bitsream.DecodeTimeStamp = 0 bitsream.TimeStamp = 0 bitsream.DecodeTimeStamp = 3000 bitsream.TimeStamp = 3000 bitsream.DecodeTimeStamp = 6000 bitsream.TimeStamp = 6000 bitsream.DecodeTimeStamp = 9000 bitsream.TimeStamp = 9000 bitsream.DecodeTimeStamp = 12000 bitsream.TimeStamp = 12000 bitsream.DecodeTimeStamp = 15000 bitsream.TimeStamp = 15000 bitsream.DecodeTimeStamp = 18000 bitsream.TimeStamp = 18000 bitsream.DecodeTimeStamp = 21000 bitsream.TimeStamp = 21000 bitsream.DecodeTimeStamp = 24000 bitsream.TimeStamp = 24000 ...

[nyanmisaka]

The fix for AV1 encoder timestamp issue doesn't exist in Windows Arc driver 31.0.101.3802.

HandBrake uses ffmpeg libs too, so it is also affected.

Any ETA we can get a new Windows driver release for this issue?

[mikk9]

The first Arc GPUs had been launched in late March and this bug exists from the beginning, yes I tried older drivers. 8 months later it's not fixed. This is not acceptable.

AV1 was one of the big major points for Arc dGPUs. Apparently it's fixed since April for Linux, maybe Windows is not a top priority and they just doesn't care or didn't properly test it. rigaya from QSVEnc fixed it in a couple of days with a workaround, you would think Intel could do the same. Handbrake nightly suffers from the same root cause from the beginning.

I wouldn't bet on the new driver. Sure the fix is ready but Intel doesn't seem to care, I mean they could have released a bugfix driver a long time ago if they really anted to release it asap. There seems to be a big delay until a fix is shipped into the public driver.

[oviano]

According to this response to my post in the community forum, the driver seems unlikely before January.

https://community.intel.com/t5/Media-Intel-oneAPI-Video/ARC-QSV-AV1-encoding-should-it-always-output-in-PTS-order/m-p/1432880#M14416

[mikk9]

This is a big fail, isn't it? There is not much use of Arc AV1 on Windows with one exception which is QSVEnc. Handbrake AV1 is completely broken and ffmpeg only works when bframes are off. It's not like Arc just launched, as I said the first version of Arc is in public since 8 months.

[oviano]

It's a bit of a missed opportunity in my view.

Currently something like the A380 should be really tempting for encoder/streamers as it's the only dual-slot hardware accelerated AV1 solution until NVIDIA release cheaper/smaller 4-series cards next year. Yet they're letting the whole thing down by only taking the Linux drivers seriously, from what I can tell.

(Having said that, I've been using my FFmpeg patch a lot these last few days and it does work just fine, so there is a workaround which would also apply to Handbrake, if you wanted it)

[mikk9]

Can you send me your patched ffmpeg?

[oviano]

Sure, it's here:

https://ovcollyer-colebrooke.dyndns.org:4001/d/s/rHO5WopEuLqJUGs1ya7Ab7XONrl4K5Vf/d7sVqPH_PPrwBAYIaEjWKV0CjP-pS8Wz-S7iA0XSfBwo

[mikk9]

Thanks, I will try it out when I have time.

[oviano]

Only caveat is that there may be other issues with the Windows driver, but I'm not 100% sure yet:

https://github.com/oneapi-src/oneVPL/issues/79

[mikk9]

By the way is there an AV1 option or profile where I can choose between 8 bit or 10 bit? I haven't found.

[oviano]

If you mean encoding an 8 bit source as 10 bit, I think you would need to convert it to 10 bit first using something like -vf qsv_scale=format=p010 in the FFmpeg command line. This would then pass each frame as 10 bit and it would get encoded as 10 bit.

I think NVENC AV1 might have an explicit option to encode an 8 bit source using 10 bit precision, without converting it first, but haven't seen the same for QSV.

[mikk9]

With QSVEnc I have output-depth 8 and output-depth 10, Handbrake also offers both 8bit and 10bit encoding regardless of the input source. There is no such option for ffmpeg.

[oviano]

Yes, that's correct. I think there are a few missing options in Intel's FFmpeg AV1 implementation. Another one is "scenario".

[oviano]

By the way, even with my timestamp FFmpeg patch, I'm struggling to get QSV to encode in AV1 with a quality that isn't slightly worse than HEVC.

I've been posting my results in this thread:

https://github.com/oneapi-src/oneVPL/issues/79

I do not know if this is a Windows-driver-specific thing, or whether the Linux AV1 QSV encodes are sub-par too because I don't have a Linux machine to try out equivalent commands.

My tests with an NVENC 4090 showed a significant Improvement in quality under AV1 vs HEVC on that card.

[dvrogozh]

@xhaihao : did you add/verify 10-bit support for AV1 ffmpeg-qsv encoder? If yes, can you, please, provide sample cmdline and answer above question rgt. profile (which is whether any special profile for AV1 is needed to encode 10-bit with av1 qsv encoder).

[mikk9]

By the way, even with my timestamp FFmpeg patch, I'm struggling to get QSV to encode in AV1 with a quality that isn't slightly worse than HEVC.

I've been posting my results in this thread:

oneapi-src/oneVPL#79

I do not know if this is a Windows-driver-specific thing, or whether the Linux AV1 QSV encodes are sub-par too because I don't have a Linux machine to try out equivalent commands.

My tests with an NVENC 4090 showed a significant Improvement in quality under AV1 vs HEVC on that card.

From my tests the AV1 scores are fine with PSNR and SSIM, VMAF scores however are quite a bit below HEVC in most cases. Sometimes bframes 1 or 3 give me higher VMAF scores but from my subjective I would prefer bframes 7 (dist 8). Not sure if VMAF is that great because there is no croma component, it's luma component only. I wouldn't blindly trust VMAF over other metrics. 3-component SSIM works quite good imho for Quicksync/x265, to me it's closer to my subjective testing.

Rigaya tested Arc and RTX 4080, in his tests 10 bit AV1 is quite a bit better than 8 bit on Arc. Does ffmpeg only support 8 bit AV1 right now?

[oviano]

FFmpeg NVENC AV1 has this option:

    { "highbitdepth", "Enable 10 bit encode for 8 bit input",OFFSET(highbitdepth),AV_OPT_TYPE_BOOL,  { .i64 = 0 }, 0, 1, VE },

There isn't an explicit option like this for FFmpeg QSVENC, but as you can see, @dvrogozh has asked for clarification as to how it works in QSVENC (maybe specifying profile main10 is enough, for example, who knows).

I don't know about the other FFmpeg AV1 encoders (aomenc, svt-av1, rav1e etc)....

My other problem is the overall stability of the Windows driver. On both machines I am currently testing, it frequently crashes the whole PC and so far I've only managed to make it produce one memory dump file. I'm dealing with that elsewhere in the Intel support forums, but I'm at the point of giving up on the Windows version of QSVENC ARC, especially when I read things from Intel engineers responding to the timestamp issue with "don't expect a driver release before January"....well in that case maybe I'll just RMA these devices and check back in 6 months....

[mikk9]

3802 is unstable, it's crashing for me too. 3491 or 3490 was more reliable.

[oviano]

3802 is unstable, it's crashing for me too. 3491 or 3490 was more reliable.

Right, that's useful to know. I'll try going back to an earlier driver. It's all a bit of a sorry state of affairs though tbh. I really want to like these devices, the hardware seems really nice....but I don't know if I arrived late to the NVIDIA cards when they'd already gone through this process, but I've never had any issues like the numerous ones I've had with these cards.

[xhaihao]

According to AV1 spec, 10bit and 8bit 4:2:0 share the same profile.

seq_profile      Bit depth       Monochrome support     Chroma subsampling
 0                8 or 10           Yes                        YUV 4:2:0

So we can't use profile to distinguish 10bit from 8bit.

It will use 10bit encoding if the input is 10bit

$ ffmpeg -y -f lavfi -i testsrc -vf "format=p010" -c:v av1_qsv -vframes 100 out.mp4 ... Output #0, mp4, to 'out.mp4': Metadata: encoder : Lavf59.34.102 Stream #0:0: Video: av1 (av01 / 0x31307661), p010le(tv, progressive), 320x240 [SAR 1:1 DAR 4:3], q=2-31, 1000 kb/s, 25 fps, 12800 tbn Metadata: encoder : Lavc59.54.100 av1_qsv ...

[xhaihao]

The output is 8bit if the input is 8bit

$ ffmpeg -y -f lavfi -i testsrc -vf "format=nv12" -c:v av1_qsv -vframes 100 out.mp4 ... Output #0, mp4, to 'out.mp4': Metadata: encoder : Lavf59.34.102 Stream #0:0: Video: av1 (av01 / 0x31307661), nv12(tv, progressive), 320x240 [SAR 1:1 DAR 4:3], q=2-31, 1000 kb/s, 25 fps, 12800 tbn Metadata: encoder : Lavc59.54.100 av1_qsv

[oviano]

According to AV1 spec, 10bit and 8bit 4:2:0 share the same profile.

seq_profile      Bit depth       Monochrome support     Chroma subsampling
 0                8 or 10           Yes                        YUV 4:2:0

So we can't use profile to distinguish 10bit from 8bit.

It will use 10bit encoding if the input is 10bit

$ ffmpeg -y -f lavfi -i testsrc -vf "format=p010" -c:v av1_qsv -vframes 100 out.mp4 ... Output #0, mp4, to 'out.mp4': Metadata: encoder : Lavf59.34.102 Stream #0:0: Video: av1 (av01 / 0x31307661), p010le(tv, progressive), 320x240 [SAR 1:1 DAR 4:3], q=2-31, 1000 kb/s, 25 fps, 12800 tbn Metadata: encoder : Lavc59.54.100 av1_qsv ...

In the OneVPL API there is TargetBitdepthLuma and TargetBitdepthChroma settings (extco3) - are these meant to convert an 8 bit input to 10 bit? I tried enabling these options in my local FFmpeg build, but even if they do the conversion I couldn't see how the metadata would then be propagated to the container in FFmpeg as the AVCodecContext would still have the input pixel format which would then get written to the stream/container, so maybe these options are unsuitable for FFmpeg-qsv.

Obviously you can use a filter as you have shown.

[dvrogozh]

In the OneVPL API there is TargetBitdepthLuma and TargetBitdepthChroma settings (extco3) - are these meant to convert an 8 bit input to 10 bit?

These are meant to encode with a different colorspace other than what is on thy input. The idea was to support cases such as 12bit -> 10 bit or 10bit -> 8bit without including video processing explicitly (i.e. as a stand alone component). I don't think that 8bit -> 10bit was the intended use case at all.

I am not sure why you are trying to look into that considering that @xhaihao clarified that AV1 ffmpeg-qsv does support 10-bit input without the need for the special profile? If you have 10-bit input, you should get 10-bit encoded bitstream. That was the question, right?

If the intend is to encode 8bit from the 10bit input, I would suggest to add explicit color conversion before the encoder. We can ask @xhaihao to help with the command line for that. This will be a much better tested path versus TargetBitdepthLuma/TargetBitdepthChroma. Besides, TargetBitdepthLuma and TargetBitdepthChroma are not supported on ffmpeg level as of now.

[oviano]

In the OneVPL API there is TargetBitdepthLuma and TargetBitdepthChroma settings (extco3) - are these meant to convert an 8 bit input to 10 bit?

I am not sure why you are trying to look into that considering that @xhaihao clarified that AV1 ffmpeg-qsv does support 10-bit input without the need for the special profile? If you have 10-bit input, you should get 10-bit encoded bitstream. That was the question, right?

I looked into it before @xhaihao's response. Just curious! Thanks for the explanation.

[mikk9]

The timestamp issue seems to be fixed in the new driver.

https://www.intel.com/content/www/us/en/download/729157/intel-arc-graphics-windows-dch-driver-beta.html

[oviano]

That's great. Any improvement in stability for you?

[mikk9]

No issue so far but I haven't tried much, too early to say. This is the first driver with API 2.08 support by the way. The stutter issue in Handbrake is also gone.

[oviano]

Closing this now as the issue is resolved with the new driver.

[dvrogozh]

Was about to let you guys know that new beta driver was posted, but you figured that out yourselves. Just confirming that I double checked internally and fix for the issue I was talking above (https://github.com/oneapi-src/oneVPL-intel-gpu/commit/dc7fd15 in terms of open source vpl runtime) is actually included in this driver (31.0.101.3959).

[oviano]

Thanks 🙏