Fix RX side dropping frames at the beginning. #917
Conversation
|
Not understand why it need this change. What's the problem if some frames are missing at the initial stage? Please note the typical case in video production is using multicast address, no one will use unicast address. Even with this change, the similar drop for the first frame parsing is still there with multicast mode. |
Address an issue where the RX is sending ARP replies to the TX while still being completely uninitialized, which leads to the session dropping frames. The problem worsens as the TX outperforms the RX in terms of initialization speed. Resolve this by halting the FFmpeg plugin initialization and starting the scheduled tasklets because we don't want the CNI thread to respond to the ARP requests sent in the tv_attach function until the RX is ready to receive those packets.
DawidWesierski4
force-pushed
the
dropping_frames_st22_issue
branch
from
3e653a9
to
168f5ed
Compare
|
Although the scenario is unlikely, isn't less frame drop better? |
|
It doesn't make sense, it has more codes but not fix anything really. |
In my testing if the TX outperforms the TX the RX Informs that the first received packet does not start with the sequence number 0 With this change the RX side will start responding to ARP messages and will start the initialization of the TX session after the RX session is initialized Although this only occurs with unicast it makes it so that the RX side receives the first packets after this change I can provide the logs confirming this To replicate the issue the easiest way is to have debug log enabled and a very high performance / low latency scenario The issue is bigger the more TX outperforms the RX (it allows for faster initialization ) |
|
The fix works basically via moving the mtl_start that enables the ARP response further down the line of RX initialization in ffmpeg as for now the RX side is not catching up to the TX side here an example where the first recived packet has the p_counter 189 I did not experience this after this change The video received usually had a few frames cropped from the beginning |
DawidWesierski4
force-pushed
the
dropping_frames_st22_issue
branch
from
68d2428
to
e07120c
Compare
DawidWesierski4
force-pushed
the
dropping_frames_st22_issue
branch
from
e07120c
to
0619339
Compare
|
Please help to fix lint fail. Just run |
Add retries to the initial read packet in FFmpeg to prevent imminent failures. This will aid in the synchronization of unicast FFmpeg streams and allow for some leniency in the RX session establishment.
DawidWesierski4
force-pushed
the
dropping_frames_st22_issue
branch
from
0619339
to
bf57988
Compare
Address an issue where the RX is sending ARP replies to the TX while still being completely uninitialized, which leads to the session dropping frames. The problem worsens as the TX outperforms the RX in terms of initialization speed. Resolve this by halting the FFmpeg plugin initialization and starting the scheduled tasklets because we don't want the CNI thread to respond to the ARP requests sent in the tv_attach function until the RX is ready to receive those packets.
Address an issue where the RX is sending ARP replies to the TX while still being completely uninitialized, which leads to the session dropping frames. The problem worsens as the TX outperforms the RX in terms of initialization speed. Resolve this by halting the FFmpeg plugin initialization and starting the scheduled tasklets because we don't want the CNI thread to respond to the ARP requests sent in the tv_attach function until the RX is ready to receive those packets.
Address an issue where the RX is sending
ARP replies to the TX while still being completely uninitialized, which leads to the session dropping frames. The problem worsens as the TX outperforms
the RX in terms of initialization speed.
Resolve this by halting the FFmpeg plugin
initialization and starting the scheduled tasklets because we don't want the CNI thread to respond to the ARP requests sent in the tv_attach function
until the RX is ready to receive those packets.