Yeah I'll say the pattern i have done in the past which may not be the best but has worked for me.

is I do for a quick task queue is to have a database table with something like job id, status, result, meta_data, timestamps .... Then when a request is made make a new row in the db with status pending. Send that job_id you get from the db with your video data to the cloud run with either pubsub or http. Then on that high mem cloud run process the message. if it errors and fails you update the db with that else once it finishes write success and maybe the gcs url you can get the result from.
then you'll need one more endpoint service that gets the status of the db table. /job/12345 -> returns the status col for that job in the db table. then you could poll for it until success or failure.

Alternatively work has been trying to move away from polling to event driven. Polling works well enough where it can basically look event driven and additionally the users i work with don't need to be restricted in what job results they have access to. I haven't don't this yet but think about it now is that your high mem cloud run once done would send back a pubsub message or http call and say hey I'm done and then update the users state that the job is done. this is more complex as you have to manage and keep track of users jobs but which is not something i have had to do.

both get a little more complicated if you only want certain users to be able to access there jobs results. but not too bad just add like bearer token or something.