Den 27.10.2024 18:32, skrev Andrew Randrianasulu:
вс, 27 окт. 2024 г., 20:30 Terje J. Hanssen <[email protected]>:
Den 27.10.2024 18:16, skrev Andrew Randrianasulu:
вс, 27 окт. 2024 г., 19:48 Terje J. Hanssen <[email protected]>:
Den 27.10.2024 17:46, skrev Andrew Randrianasulu:
On Sun, Oct 27, 2024 at 7:28 PM Terje J. Hanssen <[email protected]> wrote:
Den 27.10.2024 17:22, skrev Andrew Randrianasulu:
вс, 27 окт. 2024 г., 19:02 Terje J. Hanssen <[email protected]>:
Den 27.10.2024 16:35, skrev Andrew Randrianasulu:
вс, 27 окт. 2024 г., 18:30 Terje J. Hanssen <[email protected]>:
Den 27.10.2024 16:21, skrev Andrew Randrianasulu:
вс, 27 окт. 2024 г., 13:17 Terje J. Hanssen <[email protected]>:
Den 26.10.2024 01:37, skrev Andrew Randrianasulu: > > > On Sat, Oct 26, 2024 at 2:14 AM Andrew > Randrianasulu <[email protected]> > wrote: > > > > On Sat, Oct 26, 2024 at 1:29 AM > Andrew Randrianasulu > <[email protected]> wrote: > > > > сб, 26 окт. 2024 г., 00:58 Terje > J. Hanssen > <[email protected]>: > > > > > Den 25.10.2024 21:48, skrev > Andrew Randrianasulu: >> We branching! >> >> I looked at gpu-screen-recorder >> >> https://git.dec05eba.com/gpu-screen-recorder/tree/src/encoder/video/vaapi.c >> >> it sets >> >> |AVHWFramesContext >> *hw_frame_context = >> (AVHWFramesContext*)frame_context->data; >> hw_frame_context->width = >> video_codec_context->width; >> hw_frame_context->height = >> video_codec_context->height; >> hw_frame_context->sw_format >> = self->params.color_depth >> == GSR_COLOR_DEPTH_10_BITS >> ? AV_PIX_FMT_P010LE : >> AV_PIX_FMT_NV12; >> hw_frame_context->format = >> video_codec_context->pix_fmt; >> hw_frame_context->device_ctx >> = >> (AVHWDeviceContext*)self->device_ctx->data;| >> || >> || >> |so may be we need to set |AV_PIX_FMT_P010LE and not just P010? > > Sorry, It didn't render more > than 8bit yuv420p > > > > yeahh ... probably need more > debugging (seeing what pixel > format goes into ffmpeg vaapi > interface at least). > > I only have decoding on nouveau, > and quite flaky at that - only 2 > files so far worked w,/o > crashing, from around 2011/12. > > > I tried to change two instances > of NV12 to P010LE and it shows > no visible effect, so I assume > it was supposed to work with > encoding ...? > > it does not work even with qsv > set to p010 AND patch ? > > if so, I am afraid I only can > put this item on shelf ... for > now. Look at mantis bug > database, if there is no entry > about 10bit vaapi > deciding/encoding - add it > please .... > > you can also test (at some point > in time ) this > gpu_screen_recorder, it builds > but does not work for me due to > "nouveau" driver. > > > > at least with another patch > (attached) I can get this: > > bash-5.1$ bin/cin ~/6029.mp4 > Cinelerra Infinity - built: Oct 17 > 2024 16:18:31 > git://git.cinelerra-gg.org/goodguy/cinelerra.git > <http://git.cinelerra-gg.org/goodguy/cinelerra.git> > (c) 2006-2019 Heroine Virtual Ltd. > by Adam Williams > 2007-2020 mods for Cinelerra-GG by > W.P.Morrow aka goodguy > 2003-2017 mods for Cinelerra-CV by > CinelerraCV team > 2015-2024 mods for Cinelerra-GG by > Cinelerra-GG team > > Libav version: Lavc61.3.100 > > Cinelerra is free software, covered > by the GNU General Public License, > and you are welcome to change it > and/or distribute copies of it under > certain conditions. There is > absolutely no warranty for Cinelerra. > > RenderFarmClient::main_loop: client > started > [AVHWDeviceContext @ 0xf925c00] > Trying to use DRM render node for > device 0. > [AVHWDeviceContext @ 0xf925c00] > libva: VA-API version 1.19.0 > [AVHWDeviceContext @ 0xf925c00] > libva: Trying to open > /usr/lib/dri/nouveau_drv_video.so > [AVHWDeviceContext @ 0xf925c00] > libva: Found init function > __vaDriverInit_1_19 > [AVHWDeviceContext @ 0xf925c00] > libva: va_openDriver() returns 0 > [AVHWDeviceContext @ 0xf925c00] > Initialised VAAPI connection: > version 1.19 > [AVHWDeviceContext @ 0xf925c00] > Format 0x3231564e -> nv12. > [AVHWDeviceContext @ 0xf925c00] > Format 0x30313050 -> p010le. > [AVHWDeviceContext @ 0xf925c00] > Format 0x36313050 -> unknown. > [AVHWDeviceContext @ 0xf925c00] > Format 0x30323449 -> yuv420p. > [AVHWDeviceContext @ 0xf925c00] > Format 0x32315659 -> yuv420p. > [AVHWDeviceContext @ 0xf925c00] > Format 0x56595559 -> unknown. > [AVHWDeviceContext @ 0xf925c00] > Format 0x32595559 -> yuyv422. > [AVHWDeviceContext @ 0xf925c00] > Format 0x59565955 -> uyvy422. > [AVHWDeviceContext @ 0xf925c00] > Format 0x41524742 -> bgra. > [AVHWDeviceContext @ 0xf925c00] > Format 0x41424752 -> rgba. > [AVHWDeviceContext @ 0xf925c00] > Format 0x58524742 -> bgr0. > [AVHWDeviceContext @ 0xf925c00] > Format 0x58424752 -> rgb0. > [AVHWDeviceContext @ 0xf925c00] > VAAPI driver: Mesa Gallium driver > 22.1.7 for NV106. > [AVHWDeviceContext @ 0xf925c00] > Driver not found in known > nonstandard list, using standard > behaviour. > [AVHWFramesContext @ 0xea43980] > Created surface 0x1. > [AVHWFramesContext @ 0xea43980] > Direct mapping possible. > [av1_vaapi @ 0xf978680] Input > surface format is p010le. > [av1_vaapi @ 0xf978680] Compatible > profile VAProfileAV1Profile0 (32) is > not supported by driver. > [av1_vaapi @ 0xf978680] No usable > encoding profile found. > FFMPEG::open_encoder err: Function > not implemented > int FFMPEG::open_encoder(const > char*, const char*): > open failed > av1_vaapi:/dev/shm/yuv-test-reenc-rgba8-mpeg-range.webm > Render::render_single: Session finished. > Total excess of backups: -50 > [AVIOContext @ 0xeaf1aa40] > Statistics: 4570842 bytes read, 5 seeks > [AVIOContext @ 0xeaf348c0] > Statistics: 2997978 bytes read, 2 seeks > [AVIOContext @ 0xd7aa8900] > Statistics: 4272574 bytes read, 2 seeks > [AVIOContext @ 0xd7954080] > Statistics: 2997978 bytes read, 2 seeks > [AVIOContext @ 0xf40c2840] > Statistics: 9351290 bytes read, 18 seeks > [AVIOContext @ 0xf4008a00] > Statistics: 2997978 bytes read, 2 seeks > Session time: 0:00:48 > Cpu time: user: 0:00:09.659 sys: > 0:00:03.077 > > so i guess it sets surface format > now correctly, just no encoder > entrypoint (obviously on my hw)? > Terje, Andrea - can you test this hack ? > > > one more time, this time with env variable > > CIN_10BIT_ENC=1 bin/cin ~/6029.mp4 > > should enable P010LE input surface > format ...but you probably need to set > profile etc manually?
OK, P010 should be a 10bit 420 format, while Y210 is the 10bit 422 format.
I tried your last suggestion and started Cin with
CIN_10BIT_ENC=1 bin/cin
rendered a 10bit 422 mov input file and got
ffprobe -hide_banner hd01_hevc_vaapi.mp4 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], 11225 kb/s, 25 fps, 25 tbr, 12800 tbn (default)
from Mediainfo Color space : YUV Chroma subsampling : 4:2:0 Bit depth : 8 bits
But how should I apply your attached "10bit.diff" patch?
It didn't work with
localhost:/Cin # git am 10bit.diff fatal: previous rebase directory .git/rebase-apply still exists but mbox given.
try to
rm .git/rebase-apply
localhost:/Cin # rm .git/rebase-apply rm: cannot remove '.git/rebase-apply': No such file or directory
localhost:/Cin # git am 10bit.diff fatal: previous rebase directory .git/rebase-apply still exists but mbox given.
Am I in wrong directory?
oh sorry yes
rm ../.git/rebase-apply (from one level up)
you mean deleting the whole directory?
rm -r ../.git/rebase-apply
yes
Sorry, but now I get
localhost:/Cin # rm -r ../.git/rebase-apply
localhost:/Cin # git am 10bit.diff Patch format detection failed.
I was wondering if the patch needs .patch at the end like the previous patches?
sorry, it was git diff, not git add/git commit/git format-patch.
may be apply it with just cat | patch -p1 or something
or try attached
Hm?
localhost:/Cin # git am 0001-Experimental-try-10bit-vaapi-encoding.patch Applying: Experimental: try 10bit vaapi encoding error: cinelerra-5.1/cinelerra/ffmpeg.C: does not match index Patch failed at 0001 Experimental: try 10bit vaapi encoding hint: Use 'git am --show-current-patch=diff' to see the failed patch hint: When you have resolved this problem, run "git am --continue". hint: If you prefer to skip this patch, run "git am --skip" instead. hint: To restore the original branch and stop patching, run "git am --abort". hint: Disable this message with "git config advice.mergeConflict false"
you probably have previous patch applied
try git reset --hard before git am.
localhost:/Cin # git reset --hard HEAD is now at e5a5a6da Add onevpl support to build system
The "onevpl.patch" was applied, yes. Should I apply it again, before "0001-Experimental-try-10bit-vaapi-encoding.patch" again?
no
For me it looks like nothing has changed: localhost:/Cin # git am 0001-Experimental-try-10bit-vaapi-encoding.patch fatal: previous rebase directory .git/rebase-apply still exists but mbox given. By the way,testing bin/cin compression: hevc_vaapi.mp4 Pixels: vaapi (no other options) cin_hw_dev=vaapi Renders Color space : YUV Chroma subsampling : 4:2:0 Bit depth : 8 bits The same with CIN_10BIT_ENC=1 bin/cin
localhost:/Cin # ls -la /Cin lrwxrwxrwx 1 root root 29 Oct 22 20:23 /Cin -> /home/cinelerra/cinelerra-5.1
localhost:/Cin # ls 10bit.diff 10bit.diff