[Cin] 10bit VAAPI encoding test thread continued

Tue Nov 12 16:42:00 CET 2024

вт, 12 нояб. 2024 г., 18:32 Terje J. Hanssen <terjejhanssen at gmail.com>:

>
>
>
> Den 12.11.2024 09:59, skrev Andrew Randrianasulu:
>
>
>
> вт, 12 нояб. 2024 г., 11:41 Terje J. Hanssen <terjejhanssen at gmail.com>:
>
>>
>>
>>
>> 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?
>>
>
> yes.
>
>
>
>> 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
>>
>
> then make them so!
>
>
> I have some questions:
>
> I know how to edit the content of the included "generic" video preset
>
> cat /Cin/bin/ffmpeg/video/hevc_qsv.mp4
>
> mp4 hevc_qsv
> # only usable with ext. ffmpeg, another pixfmt is yuyv422
> profile=main
> cin_pix_fmt=nv12
>
> to create three additional, typical types:
>
> hevc_qsv_8b420.mp4
> hevc_qsv_10b420.mp4
> hevc_qsv_10b422.mp4
>
>
> I can load these compression types, but Cingg won't render with other
> names than with the hevc_qsv.mp4?
>

show content of those for all of us? ;)

> What decide what become available in the Video Preset Pixel field, one
> single default or nv12 on top of a drop down menu?
>

whatever individual encoder describes in their pixfmt array .... (inside
libavcodec)

> Testing with added
>
> global_quality=25
>
> works seemingly well and uses higher bit rate vs without this flag
> (default):
>
> hdv input:    5938 kb/s vs 3090 kb/s
> cfhd input:   4644 kb/s vs 2245 kb/s
>

good.

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