[Cin] 10bit VAAPI encoding test thread continued

Terje J. Hanssen terjejhanssen at gmail.com
Tue Nov 12 21:58:27 CET 2024




Den 12.11.2024 21:53, skrev Terje J. Hanssen:
>
>
>
> Den 12.11.2024 16:42, skrev Andrew Randrianasulu:
>>
>>
>> вт, 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? ;)
>
>
> Of course, we can clarify the questions this way.
>
> cat hevc_qsv_8b420.mp4
>
>     mp4 hevc_qsv_8b420
>     # usable with Pixels: nv12
>     profile=main
>     # global_quality=25
>
>
> cat hevc_qsv_10b420.mp4
>
>     mp4 hevc_qsv_10b420
>     # usable with Pixels: p010le
>     profile=main10
>     # global_quality=25
>
>
> cat hevc_qsv_10b422.mp4
>
>     mp4 hevc_qsv_10b422
>     # usable with Pixels: y210le
>     profile=0
>     # global_quality=25
>
>

Attached the three presets


> If I load these compression Preset types, two issues arise:
>
> 1. The window content is correct, but the Pixel field is not: no drop 
> down menu, but preferably nv12, p010le or y210le should be selected 
> directly.
> (I have tested these work, but not all other options on the drop down 
> menu)
>
> 2. Rendering won't run and the error output
> int FFMPEG::open_encoder(const char*, const char*):
> cant find codec 
> hevc_qsv_8b420:/Videoklipp/Cineform/cfhd01_hevc_qsv_pix_nv12.mp4
>
> However, as mentioned, if I load the default hevc_qsv.mp4 instead and 
> copy the content above in its window and select the right Pixel format,
> rendering works fine.
>
> ffprobe -hide_banner cfhd01_hevc_qsv_pix_nv12.mp4
>   Duration: 00:01:11.20, start: 0.000000, bitrate: 2245 kb/s
>   Stream #0:0[0x1](und): Video: hevc (Main) (hev1 / 0x31766568), 
> yuv420p(tv, bt709/unknown/unknown, top coded first (swapped)), 
> 1920x1080 [SAR 1:1 DAR 16:9], 2242 kb/s, 25 fps, 25 tbr, 12800 tbn 
> (default)
>
> and with the gobal_quality=25 flag enabled:
>
> ffprobe -hide_banner cfhd01_hevc_qsv_pix_nv12_gq25.mp4
>   Duration: 00:01:11.20, start: 0.000000, bitrate: 4644 kb/s
>   Stream #0:0[0x1](und): Video: hevc (Main) (hev1 / 0x31766568), 
> yuv420p(tv, bt709/unknown/unknown, top coded first (swapped)), 
> 1920x1080 [SAR 1:1 DAR 16:9], 4642 kb/s, 25 fps, 25 tbr, 12800 tbn 
> (default)
>
>
>>
>>
>>
>>     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/604ac6b6/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hevc_qsv_8b420.mp4
Type: video/mp4
Size: 79 bytes
Desc: not available
URL: <https://lists.cinelerra-gg.org/pipermail/cin/attachments/20241112/604ac6b6/attachment-0003.mp4>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hevc_qsv_10b420.mp4
Type: video/mp4
Size: 85 bytes
Desc: not available
URL: <https://lists.cinelerra-gg.org/pipermail/cin/attachments/20241112/604ac6b6/attachment-0004.mp4>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hevc_qsv_10b422.mp4
Type: video/mp4
Size: 81 bytes
Desc: not available
URL: <https://lists.cinelerra-gg.org/pipermail/cin/attachments/20241112/604ac6b6/attachment-0005.mp4>


More information about the Cin mailing list