Please improve the H264 encoding/transcoding quality as it is not possible to deliver anything because of low quality. Even on the highest quality or over 120000 bits the footage has a lot of banding in the sky, very visible compression artifacts and a pulsing shake all over the image. Really terrible. With Handbrake or Adobe the H264 output is perfect. I am converting from DNxHR HQ.
Was this on Windows or Mac?
windows 10 64 bits. Original files Mavic 2 Pro Log 10 bits files rendered as DNxHR HQ. Those HQ when transcoded to H264 Best Quality or 120000 bps give a very bad quality. If chosen best quality much worse than 120k Those final files are totally pixelated and unusable. The 120k are of much lower quality that what I achieve with Handbrake or Adobe. The compression artifacts are many and there is a weird image pulsing-flicker
If I transcode to Prores 422 it is fine so I guess the H264 transcoding with the PC latest version is not working right. I had to delete 17 files sent to 4 stock agencies because I didn't check 100% when I converted and when I did and saw the results I had to delete it from all the agencies and send again transcoded H264 with Handbrake. the settings were H264 Encoder Preset 2 lines before Slower Encoder Profile High Encoder Tune None Average bitrate 120000 2 pass encoding enabled.
The time of Kyno is ultra fast like 20 s on my computer for a 40s file The Handbrake is like 10 minutes with the 2 pass and the slower enabled for quality. If I go all the way to faster and 1 pass I get the same fast speed as Kyno. So it seems that the only option that works on Kyno is a fast transcoding for proxies but not delivery .
Thanks for the additional info. The H264 encoder used on Windows is of lesser quality than the one on Mac (and the H264 encoder used in Handbrake) and we will do something about it in the future. I agree with you that in the current state H.264 on Windows is not suitable for playout masters but rather for proxies but we are working on changing that in one of the next releases. Unfortunately 1.8 is almost finished and it cannot go in there. I hope Kyno is still useful for other parts of your workflow.
All the best,
Thank you Thomas. Knowing that, I will keep Handbrake at hand until you might improve this option in the future. Yeah many other parts are very useful. Transcoding to ProRes seems to work great although I have not compared it with the Adobe Media Encoder but as Davinci has no ProRes rendering for PC users Kyno is a great option to have. Fast browsing is also great. Much better that the database approach like Lightroom which I have never liked. Time is money and slow database browser/cataloguers are time expensive so I am glad that Kyno does not follows this route.
I think that Handbrake is based on open source FFmpeg so it should not be difficult to achieve the same quality for Kyno in the transcoding terrain in the future. Kind regards
Just out of curiosity, why can't you upload as DNxHD or DNxHR? I have to admit I'm not a codec expert, but my understanding is that it is equivalent to ProRes in size/quality. And it has the advantage of being exportable/usable on both Mac and PC.
Though the files are a bit larger (~20-25%), you could also export to Cineform.
If there is a good reason that the DNx codecs won't work as well, I'd love to know about it so I can file it away for future use (I'm on a PC myself).
Most stock sites that I distribute my footage don't accept DNx codecs, all take H264 or Prores. I prefer H264 as the final size is much lower and storage space with backup adds quickly. When I have something that I want quality I export in Davinci in Uncompressed form 10 bits and convert with Adobe Media encoder to Prores 422 as it has many option to encode the video and audio. Kyno also has a good Prores conversion.
Ah, ok, that makes sense then.
Though I don't really understand why they wouldn't want DNx?? rather than ProRes because, at least in my testing, DNx?? appears to be more efficient and equally editable. Then again, that is only my testing using a third party transcoder, so that may have been a variable that affected my testing.
Thanks for the quick response!