[MPlayer-users] Restarting mplayer after Network Trouble

Rasz citizenr at gmail.com
Tue Mar 22 15:32:06 CET 2016


On 3/21/16, Reimar Döffinger <Reimar.Doeffinger at gmx.de> wrote:
> Are you really using a current version?
> That is exactly what the MAX_RECONNECT_RETRIES thing was
> introduced for in 2012.

tried those:
MPlayer Redxii-SVN-r37448-4.9.3 (x86_64) (C) 2000-2015 MPlayer Team
MPlayer sherpya-r37802+g666e2ed-5.3.1 (C) 2000-2016 MPlayer Team

>
>> Seeking in the video abandons current connection abruptly _without
>> properly closing it_ and just starts another one.
>
> Huh? What made you conclude that? MPlayer calls closesocket on the
> old connection before opening the new one.

packet captures (tshark)

to reproduce get http://youtube-dl.org/
this gives you direct YT mp4 link: youtube-dl.exe -g
https://www.youtube.com/watch?v=7srmGug-a44 -f 22

mplayer "https://r6---sn-f5f7ln7l.googlevideo.com/videoplayback?mn=sn-f5f7ln7l&ip=31.178.207.150&mm=31&sparams=dur,id,initcwndbps,ip,ipbits,itag,lmt,mime,mm,mn,ms,mv,nh,pl,ratebypass,requiressl,source,upn,expire&mv=m&pl=16&mt=1458650654&requiressl=yes&ms=au&mime=video/mp4&dur=1185.866&id=o-AOiH9NxO6ngTh-HIdrRZtpyfe37tTWSWMPmlQtutChxJ&initcwndbps=2678750&expire=1458672459&sver=3&key=yt6&signature=013B6E4725C8FCB171453F248FC843A8E5903E18.A879FC3907909B8952CF2F9AEAB6EF5BDA6F56AF&source=youtube&ratebypass=yes&nh=IgpwcjAyLndhdzAyKgkxMjcuMC4wLjE&upn=v9nYiAvjU5c&itag=22&ipbits=0&fexp=9405972,9416126,9417580,9420452,9422596,9423661,9423662,9423923,9424134,9424580,9425790,9427036,9427902,9428010,9428668,9428983,9430817,9431012,9431237,9432032,9432387&lmt=1458612933224741&title=Getting%20ideas%20out%20as%20a%20small%20business%20owner%20means%20tossing%20the%20idea%20of%20perfection"

pause and watch network traffic, try unpausing after 300 seconds

  1.200969 173.194.150.124 -> 192.168.1.10 TCP 1458 [TCP segment of a
reassembled PDU]
  1.200970 173.194.150.124 -> 192.168.1.10 TCP 1458 [TCP segment of a
reassembled PDU]
  1.200970 173.194.150.124 -> 192.168.1.10 TCP 118 [TCP segment of a
reassembled PDU]
  1.200980 192.168.1.10 -> 173.194.150.124 TCP 54 [TCP ZeroWindow]
62372â+'443 [ACK] Seq=1 Ack=684386 Win=0 Len=0
  1.431178 173.194.150.124 -> 192.168.1.10 TCP 64 [TCP Keep-Alive]
443â+'62372 [ACK] Seq=684385 Ack=1 Win=253 Len=0
  1.431230 192.168.1.10 -> 173.194.150.124 TCP 54 [TCP ZeroWindow]
62372â+'443 [ACK] Seq=1 Ack=684386 Win=0 Len=0
  1.886015 173.194.150.124 -> 192.168.1.10 TCP 64 [TCP Keep-Alive]
443â+'62372 [ACK] Seq=684385 Ack=1 Win=253 Len=0
  1.886042 192.168.1.10 -> 173.194.150.124 TCP 54 [TCP ZeroWindow]
62372â+'443 [ACK] Seq=1 Ack=684386 Win=0 Len=0
  2.790032 173.194.150.124 -> 192.168.1.10 TCP 64 [TCP Keep-Alive]
443â+'62372 [ACK] Seq=684385 Ack=1 Win=253 Len=0
  2.790056 192.168.1.10 -> 173.194.150.124 TCP 54 [TCP ZeroWindow]
62372â+'443 [ACK] Seq=1 Ack=684386 Win=0 Len=0
  4.589286 173.194.150.124 -> 192.168.1.10 TCP 64 [TCP Keep-Alive]
443â+'62372 [ACK] Seq=684385 Ack=1 Win=253 Len=0
  4.589353 192.168.1.10 -> 173.194.150.124 TCP 54 [TCP ZeroWindow]
62372â+'443 [ACK] Seq=1 Ack=684386 Win=0 Len=0
  8.181129 173.194.150.124 -> 192.168.1.10 TCP 64 [TCP Keep-Alive]
443â+'62372 [ACK] Seq=684385 Ack=1 Win=253 Len=0
  8.181193 192.168.1.10 -> 173.194.150.124 TCP 54 [TCP ZeroWindow]
62372â+'443 [ACK] Seq=1 Ack=684386 Win=0 Len=0
 15.356829 173.194.150.124 -> 192.168.1.10 TCP 64 [TCP Keep-Alive]
443â+'62372 [ACK] Seq=684385 Ack=1 Win=253 Len=0
 15.356883 192.168.1.10 -> 173.194.150.124 TCP 54 [TCP ZeroWindow]
62372â+'443 [ACK] Seq=1 Ack=684386 Win=0 Len=0
 29.702154 173.194.150.124 -> 192.168.1.10 TCP 64 [TCP Keep-Alive]
443â+'62372 [ACK] Seq=684385 Ack=1 Win=253 Len=0
 29.702226 192.168.1.10 -> 173.194.150.124 TCP 54 [TCP ZeroWindow]
62372â+'443 [ACK] Seq=1 Ack=684386 Win=0 Len=0
 58.383969 173.194.150.124 -> 192.168.1.10 TCP 64 [TCP Keep-Alive]
443â+'62372 [ACK] Seq=684385 Ack=1 Win=253 Len=0
 58.384019 192.168.1.10 -> 173.194.150.124 TCP 54 [TCP ZeroWindow]
62372â+'443 [ACK] Seq=1 Ack=684386 Win=0 Len=0
 88.392458 173.194.150.124 -> 192.168.1.10 TCP 64 [TCP Keep-Alive]
443â+'62372 [ACK] Seq=684385 Ack=1 Win=253 Len=0
 88.392501 192.168.1.10 -> 173.194.150.124 TCP 54 [TCP ZeroWindow]
62372â+'443 [ACK] Seq=1 Ack=684386 Win=0 Len=0
118.400917 173.194.150.124 -> 192.168.1.10 TCP 64 [TCP Keep-Alive]
443â+'62372 [ACK] Seq=684385 Ack=1 Win=253 Len=0
118.400955 192.168.1.10 -> 173.194.150.124 TCP 54 [TCP ZeroWindow]
62372â+'443 [ACK] Seq=1 Ack=684386 Win=0 Len=0
148.410372 173.194.150.124 -> 192.168.1.10 TCP 64 [TCP Keep-Alive]
443â+'62372 [ACK] Seq=684385 Ack=1 Win=253 Len=0
148.410415 192.168.1.10 -> 173.194.150.124 TCP 54 [TCP ZeroWindow]
62372â+'443 [ACK] Seq=1 Ack=684386 Win=0 Len=0
178.419853 173.194.150.124 -> 192.168.1.10 TCP 64 [TCP Keep-Alive]
443â+'62372 [ACK] Seq=684385 Ack=1 Win=253 Len=0
178.419878 192.168.1.10 -> 173.194.150.124 TCP 54 [TCP ZeroWindow]
62372â+'443 [ACK] Seq=1 Ack=684386 Win=0 Len=0
208.428292 173.194.150.124 -> 192.168.1.10 TCP 64 [TCP Keep-Alive]
443â+'62372 [ACK] Seq=684385 Ack=1 Win=253 Len=0
208.428315 192.168.1.10 -> 173.194.150.124 TCP 54 [TCP ZeroWindow]
62372â+'443 [ACK] Seq=1 Ack=684386 Win=0 Len=0
238.436834 173.194.150.124 -> 192.168.1.10 TCP 64 [TCP Keep-Alive]
443â+'62372 [ACK] Seq=684385 Ack=1 Win=253 Len=0
238.436893 192.168.1.10 -> 173.194.150.124 TCP 54 [TCP ZeroWindow]
62372â+'443 [ACK] Seq=1 Ack=684386 Win=0 Len=0
268.446251 173.194.150.124 -> 192.168.1.10 TCP 64 [TCP Keep-Alive]
443â+'62372 [ACK] Seq=684385 Ack=1 Win=253 Len=0
268.446269 192.168.1.10 -> 173.194.150.124 TCP 54 [TCP ZeroWindow]
62372â+'443 [ACK] Seq=1 Ack=684386 Win=0 Len=0
298.456257 173.194.150.124 -> 192.168.1.10 TCP 64 [TCP Keep-Alive]
443â+'62372 [ACK] Seq=684385 Ack=1 Win=253 Len=0
298.456327 192.168.1.10 -> 173.194.150.124 TCP 54 [TCP ZeroWindow]
62372â+'443 [ACK] Seq=1 Ack=684386 Win=0 Len=0
394.822000 192.168.1.10 -> 173.194.150.124 TCP 54 [TCP Window Update]
62372â+'443 [ACK] Seq=1 Ack=684386 Win=1323 Len=0
394.832330 173.194.150.124 -> 192.168.1.10 TCP 64 443â+'62372 [RST]
Seq=684386 Win=0 Len=0

at this point mplayer closes with
[tls @ 00000000018367a0]Error in the pull function.
[tls @ 00000000018367a0]The specified session has been invalidated for
some reason.
[tls @ 00000000018367a0]The specified session has been invalidated for
some reason.
[tls @ 00000000018367a0]The specified session has been invalidated for
some reason.
[tls @ 00000000018367a0]The specified session has been invalidated for
some reason.
[mov,mp4,m4a,3gp,3g2,mj2 @ 00000000018605e0]stream 0, offset 0x45ebe3:
partial file
[h264 @ 00000000019acf40]AVC: nal size 15870
[h264 @ 00000000019acf40]no frame!
Error while decoding frame!
[mov,mp4,m4a,3gp,3g2,mj2 @ 00000000018605e0]stream 0, offset 0x45ffc9:
partial file

What is even worse Mplayer has no contingency for the event of _not_
receiving any reply at all and will simply hang _unresponsive_ while
looping last buffered xxx ms of audio.

>> At the very least there should be a way of making mplayer restart
>> failed connection couple of times.
>
> There is, by default, 5 times.

I cant get it to trigger no matter what I do. Maybe it only works for
plain http/ftp shares? or rtp streams?

>> Pausing should result in properly closed connection (maybe after a
>> decent timeout), unpause should start new one.
>
> I don't exactly see the point.
> A lot of servers might be perfectly happy with keeping
> the connection open as long as it takes, why should
> the client add an arbitrary timeout?

might is the key word, in 2016 timing out ZeroWindow quickly is 101 of
ddos resource starvation prevention. Google is very generous with 300
seconds timeout, most CDNs drop you after 10-20 seconds. Can you find
a popular hosting site that wont drop you quickly? I wouldnt suggest
this wasteful method myself either, but even Googles default YT player
does exactly that after pressing pause button (after ~1-2 seconds).


-- 
Who logs in to gdm? Not I, said the duck.


More information about the MPlayer-users mailing list