# Mean Opinion Score using the Yamamoto Formula

 0 Hello, I would like to calculate the mean opinion score using the Yamamoto Formula : ``````P_Mos = 4.0 - 0.7 ln (packet_loss ratio) - 0.1 ln (duration of the missing segment in ms) `````` I can easily calculate packet loss ratio from packet capture. is there any way to get the duration of the missing segment from Wireshark/Tshark? asked 26 Aug '16, 11:57 Wirecod 6●1●1●2 accept rate: 0%

 0 The paper you refer to describes missing segment duration the following way: the size is the packet size (actually the duration of the missing segment) in milliseconds (from 3 to 96 ms). From such wording we can deduce that the case of loss of several adjacent RTP packets is not taken into account. So the task is to convert the packet size in bytes into the packet size in time domain (i.e. in milliseconds). There are several approaches to that: to count the packet duration as `total time / number of packets`, but as there is packet loss, you may feel the result won't be precise enough (but if there is 10 % packet loss, causing the calculated size of the "missing segment" to be 10 % longer, I'm afraid the `-0.7 ln (packet loss ratio)` element of the formula becomes so dominant that the precision of the missing segment size has little impact on the total. This method is definitely unusable if any "silence suppression" (actually, bandwidth saving by transmission suppression during silence periods) mechanism is active, or intentional packet duplication is used, etc. to look at the size in bytes of the payload of a single RTP packet of the basic codec (i.e. no comfort noise or telephone-event packets), and use a table as below to convert this value into milliseconds: `codec sample rate [Hz] bytes of payload per millisecond` `PCMA 8000 8` `G729 8000 1` The sample rate is normally stated in the SDP, but for some codecs there is a default one. You have to look to the SDP anyway as the translation of payload type number (as found in the RTP packet) to codec name is there; theoretically, even the well-known values like 0, 8, 18 may be overridden. to take the difference of RTP timestamps (not of capture frame timestamps!) of two adjacent packets (i.e. those whose RTP sequential numbers differ by 1), and divide the difference by the sample rate in Hz. This way, you don't need to know what the actual codec is unless the sample rate is missing in the SDP and you need to find the default one. But again, the sample rate in the SDP may theoretically differ per codec so you must look for the one matching the payload type number in the RTP packet. For variable bitrate codecs (like e.g. Opus), none of these methods is reliable, yet there the whole formula would give unreliable results - with these codecs, the impact of loss of a particular packet on MOS differs depending on the informational value of that packet. answered 27 Aug '16, 00:41 sindy 6.0k●4●8●51 accept rate: 24%
 toggle preview community wiki:

By Email:

Markdown Basics

• *italic* or _italic_
• **bold** or __bold__
• image?![alt text](/path/img.jpg "title")
• numbered list: 1. Foo 2. Bar
• to add a line break simply add two spaces to where you would like the new line to be.
• basic HTML tags are also supported

Question tags:

×45
×2

question asked: 26 Aug '16, 11:57

question was seen: 1,568 times

last updated: 27 Aug '16, 00:47

### Related questions

p​o​w​e​r​e​d by O​S​Q​A