Cambio scheda video e drivers Nvida: MPlayer non gira più!

[joe]

Benissimo, pare che l'ISP centri eccome.
Ho provato a mettere in piedi una VPN al volo sfruttando un servizio gratutio (vpnbook).
Praticamente ecco cosa succede:

Codice: Seleziona tutto

joe@darkstar:~/tmp/down-corrupt$ mplayer 'http://ukdl.synology.com/ftp/marketing/video/DSM3.0_chs.mp4'
MPlayer 20150103-4.7.1 (C) 2000-2015 MPlayer Team

Playing http://ukdl.synology.com/ftp/marketing/video/DSM3.0_chs.mp4.
Resolving ukdl.synology.com for AF_INET6...

Couldn't resolve name for AF_INET6: ukdl.synology.com
Resolving ukdl.synology.com for AF_INET...
Connecting to server ukdl.synology.com[188.92.232.154]: 80...

Cache size set to 320 KBytes
Cache fill: 13.40% (43915 bytes)   

libavformat version 56.17.100 (internal)
libavformat file format detected.
[lavf] stream 0: video (h264), -vid 0
[lavf] stream 1: audio (aac), -aid 0, -alang und
VIDEO:  [H264]  720x480  24bpp  12.000 fps  255.6 kbps (31.2 kbyte/s)
Clip info:
 major_brand: isom
 minor_version: 512
 compatible_brands: isomiso2avc1mp41
 creation_time: 1970-01-01 00:00:00
 encoder: Lavf52.39.0
==========================================================================
Forced video codec: ffmpeg12vdpau
Forced video codec: ffmpeg12vdpauold
Forced video codec: ffh264vdpau
Opening video decoder: [ffmpeg] FFmpeg's libavcodec codec family
libavcodec version 56.19.100 (internal)
Selected video codec: [ffh264vdpau] vfm: ffmpeg (FFmpeg H.264 (VDPAU))
==========================================================================
==========================================================================
Opening audio decoder: [ffmpeg] FFmpeg/libavcodec audio decoders
AUDIO: 44100 Hz, 2 ch, floatle, 93.8 kbit/3.32% (ratio: 11721->352800)
Selected audio codec: [ffaac] afm: ffmpeg (FFmpeg AAC (MPEG-2/MPEG-4 Audio))
==========================================================================
AO: [oss] 44100Hz 2ch s16le (2 bytes per sample)
Starting playback...
Movie-Aspect is 1.33:1 - prescaling to correct movie aspect.
VO: [vdpau] 720x480 => 720x540 H.264 VDPAU acceleration 
Movie-Aspect is 1.33:1 - prescaling to correct movie aspect.
VO: [vdpau] 720x480 => 720x540 H.264 VDPAU acceleration 
A:  12.6 V:  12.6 A-V: -0.000 ct:  0.107   0/  0  2%  0%  0.2% 1 0 45% 

Exiting... (Quit)

Ora mplayer funziona dandogli in pasto direttamente l'indirizzo remoto.
Perchè?
A quanto pare anche wget in spider mode vede il file remoto in modo diverso. se ricordate nel post sopra ho evidenziata la dicitura:

Codice: Seleziona tutto

---response begin---
HTTP/1.1 200 OK
Content-Type: video/mp4
Content-Encoding: gzip
Content-Length: 7047957

Guardate invece ora cosa dice wget:

Codice: Seleziona tutto

joe@darkstar:~/tmp/down-corrupt$ wget -d --spider 'http://ukdl.synology.com/ftp/marketing/video/DSM3.0_chs.mp4'
Setting --spider (spider) to 1
DEBUG output created by Wget 1.14 on linux-gnu.

URI encoding = "UTF-8"
Modalità spider abilitata. Controllare se il file remoto esiste.
--2015-04-02 01:17:24--  http://ukdl.synology.com/ftp/marketing/video/DSM3.0_chs.mp4
Risoluzione di ukdl.synology.com (ukdl.synology.com)... 188.92.232.154
Caching ukdl.synology.com => 188.92.232.154
Connessione a ukdl.synology.com (ukdl.synology.com)|188.92.232.154|:80... connesso.
Created socket 3.
Releasing 0x08405e58 (new refcount 1).

---request begin---
HEAD /ftp/marketing/video/DSM3.0_chs.mp4 HTTP/1.1
User-Agent: Wget/1.14 (linux-gnu)
Accept: */*
Host: ukdl.synology.com
Connection: Keep-Alive

---request end---
Richiesta HTTP inviata, in attesa di risposta... 
---response begin---
HTTP/1.1 200 OK
Date: Wed, 01 Apr 2015 23:34:51 GMT
Server: Apache
Last-Modified: Wed, 10 Aug 2011 07:38:13 GMT
ETag: "6b8b15-4aa21c33c6340"
Accept-Ranges: bytes
Content-Length: 7047957
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: video/mp4

---response end---
200 OK
Registered socket 3 for persistent reuse.
Lunghezza: 7047957 (6,7M) [video/mp4]
Il file remoto esiste.

L'header Content Encoding è sparito.
Proviamone il download...

Codice: Seleziona tutto

joe@darkstar:~/tmp/down-corrupt$ wget -d 'http://ukdl.synology.com/ftp/marketing/video/DSM3.0_chs.mp4'
DEBUG output created by Wget 1.14 on linux-gnu.

URI encoding = "UTF-8"
--2015-04-02 01:19:35--  http://ukdl.synology.com/ftp/marketing/video/DSM3.0_chs.mp4
Risoluzione di ukdl.synology.com (ukdl.synology.com)... 188.92.232.154
Caching ukdl.synology.com => 188.92.232.154
Connessione a ukdl.synology.com (ukdl.synology.com)|188.92.232.154|:80... connesso.
Created socket 3.
Releasing 0x08cd6df8 (new refcount 1).

---request begin---
GET /ftp/marketing/video/DSM3.0_chs.mp4 HTTP/1.1
User-Agent: Wget/1.14 (linux-gnu)
Accept: */*
Host: ukdl.synology.com
Connection: Keep-Alive

---request end---
Richiesta HTTP inviata, in attesa di risposta... 
---response begin---
HTTP/1.1 200 OK
Date: Wed, 01 Apr 2015 23:37:04 GMT
Server: Apache
Last-Modified: Wed, 10 Aug 2011 07:38:13 GMT
ETag: "6b8b15-4aa21c33c6340"
Accept-Ranges: bytes
Content-Length: 7047957
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: video/mp4

---response end---
200 OK
Registered socket 3 for persistent reuse.
Lunghezza: 7047957 (6,7M) [video/mp4]
Salvataggio in: "DSM3.0_chs.mp4.2"

100%[====================================================================================================================>] 7.047.957    285KB/s   in 40s    

2015-04-02 01:20:18 (173 KB/s) - "DSM3.0_chs.mp4.2" salvato [7047957/7047957]

- Intanto notate la velocità!!!
Ora scarico a piena banda quel file, come da dropbox... Mentre prima ad un certo punto la velocità si piantava a 60-80 KB/s.

- Poi notate la dimensione del file scaricato, non sono più i 4.qualcosa di prima. Ma i corretti 6.7M.

- Infine vediamo il confronto col file sano prelevato via dropbox:

Codice: Seleziona tutto

joe@darkstar:~/tmp/down-corrupt$ file DSM3.0_chs.mp4.2 dropbox-DSM3.0_chs.mp4
DSM3.0_chs.mp4.2:       ISO Media, MPEG v4 system, version 1
dropbox-DSM3.0_chs.mp4: ISO Media, MPEG v4 system, version 1

joe@darkstar:~/tmp/down-corrupt$ md5sum DSM3.0_chs.mp4.2 dropbox-DSM3.0_chs.mp4
bcecdeb009fb8480213a4f639a5b2344  DSM3.0_chs.mp4.2
bcecdeb009fb8480213a4f639a5b2344  dropbox-DSM3.0_chs.mp4

Ecco che il nostro download è andato a buon fine ed ecco come viene riprodotto giustamente con mplayer:

joe@darkstar:~/tmp/down-corrupt$ mplayer DSM3.0_chs.mp4.2 -v
MPlayer 20150103-4.7.1 (C) 2000-2015 MPlayer Team
CPU vendor name: GenuineIntel max cpuid level: 10
CPU: Intel(R) Core(TM)2 Duo CPU E8200 @ 2.66GHz (Family: 6, Model: 23, Stepping: 6)
extended cpuid-level: 8
extended cache-info: 402686016
Detected cache-line size is 64 bytes
Testing OS support for SSE... yes.
Tests of OS support for SSE passed.
CPUflags: MMX: 1 MMX2: 1 3DNow: 0 3DNowExt: 0 SSE: 1 SSE2: 1 SSE3: 1 SSSE3: 1 SSE4: 1 SSE4.2: 0 AVX: 0
Compiled with runtime CPU detection.
get_path('codecs.conf') -> '/home/joe/.mplayer/codecs.conf'
Reading optional codecs config file /home/joe/.mplayer/codecs.conf: No such file or directory
Reading optional codecs config file /etc/mplayer/codecs.conf: No such file or directory
Using built-in default codecs.conf.
init_freetype
Using MMX (with tiny bit MMX2) Optimized OnScreenDisplay
get_path('fonts') -> '/home/joe/.mplayer/fonts'
Configuration: --prefix=/usr --mandir=/usr/man --confdir=/etc/mplayer --enable-gui --enable-menu --enable-vdpau --disable-arts --disable-bitmap-font --codecsdir=/usr/lib/codecs --language=en,de,es,fr --enable-runtime-cpudetection
CommandLine: 'DSM3.0_chs.mp4.2' '-v'
Using nanosleep() timing
get_path('input.conf') -> '/home/joe/.mplayer/input.conf'
Reading optional input config file /home/joe/.mplayer/input.conf: No such file or directory
Reading optional input config file /etc/mplayer/input.conf: No such file or directory
Falling back on default (hardcoded) input config
get_path('DSM3.0_chs.mp4.2.conf') -> '/home/joe/.mplayer/DSM3.0_chs.mp4.2.conf'

Playing DSM3.0_chs.mp4.2.
get_path('sub/') -> '/home/joe/.mplayer/sub/'
[file] File size is 7047957 bytes
STREAM: [file] DSM3.0_chs.mp4.2
STREAM: Description: File
STREAM: Author: Albeu
STREAM: Comment: based on the code from ??? (probably Arpi)
libavformat version 56.17.100 (internal)
Configuration: --enable-gpl --enable-postproc
LAVF_check: QuickTime / MOV
libavformat file format detected.
[...]

Ok, quindi altro che driver!

[ilmich]

Perdonami, non ce l'ho fatta a leggere fino alla fine, ma arrivato a metà credo di non essermi spiegato bene.
Il meccanismo di compressione http è trasparente, non c'e' nessun meccanismo che preso un file .txt (ad esempio) te lo cambia in un file compresso volontariamente (quello che stai notando è un non corretto funzionamento del server)
Il protocollo http comprime il file per risparmiare banda (tant'e' vero che è cattiva gestione di un sito web non avere questo tipo di funzionalità perchè fa risparmiare un sacco di banda/tempo di caricamento), ma non è un sistema atto a trasformare i file.
In altre parole, il file a tutti gli effetti è e resta di 6,7mb.. viene solo scaricato in modo compresso.. sta poi al client decomprimerlo in automatico.

Il sistema funziona piu' o meno cosi' (dropbox lavora bene.. da quello che posti tu è il sito di origine che ha un bug).

1) il client fa una richiesta http con eventualmente questo header (se è in grado di decomprimere al volo)

Codice: Seleziona tutto

 Accept-Encoding: compress, gzip

2) il server ricevente se trova questo header http risponde cosi'

Codice: Seleziona tutto

Content-Encoding: gzip

inviando come dimensione del file quella originale, ma come corpo della risposta dei dati compressi in gzip che poi il client decomprime al volo (in pratica quello che hai fatto tu concatenando wget e zcat)
se invece non lo trova ti manda tutto cosi' com'e'.

Detto questo, analizzando il comportamento che stai verificando e premesso che wget (cosi' come mplayer) non supportano la compressione al volo (quindi non mandano l'header al passo 1) ..

• il server dropbox lavora bene e difatti ti manda il file cosi' com'e (e in risposta non trovi alcun header relativo al Content-Encoding)
• l'altro server lavora male(o magari per tutti i contenuti multimediali ha la compressione forzata).. se ne frega di discriminare e ti manda sempre e comunque un file compresso.. che pero' wget non decomprime.. di conseguenza quello che hai scaricato è il file compresso che a te sembra zippato.

questa cosa non la noti col browser perchè tutti supportano la compressione delle risposte del protocollo http (che ripeto, è una funzionalità del protocollo http.. non un magheggio di qualche provider/proxy)e percio' quando fai il download di quel file, alla fine di tutto viene decompresso al volo e a te viene fuori il file corretto.

[ilmich]

Benissimo, pare che l'ISP centri eccome.

sarebbe da denuncia.

[ilmich]

testa con questa pagina gli header in piu' che il provider mette
io ne ho trovati giusto 3 in piu' col mio ISP

Codice: Seleziona tutto

X-http-proto: HTTP/1.1
X-log-7527: xxxxxxxxxxxxxxxx
X-real-ip: xxxxxxxxxxxxxx

[rik70]

Scusate, ma non avevo letto il post di miklos che era arrivato prima di me.

Morale della favola: l'ipotesi bizzarra sul ruolo dell'ISP s'è rivelata plausibile?

Uhm... interessante. Che poi alla fine vai a leggerti il contratto per intero e ti ritrovi la clausola che dice che loro, per ragioni tecniche, possono alterare o limitare le connessioni.
E io che pensavo che queste fossero pure leggende metropolitane...

Qui da me in ogni caso il Content-Type è sempre video/mp4, non importa se il client sia wget, curl, mplayer, mpv... o altro. Di gzip nemmeno l'ombra.

[joe]

Sì direi che l'ISP ci mette lo zampino.
Sul fatto che al cosa sia voluta oppure accidentale (pasticci all'italiota) non metto mano su fuoco.

Comunque Rik, non è tanto l'header "Content Type" che devi guardare, quanto la presenza o meno dell'header "Content Encoding: gzip".

La cosa migliore per capire sarebbe dare un bel:

Codice: Seleziona tutto

wget -d --spider"

E postare il risultato così vediamo le differenze.
Mi riservo di fare il test dalla pagina linkata da miklos appena riesco.

Per curiosità, che connessione avete? Quale ISP?

[rik70]

Da me niente Content-Encoding:

Codice: Seleziona tutto

URI encoding = "UTF-8"
Caching ukdl.synology.com => 188.92.232.154
Created socket 3.
Releasing 0x08c27070 (new refcount 1).

---request begin---
HEAD /ftp/marketing/video/DSM3.0_chs.mp4 HTTP/1.1
User-Agent: Wget/1.14 (linux-gnu)
Accept: */*
Host: ukdl.synology.com
Connection: Keep-Alive

---request end---

---response begin---
HTTP/1.1 200 OK
Date: Thu, 02 Apr 2015 11:54:49 GMT
Server: Apache
Last-Modified: Wed, 10 Aug 2011 07:38:13 GMT
ETag: "6b8b15-4aa21c33c6340"
Accept-Ranges: bytes
Content-Length: 7047957
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: video/mp4

---response end---
Registered socket 3 for persistent reuse

Quanto all'ISP, io ho una ADSL flat Tiscali.

[joe]

testa con questa pagina gli header in piu' che il provider mette
io ne ho trovati giusto 3 in piu' col mio ISP

Codice: Seleziona tutto

X-http-proto: HTTP/1.1
X-log-7527: xxxxxxxxxxxxxxxx
X-real-ip: xxxxxxxxxxxxxx

Non ho capito come fai a distinguere gli headers in più aggiunti dal provider.