A specific video sticker (vp9 webm, 512x314) plays way too fast on iOS compared to Telegram Desktop, and shows a magenta border along its top edge that other platforms do not have.
Analysis of the file: the webm track header declares 100 fps, but there are only 20 frames timestamped across 0-2.23s (real pace about 9 fps, total duration 2.23s). A player that trusts the declared track rate squeezes the entire loop into about 0.2s, which matches what iOS does. tdesktop plays it at the correct speed. The decoded frames themselves are clean: the colored top line is not part of the video content, so it is an iOS rendering artifact.
Attached: a screenshot of the sticker on iOS with the magenta top border, and a real-time screen capture of the loop on iOS (frames about 0.2s apart, the phase is scrambled because the whole loop only takes about 0.2s).
Steps to reproduce
Open any chat on iOS and send the affected video sticker (or open a chat that already contains it).
Watch the sticker loop: the whole animation completes in a fraction of a second instead of 2.23 seconds.
Look at the top edge of the sticker: a magenta line is visible along it.
Open the same chat in Telegram Desktop: the sticker plays at the correct speed and no border is shown.
Current result
The video sticker plays at approximately 0.2s duration instead of the correct 2.23s, and displays a magenta border along the top edge.
Expected result
The video sticker should play at the correct speed (2.23s duration) and not display any border artifacts.
I am experiencing the same fast playback bug on many of my stickers across multiple Android mobile devices (phones and tablets). Stickers are playing way faster than on Telegram Desktop
Thanks for the data point. Same fast playback on Android too means this is shared player logic on mobile, not iOS-only. The file I analyzed declares 100 fps in the track header while its 20 frames are timestamped for 2.23s, so any player keying off the header rate would loop it in about 0.2s on both platforms.
Glad the fix worked. The regression angle is worth noting though: if these same files played fine on older versions, then something changed in how the player trusts the track header fps. If you still have a build around where they played normally, that would pin down when the behavior changed.
Same issue here, started around the same time. I don't have a fast refresh rate in my own WebM files, but i have noticed it's only making stickers fast that seemingly use duplicate frames. I'm wondering if those got removed to save space with compression or something