summaryrefslogtreecommitdiffstats
path: root/media/media.gyp
Commit message (Collapse)AuthorAgeFilesLines
* Revert 177842. This doesn't build in standalone webkit builds:thakis@chromium.org2013-01-211-16/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | https://bugs.webkit.org/show_bug.cgi?id=107468 It looks like the exact same problem happened when this landed the last time: https://bugs.webkit.org/show_bug.cgi?id=105813 Please make sure this issue is fixed before you reland. The CL also likely regressed binary size by 0.25MB: http://crbug.com/171143 > Add wrapper class to media for support of VP9 video, and add a command line flag to enable the support. > > This initial version of the wrapper provides support for decoding VP9 video in WebM container files, and is disabled by default. > > New flag added: --enable-vp9-playback > > TBR=brettw,scherkus,xhwang > BUG=166094 > TEST=VP9 video in WebM containers plays back in <video> elements when --enable-vp9-playback is specified on the command line. > > > Review URL: https://chromiumcodereview.appspot.com/12025030 TBR=tomfinegan@chromium.org Review URL: https://codereview.chromium.org/11953017 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@177953 0039d316-1c4b-4281-b951-d872f2087c98
* Add wrapper class to media for support of VP9 video, and add a command line ↵tomfinegan@chromium.org2013-01-191-0/+16
| | | | | | | | | | | | | | | | | flag to enable the support. This initial version of the wrapper provides support for decoding VP9 video in WebM container files, and is disabled by default. New flag added: --enable-vp9-playback TBR=brettw,scherkus,xhwang BUG=166094 TEST=VP9 video in WebM containers plays back in <video> elements when --enable-vp9-playback is specified on the command line. Review URL: https://chromiumcodereview.appspot.com/12025030 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@177842 0039d316-1c4b-4281-b951-d872f2087c98
* Eliminate media::Buffer as a base class for media::DecoderBuffer and ↵scherkus@chromium.org2013-01-151-2/+0
| | | | | | | | | | | | | | | media::DataBuffer. It was never a good idea in the first place. Our usage is exclusively with DecoderBuffers or DataBuffers. There's never a case where we benefit from using Buffer as a base class aside from hiding GetWriteableData(), however it's not a compelling enough reason to keep Buffer around. BUG=169614 TBR=dmichael Review URL: https://codereview.chromium.org/11880008 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@176956 0039d316-1c4b-4281-b951-d872f2087c98
* Improve thread safety for device changes on OSX.dalecurtis@google.com2013-01-111-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Device changes are hard, lets go shopping! Sadly OSX does not handle property listener callbacks in a thread safe manner. On 10.6 we can set kAudioHardwarePropertyRunLoop to account for this. On 10.7 this is broken and we need to create a dispatch queue to drive callbacks. However code running on the dispatch queue must be mutually exclusive with code running on the audio thread. ExclusiveDispatchQueueTaskObserver works around this by pausing and resuming the dispatch queue before and after each pumped task. Benchmarks on my retina 10.8.2 macbook pro show on average this takes < 30us in total. No performance issues were seen even using FakeAudioOutputStream which drives audio callbacks on the message loop. Complicating matters it the fact that the AudioProperty(Add|Remove)ListenerBlock functions are not available on 10.6... so we need to dynamically load them :-/ This is not ideal and long term we should replace the audio thread on OSX with a dispatch queue to avoid having to suspend/resume the queue; this is non-trivial and requires a significant refactoring of the AudioManager to support. BUG=158170 TEST=media_unittests. manual device changes. Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=176228 Review URL: https://codereview.chromium.org/11824018 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@176474 0039d316-1c4b-4281-b951-d872f2087c98
* Tab Audio Mirroring/Capture: Browser-side connect/disconnect functionality:miu@chromium.org2013-01-111-0/+1
| | | | | | | | | | | | | | | | | | | | | | 1. Added new AudioMirroringManager to dynamically match/route "divertable" audio streams with mirroring destinations. 2. Modified AudioOutputController to provide "divert audio data" functionality. 3. Modified AudioRendererHost to notify AudioMirroringManager of all audio streams. The intention is, in a later change, to introduce a "WebContentsAudioInputStream" which will implement the AudioMirroringManager::MirroringDestination interface introduced in this change. WCAIS will represent the lifetime of a tab audio mirroring session, calling AudioMirroringManager::Start/StopMirroring() as appropriate. Testing: 1. Rewrote most of unit testing for AudioOutputController, addressing bug 112500. Also added testing for the new Divert functionality. 2. Added extensive unit testing for the new Start/StopMirroring functionality in AudioMirroringManager. 3. Minor testing clean-ups/additions elsewhere. BUG=153392,112500 TEST=Run media_unittests and content_unittests. Review URL: https://chromiumcodereview.appspot.com/11413078 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@176295 0039d316-1c4b-4281-b951-d872f2087c98
* Revert 176228dalecurtis@google.com2013-01-111-3/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | > Improve thread safety for device changes on OSX. > > Device changes are hard, lets go shopping! Sadly OSX does not handle property > listener callbacks in a thread safe manner. On 10.6 we can set > kAudioHardwarePropertyRunLoop to account for this. On 10.7 this is broken > and we need to create a dispatch queue to drive callbacks. However code > running on the dispatch queue must be mutually exclusive with code running > on the audio thread. > > ExclusiveDispatchQueueTaskObserver works around this by pausing and resuming > the dispatch queue before and after each pumped task. Benchmarks on my retina > 10.8.2 macbook pro show on average this takes < 30us in total. No performance > issues were seen even using FakeAudioOutputStream which drives audio callbacks > on the message loop. > > Complicating matters it the fact that the AudioProperty(Add|Remove)ListenerBlock > functions are not available on 10.6... so we need to dynamically load them :-/ > > This is not ideal and long term we should replace the audio thread on OSX with a > dispatch queue to avoid having to suspend/resume the queue; this is non-trivial > and requires a significant refactoring of the AudioManager to support. > > BUG=158170 > TEST=media_unittests. manual device changes. > > Review URL: https://codereview.chromium.org/11824018 Fails on 10.6 :( TBR=dalecurtis@google.com Review URL: https://codereview.chromium.org/11840005 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@176230 0039d316-1c4b-4281-b951-d872f2087c98
* Improve thread safety for device changes on OSX.dalecurtis@google.com2013-01-111-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Device changes are hard, lets go shopping! Sadly OSX does not handle property listener callbacks in a thread safe manner. On 10.6 we can set kAudioHardwarePropertyRunLoop to account for this. On 10.7 this is broken and we need to create a dispatch queue to drive callbacks. However code running on the dispatch queue must be mutually exclusive with code running on the audio thread. ExclusiveDispatchQueueTaskObserver works around this by pausing and resuming the dispatch queue before and after each pumped task. Benchmarks on my retina 10.8.2 macbook pro show on average this takes < 30us in total. No performance issues were seen even using FakeAudioOutputStream which drives audio callbacks on the message loop. Complicating matters it the fact that the AudioProperty(Add|Remove)ListenerBlock functions are not available on 10.6... so we need to dynamically load them :-/ This is not ideal and long term we should replace the audio thread on OSX with a dispatch queue to avoid having to suspend/resume the queue; this is non-trivial and requires a significant refactoring of the AudioManager to support. BUG=158170 TEST=media_unittests. manual device changes. Review URL: https://codereview.chromium.org/11824018 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@176228 0039d316-1c4b-4281-b951-d872f2087c98
* Vanquish the remnants of media::MessageLoopFactory.scherkus@chromium.org2013-01-021-2/+0
| | | | | | | | | | | | Now that media code runs on a single thread we no longer need to worry about creating additional threads at runtime. To make changes like this easier in the future, webkit_media::WebMediaPlayerParams is introduced to avoid plumbing parameters through Chrome's various abstraction layers. BUG=116873 Review URL: https://codereview.chromium.org/11468033 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@174808 0039d316-1c4b-4281-b951-d872f2087c98
* Revert "Add wrapper class to media for support of VP9 video, and add a ↵fsamuel@chromium.org2012-12-281-16/+0
| | | | | | | | | | | | | | | | | | command line flag to enable the support." This reverts commit e17c547493001b9195e1209b9444d2aee676c826. This is preventing updating the Chromium DEPS file in the WebKit repo. See here for details on the WebKit issue: https://bugs.webkit.org/show_bug.cgi?id=105813 The original patch: https://codereview.chromium.org/11644078 TBR=tomfinegan@chromium.org Review URL: https://chromiumcodereview.appspot.com/11700002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@174739 0039d316-1c4b-4281-b951-d872f2087c98
* Encrypted Media: Replace DecryptorClient with key event callbacks.xhwang@chromium.org2012-12-221-1/+0
| | | | | | | | | | | - Removed DecryptorClient and use key event callbacks. - Renamed Decryptor::KeyAddedCB to Decryptor::NewKeyCB. - ProxyDecryptor implements key event callbacks and WebMediaPlayerProxy does not handle key events anymore. - PpapiDecryptor implements key event callbacks as well so ContentDecryptorDelegate doesn't call ProxyDecryptor directly. Review URL: https://codereview.chromium.org/11226019 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@174495 0039d316-1c4b-4281-b951-d872f2087c98
* Add wrapper class to media for support of VP9 video, and add a command line ↵tomfinegan@chromium.org2012-12-221-0/+16
| | | | | | | | | | | | | | | | flag to enable the support. This initial version of the wrapper provides support for decoding VP9 video in WebM container files, and is disabled by default. New flag added: --enable-vp9-playback TBR=brettw,scherkus,xhwang BUG=166094 TEST=VP9 video in WebM containers plays back in <video> elements when --enable-vp9-playback is specified on the command line. Review URL: https://codereview.chromium.org/11644078 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@174488 0039d316-1c4b-4281-b951-d872f2087c98
* Revert 174311kinaba@chromium.org2012-12-211-16/+0
| | | | | | | | | | | | | | | | | | | | | | | Windows build is failing around libvpx after this patch: http://build.chromium.org/p/chromium/builders/Win/builds/14332 [1220/203018 : error : decomposer.cc(2186)] Block collision for function at 46813200(1536) with ..\..\build\Release\obj\global_intermediate\third_party\libvpx\vp9_subpixel_mmx.obj > Add wrapper class to media for support of VP9 video, and add a command line flag to enable the support. > > This initial version of the wrapper provides support for decoding VP9 video in WebM container files, and is disabled by default. > > New flag added: --enable-vp9-playback > > BUG=166094 > TEST=VP9 video in WebM containers plays back in <video> elements when --enable-vp9-playback is specified on the command line. > > > Review URL: https://chromiumcodereview.appspot.com/11468018 TBR=tomfinegan@chromium.org Review URL: https://codereview.chromium.org/11578046 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@174346 0039d316-1c4b-4281-b951-d872f2087c98
* Add wrapper class to media for support of VP9 video, and add a command line ↵tomfinegan@chromium.org2012-12-211-0/+16
| | | | | | | | | | | | | | | | flag to enable the support. This initial version of the wrapper provides support for decoding VP9 video in WebM container files, and is disabled by default. New flag added: --enable-vp9-playback BUG=166094 TEST=VP9 video in WebM containers plays back in <video> elements when --enable-vp9-playback is specified on the command line. Review URL: https://chromiumcodereview.appspot.com/11468018 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@174311 0039d316-1c4b-4281-b951-d872f2087c98
* Create a utility for audio initialization.milanb@chromium.org2012-12-191-4/+7
| | | | | | | | | | | | | The audio initialization on ios can happen on both UI and IO threads. Creating an audio session utility that prevents a potential race condition. R=scherkus@chromium.org BUG=None Review URL: https://chromiumcodereview.appspot.com/11505005 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@173816 0039d316-1c4b-4281-b951-d872f2087c98
* Add wrapper class to media for support of Opus audio, and add a command line ↵tomfinegan@chromium.org2012-12-181-0/+3
| | | | | | | | | | | | | | | flag to enable the support. This initial version of the wrapper provides support for decoding Opus audio in WebM container files, and is disabled by default. New flag added: --enable-opus-playback BUG=166094 TEST=Opus audio in WebM containers plays back in <video> elements when --enable-opus-playback is specified on the command line. Review URL: https://codereview.chromium.org/11416367 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@173663 0039d316-1c4b-4281-b951-d872f2087c98
* Encrypted Media: Refactor Video Decrypt-Only to use DecryptingDemuxerStream.xhwang@chromium.org2012-12-171-0/+3
| | | | | | | | | | | | | | | | | - Add VideoDecoderSelector to facilitate VideoDecoder initialization/selection. - Add VideoDecoderSelectorTest. - Remove DecryptingVideoDecoder from default decoder list. - Disable decryption in FFmpegVideoDecoder. - Updated all unittests. After this CL, FFmpegVideoDecoder and ProxyDecryptor need to be cleaned. BUG=141786 TEST=all tests pass; EME demos work. Review URL: https://codereview.chromium.org/11573047 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@173562 0039d316-1c4b-4281-b951-d872f2087c98
* Encrypted Media: Support Audio Decrypt-Only.xhwang@chromium.org2012-12-141-0/+3
| | | | | | | | | | | | | | - Add AudioDecoderSelector to facilitate AudioDecoder selection. - Add AudioDecoderSelectorTest. - Update key_system.cc to support audio in clearkey key system. - Update content_browsertests to test audio decrypt-only. BUG=123421 TEST=both decrypt-only and decrypt-and-decode works for audio! Review URL: https://codereview.chromium.org/11492003 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@173235 0039d316-1c4b-4281-b951-d872f2087c98
* Introduce time-based caching of encoded data to FFmpegDemuxer (round 2).scherkus@chromium.org2012-12-071-0/+3
| | | | | | | | | | The original commit r169004 introduce seek regressions on constrained network connections. For now we'll limit the number of asynchronous pending reads to one. While it limits throughput it shouldn't be a big factor during normal playback. BUG=160640 Review URL: https://codereview.chromium.org/11308145 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@171883 0039d316-1c4b-4281-b951-d872f2087c98
* Add AudioFileReader unittest.dalecurtis@chromium.org2012-12-071-0/+2
| | | | | | | | | | | | | Adds a unittest for WebAudio's AudioFileReader. The test runs through all supported Chrome audio codecs and performs a hash check. BUG=none TEST=unittest passes. Review URL: https://chromiumcodereview.appspot.com/11441003 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@171651 0039d316-1c4b-4281-b951-d872f2087c98
* Replace WaitableEvents and ConditionalVariables in VideoRendererBase tests ↵scherkus@chromium.org2012-12-061-2/+2
| | | | | | | | with MessageLoop. Review URL: https://chromiumcodereview.appspot.com/11316293 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@171438 0039d316-1c4b-4281-b951-d872f2087c98
* Add support for audio config changes.acolwell@chromium.org2012-12-051-0/+6
| | | | | | | | BUG=151046 Review URL: https://codereview.chromium.org/11419174 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@171249 0039d316-1c4b-4281-b951-d872f2087c98
* Re-land https://codereview.chromium.org/11419200/tommi@chromium.org2012-12-051-0/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | I had to revert the change since media and content unittests failed to load on the XP and Vista bots. This modification to the above CL moves the MF delayload entries the chrome_dll.gyp over to media.gyp for all dependents and doesn't use MF on Vista since it turns out that a special update is required (and our Vista bots don't have). Original CL description: Video capture implementation using the Media Foundation API. This replaces the DirectShow based implementation for Vista,Win7 and Win8. DirectShow isn't supported in metro mode so once we've landed this, we can revert the workaround we have in place for Win8. The CapabilityList class is mostly moved code from the DS implementation. The difference is that I'm not using a std::map<> since that wasn't really necessary and instead adding one member (via inheritance) to the capability struct on Windows that holds the stream id that is needed. BUG=140545 TEST=All video capture tests in media_unittests now test this new implementation (except on XP). TBR=mflodman@chromium.org,darin@chromium.org Review URL: https://codereview.chromium.org/11451010 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@171232 0039d316-1c4b-4281-b951-d872f2087c98
* Revert 171212tommi@chromium.org2012-12-051-34/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Broke on Vista: http://chromesshgw.corp.google.com/i/chromium.win/builders/Vista%20Tests%20%281%29/builds/31733/steps/media_unittests/logs/stdio > Re-land https://codereview.chromium.org/11419200/ > I had to revert the change since media and content unittests failed to load on the XP bots. > This modification to the above CL moves the MF delayload entries the chrome_dll.gyp over to media.gyp for all dependents. > > Original CL description: > > Video capture implementation using the Media Foundation API. > This replaces the DirectShow based implementation for Vista,Win7 and Win8. > DirectShow isn't supported in metro mode so once we've landed this, > we can revert the workaround we have in place for Win8. > > The CapabilityList class is mostly moved code from the DS implementation. > The difference is that I'm not using a std::map<> since that wasn't > really necessary and instead adding one member (via inheritance) to > the capability struct on Windows that holds the stream id that is needed. > > BUG=140545 > TEST=All video capture tests in media_unittests now test this new implementation (except on XP). > > TBR=mflodman@chromium.org,darin@chromium.org > > Review URL: https://codereview.chromium.org/11442011 TBR=tommi@chromium.org Review URL: https://codereview.chromium.org/11443011 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@171220 0039d316-1c4b-4281-b951-d872f2087c98
* Re-land https://codereview.chromium.org/11419200/tommi@chromium.org2012-12-051-0/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | I had to revert the change since media and content unittests failed to load on the XP bots. This modification to the above CL moves the MF delayload entries the chrome_dll.gyp over to media.gyp for all dependents. Original CL description: Video capture implementation using the Media Foundation API. This replaces the DirectShow based implementation for Vista,Win7 and Win8. DirectShow isn't supported in metro mode so once we've landed this, we can revert the workaround we have in place for Win8. The CapabilityList class is mostly moved code from the DS implementation. The difference is that I'm not using a std::map<> since that wasn't really necessary and instead adding one member (via inheritance) to the capability struct on Windows that holds the stream id that is needed. BUG=140545 TEST=All video capture tests in media_unittests now test this new implementation (except on XP). TBR=mflodman@chromium.org,darin@chromium.org Review URL: https://codereview.chromium.org/11442011 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@171212 0039d316-1c4b-4281-b951-d872f2087c98
* Revert 170912 - need more delayloads.tommi@chromium.org2012-12-041-21/+0
| | | | | | | | | | | | | | | | | | | | | | > Video capture implementation using the Media Foundation API. > This replaces the DirectShow based implementation for Vista,Win7 and Win8. > DirectShow isn't supported in metro mode so once we've landed this, > we can revert the workaround we have in place for Win8. > > The CapabilityList class is mostly moved code from the DS implementation. > The difference is that I'm not using a std::map<> since that wasn't > really necessary and instead adding one member (via inheritance) to > the capability struct on Windows that holds the stream id that is needed. > > BUG=140545 > TEST=All video capture tests in media_unittests now test this new implementation (except on XP). > > Review URL: https://codereview.chromium.org/11419200 TBR=tommi@chromium.org Review URL: https://codereview.chromium.org/11418307 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@170925 0039d316-1c4b-4281-b951-d872f2087c98
* Video capture implementation using the Media Foundation API.tommi@chromium.org2012-12-041-0/+21
| | | | | | | | | | | | | | | | | | This replaces the DirectShow based implementation for Vista,Win7 and Win8. DirectShow isn't supported in metro mode so once we've landed this, we can revert the workaround we have in place for Win8. The CapabilityList class is mostly moved code from the DS implementation. The difference is that I'm not using a std::map<> since that wasn't really necessary and instead adding one member (via inheritance) to the capability struct on Windows that holds the stream id that is needed. BUG=140545 TEST=All video capture tests in media_unittests now test this new implementation (except on XP). Review URL: https://codereview.chromium.org/11419200 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@170912 0039d316-1c4b-4281-b951-d872f2087c98
* Goal: Provide browser-wide audio mirroring for the TabCapture API.justinlin@chromium.org2012-12-041-0/+6
| | | | | | | | | | | | | | | | | | This CL introduces VirtualAudio{Input,Output}Streams to handle redirecting audio output from Chrome into a virtual input stream to be used as "fake" microphone input. That stream could then be used through WebRTC peer connection, essentially playing back audio from the browser remotely. Limitations: Currently, only one VirtualAudioInputStream is supported, so we can only capture browser-wide audio once. Subsequent requests for audio through the TabCapture API will result in no audio for that stream. Overview: When a VirtualAudioInputStream is created (which is triggered by the Chrome TabCapture API), we trigger a device change event which will cause all currently active output streams to be recreated as VirtualAudioOutputStreams. These will attach to the virtual input stream when they start/resume playback. When the VirtualAudioInputStream is to be released, it triggers another device change event to revert all the output streams back to output to sound hardware. The VirtualAudioOutputStreams must detach from the VirtualAudioInputStream when they are stopped, thus VirtualAudioInputStream must outlive all VirtualAudioOutputStreams. BUG=153392 Review URL: https://chromiumcodereview.appspot.com/11298006 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@170892 0039d316-1c4b-4281-b951-d872f2087c98
* Delete media/tools/player_wtl.scherkus@chromium.org2012-11-281-38/+0
| | | | | | | We don't use it and it's a constant source of compile failures. Review URL: https://codereview.chromium.org/11414209 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@170073 0039d316-1c4b-4281-b951-d872f2087c98
* Remove MessageLoopProxy-getting callbacks from various media classes.scherkus@chromium.org2012-11-281-1/+0
| | | | | | | | | | | Now that the pipeline and decoder threads are combined we can guarantee that a thread exists at construction time. BUG=116873 TBR=jamesr Review URL: https://codereview.chromium.org/11411110 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@170054 0039d316-1c4b-4281-b951-d872f2087c98
* Revert 169004 - Introduce time-based caching of encoded data to FFmpegDemuxer.scherkus@chromium.org2012-11-211-3/+0
| | | | | | | | | | Seeking performance on slow connections regressed too much for my liking: http://build.chromium.org/f/chromium/perf/linux-release/media_tests_av_perf/report.html?history=50&rev=169043&graph=seek BUG=160640 Review URL: https://codereview.chromium.org/11316138 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@169076 0039d316-1c4b-4281-b951-d872f2087c98
* Introduce time-based caching of encoded data to FFmpegDemuxer.scherkus@chromium.org2012-11-211-0/+3
| | | | | | | | | | | | | | | | | | | | | Previously demuxing was done when a decoder required data. Now that demuxing is performed asynchronously on a separate thread there's a greater risk of not delivering data in time. The solution is to cache a minimum amount of encoded data per FFmpegDemuxerStream. After collapsing the decoding and pipeline threads together, FFmpegDemuxerStreams will be able to deliver encoded data to decoders without hopping threads. Running demuxer_bench reports a ~2-3x improvement. Still not as fast as the original code pre-r168350, but significantly better. Benchmarking method: # Run once to warm up IO. $ ./out/Release/demuxer_bench $FILE # Take average of 20 runs. $ for i in $(seq 1 20); do ./out/Release/demuxer_bench $FILE; done | awk '/Time:/ { count = count + 1; sum = sum + $2 } END { print (sum / count) }' BUG=160640 Review URL: https://codereview.chromium.org/11418022 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@169004 0039d316-1c4b-4281-b951-d872f2087c98
* Collapse AudioRendererMixer and OnMoreDataResampler into AudioTransform.dalecurtis@chromium.org2012-11-211-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently we have roughly equivalent functionality in two places, and the CloudView project will add a third. As such there's a need for a single super class which can handle mixing, resampling, and general conversion from one set of AudioParameters to another. This change introduces the AudioTransform object which collapses the key functionality from AudioRendererMixer and OnMoreDataResampler into a single AudioTransform class which can do everything and is oblivious to the peculiars of RenderCallback vs AudioSourceCallback. It also introduces output_frames_ready() methods to the AudioPullFifo and MultiChannelResampler classes so that buffer delay can be measured accurately without resorting to input vs output byte counting. Due to the bulk of AudioRendererMixer's functionality moving into the new AudioTransform, it made sense to move some decisions into the AudioRendererMixerInput class as well. On my Z600, benchmarking 50000 iterations: Convert() w/ FIFO took 7030.11ms. Convert() w/o FIFO took 5218.83ms. BUG=none TEST=AudioTransform* unittests. TBR=sergeyu Review URL: https://chromiumcodereview.appspot.com/11410012 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@168976 0039d316-1c4b-4281-b951-d872f2087c98
* Check in demuxer_bench, a tool for benchmarking FFmpegDemuxer reading.scherkus@chromium.org2012-11-171-0/+11
| | | | | | | | | | Seeing as I'm making substantial changes to how we demux, it would be prudent to benchmark any differences in performance. BUG=160640 Review URL: https://codereview.chromium.org/11412016 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@168353 0039d316-1c4b-4281-b951-d872f2087c98
* Break down the webrtc code and AudioInputDevice into a WebRtcAudioCapturer.xians@chromium.org2012-11-161-0/+2
| | | | | | | | | | | | | | | | | | | | | This capturer contains a source (AudioInputDevice) and a sink (WebRtcAudioDeviceImpl) by default. What it does is to get data from AudioInputDevice via CaptureCallback::Capture() callback, and forward the data to WebRtcAudioDeviceImpl. The source can be over written by API: SetCapturerSource(media::AudioCapturerSource* source) This capture currently only support one sink (WebRtcAudioDeviceImpl), but this can be extended to multiple sinks for the future. Design doc: https://docs.google.com/a/google.com/document/d/1FmiXtk1pxFlAw_CWwbfG-EQ4Syi4vpnZm6GWMyJ1UfU/edit TBR=tommi@chromium.org BUG=157306 TEST=manual test Review URL: https://codereview.chromium.org/11366244 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@168242 0039d316-1c4b-4281-b951-d872f2087c98
* Add DecryptingDemuxerStream.xhwang@chromium.org2012-11-151-0/+3
| | | | | | | | | | | DecryptingDemuxerStream transforms an encrypted demuxer stream into a clear demuxer stream with the same stream type (audio/video) and codec config. It may be blocking because it relies on a Decryptor for decryption. Thus other than implementing the DemuxerStream interface, it also exposes a Reset() methods so that caller can cancel the decryption operation. BUG=123421,141786 TEST=media_unittests pass Review URL: https://chromiumcodereview.appspot.com/11342031 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@167852 0039d316-1c4b-4281-b951-d872f2087c98
* Refactor FFmpegURLProtocol code from FFmpegDemuxer into BlockingUrlProtocol.scherkus@chromium.org2012-11-131-0/+6
| | | | | | | | | | | I cleaned up some comments and surrounding test code in FFmpegDemuxer and FileDataSource as well. There'll be some more clean up after I get this landed. BUG=160640 TEST=FFmpegDemuxer and BlockingUrlProtocol tests Review URL: https://codereview.chromium.org/11410052 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@167462 0039d316-1c4b-4281-b951-d872f2087c98
* Revert 167387 - Break down the webrtc code and AudioInputDevice into a ↵wez@chromium.org2012-11-131-2/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | WebRtcAudioCapturer. This CL failed the TabCapture browser-test on the win_rel try-bot, and caused it to fail on Mac & Windows on the build-bots. BUG=160782 This capturer contains a source (AudioInputDevice) and a sink (WebRtcAudioDeviceImpl) by default. What it does is to get data from AudioInputDevice via CaptureCallback::Capture() callback, and forward the data to WebRtcAudioDeviceImpl. The source can be over written by API: SetCapturerSource(media::AudioCapturerSource* source) This capture currently only support one sink (WebRtcAudioDeviceImpl), but this can be extended to multiple sinks for the future. Design doc: https://docs.google.com/a/google.com/document/d/1FmiXtk1pxFlAw_CWwbfG-EQ4Syi4vpnZm6GWMyJ1UfU/edit BUG=157306 TEST=manual test Review URL: https://codereview.chromium.org/11231003 TBR=xians@chromium.org Review URL: https://codereview.chromium.org/11362231 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@167448 0039d316-1c4b-4281-b951-d872f2087c98
* Break down the webrtc code and AudioInputDevice into a WebRtcAudioCapturer.xians@chromium.org2012-11-131-0/+2
| | | | | | | | | | | | | | | | | | | This capturer contains a source (AudioInputDevice) and a sink (WebRtcAudioDeviceImpl) by default. What it does is to get data from AudioInputDevice via CaptureCallback::Capture() callback, and forward the data to WebRtcAudioDeviceImpl. The source can be over written by API: SetCapturerSource(media::AudioCapturerSource* source) This capture currently only support one sink (WebRtcAudioDeviceImpl), but this can be extended to multiple sinks for the future. Design doc: https://docs.google.com/a/google.com/document/d/1FmiXtk1pxFlAw_CWwbfG-EQ4Syi4vpnZm6GWMyJ1UfU/edit BUG=157306 TEST=manual test Review URL: https://codereview.chromium.org/11231003 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@167387 0039d316-1c4b-4281-b951-d872f2087c98
* Add RunCallback to invoke a callback parameter in unittests.xhwang@chromium.org2012-11-131-0/+2
| | | | | | | | | | | | | | In gmock, ::testing::InvokeArgument doesn't support chromium base::Callback. Adding customized templated action RunCallback to support this. Also added new matchers for base::callback. BUG=none TEST=Added unittests to test the new matchers and actions. Updated media_unittests to use the new matchers and actions. Review URL: https://chromiumcodereview.appspot.com/11359100 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@167309 0039d316-1c4b-4281-b951-d872f2087c98
* Make media targets work with the shared library build for Android.yfriedman@chromium.org2012-11-061-4/+2
| | | | | | | | | | | | It looks like gpu_video_decoder has been refactored to not depend on ffmpeg and is required for the shared library build. BUG=158821 Review URL: https://chromiumcodereview.appspot.com/11362107 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@166249 0039d316-1c4b-4281-b951-d872f2087c98
* Roll ffmpeg DEPS for fixes, patch removal, and better GOMA detection.dalecurtis@google.com2012-11-021-4/+0
| | | | | | | | | | | | | | | | | | Also fixes various media tools which were using the old av_register_protocol2() path instead of the new FFmpegGlue hotness. Includes: 3d123ab Zero initialize ff_lockmgr_cb. b694550 Remove custom av_register_protocol2() patch. c317c1c Use build.ninja to see the user uses GOMA or not. BUG=146529,118986,159139 TEST=builds. Review URL: https://codereview.chromium.org/11365050 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@165752 0039d316-1c4b-4281-b951-d872f2087c98
* Adds new Core Audio utility methods in the media::win namespace.henrika@chromium.org2012-10-291-0/+3
| | | | | | | | | | | End goal is to use these methods in a unified audio class implementation for Windows and thereby make the code more readable and at the same time avoid duplicating code. BUG=154268 TEST=media_unittests.exe --gtest_filter=CoreAudio* Review URL: https://codereview.chromium.org/11226057 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@164633 0039d316-1c4b-4281-b951-d872f2087c98
* Handle audio device changes on Windows.dalecurtis@google.com2012-10-261-0/+3
| | | | | | | | | | | | | | | | | | Uses the new AudioDeviceListener framework to notify of device changes. Handles only default device changes at the moment, e.g., not manually changing the sample rate, etc on a current default device. This all works well enough that I can connect / disconnect remote desktop sessions with and without audio and everything continues to play seamlessly and in sync! BUG=153056 TEST=Unplug... Plug... Unplug! Plug! Review URL: https://codereview.chromium.org/11233023 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@164236 0039d316-1c4b-4281-b951-d872f2087c98
* Add initialization for ios audio-video framework.milanb@chromium.org2012-10-251-0/+1
| | | | | | | | | | | | The default initialization on ios blocks audio input when audio output is active. This enables duplex mode. BUG=None Review URL: https://chromiumcodereview.appspot.com/11276024 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@164129 0039d316-1c4b-4281-b951-d872f2087c98
* Moved SkCanvasVideoRenderer to media/filters.skaslev@chromium.org2012-10-241-1/+5
| | | | | | | | | | | | | | | | | | | SkCanvasVideoRenderer will be used for rendering YUV video streams by the software compositor. To avoid circular dependencies cc/ cannot depend on webkit/ hence the move. Also changed the interface of SkCanvasVideoRenderer::Paint to accept gfx::RectF instead of gfx::Rect. The gfx::Rect was converted to a floating point SkRect anyway and we actually use the floating point version from the software compositor. BUG=150016 Review URL: https://chromiumcodereview.appspot.com/11234071 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@163829 0039d316-1c4b-4281-b951-d872f2087c98
* Add support for channel transforms.dalecurtis@chromium.org2012-10-201-0/+3
| | | | | | | | | | | | | | | | | Introduces the ChannelMixer class for upmixing and downmixing AudioBus objects from one channel layout to another. Matrix building code is based on libavresample and libswresample from ffmpeg. Full decision listing: http://pastebin.com/KfeFzC0X BUG=138762 TEST=unit tests. Review URL: https://chromiumcodereview.appspot.com/11150034 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@163158 0039d316-1c4b-4281-b951-d872f2087c98
* Add DecryptingAudioDecoder.xhwang@chromium.org2012-10-191-0/+3
| | | | | | | | | | BUG=123421 TEST=added new tests to media_unittests Review URL: https://chromiumcodereview.appspot.com/11198017 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@162976 0039d316-1c4b-4281-b951-d872f2087c98
* Simulate an audio output stream when a real one isn't available.dalecurtis@chromium.org2012-10-181-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Upgrades FakeAudioOutputStream to fake OnMoreData calls using a PostDelayedTask approach similar to NullAudioSink. This is necessary for playback of HTML5 videos when a real audio device is not present. I.e. over remote desktop w/ remote audio disabled on on some of the Buildbot machines (this should allow us to remove --disable-audio from many of our tests). This is a two fold change: 1. AudioOutputResampler will now request an AUDIO_FAKE device when invalid output parameters are provided. 2. AudioManagerBase will check for AUDIO_FAKE as it always has but will additionally check if there are any output devices and if not return a fake stream. 2 is necessary for HTML5 audio since it doesn't use the low latency output path. BUG=120749 TEST=unittests. HTML5/Flash video playback over Remote Desktop w/o Remote Audio works. Review URL: https://chromiumcodereview.appspot.com/10987087 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@162810 0039d316-1c4b-4281-b951-d872f2087c98
* Don't build shader_bench for Aura builds since it breaks all the win_aura ↵jam@chromium.org2012-10-101-1/+1
| | | | | | | | trybots (gfx::NativeWindow != HWND). Review URL: https://codereview.chromium.org/11086055 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@161200 0039d316-1c4b-4281-b951-d872f2087c98
* Add WASAPI-based unified audio I/O back-end for Windows 7.henrika@chromium.org2012-10-051-0/+3
| | | | | | | | | | | | | | | | | | | | | | | Implementation of AudioOuputStream for Windows using the WASAPI API. Both input and output device must use the same sample rate. Corresponding implementation for Mac OS X is given by http://codereview.chromium.org/10916105/. Additional test using full Chrome: http://webaudiodemos.appspot.com/input/index.html Local tests have been performed using a wide range of audio devices and sample rates. It has also been verified that the QoS is good between two different devices as well as long as they both run at the same sample rate. 12 hour test of http://webaudiodemos.appspot.com/input/index.html worked well. Verified that we log a warning "Unified audio I/O is not supported." if the user has selected different sample rates for in and out. BUG=145092 TEST=media_unittests.exe --gtest_filter=WASAPIUnified* --enable-webaudio-input Review URL: https://codereview.chromium.org/10959068 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@160346 0039d316-1c4b-4281-b951-d872f2087c98
generated by cgit v1.1 at 2025-02-07 23:06:30 +0000