I have an mp4 (h.264) file that I want to play on an IPhone (via HTTP). When the file sits on a Windows IIS server, my IPhone and IPad will play the video without any issues.
The file is here: test file
I will leave access to this server for a few days for testing purposes.
When the file sits on our proprietary server, my IPhone and IPad request the download, but then stops the process almost immediately. Non IOS phones and desktop browsers have no problems requesting and viewing the video from the proprietary server. I don't believe that it has anything to do with the HTTP response headers because of the fact that non-IOS phones can play the video.
I use Wireshark to see the http/tcp requests between the IPhone and the server. I see the IPhone request the mp4 and then I see the server send a "200 OK" response and then start to send the file. Soon after the server starts to send the file, the IPhone sends a "reset" request which stops the sending of the file.
Any ideas why the IPhone would reset the communication and stop the file from being sent? I am far from a regular user of Wireshark, so hopefully, my reading of the file is correct.
Here is an image of my Wireshark capture if anyone is interested. It clearly shows the reset from the IPhone.
Wireshark Image
Any help will be appreciated.
Thanks,
Dana
This has been solved. Our server did not handle HTTP requests for partial content (i.e. Range: bytes=0-999). Range headers in incoming requests were being ignored.
We updated the server to handle these requests and IOS devices are now able to download video from our server.
See the link below for more info:
http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p5-range-latest.html
Related
Since many days, I'm trying to load this link: http://test-v4.pleade.com:8205/pleade/functions/ead/detached/docs/test.mp4 It doesn't work in Safari (Desktop and IOS devices)
According to this thread: Why won't Safari play file without extension in <video>? (and many others), you can notice that HTTP headers (Ranges, Content-Length, ...) are correctly defined in my case.
When you check the "request response flow", you can noticed that the first request, where Safari test the compatibility with Range (Byte Range 0-1) is correctly processed. But, It stops at that point. Safari refuses to throw next parts where he asks the MP4 file bytes per bytes.
I'm working with Tomcat and Apache Cocoon. For being sure to avoid encode problems, I have tried the same mp4 file directly and only with an Apache Server. It is loaded well in Safari and all other browsers (direct link here: http://test-v4.pleade.com/test.mp4).
Thank you for you helps.
I am trying to debug my web based HLS player (with HTML5 tag) and would like to monitor the network request to fetch the segments of the stream. This works fine in all desktop browsers (safari, chrome, firefox), and works with the OSX Safari, as well.
But when I connect to a iOS Safari (Simulator or real iPhone), only the request of the m3u-file shows up in the network monitor, not the requests to the segments of the stream.
Is there a way to monitor those requests on iOS Safari?
The reason I want to do this is trying to avoid automatic loading of segments while the player is paused/stopped. This works fine with hls.js, but I am not sure how iOS Safari handles the preload=none attribute. Although here Apple says that "Safari on iOS never preloads", this does not seem to be true when pausing the player. (see https://developer.apple.com/documentation/webkitjs/htmlmediaelement/1633059-preload, too)
Thanks!
P.S.: I tried to get any information in Apple's forums before, unfortunately without any success (https://discussions.apple.com/message/32027089#32027089).
You can monitor these requests like any other. I recommend Fiddler... It works as a proxy server and can be used to monitor or edit traffic, even with HTTPS. For lower level debugging or cases where you can't use a proxy, use a packet sniffer like Wireshark.
My app solution on iOS has downloaded audio and video for offline use. Streaming to apple tv worked like charm for a while, however, we needed to implement file encryption. As a web app, to support encrypted file on the webview, we implemented a http server, which decrypts the file, and streams it unencrypted to the webview request. But now, we need to stream theses encrypted files to the Apple Tv, obviously, when trying to shared the video/audio, the Apple TV tries to stream from the iPad http server url (localhost:8000), and an error is shown.
How should I be able to stream it? As I see, there are other apps which uses encryption and works fine with air play.
Edit: The error message is way generic, just appears on TV that the file could not be played, no log on xcode console.
The HTML on the webview is simple as that, no big deal: <video src= "http://localhost:8000/file/fileId"/>, works fine on iPad, but not streaming to Apple TV.
I'm working in analyze the live tv streaming from TVB(HK)
Well known the url(s) to watch them are:
http://token.tvb.com/stream/live/hls/mobilehd_hdj.smil
http://token.tvb.com/stream/live/hls/mobilehd_j2.smil
http://token.tvb.com/stream/live/hls/mobilehd_inews.smil
We can directly watch by url(s) above in any apple native software(such as QuickTime, Safari) no matter in Mac or iOS. And also known they are using AppleCoreMedia framework. But it won't works in other platforms. You will get HTTP 200 but "access denied" in content.
I analyzed all the traffic about it. I found that the HTTP request(by CoreMedia) to the endpoint(the server really provide video) contain a header:
x-playback-session-id: xxxxx
The video arrived instead of "access denied" message after I add the header manually(I tried in Chrome or Firefox), no matter what the user-agent is. But the problem occur is, I can't find any other place contain this header in earlier request(since it redirected a few times) in the traffic I dumped. So I'm curious what AppleMediaCore did when it playing http stream? Did it calculated a session id(or hash) or it got the id from somewhere i missed?
p.s. I'm not sure TVB do a IP check or not. Since they had a copyright or legal concern so maybe blocked to access from somewhere. You maybe need a VPN.
Finally I found the answer. The x-playback-session-id is a UUID comes from the AVPlayer Framework. But in fact this won't affect I got token or not. The real token is HTTP cookie.
Authorization process I found:
token.tvb.com redirect to vod server with a couple of GET value
VOD Server check GET value and set cookie if valid. Also respond m3u8 file(contains several different quality stream url)
Player will request one or more url in m3u8 to retrieve streams. VOD server will then check cookie and user-agent as token.
In the coming time player will keep using the cookie and user-agent as token to request ts files.
p.s. HLS from TVB for android has different process I haven't figure out. But I found that if user-agent contains "Android" then authorization will fail.
I have a small iPhone app that consumes streaming video. With Apache on my Macbook, I have been able to get it working without any trouble. i.e., I've deployed the .m3u8 and .ts files and the server is correctly streaming the files and the phone app is displaying the video too.
Now I try to replicate this on an apache server running on a Windows Server, and can't get it to work. I've got the correct settings in mime.types for both content types.
Using the mediastreamvalidator locally returns verified ok status. Running it on the remote stream hangs it.
access.log shows the first five segments being requested and then nothing. If I try to access from Safari it shows the controls and the trackbar updates up to 8 seconds and then nothing. I have seen this question but that doesn't seem to be the problem.
In the browser, the GET statements for both local and remote return identical results.
Safari plays from the local URL, Firefox and Chrome don't and neither gives any errors.
Any help would be much appreciated!
Turns out you need to use the "-no-floating-point-duration" and "-iframe-index-file none" parameters to mediafilesegmenter. Still doesn't work in Firefox or Chrome. But that's not a problem for now.