![]() so maybe avoiding the extra trancode at the input stage is a better bet, as you suggest. I suspect that the final delivery / rendering will involve some encoding anyway to combine effects, text, color corrections etc. before adding to Resolve timeline) or the output (i.e. So maybe the question is whether there is more transcoding loss at the input (i.e. My tests show that creating optimized media with DNxHR SQ (8-bit) only takes about one third of the time of the DNxHR HQX (10-bit) encodes, and the quality seems to be absolutely fine for editing I can always improve the timeline responsiveness by using Optimized Media, with the benefit that this can be of lower quality and resolution because the optimized media won't be (usually) used for the final render. I'm not quite sure what "regales quality" means - I assume you meant "reduces quality"? If your machine can handle original h264 then there is really no need for this step. This step gives you nothing regales quality (it can only marginally decrease it), but you can gain timeline responsiveness. Whether this is perceptible is probably subjective to a certain degree.Ĭamera source (10-bit 4:2:2 UHD, AVC/H.264) -> ffmpeg transcode to DNxHR HQX (10bit) ->. transcoding camera source, or transcoding to a different delivery codec) will degrade the quality to some degree. I realise that transcoding in either the input or output stages (i.e. in ffmpeg -profile:v dnxhr_hqx -pix_fmt yuv422p10le ), would result in a faster render with better quality. I'm afraid I don't fully understand how the rendering process works as far as transcoding is concerned, but my question was whether having the timeline clips previously transcoded to DNxHR HQX and exporting with exactly the same codec settings (e.g. ![]() So far, I have not experimented with color grading, but will be entering into this world once I have learned the core editing functions of Resolve. I record in 10-bit with the CineLike D profile on the GH5. The GH5 can record in log profile, but this is an optional (US$100) add-on that I do not yet have. There are some cameras that record to HLG and if you are delivering HLG and have made zero adjustments to the color or luma, then you may be able to transcode directly. When rendering video it's usually to 8 bits for SDR and 10 bits for HDR but NOT log profile. When cameras record in 10 bits, it's usually to a log profile. ![]() But then the degradation may be imperceptible. Michael_Andreas wrote:General rule: transcoding never adds quality, can only degrade. However, I am curious to know whether there any other downsides to working directly with the H.264 camera files on the timeline apart from the worse playback performance.įor example, if I am exporting to a DNxHR master, is there any quality difference between rendering from an H.264 timeline (which presumably involves transcoding during the final render), compared to one which is already using DNxHR? Would the render be faster in the latter case because no transcoding is required?Ĭamera source (10-bit 4:2:2 UHD, AVC/H.264) -> Resolve timeline -> DNxHR master -> H.264 distribution encode (YouTube etc.)Ĭamera source (10-bit 4:2:2 UHD, AVC/H.264) -> ffmpeg transcode to DNxHR HQX (10bit) -> Resolve timeline -> DNxHR master -> H.264 distribution encode (YouTube etc.) I'm considering buying the Studio version to avoid having to do the initial transcoding which is time consuming and generates huge files (c. ![]() This is mostly because I'm still using the free version (sorry!), and partly because it seems to play more smoothly on the timeline on my somewhat old workstation. I am editing 10-bit UHD footage from a Panasonic GH5 and have been transcoding this to DNxHR HQX prior to adding to my Resolve media pool. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |