Tvheadend

TCP datagram has 64 bytes, while UDP has 52 bytes, so it's 12 bytes on single empty packet.

Rafal Kupiec wrote:

TCP datagram has 64 bytes, while UDP has 52 bytes, so it's 12 bytes on single empty packet.

Yeah, good point, 'cause we sit here all day watching TV with empty packets

Seriously, this is even in the FAQ: https://tvheadend.org/projects/tvheadend/wiki/Faq

Why does HTSP use TCP? I thought it was bad to use TCP for realtime sensitive traffic?

HTSP – (Home Tv Streaming Protocol), the protocol used for streaming TV, sending meta information updates and RPC between Tvheadend and a HTSP client uses a transmission scheduler with multiple queues on the Tvheadend side. This means that Tvheadend can measure the available bandwidth between itself and the media player and when congestion happens it’s even capable of dropping less important data (such as B-frames). HTSP has been tested over WAN links and DSL connections with no video or audio artefacts.

And? I don't understand your irony...
It is not about HTSP, but about TCP and UDP. The first one proves all data will be sent (earlier or later) what causes re-transmissions and loss of available bandwidth, while UDP not.
I believe you don't need lost packets while watching live TV.

What is more, TCP requires acknowledgments, so if there is 50ms latency between client and server, it takes for a packet to be sent to a receiver and receiver to send an acknowledgement would be 100ms. Maximum throughput possible as compared to UDP based transmission is already halved.

Anything that streams gains the most benefits from UDP. The packet loss causing a one minute delay to TCP would not cause a one minute delay to UDP.

So to sum up, I believe cahnnel list, EPG and other should be still send via TCP, while A/V streaming should give an option to chose, whether it should be transmitted over TCP or UDP. What is more I believe, TVH should listen on 9982 TCP and UDP and the client should choose which protocol to use.

Rafal Kupiec wrote:

What is more, TCP requires acknowledgments, so if there is 50ms latency between client and server, it takes for a packet to be sent to a receiver and receiver to send an acknowledgement would be 100ms. Maximum throughput possible as compared to UDP based transmission is already halved.

That's simply not how TCP works. First, just because the client has to acknowledge a packet, does not mean, this doubles the latency (he's already received the data). Second, the client does not have to acknowledge every packet but only after a chunk (as defined in the window-size in tcp, 16k or something like that).

Anything that streams gains the most benefits from UDP.

anything realtime, but strictly speaking, htsp isn't realtime.

Name one protocol execpt RTP (voice, multicast-iptv) used for streaming that uses udp. rtmp, hls (which is notting but a html playlist with different streams where the clients selects the most convienient one from), the realplayer (yeah, that still exists), all use tcp, even dns switches to tcp if your packet is larger than 1024 bytes.

The packet loss causing a one minute delay to TCP would not cause a one minute delay to UDP.

Packet loss doesn't cause any delay, the TCP retransmits may, but as stated in the FAQ, HTSP adapts to that. What would you gain from changing a working protocol?

You would gain the purely theoretical advantage of slightly faster setup in a LAN, but in real live, you need the tcp-connection anyways for all the other stuff, and in the moment you want to start a channel, the connection is already there. But, assuming that the channel isn't allready subscribed, tvheadend first has to do that (subscribe to a multicast-stream, tune to a channel, start receiving etc), and this ignores all the buffers that are in play, from receive-buffer on the DVB-Device, Clientside, and probably even the timeshifting-buffer. That all completely negates the slightly faster "setup" on the first packet. On the other hand, you had to implement some sort of packet-loss-concealment on application level that's currently not needed, because its tcp.

You see, it's a lot more complex that changing the socket-type to tcp/udp :). And, you don't really gain anything in a real-live-scenario. I guess noone will stop you, if you want to implement udp (and the needed PLC-Layer in the server and clients), but i would bet my left testicle, that noone will do it for you :). It would be a fix for a non-existing-problem, and even if it would not cause problems (as long as udp stays optional), but it would add a lot of complexity to an allready not so trivial pice of software. adding true iptv-multicast-sender-capability would be cool, but adapting HTSP to udp, nah, i don't see that happening...

Disclamer: I'm not one of the core-programmers, nor do is speak on their behalf. This is my opinion, and mine allone

regards,

/hp