From: "Peter J. Philipp" <pjp@delphinusdns.org>
Subject: ffmpeg on riscv64
To: ports@openbsd.org
Date: Tue, 23 Jul 2024 08:26:24 +0200

Hi,

I had a long debug on ffmpeg on riscv64 and noticed that it only works with this
patch:

0813/stern$ more patch-libavdevice_v4l2_c                                      
--- libavdevice/v4l2.c.orig.port        Wed Apr 12 20:01:50 2023
+++ libavdevice/v4l2.c  Mon Jul 22 16:21:58 2024
@@ -95,11 +95,7 @@
     int (*open_f)(const char *file, int oflag, ...);
     int (*close_f)(int fd);
     int (*dup_f)(int fd);
-#ifdef __GLIBC__
     int (*ioctl_f)(int fd, unsigned long int request, ...);
-#else
-    int (*ioctl_f)(int fd, int request, ...);
-#endif
     ssize_t (*read_f)(int fd, void *buffer, size_t n);
     void *(*mmap_f)(void *start, size_t length, int prot, int flags, int fd, int64_t offset);
     int (*munmap_f)(void *_start, size_t length);


As you may have just seen that I took out the __GLIBC__ ifdef which may need to
be defined somewhere, this is best debated by you (the openbsd ports team).
I just want to make this work with this (partial) script:

            ffmpeg -y  -loglevel verbose -thread_queue_size 256 -copyts \
                        -vcodec rawvideo \
                        -f video4linux2 \
                        -i /dev/video0 \
                        -c:v copy \
                        -c:v libvpx-vp9 \
                        -vcodec libvpx-vp9 \
                        $OUTFILE  & 

                ffmpeg -y -loglevel quiet -thread_queue_size 256 -copyts \
                        -acodec pcm_s16le \
                        -f sndio -i snd/1 \
                        -c:a libvorbis \
                        -b:a 128k \
                        $OUTSOUND 
---

Unfortunately after fixing the ffmpeg, I noticed that my riscv box is too
slow so I'll have to look what I can do to speed it up (like offload routines).

Basically in the patch when the ioctl is taking an int instead of a u_long,
the kernel exited with ENOTTY which I had modified with a DPRINTF that looked
like so:

Jul 22 20:40:56 stern /bsd: huh? 18446744072641074714 is the case they gave me

    386         default:
    387                 DPRINTF(1, "huh? %lu is the case they gave me\n", cmd);
    388                 error = (ENOTTY);
    389         }
    390
    391         return (error);

which is from the /sys/dev/video.c file.

The fix is in userland thus ffmpeg, but it took a little debugging kernel to 
understand what was happening here.

This fix/workaround shouldn't affect anything because of the SYNOPSIS in the
ioctl(2) manpage:

---
SYNOPSIS
     #include <sys/ioctl.h>

     int
     ioctl(int d, unsigned long request, ...);
---

Fix at your judgement whether this is the way to go.  I'm not on the ports@
mailing list so if you need feedback at anything CC me directly.

-pjp

-- 
** all info about me:  lynx https://callpeter.tel, dig loc delphinusdns.org **