[Cin] 10bit VAAPI encoding test thread continued

[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? 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 ...



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