[mythtv-users] HDHR prob with new wallwarts
mythtv at silicondust.com
Sun Dec 8 03:08:35 UTC 2019
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
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the mythtv-users