On Tue, Mar 17, 2015 at 07:44:54AM -0500, Jeremy Luce wrote: > It appears that c/C doesn't pause the input threads, which results in > higher CPU usage than the 'p' pause method. Also, since the input > threads continue to read data, the input buffer will continue to grow, > which may lead to undesirable results. I'm not sure if this is by > design or not, so I'm hesitant to attempt to "fix" it. These are the > main reasons why my method was implemented differently than c/C. > > If I were to add some visual feedback for 'p', is there anything I > could tweak that would make you more comfortable with this approach? > If not, would pausing the input threads on c/C be a viable option?
i think pausing the input threads with c/C is what should be done thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Many things microsoft did are stupid, but not doing something just because microsoft did it is even more stupid. If everything ms did were stupid they would be bankrupt already.
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
