Content
@
0 reply
0 recast
0 reaction
Ryan J. Shaw
@rjs
I did some experiments recently with async updates to frames, because I know that the Cloudflare proxy is new to the mix for the most popular Frames client - Warpcast: 1. MJPEG streaming works, but only on desktop. 2. GIF streaming does not appear to work on either desktop or mobile; CF appears to try loading the entire GIF and seems to repeatedly give up and retry. If anybody's interested I'll share my source code. 3. It's possible that some combination of cache control values can rescue GIF streaming, but values that worked for e.g. my countdown clock don't seem to work for GIF streaming (`https://warpcast.com/rjs/0x010c0699`). 4. Maybe there's a particular GIF size which might avoid additional processing by CF, if the issue is that WC is trying to apply some kind of resizing operation, but I don't see any hints in the proxied URL.
4 replies
0 recast
21 reactions
adnum
@adnum
Thanks for testing that out. Was curious myself. Mind sharing the test env setup and code? Came across CF proxy but did not tray it yet. I use pyjam.as most of the time
2 replies
0 recast
1 reaction
Ryan J. Shaw
@rjs
Oh BTW the CF proxy I'm referring to is what the Warpcast client uses when loading images (they proxy stuff for privacy, otherwise you could track who's viewing your posts)
1 reply
0 recast
0 reaction
Ryan J. Shaw
@rjs
For the MJPEG details see my reply to my own post, it's a link to a blog post explaining how the DOOM frame works The GIF streaming is pretty simple and works on a local browser, but not in the Warpcast Frames validator, or when posted https://warpcast.com/rjs/0x14f888b7 https://github.com/ryanjshaw/frames-gif-streaming-test
1 reply
0 recast
0 reaction
