> > > > Speed (from prores 422 HQ file -> Prores 444) > > > > ./ffmpeg -i prores422hqfile.mov -pix_fmt yuv444p10 -c:v prores -an > > -profile:v 4 res_aw.mov -y > > ==> 25 fps > > > > ./ffmpeg -i prores422hqfile.mov -pix_fmt yuv444p10 -c:v prores_ks -an > > -profile:v 4 res_ks.mov -y > > ==> 10 fps > > This is unfair comparison. >
What command line seems fair to you ? Even if, i set the same min/max quant (1, 6) and reducing the target bitrate (to have similar output size), the speed difference is very important. The resulting file is very close in quality (most of the picture is the same), on few part there is a very little difference in favour of one or another encoder depending of the content. > > > > 001 : Add support for Prores 444 (without alpha) > > 002 : change the frame flag in header part, to be the same than the > > official encoder in 422 mode > > (and update fate test) > > Whatever you are doing regarding improving prores_aw is bad idea. > > > I disagree (of course !). And i suppose you say that, because you have in mind to remove this encoder. After taking a look on both encoder, prores_aw have a faster quantif search, than prores_ks for me. Ks encoder sometime reduce too much the quality on some slice, where aw, is much simpler, and make less quality variation between slice. IMHO : Considering, the main use of prores codec (intermediate format in post-production) A simple/fast encoder (Prores Aw) is more appropriate in most of the case (reason why i mainly use this one, when i can). The main disadvantage (for now), for aw encoder, is lack of some user option (to adapt speed/size/bitrate constraint (in other word, min_quant, max_quant, target_mb_bitrate), and the support of other kind of prores (444 with alpha, and interlace content) But probably not so much work to do to add it (considering, the work already done in ks encoder). Martin _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
