![]() Thanks for the further clarification! so another question for you guys. (Note that 10-bit is even more compressed because while you are 10-bit, the data rate is the same as the 8-bit codec.) Most people using 29.97 or 59.94 projects find DNxHD 145 to be just fine, but you could also use 220 or 220x (10-bit) if you want. You can also pick whatever resolution you want, based on the amount of disk space and footage you have. I would certainly recommend the second method, and you'll have to decide whether you want to transcode or start editing immediately. This will create new files, but only the scenes you used (plus user-defined handles). ![]() The advantage is that when you are done, you can take your finished sequence, relink to your AMA files, and then re-transcode at a higher resolution. Most people, after they Link, will TRANSCODE which will convert the AMA material into Avid MXF media at a desired resolution. It also is more cumbersome to edit, since your CPU has to deal with every frame in real-time to make it a more editor-friendly format. Avid does not manage your media, so the chance of it going offline is more likely. When you LINK TO AMA, you work with the footage in its native format. This is the historical method of using files in Avid. ![]() But that means the entire clip must be re-imported, even if only a few seconds were used in your sequence. Then, if a new resolution is needed, you need to Batch Import the necessary clips at the higher resolution. Files are converted to Avid MXF media at a defined resolution and managed by Avid. IMPORT refers to using the File > Import method to use media. So, I could use the hardware encoder with clips that have already been converted to sRGB, but that opens up a can of worms.Just so you understand, you're kind of mixing your terminology here. That said, if the color range, color primaries, transfer characteristics, matrix coefficients info isn't present, the clips will display incorrectly even using PC players (I suspect they just pass through the data straight.hence why they appear brighter and washed out). This may not have always been the case, but it definitely is now. As long as the resulting clips are output as Rec 709 Gamma 2.4, they SHOULD display correctly on YouTube because their player EXPECTS Standard Dynamic Range clips to be Rec 709 Gamma 2.4. Adobe color mangement appears to have this part configured and working correctly. I'm on a PC, so I expect the "working space" to display the clips as sRGB IEC61966-2.1. 709, sRGB, and social media delivery." As mentioned, my source clips are in Rec 709 (BT.709) Gamma 2.4. Disabling color management is useful when your screen matches the media on the timeline. This passage in particular is a red flag: "Enabling color management is useful when you want to display the color appearance of a timeline on a reference monitor. YouTube converts full color range clips to limited anyway.īased on Adobe's documention, I get the sense there's a bit of confusion regarding how their own products handle color management. It would be nice if there was an option for the h264 encoder to use "Full" vs "Limited" color range, but it's not a big deal as long as the players handle playback correctly. The only difference between the Software Encoder color values and the source files (from my Canon EOS R5) is that the camera encodes clips with "Full" color range. I don't know if this issue is due to how the hardware encoder is implemented on Adobe's end or if it is an issue with the hardware vendor's provided driver.but it IS an issue that has caused much grief over the past several months! I have a nVidia RTX2070 currently using Studio driver 472.84. In other words, I have a valid workaround.just slightly slower since I can't take advantage of the hardware encoder's speed. These mp4 files now play correctly in every player I have tried them in (VLC, Windows Media Player, Media Player Classic, Chrome) and on every website I have uploaded them to except SmugMug (I reached out to their support.will continue to upload ProRes clips to their website until there is a resolution). The difference was easily visible when I used After Effects Render Queue to export ProRes 422/422HQ/4444 mov files.these all render and play back as expected, so ProRes had been my workaround for uploading to various websites (including YouTube, Facebook, SmugMug).Īs a quick test, I switched to the H.264 Software Encoder and, sure enough, the expected data gets properly encoded in the mp4 files: ![]() After a little sleuthing, I determined the cause was due to the resulting file not including the following information that had been present in the source mov and mp4 files: When I use Adobe Media Encoder to export h264 mp4 files using the Hardware Encoder, I noticed a gamma shift on playback that was really driving me insane.
0 Comments
Leave a Reply. |