计算响应的文件大小？

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无延迟）服务器端，至少对于这些转码请求连接。这将防止缓冲，我怀疑这会导致连接丢失。