On 09/05/2026 13:00, Erikas Bitovtas wrote:
across reboots, so when I reverted the patch, I was actually testing
against decoder, not encoder.
So, the result is the same when the patch is applied, when it is
reverted, and when testing against v1 where the cores are enabled only
for decoding.
OK but this is testing encoding
v4l2-ctl --verbose
--set-fmt-video-out=width=1280,height=720,pixelformat=NV12
--set-selection-output target=crop,top=0,left=0,width=1280,height=720
--set-fmt-video=pixelformat=H26
4 --stream-mmap --stream-out-mmap
--stream-from=cyclists_1280x720_92frames.yuv
--stream-to=/tmp/cyclists_1280x720_92frames.h264 -d /dev/video1
I think the GDSC patch specifically isn't too much of a concern.
1. Core0 works as decoder
2. Core1 doesn't work right now.
So what I'm trying to ask is if we could test it both
as an encoder or as a decoder.
If decoder works when both cores are declared decoder, we know there's a
problem with encoder and could potentially proceed with upstream decoder
x 2.
OTOH if Core1 can't be coaxed into working in either mode, we are better
off either holding off on this series until the breakages is root caused
or leaving out Core1 entirely for now.
i.e. there is no utility in declaring an encoder or decoder to userspace
that is known to be broken.
---
bod
