[Cin] 10bit VAAPI encoding test thread continued

[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!


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