summaryrefslogtreecommitdiffstats
path: root/chrome/renderer/media
Commit message (Collapse)AuthorAgeFilesLines
* Fix build bustage r24568hclam@chromium.org2009-08-271-0/+2
| | | | | | | | TBR=scherkus Review URL: http://codereview.chromium.org/173549 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@24570 0039d316-1c4b-4281-b951-d872f2087c98
* Make audio and video in sync while playback rate != 1.0hclam@chromium.org2009-08-271-0/+7
| | | | | | | | | | | | | | BUG=20290 TEST=play a video with rate 0.5, audio and video should be in sync This change use the playback rate as a scaling factor for delay introduced in the audio hardware buffer. After we scaled the amount of audio buffer not played, we'll be able to make audio / video in sync again. Review URL: http://codereview.chromium.org/174584 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@24568 0039d316-1c4b-4281-b951-d872f2087c98
* AudioRendererHost send ViewMsg_AudioStreamStatehclam@chromium.org2009-08-112-9/+8
| | | | | | | | | | | | | AudioRendererHost should use ViewMsg_AudioStreamState to notify renderer of its state instead of AudioOutputStream::State. The enum of AudioOutputStream::State is not used anywhere, thus removed. TEST=unit_tests --gtest_filter=Audio* Review URL: http://codereview.chromium.org/165255 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@23061 0039d316-1c4b-4281-b951-d872f2087c98
* Free demuxed audio packets if audio device failshclam@chromium.org2009-08-061-0/+1
| | | | | | | | | | | | | | | | BUG=17481 TEST=media_unittests Introduced a mesage broadcasting mechanism to notify filters of events from another filter. In particular this is used to notify all filters that the audio device has failed and special actions should be taken to handle it. In this case, demuxer should disable the audio stream and should free the demuxed audio packets instead of caching them. This will fix the memory leak that happens if audio device fails during playback. Review URL: http://codereview.chromium.org/159845 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@22630 0039d316-1c4b-4281-b951-d872f2087c98
* Replace the guts of AudioRendererBase with calls to scaling algorithm.kylep@chromium.org2009-08-012-13/+7
| | | | | | | | BUG=16011 TEST=audio_renderer_base_unittest.cc and buffer_queue_unittest.cc Review URL: http://codereview.chromium.org/155695 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@22237 0039d316-1c4b-4281-b951-d872f2087c98
* Fixes an audio playback regression caused by seeking in audio/video media.scherkus@chromium.org2009-07-291-1/+1
| | | | | | | | | | | This is a temporary fix to a much larger problem of dealing with Chrome's audio IPC layer. Since a seek is a small amount of time, we keep the audio IPC conversation going by writing 8k of zeros. Before we were telling the audio IPC layer that we were out of data, which technically was a lie (we were just seeking), and as a result the conversation died at that point. TEST=seek around in a video, audio should keep playing and remain in sync BUG=17917 Review URL: http://codereview.chromium.org/160283 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@21935 0039d316-1c4b-4281-b951-d872f2087c98
* Changes to provide asynchronous read in data source:hclam@chromium.org2009-07-222-992/+0
| | | | | | | | | | | | | 1. FFmpegGlue now taks a FFmpegProtocol instead of DataSource as input 2. FFmpegDemuxr implements FFmpegProtocol and does the blocking read and submit asynchronous read request to DataSource (with unit tests) 3. Changed SimpleDataSource to work with asynchronous read (with unit tests) 4. Reimplemented BufferedDataSource to work with asynchronous read (with unit tests) 5. Moved BufferedDataSource from chrome/renderer/media to webkit/glue/media (for faster build/debug and better coverage in automated testing) TEST=BufferedDataSourceTest.*, SimpleDataSourceTest.*, FFmpegDemuxerTest.* Review URL: http://codereview.chromium.org/149567 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@21326 0039d316-1c4b-4281-b951-d872f2087c98
* Ignore errors about creating audio output streamhclam@chromium.org2009-07-221-1/+5
| | | | | | | | | | | | | | | Instead of failing the media playback pipeline completely, this change will ignores all errors reported by the browser about audio output streams. This is the first step towards handling audio hardware errors. TEST=MediaTest.VideoBearTheora Review URL: http://codereview.chromium.org/159205 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@21318 0039d316-1c4b-4281-b951-d872f2087c98
* Renamed FilterHost::Error() and Pipeline::GetTime() to more appropriate names.scherkus@chromium.org2009-07-172-6/+6
| | | | | | | | | BUG=17107 TEST=none Review URL: http://codereview.chromium.org/155711 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@21013 0039d316-1c4b-4281-b951-d872f2087c98
* Adding callback support to media filter Initialize() and Seek().scherkus@chromium.org2009-07-162-14/+28
| | | | | | | | | | | | | Also includes unit tests for AudioRendererBase and VideoRendererBase. I had to rollback my first attempt at this change. Original review: http://codereview.chromium.org/155469 BUG=16014,16031 TEST=media_unittests, layout tests Review URL: http://codereview.chromium.org/155608 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@20836 0039d316-1c4b-4281-b951-d872f2087c98
* Made MediaFilter::host_ and MediaFilter::message_loop_ private.scherkus@chromium.org2009-07-092-9/+9
| | | | | | | | | | | More cleanup relating to pipeline cleanup. BUG=16008 TEST=no real code chage, nothing should change Review URL: http://codereview.chromium.org/155230 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@20338 0039d316-1c4b-4281-b951-d872f2087c98
* Revert "Made MediaFilter::host_ and MediaFilter::message_loop_ private."scherkus@chromium.org2009-07-092-9/+9
| | | | | | | | | | TEST=none BUG=none TBR=evmar Review URL: http://codereview.chromium.org/155333 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@20336 0039d316-1c4b-4281-b951-d872f2087c98
* Made MediaFilter::host_ and MediaFilter::message_loop_ private.scherkus@chromium.org2009-07-092-9/+9
| | | | git-svn-id: svn://svn.chromium.org/chrome/trunk/src@20335 0039d316-1c4b-4281-b951-d872f2087c98
* Refactorying to create the ResourceLoaderBridge through a factory class for ↵hclam@chromium.org2009-06-252-60/+47
| | | | | | | | | | | <video> Extract the code to create a ResourceLoaderBridge to a factory class to enable testing on the data source filters. Review URL: http://codereview.chromium.org/146007 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@19262 0039d316-1c4b-4281-b951-d872f2087c98
* Since the introduction of PushSource, there are two buffering layers in thehclam@chromium.org2009-06-162-14/+80
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | browser process, the hardware buffer used in AudioOutputStream and transportation buffer in PushSource. Together with the latency in the IPC audio layer we have a serious AV sync problem. To compensate the delay and latency introduced by these three factors two parameters are added in RequestAudioPacket message that include the buffer fill level and timestamp of the request. These two parameters are used to determine the playback delay to be used by the audio renderer to update the pipeline with the time delta. So we have three parameters we need to care about: 1. Hardware buffer in AudioOutputStream 2. Buffered data in PushSource 3. IPC latency We have accurate values for 2 and 3 but not 1. We currently don't have the API in AudioOutputStream to query the remaining buffer in the hardware buffer. But usually there is a large amount of data in it, e.g. on Windows 400ms worth of data. Since we now detached the hardware buffer request of OnMoreData() from the actual packet request of IPC (by the introduction of PushSource), it is really critical to know the buffer level in the hardware. I made a guess of this buffer level by using the amount of last buffer copy. Review URL: http://codereview.chromium.org/122020 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@18536 0039d316-1c4b-4281-b951-d872f2087c98
* Access RenderThread::current() only on render threadhclam@chromium.org2009-06-162-46/+77
| | | | | | | | | | Since the renfer to RenderThread is now stored in the thread local storage, we can only access RenderThread::current() from render thread. Change BufferedDataSource accordingly. Review URL: http://codereview.chromium.org/126183 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@18513 0039d316-1c4b-4281-b951-d872f2087c98
* Enable <video> in test_shellhclam@chromium.org2009-06-114-600/+0
| | | | | | | | | | | | | | | | | | | | | This is a work in progress draft. Summary of changes: 1. Moved code shared by chrome and test_shell to webkie/glue: WebMediaPlayerImpl SimpleDataSource VideoRendererImpl 2. Since WebMediaPlayerImpl is shared, chrome specific renderers are enabled by passing the FilterFactoryCollection into WebMediaPlayerImpl, this is done in RenderView. And WebMediaPlayerImpl provides some default renderer filters, which are used by the test shell and also chrome. Review URL: http://codereview.chromium.org/119229 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@18182 0039d316-1c4b-4281-b951-d872f2087c98
* Changed to use PushSource for the intermediate bufferhclam@chromium.org2009-06-052-27/+105
| | | | | | | | | | | | | | | between the IPC layer and the audio hardware interface. We have completely moved away from being blocking in AudioRendererHost. Since we'll be using PushSource for a longer period of buffering. It's necessary to have Play/Pause functionality in the AudioOutputStream, this is simulated by start/stop the AudioOutputStream multiple times. Review URL: http://codereview.chromium.org/114069 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@17707 0039d316-1c4b-4281-b951-d872f2087c98
* Reduce header dependencies in base/phajdan.jr@chromium.org2009-06-031-0/+1
| | | | | | | | Also adds more explicit #includes for needed things. Review URL: http://codereview.chromium.org/118162 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@17479 0039d316-1c4b-4281-b951-d872f2087c98
* Remove DataSourceImpl from chrome/renderer/mediahclam@chromium.org2009-05-282-538/+0
| | | | | | | | | | Since media in chrome renderer doesn't use file handle anymore, and these two files are deprecated, remove them from the tree. Review URL: http://codereview.chromium.org/115841 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@17046 0039d316-1c4b-4281-b951-d872f2087c98
* Chrome renderer support for YV16.fbarchard@chromium.org2009-05-271-11/+17
| | | | | | Review URL: http://codereview.chromium.org/113890 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@17016 0039d316-1c4b-4281-b951-d872f2087c98
* Fixing a long resource loading for small clipshclam@chromium.org2009-05-261-16/+18
| | | | | | | | | | | | The logic for resource loading for media file has a problem in determining the wait condition that it waited for one extra cycle (about ~5s) to know that the resource loading has completed, it is fixed in this patch. Also made clear about the logic in it. Review URL: http://codereview.chromium.org/113861 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@16935 0039d316-1c4b-4281-b951-d872f2087c98
* Introduce a buffer wait and timeout threshold for BufferedResourceLoaderhclam@chromium.org2009-05-222-175/+314
| | | | | | | | | | | | | | | | | | | | | The logic in the seek method of BufferedResourceLoader was that it will wait until the data is downloaded if we know that the desired seek position is within the bufferable range of the buffer, which is 10MB for now. This number is found to be too big and we should have another constant that governs the threshold of bytes that we should wait for forward seeking instead of starting a new request, this value is essentially much smaller than the buffer size, we guess this number to be 2MB. Also introduced the timeout logic to BufferedResourceLoader, so if BufferedResouceLoaderRead() takes more than a certain amount of time it is declared timeout and a new request should be started. The current timeout is set to 5s. Review URL: http://codereview.chromium.org/115627 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@16793 0039d316-1c4b-4281-b951-d872f2087c98
* BufferedDataSource uses media::SeekableBufferhclam@chromium.org2009-05-202-173/+119
| | | | | | | | | | | Use SeekableBuffer as internal cache for BufferedResourceLoader. By switch to SeekableBuffer that supports short seek within buffered data in both backward and forward direciton. The amount of range request is greatly reduced. Review URL: http://codereview.chromium.org/115453 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@16456 0039d316-1c4b-4281-b951-d872f2087c98
* Fix a misaligmnet in rendering video frameshclam@chromium.org2009-05-191-2/+2
| | | | | | | | Misalignment if clip top is odd. Review URL: http://codereview.chromium.org/115499 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@16358 0039d316-1c4b-4281-b951-d872f2087c98
* Fast paint for <video> by writing to SkCanvas directlyhclam@chromium.org2009-05-192-17/+193
| | | | | | | | | | | | | A direct path for rendering <video>, writes directly to bitmap in SkDevice in SkCanvas. There's several criteria for direct path: 1. No skew 2. SkDevice is ARGB8888 3. SkCanvas is opaque Review URL: http://codereview.chromium.org/115281 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@16350 0039d316-1c4b-4281-b951-d872f2087c98
* YUV with clipping.fbarchard@chromium.org2009-05-181-9/+10
| | | | | | | | | | | | All functions do 2 pixels at a time. 90 and 270 rotations implemented. YV16 refactored. YV12 code accepts a YuvType that allows the same code to support YV16 as well. Special case for half size removed. Special case for doubling added. 3.62 ms versus 8.62 for general purpose code. Review URL: http://codereview.chromium.org/113407 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@16334 0039d316-1c4b-4281-b951-d872f2087c98
* An adhoc fix for memory leak when playing a badly muxed video filehclam@chromium.org2009-05-172-9/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since the current data souce implementation for media resource loading assumes forward reading, when playing some badly muxed video files that has out-of-order read patterns a memory leak is observed. Here's the reason: 1. The video file has out-of-order read pattern 2. A lot of BufferedResourceLoader is created and destroyed to accomodate the seek requests that cannot be served by the buffer. 3. BufferedResourceLoader is not destroyed immediately when a new request is made, it is destroyed when the request has completed (triggered by cancelling the request). 4. Since request completion comes at a much lower rate than creation of BufferedResourceLoader, a lot of BufferedResourceLoader are remain alive and keep increasing, a leak is resulted. Adhoc solution: We can destroy all buffers in BufferedResourceLoader when it is called to stop. This can greatly reduce the leak amount. Although a lot of BufferedResourceLoader are still alive, they will be destroyed eventually (since a request completion is received due to cancelling of the request). A better solution would be to destroy the BufferedResourceLoader right away after it is stopped and fix the leak in ResourceDispatcher so we don't need to lengthen the lifetime of BufferedResourceLoader. CL for fixing ResourceDispatcher: http://codereview.chromium.org/115396 Review URL: http://codereview.chromium.org/115394 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@16262 0039d316-1c4b-4281-b951-d872f2087c98
* Shouldn't assume response code of 200 in SimpleDataSourcehclam@chromium.org2009-05-161-7/+12
| | | | | | | | | | | SimpleDataSource assumes the scheme is file or http and the response code is 200. We should just check if the response is successful using response.is_success() and verify the content_length, which will be -1 in case of unspecified length. Review URL: http://codereview.chromium.org/113422 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@16217 0039d316-1c4b-4281-b951-d872f2087c98
* A few quick fixes to SimpleDataSource.scherkus@chromium.org2009-05-142-12/+13
| | | | | | | | | Total bytes and buffered bytes weren't being set and a DCHECK was firing when loading files when it really shouldn't have. Review URL: http://codereview.chromium.org/113385 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@16092 0039d316-1c4b-4281-b951-d872f2087c98
* Change VideoRendererImpl to use VideoThread as opposed to VideoRendererBase.scherkus@chromium.org2009-05-142-17/+34
| | | | | | | | Now with less jitter! Review URL: http://codereview.chromium.org/115358 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@16087 0039d316-1c4b-4281-b951-d872f2087c98
* Move WebKit API to src/webkit/api.darin@chromium.org2009-05-101-1/+1
| | | | | | | | R=dglazkov Review URL: http://codereview.chromium.org/113186 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@15739 0039d316-1c4b-4281-b951-d872f2087c98
* Refactor media player to move away from webkit_gluehclam@chromium.org2009-05-075-37/+23
| | | | | | | | | | | | Highlights: 1. WebCore::MediaPlayerPrivate now only has one static method that constructs WebMediaPlayerClient 2. Implementation of WebCore::MediaPlayerPrivateInterface now is WebMediaPlayerClient 3. WebMediaPlayerClient does the delgation to WebMediaPlayer 4. Implemtnation of real media player will go into chrome/renderer and implements WebMediaPlayer Review URL: http://codereview.chromium.org/105007 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@15492 0039d316-1c4b-4281-b951-d872f2087c98
* Add --simple-data-source which uses simplified media resource loading.scherkus@chromium.org2009-05-062-0/+218
| | | | | | | | Comes in really handy for demo purposes and for testing playback performance with buffering and range requests removed from the equation. Review URL: http://codereview.chromium.org/109049 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@15354 0039d316-1c4b-4281-b951-d872f2087c98
* Fix a memory leak that happen on some video fileshclam@chromium.org2009-05-051-8/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The memory leak was introduced by BufferedDataSource, the cause of the leak: 1. Some video files have read patterns that BufferedResourceLoader cannot provide data buffer with, thus a large amount of BufferedResourceLoader is created and destroyed. 2. In the destruction of BufferedResourceLoader, it cancels the resource request and immediately deletes the ResourceLoaderBridge. 3. The request canceled in the renderer process isn't cancalled immediately in the browser process, at the mean time browser process still sends shared memory buffers to the renderer process. 4. When these shared memory buffers arrived at the renderer process, the ResourceLoaderBridge associated with the requst has already been destroyed, ResourceDispatcher can't find the associated ResourceLoaderBridge and simply delete the message. But the IPC message is not POD, it contains the handle to shared memory that should be closed. 5. End result is a lot of memory are shared to the renderer process but they are not closed. Solutions: 1. Delete ResourceLoaderBridge only at OnCompletedResponse. Delete ResourceLoaderBridge at OnCompletedResponse, it is guranteed that no more shared memory buffer will arrive after this point, so it's safe to delete ResourceLoaderBridge. The downside is the lifetime of BufferedResourceLoader is prolonged until OnCompletedResponse is received, which may never is received in case of timeout for certain protocol.. 2. Inside ResourceDispatcer, close the handles to shared memory even if ResourceLoaderBridge is not found. I'm going for route 1. The problem I mentioned in 2 also sounds like a bug in ResourceDispatcher, will talk to erickay or eroman to find a solution. Review URL: http://codereview.chromium.org/100302 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@15304 0039d316-1c4b-4281-b951-d872f2087c98
* Buffered data source that does range request to provide data to media pipelinehclam@chromium.org2009-04-292-0/+862
| | | | | | | | | | | | The implementation of buffered data source that uses buffered resource loader to download a media object and does buffering. This implementation knows when to do defer loading and when to restarts the loading. The implementation uses one buffered resource loading for one data source and does no connection recovery. Review URL: http://codereview.chromium.org/88047 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@14818 0039d316-1c4b-4281-b951-d872f2087c98
* Finished implementing seeking in WebMediaPlayerDelegateImpl.scherkus@chromium.org2009-04-291-0/+2
| | | | | | | | Turns out we need to add a few more things to the Pipeline interface for time update/seek completion callbacks, but for now this works pretty well. Review URL: http://codereview.chromium.org/100131 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@14810 0039d316-1c4b-4281-b951-d872f2087c98
* Prototype audio time shift.fbarchard@chromium.org2009-04-231-2/+2
| | | | | | Review URL: http://codereview.chromium.org/92007 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@14366 0039d316-1c4b-4281-b951-d872f2087c98
* Video and audio now pauses by playing NULL (0) PCM audio when the playback ↵ralphl@chromium.org2009-04-212-10/+15
| | | | | | | | | | | | rate is != 1.0. This is a non-optimal, but easy to implement interem solution. Correct fix is to actually stop audio playback, but that requires refactoring of components. Addede TODO's() where refactor needs to occur. Review URL: http://codereview.chromium.org/88014 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@14112 0039d316-1c4b-4281-b951-d872f2087c98
* Refactor DataSourceImpl to get rid of using ReleaseRendererResource for cleanuphclam@chromium.org2009-04-174-130/+125
| | | | | | | | | | | | | The previous model of waiting in Stop() was extremely bad, it created a lot of deadlocks and made cleanup harder. What should be the correct way of doing cleanup is that DataSourceImpl should signal it has stopped so no more activity in other threads, post a task on render thread to do final cleanup on that thread, if render thread is dying then it's simply leaked and don't care. This refactoring helped cleanup some ugly pattern in cleaning up. Review URL: http://codereview.chromium.org/77008 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@13984 0039d316-1c4b-4281-b951-d872f2087c98
* Handles audio messages on IO thread in render processhclam@chromium.org2009-04-162-119/+166
| | | | | | | | | | | | | | | | First step to have smoother audio playback. We previously performed audio messages handling on render thread, which gave us huge amount of latency, especially when renderer is busy compositing or is blocked by synchronous IPC call. A lot of these latencies are eliminated by moving audio messages handling to IO thread, this is the first step to see if sharing the regular IPC channel for audio messages is creating too much stress for the IPC channel. Also doubled the audio packet size to 8192 samples, ~194ms of audio for 16bit/44.1khz/2ch. Review URL: http://codereview.chromium.org/62125 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@13863 0039d316-1c4b-4281-b951-d872f2087c98
* Revert 12739, 12740, and 12741 because we're going to fix Issue 7448 purely ↵abarth@chromium.org2009-04-081-1/+0
| | | | | | in WebKit. git-svn-id: svn://svn.chromium.org/chrome/trunk/src@13343 0039d316-1c4b-4281-b951-d872f2087c98
* Adds new messages and widens some existing messages between the renderer and ↵michaeln@google.com2009-04-071-0/+5
| | | | | | | | browser processes to support an implementation of the HTML5AppCache spec with most of the logic running in the browser process. The gist of most of the changes are to indicate which frame each resource request is coming from, and to indicate which appcache each response was retrieved from (if any).See https://docs.google.com/a/google.com/Doc?docid=agv6ghfsqr_15f749cgt3&hl=en Review URL: http://codereview.chromium.org/9712 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@13258 0039d316-1c4b-4281-b951-d872f2087c98
* Detach media filters from WebMediaPlayerDelegateImplhclam@chromium.org2009-04-064-0/+11
| | | | | | | | | | | During stopping of the media pipeline in chrome, we need to detach the filters from WebMediaPlayerDelegateImpl so it doesn't hold renferences to the filters and filters can be destructed by the pipeline. Review URL: http://codereview.chromium.org/60113 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@13204 0039d316-1c4b-4281-b951-d872f2087c98
* Enable streaming in ffmpeg based on data sourcemedia::DataSource interface ↵hclam@chromium.org2009-03-302-2/+11
| | | | | | | | has IsSeekable() method to decideon runtime whether the data source is seekable or not. Thisinformation is provided to FFmpeg to decide whether to dostreaming or not. In the case of streaming, FFmpeg does notsupport seeking. Review URL: http://codereview.chromium.org/57015 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@12802 0039d316-1c4b-4281-b951-d872f2087c98
* Decoders now use standard callback mechanism for Reads. Removed ↵ralphl@chromium.org2009-03-302-6/+6
| | | | | | | | | Assignable<> template. Also includes an update that should provide more accurate timing from the audio renderer. Review URL: http://codereview.chromium.org/55031 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@12796 0039d316-1c4b-4281-b951-d872f2087c98
* Add the ability to specify a default MIME type when loading a resource. ↵abarth@chromium.org2009-03-281-0/+1
| | | | | | | | | | | | | We'll need this to correctly load stylesheets that lack a Content-Type header in standards mode. We're waiting on https://bugs.webkit.org/show_bug.cgi?id=24904 upstream before this works fully. This change, as it stands, is a no-op. R=wtc BUG=7448 Review URL: http://codereview.chromium.org/55049 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@12739 0039d316-1c4b-4281-b951-d872f2087c98
* Fixed a lot threading issues during tear down of <video>hclam@chromium.org2009-03-274-63/+65
| | | | | | | | | | | | | | | | | Fixed a lot of dead locks during tead down of <video> due to DataSourceImpl. Most of the issues come from that during a tab close RenderThread is destroyed and new tasks posted on it will not executed, but DataSourceImpl is waiting for those tasks to finish to complete stopping. Another dead lock comes from that when RenderThread is destroyed the owner loop of it (a IO Message Loop) is being destroyed too and DataSourceImpl shouldn't post tasks to that message loop when stopping. Review URL: http://codereview.chromium.org/42675 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@12720 0039d316-1c4b-4281-b951-d872f2087c98
* Lots of files touched for a very simple change. Everywhere we used a const ↵scherkus@chromium.org2009-03-264-23/+15
| | | | | | | | | | MediaFormat* we now use a const MediaFormat&. This makes for simpler code and for better pointer reference safety. Review URL: http://codereview.chromium.org/42635 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@12623 0039d316-1c4b-4281-b951-d872f2087c98
* TBR=ralphl, scherkushclam@chromium.org2009-03-261-3/+4
| | | | | | | | | VideoRendererImpl did an incorrect scaling matrix, resulting in no video image drawn. Review URL: http://codereview.chromium.org/42647 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@12566 0039d316-1c4b-4281-b951-d872f2087c98
generated by cgit v1.1 at 2025-02-28 21:47:29 +0000