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

[joe]

Mi sono accorto che Mplayer non riproduce più alcun video: non capisco perchè...
I sospettati principali sono alcuni cambiamenti recenti dell'hardware, infatti recentemente ho cambiato/aggiunto:

• - monitor (ma non penso influisca)
  - scheda video Nvidia GT-210
  - installati relativi driver Nvidia proprietari

Come capire dove potrebbe stare il problema?
Avete qualche ipotesi così su due piedi?

[joe]

Aggiungo che mplayer riesce a riprodurre un filmato wmv.
Il problema sembra con gli mp4.
Aggiungo che anche ffplay non riesce a riprodurre l'mp4 di prova che ho scaricato a caso cercando in rete.

Tanto per fare un esempio il file di prova è questo:
http://ukdl.synology.com/ftp/marketing/ ... .0_chs.mp4

- lo scarico con wget
- lo riproduco con mplayer
- niente da fare

- se invece metto l'indirizzo in chromium il video viene riprodotto da dentro il browser

- allora provo ad aprire col browser lo stesso file scaricato in locale mettendo nella barra degli indirizzi 'file:///home/joe/downloads/DSM3.0_chs.mp4

- niente da fare...

Conclusione non ci capisco più niente....

Lanciando mplayer in modo debug "-v":

Codice: Seleziona tutto

MPlayer 1.1-4.7.1 (C) 2000-2012 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 SSSE3: 1
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 --disable-arts --disable-bitmap-font --codecsdir=/usr/lib/codecs --language=en,de,es,fr --enable-runtime-cpudetection --disable-libdvdcss-internal --disable-mp3lame --disable-mp3lame-lavc --disable-libopencore_amrnb --disable-libopencore_amrwb
CommandLine: '-v' 'DSM3.0_chs.mp4'
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.conf') -> '/home/joe/.mplayer/DSM3.0_chs.mp4.conf'

Playing DSM3.0_chs.mp4.
get_path('sub/') -> '/home/joe/.mplayer/sub/'
[file] File size is 4400839 bytes
STREAM: [file] DSM3.0_chs.mp4
STREAM: Description: File
STREAM: Author: Albeu
STREAM: Comment: based on the code from ??? (probably Arpi)
libavformat version 54.4.100 (internal)
Configuration: --enable-gpl --enable-postproc
LAVF_check: raw H.263
Checking for YUV4MPEG2
ASF_check: not ASF guid!
Checking for REAL
Checking for SMJPEG
Searching demuxer type for filename DSM3.0_chs.mp4 ext: .mp4
Checking for Nullsoft Streaming Video
Checking for MOV
Checking for VIVO
AVS: avs_check_file - attempting to open file DSM3.0_chs.mp4
AVS: File is too big, aborting...
Checking for PVA
Checking for MPEG-TS...
TRIED UP TO POSITION 69041, FOUND 47, packet_size= 0, SEEMS A TS? 0
Checking for LMLM4 Stream Format
Invalid packet in LMLM4 stream: ch=8075 size=4294967288
LMLM4 Stream Format not found
sync_mpeg_ps: seems to be MP3 stream...
MPEG Stream reached EOF
ds_fill_buffer: EOF reached (stream: video)  
MPEG packet stats: p100: 0  p101: 0 p1B6: 0 p12x: 0 sli: 0 a: 0 b: 0 c: 0 idr: 0 sps: 0 pps: 0 PES: 1  MP3: 286, synced: 0
Not MPEG System Stream format... (maybe Transport Stream?)
  {ERROR5,c=234}  

sync_mpeg_ps: seems to be MP3 stream...
MPEG Stream reached EOF
ds_fill_buffer: EOF reached (stream: video)  
MPEG packet stats: p100: 0  p101: 0 p1B6: 0 p12x: 0 sli: 0 a: 0 b: 0 c: 0 idr: 0 sps: 0 pps: 0 PES: 0  MP3: 437, synced: 0
Not MPEG System Stream format... (maybe Transport Stream?)
==> Found video stream: 0
ds_fill_buffer: EOF reached (stream: video)  
LAVF_check: no clue about this gibberish!
demux_aac_probe, failed to detect an AAC stream

vo: x11 uninit called but X11 not initialized..

Exiting... (End of file)
lines 14-71/71 (END)

BoOo!!??!?

[rik70]

Sicuro che c'entri qualcosa il cambio di hardware?
L'errore inizia da qui - parte in grassetto:

[...]
Configuration: --enable-gpl --enable-postproc
LAVF_check: raw H.263
[...]

In sostanza canna l'identificazione del formato, mentre l'output dovrebbe essere:

[...]
Configuration: --enable-gpl --enable-postproc
LAVF_check: QuickTime/MPEG-4/Motion JPEG 2000 format
libavformat file format detected.
[mov,mp4,m4a,3gp,3g2,mj2 @ 0x8aad4e0]ISO: File Type Major Brand: isom
[mov,mp4,m4a,3gp,3g2,mj2 @ 0x8aad4e0]File position before avformat_find_stream_info() is 71711
[mov,mp4,m4a,3gp,3g2,mj2 @ 0x8aad4e0]All info found
[mov,mp4,m4a,3gp,3g2,mj2 @ 0x8aad4e0]File position after avformat_find_stream_info() is 75881

Su che distribuzione sei? E la versione di mplayer/ffmpeg da dove l'hai presa?
Sei sicuro che l'output che hai postato sia quello del file in questione e che sia stato scaricato completamente?

Prova innanzitutto a riprodurlo direttamente:

Codice: Seleziona tutto

mplayer -v 'http://ukdl.synology.com/ftp/marketing/video/DSM3.0_chs.mp4'

[joe]

Ciao, ieri sera poi ho ricompilato mplayer per aggirnarlo un po' visto che era la versione del 2012 o giù di lì.
Il vecchio mplayer di cui è relativo il log che ho postato sopra era appunto una versio più vecchia, non ricordo bene dove l'avevo preso, forse dal repo di alienbob...

Quest'ultimo l'ho preso dal repo di Ponce:

Codice: Seleziona tutto

 /var/log/packages/MPlayer-20150103-i486-1

Ho scaricato la directory remota dei sorgenti dal repo:

Codice: Seleziona tutto

http://ponce.cc/slackware/testing/MPlayer/

E ho lanciato lo slackbuild che c'è dentro.
Poi ho installato anche il vecchio pacchetto dei codecs... "all", ma non so se serve ancora a qualcosa.

Il Sistema Operativo attuale in cui riscontro questo comportamento è Slackware-14.0.

Per quanto riguarda ffmepg se non ricordo male quella contro cui viene compilato mplayer dovrebbe essere recente, presa via git, non ho visto bene lo slackbuild di Ponce ma mi pare faccia qualcosa del genere.
Quella che invece ho installato sul sistema dovrebbe essere la seguente:

Codice: Seleziona tutto

ffmpeg-1.1.2-i686-1sl

Resta il fatto che mplayer ha sempre funzionato...
Ora non capisco cosa sia successo.

Ad ogni modo con questa versione di mplayer ecco come appare il log tentando di riprodirre lo stesso mp4 di ieri:

Codice: Seleziona tutto

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: 0porn m.xhamster.com

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' '-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.conf') -> '/home/joe/.mplayer/DSM3.0_chs.mp4.conf'

Playing DSM3.0_chs.mp4.
get_path('sub/') -> '/home/joe/.mplayer/sub/'
[file] File size is 4400839 bytes
STREAM: [file] DSM3.0_chs.mp4
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: raw H.263
Checking for YUV4MPEG2
ASF_check: not ASF guid!
Checking for REAL
Checking for SMJPEG
Searching demuxer type for filename DSM3.0_chs.mp4 ext: .mp4
Checking for Nullsoft Streaming Video
Checking for MOV
Checking for VIVO
AVS: avs_check_file - attempting to open file DSM3.0_chs.mp4
AVS: File is too big, aborting...
Checking for PVA
Checking for MPEG-TS...
TRIED UP TO POSITION 69041, FOUND 47, packet_size= 0, SEEMS A TS? 0
Checking for LMLM4 Stream Format
Invalid packet in LMLM4 stream: ch=8075 size=4294967288
LMLM4 Stream Format not found
sync_mpeg_ps: seems to be MP3 stream...
MPEG Stream reached EOF
MPEG packet stats: p100: 0  p101: 0 p1B6: 0 p12x: 0 sli: 0 a: 0 b: 0 c: 0 idr: 0 sps: 0 pps: 0 PES: 1  MP3: 286, synced: 0
Not MPEG System Stream format... (maybe Transport Stream?)
  {ERROR5,c=234}  
sync_mpeg_ps: seems to be MP3 stream...
MPEG Stream reached EOF
MPEG packet stats: p100: 0  p101: 0 p1B6: 0 p12x: 0 sli: 0 a: 0 b: 0 c: 0 idr: 0 sps: 0 pps: 0 PES: 1  MP3: 437, synced: 0
Not MPEG System Stream format... (maybe Transport Stream?)
==> Found video stream: 0
ds_fill_buffer: EOF reached (stream: video)  
LAVF_check: no clue about this gibberish!
demux_aac_probe, failed to detect an AAC stream

vo: x11 uninit called but X11 not initialized..

Exiting... (End of file)

Quindi l'errore persiste...
Cosa potrei fare per risolvere?

[rik70]

Come dicevo sopra, prova innanzitutto a riprodurlo direttamente in streaming perché l'errore è di Mplayer.:

Codice: Seleziona tutto

mplayer -v 'http://ukdl.synology.com/ftp/marketing/video/DSM3.0_chs.mp4'

Questo è lo md5sum del file:

Codice: Seleziona tutto

bcecdeb009fb8480213a4f639a5b2344  DSM3.0_chs.mp4

[lablinux]

Prima che driver avevi? Hai installato i driver nVidia corretti?

[rik70]

P.s.
Mi spiego meglio: l'errore non è hardware - o correlato ai driver video - ma del software mplayer.

Tu puoi anche bypassare completamente l'uscita video e i codec video, ma quello che devi ottenere è questo output - col quale il player c'informa che sta riproducendo un formato audio/video noto:

libavformat version 56.18.100 (internal)
Configuration: --enable-gpl --enable-postproc
LAVF_check: QuickTime / MOV
Rilevato formato file libavformat!
[mov,mp4,m4a,3gp,3g2,mj2 @ 0xb746f9a0]ISO: File Type Major Brand: isom
[mov,mp4,m4a,3gp,3g2,mj2 @ 0xb746f9a0]Before avformat_find_stream_info() pos: 71711 bytes read:98304 seeks:0
[aac @ 0xb7574380]skip whole frame, skip left: 0
[mov,mp4,m4a,3gp,3g2,mj2 @ 0xb746f9a0]All info found
[mov,mp4,m4a,3gp,3g2,mj2 @ 0xb746f9a0]After avformat_find_stream_info() pos: 75881 bytes read:98304 seeks:0 frames:2

Tu invece ottieni un non precisato formato 'raw h263', di qui l'errore.

Il comando utilizzato è questo:

Codice: Seleziona tutto

mplayer -vc null -vo null DSM3.0_chs.mp4 -nocorrect-pts -v

[joe]

Ti anticipo che l'md5sum è diverso da quello del mio file... Quindi durante il download è successo qualcosa. Però mplayer non è mai stato molto schizzinoso di solito. Tanto più che vlc riproduce il video...

Aggiungo che neanche in streaming riesco ad ottenere nessun video. Incollo sotto l'output di mplayer lanciato in streaming sull'indirizzo del file mp4, anzi lo metto in allegato perchè è lunghetto...

Che la causa sia la mia connessione ad internet?

Dico questo perchè da qualche settimana il mio ISP, ovvero Telecom Italia Mobile ha cambiato politiche per quel che riguarda l'assegnazione di IP pubblico ai propri utenti connessi ad internet. Non vedo come questo possa causare problemi del genere, ma visto che non sono molto esperto in materia dico non si sà mai e vi faccio presente anche questo fatto.

Farò una prova:
- trasferire il file su dropbox, una volta era possibile con urldorplet, proverò
- scaricare poi il file da dropbox
- calcolo md5
- confronto con l'alltro e col tuo mde5 che hai riportato.

Non chiedetemi perchè dovrebbe cambiare qualcosa... però una prova non costa nulla.
Vi faccio sapere...




@lablinux
Allora, prima avevo i driver Nvidia sempre proprietari, ma relativi al chip integrato nella scheda madre (http://www.asus.com/Motherboards/P5NMX/specifications/) ovvero GeForce 7050 GPU.
Qui si dovrebbero trovare i drivers che avevo installati: http://www.nvidia.it/download/driverRes ... x/80453/it

Invece dopo che ho aggiunto la scheda video nuova, ricordo GeForce 210: http://www.asus.com/Graphics_Cards/EN21 ... fications/
Dopodichè ho disinstallato i drivers vecchi e installato quelli al link di seguito: http://www.nvidia.it/download/driverRes ... x/81777/it

Confermate che sono quelli giusti?

Vi ringrazio davvero intanto per la disponibilità!

[joe]

Ho fatto la prova passando il file dall'indirizzo di origine a dropbox e quindi trasferendolo in locale da lì.
In effetti il file così scaricato ha md5sum uguale a quello postato da Rik.

Non solo, ma mplayer lo riproduce senza problemi... ecco un po' di log:

Qui sotto l'MD5: il primo è quello vecchio scaricato ieri direttamente dal sito originale. Il secondo nella dir "Scaricati" è quello tirato giù via dropbox, mentre il terzo è banalmente l'md5 copiato e incollato lì dopo l'echo.

Codice: Seleziona tutto

joe@darkstar:~$ md5sum DSM3.0_chs.mp4 Scaricati/DSM3.0_chs.mp4 && echo 'bcecdeb009fb8480213a4f639a5b2344  DSM3.0_chs.mp4'
2d82d505caeb60151a9ea43b64905690  DSM3.0_chs.mp4
bcecdeb009fb8480213a4f639a5b2344  Scaricati/DSM3.0_chs.mp4
bcecdeb009fb8480213a4f639a5b2344  DSM3.0_chs.mp4

Di seguito l'output del tentativo di riproduzione del file tirato giù da Dropbox (quello con l'md5 giusto insomma).

Codice: Seleziona tutto

joe@darkstar:~$ mplayer -vc null -vo null Scaricati/DSM3.0_chs.mp4 -nocorrect-pts -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: '-vc' 'null' '-vo' 'null' 'Scaricati/DSM3.0_chs.mp4' '-nocorrect-pts' '-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.conf') -> '/home/joe/.mplayer/DSM3.0_chs.mp4.conf'

Playing Scaricati/DSM3.0_chs.mp4.
get_path('sub/') -> '/home/joe/.mplayer/sub/'
[file] File size is 7047957 bytes
STREAM: [file] Scaricati/DSM3.0_chs.mp4
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.
[mov,mp4,m4a,3gp,3g2,mj2 @ 0xb7496a00]ISO: File Type Major Brand: isom
[mov,mp4,m4a,3gp,3g2,mj2 @ 0xb7496a00]Before avformat_find_stream_info() pos: 71711 bytes read:98304 seeks:0
[aac @ 0xb7599b20]skip whole frame, skip left: 0
[mov,mp4,m4a,3gp,3g2,mj2 @ 0xb7496a00]All info found
[mov,mp4,m4a,3gp,3g2,mj2 @ 0xb7496a00]After avformat_find_stream_info() pos: 75881 bytes read:98304 seeks:0 frames:2
==> Found video stream: 0
======= VIDEO Format ======
  biSize 83
  biWidth 720
  biHeight 480
  biPlanes 1
  biBitCount 24
  biCompression 875967048='H264'
  biSizeImage 1036800
Unknown extra header dump: [1] [4d] [40] [d] [ff] [e1] [0] [1c] [67] [4d] [40] [d] [92] [54] [5] [a1] [ed] [ff] [80] [4] [0] [4] [88] [0] [0] [3] [0] [8] [0] [0] [3] [0] [c0] [78] [a1] [55] [1] [0] [4] [68] [cf] [3c] [80]
===========================
[lavf] stream 0: video (h264), -vid 0
==> Found audio stream: 1
======= WAVE Format =======
Format Tag: 20557 (0x504D)
Channels: 2
Samplerate: 44100
avg byte/sec: 11721
Block align: 1
bits/sample: 16
cbSize: 2
[...]

Alla fine l'ho interrrotto con ctrl-c.
Ad ogni modo come ho detto mplayer lo riproduce in locale senza problemi, mentre la riproduzione streaming non funge.
Inoltre neanche il download del file direttamente dal suo link originale sembra essere corretto e questo porta mplayer a fallire nella riproduzione.

Detto questo annoto che vlc comunque riesce a riprodurre anche il file corrotto.
Lanciandolo da terminale ecco cosa appare scritto.

Codice: Seleziona tutto

joe@darkstar:~$ vlc DSM3.0_chs.mp4 
VLC media player 2.0.7 Twoflower (revision 2.0.6-54-g7dd7e4d)
[0x8d87460] main libvlc: Esecuzione di vlc con l'interfaccia predefinita. Usa 'cvlc' per utilizzare vlc senza interfaccia.

gzip: stdout: Broken pipe

gzip: stdin: decompression OK, trailing garbage ignored
[0xb6d03758] decomp stream error: cannot write data (Broken pipe)

Quindi ok, il problema è di corruzione del file durante i download, ma anche mplayer perde qualche colpo rispetto a vlc in questo caso.

Negli ultimi giorni mi sono accorto che aprendo alcuni mp4 a caso da chromium, non riuscivo più a vederli da dentro il browser.
Non so cosa chromium utilzzi per questa funzione, ma non credo sia mplayer-plugin, di preciso non so...
In ogni caso era comodo perchè il palyer che appare dentro chromium consente di posizionarsi lungo il video al secondo desiderato e non mi costringe così a scaricarmi l'intero file con risparmio di traffico e meno perdita di tempo.
Vedendo che non funzionava più ho provato a scaricare un video e capire cosa non và.
Insomma, sembra svelato il mistero.. Principalmente dovuto alla connessione internet "errorata".

Vi chiedo qualche opinione o commento:
- Anzitutto, mistero svelato ma.... come risolvere?
- Cosa ne pensate? Può essere effettivamente il recente cambio IP a portarsi dietro questo degrado della linea?

Grazie ancora!

[rik70]

Allora, attualmente sul sito del mio ISP riportano che ci sono problemi della linea ADSL in tutta Italia.

Ed in effetti o va lentissima o singhiozza. Quindi potrebbe essere quello: file corrotto durante il download. Fai una verifica con il tuo provider.

Ad ogni modo mi pare di capire che sei riuscito a riprodurlo almeno in locale: giusto? L'ultimo output che hai incollato sembra corretto.

Quanto a vlc, innanzitutto ha dei settaggi della cache diversi da mplayer - o almeno da quelli di default. Da me però mplayer è in grado di riprodurre anche il file parziale - ad esempio interrompendo il download con wget via CTRL+C.

Se vuoi fare dei test, posso passartelo via torrent.

[joe]

Scusa ma non ti seguo del tutto:
Io mi collego con una chiavetta usb su rete mobile TIM, ormai da diversi anni.
Tanto per curiosità se mi dai il link del tuo ISP leggo cosa dicono....

Quello che non ho capito è come potrei verificare col mio provider.
Se significa chiamare il call center TIM, lasciamo perdere.. i guasti tecnici sulla rete o simili, in genere non sono il loro cavallo di battaglia. Per quella poca esperienza che ho avuto non conoscono molti dettagli della qualità della linea.

La situazione rilevata è piuttosto random, ma la possiamo suddividere come segue:
Download con wget:
- se scarico il file in locale direttamente, la connessione in qualche modo corrompe il file stesso e l'md5sum viene sballato. Di conseguenza mplayer mi dà errore e non riesce a riprodurlo.
- se scarico il file che mi sono trasferito da dropbox, tutto liscio nel senso che il file scaricato viene tranquillamente riprodotto e ha md5 giusto.

Veniamo alla riproduzione:

Streaming con mplayer
- mplayer indirizzo-diretto: NO
- mplayer dropbox-url: Sì

Streaming dal browser Chromium
- Se apro il link diretto: Sì funziona, ma ieri non funzionava
- Se apro il link di dropbox: funziona tutto


Parlavi poi di riproduzione di spezzoni di files.
Anche a me mplayer ha sempre riprodotto tutto inclusi gli spezzoni di files.
Ho fatto una prova, riscarico prima il file diretto, quello di dropbox è già apposto quindi non lo riscarico:
Poi creo uno spezzone copiando con dd i primi 4MB del file.
Quindi tento la riproduzione dello spezzone.

Intanto ecco cosa succede durante il download:

Codice: Seleziona tutto

joe@darkstar:~$ wget  http://ukdl.synology.com/ftp/marketing/video/DSM3.0_chs.mp4
--2015-04-01 17:23:55--  http://ukdl.synology.com/ftp/marketing/video/DSM3.0_chs.mp4
Risoluzione di ukdl.synology.com (ukdl.synology.com)... 188.92.232.154
Connessione a ukdl.synology.com (ukdl.synology.com)|188.92.232.154|:80... connesso.
Richiesta HTTP inviata, in attesa di risposta... 200 OK
Lunghezza: 4400839 (4,2M) [video/mp4]
Salvataggio in: "DSM3.0_chs.mp4"

98% [=================================================================================================================>   ] 4.325.446   23,8KB/s   in 2m 25s 

2015-04-01 17:26:21 (29,2 KB/s) - Connessione chiusa al byte 4325446. Altro tentativo in corso.

--2015-04-01 17:26:22--  (tentativo: 2)  http://ukdl.synology.com/ftp/marketing/video/DSM3.0_chs.mp4
Connessione a ukdl.synology.com (ukdl.synology.com)|188.92.232.154|:80... connesso.
Richiesta HTTP inviata, in attesa di risposta... 206 Partial Content
Lunghezza: 4400839 (4,2M), 75393 (74K) rimanenti [video/mp4]
Salvataggio in: "DSM3.0_chs.mp4"

100%[++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++==>] 4.400.839    131KB/s   in 0,6s   

2015-04-01 17:26:23 (131 KB/s) - "DSM3.0_chs.mp4" salvato [4400839/4400839]

Come vedete si è interrotto ed è ripreso automaticamente. Ci può anche stare ma il problema è un altro (e me ne sono accorto dopo).

Codice: Seleziona tutto

$ file *mp4
DSM3.0_chs.mp4:         gzip compressed data, from FAT filesystem (MS-DOS, OS/2, NT)
dropbox-DSM3.0_chs.mp4: ISO Media, MPEG v4 system, version 1
joe@darkstar:~$ md5sum *mp4
2d82d505caeb60151a9ea43b64905690  DSM3.0_chs.mp4
bcecdeb009fb8480213a4f639a5b2344  dropbox-DSM3.0_chs.mp4

C'è poco da dire... i files sono differenti e quello appena scaricato direttamente dal sito è palesemente corrotto rispetto all'originale. E non ne funziona la riproduzione con mplayer.
Ma andiamo avanti lo stesso a creare lo spezzone.

Codice: Seleziona tutto

joe@darkstar:~$ dd if=DSM3.0_chs.mp4 of=partial.mp4 count=1 bs=4000000
1+0 record dentro
1+0 record fuori
4000000 byte (4,0 MB) copiati, 0,00944553 s, 423 MB/s

joe@darkstar:~$ dd if=dropbox-DSM3.0_chs.mp4 of=dropbox-partial.mp4 count=1 bs=4000000
1+0 record dentro
1+0 record fuori
4000000 byte (4,0 MB) copiati, 0,0094988 s, 421 MB/s

joe@darkstar:~$ file *partial*
dropbox-partial.mp4: ISO Media, MPEG v4 system, version 1
partial.mp4:         gzip compressed data, from FAT filesystem (MS-DOS, OS/2, NT)

Ok, quindi niente di nuovo, dal file diretto che non risultava un video è uscito uno spezzone che nono è un video.
mplayer riproduce senza problemi lo spezzone targato dropbox, ma si rifiuta di mostrare a video lo spezzone creato dal file originale.
Quindi è vero che mplayer fuzniona. E riproduce anche gli spezzoni, ma a condizione che il file in entrata non sia un video corrotto.

Ora, ragionando semplicisticamente mi pongo la domanda: perchè diamine deve corrompersi il video solo quando lo scarico direttamente dal suo sito originale, mentre se lo faccio passare per dropbox è valido?

1- il file targato dropbox è identico a quello originale del server di origine, perchè banalmente ne ho fatto il "trans-load" da lì a dropbox, senza passare per la mia connessione. LA mia 2- la mia connessione però entra in gioco nel momento in cui da dropbox ho scaricato il mio file. Perchè in questo modo non ha subito le stesse corruzioni del download diretto?

Continuo in un post successivo... Notando una cosa banale quanto inspiegabile (con le mie conoscenze almeno).

[joe]

Cosa ho scoperto:
l'acqua calda!

Guardate un po' cosa dice wget se usato come spider:

Codice: Seleziona tutto

joe@darkstar:~$ wget --spider https://dl.dropboxusercontent.com/u/41058472/DSM3.0_chs.mp4 http://ukdl.synology.com/ftp/marketing/video/DSM3.0_chs.mp4

Modalità spider abilitata. Controllare se il file remoto esiste.
--2015-04-01 17:50:25--  https://dl.dropboxusercontent.com/u/41058472/DSM3.0_chs.mp4
Risoluzione di dl.dropboxusercontent.com (dl.dropboxusercontent.com)... 23.23.155.202, 54.225.210.31, 23.23.199.111, ...
Connessione a dl.dropboxusercontent.com (dl.dropboxusercontent.com)|23.23.155.202|:443... connesso.
Richiesta HTTP inviata, in attesa di risposta... 200 OK
Lunghezza: 7047957 (6,7M) [video/mp4]
Il file remoto esiste.

Modalità spider abilitata. Controllare se il file remoto esiste.
--2015-04-01 17:50:26--  http://ukdl.synology.com/ftp/marketing/video/DSM3.0_chs.mp4
Risoluzione di ukdl.synology.com (ukdl.synology.com)... 188.92.232.154
Connessione a ukdl.synology.com (ukdl.synology.com)|188.92.232.154|:80... connesso.
Richiesta HTTP inviata, in attesa di risposta... 200 OK
Lunghezza: 7047957 (6,7M) [video/mp4]
Il file remoto esiste.

Quindi ok, i due files remoti (che sono digitalmente identici) esistono ad entrambi gli indirizzi, sono regolarmente riconosciuti come video/mp4 ed entrambi risultano pesare 6.7M.
Perfetto.
Ora vediamo cosa succede quando tento di scaricare il link diretto (volende lo vedete anche dal post precedente):

Codice: Seleziona tutto

joe@darkstar:~$ wget http://ukdl.synology.com/ftp/marketing/video/DSM3.0_chs.mp4
--2015-04-01 18:04:23--  http://ukdl.synology.com/ftp/marketing/video/DSM3.0_chs.mp4
Risoluzione di ukdl.synology.com (ukdl.synology.com)... 188.92.232.154
Connessione a ukdl.synology.com (ukdl.synology.com)|188.92.232.154|:80... connesso.
Richiesta HTTP inviata, in attesa di risposta... 200 OK
Lunghezza: 4400839 (4,2M) [video/mp4]
Salvataggio in: "DSM3.0_chs.mp4.2"

13% [==============>                                                                                                      ] 589.824      126KB/s  est 29s    ^C

Ma il file era di 6.7M!!!
Invece ora appare a wget in fase di download già molto diverso: 4.2M
Chi l'ha compresso così rapidamente?
Parlo di compressione perchè il file finale risulta in locale proprio (mi ripeto):

Codice: Seleziona tutto

DSM3.0_chs.mp4:         gzip compressed data, from FAT filesystem (MS-DOS, OS/2, NT)

Che ci sia di mezzo una sorta di proxy? che fa qualche operazione strana?
E forse non riusciva a farla per il link da dropbox per via dell'https invece che http?

Sono solo ipotesi che sottopongo a voi più esperti! Quindi no scandalizzatevi, io non sono ferrato in materia.
Grazie di nuovo!

[ilmich]

il 'problema' è semplice.. wget, cosi' come probabilmente mplayer non supportano la compressione http.
Tecnicamente parlando il protocollo web prevede che si possano comprimere le risposte http (chi lo faccia.. l'http server piuttosto che l'applicazione varia da caso a caso) per risparmiare banda.
Ovviamente c'e' una sorta di meccanismo di compatibilità tramite il quale il protocollo capisce se il client che fa la richiesta supporta la decompressione.. se la supporta (è il caso di molti browser) manda la risposta compressa.. altrimenti (il caso di wget e mplayer) te la rimanda decompressa.

Secondo me c'e' un buco sul sito (non su dropbox) originale che non tiene conto delle capacità del client http (wget e mplayer) e ti manda sempre e comunque tutto compresso...
Per 'risolvere' il problema potresti provare a mettere in pipe wget e un programma di decompressione (gzcat me pare) ottenendo il file corretto...

[rik70]

E se invece, proprio perché sei su una connessione mobile, fosse il tuo provider a giocarti questo scherzo?

Della serie: scarichi con un programma diverso da un browser, ciucci banda, e io ti zippo
Ovviamente quanto detto è totalmente campato in aria.

Comunque tentar non nuoce. Prova così:

Codice: Seleziona tutto

curl -s -A 'Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Firefox/31.0 ' http://ukdl.synology.com/ftp/marketing/video/DSM3.0_chs.mp4' | mplayer -

O con wget:

Codice: Seleziona tutto

wget -qO- -U 'Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Firefox/31.0' 'http://ukdl.synology.com/ftp/marketing/video/DSM3.0_chs.mp4' | mplayer -

Se va, prova direttamente con mplayer:

Codice: Seleziona tutto

mplayer -user-agent "Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Firefox/31.0" 'http://ukdl.synology.com/ftp/marketing/video/DSM3.0_chs.mp4'

Altra ipotesi:
hai poca velocità in download e il server comprime il file - ma anche questa suona "strano".

Comunque sia la faccenda, non è un problema di driver video.

[joe]

Parto dal fondo:

1) Certamente il problema non è dovuto ai drivers nuovi che ho installato dopo l'installazione della nuova scheda video. Quindi il titolo che ho dato alla discussione dovrebbe essere modificato.

2) Dalle prove che ho fatto non sembra un problema di user agent. Ciò non esclude che il mio ISP ci metta del suo, ma se lo fà, allora applica metodi più furbi.

3) Il problema viene risolto con "zcat" come suggerito da miklos. Per capirci, il seguente comando funziona e si riesce a riprodurre lo streaming.

Codice: Seleziona tutto

wget -q 'http://ukdl.synology.com/ftp/marketing/video/DSM3.0_chs.mp4' -O-|zcat| mplayer - 

Anche così:

Codice: Seleziona tutto

curl -s 'http://ukdl.synology.com/ftp/marketing/video/DSM3.0_chs.mp4' |zcat | mplayer -

Quindi non è un problema di user agent.
Gli imputati principali sembrano le applicazioni (curl, wget, mplayer) che non dimostrano di scompattare il file scaricato al volo, richiedendo l'intervento di un attore esterno come zcat.

Questo non spiega però perchè il transload su dropbox determini automagicamente la decompressione del file che risulta poi un mp4 direttamente fruibile. Forse l'applicazione urldroplet riconosce che viene compresso il tutto e la decomprime al volo verso dropbox, o forse visto che il transload sfrutta velocità di banda ben superiori rispetto alla mia è il server di origine che no comprime i dati.

Aggiungo a tal proposito alcune info che rilevo con "wget --spider -d" sui due files (quello passato su dropbox e quello sul server di partenza).

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-01 23:43:17--  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 0x0933be58 (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
Content-Type: video/mp4
Content-Encoding: gzip
Content-Length: 7047957
Connection: Keep-Alive
Keep-Alive: timeout=5, max=100
Accept-Ranges: bytes
Cache-Control: no-cache
Date: Wed, 01 Apr 2015 22:00:43 GMT
ETag: "6b8b15-4aa21c33c6340"
Expires: Thu, 01 Dec 1994 16:00:00 GMT
Pragma: no-cache
Server: Apache

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

Codice: Seleziona tutto

joe@darkstar:~/tmp/down-corrupt$ wget -d --spider 'https://dl.dropboxusercontent.com/u/41058472/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-01 23:44:52--  https://dl.dropboxusercontent.com/u/41058472/DSM3.0_chs.mp4
Risoluzione di dl.dropboxusercontent.com (dl.dropboxusercontent.com)... 23.23.244.164, 23.23.161.172, 107.21.125.101, ...
Caching dl.dropboxusercontent.com => 23.23.244.164 23.23.161.172 107.21.125.101 23.21.154.121 23.21.160.18 23.23.107.198 184.72.249.105 23.21.45.60
Connessione a dl.dropboxusercontent.com (dl.dropboxusercontent.com)|23.23.244.164|:443... connesso.
Created socket 3.
Releasing 0x09507768 (new refcount 1).
Initiating SSL handshake.
Handshake successful; connected socket 3 to SSL handle 0x09507ad0
certificate:
  subject: /C=US/ST=California/L=San Francisco/O=Dropbox, Inc/CN=*.dropboxusercontent.com
  issuer:  /C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert SHA2 High Assurance Server CA
X509 certificate successfully verified and matches host dl.dropboxusercontent.com

---request begin---
HEAD /u/41058472/DSM3.0_chs.mp4 HTTP/1.1
User-Agent: Wget/1.14 (linux-gnu)
Accept: */*
Host: dl.dropboxusercontent.com
Connection: Keep-Alive

---request end---
Richiesta HTTP inviata, in attesa di risposta... 
---response begin---
HTTP/1.1 200 OK
accept-ranges: bytes
cache-control: max-age=0
content-disposition: inline; filename="DSM3.0_chs.mp4"; filename*=UTF-8''DSM3.0_chs.mp4
Content-Length: 7047957
Content-Type: video/mp4
Date: Wed, 01 Apr 2015 22:02:20 GMT
etag: 277n
pragma: public
Server: nginx
set-cookie: uc_session=GnHuIVlmuuu4KF7rY0syQbRaetVEg5lYT4aLxVGqwC4mYSZDZgDdHgULHsrVFLRl; Domain=dropboxusercontent.com; httponly; Path=/; secure
x-dropbox-request-id: b637bfd6d57ad1ea43926cebfc3a4291
x-robots-tag: noindex, nofollow
X-Robots-Tag: noindex, nofollow, noimageindex
x-server-response-time: 364
Connection: keep-alive

---response end---
200 OK
cdm: 1 2 3 4 5 6 7 8
Stored cookie dropboxusercontent.com -1 (ANY) / <session> <secure> [expiry none] uc_session GnHuIVlmuuu4KF7rY0syQbRaetVEg5lYT4aLxVGqwC4mYSZDZgDdHgULHsrVFLRl
Registered socket 3 for persistent reuse.
Lunghezza: 7047957 (6,7M) [video/mp4]
Il file remoto esiste.

Fate caso al fatto che sul server di origine risulta "Content Encoding: gzip". Mentre su dropbox questo non risulta più.
Questo dimostra che il file su dropbox viene scompattato in qualche modo da urldroplet durante il transolad o qualcosa del genere.
Cosa assai strana secondo me. Perchè un conto è accedere al file remoto con un'applicazione che lo riproduce e allora la scompattazione è necessaria e prevedibile che venga fatta in automatico (vedi ad esempio il browser che riesce a riprodurre il file mentre wget da solo no).
Ma altra cosa è accedervi con un tool di trasferimento come urldroplet che di fatto fà l a stessa cosa di wget. Ovvero su Dropbox mi aspetterei di trovare lo stesso file compresso che ho in origine.

Può anche essere come dicevate che il server di origine decida a priori a chi dare il file compresso e a chi servirlo già decompresso, sulla base della velocità.
Questo potrebbe spiegare perchè wget riesca a vedere il file in dimensioni decompresse ovvero 6.7MB, quando contatta il server i modalità spider. Ma gli venga propinato poi qualcosa più ristretto (4.x MB) se tenta di fare il download dal mio PC collegato ad internet a velocità più ridotta.

A me resta il dubbio però che possa esserci di mezzo qualche proxy messo in piedi ultimamente da TIM inseme al pietoso NAT dietro cui hanno infilato parecchi utenti, se non tutti.

Vi chiedo una conferma ancora.
Se voi scaricate con wget il file in questione, con la vostra connessione, cosa succede?
Potreste postare in codice l'output che registrate come ho fatto io sopra? Magari anche con l'opzione debug che mostra qualche info in più su come wget veda il file remoto.
Aggiungete poi l'output del comando "file". Per capire che roba sia il malloppo scaricato.

In questo modo dovremmo avere una casistica che chiarisce meglio se la compressione/decompressione viene fatta a livello di applicazione o a livello server.

Vi ringrazio per il momento del supporto: senza il vostro aiuto non sarei riuscito a capire questi aspetti.

PS.
Dico che vi potrebbe essere qualcosa frapposto ultimamente da TIM tra me e internet (oltr al NAT), perchè mentre prima dal browser visionavo senza problemi files mp4, adesso spesso il player interno a chromium (ma che player sfrutta poi chromium?) si freeza lì senza fare nulla.

PS-2.
A questo proposito sarei quasi tentato di provare una servizio VPN, magari per un mese... in modo da capire se uscendo da un tunnel cifrato possa aggirare i limiti dell'ISP.
Ho letto proprio ultimamente per esempio di questo servizio: http://123systems.net/kvm.html
Dovrebbe essere sufficiente per mettere in piedi una vpn. Non ho ben capito quale sia la velocità con cui si è connessi, ma 12 euro all'anno sarebbero accessibili.
Però oltre il prezzo mi sarebbe piaciuta la possibilità di provare il servizio tipo per un mese, del tipo un paio di dollari per un mese di prova. Se vedo che tutti i problemi si risolvono allora compro il servizio annuale... comunque per 12 dollari penso che sia accettabile anche solo per fare una prova. Mal che vada non si è speso tanto dopotutto.

PS-3.
MPlayer però in passato non mi ha mai dato problemi neanche a riprodurre file compressi direttamente. Ad esempio una volta ricordo di aver scaricato un file video splittato in diversi archivi RAR e ciascun archivio era tranquillamente riproducibile con mplayer, senza neanche scompattarlo. Anzi a scompattarli non si riusciva con unrar perchp servivano tutti i RAR dello split.
Ora ho provato a zippare sia con gzip che con zip il file mp4 valido (quello targato dropbox per capirci). E mplayer non riesce a riprodurre direttamente l'archivio compresso...
Forse l'mplayer che avevo ai tempi era compilato con qualche opzione in più. O forse ricordo male io e mi scordo di qualche dettaglio.

In ogni caso ho provato a dare:

Codice: Seleziona tutto

vlc dropbox-DSM3.0_chs.mp4.zip

E il video lo riesce a riprodurre anche se zippato.

Mi informerò sulle opzioni "build-time" di mplayer.

PS-Last
Scusate se l'ho fatta lunga.
Ringrazio chi è arrivato a leggere fin qui per la pazienza..