This fixes some framedropping issues when the overlay is enabled
with the pipelines which rescale in mppvideodec. But we add them
everywhere to increase our performance margins and keep things
consistent
We also change the queue into mppvideodec to the standard length.
We only need one extra long queue per input into the muxer to
accommodate the audio / video delay settings, and we already had
one for video, after encoding
mppvideodec turns out to always decode to NV12, and them, if a
different format is requested, perform a separate conversion
using RGA. We don't gain anything from this conversion, so remove
the format option
When a 1920x1080 H264 configuration is selected, the OA6 actually
outputs 1920x1088 video, with the top 4 and bottom 4 rows black.
These pipelines crop out the extra blank lines
These pipeline files may be removed in the future if DJI fixes the
video format in a firmware update, or if we end up implementing
an automated workaround for this issue in BELABOX
This allows more slack in the timing differences between the video
and audio feeds. Should fix pipeline stalls on DJI RC2 RTMP streams
and maybe other devices too
Zero-coppying seems to cause elevated framedropping under high
loadscenarios. I suspect that the buffers weren't returned quickly
enough to the capture card's drivers
This reverts commit de9b4ab2fc.
Looks like we were sometimes hitting some pathological cases where the
backlog of retransmissions was causing additional packet loss
Retransmissions remain limited by the efficient retransmission
algorithm, but will no longer be limited by SRTO_MAXBW
This is an attempt to reduce glitching under lossy networks -
particularly when using modems or networks which throttle by
dropping packets instead of queuing them
SRT's timeout doesn't work correctly under high RTT. It may be
adding a multiple of the RTT to the timeout duration. In any case,
it can take minutes for it to fail a connection that was running
on a congested connection with RTT in the order of seconds
This could result in the encoder reconnecting to the network,
and showing an active stream, even though it had long since timed
out on the ingest server's side
This reverts commit 2003453d4e.
While it improved behaviour over throttled connections, this seemed
more likely to glitch by oversending excessive amounts of data in
the pathological SRT(la) case when moving from areas with good
reception to areas with significantly worse reception, when the SRT
stats are slow to update causing the bitrate to remain set too high
for a few seconds
rationalsa