[Cin] 10bit VAAPI encoding test thread continued

Terje J. Hanssen terjejhanssen at gmail.com
Tue Nov 12 21:53:43 CET 2024




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


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/47460a19/attachment-0001.htm>


More information about the Cin mailing list