Using -re input option with UDP inputs

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Using -re input option with UDP inputs

Brainiarc7
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?

Thanks,

Dennis
_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: Using -re input option with UDP inputs

Marton Balint


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
_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: Using -re input option with UDP inputs

Brainiarc7
On Tue, 26 Nov 2019, 00:40 Marton Balint, <[hidden email]> 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
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".