[Cin] 10bit VAAPI encoding test thread
Terje J. Hanssen
terjejhanssen at gmail.com
Sun Oct 27 21:11:24 CET 2024
Den 27.10.2024 20:51, skrev Andrew Randrianasulu:
>
>
> вс, 27 окт. 2024 г., 22:09 Terje J. Hanssen <terjejhanssen at gmail.com>:
>
>
>
>
> Den 27.10.2024 18:32, skrev Andrew Randrianasulu:
>>
>>
>> вс, 27 окт. 2024 г., 20:30 Terje J. Hanssen
>> <terjejhanssen at gmail.com>:
>>
>>
>>
>>
>> Den 27.10.2024 18:16, skrev Andrew Randrianasulu:
>>>
>>>
>>> вс, 27 окт. 2024 г., 19:48 Terje J. Hanssen
>>> <terjejhanssen at gmail.com>:
>>>
>>>
>>>
>>>
>>> Den 27.10.2024 17:46, skrev Andrew Randrianasulu:
>>>>
>>>>
>>>> On Sun, Oct 27, 2024 at 7:28 PM Terje J. Hanssen
>>>> <terjejhanssen at gmail.com> wrote:
>>>>
>>>>
>>>>
>>>>
>>>> Den 27.10.2024 17:22, skrev Andrew Randrianasulu:
>>>>>
>>>>>
>>>>> вс, 27 окт. 2024 г., 19:02 Terje J. Hanssen
>>>>> <terjejhanssen at gmail.com>:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Den 27.10.2024 16:35, skrev Andrew Randrianasulu:
>>>>>>
>>>>>>
>>>>>> вс, 27 окт. 2024 г., 18:30 Terje J. Hanssen
>>>>>> <terjejhanssen at gmail.com>:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Den 27.10.2024 16:21, skrev Andrew
>>>>>> Randrianasulu:
>>>>>>>
>>>>>>>
>>>>>>> вс, 27 окт. 2024 г., 13:17 Terje J.
>>>>>>> Hanssen <terjejhanssen at gmail.com>:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Den 26.10.2024 01:37, skrev Andrew
>>>>>>> Randrianasulu:
>>>>>>>>
>>>>>>>>
>>>>>>>> On Sat, Oct 26, 2024 at 2:14 AM
>>>>>>>> Andrew Randrianasulu
>>>>>>>> <randrianasulu at gmail.com> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Sat, Oct 26, 2024 at 1:29 AM
>>>>>>>> Andrew Randrianasulu
>>>>>>>> <randrianasulu at gmail.com> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> сб, 26 окт. 2024 г., 00:58
>>>>>>>> Terje J. Hanssen
>>>>>>>> <terjejhanssen at gmail.com>:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> 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.
>
>
>
> remove it again?
>
>
> 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
>
>
>
> yeah, it does not exist in normal cin, only after you add patch.
>
>
> may be just take a break from all this, I do not think we will solve
> this problem in few remaining days until end of October. So ... do
> not rush
Ok for me.
>
>
>
>
>
>
>
>>
>>
>>>
>>>
>>>
>>>
>>>>
>>>>
>>>>
>>>>>
>>>>>
>>>>>>
>>>>>> 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
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.cinelerra-gg.org/pipermail/cin/attachments/20241027/201ffb4a/attachment-0001.htm>
More information about the Cin
mailing list