mp4 playback

I use mp4 files from client in my workflow. Before studio 20 these would playback fine. Now they're playing in the single digit range, (2-3fps). Is there anything I can do to fix this?

Thanks

Difficult to say. You give us NO details.

Thanks.

H.264, on an Apple M1 Max running Sequoia 15.1. The same files worked fine in V19.

It's also an issue with mp4 files I've rendered myself (so it doesn't appear to be an issue with the client doing something odd).

Can you post a sample to a cloud?

H.264, on an Apple M1 Max running Sequoia 15.1. The same files worked fine in V19. It's also an issue with mp4 files I've rendered myself (so it doesn't appear to be an issue with the client doing something odd).

H.264 is not a good choice for workflow. You'll get far better results with a light-duty ProRes format like 422, or possibly ProRes 422HQ (if it's 10-bit H.264).

You could transcode it outside of Resolve with a utility like Handbrake (free) or Uniconverter (paid), or Adobe Media Encoder or Apple Compressor. Do a short test and check what the speed difference is between playing back the native H.264 and a ProRes 422 transcode.

The amount of RAM and cores you have in the M1 Max will also have an effect on speed. H.264 plays back great on the M4 Max I'm using here, but I still avoid it for a session whenever possible.

Sorry, Marc, but that shouldn’t happen between 19 and 20.
I can work smoothly with H.264 in both versions on a humble M1. Something else must be wrong.

[Shrinivas Ramani]

Hi Jacob

Please add a link to a sample clip (and a project if there are changes or effects involved), so we can take a look.

Thanks
Shrinivas

Thanks for the replies all.

@ Marc, I'm aware it's not a good workflow, but it's what the client sends, and worked absolutely fine before I upgraded to V20. I mean, it worked fine on my ancient intel MacBook. I know I could transcode, but I'd rather find the cause than have to add another step.

I'm working with prores proxy for my rushes.

@ Shrinivas, I can't post a link unfortunately, as it's all embargoed.

Thanks for the replies all.

@ Marc, I'm aware it's not a good workflow, but it's what the client sends, and worked absolutely fine before I upgraded to V20. I mean, it worked fine on my ancient intel MacBook. I know I could transcode, but I'd rather find the cause than have to add another step.

I'm working with prores proxy for my rushes.

@ Shrinivas, I can't post a link unfortunately, as it's all embargoed.

You claimed your own h264 files also played back slowly or did I misunderstand you? You should be able to generate sample media that is not 'embargoed'? Maybe include a project file so that we can see what other settings you have set that may explain the slow-down?

...I can't post a link, unfortunately, as it's all embargoed.

Use Quicktime Player's built-in feature to trim a very small piece of an original camera file which demonstrates the problem. This does "no encode" trimming, so the extracted piece will have all the characteristics of the original long clip.

A three-second outtake not disclosing anything should be sufficient. Please upload that to a file-sharing site and post the link here. I have an M1 Max, M1 Ultra, and several other Macs I can test it on.

However, make sure that three-second clip with no effects still exhibits the problem. You could also duplicate the timeline and disable or remove all effects to determine if it's a problem with MP4 playback or a problem with a certain effect. If it's a problem with a certain effect (inc'l retiming), we won't be able to reproduce it without more details.

Instructions: https://support.apple.com/en-mz/guide/q ... 15f6fd/mac

Quicktime Player also allows splitting and reordering clip segments, then exporting without re-encoding: