RTP vs. HTTP

Kodi Community Development

Moderator: TVJunkie198

Post Reply
jamessahm
Posts: 4
Joined: Sun Dec 16, 2018 11:43 am

RTP vs. HTTP

Post by jamessahm » Mon Dec 17, 2018 8:22 am

Hello all,

Is there a reason the HD Homerun Viewer does not use "rtp" for it's transfer? My MythTV box talks to the HDHR via RTP...I was just wondering if one was more efficient? Syslog reveals:

20181217-04:46:35 CableCARD: tuner0 510 WCAU-HD (auto:459MHz-1140) access = subscribed
20181217-04:46:35 Tuner: tuner0 http stream ended (remote closed)

20181216-08:00:00 CableCARD: tuner2 1542 CNN Headline Ne (auto:483MHz-119) access = subscribed
20181216-08:00:00 Tuner: tuner2 rtp stream ended (stop request)

rpcameron
Posts: 845
Joined: Fri Mar 25, 2016 9:55 am

Re: RTP vs. HTTP

Post by rpcameron » Mon Dec 17, 2018 10:45 am

SD seems to be moving towards HTTP for their API. Why?, I have no clue. HTTP is served over TCP, which is a little slower, especially for streaming video, because it needs to verify receipt of every packet sent.

On the other hand, RTP is served over UDP, which does not verify packets and is therefore (a little bit) faster. Streaming video formats were generally created for UDP connections, and therefore can usually cope well with dropped packets.

If you don't want HTTP streaming, then you need to use something other than SD's software.

gtb
Expert
Posts: 3985
Joined: Thu Oct 06, 2011 1:00 pm
Location: Sunnyvale, CA USA

Re: RTP vs. HTTP

Post by gtb » Mon Dec 17, 2018 12:02 pm

jamessahm wrote:
Mon Dec 17, 2018 8:22 am
My MythTV box talks to the HDHR via RTP.
MythTV can (using the contributed external recorder) use HTTP(*). One can argue efficiency(**), but the reality is that in almost all consumer environments(***) is that packets will get dropped using UDP, which will result in artifacts (how many packets will get dropped, and how badly the artifacts are(****), will of course vary), and since it is UDP, you have no chance to get that packet back.

And at least until v30 ships [or you are running master], where some locking code had been added, MythTV does not share its tuners well (i.e. at all) with other compliant applications, so you can easily lose recordings, so running via HTTP (using the contributed external recorder) is often the only viable solution in a mixed residence.

(*) And if one is interested in using the Premium TV service with MythTV, one has to use the HTTP protocols. Obviously not everyone cares about that service.

(**) The overheads of TCP vs UDP are real, but for mostly well behaved streams (few losses, or packet corruption) the differences are not all that great in any proper implementation. The advantages come about when you actually are getting losses or corruption, where one is likely willing to pay for those overheads.

(***) Those with more advanced (typically enterprise/data center) switches and the knowledge to properly configure them can implement various QoS settings such that one can substantially minimize losses within the network itself (tuning your OS is a different issue). It is trivial to show extremely high packet losses in a synthetic that can be mitigated to zero with careful setup. Few people have the equipment (and knowledge) to implement that.

(****) Some people can completely ignore those visual artifacts, while some other people they are driven crazy to see a recording with random screen color splotches, even if they disappear in a few seconds.

Post Reply