Thank you all for your response so far - clearly this is going to be a somewhat complicated answer (I didn't believe that it wouldn't) ;-)
3/ - yes, my (and somewhat 'our') hypothesis is that because chunk requests are made through the host browser, they will be restricted as any other internet content is - for example, requesting a web page, then all the assets from the HTML response, is clearly managed by limiting the number of concurrent 'threads' (I may obviously be using the wrong words here) to some sort of rule for 'same domain'. If we had more than one player in the browser instance (maybe on multiple tabs/windows) all requesting chunks from the same domain, but different 'channels' (ie. different streams), then they will likely 'fight' each other for spare slots in the concurrent 'threads'. We're not sure how much of an 'edge case' that is - though I can believe some of our viewers/listeners having a couple of windows open during big events (like the Olympics in London coming soon) with HDS playback in Flash. I have supplied an example of HDS through Flash which is live on our site at the moment. This may help you see how it's working in the real world. I've already poked around to see what happens to the chunks. In RTMP communication, or where NetConnect (or similar) is being used directly inside the Flash Player container - Flash handles that communication. But for HDS it throws the HTTP request up to the host browser. This is what sees to happen. On 18 May 2012 02:05, Steve Workman <[email protected]> wrote: > Hi Alan, > > (I'm cross posting to dev-media to get some insight on the media cache - > media folks, this email is with respect to Flash/HDS, and I don't think it > uses the media cache - please confirm. > > And Patrick, I'm bouncing it back to you for the resource-sharing question > about parallel chunk requests :) I'm not 100% on the details, so I'm going > to spend some time on that, but in the meantime, you might be able to give > Alan a quicker response than me. > > And Nick and Michal, please take a look over the disk cache question). > > On May 17, 2012, at 6:31 AM, Patrick McManus wrote: > > Maybe steve can give a little insight here. He's been working on a DASH > implementation. > > > As Patrick wrote, I'm working on DASH/WebM for Firefox, so I'll comment as > best I can from that context, but there may be differences with how Flash > works. Also, for some of these things I'm learning as well, so forgive me > for forwarding you to other folks for specific details. > > On May 13, 2012, at 5:20 PM, AlanO wrote: > > I'm working with the HDS streaming technologies, within the Adobe > Flash world, and I'm trying to compile a set if 'FAQs' about each main > browser available to consumers and how it will react to the 'chunks' > being delivered via the HTTP stack. > > My current understanding on Firefox is that, although the Adobe Flash > plugin handles presentation of the video, the chunks are requested via > the host browser's network stack. Resulting in an HTTP request for a > chunk (aka 'fragment'). > > A couple of things have struck me about this: > > 1/ What is the default setting in Firefox for the Cache? Is it RAM > then Disk. Is this flow described anywhere? > > > One of our cache experts, Nick, has told me that the resources are cached > in both RAM and disk by default. > > Nick, Michal, is there a flow described somewhere for the cache that Alan > could look at? Do you know how plugins like Flash use the cache? Is there a > difference? > > > 2/ How is garbage collection instigated - the latest Firefox has an > option suggesting that, by default, there is an automatic garbage > collection which must use some rules... perhaps about disk space? For > example: in Google Chrome, the default cache can take up huge amounts > of disk space growing without some sort of size limit it seems, plus > you can only change the cache settings on the CLI of Chrome (no > 'consumer' level configuration in the 'preferences' dialogs). > > > I'll let Nick and Michal comment on garbage collection for regular cache > objects. We also have a media cache, which the guys on dev-media have a > better understanding since they wrote it, but I don't think it's used for > Flash, only for built-in decoders. > > > 3/ What are the methods employed when multiple chunks are requested - > as with loading a web page, there is some 'pipeline' going on in the > network stack. Perhaps limiting the total number of working threads > for 'same domain' requests - this could impact on HDS chunks. Consider > where more than one HDS stream is present in a users browser (e.g. > multiple tabs/windows with an HDS stream) - if chunks are served from > the same FQDN, would there be a 'fight' due to slots within the worker > threads in the network stack? > > > Chunks as a concept is something on my todo-list-to-think-about for DASH, > albeit to examine the effect of different chunk sizes on TCP window size > and thus bandwidth usage, which is, of course, a different issue. > > So, to make sure I understand your question, you're asking if there could > be a fight for resources if there were two or more media presentations > grabbing files/chunks from the same FQDN. Assuming that's right, I'm going > to look into it and get back to you, because I'm not 100% sure. I have a > notion that it depends on what protocol you're using (HTTP, maybe with > pipelining, or SPDY) and the number of parallel TCP connections available. > As far as the number of threads or other resources we have in Firefox, I'm > not sure of those details. > > In the meantime, Patrick may actually have a better idea about the inner > workings - sorry to bounce it back, Patrick :) > > > Although I mention HDS here, this would likely go for any other > chunked streaming methods (MPEG-DASH, HLS) which may have a client > implemented inside a browser host. > > > For sure, so it's useful discussion to have all round. > > > I hope that someone in your team could assist me with these queries. > > Alan > _______________________________________________ > dev-tech-network mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-tech-network > > > _______________________________________________ dev-media mailing list [email protected] https://lists.mozilla.org/listinfo/dev-media
