On 12/16/2014 10:33 AM, Carl Eugen Hoyos wrote:
Peter Rabbitson <rabbit+list <at> rabbit.us> writes:
a playback of the stream via `ffplay -i stdin.h264`
seems to run faster.
You can now use the input option "-r 30" to remux
this stream with "correct" timestamps.
(I am not sure if they will really be correct but
playback works fine here.)
The output will never be perfect because you have
reception errors in your input stream. Consider
using mpegts which allows such errors, I suspect
all other file types are invalid whenever such
errors occur.
Which brings me back to the question about ffplay - how does it manage
to compensate for (apparently) perfect timing as long as I feed it STDIN
in special chunks at special times?
Basically - is there a way to take the h264 frames as they come down
from the camera, and force-set the PTS based on a wallclock or something?
Basically "the output will never be perfect" is not something I am
willing to settle for. I either want to find out what is causing it, or
how to work around in a perceptually-satisfactory manner (which the
scheduler | ffplay example implies *is* possible)
_______________________________________________
ffmpeg-user mailing list
[email protected]
http://ffmpeg.org/mailman/listinfo/ffmpeg-user
