расчет размера файла ответа?

Question

im пытается скопировать сценарий для выполнения динамического транскодирования видео и аудио (скорее всего, только аудио в настоящее время) и потоковой передачи на мобильные устройства, в настоящее время im используя сценарий, опубликованный в другом месте здесь (How do you convert audio files (on the fly) to the browser?), но у этого, похоже, есть проблемы, поскольку я не знаю как вычислить размер файла выводимых данных, может ли кто-нибудь предложить, как я могу рассчитать это динамически и передать правильный заголовок?

Answer 1

(Обновлено с окончательным решением конкретной проблемы в нижней части ответа.)

Вы не можете

аудио и видео кодирования, в данном случае (и в большинстве других), не предсказуемыми он приходит к точному размеру файла. Помните тот факт, что характер вашего исходного материала и влияние на размер финального файла нельзя предсказать при кодировании. Если вы перекодируете «на лету», вы делаете две вещи: 1) сжимаете, 2) теряете данные. Это не может быть сделано с форматом вывода mp3.

Вы могли бы ... если: кодирование без потерь были, и ваш алгоритм был настроен на очень специфические характеристики исходного материала (частота дискретизации, размер выборки и т.д.) и как форматы исходных и целевых где несжатый , Но это не ваша ситуация.

Что касается заголовка: не отправляйте его! Заголовок Content-Length не является требованием HTTP 1.1. Есть недостатки в этом (индикаторы прогресса никогда не могут знать, что 100% сделано до конца файла, и «оставшееся время» тоже возможно), но я думаю, вы можете жить без него.

---

Заключительная дискуссия на основе комментариев:

С помощью браузера, я получаю поведение, которое вы описываете. И с этим завитком команды (полезно для отладки низкого уровня боли, как это), она также не работает:

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

Я получаю 0 байт, и увидеть это в моих след:

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 

Но ....

Если я добавлю опцию --tcp-nodelay, это прекрасно работает! Например:

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 

Он вернул 3219104 байт. Trace.txt выглядит следующим образом:

== 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 

Я могу слушать песни (3m21s, стерео, mpga, 48kHz, 128kbps) без проблем.

Итак, моя теория заключается в том, что, поскольку в потоке есть последовательные 0x00 байт, клиенты думают «Хорошо, я получил 0x00, 0x00 ... и ничего больше не было отправлено, соединение должно быть закончено. " Но с опцией --tcp-nodelay, установленной на клиенте curl, этого не происходит.

Мое решение кандидата: Отключить Nagel's algorithm (установить TCP без задержки на параметры сокета) на стороне сервера, по крайней мере для этих соединений запроса на перекодирование. Это предотвратит буферизацию, которая, как я подозреваю, приводит к удалению соединений.