Android文件下载。 媒体URL不以文件名和类型结尾的问题

Question

I'm developing a download-anything app for Android and it works fine in most cases.

I have come across sites that have URLs with a long hash signature (it seems) at the end of it. But the standard video app for Android, and my web browser is able to play it directly, streaming.

I have no clue as to how to stream this to a file (progressive download?), which should be possible. The URL paramater after '?' is used for something. As Jessica pointed out the URL below is probably used for RTMP streams with rtmp://....

URL example (host domain edited out):

 http://blush.im.54ca3830.919727.x.yesitisporn.com/videos/3gp/d/b/f/
      filthysite.com_dbf7f0a9c3913d4d0e09a36fe8ab3aba.mp4?e=1348368010&ri=1024&rs=85&h=c81c6707b13714ac65b651ba2939d94a

In the URL above there is a link to an mp4 video file. Trying to download it with this shorter URL does not work: http://blush.im.54ca3830.919727.x.yesitisporn.com/videos/3gp/d/b/f/ filthysite.com_dbf7f0a9c3913d4d0e09a36fe8ab3aba.mp4 . Returns an empty document.

Since popular video apps and browsers pick up these types of HTTP links just fine for playback; there should be a standard way of getting the byte stream and write it to file. Thanks for any help!

Answer 1

In response to the question as originallly posed: It is quite common to add URL parameters, splitting the url from the parameters with a question-mark, and seperating the parameters with ampersands. Take the substring on everything up to the first non-esecaped question-mark in the url, if a question-mark is present, otherwise use the entire string.

Based on new feedback: Like I said in my comment, and as confirmed by your tests without the parameters, I think you're barking up the wrong tree to try to change the URL. I would suspect the reason you can't save these specific streams is there is something different about the file format or server configuration that is different than the ones that work. In particular, my first thought would be that perhaps those URLs are served by a Streaming Server (Example: Icecast ), and not a normal file-based HTTP server. Advanatages of a streaming server include being able to on the fly serve different bandwidth versions of the streams, and instant seeking to any part of the file and so forth, but the downside for people trying to build download anything applications is those servers don't send the data as a single file, they send the data in chunks--trying not to get too crazy technical, basically, a chunk might have the first frame plus a bunch of diffs for what's on the video in the next several frames and the audio, repeat. As it does this it can throttle what quality to send depending on the latency it's seeing or the resolution of your screen, or resize what it sends if you resize the window and so forth. This sort of streaming works particularly well for live events, but it is not without its advantages for recorded events as well--particularly random seeking. To complicate the matter of capturing the data, some streaming servers actually transmit the video data via RTMP, RTSP, or MMS protocols instead of over HTTP. HTTP Pseudo-streaming or straight HTTP downloads is going to be a lot easier to save than streaming via RTMP . Some streaming types you pretty much have to recreate the file from the individual packets or transcode it from what plays on the screen as it plays in real time. So you may need to spend some time learning about different streaming protocols to figure out the best way to save the specific stream you're looking at.