![]() ![]() If you have to do a lot of encoding, it'd be worth searching around to see if there's any way to get your hands on a publicly available implementation of this. ![]() I'm pretty sure I would have noticed that in x264 -fullhelp output at some point. Neither the vanilla x264 cli frontend, nor the ffmpeg libx264 wrapper, have options to activate a feature like this. I'm not sure if that was just for google's internal use, and it never got merged, or what. So motion-search, frame-type decision, and a bunch of other analysis only has to be done once. I think I remember reading about someone having added support to x264 for making multiple encodes at different bitrates at the same time. Then do whatever you normally do, but with deinterlaced.mkv as your source. Simpler codecs like ffvhuff might have a place if you need to frame-step backwards without taking seconds per frame, or you could just lower keyint in x264. I think it's your best bet for scratch files (pretty good CPU usage, ASM-optimized decoders, and one of the best as far as compression ratio). ![]() Lossless x264 is about as fast to decode as ffvhuff, if not faster, but half the file size. If you have a ton of scratch space to work with, you could use an uncompressed output file. ![]() (never use ultrafast except with lossless, it's WAY worse than superfast -x264-params cabac=0, and not much faster.) CABAC takes most of the CPU time at lossless bitrates, but it does save 15% bitrate vs. If stib's suggestion of making multiple outputs in parallel with the same ffmpeg commandline doesn't quite do the trick, then use a temp file to hold a lossless copy of the output of any slow filtering: ffmpeg -i src.mkv -vf yadif=3:1,mcdeint=2:1 -c:a copy -c:v libx264 -preset ultrafast -qp 0 deinterlaced.mkv ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |