計算響應的文件大小？

Question

即時通訊編碼腳本做動態視頻和音頻轉碼（可能只是音頻現在）和流媒體到移動設備，目前即時通訊使用腳本發佈在這裏的其他地方（How do you convert audio files (on the fly) to the browser?），但這似乎有問題，因爲我不知道如何計算輸出數據的文件大小，任何人都可以建議我如何動態計算並傳遞正確的頭文件？

Answer 1

（更新與答案的底部末解決特定的問題。）

你不能

音頻和視頻編碼，在這種情況下，（和大多數人），不可預測的時候它涉及到確切的結果文件大小。請記住，在編碼時無法預測源素材的特性和對最終文件大小的影響。如果您正在進行轉碼，您正在做兩件事1）壓縮，2）丟失數據。它只是不能用一個mp3輸出格式來完成。

你會......如果：編碼是無損的，和你的算法進行了調整，非常具體的源材料特性（採樣率，樣本大小等），源和目標格式，其中未壓縮。但那不是你的情況。

至於標題：不要發送它！ Content-Length標題不是HTTP 1.1的要求。這是有缺點的（進度條不知道什麼時候完成了100％，直到文件結束，沒有剩餘時間）是可能的）但我的猜測是你可以沒有它。根據意見

---

最後的討論：

與瀏覽器，我得到你所描述的行爲。而與此curl命令（用來輔助調試這樣的低級別疼痛），它也不起作用：

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字節，所以客戶想到「OK，我得到了0x00,0x00 ......並且沒有其他東西被髮送，連接必須結束。 「但curl客戶端上設置的--tcp-nodelay選項不會發生。

我的候選解決方案：禁用Nagel's algorithm（在套接字選項中設置TCP無延遲）服務器端，至少對於這些轉碼請求連接。這將防止緩衝，我懷疑這會導致連接丟失。