After Effects and Adobe Media Encoder 2020 are rendering h264 codec MP4s too bright. The colors are washed out slightly and what I'm assuming is a gamma shift. I'm using Windows 10, After Effects v17.1.4, Adobe Media Encoder v14.4, and Nvidia driver 451.77.

This issue does not exist on After Effects 2019 and Adobe Media Encoder 2019. The MP4s look as you would expect, using identical settings for export.

One additional finding was that using After Codecs plugin, I'm able to export an MP4 using the x264 codec and the colors are correct. That is also using AE and AME 2020. So, from what I'm gathering there is definitely an issue with AME 2020.

I find this annoying issue with nearly every release of AME, and have had it pop up off and on since 2004. This is not an issue with playback between video players, but specifically a color shift in the actual render. I'm not using any display profiles, and have After Effects set to not use a Workspace color profile in Project settings. Have also tested rendering the files with and without Hardware encoding turned on.

Would be happy to send additional info or files if needed. Thank you!

I'm editing a feature documentary, and many of the archives are made of old DV footage. Unfortunately I can't import any of the material either directly into premiere or into ME to convert into a supported format. Adobe should have kept the codec at least for media encoder. I can't imagine the amount of editors around the world who've had similar frustration and with the monthly subscription service as it is, a creative cloud user, shouldn't have to turn to or pay for additional 3rd party support for a feature that was a part of the older editions. It's absurd to the extreme. An entire generation of archive was shot on the DV format, so the decision to remove it smacks of corporate greed or oversight. Something that could be easily amended on their side, if they so consented.

Hello Everybody,

I would like to ask if there could be an option added maybe to premiere or especially to Adobe Media Encoder to be able to Remux files to different containers.

Option also without transcoding just copy the CODECS from input file and change only the container.

Example there is one really important remuxing that is needed and there are just so limited the options for someting so simple.

In Broadcasting Centers there are still a lot of equipment that only support Transport Stream (TS), as there is only option from Adobe for MPEG2 and not for H264 which is what we need.

Also if there could be one option for only multiplexing to change container with out encoding again would save a lot of time for cases where the files are already h264 but mp4/mov/mkv.

By selecting multiplex and with codec to only copy would take seconds even for 2 hour long videos.

Thank you and hope somebody will take this in consideration for future update.

We just had an issue during QC: there was an obvious low quality shot in our AVCIntra100 file export.

We came from a ProRes4444 HD master file and used Premiere 15.1.0 and AME to encode the braodcast deliveries. But the result is a low detail image with artifacts and loss of details.

We use the "ARD-ZDF HDF02a-1.1" Profile and just changed the Scan Order (to Progressive) and enabled the "Render on Maximum Depth" and "Use Maximum Render Quality" checkbox. We are on MacOS 10.15 and tested it on 10.14 and Premiere CC 2020 too. Same result.

We did the same export with other tools and it looks much better. So this is not a codec issue per se.

You can get the samples here: https://we.tl/t-4t9uKlccD0 (uncompressed PNGs with 400% preview scaling).

When exporting from for example After Effects, I'd like to take advantage of the newest formats to cater the needs of my co-workers and ensure the best quality. This includes being able to make life easier for the developers with more flexible formats like WebP and WebM. WebP is very versatile; it allows for a 24-bit transparency coloring, which is something other animation formats simply do not support (and formats that do support it, are not supported by web browsers).

Supporting WebP would solve this (for stills, but also for animation). Animated GIFs don't support the same level of transparency, which deminishes the flexibility (since it requires you to select a matte, which is only sporadically desirable).

Windows 10 - 32GB RAM - GTX1080
When I export a show with embedded closed captioning as an OP1a MXF from Premiere Pro 14.8 to Media Encoder 14.8, the captions are being changed from .scc to .mcc. I am exporting an HDCAMHD 50 MXF that has 608 and 708 captions that were imported from Scenarist files (.scc). When I go to the captions tab in PPro, I am selecting "Embed in Output File." Below that, the greyed out boxes confirm that it is a .scc file. I can even check "Create Sidecar File" and .scc is still one of the options. Everything is correct. I have done numerous times before. However upon queuing to Media Encoder, the captions tab show ONLY Mac Closed Captions (.mcc) Timed Text (.xml) or SubRip (.srt). There is no longer any option for Scenarist (.scc) files.

This is a new issue, as I have used this workflow many times before. So, currently, I am having to export directly from Premiere in order to get embedded Scenarist closed captioning in my MXF files for broadcast. Can this be fixed RAPIDLY???????

When encoding MP4 files from Media Encoder or Premiere Pro the exported file is missing the SAR and DAR values.

This can be easily check with ffprobe and this command:
ffprobe -v error -showformat -showstreams file.mp4
[STREAM]
index=0
codecname=h264
codeclongname=H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10
profile=Main
codectype=video
codectimebase=1/50
codectagstring=avc1
codectag=0x31637661
width=1920
height=1080
codedwidth=1920
codedheight=1088
closedcaptions=0
hasbframes=2
sampleaspectratio=N/A
displayaspectratio=N/A

As you can see above the encoded file shows N/A values instead of the expected SAR value 1:1 and DAR value 16:9.

I have of course tested with other source files and mp4 files from other vendors and they provide these values in the mp4 files they create.

Is this perhaps a bug or missing feature?

Hope for a resolution in the near future :-)