Cursor Frame Behavior (Affecting In Out, Ripple Edits).

Ok team, I know you had some guy complain about how the Cursor works in the timeline, and now you changed how it works, which completely screwed over the Ripple Trim to Previous Edit.

What WORKED before yesterday was if you were on the front of a clip in the timeline, and you hit the Ripple Trim to Previous Edit, it would remove the first frame and obviously move the entire timeline up a frame to compensate.

THIS WAS INSANELY HANDY because if you're trimming a clip, you could just hit that button a few times and make it work right.

Now, because you guys changed how the cursor works, I have to hit Right on my keypad, and then hit the Ripple edit button, and it'll remove that first frame.

Guys, you seriously screwed over an entire generation of editos who know how editing works. I know some people complain about how the cursor works, but this sucks.

Why not just create a preference option where you can make the Cursor act like FILM or act like it is now. All NLEs were based on film editing, which lots of people expect and relied upon. Now, I have to hit an extra keystroke all the time which is massively time consuming.

Can you please just put in a preference option to revert back or not? That would solve this issue for everyone instead of bowing to people that don't understand NLE history.

I've worked with these files fine in Premiere v15.4.1 and did not have this issue but since updating earlier this month to v22.1.2 I've had several issues with Premiere errors while editing and random crashes without warning or pinwheel of death.

Most common error is "Unable to access resource "SErrorXlND@2x'(type svg)" Attached screen shot below. Once this error occurs I almost always have to completely restart Premiere.

It also has made it nearly impossible to export a finished project from both Premiere and Media Encoder. When doing so it will hang up at some point in the export and create an Accelerated Renderer Error - Unable to produce frame.

The only way I'm able to export is by changing the render settings from GPU to mercury playback engine software only. That work around works for now but isn't great.

The issue is difficult to replicate. I've provided my computer specifications below.

Mac Pro 2019
BigSur 11.6
3.2 GHz 16 Core Xeon W
128 GB Ram
AMD Radeon Pro Vega II 32 gb

Request for Essential Graphics Text Tool
It is wonderful to be able to gradation the color of letters!
Thank you very much! !! Very glad! !! All Japanese users are happy!

As a request for further creative creation ...
・ We want a gradation function for the border.
・ We also want a gradation function for shadows.
-Multiple boundaries can be used. We want you to be able to use multiple shadows as well.

Especially in the Japanese video industry, multiple boundaries and their gradations are really used a lot. Hopefully at this time, we hope for further evolution!
Thank you!

エッセンシャルグラフィックステキストツールのリクエスト
文字の色をグラデーションできるようになったことはとても素晴らしい！
本当にありがとう！！とてもうれしい！！日本のユーザーはみんな喜んでいます！

さらなるクリエイティブの創造のためのリクエストとして・・・
・境界線にもグラデーション機能が欲しい。
・シャドウにもグラデーション機能が欲しい。
・境界線は複数使用することができる。同じようにシャドウも複数使用できるようになって欲しい。

特に日本の映像業界では、複数の境界線、それらのグラデーションは本当に多く使われています。できればこのタイミングで、さらなる進化を望みます！
よろしくお願いします！

h264 exports done on an M1 MacMini show significantly more compression artefacts than those done on non-M1 hardware. In investigating the problem I noticed that the file sizes are significantly smaller than expected and digging into the export shows that the resultant bitrate is only around 60% of what it should be. This is across all the built-in presets that use single-pass h264 hardware encoding as well as any custom ones. To prove the point I encoded the same file on several platforms, (both Mac and PC), with several export presets. See the attached file that shows the results.

h264 exports on M1 hardware only achieve 60-65% of the target bitrate, where-as other hardware is in the 80-90% range.

Bitrate isn't the whole story as increasing it such that the resultant file has the intended bitrate still produces files with more noticeable macro-blocking, (although the differences are now more subtle).

I have also tried using v22.1 BETA of both Premiere and Media Encoder, which give the same low bitrate exports on M1 hardware.

The new color management options in 22.x versions break the proxy color and dynamic range, when using LOG or HLG/PQ original clips that have been over-ridden to Rec.709 with an input LUT.

The original clip on the Rec.709 sequence is 'normalized' correctly. But when you then go to create proxies, the CM is not used in creating the proxy.

What you get is a blown out useless mess of an image as your "proxy".

Not a correctly viewable image in the same color space as the original clip and the sequence.

We need the proxies to follow the clip Color Management.

We rendered a 960x540 DNxHR LB clip in MXF OP1a container out of DaVinci Resolve.

Upon trying to import it into Premiere Pro, the Project Panel metadata wrongly shows that clip as being 1280x540, even though VLC and DaVinci Resolve show it correctly as 960x540. After importing, the clip is stuck showing the "Media Pending" graphic and won't show that actual footage.

Rendering the same clip from DaVinci Resolve as 960x540 DNxHR LB in a QuickTime MOV container allows Premiere Pro to import the clip fine, show it correctly as 960x540, and show the footage just fine.

So this appears to be some kind of nasty bug from Premiere Pro with the MXF OP1a container and DNxHR LB footage at this resolution.

Yesterday I started Premiere after a long time and faced a strange crash on Startup. At first I thought it's because of the Blackmagic RAW plug-in. At least it was the last thing Premiere Launcher showed on the Screen. After deleting the BM_RAW Plug-in, it kept hanging on other Plug-ins and dll's.
Meanwhile, I had upgraded to a new Monitor and had another Graphics driver. So I started deleting, reinstalling and updating everything possible. I also used "AdobeCreativeCloudCleanerTool", but unfortunately it didn't help to remove everything. I changed Monitor refresh rate, because I thought maybe Premiere can't handle 240Hz (BTW it works fine). So after almost one day spending to open Premiere, I remembered that my NAS is turned off. It was very strange to imagine that the missing Network Path to some favorites in the Media Browser can cause such a problem... but guess what, it was...
I can reproduce this problem by turning off the network card (You can see the Video on Youtube -> https://youtu.be/xMhbPeQUNN4 ). So It's actually a big problem and I guess there are many Users having the same issue, not knowing the cause.

So I have 2 kindly requests:
- please add a function that detects if a Path is missing and show it as notification and let the Program start (just like if a file is missing, and you can mark it as offline). This Problem shouldn't cause a Program to crash.
- I wasn't able to detect any reason for the crash in Windows Events.
At least, no useful info.
This is all I get:

Description:
A problem caused this program to stop interacting with Windows.
Faulting application path: C:\Program Files\Adobe\Adobe Premiere Pro 2021\Adobe Premiere Pro.exe

Problemsignatur
Problemereignisame: AppHangB1
Application Name: Adobe Premiere Pro.exe
Application Version: 15.4.1.6
Application Timestamp: 610dd418
Hang Signature: 9f91
Hang Type: 134742016
Betriebsystemversion: 10.0.19043.2.0.0.256.48
Gebietsschema-ID: 1031
Additional Hang Signature 1: 9f91c8cf2156af83a7f3a52b3ee474b4
Additional Hang Signature 2: ab04
Additional Hang Signature 3: ab042c0da1b85fd3e46862b994258421
Additional Hang Signature 4: 9f91
Additional Hang Signature 5: 9f91c8cf2156af83a7f3a52b3ee474b4
Additional Hang Signature 6: ab04
Additional Hang Signature 7: ab042c0da1b85fd3e46862b994258421

TL;DR:
If you have a Network path as favorite in Media Browser and that Path is not reachable, Premiere Pro and After Effects will probably crash on startup.
I hope this gets fixed soon, and it will possibly help someone.