Can just use avif instead, it holds an AV1 stream and acts like gifs/images do WRT looping — also very broad support (more than AV1 in WebM containers).
Demonstration:
Edit: switched to an example with simpler decode requirements.
I do regularly. However apple users are largely the bane of this. Apple’s support for things can be very slow and spotty. As long as you keep it extremely old and basic. Say h264 they’ll be able to see. A lot of apple mobile devices could support h265 but apple doesn’t. My last couple of mobile devices have supported it for nearly a decade. But apple enabling it on their mobile hardware hasn’t been anywhere near that long. Apple will hopefully have AV1 support common by the time AV3 is released and AV2 widely supported by the 2030s.
Oh yes with respect to Avif you are correct. I was more referring to multimedia messages in general. But you are correct about Avif. That format in particular is not well supported a lot of places. I know Linux is probably one of the few areas it sees much. Windows is a much different story and I’m sure Apple desktops as well.
I checked that app’s source code, and basically they’re doing their own avif decode call instead of relying on a browser/webview to handle it. So essentially they forgot/don’t know/don’t intend to implement animated avif. Looks like they also use the aom reference decoder instead of using something faster like dav1d.
(on Arctic on ios) the uploaded image displays as a static image for me. Even clicking on it and waiting, it doesn’t seem to animate :T
Edit: I checked again through the Voyager app, and it did indeed load, though it took around 45-60 seconds* for it to get through the entire animation before it started looping again, albeit at the same speed as the first playthrough.
I chalked it up to the outdated hardware, as you mentioned in your reply. Cheers! :)
Apple has limited support for AV1 streams (yes, even for software decode) unless on very recent hardware.
Here’s an AV1 stream inside a webm container for comparison, would be interesting to see if that works over the avif container on your stack.
Ah yeah, that would explain it - my phone is now pretty outdated (I’m on a 12) - I clicked on the image link in your response but it didn’t load for me, unfortunately.
I’m not sure if that’s a result of my outdated hardware or if I perhaps clicked on it before it had a chance to process your upload, but you seem much more knowledgeable than I, so I’m going to assume it’s my hardware. I appreciate the response and the second attempt, though! :)
It’s an intentional behavior by Apple. Basically they just don’t support AV1 videostreams unless the hardware you’re using has a hardware decoder (read: very new). They could support it using software decode (what browsers typically do for AV1 inside avif containers) but… for whatever reasons don’t.
It’s not the route I’d take, after all, the video tag in html supports specifying multiple sources (including different formats/encodings), and with full control of the stack (they vend Safari) you could have logic on devices without AV1 hardware that prefers the AVC/HEVC/VP9 sources instead — then fallback to AV1 SW if it’s the only option. That seems a better user experience than just failing to display content.
Counterpoint: GIFs loop by default in basically every app, WEBM doesn’t
Can just use avif instead, it holds an AV1 stream and acts like gifs/images do WRT looping — also very broad support (more than AV1 in WebM containers).
Demonstration:
Edit: switched to an example with simpler decode requirements.
your demo is a static image.
Your example image doesn’t work in boost while the gif above does :/
Let me know when I can text one of these to someone
I do regularly. However apple users are largely the bane of this. Apple’s support for things can be very slow and spotty. As long as you keep it extremely old and basic. Say h264 they’ll be able to see. A lot of apple mobile devices could support h265 but apple doesn’t. My last couple of mobile devices have supported it for nearly a decade. But apple enabling it on their mobile hardware hasn’t been anywhere near that long. Apple will hopefully have AV1 support common by the time AV3 is released and AV2 widely supported by the 2030s.
Apple only supports avif on paper and doesn’t actually support avif in iMessage in practice. It won’t display properly and they don’t care to fix it.
On the Android side Google Messages Doesn’t appear to support avif at all
Oh yes with respect to Avif you are correct. I was more referring to multimedia messages in general. But you are correct about Avif. That format in particular is not well supported a lot of places. I know Linux is probably one of the few areas it sees much. Windows is a much different story and I’m sure Apple desktops as well.
an Osman classic
Works great as a static image. Would probably be better if it actually played…
Boost for Lemmy is not a fan.
That’s caused by bad regex in the app, it’s getting confused about domains.
e: attempted fix by using an aliased domain.
Your demonstration is a sluggishly loading static image on my end, so I guess support isnt that widespread :P
(Im using the app “Summit”)
I checked that app’s source code, and basically they’re doing their own avif decode call instead of relying on a browser/webview to handle it. So essentially they forgot/don’t know/don’t intend to implement animated avif. Looks like they also use the aom reference decoder instead of using something faster like dav1d.
Static image, Eternity.
Static image, also Summit.
It’s unfortunately not that simple. The AVIF doesn’t load at Jerboa, for example :/
(on Arctic on ios) the uploaded image displays as a static image for me. Even clicking on it and waiting, it doesn’t seem to animate :T
Edit: I checked again through the Voyager app, and it did indeed load, though it took around 45-60 seconds* for it to get through the entire animation before it started looping again, albeit at the same speed as the first playthrough.
I chalked it up to the outdated hardware, as you mentioned in your reply. Cheers! :)
Apple has limited support for AV1 streams (yes, even for software decode) unless on very recent hardware. Here’s an AV1 stream inside a webm container for comparison, would be interesting to see if that works over the avif container on your stack.
This doesn’t work for me but the original one you posted does (Voyager, iPhone 14 pro)
Very interesting, thank you!
Random Android phone on Voyager; yes.
Ah yeah, that would explain it - my phone is now pretty outdated (I’m on a 12) - I clicked on the image link in your response but it didn’t load for me, unfortunately.
I’m not sure if that’s a result of my outdated hardware or if I perhaps clicked on it before it had a chance to process your upload, but you seem much more knowledgeable than I, so I’m going to assume it’s my hardware. I appreciate the response and the second attempt, though! :)
It’s an intentional behavior by Apple. Basically they just don’t support AV1 videostreams unless the hardware you’re using has a hardware decoder (read: very new). They could support it using software decode (what browsers typically do for AV1 inside avif containers) but… for whatever reasons don’t.
Haha, ye$, for rea$on$, I’m $ure… :D
I’m not sure demand for AV1 is enough to ship units
Probably either laziness or they want to avoid software decoding in general for performance reasons
I think that’s a reasonable way to look at it.
It’s not the route I’d take, after all, the video tag in html supports specifying multiple sources (including different formats/encodings), and with full control of the stack (they vend Safari) you could have logic on devices without AV1 hardware that prefers the AVC/HEVC/VP9 sources instead — then fallback to AV1 SW if it’s the only option. That seems a better user experience than just failing to display content.
Fwiw it works on the desktop’s alexandrite ui and on the thunder app
For the record, this is static in my Lemmy app (Summit).
on boost its a little slow but time quality.
better than most moving images in comments!