• Global community
    • Language:
      • Deutsch
      • English
      • Español
      • Français
      • Português
  • 日本語コミュニティ
    Dedicated community for Japanese speakers
  • 한국 커뮤니티
    Dedicated community for Korean speakers

Bug in font display in PPro beta, AAC options missing, HEVC still broken 6 ways from sunday

Jul 20, 2021 Jul 20, 2021

Copy link to clipboard


This is a source sequence in BT.2100 PQ which is important for some  of these items.

Steps to reproduce:
    1. Right click sequence, "Export media"
Result: Fonts in various locations range from slightly glitched to unreadable.
Expected: Vector fonts display correctly like they have since Windows 3.1.

These next ones have been issues for a while, but I don't write these types of things up often so they're going here.  I was kind of hoping the beta would have fixed one or any of them, but it hasn't.  I apologize but I'm not going to make multiple posts / bugs for this topic.


   1.  Select HEVC (H.265) encoding.

   2.  Select Main10 as profile.


Result:  Hardware encoding is disabled with no explanation.

Expected:  If it's trying to use the hardware encoder chip on my GPU (Radeon Vega 64) and 10bpc isn't supported, just tell me that somewhere.   The non-beta premiere at least had a message, even though it was vague (is it my card or the software that doesn't support this?).


1.  Main10 isn't automatically selected when sequence is BT.2100


Result:  Main is selected, without BT.2020 selected.

Expected: The BT.2100 standard in force only specifies 3 color depths;  Integer (10bpc, 12bpc), and Float (16bpc).   A sequence in BT.2100 PQ or HLG can't be output to 8bpc HEVC and actually retain the color space and transfer characteristics, so making it the default is silly.  This is an issue with several other codecs that can't actually output BT.2100 compliant streams.


1.  Enable HDR

Expected:  A working HDR file.

Result:  Nothing is checked regarding the metadata, which, unless it's being output regardless of the setting, means the file won't actually trigger HDR on TVs and set-top players.  It will be wide color gamut, but not parsed as HDR.   (Note, I couldn't test this because the codec is broken, but it makes sense.)


1.  Apply any Lumetri effect that raises the max light level for any given frame (thus the max_cll) above 1000.   Enable HDR10 metadata. 

Expected:  Max and average content light level should be set to the calculated values from the video, or failing that, both set to zero (this is the case with a lot of content and it causes TV fallback to some hopefully OK defaults).

Result: Max CLL and Max FALL (which isn't really labeled properly in the encoder settings) are set to 1000 and 200.   This could either be ok or might be horribly wrong for a mostly dark video, or a really bright one.  An external utility like the x265 encoder in analyze mode is needed to pull the values, which begs the question of why I'm not just using it in the first place since it's much faster than the software encoder in premiere (Hint:  That's what I've been doing, which doesn't bode well for premiere sticking around much longer because an open source command line encoder shouldn't be easier to get working than a subscription-based GUI)


1.  Enable HDR10 metadata with a BT.2100 timeline.  
Expected:  Color primaries are either P3D65 (most common in "in the wild" videos and UHD BD, wrapped in the file's BT2020 colorspace), or BT2020.  
Result: Color Primaries default to Rec. 709, which isn't a supported BT.2100 colorspace.   That's BT.1886, which I believe only allows HLG, not PQ, and *does* allow 8bpc color... 

Expected 2:  Mastering display luma values are adjustable within the ranges specified in Rec. ITU BT.2100-2, <= 0.005 and >= 1000.   Any attempt to adjust the minimum value results in it being fixed at 0.0005.  This is correct for the default value of max 1000, but the other two standard BT2100 values are (0.005, 4000) with P3D65 and (0.0001, 1000) for BT.2020, and I'm fairly certain those are the only acceptable values for mastering luma that conform with the standard but I can't find the paper.


1.  With Main10 selected, attempt to render.

Result:  The dialogs in ppro_hevc_render-1.png and ppro_hevc_render-2.png appear (In PPro beta's export) and just the first and the similar one for the decoder appear if transfered to Media Encoder.  The resolution steps in the dialog do not work, and a search for this finds somebody from Adobe in 2017 telling the user to "format the Operating system" which is both a meaningless statement and terrible advice.

Expected:  It works OOB.  Perhaps downloading arbitrary .dll files to a public-writable directory that doesn't normally contain executables might be causing Windows 10 to block their use due to security issues.   Usually some form of elevation is required for this type of thing to work.  Since it doesn't say where I'm supposed to be getting it, how it's trying to download it and from where, or why it's missing in the first place I guess I'll never know.     I can GPU encode at 8 bit in Premiere but it tends to mess up the input video somehow (are you guys setting the encoder use to realtime and letting it drop frames?) and I usually have to split the audio out first since Premiere doesn't know anything about multiple audio tracks so the result is horribly desynced. 


1.  Set audio to AAC (from the enormous list of choices)

Expected:  All options of previous versions show up.  Parametric stereo for v2, oversampled mode for v1, etc.

Actual:  None of the advanced options for the higher two levels show up, and bitrate is maxed out at 64kbps (was 256k, 384k for 5.1)

    Application: Premiere Pro (Beta) v22.0.0.29
    OS: Windows v10.0.18363, RAM: 159.92 GB, CPUs (logical): 20

Bug , Error






Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
no replies

Have something to add?

Join the conversation