Spent a few hours trying to make sense of this … (mess?); let’s sum up.
The problem with VLC is still this one: no-h264-support-on-leap-16-0
Some package installed during your last round enabled HW decoding, likely libvulkan_radeon but I have no such HW so I can only guess.
SM-Player (and the underlying mpv) work even on a VirtualBox VM: no HW decoding, no vulkan, no Packman, slow CPU etc.
Jumping back and forth works, temporary stop-and-wait are normal (check the SM-Player logs with CTRL+S) while mpv looks for the appropriate “base frame” (see below). Maybe enabling hw acceleration shortened that seek time so you now don’t notice it.
And here comes the next chapter of the story.
The file_example_MP4_xxx, like more and more .mp4 files on the net, has a “base frame” every 3 seconds. You can easily see that with SM-Player: try to jump to 5 or 7 seconds, play actually resumes at 3 s or 6 s respectively.
So when you jump to an arbitrary position, the player seeks for the last leading base frame and resumes playing from there.
SM-Player and the underlying mpv stop during that seek time but are not frozen, as the log reports.
On the other hand, Firefox is apparently unable to look for the last leading base frame and simply stops, complaining that “Video can’t be played because the file is corrupt”.
Disclaimer: since I’m no video specialist, others might have a better understanding about the details.