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



Den 25.10.2024 17:31, skrev Andrew Randrianasulu:


On Fri, Oct 25, 2024 at 5:05 PM Terje J. Hanssen <terjejhanssen@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@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


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