0

Basing on multicast receiver from: How do you UDP multicast in Python?

I adjusted it to my needs considering the fact I wanted to stream 10,5 MB test file video using VLC and analyse packets sent by it. Here is configuration of VLC: https://i.stack.imgur.com/l0wsd.jpg

The problem is that I see on wireshark 769 captured packets where python prints out that he received a little bit above 600. What may be cause? I believe my method of calculating packets may be wrong in python. Do you have any solutions? Here is python vs wireshark packets shown:

https://i.stack.imgur.com/8QIjA.jpg

import socket
import struct

MCAST_GRP = '239.200.200.1'
MCAST_PORT = 5252
IS_ALL_GROUPS = True

sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM, socket.IPPROTO_UDP)
sock.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
if IS_ALL_GROUPS:
    # on this port, receives ALL multicast groups
    sock.bind(('', MCAST_PORT))
else:
    # on this port, listen ONLY to MCAST_GRP
    sock.bind((MCAST_GRP, MCAST_PORT))

mreq = struct.pack("4sl", socket.inet_aton(MCAST_GRP), socket.INADDR_ANY)

sock.setsockopt(socket.IPPROTO_IP, socket.IP_ADD_MEMBERSHIP, mreq)
counter = 0
print("Entering while loop")
while True:
    datagram = sock.recv(1328)
    counter +=1
    print(counter)

I would like to calculate bitrate by knowing amount of captured packets sent by multicast streamer and dividing this number by time of observation. But the thing is I want to be sure if amount of captured packets by python is correct, but so big divergence between wireshark and python looks like it is not correct.

The interesting thing is that if I'm understanding it correctly, even 769 packets are not enough. 769 * 1328 = 1.021.232 bytes which is about 1MB where video is 10.5MB. Am I thinking correctly?

Yenjay
  • 55
  • 8
  • 1
    i think i see the issue `datagram = sock.recv(1328)` means receive **up to** 1328, if for some reason it got less, then you increment the counter in error(the inverse is also true, it could catch multiple smaller packats if they arrived fast enough). it would be better to count the actual amount of bytes you get into `datagram`, – Nullman Jul 30 '19 at 12:43
  • 1
    How can I do so? I tried implementing `amountOfBytes = b""` first and then after receiving 1328 bytes adding them into `amountOfBytes` but even after first adding, after converting bytes to int(If I understand it properly) `int.from_bytes(testBytes, byteorder='big')` the value is absurdly high, but I believe that it's because it converts *subsequent* bytes not the whole *datagram* into *how many bytes are in datagram* – Yenjay Jul 30 '19 at 12:52
  • 1
    instead of `counter +=1` try `counter +=len(datagram)` at the end you should have the number of total BYTES you received. also it might not total 10MB because there might be compression involved (i dont know how vlc streams, but compression is pretty common) – Nullman Jul 30 '19 at 12:54
  • 1
    Try to tick "Keep original video track" on video codec settings. This should bring you closer to the 10MB. It will still not match exactly (raw video data will match but the container format differs). About your difference in count: maybe python is not fast enough and the UDP-buffer spills over? – Peter Schneider Jul 30 '19 at 13:02
  • Peter: It helped and i receive about 8569 datagrams which is over 11.379.000 bytes that is higher value than file size, and i consider only raw data not bytes used to encapsulate data, so i think I will use compression and the main goal is still to make wireshark number of packets and python packets equal @Nullman I did what You said, and the effect is the same - counter prints at the end value equal to ~615 datagrams * 8 bytes which is ~820KB instead of ~760*8 that would be over 1MB – Yenjay Jul 30 '19 at 13:33
  • 1
    @PeterSchneider So is there any solution to UDP-buffer spilling over? – Yenjay Jul 30 '19 at 13:46
  • 1
    Would be my guess but doesn't mean that it is right. Wireshark is seeing it so sending site is fine. Try to set your recivie buff size to a few megabytes... – Peter Schneider Jul 30 '19 at 13:54
  • 1
    I did it, but python still doesn't capture about 15-20% of required packets :/ – Yenjay Jul 30 '19 at 14:02
  • 1
    as an alternative, you can sidestep the problem by having something faster read and cache your data like [this](https://stackoverflow.com/a/51449587/7540911) – Nullman Jul 31 '19 at 10:44
  • 1
    As far as I understand, it means that I would make script that saves logs from packets to `.pcap file` and then another one that will read this file and using scapy that will analyse it? It implies, that those results won't be **live**, am I right? – Yenjay Jul 31 '19 at 13:42
  • 1
    they will be as live as python can process them – Nullman Aug 01 '19 at 08:52

0 Answers0