Den 11.11.2024 22:34, skrev Andrew Randrianasulu:


вт, 12 нояб. 2024 г., 00:31 Terje J. Hanssen <[email protected]>:




    Den 11.11.2024 22:20, skrev Andrew Randrianasulu:


    пн, 11 нояб. 2024 г., 23:43 Terje J. Hanssen
    <[email protected]>:

    {snip}



                .


                hevc_qsv.mp4  revised:
                pixel formats p010le and y210le render again to
                yuv420p10le and .yuv422p10le respectively
                Woops; only when these window lines are commented
                out as written in my previous post !

                    # profile=main
                    # cin_pix_fmt=nv12

                Works both with and without
                export CIN_10BIT_ENC=1
                before cin/bin



            we most likely will need new profiles for 10bit
            everything anyway ...

            thanks for continued (and very exhaustive!) testing

            Also the preset's combination of pixel formats and the
            right (ffmpeg) codec profiles would need an overhaul.

            As mentioned already above:

            hevc_qsv.mp4  revised:
            pixel formats p010le and y210le render again to
            yuv420p10le and .yuv422p10le respectively
            Woops; only when these window lines are commented out as
            written in my previous post !

                # profile=main
                # cin_pix_fmt=nv12


            I experimented additional and got

            y210/profile=1  ==> yuv422p10le

            y210/ profile=main10/ profile=2/ profile=3 ==> yuv420p10le

            I got similar results with my own dynamic Cingg built
            with ffmpeg 7.1.

            --------------------------

            So a question beside:

            Yesterday I did a new (monthly) upgrade of
            Tumbleweed-Slowroll, which replaced Packman package libs
            and ffmpeg 7.1

            After that, the static Cingg with onevpl and 10bit patch
            would not render hevc_qsv.

            Today's upgrade with new Packman packages up-to-date
            with the new Slowroll version, and now Cingg worked as
            before:

             ffmpeg-7 ffmpeg-7-libavcodec-devel
            ffmpeg-7-libavdevice-devel ffmpeg-7-libavfilter-devel
              ffmpeg-7-libavformat-devel ffmpeg-7-libavutil-devel
            ffmpeg-7-libpostproc-devel ffmpeg-7-libswresample-devel
              ffmpeg-7-libswscale-devel libavcodec61 libavdevice61
            libavfilter10 libavformat61 libavutil59 libpostproc58
              libswresample5 libswscale8

            So even Cingg with onevpl is static built, it looks like
            it is dependent of one or more system packages/libs beside?
            Any idea what packages it can be ?



        onevpl/vaapi/vdpau - they all linked  dynamically (not sure
        if static version of them even possible)

        Ah, I see.

        I tried to compare the two configure lines for my full
        dynamic Cingg/ffmpeg7.1 built and static-dynamic
        Cingg/ffmpeg7.0 respectively:

        ./configure --with-single-user --disable-static-build
        --without-thirdparty --without-libdpx
        ./configure --with-single-user --with-onevpl

        As the first line didn't mention "vpl" I searched backwards
        and got the understanding that the source code was patched to
        use the system libvpl.


    not exactly, in first case it just uses libav* from system ffmpeg
    package... and this in your case uses libvpl.


        In the second case the build-system itself was patched with
        onevpl (default off) to use the same system libvpl, I assume?

        Is/will possibly the current or upcoming Cingg appimage/rpm
        available with the onevpl patch, so it can be switched on and
        tested on other available hardware?



    I was about to ask if onevpl patch can be added to git ...

    Dear Phyllis, can you add onevpl.patch so future QSV testing will
    be easier (it defaults to off so should not break anything ... by
    default).

    while there, Terje, can you pack your latest profile work and
    send it separately?


Do you mean to attach them with filenames to a separate post here or?

    I think we use codec_encoder_additional_params.container as format

    so 10bit 420 hevc  qsv for mp4 will look like

    hevc_qsv_10bit.mp4

    with  content you experimentally determinated.

    and y210 probably will be named

    hevc_qsv_y210.mp4


    What about

    hevc_qsv_10bit-420.mp4

    and

    hevc_qsv_10bit-422.mp4

    respectively?




if those relative long names fit their box - then ok ...

An alternative short(er) form and still a relative unambiguous description

hevc_qsv_10b420.mp4
hevc_qsv_10b422.mp4






-- 
Cin mailing list
[email protected]
https://lists.cinelerra-gg.org/mailman/listinfo/cin

Reply via email to