good morning.. (Your comment that by common knowledge playback in Premiere is mainly Mercury, therefore GPU, is completely in error.)... you have the best connections to adobe yourself...so go , ask the developers of your choice..... I / we did, not long ago , and we have a protocoll and the proven statement : decoding = mercuryplayback (always). .. in case of set to "software" ..you are right = cpu...in all other cases = gpu ..can / will not tell more (under nda) if it would be only the cpu we all at the timecritical business, could save a big bunch of money and forget the expensive graphicsadaptor ...if only fast editing mainly without affects is required, an internal Intelgraphics xyz would be enough. For example ...on my timeline there are only plain native 60Mbit/s clips from one camera (H264) ...no editing , simply dropped it on a new sequence..ne effects ...nothing..... playback with "metal" ....depending on the movement in picture running semi-smooth with some stutters/jerks. switching to "software-only" .... much much more stuttering! So , if it is aways only the cpu (no effects applied) why is there a difference ... maybe you can explain it !? (cpu-centic) : I agree ...meaning the cpu organizes and pushes/pulls the data from storage via databuses to ram / and/or registers of cpu/gpu depending on functionality. but the cpu is not decoding the frames to baseband in cases of "metal/openCl". ... ask the developers yourself. (even a Samsung T5 is adeqate ) = 100% agreed and tested ... absolute right! (No. If your original is a variable frame rate, GOP codec (such as H264), Prores is going to be smoother....) Else then the Iphone , I have not seen any noticable camera on the market which creates VARIABLE FRAMERATES. This is not commonly used because of H264. nearly 99,9% of all cameras set to H264 are working in FIXED FRAMERATE ...... ONLY if set to H265 then some of them , because of the lack of processingpower can switch to "variable"... but this is not the case in here! (The whole point of making proxies is to make them smaller than your originals...) How can you do this ? In case of H264 you would need a much more efficient codec to get it smaller...and that would be H265 as the only choice !? ProRes is always much bigger (less efficient but I-Frame only) . Even LT is 102Mbit/s , and as noticed above, that is no benefit if having 100Mbit camerafootage. You only get it smaller if you reduce the framesize (HD-SD / 4K-SD). Changing from Interframe (GOP) to I-Frame only will always increase the bandwidht (nature of physics ...now you have to store every frame fully, instead of only describing the changes in between the frames ). And here lies the bottleneck (as you mentioned very clearly)..it is the calculation backwards from the last/next full I-Frame , add the changes of the B or P-Frame and create the full required frame in realtime. That is what mercuryplayback is made for, and that is what even AdobeRush/LumaFusion/FinalCut/Reolve (to name only a few) even in H264 can recalculate in faster then realtime . but...enough discussion.... the future will show the truth..the next IBC is around ...announcements will possibly made ... other companies will show theirs .... and reality will show each of us the best way for our way of surviving the productionmarket. ... and complaining customers will rise more and more if adobe does not change it's policy immediately have a nice day
... View more