<div dir="ltr">>It would be really nice if the HDHRs tagged their packets with<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
>real-time priority in the IP packet DSCP header bits.  Then you could<br>
>set up the Ethernet port so that the packets with high priority took<br>
>precedence over the standard priority packets and the HDHR traffic<br>
>would be able to get through even when the port was being used to full<br>
>capacity by other traffic.  Not having an HDHR, I am unable to take a<br>
>look at its packets to see what the DSCP bits are set to.  There are<br>
>some posts out on the net that suggest that the DSCP bits are set, so<br>
>if they are, it would be worthwhile taking a look at what it takes to<br>
>enable QoS processing on your Ethernet port - and on your Ethernet<br>
>switch also if it supports that.  But before that, someone with an<br>
>HDHR needs to run Wireshark or tshark or tcpdump to capture some HDHR<br>
>recording packets and confirm the DSCP bits are being set properly.<br><br></blockquote><div>Hi,</div><div><br></div><div>Nick here from SIlicondust...</div><div><br></div><div>All HDHomeRun models tag UDP and RTP video stream packets with IP_TOS = (5<<5). No target option required.<br></div><div><br></div><div>After reviewing I see two possible quirks...</div><div>1) Wireshark is reporting that as CS5 whereas I think it should be CS3 for broadcast video.<br></div><div>2) The HDHomeRun should probably tag HTTP video stream packets with CS3 as well.</div><div><br></div><div>Nick<br></div></div>
</div>