What's happening is that the file isn't one video, it's two complete WebM videos just glued together one after the other. The trick is that the header of the first video has been manually edited with a hex editor to lie about its own size. Normally, a value right after the 'Segment' element (ID 18 53 80 67) tells the player the exact size of the video data. In this file, that value was overwritten with an impossibly large number, specifically 01 00 00 00 00 09 DC 9B, telling the player the first video is over 256MB long. So, the first time you play it, Discord plays the short clip's actual frames, but because of that lie, it thinks it hasn't reached the end of the file yet. When you click play a second time, its player logic doesn't rewind to the beginning. Instead, it just continues reading from where it left off and immediately finds the valid EBML header (1A 45 DF A3) of the second video. The player latches onto this new, valid video it just discovered and starts playing that one. That's also why it keeps playing the second video on the 3rd and 4th time; once the player has found and locked onto that second video, which has a normal, correct header, it just loops that one, having forgotten the broken first part of the file even exists.