Bug #5835
Sending multiple RTSP chunk at once leads to garbled output
0%
Description
In an attempt to reduce the number of syscalls minisatip performs, I tried to buffer multiple RTSP Chunks (RTSP header 0x24 00 len + RTP header (12 bytes) + 42 * 188 TS packets) and issue just one syscall in minisatip.
Reference commit: https://github.com/catalinii/minisatip/commit/71b93ccea20c8bdf2aa3eaca41da0675c303fb2d
The interesting code is in: process_packets_for_stream.
Basically the only change from the client side is that instead of issuing a writev syscall for 1 RTSP chunk (7912 bytes) now it is possible to issue 1 syscall for the entire for around 72k.
While I thought this will not impact in any way TVH, I see there are some issues and the viewing is completely broken if I call writev for even 2 RTSP chunks. Tried the same test with minisatip as satip client or ffmpeg and both work with no issues.
How to repro with an HD channel:
./minisatip -2 88 -f -l http (does not work)
./minisatip -2 80 -f -l http (works)
The difference is that the second call will call writev after each 42 TS packets, while second will call it after just 1 (same behaviour as before).
The plan is to remove the option completely and call writev only if MAX_IOV is reached (1024)
History
Updated by Flole Systems almost 5 years ago
If you are going above the MTU you are violating the RFC, that could cause problems. However, tvheadend assumes that the MTU is 1500, I tried to add support for jumbo frames a while ago but never finished that work.
Updated by catalin toda almost 5 years ago
Sorry for not specifying. This is RTSP over TCP where you could fit more than 7 TS packets in an RTSP/RTP header. Tvh has that limit to 20k according to httpc.c
Updated by Jaroslav Kysela almost 5 years ago
--trace satip : https://tvheadend.org/projects/tvheadend/wiki/Traces
Updated by catalin toda almost 5 years ago
Satip trace revealsed that there was a rtp sequence issue. After fixing it everything is good.
Thanks for the help. Please feel free to close.