On Fri, Apr 17, 2020 at 2:38 PM Simon Brown <simon.k.br...@gmail.com> wrote:
> Thanks Devin, found the right place, but finding frames to skip seems to be > taking more CPU time. You probably need to understand where within libavformat/libavcodec the time is being spent. Such an exercise in profiling can be non-trivial of course. > Is there any way of building ffmpeg libraries to a) minimize any other stuff > that isn't being used, and b) raise priorities on threads that are decoding? > Is it faster to run with static libraries or dynamic? Anything! You can certainly recompile without stuff that isn't used as well as build static libraries, but neither of these things will have any material impact on performance. Usually excluding unneeded code just reduces code size but won't make anything run faster. Adjusting thread priority is likely to only help if you've got other stuff on the platform competing for CPU resources. > We've got a 2Mbps stream with just I and P frames, no B frames. It's just > Standard Definition, and it can just about keep up but not quite. So I need > to be able to shave off 1% here, 2% there, etc. One thing to watch out for - is the output of the decoder something that can be fed directly into your HDMI output hardware? Or are you using libavfilter to do anything like scaling, planer-to-packed conversion, or colorspace conversion. On an embedded target these sorts of operations can actually be more expensive than the actual H.264 decoding. Also bear in mind that sometimes such operations are inserted into the pipeline dynamically based on the specified input/output formats. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com _______________________________________________ Libav-user mailing list Libav-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/libav-user To unsubscribe, visit link above, or email libav-user-requ...@ffmpeg.org with subject "unsubscribe".