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.
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.
So I recently got a nodeMCU Lua V1, I started it up connected to my WiFi, and loaded the default HTTP server from https://en.wikipedia.org/wiki/NodeMCU#HTTP_server. Excitedly I did a port forward on my ADSL router and asked friends to connect to see my hello world response. My friends that has apple devices (iPhone/iPad) where unable to load the website. Where as friends with android devices or computers had no trouble viewing the site. I tried using my iPad that is on the same WiFi network. It also had this behavior. To find out what is going on, I tried different browsers on the iPad. I did a Wireshark trace and saw the NodeMCU sending the response to the iPad. But the iPad kept showing either connection error, or a you are offline message. Thinking it might be html headers that is missing I changed the response the nodeMCU is sending to:
<!DOCTYPE html><html><body><h1>My First Heading</h1><p>My first paragraph.</p></body></html>
Still the iPad showed the same message.
So my question is why is iOS behaving this way, what is blocking it and making the browser think it has no internet connection? Is the browser on iOS behaving this way, or is the OS doing something odd. What would I need to do in order for an iOS device to see the web page?
Oh man, that Wikipedia article really is awful (also see https://github.com/nodemcu/nodemcu-firmware/issues/832). I've seen this code example many times but never realized where it originated from.
First of all, you shouldn't use the old 0.9.x binaries your NodeMCU module probably come loaded with. They're no longer supported and contain lots of bugs. Build a custom firmware from the dev or master branch. Second, checkout the official documentation on socket:send() to learn how to do that properly.
The actual problem though is conn:send("<h1> Hello, NodeMcu.</h1>") because that message is NOT a valid HTTP response. You need to prefix that with HTTP/1.0 200 OK\r\nContent-Type: text/html\r\n\r\n.
Similar questions & answers are here and here.
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
I need to view some local (saved somewhere in the iPad) html / js contents with mobile Safari. By reading some threads it seems that the file:// protocol is disabled. Right?
If so, the solution I see is to install an app which turns the iPad into an http server (no need for support of php or anything else), load my contents there and access somehow them within the same device by http://localhost/... or http://127.0.0.1/... with mobile safari.
Is that actually possible? Can someone please suggest me a good web server app which possibly does not require jailbrake or other hacking?
Thanks!
You probably can't do what you want because in order for your application to be serving up HTTP requests to Mobile Safari, it would have to be running in the background, and there's no permissible background mode that covers this.
If you only need a one-time-only response immediately after running your application, then you could possibly use beginBackgroundTaskWithExpirationHandler:, although this might not be approved by Apple - it's difficult to predict their response to that.
If you are sure that you don't need this to go into the App Store, then you can get your application running in the background permanently by abusing one of the other background modes, such as pretending to be a VOIP app or media player.
Once you're running in the background, you can use CocoaHTTPServer to actually serve the files.
If you describe what you are trying to achieve, somebody might be able to suggest an alternative approach to using local files / Mobile Safari.