[Cin] 10bit VAAPI encoding test thread continued
Terje J. Hanssen
terjejhanssen at gmail.com
Tue Nov 12 16:32:56 CET 2024
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?
What decide what become available in the Video Preset Pixel field, one
single default or nv12 on top of a drop down menu?
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
>
>
>>
>>
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.cinelerra-gg.org/pipermail/cin/attachments/20241112/f60c83f9/attachment-0001.htm>
More information about the Cin
mailing list