Thanks. I'll explore them.

I wouldn't have thought pixel interpolation was necessary. Merely rotation of each frame by 180 degrees (or perhaps each GOP) (or perhaps I am just ignorant).

I actually ran one of my silly tests a few years ago and found differences from the original in the way Vegas does it.
Interpolation may be an inaccurate choice of words; remapping to new coordinates might be closer to what goes on.

Well, the dumb straight forward way would be to fully decode each frame, rotate 180 degrees and then re-encode. Perhaps that is what Vegas does.

t seems to me that there should be a way to rotate losslessly, just as can be done for JPEG images. MPEG is further complicated by the interframe predictive coding, but that should only be a complication, not something insurmountable. All coefficients applying to pixel (x,y) are "simply" transferred to pixel (N-x-1, M-y-1), where the frame size is NxM pixels.

Given the math involved and the complex intraframe encoding of MP4 files, I know of no way to losslessly invert the video without a decoding/encoding cycle.

Correct. Only one in every 300 frames or so constitutes an actual image, called an i-frame.
Incomplete macroblocks would result in errored or "filled in" bits.

Just turn your TV upside down.
I'll get me coat ....

Maybe rendering to a PNG image sequence & then re-rendering a new video would be the highest quality way. Except for the "rotate TV" method. Works every time. Windows even let's you flip the display w/o physically doing it so that might work too. :)

Rendering to a PNG image sequence would be absolutely no different than just having Vegas rotate the video. Of course, the visual quality of the subsequent encoding to MP4 will be significantly affected by the choice of MP4 encoding parameters and bit rate. Rotating the video is the easy part and Vegas is perfectly capable of this.

Use your mobile phone to capture a video the right way up, then put a Dymo label on the camera saying THIS WAY UP. Then you'll never have to flip the video...
Happy New Year, everyone!
David

"All coefficients applying to pixel (x,y) are "simply" transferred to pixel (N-x-1, M-y-1), where the frame size is NxM pixels."

The problem is that in highly compressed formats like MP4 with GOP encoding, there are no pixels in the data stream. All you have is mathematical descriptions of amorphous waveforms that represent an approximation of the original image, and that only on I frames. In between the I frames are merely differences between the previous I frame and the next.

The only way to pull pixel data out of that is to decompress and decode it completely, of course with the concomitant loss of quality that the original encoding introduced. If you then want an MP4 file out of it after the transformation then you have to re-encode and compress it again, introducing more quality loss.

You may not need to actually transpose the stored matrices (if no flipping is needed) . If the video player understands embedded rotation tag, then the following ffmpeg command will quickly (and losslessly) indicate to the video player on how to orient the decoded video stream

ffmpeg -i input.mp4 -c copy -metadata:s:v rotate=180 output.mp4

The trouble with the rotation tag is that some apps ignore it (MPC-HC and VideoReDo for instance).

The tag is apparently already set. I was looking for a universal solution and I suffer from a tidy mind :(