[mythtv-users] HDHR prob with new wallwarts

[Stephen Worthington]

On Sat, 7 Dec 2019 20:08:35 -0700, you wrote:

>On Sat, Dec 7, 2019 at 7:56 PM Silicondust <mythtv at silicondust.com> wrote:
>
>> >It would be really nice if the HDHRs tagged their packets with
>>
>>> >real-time priority in the IP packet DSCP header bits.  Then you could
>>> >set up the Ethernet port so that the packets with high priority took
>>> >precedence over the standard priority packets and the HDHR traffic
>>> >would be able to get through even when the port was being used to full
>>> >capacity by other traffic.  Not having an HDHR, I am unable to take a
>>> >look at its packets to see what the DSCP bits are set to.  There are
>>> >some posts out on the net that suggest that the DSCP bits are set, so
>>> >if they are, it would be worthwhile taking a look at what it takes to
>>> >enable QoS processing on your Ethernet port - and on your Ethernet
>>> >switch also if it supports that.  But before that, someone with an
>>> >HDHR needs to run Wireshark or tshark or tcpdump to capture some HDHR
>>> >recording packets and confirm the DSCP bits are being set properly.
>>>
>>> All HDHomeRun models tag UDP and RTP video stream packets with IP_TOS =
>> (5<<5). No target option required.
>>
>> After reviewing I see two possible quirks...
>> 1) Wireshark is reporting that as CS5 whereas I think it should be CS3 for
>> broadcast video.
>> 2) The HDHomeRun should probably tag HTTP video stream packets with CS3 as
>> well.
>>
>> Correction - all HDHomeRun models tag UDP, RTP, and HTTP video stream
>packets with CS5 today.
>The only question is if it should be CS3 rather than CS5.

Excellent!

As for CS3 versus CS5, there are two different ways an HDHR gets used.
One is where it is being recorded, and the other is where it is being
watched directly by a human.  For a recording, it would actually be
better to use a TCP connection with error correction and
retransmission, so you could under most circumstances ensure that
there were zero lost or damaged packets.  It does not matter to a
recording device if the packets arrive a little late and with variable
timing.  So if a TCP connection is used, in theory it would not be
necessary to use a DSCP priority tag at all.  Where a human is
watching though, the error correction involved in a TCP connection is
usually unacceptable as it causes "buffering" moments where the
playback stops.  So for a human, a high priority for the traffic is
necessary to allow the packets to not be dropped and to travel with
low jitter.  So that might well justify using CS5 instead of the CS3
recommended by RFC4594.  For recording using UDP packets, CS3 should
be all that is necessary.

So if I had to pick between CS3 and CS5 on all the packets, I would go
with CS5 until there was some way for the HDHR to know whether a human
was watching or it was being used for recording purposes.