![]() Basically the intervals between the spikes represent intervals of time when the client is not communicating at all with the video server. In the case of the network with video jitter issue, I filtered on port 1935 and the relevant IP, which gave us this result n the IO graph: You can also have multiple filters to compare different traffics’ throughput. Notice also that you can apply normal wireshark display filters at the bottom, causing the graph to change and show throughput for only the traffic of interest. If you would like to “zoom in” or “stretch” the graph, change the “Pixels per tick” in the X Axis options to a higher number. To do this, simply change the “Unit” option for the “Y Axis” at the bottom right corner to “Bytes/Tick”. I almost always change this to show the number of bytes per second. This will produce a graph showing (by default) the number of packets per second. To open the IO graphs, go to the menu “Statistics > IO graphs” This graph is indispensable when dealing with suspected network bandwidth issues. With this information in hand, we can proceed to perform a packet capture (ideally on both the end client and the gateway).Īs a starting point, I usually get a general “feel” for the network traffic by using wireshark’s in-built I/O graphs (Input / Output graphs). Make sure to note which IPs and ports are generating the video traffic. ![]() ![]() In BBC’s case, the video stream is using RTMP (port 1935), however it is just as common to see video streams using port 80, 443 or other ports. To start tackling the above issue it is first important to observe the normal behaviour of the video stream. Issue : sporadically and randomly clients would see jitter (picture freezing for a small number of seconds) when viewing live video streams such as BBC news ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |