UPD: ffmpeg builds I shared were added just to show encoder is no a myth, but as FFmpeg (or at least some guys from the community) has something against I had to remove repo…s o all github links below invalid, sorry
In the previous post I forgot to mention the problem I mentioned couple times before – Quality. Its not always easy to detect by eye big difference, but I have some test files where any of ffmpeg prores encoders really fails.
I uploaded one to github if you want to check:
https://github.com/da8eat/ffmpeg_prores_encoder/blob/master/1.bmp
and you can see how badly ffmpeg encodes it if you want Proxy profile:
ffmpeg -i 1.bmp -c:v prores_ks -profile:v -pix_fmt yuv422p10le ks.mov
as you see both looks quite blury (aw looks better but as I said before there is nothing about rate control and aw guarantees nothing except correct bitstream)
Thats how looks same frame encoded with encoder I made:
ffmpeg -i 1.bmp -c:v prores_amcdx -profile:v -pix_fmt yuv422p10le amcdx.mov
I uploaded all 3 mov files so you can compare results by yourself:
https://github.com/da8eat/ffmpeg_prores_encoder/blob/master/aw.mov
https://github.com/da8eat/ffmpeg_prores_encoder/blob/master/ks.mov
https://github.com/da8eat/ffmpeg_prores_encoder/blob/master/amcdx.mov
I also do believe you have your own test footage which you want to try encoder with, so I built ffmpeg master branch and added one more Prores Encoder, so you can test and check results . Usage:
https://github.com/da8eat/ffmpeg_prores_encoder/blob/master/build/ffmpeg_win_MSVS2015.7z
https://github.com/da8eat/ffmpeg_prores_encoder/blob/master/build/ffmpeg_osx_clang.7z
ffmpeg.exe -i 1.bmp -c:v prores_amcdx -profile:v 5 -pix_fmt yuv444p12le xq.mov
profiles same as others ffmpeg Prores encoders: 0 – Proxy, 1 – LT, 2 – Standard, 3 – HQ, 4 – 4444, 5 – XQ
supported pixel formats: uyvy422, yuv422p10le, yuv422p12le, yuv444p12le
I do believe my encoder still have some bugs, so If you face any do not hesitate to message me
I’m just stunned. Lately I was looking for a way to get better quality out of prores_ks inside of ffmpeg but still lowering the file size (lets say that my source material is 1tb of 4k h264 10bit footage in long gop, for sure I cannot use the standard bitrates). I’ve downloaded your prebuild ffmpeg and tested it… the resaults are pretty crazy. Not only your prores does not suffer from the blocking artifacts that the others do, but in performance (writing and reading) is way better. My only concern is that with your prores_amcdx I don’t have te posibility to se the qscale:v parameter to save up on space while reducing a bit of quality, is it disabled compared the ks? Or just not working? I’m not at all a programmer but after years of using ffmpeg (both as an hobby and professionally) I started to understand the mechanism of it.
hi Sandro,
first of all force qscale is not normal behavior for Prores encoder, it was implemented in prores_ks just because default rate control fails from time to time.
never the less my implementation also has the parameter to force rate control its more strict though:
target_size:v
setting this parameter you literally limit each frame size by this value. it was implemented for a different purpose but should work for you
Kind Regards,
Alex
Please publish full source code as per the GPL. I have opened a ticket here:
https://trac.ffmpeg.org/ticket/8086
the build was just a proof of concept… if its that critical I would just remove binaries, not sure why its critical though