calculer la taille du fichier d'une réponse?

Question

im essayant de coder un script pour faire le transcodage dynamique de la vidéo et de l'audio (probablement juste l'audio pour le moment) et le streaming sur les appareils mobiles, en utilisant le script affiché ailleurs (How do you convert audio files (on the fly) to the browser?) mais cela semble avoir des problèmes car je ne sais pas comment calculer la taille de fichier des données produites, quelqu'un peut-il suggérer comment je pourrais calculer ceci dynamiquement et passer l'en-tête correct?

Answer 1

(mise à jour avec une solution finale à un problème spécifique au bas de la réponse.)

Vous ne pouvez pas

encodage audio et vidéo est, dans ce cas (et la plupart des autres), pas prévisible lorsque il s'agit de la taille de fichier résultante exacte. Souvenez-vous du fait que la caractéristique de votre source et son impact sur la taille finale du fichier ne peuvent pas être prédits lors du codage. Si vous transcodez «à la volée», vous faites deux choses: 1) compresser, 2) perdre des données. Cela ne peut tout simplement pas être fait avec un format de sortie mp3.

Vous ... si: l'encodage est sans perte, et votre algorithme a été réglé sur les caractéristiques du matériau source très spécifiques (fréquence d'échantillonnage, taille de l'échantillon, etc.) et la source et les formats cibles où non compressé . Mais ce n'est pas ta situation.

En ce qui concerne l'en-tête: ne l'envoyez pas! L'en-tête Content-Length n'est pas une exigence HTTP 1.1. Il y a des inconvénients à cela (les barres de progression ne peuvent jamais savoir ce qui a été fait à 100% jusqu'à la fin du fichier, pas de 'temps restant' non plus) mais je pense que vous pouvez vivre sans.

---

Discussion finale en fonction des commentaires:

Avec un navigateur, je reçois le comportement que vous décrivez. Et avec cette commande curl (utile pour le débogage douleur bas niveau comme celui-ci), il ne fonctionne pas non plus:

curl --trace-ascii trace0.txt "http://dmpwap.net/playmp3.php?b=128&file=Red_Hot_Chili_Peppers_-_15_-_Fortune_Faded.mp3" > test0.mp3 

je reçois 0 octets, et voir dans ma trace:

manoa:~ stu$ cat trace0.txt == Info: About to connect() to dmpwap.net port 80 (#0) 
== Info: Trying 64.191.50.69... == Info: connected 
== Info: Connected to dmpwap.net (64.191.50.69) port 80 (#0) 
=> Send header, 213 bytes (0xd5) 
0000: GET /playmp3.php?b=128&file=Red_Hot_Chili_Peppers_-_15_-_Fortune 
0040: _Faded.mp2 HTTP/1.1 
0055: User-Agent: curl/7.19.4 (universal-apple-darwin10.0) libcurl/7.1 
0095: 9.4 OpenSSL/0.9.8k zlib/1.2.3 
00b4: Host: dmpwap.net 
00c6: Accept: */* 
00d3: 
<= Recv header, 17 bytes (0x11) 
0000: HTTP/1.1 200 OK 
<= Recv header, 19 bytes (0x13) 
0000: Connection: close 
<= Recv header, 37 bytes (0x25) 
0000: Date: Fri, 11 Dec 2009 14:04:58 GMT 
<= Recv header, 27 bytes (0x1b) 
0000: Server: Microsoft-IIS/6.0 
<= Recv header, 27 bytes (0x1b) 
0000: X-Powered-By: PHP/5.2.9-2 
<= Recv header, 35 bytes (0x23) 
0000: Content-Transfer-Encoding: binary 
<= Recv header, 26 bytes (0x1a) 
0000: Content-Type: audio/mpeg 
<= Recv header, 2 bytes (0x2) 
0000: 
<= Recv data, 0 bytes (0x0) 
== Info: Closing connection #0 

Mais ....

Si j'ajoute une option --tcp-nodelay, ça marche très bien! .: par exemple

curl --tcp-nodelay --trace-ascii trace1.txt "http://dmpwap.net/playmp3.php?b=128&file=Red_Hot_Chili_Peppers_-_15_-_Fortune_Faded.mp3" > test1.mp3 

Il est revenu 3219104 octets. Le trace.txt ressemble à ceci:

== Info: About to connect() to dmpwap.net port 80 (#0) 
== Info: Trying 64.191.50.69... == Info: TCP_NODELAY set 
== Info: connected 
== Info: Connected to dmpwap.net (64.191.50.69) port 80 (#0) 
=> Send header, 213 bytes (0xd5) 
0000: GET /playmp3.php?b=128&file=Red_Hot_Chili_Peppers_-_15_-_Fortune 
0040: _Faded.mp3 HTTP/1.1 
0055: User-Agent: curl/7.19.4 (universal-apple-darwin10.0) libcurl/7.1 
0095: 9.4 OpenSSL/0.9.8k zlib/1.2.3 
00b4: Host: dmpwap.net 
00c6: Accept: */* 
00d3: 
<= Recv header, 17 bytes (0x11) 
0000: HTTP/1.1 200 OK 
<= Recv header, 19 bytes (0x13) 
0000: Connection: close 
<= Recv header, 37 bytes (0x25) 
0000: Date: Fri, 11 Dec 2009 13:56:47 GMT 
<= Recv header, 27 bytes (0x1b) 
0000: Server: Microsoft-IIS/6.0 
<= Recv header, 27 bytes (0x1b) 
0000: X-Powered-By: PHP/5.2.9-2 
<= Recv header, 35 bytes (0x23) 
0000: Content-Transfer-Encoding: binary 
<= Recv header, 26 bytes (0x1a) 
0000: Content-Type: audio/mpeg 
<= Recv header, 2 bytes (0x2) 
0000: 
<= Recv data, 1258 bytes (0x4ea) 
0000: ID3.......TENC.......Lavf52.23.1...d.... ..=....w......oq......0 
    ... {many lines} 
0180: UUUUUU 
== Info: Closing connection #0 

Je peux écouter la chanson (3m21s, stéréo, mpga, 48kHz, 128kbps) sans problème. Donc, ma théorie est que, parce qu'il y a 0x00 octets consécutifs dans le flux, les clients pensent "OK, j'ai eu 0x00, 0x00 ... et rien d'autre n'a été envoyé, la connexion doit être terminée. " Mais avec l'option --tcp-nodelay définie sur le client curl, cela n'arrive pas.

Ma solution candidate: Désactiver Nagel's algorithm (définir le paramètre TCP sans délai sur les options de socket) côté serveur, au moins pour ces connexions de demande de transcodage. Cela empêchera la mise en mémoire tampon, qui, je le soupçonne, conduit à l'abandon des connexions.