[Cin] adding onevpl support for buildsystem

Andrew Randrianasulu randrianasulu at gmail.com
Fri Oct 25 19:45:31 CEST 2024 

пт, 25 окт. 2024 г., 19:56 Terje J. Hanssen <terjejhanssen at gmail.com>:

>
>
>
> Den 25.10.2024 17:31, skrev Andrew Randrianasulu:
>
>
>
> On Fri, Oct 25, 2024 at 5:05 PM Terje J. Hanssen <terjejhanssen at gmail.com>
> wrote:
>
>>
>>
>>
>> Den 25.10.2024 01:55, skrev Terje J. Hanssen:
>>
>>
>>
>>
>> Den 25.10.2024 00:43, skrev Andrew Randrianasulu:
>>
>>
>> snip ...................
>>
>>
>>>> -----------------------
>>>>
>>>> localhost:/Cin # bin/cin
>>>> Cinelerra Infinity - built: Oct 24 2024 16:26:16
>>>>
>>>> Tested with similar results as my previous ffmpeg_71 build:
>>>>
>>>> SD-DV to av1_qsv, hevc_qsv and h264_qsv nv12 works
>>>> HDV to hevc_qsv works with nv12, p010le and yuv422 works
>>>> HDV to av1_qsv and to h264_qsv don't work
>>>>
>>>
>>> does av1_vaapi work for HDV case?
>>>
>>>
>>>
>>> Yes, I test-rendered HDV (hdv09_04) to hevc_vaapi, av1_vaapi,
>>> h264_vaapi, all i .mp4 below
>>> Also FHD (hd01) to av1_vaapi.mp4 worked, see ffprobe below
>>>
>>> Testing .webm type breaks with the following output:
>>>
>>> [av1_vaapi @ 0x7f5f74122a80] Driver does not support QVBR RC mode
>>> (supported modes: CQP, CBR, VBR, ICQ).
>>> FFMPEG::open_encoder  err: Invalid argument
>>> int FFMPEG::open_encoder(const char*, const char*):
>>> open failed av1_vaapi:/Videoklipp/VAAPI/hdv09_04_av1_vaapi.webm
>>>
>>>
>> hm, you probably need to tweak this profile for your driver then ...
>>
>>
>> I got this tweak to work for hdv09_04.m2t rendering to av1_vaapi.webm
>>
>> cin_hw_dev=vaapi
>> g=30
>> profile=main
>> rc_mode=CQP
>>
>> Render::render_single: Session finished.
>> ** rendered 5972 frames in 27.408 secs, 217.893 fps
>> FFMPEG::open_decoder: some stream times estimated:
>> /Videoklipp/VAAPI/hdv09_04_av1_vaapi.webm
>> FFMPEG::open_decoder: some stream times estimated:
>> /Videoklipp/VAAPI/hdv09_04_av1_vaapi.webm
>> audio0 pad 64 -143 (207)
>> audio0 pad 0 -143 (143)
>> audio0 pad 0 -15 (15)
>>
>>
>> while
>>
>> [av1_vaapi @ 0x7f8000317a40] Bitrate must be set for VBR RC mode.
>> FFMPEG::open_encoder  err: Invalid argument
>> int FFMPEG::open_encoder(const char*, const char*):
>> open failed av1_vaapi:/Videoklipp/VAAPI/hdv09_04_av1_vaapi.webm
>>
>>
>>
>> I think this build uses ffmpeg 7.0 embedded, but is it a way to very
>> which ffmpeg version in use via Cingg?
>>
>
> Yes, look at line
>
> Libav version: Lavc61.3.100
>
> 61.19 -> 7.1
> 61.3 -> 7.0
>
>
> So it is not possible to query somewhere with
>
> ffmpeg --version (or just ffmpeg)
>
> to get it's version on the first line like on the system ffmpeg
>
> # ffmpeg
> ffmpeg version 7.1 Copyright (c) 2000-2024 the FFmpeg developers
>   built with gcc 14 (SUSE Linux)
>
> or optional via verbose/debug output?
>

no ..... I hoped just libavc version should be enough because it really one
most directly used.



>
>
>
>
>>
>> As already tested as working on my own build Cingg based on system ffmpeg
>> 7.1,
>> https://lists.cinelerra-gg.org/pipermail/cin/2024-October/008932.html
>>
>> this also shows to work on this 7.0(?) build:
>> hdv.m2t and hd.mov (prores 422 hq) rendering with to av1_vaapi.webm on
>> Arc A750 works with
>>
>> vprofile=high or vprofile=professional
>>
>> but 10bit yuv422 are downscaled to 8bit yuv420 in the output, at least
>> with this profile and/or without other parameters set
>>
>
> yeah, seems to be limitation of current code in cingg.
>
> in cinelerra/ffmpeg.C there is function
>
> AVHWDeviceType FFVideoStream::encode_hw_activate()
>
> frames_ctx->sw_format = AV_PIX_FMT_NV12;
>
> if you change AV_PIX_FMT_NV12 with AV_PIX_FMT_P010
>
> does it  encode 10 bit ?
>
>
> Sorry, no it doesn't, just the same.
>


ah, sad! There is another NV12 in

int FFVideoStream::init_frame(AVFrame *picture)
{
                                switch( avctx->pix_fmt ) {
        case AV_PIX_FMT_VAAPI:
                picture->format = AV_PIX_FMT_NV12;
                break;


but I thought it was for decoding?

you can change it there too ... and see if it helps.





> And as seen in the ffprobe output below:
>     Stream #0:0: Video: av1 (libdav1d) (Main), yuv420p
>
> That is Main profile, even if I set and used vprofile=professional for the
> rendering !?
>
>
> You said av1_qsv  at least can be set to p012 ? Then, this is advantage
> (when it works)
>
>
> I remember I rendered hevc_qsv with p010le and yuv422, but I'm not sure I
> did verify it in the output.
> At least I'm not able verify it now, as they also seems to rescale to 8bit
> yuv420p.
>

probably surface format must be set differently ..

you tried with Format = rgba-float too?




>
>
>>
>>
>> Render::render_single: Session finished.
>> ** rendered 5972 frames in 28.582 secs, 208.943 fps
>> FFMPEG::open_decoder: some stream times estimated:
>> /Videoklipp/VAAPI/hdv09_04_av1_vaapi.webm
>>
>> Render::render_single: Session finished.
>> ** rendered 1781 frames in 13.666 secs, 130.323 fps
>> FFMPEG::open_decoder: some stream times estimated:
>> /Videoklipp/VAAPI/hd01_av1_vaapi.webm
>>
>> /Videoklipp/VAAPI # ls -lht hdv* hd*
>> -rw-r--r-- 1 root  root  567M Oct 25 15:30 hd01_av1_vaapi.webm
>> -rw-r--r-- 1 root  root  1.5G Oct 25 15:11 hdv09_04_av1_vaapi.webm
>>
>>
>> ffprobe -hide_banner hd01_av1_vaapi.webm
>> Input #0, matroska,webm, from 'hd01_av1_vaapi.webm':
>>   Metadata:
>>     ENCODER         : Lavf61.1.100
>>   Duration: 00:01:11.28, start: 0.000000, bitrate: 67255 kb/s
>>   Stream #0:0: Video: av1 (libdav1d) (Main), yuv420p(tv,
>> bt709/unknown/unknown), 1920x1080, SAR 1:1 DAR 16:9, 25 fps, 25 tbr, 1k tbn
>>       Metadata:
>>         DURATION        : 00:01:11.243000000
>>   Stream #0:1: Audio: vorbis, 48000 Hz, 16 channels, fltp
>>       Metadata:
>>         DURATION        : 00:01:11.283000000
>>
>>
>>
>>
>>
>> so, vaapi works in more cases than qsv, it seems?
>>
>>
>> So far, yes
>>
>>
>>
>>
>>>
>>> terje at localhost:/Videoklipp/VAAPI> ls -lt hd*
>>> -rw-r--r-- 1 root  root  349812400 okt.  24 20:54 hdv09_04_hevc_vaapi.mp4
>>> -rw-r--r-- 1 root  root  112467398 okt.  24 20:42 hd01_av1_vaapi.mp4
>>> -rw-r--r-- 1 root  root  606029742 okt.  24 20:35 hdv09_04_h264_vaapi.mp4
>>> -rw-r--r-- 1 root  root  378664255 okt.  24 20:28 hdv09_04_av1_vaapi.mp4
>>>
>>>
>>> ffprobe -hide_banner hdv09_04_hevc_vaapi.mp4
>>> Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'hdv09_04_hevc_vaapi.mp4':
>>>   Metadata:
>>>     major_brand     : isom
>>>     minor_version   : 512
>>>     compatible_brands: isomiso2mp41
>>>     encoder         : Lavf61.7.100
>>>   Duration: 00:03:58.88, start: 0.000000, bitrate: 11715 kb/s
>>>   Stream #0:0[0x1](und): Video: hevc (Main) (hev1 / 0x31766568),
>>> yuv420p(tv, bt470bg/unknown/unknown, top coded first (swapped)), 1440x1080
>>> [SAR 4:3 DAR 16:9], 11580 kb/s, 25 fps, 25 tbr, 12800 tbn (default)
>>>       Metadata:
>>>         handler_name    : VideoHandler
>>>         vendor_id       : [0][0][0][0]
>>>   Stream #0:1[0x2](und): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz,
>>> stereo, fltp, 129 kb/s (default)
>>>       Metadata:
>>>         handler_name    : SoundHandler
>>>         vendor_id       : [0][0][0][0]
>>>
>>>
>>> ffprobe -hide_banner hd01_av1_vaapi.mp4
>>> Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'hd01_av1_vaapi.mp4':
>>>   Metadata:
>>>     major_brand     : isom
>>>     minor_version   : 512
>>>     compatible_brands: isomav01iso2mp41
>>>     encoder         : Lavf61.1.100
>>>   Duration: 00:01:11.28, start: 0.000000, bitrate: 12622 kb/s
>>>   Stream #0:0[0x1](und): Video: av1 (libdav1d) (Main) (av01 /
>>> 0x31307661), yuv420p(tv, bt470bg/unknown/unknown, top coded first
>>> (swapped)), 1920x1080, 12246 kb/s, SAR 1:1 DAR 16:9, 25 fps, 25 tbr, 12800
>>> tbn (default)
>>>       Metadata:
>>>         handler_name    : VideoHandler
>>>         vendor_id       : [0][0][0][0]
>>>   Stream #0:1[0x2](und): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz,
>>> 16 channels, fltp, 378 kb/s (default)
>>>       Metadata:
>>>         handler_name    : SoundHandler
>>>         vendor_id       : [0][0][0][0]
>>>
>>>
>>> can you add auto-scale filter to HDV cases so it will be full HD and not
>>> 1440*1080 ? or another similar rescaling ....
>>>
>>> again, thanks for testing.
>>>
>>> But as with any experimentation we get some new questions instead of
>>> pure answers ....
>>>
>>>
>>>
>>>
>>>>
>>>> ===================================
>>>>
>>>> In separate posts:
>>>> Can you possibly setup guideline detail procedure on how to build an
>>>> appimage and a rpm package of this build,
>>>> to possible install and test it on my legacy Skylake and Kabylake
>>>> platforms?
>>>>
>>>> ===================================
>>>>
>>>
>>> I think basic procedure at
>>>
>>>
>>> https://cinelerra-gg.org/download/CinelerraGG_Manual/Build_CinGG_AppImage_from_s.html
>>>
>>> starting from
>>>
>>> 2- The script bld_appimage.sh uses a platform specific version of
>>> appimagetool so that it can create appimages for x86_64, i686, aarch64, or
>>> armv7l architecture. We need to add appimagetool-(platform).AppImage to the
>>> /{path to cinelerra- 5.1}/tools directory, or somewhere in your path. You
>>> can download the tool for your system (e.g. appimagetool-x86_64.AppImage)
>>> from git: https://github.com/AppImage/AppImageKit/releases
>>>
>>>
>>> for rpm build I think we need to wait for this patch to land in git and
>>> then become part of monthly src tarball.
>>>
>>> Then you can edit .spec file with soecifix date-based filename to fetch
>>> and run
>>>
>>> rpmbuild -bb ("build binary") our_spec_file.spec
>>>
>>>
>>> snip ...........
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.cinelerra-gg.org/pipermail/cin/attachments/20241025/482e7790/attachment-0001.htm>

More information about the Cin mailing list