Closed PanKaker closed 1 month ago
It appears that we must wait for the last frame to complete its transmission processing before we can close all resources. Thank you; let's work on a solution for this issue.
By the way, you mentioned that 3 frames were dropped on the RX side. Could you specify which frames, other than the last one, were affected also?
As a proposition, maybe it's possible to implement in API of IMTL/DPDK a func that waits for all packets to be bursted/flushed and then we can close/free the resources. It will be really helpful.
About 3 frames: After receiving a video in RX side, we saved it to the file and broke by frames with ffmpeg, it appeared that only last 3 frames (123,124,125) were missing. I will try to run this again to confirm it and will back to you.
UPD: Yes, I can confirm losing the last 3 frames from the sequence.
Can you rebase the IMTL code to latest? https://github.com/OpenVisualCloud/Media-Transport-Library/pull/871 should fix this problem.
Hi! Thank you for the fast fix! We will try to test it and I will reach out to you!
P.S. I think the problem also occurs in st22 proto/pipeline
Hi! We've tried to run st20 again with the last fix and we can confirm that all frames were delivered correctly.
st22p and st30p is fixed also. Close this. Open a new one if it has any other issue.
Context
Hi!
We would you like to use your library with ffmpeg plugin, but we noticed that there are a few frames drops in RX side.
We've tried to use different duration of videos: 5, 10, 30, 400 seconds and the amount of dropping frames was always around 3. We have analyzed the frames that we're missing and it was the last frames from the sequence of a video.
Please find logs from TX and RX side below.
Thoughts on the problem
The issues is likely connected with finishing the session from TX/RX side and no proper flushing/burst packets from the buffers at the end of the session.
Possible workaround
Please be aware that this is not the perfect solution and we would like to get your expertise/thoughts on that.
As a workaround:
tx_video_session_get
/tx_video_session_put
are called to get the number of session inflight packets and we are calling usleep untill all the inflight packets are sent.We added a new function
st_tx_wait_for_inbound
inmtl_st20p_write_close
to achieve this:Logs
FFmpeg st20 TX
Test-video is a 10 seconds video with 25 fps = 125 frames.
Command
ffmpeg -video_size 1920x1080 -f rawvideo -pix_fmt yuv422p10le -i test_video.yuv -filter:v fps=25 -p_port 0000:b1:00.1 -p_sip 192.168.96.3 -p_tx_ip 239.168.85.20 -udp_port 20000 -payload_type 112 -f mtl_st20p -
Output
FFmpeg st20 RX
Command
ffmpeg -p_port 0000:b1:00.0 -p_sip 192.168.96.2 -p_rx_ip 239.168.85.20 -udp_port 20000 -payload_type 112 -fps 25 -pix_fmt yuv422p10le -video_size 1920x1080 -f mtl_st20p -i "k" -f rawvideo /dev/null -y
Output