On Tue, 26 Nov 2019, 00:40 Marton Balint, <c...@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 >
Thanks. 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 > _______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
