Surprisingly high outgoing bandwidth from Mezzmo

[Coises]

I just happened to peek at our media server, running Mezzmo 5.0.5.0 under Windows 7 Pro x64, by remote desktop while my housemate was watching a movie on her PS3. I’m puzzled by something. I was looking at Windows Resource Monitor. Nothing was running but Mezzmo, my remote desktop connection and default Windows processes, and the only connection to Mezzmo was the PS3. I have transcoding turned off, and the file is stored on a disk drive within the server.

The file she was watching has a total bitrate of just under 10Mbps. (FFprobe says “bitrate: 9871 kb/s.”) The size of the file divided by its length is consistent with this. The disk activity shown by Resource Monitor was also consistent with that bitrate, ranging from 0-3 MB/sec and, by eye, averaging a little more than 1 MB/sec.

The Network Utilization, though, was showing 80-87 Mbps at all times, nearly all of it sending to the PS3 from MezzmoMediaServer.exe.

Does this make sense? Why is Mezzmo’s outgoing bandwidth over 8 times the file’s bitrate?

Our home network can handle this (it’s limited by our MoCA transceivers, which I think can handle around 200Mbps), and the PS3 doesn’t seem to be choking (yet), so I have no immediate problem... but this seems like it could indicate something wrong.

[Paul]

Seems very strange. When transcoding is turned off, Mezzmo is simply streaming the file to your PS3. The only clue from your description is the 8 times difference - so possibly bytes/sec vs. bits/sec?

[Coises]

Seems very strange. When transcoding is turned off, Mezzmo is simply streaming the file to your PS3. The only clue from your description is the 8 times difference - so possibly bytes/sec v.s bits/sec?

I’m sure it is not a bits/bytes error. I tripled-checked for that mistake. The Network Utilization is around 85Mbps—if that were bytes, it would be eight times more odd. The file data rate is definitely just under 10 megabits per second, not megabytes per second. (The file is 6.64 GB and 1:36:19.)

She has finished the movie now, so the numbers are no longer in front of me, and it would be unwise to disturb her now to retry it. I will try to determine if the strange numbers occur consistently, and if they are unique to the PS3. (It’s normally the only thing we use to watch video stored on Mezzmo, but I can try streaming to a web browser and to my HTC M8.)

[Paul]

OK - do let us know what you find out. We'll certainly look into it if you can establish it is actually happening.

[Coises]

I checked this out with a different file: a movie with a reported bitrate of 10063 kb/s (around 1,290,000 Bytes/sec). I streamed it to the Mezzmo app on my HTC M8 and to the PS3, from both Mezzmo 4.1.3.0 running under Windows XP 32-bit and Mezzmo 5.0.5.0 running under Windows 7 64-bit.

I've placed some screen shots of the monitoring results at http://bisonica.pairserver.com/mezzmo/mezperf/.

Here is the information for the file, from Mezzmo 5.0.5.0:


ffmpeg version N-78742-gf477849 Copyright (c) 2000-2016 the FFmpeg developers
built with gcc 4.9.2 (GCC)
configuration: --enable-memalign-hack --arch=x86_64 --target-os=mingw32 --cross-prefix=x86_64-w64-mingw32- --enable-static --disable-shared --enable-zlib --disable-postproc --prefix=/home/peter/ffmpeg/build/gpl64 --enable-libmp3lame --enable-libx264 --enable-gpl --extra-libs='-lx264 -lpthread -lstdc++' --enable-runtime-cpudetect --extra-cflags=-I/home/peter/cc32/include --extra-ldflags=-L/home/peter/cc64/lib --pkg-config=pkg-config --pkg-config-flags=--static --disable-w32threads --enable-libvpx --enable-libvorbis --enable-libtheora --enable-libx265 --enable-libmfx --enable-gnutls --extra-libs='-lz -lnettle -lhogweed -lgmp -lidn -lws2_32 -lcrypt32'
libavutil 55. 19.100 / 55. 19.100
libavcodec 57. 25.101 / 57. 25.101
libavformat 57. 26.100 / 57. 26.100
libavdevice 57. 0.101 / 57. 0.101
libavfilter 6. 36.100 / 6. 36.100
libswscale 4. 0.100 / 4. 0.100
libswresample 2. 0.101 / 2. 0.101
[mov,mp4,m4a,3gp,3g2,mj2 @ 0000000000560520] stream 0, timescale not set
[mjpeg @ 0000000000562740] Changing bps to 8
[mov,mp4,m4a,3gp,3g2,mj2 @ 0000000000560520] Stream #2: not enough frames to estimate rate; consider increasing probesize
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from '\\Peacock\Movies\babadook the (2014).mp4':
Metadata:
major_brand : isom
minor_version : 1
compatible_brands: isomavc1
creation_time : 2015-02-25 09:44:00
date : 2014-01-17
title : The Babadook
Duration: 01:33:46.08, start: 0.000000, bitrate: 10063 kb/s
Stream #0:0(und): Video: h264 (High) (avc1 / 0x31637661), yuv420p(tv, bt709), 1920x816, 9841 kb/s, 23.98 fps, 23.98 tbr, 24k tbn, 47.95 tbc (default)
Metadata:
creation_time : 2015-02-25 09:44:00
handler_name : baba3.264 - Imported with GPAC 0.5.0-rev4065
Stream #0:1(und): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, stereo, fltp, 212 kb/s (default)
Metadata:
creation_time : 2015-02-25 09:44:59
handler_name : GPAC ISO Audio Handler
Stream #0:2: Video: mjpeg, yuvj444p(pc, bt470bg/unknown/unknown), 4000x3000, 90k tbr, 90k tbn, 90k tbc
At least one output file must be specified

<MEZZMO>: Child process ended with code: 109, ExitCode=1


---> DB Level Info: 41, 100
---> Frame rate: 23.98
---> Aspect ratio:
---> Duration: 01:33:46

Here is what I find odd. In all cases, the rate at which the disk is being read is consistent with the bit rate of the file. With the Mezzmo app on the HTC M8, the data send rates are also consistent. With the PS3, 5-6 times as much data is being sent as is being read. This is true for both Mezzmo 4.1.3.0 and Mezzmo 5.0.5.0.

I realize there could be caching going on... but I can’t come up with a scenario that explains why the machine would be reading data from the file at approximately the real-time rate of the file, but sending data at five times that rate.

[Paul]

Thanks for the great analysis. My only thought is that the PS3 is requesting data using multiple sockets (i.e. making multiple requests). Mezzmo server simply delivers whatever is asked. And when transcoding is turned off, no changes to original file are made, so unless there are multiple requests, there can be no reason that I can think of for more data than the original file being sent. We'll try it here with our PS3 and see if we can replicate your situation.

BTW: the http://Peacock:53168/web/login?user=guest issue that you reported was also fixed in v5.0.5.0 release. Let us know if it works for you now.

[Coises]

Thanks for the great analysis. My only thought is that the PS3 is requesting data using multiple sockets (i.e. making multiple requests). Mezzmo server simply delivers whatever is asked. And when transcoding is turned off, no changes to original file are made, so unless there are multiple requests, there can be no reason that I can think of for more data than the original file being sent. We'll try it here with our PS3 and see if we can replicate your situation.

Thanks for looking into it. I’m no expert on reading those activity statistics, so it could be nothing—and it’s not causing a problem right now—but it sure seems odd. I can’t figure out how Mezzmo can be sending more data than it’s reading. If it had cached the file already, before I got down to look at the monitoring windows, sure... but then, why is it reading the file at all... and, suspiciously, at approximately the real time data rate? And why for the PS3 but not for the Mezzmo app on the HTC One M8?


BTW: the http://Peacock:53168/web/login?user=guest issue that you reported was also fixed in v5.0.5.0 release. Let us know if it works for you now.

Yes, it works as expected now. Thank you!