[Cin] 10bit VAAPI encoding test thread continued

[Terje J. Hanssen]

Den 11.11.2024 22:34, skrev Andrew Randrianasulu:
>
>
> вт, 12 нояб. 2024 г., 00:31 Terje J. Hanssen <terjejhanssen at gmail.com>:
>
>
>
>
>     Den 11.11.2024 22:20, skrev Andrew Randrianasulu:
>>
>>
>>     пн, 11 нояб. 2024 г., 23:43 Terje J. Hanssen
>>     <terjejhanssen at gmail.com>:
>>
>>     {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

>
>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.cinelerra-gg.org/pipermail/cin/attachments/20241112/57765ee4/attachment-0001.htm>