[FFmpeg-user] Using -re input option with UDP inputs

Dennis Mungai dmngaie at gmail.com
Mon Nov 25 23:58:22 EET 2019

On Tue, 26 Nov 2019, 00:40 Marton Balint, <cus at passwd.hu> wrote:

> On Mon, 25 Nov 2019, Dennis Mungai wrote:
> > Hello there,
> >
> > Are there any known caveats to using -re with UDP streams as input, such
> as
> > packet loss?
> >
> > I’ve seen the -re option being discouraged with the likes of RTP, does
> the
> > same apply to mpegts UDP streams?
> Yes. -re is widely misundetstood for some reason, despite that it is
> documented reasonably well:
> -re (input)
> Read input at native frame rate. Mainly used to simulate a grab device, or
> live input stream (e.g. when reading from a file). Should not be used with
> actual grab devices or live input streams (where it can cause packet
> loss). By default ffmpeg attempts to read the input(s) as fast as
> possible. This option will slow down the reading of the input(s) to the
> native frame rate of the input(s). It is useful for real-time output (e.g.
> live streaming).
> So you only need -re if you want to limit reading your input to realtime
> speed in order to generate your output at realtime speed. If your input is
> already realtime, then you don't need it. If your output is inherently
> realtime (e.g. decklink), you don't need it either.
> Regards,
> Marton


I noticed that every time I used -re with UDP inputs, I'd run into decode
errors (appears like smearing on the final output) and netstat would report
packet loss


More information about the ffmpeg-user mailing list