0

I am using ffmpeg and mpv, to stream audio/video between two hosts. One of the hosts is sending stream with ffmpeg:

ffmpeg -f pulse            \
       -thread_queue_size 0 \
       -i audioInput         \
       -f video4linux2        \
       -thread_queue_size 0    \
       -standard PAL            \
       -i videoInput             \
       -vcodec mpeg4              \
       -r 10                       \
       -s 176x144                   \
       -maxrate 256K                 \
       -acodec pcm_s16le              \
       -ar 8000                        \
       -b:a 32k                         \
       -af aresample=async=1000          \
       -f rtsp                            \
       -rtsp_transport tcp                 \
    url

and second host is receiving with mpv:

mpv url --rtsp-transport=tcp             \
        --profile=low-latency             \
        --demuxer-lavf-o=rtsp_flags=listen \
        --no-cache                          \
        --autosync=30                        \
        --no-demuxer-thread                   \
        --demuxer-lavf-analyzeduration=0       \
        --demuxer-lavf-probesize=32

I have tried a lot of options and combinations to reduce latency as much as possible. Above commands works nice, the latency on startup is < 1s. Unfortunately, sometimes, delay appears during streaming and it can even increase in time. My goal is to ensure, that delay will be more or less constant (close to 1s), and if some delay will appear, delayed frames will be dropped (even if it will affect audio or video quality).

How to force ffmpeg/mpv to drop frames, which are delayed e.g. more than 1s?

user3666197
  • 1
  • 6
  • 50
  • 92
user3469024
  • 21
  • 3
  • I am absolutely no expert in this, but I just notived you are using the tcp protocol. Afaik switching to udp might help a lot since the delays might well originate from the sender to wait for the acknowledge packets that are part of the tcp protocol and that inform the sender of a message that it has arrived. udp does not wait for those ack’s. – olidem Sep 02 '20 at 21:47
  • @olidem thank you, you are right, that was one of the options I have already tested. Unfortunately, with udp, packet loss is too high and the quality of video and sound is not acceptable. – user3469024 Sep 03 '20 at 05:46

0 Answers0