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? Jeremy > it seems any key unpauses transcoding > > also theres no vissual feedback that ffmpeg is paused or how the > user can unpause it > this is bad in case the user pressed p by mistake > > also the c and C keys already effectivly pause ffmpeg > p should not be implemented entirely differently than how they work. > If c/C have problems these problems should be fixed > _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
