Hi all, I'm thinking about making extension to URLRequest and underlying layers (URLRequestJob, URLRequesrHttpJob, HttpCache, HttpCache::HttpTransaction) to support for loading media files. Resource loading for media files is different from other resources because of the nature of media file containers and HTML5 spec. There's a few challenges:
1. Throttling for data rates (especially for streaming) 2. Being able to read from random positions within the stream 3. Having multiple ranges cached It seems to me that best place to solve the problem has do with URLRequest and underlying layers, the reasons being: 1. URLRequest is self contained, we can add the above features to URLRequest and build additional IPC interfaces to support them, media player within the renderer don't have to know details about the protocol or data source. The media player can change behavior only based on the capabilities of URLRequestJob. (The media player shouldn't know whether it is a URLRequestFileJob or URLRequestHttpJob backed by MemBackendImpl) 2. All the implementation of above features could stay in one place (URLRequest and underneath), the media player does have to implement any of it but just access it through common interface. 3. Fully featured URLRequest is reusable 4. With well defined interface, we can add more streaming protocols to URLRequest (like RTSP), it would be transparent to the media player, media player only knows the capabilities of the transport. What I think would be nice to have for URLRequest to support above features are the following methods: 1. void Seek(int position): seeking to position desired and read from that position 2. void ThrottleDownstreamRate(int rate): throttling downloading rate 3. vector<Range> QueryCachedRanges(): query list of cached ranges 4. bool CanReadFromFile(): whether we can read the response data from file directly, could minimize data transfer across IPC 5. base::PlatformFile GetResponseDataFile(): get the handle of the cache file containing response data. Alpha --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
