[MPlayer-users] hd video playback problems over wireless network

[belcampo]

h9wzuy45tm at snkmail.com wrote:
> I have problems with stuttering and video/audio desync when playing
> videos over wireless network (macbook that is 1m away from airport
> express), when I don't have the same problems on the wired network. By
> playing video, I mean that I have an mkv or avi file exported via CIFS
> from a NAS running samba.
> 
> I've done what I know of in terms of tuning the macbook (eg. setting
> net.inet.tcp.delayed_ack), but I'd be pleased to try any suggestions.
> 
> I've also done what I know of in terms of tuning mplayer (ie. setting
> -cache 16384)
Maybe an additional -cache-min 90 after the -cache statement will help
> 
> I've observed during playback that I'm reading at ~ 660KB/s, and I
> believe that the limited throughput is linked to the problem.
> 
> Yet, I'm pretty sure that the wireless network has more than
> sufficient capacity.
> ie. cat /Volumes/share/path/to/file.mkv > /dev/null yields in excess
> of 2 MB/s network throughput.
> 
> So, I tried to investigate what bottlenecks might exist in how mplayer
> reads the file, as opposed to how cat would read the file. Using sudo
> dtruss -n mplayer, I get a constant stream of something like the
> following:
> 
> 24741/0x628e3: read(0x3,
> "<d5)\272\246]\322,K\215\355\266\003^\377<}yo.\206\246\244\t\236\371'\303\0026\351i\303\027\270n#\345a\266\311\256\003f\302\207$\233\203\270qE\374\244\333\206#R\"\214\tp\307\273_,\230\\\322\204+\326\020\177\326\177\222\241Z\250\371.\364\257\200\264\266L\275\177\024T\250\354q8\372\361W\253\320\255k;\333\217#\270\312\240\265\032\375\267\251\004\214{\340\v7@\365\234M\236\035zz\016%^~\310\022\263\3044\304\342\t\265y5R\227qD\233\316\032vX\247\271.:\"\322\251\232\035v\311\340\242A\003\376\020\273\204\360\235\324\274+\373C;\313\374\001\0044\256\262\260\204/\212:i\305\340\254\217g\336\343<\210\017\240v\210:\260\323\004w\252\372\370\26602\331Y\017)bO\032\221\273{m\274\350v\215\221\321\221@\2152\366\0",
> 0x800) = 2048 0
> 24741/0x628e3: read(0x3,
> "\023\344\313!\3465#\003\301\315:3\374D4\235\247\230npf\t\304\261ef(\3044\fD\326\363\327($\\\262-\374-\216*e\332b8\n\025\244S4\313\243\342\026\246\266\363\306\306+\310\021\233\262\317\026\343\tD^r:\223\341u\257
> \035\371\245\0041\246\322%Z\3504n\344#\"uAT\352q\374\a;w#\212L\224\373\217,\326\201\242\2017\006\21688\024B9v\350\177&\346\345\205$2}3iA\213\025\335\361\373\0220W\214Y\001\306Z\220\272\261\227\001\030\366\215w\244\333\001\fsLQ&\357F\025\r\0347bP%\226a5\002\265\0",
> 0x800) = 2048 0
> 
> From the read(2) manpage at http://www.manpagez.com/man/2/read/, the
> 0x800 indicates that a buffer size of 2048 bytes was allocated for the
> read, and the return value of 2048 indicates how many bytes were
> successfully read. Note that this 2048byte read buffer is not linked
> to the 16384 KB cache that I had specified.
> 
> Could this be the cause of the problem? Looking at the dtruss output
> for the cat command, the buffer size is 0x20000, or 131072 bytes,
> which is significantly larger than 2048.
> 
> I did some other tests that suggest that this read buffer size really
> could be the problem.
> 
> dd if=/Volumes/share/path/to/file.mkv of=/dev/null bs=2048 yields
> consistent network speed of ~ 660KB/s, just like mplayer.
> 
> I hypothesize that the read syscall blocks, and so the maximum
> theoretical throughput would be bounded by buffersize/network latency.
> On my wireless network, I get pings to the NAS of approximately 2.5ms.
> ie, 0.0025ms
> 
> Playing with other values shows that the read buffer size has a
> visible relationship to network speed, up to a certain point.
> bs (B) approxthroughput (KB/s) theoretical bs/latency (KB/s)
> 512 150 204
> 1024 400 410
> 2048 650 819
> 
> Is it possible to increase the read buffer to something that would
> work in high bandwidth, high latency environments? If possible, I'd
> suggest going with the value used by cat (128KB or 131072 bytes), so
> that high throughput is still achievable in a long distance network
> with 100ms latency. Alternatively, something which pre-fetches from
> file streams to fill the cache buffer might do the trick too.
> 
> I think the 2048b buffer size is defined in main/stream/stream.h
> 57: #define STREAM_BUFFER_SIZE 2048
> 
> and it's used in main/stream/stream_file.c
> 54: static int fill_buffer(stream_t *s, char* buffer, int max_len){
> int r = read(s->fd,buffer,max_len);
>   return (r <= 0) ? -1 : r;
> }
> 79: int len=s->fill_buffer(s,s->buffer,STREAM_BUFFER_SIZE);
> _______________________________________________
> MPlayer-users mailing list
> MPlayer-users at mplayerhq.hu
> https://lists.mplayerhq.hu/mailman/listinfo/mplayer-users