summaryrefslogtreecommitdiffstats
path: root/media/video
Commit message (Collapse)AuthorAgeFilesLines
* Enable Android SurfaceView fullscreen video with WMPIwatk2016-02-181-1/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This CL enables SurfaceView fullscreen video with the unified media pipeline in cases where we use the AVDA deferred rendering strategy today. * There's a new media interface called SurfaceManager with two methods: CreateFullscreenSurface() and NaturalSizeChanged(). * SurfaceManager is implemented by RendererSurfaceViewManager, which is a RenderFrameObserver, and BrowserSurfaceViewManager, which is created for each RenderFrame by MediaWebContentsObserverAndroid. * BrowserSurfaceViewManager creates a ContentVideoView in response to a CreateFullscreenSurface message, and registers it in a surface map that the decoder can look up in the GPU process. * WMPI interacts with SurfaceManager on behalf of the decoder. It passes GpuVideoDecoder a callback for requesting surfaces which it calls before initializing VDAs. * In response to the callback, if the player is in fullscreen WMPI will pass the request to the SurfaceManager which will return the surface id to GVD. If the player is not in fullscreen WMPI will return a null surface id. * When GVD gets a surface id back it completes its initialization by calling VDA::Initialize with the surface id and the VDA will render to the given surface. * WMPI records that it got a surface request callback so that it knows that future fullscreen transitions will require a restart of the decoder in order to switch surfaces. * A future CL will allow us to switch the surface dynamically without requiring a restart. BUG=533630 Review URL: https://codereview.chromium.org/1655083002 Cr-Commit-Position: refs/heads/master@{#376068}
* Reland: Enable NV12 VideoFrames on Mac.dcastagna2016-02-171-2/+1
| | | | | | | | | | | | | | | | As described in crbug.com/524582, we observed a reduction in power consumption when this format is used to display videos directly using the WindowServer. The downside of this format is that a conversion from YUV to RGB will be performed on the GPU using GL when the VideoFrame has to be used from GL. BUG=524582 Review URL: https://codereview.chromium.org/1686443002 Cr-Commit-Position: refs/heads/master@{#375720}
* Introducing gpu::CommandBufferId as a distinct, IdType<...>-based type.lukasza2016-02-161-4/+4
| | | | | | | | | | | | | | | This CL generalizes the pattern used by content::SavePackageId and cc::SurfaceId and puts it into //base/id_type.h. Using this pattern for gpu::CommandBufferId should hopefully help avoid bugs like the mixup fixed by https://crrev.com/365437. BUG=514815, 565545 CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel TBR=wolenetz@chromium.org, sky@chromium.org Review URL: https://codereview.chromium.org/1548443002 Cr-Commit-Position: refs/heads/master@{#375620}
* Revert of Enable NV12 VideoFrames on Mac. (patchset #3 id:40001 of ↵zmo2016-02-111-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | https://codereview.chromium.org/1686443002/ ) Reason for revert: Revert to see if the bot recovers. Original issue's description: > Enable NV12 VideoFrames on Mac. > > As described in crbug.com/524582, we observed a reduction in power > consumption when this format is used to display videos directly using > the WindowServer. > > The downside of this format is that a conversion from YUV to RGB will > be performed on the GPU using GL when the VideoFrame has to be used > from GL. > > BUG=524582 TBR=ccameron@chromium.org,dalecurtis@chromium.org,dcastagna@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=524582 Review URL: https://codereview.chromium.org/1684123003 Cr-Commit-Position: refs/heads/master@{#374847}
* Enable NV12 VideoFrames on Mac.dcastagna2016-02-111-2/+1
| | | | | | | | | | | | | | | | As described in crbug.com/524582, we observed a reduction in power consumption when this format is used to display videos directly using the WindowServer. The downside of this format is that a conversion from YUV to RGB will be performed on the GPU using GL when the VideoFrame has to be used from GL. BUG=524582 Review URL: https://codereview.chromium.org/1686443002 Cr-Commit-Position: refs/heads/master@{#374825}
* Add support for 9- and 10-bit h264 videos.hubbe2016-02-091-0/+6
| | | | | | | | | | | | | | | | | Videos are uploaded to GPU using half-floats if supported, otherwise they are downshifted to regular 8-bit textures before uploading. No dithering is done, except for whatever GL_DITHER might do. (Which is probably nothing.) BUG=445071 CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel Committed: https://crrev.com/074c4287f2625860b2a9eb437b97f1f1788f8f4b Cr-Commit-Position: refs/heads/master@{#373691} Review URL: https://codereview.chromium.org/1599533002 Cr-Commit-Position: refs/heads/master@{#374221}
* Revert of Add support for 9- and 10-bit h264 videos. (patchset #27 of ↵flackr2016-02-051-6/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | https://codereview.chromium.org/1599533002/ ) Reason for revert: Commit was failing content_browsertests on Mac 10.10: failures: Http/MediaTest.VideoBearHighBitDepthMp4/0 File/MediaTest.VideoBearHighBitDepthMp4/0 First failure: https://build.chromium.org/p/chromium.mac/builders/Mac10.10%20Tests/builds/5222 Original issue's description: > Add support for 9- and 10-bit h264 videos. > > Videos are uploaded to GPU using half-floats if supported, otherwise > they are downshifted to regular 8-bit textures before uploading. No > dithering is done, except for whatever GL_DITHER might do. (Which > is probably nothing.) > > BUG=445071 > CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel > > Committed: https://crrev.com/074c4287f2625860b2a9eb437b97f1f1788f8f4b > Cr-Commit-Position: refs/heads/master@{#373691} TBR=fbarchard@chromium.org,erg@chromium.org,reed@chromium.org,piman@chromium.org,danakj@chromium.org,asvitkine@chromium.org,dalecurtis@chromium.org,nasko@chromium.org,fsamuel@chromium.org BUG=445071 NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel Review URL: https://codereview.chromium.org/1674703002 Cr-Commit-Position: refs/heads/master@{#373824}
* Add support for 9- and 10-bit h264 videos.hubbe2016-02-051-0/+6
| | | | | | | | | | | | | | Videos are uploaded to GPU using half-floats if supported, otherwise they are downshifted to regular 8-bit textures before uploading. No dithering is done, except for whatever GL_DITHER might do. (Which is probably nothing.) BUG=445071 CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel Review URL: https://codereview.chromium.org/1599533002 Cr-Commit-Position: refs/heads/master@{#373691}
* AndroidVideoDecodeAccelerator can now render to a SurfaceViewwatk2016-02-031-0/+7
| | | | | | | | | | | | Previously AVDA would always configure MediaCodec with a SurfaceTexture. Now, to support efficient fullscreen video, it can render to a SurfaceView too. BUG=533630 Review URL: https://codereview.chromium.org/1639963002 Cr-Commit-Position: refs/heads/master@{#373365}
* Make 'kVideoImageTextureTarget' a list of texture targets.dcastagna2016-01-271-13/+14
| | | | | | | | | | | | | | | | | | | | | Pass to the renderer a list of texture targets, one per GpuMemoryBuffer format, via a command line argument. In this way GMBVFP can pick whatever GMB format it needs to use and bind to the correct texture target. This is similar to what we do for content (kContentImageTextureTarget). kContentImageTextureTarget can't be used since the buffer usage could differ from the buffer usage in GMBVFP. Once all GMB formats supports persistent usage and we can consolidate GPU_READ_CPU_READ_WRITE_PERSISTENT and GPU_READ_CPU_READ_WRITE this code can go away and we can use just one command line switch. BUG=524582 Review URL: https://codereview.chromium.org/1605423002 Cr-Commit-Position: refs/heads/master@{#371644}
* Verify returned frames from media::VideoFrame::Wrap*() methodsemircan2016-01-152-14/+25
| | | | | | | | | BUG=552112 CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel Review URL: https://codereview.chromium.org/1476523005 Cr-Commit-Position: refs/heads/master@{#369705}
* Report VP8 and VP9 capabilities for non-accelerated decoders in AVDAtimav2016-01-142-0/+16
| | | | | | | | | | | | | | We need them because we use AVDA for EME even for non-acelerated decoders. This CL reports VP8 and VP9 capabilities for all decoders, but succeeds AVDA VP8/9 initialization only for the accelerated ones (as before) or for both accelerated and non-accelerated if the stream is encrypted. BUG=577424 Review URL: https://codereview.chromium.org/1583083002 Cr-Commit-Position: refs/heads/master@{#369525}
* Updated media sync points to use new sync tokens.dyen2016-01-132-5/+38
| | | | | | | | | R=dalecurtis@chromium.org BUG=514815 Review URL: https://codereview.chromium.org/1443963003 Cr-Commit-Position: refs/heads/master@{#369083}
* GpuMemoryBuffers: Add an IsInUse functionccameron2016-01-112-6/+70
| | | | | | | | | | | | | | | | | Add a function GpuMemoryBuffer::IsInUseByWindowServer to see if a resource is currently in use by the system. This will only return true on Mac, where it returns the result of IOSurfaceIsInUse. Hook this up to cc::ResourceProvider::CanLockForWrite and InUseByConsumer. These fix the bug where tiles would flicker during reuse. BUG=558701 CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel Review URL: https://codereview.chromium.org/1527483003 Cr-Commit-Position: refs/heads/master@{#368718}
* Configure MediaCodec with CDM in ADVAtimav2016-01-112-0/+9
| | | | | | | | | | | | | | | | | | Implemented SetCdm() by retrieving the CDM object from mojo (it should be MediaDrmBridge), registering this bridge with nesessary callbacks and postponing the MediaCodec configuration till we get the MediaCrypto object. After MediaCrypto object is obtained we configure MediaCodec and only then report the SetCdm() status by NotifyCdmAttached(bool). With this approach any failure in MediaCodec creation is reported as a CDM failure. BUG=542417 Review URL: https://codereview.chromium.org/1469353010 Cr-Commit-Position: refs/heads/master@{#368679}
* Switch to standard integer types in media/, take 2.avi2015-12-2311-0/+27
| | | | | | | | | | | | This uses an automated script, so it'll catch things the first pass, done by hand, missed. BUG=138542 TBR=dalecurtis@chromium.org NOPRESUBMIT=true Review URL: https://codereview.chromium.org/1542013004 Cr-Commit-Position: refs/heads/master@{#366712}
* Add missing macros includes in media/.avi2015-12-193-0/+4
| | | | | | | | | BUG=138542 TBR=dalecurtis@chromium.org Review URL: https://codereview.chromium.org/1535193003 Cr-Commit-Position: refs/heads/master@{#366263}
* Switch to standard integer types in media/.Avi Drissman2015-12-1910-80/+63
| | | | | | | | | BUG=138542 TBR=dalecurtis@chromium.org Review URL: https://codereview.chromium.org/1534273002 . Cr-Commit-Position: refs/heads/master@{#366242}
* Don't require VDAs to return all PictureBuffers at once.liberato2015-12-102-4/+29
| | | | | | | | | | | | | | | | | | | The android deferred rendering backing strategy cannot always guarantee a minimum number of outstanding PictureBuffers beyond one at the client. Failure to do so can cause the pipeline to hang waiting for more pictures before returning any. This CL allows the VDA to provide a flag with its SupportedProfiles, collectively called the VDA Capabilities, that indicates that it cannot promise to return all of the PictureBuffers at once. In practice, GpuVideoDecoder uses this flag to always return false from CanReadWithoutStalling, once picture buffers are assigned. BUG=531606 Review URL: https://codereview.chromium.org/1490333005 Cr-Commit-Position: refs/heads/master@{#364387}
* Passed is_encrypted parameter to the VDA initialization.timav2015-12-043-3/+24
| | | | | | | | | | | | | | | The VDA on Android (AVDA) requires this info to properly implement CDM. This CL changes the method VideoDecodeAccelerator::Initialize() to accept the structure holding VDA initialization parameters. There are two parameters: video codec profile and the is_encrypted flag. For Android both parameters are propagated to GPU process. BUG=542417 Review URL: https://codereview.chromium.org/1485043002 Cr-Commit-Position: refs/heads/master@{#363127}
* Use std::default_delete as the default deleter for scoped_ptr.dcheng2015-11-194-33/+22
| | | | | | | | | | | The aim is to make scoped_ptr and std::unique_ptr functionally identical so scoped_ptr can simply be a typedef. BUG=554298 Review URL: https://codereview.chromium.org/1445003002 Cr-Commit-Position: refs/heads/master@{#360539}
* media: Support SetCdm() on VideoDecodeAccelerator interface.xhwang2015-11-132-2/+28
| | | | | | | | | | | This is needed to support encrypted stream handling in VideoDecodeAccelerator (VDA) implmentations on certain platforms (e.g. Android). BUG=545099 Review URL: https://codereview.chromium.org/1438063002 Cr-Commit-Position: refs/heads/master@{#359696}
* cc: Fix GL_R8 GpuMemoryBuffersccameron2015-11-061-1/+1
| | | | | | | | | | | | | Make GLImages use GL_RED instead of GL_R8 as the internal format, because GL_R8 isn't supported as an internal format for most GL functions and almost all GLES functions. BUG=533677 CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel Review URL: https://codereview.chromium.org/1434453008 Cr-Commit-Position: refs/heads/master@{#358225}
* Modified old wait sync point functions to also accept new sync tokens.dyen2015-11-032-9/+9
| | | | | | | | | | | | | | | | | | In order to help with refactoring old sync points into new sync points, glWaitSyncPointCHROMIUM() has been changed to accept both the old and new sync points. This CL only refactors all the ways we pass around sync points so in theory shouldn't change any behavior. Once this lands we can then incrementally change the sync point insertions to the new sync points. R=piman@chromium.org BUG=514815 CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel Review URL: https://codereview.chromium.org/1427543002 Cr-Commit-Position: refs/heads/master@{#357595}
* Carry over REFERENCE_TIME for the frames using GPU Memory Bufferqiangchen2015-10-301-0/+8
| | | | | | | | | | | | | | | For the frames using GPU memory buffer, the REFERENCE_TIME is lost, and then WebMediaPlayerMS will not be able to apply rendering algorithm to enhance the rendering smoothness. In this CL, we make those frames to carry over the REFERENCE_TIME from original frame. BUG=545165 Review URL: https://codereview.chromium.org/1418923006 Cr-Commit-Position: refs/heads/master@{#357156}
* [tracing] Add names to memory-infra dumpers for debuggingprimiano2015-10-301-1/+1
| | | | | | | | | | | | | | | | | Follow-up CL to crrev.com/1425793002. Adds an extra |name| argument to the memory-infra RegisterDumpProvider methods. This allow to see the names of the dump providers in the trace and diagnose dump providers getting stuck or taking more time than usual. No further behavioral change is introduced by this CL. BUG=547764 TBR=xhwang@chromium.org,simonhatch@chromium.org,jochen@chromium.org,shess@chromium.org,piman@chromium.org CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel Review URL: https://codereview.chromium.org/1406213005 Cr-Commit-Position: refs/heads/master@{#357089}
* ui: Rename gfx::BufferUsage enum values and add BufferUsage::GPU_READ.reveman2015-10-261-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The problem with the current usage modes is that we currently use SCANOUT for anything that doesn't require CPU access. When importing a buffer we typically don't care about anything but having the GPU be able to read from it. SCANOUT is not a good description of that and currently means GPU read/write support. This patch attempts to make usage more explicit and it solves the use case where a buffer type can only provide GPU read and not GPU write support (e.g. SHM fallback). Here are the new usage modes: - GPU_READ - GPU_READ_WRITE - GPU_READ_CPU_READ_WRITE GPU_READ is useful when importing a buffer and all you care about is being able to use it for sampling and optionally scanout. GPU_READ_WRITE is useful for things like WebGL or GPU raster where we want the ability to write to the buffer using GL and potentially use it for scanout. GPU_READ_CPU_READ_WRITE is the usage mode that allows CPU access and is used for one-copy and zero-copy texture initialization. There's nothing preventing this mode from also supporting scanout. - GPU_READ_CPU_READ_WRITE_PERSISTENT This usage mode indicates that the data will be persistent across Unmap()/Map() calls but will likely become part of the normal GPU_READ_CPU_READ_WRITE usage once all buffer types support this. BUG=538325 CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel Review URL: https://codereview.chromium.org/1420923005 Cr-Commit-Position: refs/heads/master@{#356108}
* media: Compute compatible VideoFrame::coded_rect for copies to GMBs.dcastagna2015-10-261-25/+52
| | | | | | | | | | | | | | | | | | Before this patch, GMBVFP would copy only visible_rect to GpuMemoryBuffers. Unfortunately GMBs can't always be created with visible_rect size since visible_rect might have dimensions not compatible with the output format. With this patch we compute a format compatible coded_rect and we use that as the new coded rect for copies and the new output VideoFrame. BUG=544554 CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel Review URL: https://codereview.chromium.org/1420943002 Cr-Commit-Position: refs/heads/master@{#356090}
* Reland: GpuMemoryBuffer interface change: Map(**) to Map() and ↵mcasas2015-10-221-18/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | memory(plane); stride(plane) Relanding http://crrev.com/1401183003 which had a compile error. Original reviewers: TBR=avi@chromium.org, bajones@chromium.org, reveman@chromium.org, dalecurtis@chromium.org, fsamuel@chromium.org, miu@chromium.org Original CL description:----------------------------------- GpuMemoryBuffer interface change: Map(**) --> Map() + memory(plane); GetStride(*) --> stride(plane) And at the same time clean up/simplify/homogeneise uses of those APIs. buffer_format_util.cc:RowSizeForBufferFormatChecked() is only used in unittests and internally to the file, this CL restricts it to the .cc file. Also a function there is only used in test --> added ForTesting() suffix. BUG=542225 CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel Committed: https://crrev.com/a11ca23b4ae411b4dc6cd8ff755e366680e80776 Cr-Commit-Position: refs/heads/master@{#355396} Review URL: https://codereview.chromium.org/1412223009 Cr-Commit-Position: refs/heads/master@{#355630}
* Revert of GpuMemoryBuffer interface change: Map(**) to Map() and ↵vasilii2015-10-221-18/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | memory(plane); stride(plane) (patchset #5 id:610001 of https://codereview.chromium.org/1401183003/ ) Reason for revert: Broke Win x64 GN compilation: e:\b\build\slave\win_x64_gn\build\src\components\mus\gles2\mojo_gpu_memory_buffer.cc(78) :error C2220: warning treated as error - no 'object' file generated e:\b\build\slave\win_x64_gn\build\src\components\mus\gles2\mojo_gpu_memory_buffer.cc(78) : warning C4267: 'argument' : conversion from 'size_t' to 'int', possible loss of data Original issue's description: > GpuMemoryBuffer interface change: Map(**) --> Map() + memory(plane); GetStride(*) --> stride(plane) > > And at the same time clean up/simplify/homogeneise > uses of those APIs. > > buffer_format_util.cc:RowSizeForBufferFormatChecked() > is only used in unittests and internally to the file, this CL > restricts it to the .cc file. Also a function there is only > used in test --> added ForTesting() suffix. > > BUG=542225 > CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel > > Committed: https://crrev.com/a11ca23b4ae411b4dc6cd8ff755e366680e80776 > Cr-Commit-Position: refs/heads/master@{#355396} TBR=reveman@chromium.org,avi@chromium.org,bajones@chromium.org,dalecurtis@chromium.org,fsamuel@chromium.org,miu@chromium.org,mcasas@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=542225 Review URL: https://codereview.chromium.org/1409163003 Cr-Commit-Position: refs/heads/master@{#355511}
* GpuMemoryBuffer interface change: Map(**) --> Map() + memory(plane); ↵mcasas2015-10-211-18/+18
| | | | | | | | | | | | | | | | | | | GetStride(*) --> stride(plane) And at the same time clean up/simplify/homogeneise uses of those APIs. buffer_format_util.cc:RowSizeForBufferFormatChecked() is only used in unittests and internally to the file, this CL restricts it to the .cc file. Also a function there is only used in test --> added ForTesting() suffix. BUG=542225 CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel Review URL: https://codereview.chromium.org/1401183003 Cr-Commit-Position: refs/heads/master@{#355396}
* media: Use GL shared worker context instead of allocating one.dcastagna2015-10-193-109/+50
| | | | | | | | | | | | | | | | | | | | | | | | Media used to create its own GL context. This context, that takes up a few MBs of memory, was used to create textures, mailboxes and syncpoints. This CL replaces the media context with the shared worker context already present in RenderThreadImpl. It also makes sure that media drops any reference to it in the main thread (that's required by the shared worker context.) This change will also allow media to access the context in a worker thread, in this way the GL operations won't need to be serialized on the media thread that might be busy decoding video/audio. NOTE: media didn't handle GL context lost properly, but simply stopped working after the first context lost. This CL doesn't fix that and reproduces the same behavior. BUG=544547 CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel Review URL: https://codereview.chromium.org/1369843002 Cr-Commit-Position: refs/heads/master@{#354848}
* Reland: Use GpuMemoryBufferVideoFramePool for WebMediaPlayerMS and ↵emircan2015-10-141-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | MediaStreamVideoRendererSink Relanding after expanding a DCHECK on CopyFrameToYV12() of wedmediaplayer_ms.cc TBR=dcastagna@chromium.org, phoglund@chromium.org, mcasas@chromium.org, sievers@chromium.org, xhwang@chromium.org, rationale: this patch is equivalent to the already LGTMd Original description --------------------------------------------------- Use GpuMemoryBufferVideoFramePool for WebMediaPlayerMS and MediaStreamVideoRendererSink MediaStreamVideoRendererSink is the common sink for video playback where we receive both the local camera capture frame and all the remote capture frames from peer connections. They are all hooked to the MediaStream elements. This CL follows dcastagna's CL that applies asynchronous copies to WebMediaPlayerimpl [0]. [0] https://codereview.chromium.org/1273943002/ BUG=440843, 503835 TEST= On Linux: - With and Without the kUseGpuMemoryBuffersForCapture flag, AppRTC loopback runs as expected. - With and Without the kEnableGpuMemoryBufferVideoFrames flag, AppRTC loopback runs as expected Committed: https://crrev.com/d49c3945570e7eff2ce728927f8c9fecd04f3487 Cr-Commit-Position: refs/heads/master@{#353839} patch from issue 1358883003 at patchset 310001 (http://crrev.com/1358883003#ps310001) Review URL: https://codereview.chromium.org/1407703003 Cr-Commit-Position: refs/heads/master@{#354087}
* Revert "Use GpuMemoryBufferVideoFramePool for WebMediaPlayerMS and ↵Henrik Grunell2015-10-141-4/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | MediaStreamVideoRendererSink" This reverts commit d49c3945570e7eff2ce728927f8c9fecd04f3487. The CL breaks WebRtcVideoQualityBrowserTest.MANUAL_TestVideoQuality on Chromium WebRTC Mac tester. https://uberchromegw.corp.google.com/i/chromium.webrtc/builders/Mac%20Tester/builds/44376 [9411:1799:1013/151010:FATAL:webmediaplayer_ms.cc(65)] Check failed: frame->format() == media::PIXEL_FORMAT_ARGB || frame->format() == media::PIXEL_FORMAT_XRGB. 0 Chromium Framework 0x0000000108c800a3 base::debug::StackTrace::StackTrace() + 19 1 Chromium Framework 0x0000000108c9b615 logging::LogMessage::~LogMessage() + 69 2 Chromium Framework 0x000000010d35fe66 content::WebMediaPlayerMS::Compositor::ReplaceCurrentFrameWithACopy(media::SkCanvasVideoRenderer*) + 294 3 Chromium Framework 0x000000010d35fbd1 content::WebMediaPlayerMS::pause() + 289 4 Chromium Framework 0x000000010af95906 blink::HTMLMediaElement::updatePlayState() + 246 5 Chromium Framework 0x000000010ae0ccfe blink::ContainerNode::notifyNodeRemoved(blink::Node&) + 94 6 Chromium Framework 0x000000010ae0d20f blink::ContainerNode::removeChildren(blink::SubtreeModificationAction) + 559 7 Chromium Framework 0x000000010b2e6a00 blink::replaceChildrenWithFragment(blink::ContainerNode*, WTF::PassRefPtr<blink::DocumentFragment>, blink::ExceptionState&) + 96 8 Chromium Framework 0x000000010ae6380a blink::Element::setInnerHTML(WTF::String const&, blink::ExceptionState&) + 234 9 Chromium Framework 0x000000010b875892 blink::ElementV8Internal::innerHTMLAttributeSetterCallback(v8::FunctionCallbackInfo<v8::Value> const&) + 386 10 Chromium Framework 0x000000010a2a6dcc v8::internal::FunctionCallbackArguments::Call(void (*)(v8::FunctionCallbackInfo<v8::Value> const&)) + 172 11 Chromium Framework 0x000000010a2cd445 v8::internal::MaybeHandle<v8::internal::Object> v8::internal::HandleApiCallHelper<false>(v8::internal::Isolate*, v8::internal::(anonymous namespace)::BuiltinArguments<(v8::internal::BuiltinExtraArguments)1>&) + 1429 12 Chromium Framework 0x000000010a2ccd98 v8::internal::Builtins::InvokeApiFunction(v8::internal::Handle<v8::internal::JSFunction>, v8::internal::Handle<v8::internal::Object>, int, v8::internal::Handle<v8::internal::Object>*) + 456 13 Chromium Framework 0x000000010a42f402 v8::internal::Execution::Call(v8::internal::Isolate*, v8::internal::Handle<v8::internal::Object>, v8::internal::Handle<v8::internal::Object>, int, v8::internal::Handle<v8::internal::Object>*) + 1170 14 Chromium Framework 0x000000010a5be988 v8::internal::Object::SetPropertyWithDefinedSetter(v8::internal::Handle<v8::internal::Object>, v8::internal::Handle<v8::internal::JSReceiver>, v8::internal::Handle<v8::internal::Object>) + 120 15 Chromium Framework 0x000000010a5be4df v8::internal::Object::SetPropertyWithAccessor(v8::internal::LookupIterator*, v8::internal::Handle<v8::internal::Object>, v8::internal::LanguageMode) + 687 16 Chromium Framework 0x000000010a5d1cad v8::internal::Object::SetPropertyInternal(v8::internal::LookupIterator*, v8::internal::Handle<v8::internal::Object>, v8::internal::LanguageMode, v8::internal::Object::StoreFromKeyed, bool*) + 589 17 Chromium Framework 0x000000010a5d1a21 v8::internal::Object::SetProperty(v8::internal::LookupIterator*, v8::internal::Handle<v8::internal::Object>, v8::internal::LanguageMode, v8::internal::Object::StoreFromKeyed) + 49 18 Chromium Framework 0x000000010a56f2ac v8::internal::StoreIC::Store(v8::internal::Handle<v8::internal::Object>, v8::internal::Handle<v8::internal::Name>, v8::internal::Handle<v8::internal::Object>, v8::internal::Object::StoreFromKeyed) + 1068 19 Chromium Framework 0x000000010a57442c v8::internal::Runtime_StoreIC_Miss(int, v8::internal::Object**, v8::internal::Isolate*) + 812 TBR=emircan@chromium.org Review URL: https://codereview.chromium.org/1398033005 . Cr-Commit-Position: refs/heads/master@{#353976}
* media: Use libyuv::CopyPlane instead of memcpy.dcastagna2015-10-131-4/+4
| | | | | | | | | | | | libyuv::CopyPlane uses some low level optmization that memcpy doesn't have. This patch replaces the memcpy used when copying video frames to I420 GpuMemoryBuffers with libyuv::CopyPlane. BUG= Review URL: https://codereview.chromium.org/1400923003 Cr-Commit-Position: refs/heads/master@{#353898}
* Use GpuMemoryBufferVideoFramePool for WebMediaPlayerMS and ↵emircan2015-10-131-2/+4
| | | | | | | | | | | | | | | | | | | MediaStreamVideoRendererSink MediaStreamVideoRendererSink is the common sink for video playback where we receive both the local camera capture frame and all the remote capture frames from peer connections. They are all hooked to the MediaStream elements. This CL follows dcastagna's CL that applies asynchronous copies to WebMediaPlayerimpl [0]. [0] https://codereview.chromium.org/1273943002/ BUG=440843, 503835 TEST= On Linux: - With and Without the kUseGpuMemoryBuffersForCapture flag, AppRTC loopback runs as expected. - With and Without the kEnableGpuMemoryBufferVideoFrames flag, AppRTC loopback runs as expected Review URL: https://codereview.chromium.org/1358883003 Cr-Commit-Position: refs/heads/master@{#353839}
* media: GpuMemoryBuffers memory tracing.dcastagna2015-09-281-5/+53
| | | | | | | | | | | This patch adds memory tracing for GpuMemoryBuffers and graphics resources used by media in GpuMemoryBufferVideoFramePool. BUG= Review URL: https://codereview.chromium.org/1355373003 Cr-Commit-Position: refs/heads/master@{#351152}
* media: GMBVideoFramePool, crop VideoFrame using visible_rect.dcastagna2015-09-281-17/+13
| | | | | | | | | | | | | | | | VideoFrame::visible_rect could be different than natural_size when the VideoFrame is coming from a media stream that is from a camera. crrev.com/1358883003 is planning to convert the video frames coming from different media sources. This CL crops VideoFrame using visible_rect when it gets converted to a new VideoFrame backed by GpuMemoryBuffers. BUG= Review URL: https://codereview.chromium.org/1371683002 Cr-Commit-Position: refs/heads/master@{#351149}
* Deal with AllocateGpuMemoryBuffer returning null.dcastagna2015-09-142-50/+83
| | | | | | | | | | | | AllocateGpuMemoryBuffer can return null (e.g: when the GPU process is down). This CL makes sure we don't crash in that case and make the code behave in the most similar way to when allocations succeed. BUG=529088 Review URL: https://codereview.chromium.org/1304843005 Cr-Commit-Position: refs/heads/master@{#348738}
* Add PIXEL_FORMAT_MT21.wuchengli2015-09-141-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | MT21 is a MediaTek proprietary format. MT21 is similar to NV21 except the memory layout and pixel layout (swizzles). YUV 4:2:0. 2x2 VU samples. 12 bits per pixel. Each image contains two buffers, one for Y plane and one for interleaved VU plane. Two planes can be non-contiguous in memory. Suppose image dimension is (width, height) Plane[0]: Y plane Start address alignment = 4K bytes Offset from Buffer[0] start address = 0 Row pitch = ((width+15)/16) * 16 Plane size = Row pitch * (((height+31)/32)*32) Plane[1]: VU plane Start address alignment = 4K bytes Offset from Buffer[1] start address = 0 Row pitch = ((width+15)/16) * 16 Plane size = Row pitch * (((height+31)/32)*32)/2 BUG=chrome-os-partner:44784 TESTS=Play video and run apprtc loopback. CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel Review URL: https://codereview.chromium.org/1326153002 Cr-Commit-Position: refs/heads/master@{#348575}
* Revert "Revert of Add support for converting I420 software frames into NV12 ↵guidou2015-09-102-41/+139
| | | | | | | | | | | | | | | | hardware frames (patchset #6 id:140001 of https://codereview.chromium.org/1307853003/ )" This reverts commit 9fbd81e3c8adf06f9a77d917050eb99f2cdad3c3. TBR=dcastagna@chromium.org,sandersd@chromium.org,ccameron@chromium.org,andresantoso@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=524582 Review URL: https://codereview.chromium.org/1332733003 Cr-Commit-Position: refs/heads/master@{#348141}
* Revert of Add support for converting I420 software frames into NV12 hardware ↵tommi2015-09-102-139/+41
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | frames (patchset #6 id:140001 of https://codereview.chromium.org/1307853003/ ) Reason for revert: We suspect this CL caused a WebRTC browser test to start failing. The failures are consistent and started here: https://build.chromium.org/p/chromium.webrtc/builders/Win7%20Tester/builds/21330 Original issue's description: > Add support for converting I420 software frames into NV12 hardware frames > > Enhance MaybeCreateHardwareFrame() to be able to create a NV12 hardware > frame backed by a YUV_420_BIPLANAR GpuMemoryBuffer. > > This code path is not enabled yet. > > BUG=524582 > CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel > > Committed: https://crrev.com/422d099ed5b8439b92d198deb84d4528c14ccc0c > Cr-Commit-Position: refs/heads/master@{#347864} TBR=dcastagna@chromium.org,sandersd@chromium.org,ccameron@chromium.org,andresantoso@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=524582 Review URL: https://codereview.chromium.org/1327243002 Cr-Commit-Position: refs/heads/master@{#348120}
* Add support for converting I420 software frames into NV12 hardware framesandresantoso2015-09-092-41/+139
| | | | | | | | | | | | | | Enhance MaybeCreateHardwareFrame() to be able to create a NV12 hardware frame backed by a YUV_420_BIPLANAR GpuMemoryBuffer. This code path is not enabled yet. BUG=524582 CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel Review URL: https://codereview.chromium.org/1307853003 Cr-Commit-Position: refs/heads/master@{#347864}
* media: Fix inconsistent pending_read_ state in VideoRendererImpl.dcastagna2015-09-032-3/+7
| | | | | | | | | | | | | | | | | | | | | | After asynchronous VideoFrame copies have been added in VideoRendererImpl, pending_read_ might end up in an inconsistent state. The problem is that while a VideoFrame copy is in flight, pending_read_ is set to true. The video frame stream might be reset while the copy is happening. Previously the expectation was that pending_read_ would be always false when OnVideoFrameStreamResetDone was called. This CL removes the DCHECK and set pending_read_ to false when the video frame stream is reset. This CL also adds a sequence_token that is incremented every time the stream is reset. VideoFrames added with a mismatching sequence token will be discarded. BUG= Review URL: https://codereview.chromium.org/1319303005 Cr-Commit-Position: refs/heads/master@{#347234}
* Check ycbcr422 extension to set VideoFrame to GMB format.dcastagna2015-09-022-20/+23
| | | | | | | | | | | | | | | crrev.com/1305153005 and crrev.com/1308643003 added ycbcr_422_image Chromium extension. This CL select the correct VideoFrame format used to convert software to GpuMemoryBuffer video frames based on the availability of the extension. The internal format used for the images associated to the GMBs has been corrected accordingly. BUG=526311 Review URL: https://codereview.chromium.org/1306243010 Cr-Commit-Position: refs/heads/master@{#346828}
* Merge media::VideoCapturePixelFormat with media::VideoPixelFormatemircan2015-09-011-1/+6
| | | | | | | | | | | | | | | | This CL merges these 2 enums that overlap and represent pixel formats. - Moved types that do not exist to media::VideoPixelFormat - Updated histograms.xml for UMA values - Updated media_types.mojom for matching mojo enums - Added kWinSupportedCaptureFormats to capability_list_win.cc such that we are no longer dependant on the order of media::VideoCapturePixelFormat for choosing the preferred type. BUG=521068, 504160 CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel Review URL: https://codereview.chromium.org/1301133002 Cr-Commit-Position: refs/heads/master@{#346711}
* media: Convert I420 VideoFrame to UYVY GpuMemoryBuffer.dcastagna2015-08-212-61/+174
| | | | | | | | | | | | | | | | | This patch adds support for UYVY as a pixel format for the VideoFrame backed by GpuMemoryBuffer. If UYVY is set as format in GpuMemoryBufferVideoFramePool, the source VideoFrame will be converted during the copy to GMB. UYVY VideoFrames might get promoted to overlays on Mac. CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel BUG=485859,510252 Review URL: https://codereview.chromium.org/1306693002 Cr-Commit-Position: refs/heads/master@{#344899}
* Add UYVY 4:2:2 support to VideoFrame and GpuMemoryBuffer.andresantoso2015-08-211-0/+1
| | | | | | | | | | | | | Added media::PIXEL_FORMAT_UYVY. Replace gfx::BufferFormat::YUV_420_BIPLANAR with gfx::BufferFormat::UYVY_422. We plan to use this format to enable video overlays on Mac. BUG=510252 CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel Review URL: https://codereview.chromium.org/1299973003 Cr-Commit-Position: refs/heads/master@{#344692}
* media: Make GpuMemoryBuffers VideoFrame copies asynchronous.dcastagna2015-08-203-123/+287
| | | | | | | | | | | | | | | Plane copies from VideoFrames to GpuMemoryBuffers happening in the same thread as the decoding thread might push the decoding time past the frame time and slow down the entire video. This patch adds a TaskRunner to GpuMemoryBufferVideoFramePool that is used to do the copies asynchronously. BUG=485859 Review URL: https://codereview.chromium.org/1273943002 Cr-Commit-Position: refs/heads/master@{#344401}
* Introduce a client minimum picture pool sizelpique2015-08-201-1/+5
| | | | | | | | | | | | | | | | | | When using the video decoder PPAPI, the most recent version of the ARC extension requires there to be a certain minimum number of picture buffers in flight (allocated but not released). Without a larger pool, ARC video decoding will stall trying to allocate more decoded picture frames than are available by default. This patch creates a new DEV interface version for the VideoDecoder PPAPI. The new interface simply adds a single new argument to VideoDecoder::Initialize() so that a PPAPI client indicate the minimum number of pictures it needs to function. In order to implement this minium picture count, the meaning of the ProvidePictureBuffers() interface call used by the video decoder implementations has changed slightly. After making the call to ProvidePictureBuffers() with a given picture buffer size, the subsequent callback via AssignPictureBuffers() includes a std::vector of buffers that might be larger than requested. I've adjusted the various implementations to handle this change -- most of them previously assumed and asserted that the count was the same. In particular this meant moving some code around in the V4L2 implementations since they also do some internal allocations based on the number of picture buffers that actually end up being chosen. BUG=485775 Review URL: https://codereview.chromium.org/1207043002 Cr-Commit-Position: refs/heads/master@{#344391}
generated by cgit v1.1 at 2025-02-08 00:34:44 +0000