That might be more steps than you want to do unless that MP4 used a lossless codec. If you can replicate with lossless then do that -- no sense introducing more noise from two conversions that also has to be accounted for. Converting things back can also be tricky -- many times we will have decoders for video formats but no free/open source encoder (and possibly even less chance for the container), and I am not sure if that particular aspect of the Wii dev kit (or maybe gamecube before it) was leaked or otherwise made available (Nintendo in house probably means that is something in the mobiclip/act imagine family but I have not checked at time of writing this). Or if you prefer it is not only the quality issue that sees most translations of cutscenes opt to instead hack in subtitles.
Hard limit* for resolution would presumably be the limit of the console's own output (don't think the Wii U has anything special here with its backwards compatibility) with fancy component cables so presumably 480p as I don't think there are any fun tweaks for PAL regions. The real question then becomes was it basic space saving that caused the original devs to drop resolution below that limit (don't want to press those dual layer discs), some kind of technical annoyance (368 hopefully progressive is an odd resolution as these things go so not like they left it at the 480i of most Wiis on the market) or some actual hard technical limit like runs out of CPU/memory/disc bandwidth**.
The answer to that question informs what you do next, though I will note most console video playback (possibly down to specific videos within the game) is not like a normal media player where it can switch resolutions/codecs/... at will with no ill effect and instead video is usually quite deep in code to be that one specific codec, container, resolution, colour space, possibly bitrate range (or at least a max) and whatever else. You might get lucky and find it plays any valid thp file that does not stress hardware limits but it is not a bet I would take and would expect to have to comb through code and hold its hand as you tell it to play something it was not originally explicitly coded to do. If it is a more tricky limitation like CPU bound then you still have options (usually go for a more low impact codec -- the Wii quite notably having a motion JPEG decoder somewhere in it all that various media streamers used, but you could optimise something beyond what the original devs*** could do) but not nice ones.
*most of the time we do ROM hacks to work on hardware around here but there are emulators, successor consoles, later console revisions (granted all later wii models themselves are worse than the older ones unlike say the Amiga, PSP or 3ds) that might exceed things, and if your emulator does Lua you might even be able to go the other way and have the emulation pause, load up some glorious better than 4k 10bit 240fps video (not sure how you would get that in anything like useful extra data from such a source but hey) rendered on your PC before returning you to the game after it is done.
**if you are playing this from USB drives or SD cards then different matter entirely. Can also be things like while the drive max was certain rates then you have to assume troubled drive or indeed video being used as a glorified load screen and thus half the speed goes to something else (grabbing the next level maybe) and still have it work.
***this was likely not some random game devs being thrown into the video encoding jungle (
https://www.gamedeveloper.com/audio/in-depth-playing-with-video ) but instead a dedicated firm (Nintendo had been variously partnered with mobiclip/act imagine for quite a while by this who were a legit video software firm with a decent chunk of the Japanese phone market, and they later bought them out). If you are asking this sort of question though then chances of you being able to assembly hack in a new codec or more optimised codec is rather slim/you face a massive barrier to entry.
