计算响应的文件大小?
即时通讯编码脚本做动态视频和音频转码(可能只是音频现在)和流媒体到移动设备,目前即时通讯使用脚本发布在这里的其他地方(How do you convert audio files (on the fly) to the browser?),但这似乎有问题,因为我不知道如何计算输出数据的文件大小,任何人都可以建议我如何动态计算并传递正确的头文件?计算响应的文件大小?
(更新与答案的底部末解决特定的问题。)
你不能
音频和视频编码,在这种情况下,(和大多数人),不可预测的时候它涉及到确切的结果文件大小。请记住,在编码时无法预测源素材的特性和对最终文件大小的影响。如果您正在进行转码,您正在做两件事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无延迟)服务器端,至少对于这些转码请求连接。这将防止缓冲,我怀疑这会导致连接丢失。
问题他们,媒体不正确流(流约3秒,然后死)我的工作有点类似,但它做转换两次做到这一点 – 2009-12-04 11:03:40
为什么它会死?你确定这是客户放弃流吗? – 2009-12-04 14:32:54
是的,好像我去我的手机上的同一个流(tmob g1作为参考),它正确流式播放歌曲,但它永远不会结束,因为电话不能确定歌曲的长度,quicktime在PC上的Firefox只需3秒,然后停止 – 2009-12-08 18:30:22