> > Regardless of the actual proposed patch, I think the author's use of > wallclock time to describe the problem is very reasonable. I do a > large amount of work where I'm measuring "glass-to-glass" latency, > where I am interested in the total pipeline (encode/network/decode), > and I definitely went through the experience of trying to figure out > why ffmpeg was introducing nearly 500ms of extra latency during > decoding. It turned out that it was because my particular platform > had 8-cores and thus 16 decoding threads and thus 15x33ms of delay, > regardless of the stream complexity. >
You shouldn't be using frame threads for this kind of application. Kieran _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
