пт, 25 окт. 2024 г., 19:56 Terje J. Hanssen <[email protected]>:
Den 25.10.2024 17:31, skrev Andrew Randrianasulu:
On Fri, Oct 25, 2024 at 5:05 PM Terje J. Hanssen <[email protected]> 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
https://cinelerra-gg.org/download/CinelerraGG_Manual/Build_CinGG_AppImage_fr...
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 ...........