The original is upside down, with a 180degree rotation file annotation. Apparently at some point the transcodes for that recognized this and fixed it.
It seems at a later point in time it stopped being able to handle this. Bit strange, as ffmpeg should be autocorrecting for this ever since 2015.. I wonder if perhaps we have a commandline option set that accidentally disables this autorotation...
This is slightly different than T209560: Mp4 video recorded in portrait (vertical) mode gets rotated and squeezed by mediawiki as a 180degree flip bug in TMH shouldn't affect the resulting transcode in any way.
This may be a problem that's been since fixed in upstream ffmpeg...?
On ffmpeg on my stretch Linux VM:
ffmpeg version 3.2.14-1~deb9u1 Copyright (c) 2000-2019 the FFmpeg developers
$ ffmpeg -t 5 -i Tramvia_creuant_la_plaça.ogv -vf scale=320x180 barf2.mp4
-> https://brionv.com/misc/tram/barf2.mp4 upside-down
Same comment with newer ffmpeg on my Mac:
ffmpeg version 4.1.3 Copyright (c) 2000-2019 the FFmpeg developers
$ ffmpeg -t 5 -i Tramvia_creuant_la_plaça.ogv -vf scale=320x180 barf2-newer.mp4
-> https://brionv.com/misc/tram/barf2-newer.mp4 right-side up
I suspect that the 'rotate' annotation in the comments is not actually handled by Firefox, VLC, or ogv.js -- certainly I never wrote code in ogv.js to handle it -- and may be a leftover from the MP4/3gpp original file the .ogv was sourced from.
Perhaps the ffmpeg 3.2.x was incorrectly mapping it when older and newer versions don't?
Fixing the .ogv file by setting the 'ROTATE=180' to 'ROTATE=0':
$ ffmpeg -i Tramvia_creuant_la_plaça.ogv -c copy -metadata:s:v:0 ROTATE=0 Tramvia_creuant_la_plaça_norotate.ogv
and about to reupload it in place and let it re-run to confirm...