On 2026-01-22 9:21 a.m., Jeremie Courreges-Anglas wrote:
> On Mon, Jan 19, 2026 at 01:43:18PM +0100, Jeremie Courreges-Anglas wrote:
>> On Mon, Jan 19, 2026 at 01:36:46PM +0100, Kirill A. Korinsky wrote:
>>> On Mon, 19 Jan 2026 13:18:08 +0100,
>>> Jeremie Courreges-Anglas <jca@wxcvbn.org> wrote:
>>>> On Mon, Jan 19, 2026 at 12:53:36PM +0100, Kirill A. Korinsky wrote:
>>>>> On Mon, 19 Jan 2026 12:12:58 +0100,
>>>>> Stuart Henderson <stu@spacehopper.org> wrote:
>>>>>> On 2026/01/19 17:33, Pontus Stenetorp wrote:
>>>>>>>   # keep it synced with x11/mplayer
>>>>>>>   V=		8.0.1
>>>>>>> +REVISION=       1
>>>>>> please use tabs not spaces and REVISION should start at 0
>>>>>>
>>>>>>> +.include <bsd.port.arch.mk>
>>>>>>> +
>>>>>>> +.if ${PROPERTIES:Mlp64} || ${MACHINE_ARCH} == i386
>>>>>> why the arch restriction?
>>>>>>
>>>>> Probably because multimedia/svt-av1 has:
>>>>>
>>>>> ONLY_FOR_ARCHS=	${LP64_ARCHS} i386
>>>> That sucks because it means wantlib vs deps breakage on non-lp64
>>>> non-i386 archs.
>>>>
>>> I had fast look to https://gitlab.com/AOMediaCodec/SVT-AV1/-/tree/master/Source/Lib
>>> and I don't see anything that should technically prevent it from at least
>>> build on non LP64 architectures.
>>>
>>> Also, it seems that it was imported with ONLY_FOR_ARCHS=${LP64_ARCHS}
>>>
>>> Maybe try to remove it and see how it goes?
>> That, and/or ask Brad (cc) why ONLY_FOR_ARCHS was added in the first
>> place.
> ping
>
> svt-av1 doesn't *seem* to have any hard arch restriction, except:
> - message(WARNING "32-bit is not supported")
> - only amd64 and arm64 has assembly code
>
> so is there another reason why svt-av1 is disabled on all 32 bits
> archs but i386?
>
> The only other 32 bits archs which gets bulk builds is arm and isn't
> really suitable for multimedia, but still, it would be saner to clarify
> the situation here.

Originally it was set to only build on 64-bit archs as it did not even 
build on
32-bit archs, but that was fixed. Which is when I added i386 to play 
around with.

I was under the impression the memory requirements made it unusable all 
together
on 32-bit systems. It's the reason I haven't enabled support in FFmpeg 
to date.

Testing now on i386 with some 4K and 1080P content to see what things 
are like.

4K is unusable to be encoded on a 32-bit system. But it's the same for 
all of the
encoders so this is not unique to SVT-AV1. With 1080P content it does 
not seem
to be any worse than the rest.

I have removed the ONLY_FOR_ARCHS marker.


>> IIRC this restriction was already discussed in the past, if there's
>> a good reason we should at least add a comment in svt-av1/Makefile.
>>
>> -- 
>> jca
>>