Surprisingly high outgoing bandwidth from Mezzmo

Printable View

06-26-2016, 03:45 PM
Coises

Surprisingly high outgoing bandwidth from Mezzmo

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.
06-26-2016, 04:11 PM
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?
06-26-2016, 04:29 PM
Coises

Quote:

Originally Posted by 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 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.)
06-26-2016, 06:40 PM
Paul

OK - do let us know what you find out. We'll certainly look into it if you can establish it is actually happening.
06-27-2016, 05:32 AM
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:

Code:

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.
06-28-2016, 08:43 AM
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.
06-28-2016, 09:09 AM
Coises

Quote:

Originally Posted by 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.

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?

Quote:

Originally Posted by Paul

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!