I have an mvc webpage with videojs on it streaming an mp4 file. when I run the page from a desktop, and debug the site, I can see that with a desktop view of the page, the video gets called twice for some reason, both calls seems to have a range-request of the entire filesize. this seems strange that its being called twice, but even stranger, if I call this same page from IOS (IPAD), I see 6 calls for the stream. the first two are usually requesting the first two bytes which makes sense based on my knowledge that IOS does this to determine if the stream is seekable. Then it makes 4 more calls to pull the stream each with a range-request of the entire filesize from what I can recall. Anyone know if this is normal for IOS and videojs use?
Yes, this is normal. the player is probing the file to determine characteristics. It is trying to find the location of the mdat and moov atoms. Even though it asks for the entire file, it will disconnect the TCP session as soon as it has the data it needs to seek with into file.
Related
I'm currently working on a library that sends a MediaStreamTrack from one electron window to another one via an RTCPeerConnection.
The problem I currently have is that everything works fine except remote tracks. A MediaStreamTrack of my camera is created on localhost and can be sent without any problem but when I'm trying to send a track, which I'm receiving from an external server, then it only shows black frames.
It's the same problem as here I guess.
What I've checked
The track is getting received (I checked chrome://webrtc-internals) and the video element is in a playing state. I don't see any errors, neither in the console nor in webrtc-internals.
Additionally the stream/track is enabled and not muted. Using captureStream() on the source window results in the same.
Capturing and streaming a video element with an external source is working without any problems.
Possible reason
I think the problem might be that the initial stream is coming from a domain that is not localhost and for which reason it is impossible to restream it. In the w3c standard, it is described as follows:
A track could have contents that are inaccessible to the application. This can be due to anything that would make a track CORS cross-origin. These tracks can be supplied to the addTrack() method, and have an RTCRtpSender created for them, but content MUST NOT be transmitted. Silence (audio), black frames (video) or equivalently absent content is sent in place of track content.
Source (10.)
Idea
I'm not sure if the "possible problem" I mentioned above is the real problem but one idea I had was to rewrite the request and response headers to match localhost but it didn't work. I guess it doesn't affect WebRTC connections.
Electron hooks I used:
session.defaultSession.webRequest.onBeforeSendHeaders();
session.defaultSession.webRequest.onHeadersReceived();
Would like to understand how AirBnb is able to load a 20MB background video file so fast on their homepage. After inspecting their homepage on WebPageTest, I noticed that the video did not show up in any of the downloaded resources, which made it score so high. When I've tried this tactic, via loading the video asynchronously via AJAX, the video still shows up on WebPageTest as a downloaded resource, but just after the DOM loads. So I'm really not sure how AirBnb is able to make this work. Does anyone have an idea?
AirBnb isn't doing anything special here. They're just starting playback of media using progressive download, which just means playback starts while the video is still downloading.
On their CDN, they have uploaded some fairly large MP4 files with two important characteristics:
The indexing information (MOOV atom) has been moved to the beginning of the MP4 file
The video is encoded in a format and codec that your browser supports
Because of these characteristics, all the site has to do is tell your browser to begin playing the source URL, and it will do the right thing: it makes a web request to the CDN and begins downloading the file. As soon as enough data has been transferred to start playback, it does so.
Finally, I can't say for sure why WebPageTest doesn't show you the video MP4s that are driving the video, but they are certainly there, and the URLs look like https://a0.muscache.com/airbnb/static/Xxxxx-X1-1.mp4. I suspect they're looking at your User Agent to decide which file to send you, and are not sending any video at all to bots like Google and WebPageTest.
You're not getting the real story through WebPageTest. Instead of relying on a third party to evaluate the page in their environment, you should watch the traffic you are actually being sent using Fiddler or the Network tab on Chrome Developer Tools.
The problem
I made a receiver application that is just showing a video in loop on the Chromecast. The problem is that the Chromecast doesn't seems to be caching the video in it's cache. So the video keeps getting downloaded every time it finishes a loop and it takes a lot of bandwidth. The video will be hosted on external server so the Chromecast will have to download it from internet every time (I cannot change that spec).
Just for you know, when debugging the receiver application on a desktop chrome application, the video is cached by the browser, so the problem doesn't seems to come from http responses for the caching behaviour.
A solution I explored
I tried to download the video file in ajax and play it. The problem is the Chromecast seems to crash when my Javascript tries to read the responseText field of the xhr when the result has more than 28MB (I tried with a 50MB file (it crashed) and a 28MB file (it didn't crash), the limit could actually be 32MB).
EDIT:
I also tried this example and it also makes the chromecast crash...
The question
Is it possible to cache a video of 50-100MB on the Chromecast and prevent it from downloading it every time or is there a memory trick I could be doing to store that video in the Chromecast memory? Loading the video once per application use would be my target result to reduce bandwidth usage.
I'm a bit unsure about this answer because I find it a bit too obvious. But I'll give it a try:
You said you had no trouble with a setup where you download 28MB via ajax. Why don't you cut it down even further? You could for example go with 4MB. I'm suggesting this because it may alleviate problems arising from "bursts" of computation as you for example mentioned with reading the responseText field of the xhr object.
After you decided on an appropriate chunk size you could use https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-p5-range-22#section-3 to download your video in parts and then concatenate it in javascript according to your needs. See also Download file in chunks in Chrome Javascript API?
If you have access to the server you could also split the file on the server side such that you can send requests from the client like so:
example.com/movies/my_movie.mp4?chunk=1
Try using an Application Cache manifest file to ensure that the file is only downloaded once:
<html manifest="some.manifest">
where some.manifest has the contents:
CACHE MANIFEST
# version 1.0
the_video_to_cache.webm
This will ensure that future HTTP requests for the resource will not cause download. The video will only re-download when the manifest file changes (so you can change the #-prefixed comment string to cause a re-download). Note that the new version will be shown on first page load after the download completes. After an update, the user will see an out-of-date video one time (while the new version downloads) and then see the new version on the next visit.
Note that this may not work if your video is larger that the permitted size of the app cache.
I'm don't have chromecast, and not sure. Is it possible to use experimental features, like Quota Management API? This API, could add some extra memory for you stored data, may be you should try to use it.
This is a weird scenario I just experienced and I am not sure how to phrase the question.
It may be best to describe my application and what it does 1st.
I have an IP camera connected to my router.
I use a C# VLC wrapper to get 10 frames a second using a RTSP protocol.
I then upload to my web server using a [web method] these seperate jpegs to my server.
Then via browser using a javascript timer set to 100ms it renders the image into a HTML image control by calling an ashx page repteadly.
Now this has worked for a few days OK.
Now this is what I have experienced in the last 48hrs.
The images coming from the IP Camera was jumpy. That is to say sometimes the images flow in a timely order and sometimes it will slow down, stop and speed up again to 'catch up'.
I noticed when viewing via a web browser client on another PC on my network that the javascript timer calls were slow and sometimes stopped for periods of time. I used Google Chrome to view how often the ashx url was being called.
I closed down my own applications. Rebooted all my PCs and started VLC application without using the wrapper. Again, the flow was 'jumpy'. So the conclusion there was that it was not my application.
For some reason I decided to log into my router (192.168.0.1).
Page was not found.
In fact I had to do a complete restart of my router to be able to access my router 'page'.
As soon as I did this everything worked OK again.
So, the 2 questions I have is (1) why could I not access my router through that IP address and (2). Why was my javascript timer crashing to a stand-still?
Like I said this is a weird scenario and I would not blame anyone for wanting to close or vote down this question.
But on the off-chance this is a known thing I would like to be educated.
Thanks
Is there a way to make a video download in the background (Possible on a different thread?) than I get my images and do webrequests?
Situation:
I show a video, video plays fine.
But, once I start getting 2 images at the same time from that server, the page won't response and will wait for my video to have finished loading, then it loads the images within a few seconds. (about 100kb per image).
If I try to open any other page on the same browser and the crashed page's server it won't load untill the crashed page is done loading, however any other site(For example google) will just load fine.
So is there a way to make the browser not want to download full video, or maybe just give priority to images?
This sounds like the server throttling your requests, as everything apart from scripts always load asynchronously in a browser.
It might be that you are only allowed so much bandwidth per second from the server - or so many connections - and that could be the reason why the server won't respond until your first request has finished.
Check your server configuration and perhaps have a play with it to exclude this possibility.
Maybe you can try a worker, it provides a way to execute background scripts (you will have to split your video and images in separate files), as you can see in the Use Cases it refers to "Prefetching and/or caching data for later use" as a possible scenario. Hope it helps.
More info here:
http://www.html5rocks.com/en/tutorials/workers/basics/#toc-examples