summaryrefslogtreecommitdiffstats
path: root/media/base/video_frame_unittest.cc
Commit message (Collapse)AuthorAgeFilesLines
* Switch to standard integer types in media/, take 2.avi2015-12-231-0/+4
| | | | | | | | | | | | 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}
* Switch to standard integer types in media/.Avi Drissman2015-12-191-13/+14
| | | | | | | | | BUG=138542 TBR=dalecurtis@chromium.org Review URL: https://codereview.chromium.org/1534273002 . Cr-Commit-Position: refs/heads/master@{#366242}
* Reland "Added an extra sync token field for extra command buffer..."dyen2015-12-091-3/+4
| | | | | | | | | | | This reverts commit 5097a2103f86741a7d0e6567e57759be939182b0. R=dalecurtis@chromium.org, dcheng@chromium.org, piman@chromium.org, sky@chromium.org BUG=514815, 566291 Review URL: https://codereview.chromium.org/1499813003 Cr-Commit-Position: refs/heads/master@{#363922}
* Revert of Added an extra sync token field for extra command buffer ↵ajuma2015-12-041-4/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | identification. (patchset #8 id:140001 of https://codereview.chromium.org/1489573003/ ) Reason for revert: This is causing a large number of layout tests in virtual/threaded/animations to crash. They're hitting the following assertion: FATAL:scheduler.cc(203)] Check failed: state_machine_.pending_swaps() > 0 (0 vs. 0){"compositor_timing_history": e.g. see https://build.chromium.org/p/chromium.webkit/builders/WebKit%20Mac10.7%20%28dbg%29/builds/25835 Confirmed with a local bisect. Original issue's description: > Added an extra sync token field for extra command buffer identification. > > This CL adds an extra field within sync tokens without changing the size > of the sync token. Currently this extra field is only used for the > GPU channel implementation, storing the stream of the identified command > buffer. > > BUG=514815 > > Committed: https://crrev.com/f21e7e6e2b260d56fa54373dd662c81c9d955331 > Cr-Commit-Position: refs/heads/master@{#363231} TBR=dcheng@chromium.org,dalecurtis@chromium.org,piman@chromium.org,sky@chromium.org,dyen@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=514815 Review URL: https://codereview.chromium.org/1495893005 Cr-Commit-Position: refs/heads/master@{#363290}
* Added an extra sync token field for extra command buffer identification.dyen2015-12-041-3/+4
| | | | | | | | | | | | | This CL adds an extra field within sync tokens without changing the size of the sync token. Currently this extra field is only used for the GPU channel implementation, storing the stream of the identified command buffer. BUG=514815 Review URL: https://codereview.chromium.org/1489573003 Cr-Commit-Position: refs/heads/master@{#363231}
* Re-land: Converted video frame and image callbacks to use new sync tokens.dyen2015-11-061-5/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit a1ab22a90140fe9e6c669998f3efc52795e569e2. Original issue's description: > Converted video frame and image callbacks to use new sync tokens. > > As an incremental step towards utilizing the new sync tokens, this > CL converts existing video frame and image sync points to use > sync tokens instead. > > In order to accomplish this, the GpuCommandBufferMsg_CreateImage > IPC message has been modified to accept a fence_release parameter > so that it can act as a sync token IPC. > > A new SyncPointClientWaiter concept has also added which can wait > on other sync point clients without an associated order number. > This only works because the SyncPointClientWaiter cannot be waited > on so no deadlocks can occur. > > BUG=514815 > CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel > > Committed: https://crrev.com/c7aff68a0c11820cc2b8d488851c682c0d32cd2b > Cr-Commit-Position: refs/heads/master@{#357997} BUG=514815 CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel Review URL: https://codereview.chromium.org/1427893003 Cr-Commit-Position: refs/heads/master@{#358346}
* Revert of Converted video frame and image callbacks to use new sync tokens. ↵nhiroki2015-11-051-11/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | (patchset #9 id:160001 of https://codereview.chromium.org/1429213002/ ) Reason for revert: This could be breaking webkit_tests: http://build.chromium.org/p/chromium.webkit/builders/WebKit%20Linux%20%28dbg%29/builds/4445 http://build.chromium.org/p/chromium.webkit/builders/WebKit%20Mac10.7%20%28dbg%29/builds/25461 Original issue's description: > Converted video frame and image callbacks to use new sync tokens. > > As an incremental step towards utilizing the new sync tokens, this > CL converts existing video frame and image sync points to use > sync tokens instead. > > In order to accomplish this, the GpuCommandBufferMsg_CreateImage > IPC message has been modified to accept a fence_release parameter > so that it can act as a sync token IPC. > > A new SyncPointClientWaiter concept has also added which can wait > on other sync point clients without an associated order number. > This only works because the SyncPointClientWaiter cannot be waited > on so no deadlocks can occur. > > BUG=514815 > CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel > > Committed: https://crrev.com/c7aff68a0c11820cc2b8d488851c682c0d32cd2b > Cr-Commit-Position: refs/heads/master@{#357997} TBR=dcheng@chromium.org,dalecurtis@chromium.org,piman@chromium.org,sky@chromium.org,dyen@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=514815 Review URL: https://codereview.chromium.org/1414793018 Cr-Commit-Position: refs/heads/master@{#358008}
* Converted video frame and image callbacks to use new sync tokens.dyen2015-11-051-5/+11
| | | | | | | | | | | | | | | | | | | | | | As an incremental step towards utilizing the new sync tokens, this CL converts existing video frame and image sync points to use sync tokens instead. In order to accomplish this, the GpuCommandBufferMsg_CreateImage IPC message has been modified to accept a fence_release parameter so that it can act as a sync token IPC. A new SyncPointClientWaiter concept has also added which can wait on other sync point clients without an associated order number. This only works because the SyncPointClientWaiter cannot be waited on so no deadlocks can occur. BUG=514815 CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel Review URL: https://codereview.chromium.org/1429213002 Cr-Commit-Position: refs/heads/master@{#357997}
* Modified old wait sync point functions to also accept new sync tokens.dyen2015-11-031-32/+35
| | | | | | | | | | | | | | | | | | 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}
* Add VideoFrame::CreateZeroInitializedFrameemircan2015-09-081-0/+20
| | | | | | | | BUG=514759, 526441 Review URL: https://codereview.chromium.org/1313413010 Cr-Commit-Position: refs/heads/master@{#347753}
* Rename media/base/buffers.h to media/base/timestamp_constants.hwatk2015-09-041-1/+0
| | | | | | | | | | | | | | | buffers.h now only contains functions for creating timestamps. This change also removes 'extern' from the functions in timestamp_constants.h (because it doesn't mean anything on a function definition), stops including it in files that don't use it, and adds includes to files that use it without including it. BUG=528114 TEST=It compiles Review URL: https://codereview.chromium.org/1321473004 Cr-Commit-Position: refs/heads/master@{#347491}
* Allow odd sized video decoder configs.chcunningham2015-07-291-0/+44
| | | | | | | | | | | | | | | | | | | | | | | | | VideoFrame::IsValidConfig is a public static method, called both externally and internally. This change removes a check which is not wanted in all (or even most) cases where IsValidConfig was called. Spoke with some past authors. The check is not well understood, but best guess is that it was meant to verify that coded size is properly aligned with the sub-sampled UV planes. The check is now made more narrowly in CreateFrame, where we are free to adjust the size because we own the allocation. This change also includes some unification of error handling among the various "Create" methods. These will now return null if the video frame configuration is found to be invalid. See extensive discussion and back-story in code review comments. BUG=505070, 489744, 379127 TESTS=media_unittests (added some), and manually tested repro in bug Review URL: https://codereview.chromium.org/1240833003 Cr-Commit-Position: refs/heads/master@{#340946}
* Remove memset from VideoFrame and mark buffer as unpoisonedemircan2015-07-171-13/+0
| | | | | | | | | | | - I removed the memset from AllocateYUV as it looks unnecessary except for FFmpegVideoDecoder. - FFmpegVideoDecoder marks the incoming buffer from VideoFramePool as unpoisoned. BUG=508220 Review URL: https://codereview.chromium.org/1227383003 Cr-Commit-Position: refs/heads/master@{#339304}
* media: extract Format and ColorSpace enum from VideoFrame.dongseong.hwang2015-07-131-19/+18
| | | | | | | | | | | | These enums are used in IPC as well as many classes. It's too big to include video_frame.h for only these enums. BUG=489744 CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel Review URL: https://codereview.chromium.org/1165003008 Cr-Commit-Position: refs/heads/master@{#338514}
* VideoFrame method reordering and minor cleanupmcasas2015-06-231-3/+3
| | | | | | | | | | | | | | | | | | | This CL cleans up a few itches I found during previous CLs: - Reorders VideoFrame methods to follow declaration/style guide. - Removes VideoFrame::PlaneAllocationSize() and replaced its use with VideoFrame::PlaneSize().GetArea() since clients absolutely know what they are doing and this convenience method is thus more a burden - Turns HashFrameForTesting() into static. - Removes ReleaseData() and binds base::AlignedFree() directly. BUG=489744 Review URL: https://codereview.chromium.org/1195153003 Cr-Commit-Position: refs/heads/master@{#335701}
* VideoFrame: extract AccessType from StorageType, allow clients to add DmaBuf ↵mcasas2015-06-121-7/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | File Descriptors VideoFrame::StorageTexture mixes access type and storage proper. This CL separates both so we have access (mappable in memory versus non-accessible, be that ACCESS_TEXTURE or ACCESS_HOLE) and storage type (owned/non owned/shared memory or DmaBufs). In principle all combinations of Access+Storage could be possible, although in practice they are limited by the availability of Factory and Wrap methods. I sprinkled DCHECKs everywhere to make some existing assumptions visible. This new added capability to add e.g. DmaBuf File Descriptors (fd) is used in VideoCaptureDeviceClient to plug those to a Texture VideoFrame. Note that with this new storage/access marking method it would be possible to have e.g. a ACCESS_TEXTURE with STORAGE_SHMEM or STORAGE_DMABUFS. Also added IsTexture() method to simplify clients that currently explicitly check for equality with STORAGE_TEXTURE. (Note: VideoFrame::IsValidConfig() is also marked for removal if possible). BUG=440843, 489744 CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel TBR=reveman@chromium.org for cc/* since is just a mechanical change video_frame->storage_type() == media::VideoFrame::STORAGE_TEXTURE turns into video_frame->HasTextures() Review URL: https://codereview.chromium.org/1156723005 Cr-Commit-Position: refs/heads/master@{#334207}
* VideoFrame cleanup: change |allow_overlay_| to metadata and |has_alpha| to ↵mcasas2015-06-111-7/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Format VideoFrame::WrapNativeTexture() has a parameter |allow_overlay_| that is overwhelmingly |false| around the codebase. This CL moves this parameter as a metadata entry, false by default except when explicitly set. VideoFrame::WrapNativeTexture() loses the parameter |has_alpha| and instead gets a VideoFrame::Format; all cases I found say ARGB, added DCHECK to see if bots agree and to make this situation evident. This is in preparation for Texture frames that are not ARGB, e.g. any 4:2:2. BUG=440843, 489744 CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel TBR= bbudge@chromium.org for content/renderer/pepper/video_decoder_shim.cc reveman@chromium.org for cc/resources/video_resource_updater.cc and a few associated unittests. In both cases it's just an automatic change derived from VideoFrame method smart-renaming: video_frame->allow_overlay() turns into video_frame->metadata()->IsTrue(media::VideoFrameMetadata::ALLOW_OVERLAY) Review URL: https://codereview.chromium.org/1150863008 Cr-Commit-Position: refs/heads/master@{#333855}
* VideoFrame cleanup: move |end_of_stream| indication as metadata ISO bool membermcasas2015-06-051-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | VideoFrame::end_of_stream_ is practically never use, but is currently kept as a member variable, and initialized by the constructor to false in the majority of cases -- only CreateEOSFrame() and eventually WrapVideoFrame() can set it to true. This CL changes that to an explicit post constructor SetEndOfStreamIndication() member. Since the underlying |end_of_stream_| is removed, end_of_stream() needs to be renamed as IsEndOfStream(). Moved VideoFrame::AllocateYUV() to its corresponding location according to header file. No code change here. BUG=489744 TBR = bbudge@chromium.org for the trivial change in content/renderer/pepper/ Review URL: https://codereview.chromium.org/1160003005 Cr-Commit-Position: refs/heads/master@{#332983}
* Relanding 1143663007: VideoFrame: Separate Pixel Format from Storage Type.mcasas2015-05-291-6/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Relanding after revert 1161803003. (original list of reviewers:) TBR=reveman@chromium.org, watk@chromium.org, jfroy@chromium.org, svitkine@chromium.org, DaleCurtis@chromium.org, miu@chromium.org, bbudge@chromium.org (for pepper) Original CL description: ----------------------------------------------------------- VideoFrame: Segregate Pixel Format and Storage Type. VideoFrame::Format is a mix of textures and cpu-backed formats. Textures are then further specified by a texture format VideoFrame::TextureFormat. This CL consolidates this into a single pixel format and a storage type. This applies to HOLE as well, which is understood as another Storage type. VideoFrame ctor forces to pass a |mailbox_holders_| also for non-texture based formats. Another private ctor is added without this necessity, and all the necessary factory methods are updated. UMA-wise: Removing NATIVE_TEXTURE and HOLE from pixel format prevents them from being UMA-accounted, but there are no registered instances of those anyway. NV12 format is restricted to OS_MACOSX. BUG=489744 CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel Committed: https://crrev.com/80f289fe303323361d07c5b58b23f8499903a154 Cr-Commit-Position: refs/heads/master@{#332000} Review URL: https://codereview.chromium.org/1154153003 Cr-Commit-Position: refs/heads/master@{#332065}
* Revert "VideoFrame: Segregate Pixel Format and Storage Type."Matt Mueller2015-05-291-7/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit 80f289fe303323361d07c5b58b23f8499903a154. Appears to have broken chromium OS compile: ../../content/common/gpu/media/v4l2_device.cc: In static member function 'static media::VideoFrame::Format content::V4L2Device::V4L2PixFmtToVideoFrameFormat(uint32)': ../../content/common/gpu/media/v4l2_device.cc:46:14: error: 'NV12' is not a member of 'media::VideoFrame' return media::VideoFrame::NV12; ^ ../../content/common/gpu/media/v4l2_device.cc: In static member function 'static uint32 content::V4L2Device::VideoFrameFormatToV4L2PixFmt(media::VideoFrame::Format)': ../../content/common/gpu/media/v4l2_device.cc:65:10: error: 'NV12' is not a member of 'media::VideoFrame' case media::VideoFrame::NV12: ^ [..snip..] In file included from ../../base/memory/weak_ptr.h:69:0, from ../../base/bind_helpers.h:148, from ../../base/bind_internal.h:8, from ../../base/bind.h:8, from ../../content/common/gpu/media/v4l2_image_processor.cc:12: ../../content/common/gpu/media/v4l2_image_processor.cc: In member function 'bool content::V4L2ImageProcessor::Initialize(media::VideoFrame::Format, media::VideoFrame::Format, gfx::Size, gfx::Size, gfx::Size, const Closure&)': ../../content/common/gpu/media/v4l2_image_processor.cc:112:28: error: 'NV12' is not a member of 'media::VideoFrame' DCHECK_EQ(output_format, media::VideoFrame::NV12); ^ ../../base/logging.h:671:22: note: in definition of macro 'DCHECK_OP' (val1), (val2), #val1 " " #op " " #val2)) \ ^ ../../content/common/gpu/media/v4l2_image_processor.cc:112:3: note: in expansion of macro 'DCHECK_EQ' DCHECK_EQ(output_format, media::VideoFrame::NV12); ^ ninja: build stopped: subcommand failed. BUG=489744 CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel TBR=mcasas@chromium.org Review URL: https://codereview.chromium.org/1161803003 Cr-Commit-Position: refs/heads/master@{#332012}
* VideoFrame: Segregate Pixel Format and Storage Type.mcasas2015-05-291-6/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | VideoFrame::Format is a mix of textures and cpu-backed formats. Textures are then further specified by a texture format VideoFrame::TextureFormat. This CL consolidates this into a single pixel format and a storage type. This applies to HOLE as well, which is understood as another Storage type. VideoFrame ctor forces to pass a |mailbox_holders_| also for non-texture based formats. Another private ctor is added without this necessity, and all the necessary factory methods are updated. UMA-wise: Removing NATIVE_TEXTURE and HOLE from pixel format prevents them from being UMA-accounted, but there are no registered instances of those anyway. NV12 format is restricted to OS_MACOSX. BUG=489744 CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel TBR=bbudge@chromium.org for pepper/ since the change is trivial there. Review URL: https://codereview.chromium.org/1143663007 Cr-Commit-Position: refs/heads/master@{#332000}
* VideoFrame: Replace no_longer_needed_cb_ with AddDestructionObserver().miu2015-05-281-5/+6
| | | | | | | | | | | | | | | | | | | This change provides "done callback" functionality to media::VideoFrame. Instead of forcing client code to provide a done callback at construction time, this allows any code that touches a VideoFrame to add a done callback to perform post-use clean-up or examine the final metadata values for a frame. The latter use case is needed for an upcoming change where consumers will provide a feedback signal that a the producer of a VideoFrame can use to auto-adjust to the bottlenecks in an end-to-end system. See bug for more details. BUG=156767,489744 TBR=raymes@chromium.org CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel Review URL: https://codereview.chromium.org/1153033005 Cr-Commit-Position: refs/heads/master@{#331729}
* New FRAME_DURATION VideoFrameMetadata, with Cast Streaming use case.miu2015-05-201-0/+8
| | | | | | | | | | | | | | | | | | | | | Adds a new FRAME_DURATION option to VideoFrameMetadata, which can be used by consumers of video frames to improve performance (e.g., encoding quality). This change also adds population of the new metadata by the desktop/tab capture pipeline, and consumption by Cast Streaming's software VP8 encoder. Having accurate frame duration information improves the encoder's ability to choose a compression quality level that better meets the target encode bitrate. Later changes will require this in order to compute resource utilization feedback signals (see bug for details). BUG=156767 Review URL: https://codereview.chromium.org/1146723002 Cr-Commit-Position: refs/heads/master@{#330661}
* Add distinction between RGB and RGBA native texture video frame and resourceshalliwell2015-05-131-1/+2
| | | | | | | | | | | | | | | | Currently it's impossible to place a NATIVE_TEXTURE VideoFrame into an overlay, because: * NATIVE_TEXTURE VideoFrame turns into RGB_RESOURCE in VideoResourceUpdater * RGB_RESOURCE always sets premultipled_alpha flag on its TextureDrawQuad (see VideoLayerImpl::AppendQuads) * OverlayStrategyCommon rejects quads with premultiplied alpha BUG= Review URL: https://codereview.chromium.org/1134643002 Cr-Commit-Position: refs/heads/master@{#329651}
* More base::Values-related bare pointer -> scoped_ptr conversionsestade2015-05-121-2/+1
| | | | | | | | | | main change: Value::CreateNullValue returns a scoped_ptr BUG=none Review URL: https://codereview.chromium.org/1129083003 Cr-Commit-Position: refs/heads/master@{#329443}
* media: Let VideoFrame carry more than one native texture.dcastagna2015-05-071-25/+36
| | | | | | | | | | | | | | | The goal of this patch is to be able to use VideoFrame to be created and to transport three R8 textures that represent a YUV frame. A new enum VideoFrame::TextureFormat has been added in order to determine how the textures attached to the VideoFrame should be interpreted when the VideoFrame::Format is NATIVE_TEXTURE. BUG= Review URL: https://codereview.chromium.org/1117423002 Cr-Commit-Position: refs/heads/master@{#328783}
* Add metadata to media::VideoFrame and plumb it through IPC/MediaStream.miu2015-03-031-0/+79
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This change has three main goals: First, to be able to pass extra information associated with each VideoFrame from the capture source to the downstream consumers (see bugs for details). Second, to eliminate redundancies in the current MediaStreamVideoSink API; specifically, media::VideoFrame contains most of the same properties as media::VideoCaptureFormat. Third, to fully support the separate VideoFrame concepts of "coded size" versus "visible size" in the capture pipeline, rather than force all producers/consumers to deal with packed data. (Using packed frame sizes can be suboptimal for performance in some use cases.) The metadata is stored in a base::DictionaryValue owned by media::VideoFrame to allow for structured data passing. DictionaryValue is a great choice since an efficient IPC (de)serialization implementation already exists, and the metadata can be easily pretty-printed for logging where needed. Also, it's logical for VideoFrame to own the metadata, as both need to be passed/shared together across threads without copying. Finally, this change includes one new use of the metadata as a motivation for its existence: The tab/desktop capture code now includes capture timing information, which will allow Cast streaming sessions to be analyzed for user experience improvements. In the future, some of the special-use-case data members in VideoFrame should be moved into the metadata. BUG=461116,462101 Review URL: https://codereview.chromium.org/955253002 Cr-Commit-Position: refs/heads/master@{#318954}
* gpu video: optimize HW video to SW canvas and implement it for WebRTC.dongseong.hwang2015-02-111-2/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently, very complicated callback mechanism is used to copy HW video to SW canvas in SkCanvasVideoRenderer. When Blink thread needs to readback HW video, the readback callback of VideoFrame is called, and then readback is executed in the media thread using gl context belonging to gpu decoder. It has two bad points: 1. Blink thread is blocked until the media thread gets readback done. 2. It's not implemented yet for WebRTC HW Video to be drawn on SW Canvas. In detail for #2, VideoCaptureImpl creates a texture VideoFrame using the mailbox made in browser process. VideoCaptureImpl doesn't use any gl context so the readback callback is not implemented. Now the callback is removed. This CL implements drawing HW Video on SW SkCanvas in SkCanvasVideoRenderer, so two bad points are resolved. 1. SkCanvasVideoRenderer draws HW Video on SW SkCanvas in Blink thread without interaction with the media thread. 2. WebRTC impl (i.e. VideoCaptureImpl) doesn't need to do anything because SkCanvasVideoRenderer has all logic to draw HW Video on SW SkCanvas. TEST=blink layout test virtual/gpu/fast/canvas/yuv-video-on-accelerated-canvas.html BUG=401058 Review URL: https://codereview.chromium.org/850993002 Cr-Commit-Position: refs/heads/master@{#315819}
* reland: Plumb allow_overlay flag for video path into ccachaulk2015-01-291-10/+12
| | | | | | | | This will allow hardware video overlays to be enabled in the compositor Review URL: https://codereview.chromium.org/806413004 Cr-Commit-Position: refs/heads/master@{#313806}
* Revert of Plumb allow_overlay flag for video path into cc (patchset #3 ↵jamescook2015-01-271-12/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | id:80001 of https://codereview.chromium.org/806413004/) Reason for revert: This breaks the Chrome OS daisy (32-bit ARM) builder: http://build.chromium.org/p/chromiumos.chromium/builders/Daisy%20%28chromium%29/builds/4364/steps/BuildPackages/logs/stdio It just looks like a missing callsite. Original issue's description: > Plumb allow_overlay flag for video path into cc > > This will allow hardware video overlays to be enabled in the compositor > > Committed: https://crrev.com/32c0609baa6c3eea2400c6fe899a0ff60a1358dd > Cr-Commit-Position: refs/heads/master@{#313310} TBR=jschuh@chromium.org,piman@chromium.org,alexst@chromium.org,dalecurtis@chromium.org,posciak@chromium.org,achaulk@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true Review URL: https://codereview.chromium.org/881893002 Cr-Commit-Position: refs/heads/master@{#313345}
* Plumb allow_overlay flag for video path into ccachaulk2015-01-271-10/+12
| | | | | | | | This will allow hardware video overlays to be enabled in the compositor Review URL: https://codereview.chromium.org/806413004 Cr-Commit-Position: refs/heads/master@{#313310}
* Standardize usage of virtual/override/final in media/dcheng2014-10-211-3/+3
| | | | | | | | | | | | This patch was automatically generated by applying clang fixit hints generated by the plugin to the source tree. BUG=417463 TBR=ddorwin@chromium.org Review URL: https://codereview.chromium.org/655713003 Cr-Commit-Position: refs/heads/master@{#300471}
* replace OVERRIDE and FINAL with override and final in media/mostynb2014-10-071-2/+2
| | | | | | | | BUG=417463 Review URL: https://codereview.chromium.org/623263003 Cr-Commit-Position: refs/heads/master@{#298317}
* Android media: VideoFrame should not store so many sync points.dongseong.hwang@intel.com2014-07-221-24/+31
| | | | | | | | | | | | | | | | | VideoFrame based on StreamTexture is reused on many frames. However, clients (e.g. compositor, WebGL) inserts a sync point every frame. So VideoFrame on Android can keep several mega byte sync points unnecessarily. This CL makes VideoFrame keep only one sync point. When a client set new sync point to VideoFrame and VideoFrame already keeps the sync point of another client, VideoFrame waits the previous sync point before inserting a new sync point. A client must provide a VideoFrame::SyncPointProvider so that VideoFrame can insert or wait a sync point. BUG=350925 Review URL: https://codereview.chromium.org/312803002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@284658 0039d316-1c4b-4281-b951-d872f2087c98
* Zero initialize the first allocation of a VideoFrame.dalecurtis@chromium.org2014-07-121-0/+13
| | | | | | | | | | | | Replicates FFmpeg's behavior for frame allocation. They do not zero the frame on subsequent pool reuse, so I have not done so either. BUG=390941,390944,390945 TEST=new unittest. Review URL: https://codereview.chromium.org/383893002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@282775 0039d316-1c4b-4281-b951-d872f2087c98
* HW Video: Make media::VideoFrame handle the sync point of the compositor as ↵dongseong.hwang@intel.com2014-04-301-29/+38
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | well as webgl and canvas. This makes it compatible when the video hw texture and WebGL destination texture are in different share groups. media::VideoFrame must receive multiple sync points from clients, because clients can be many. In WebGL case, only the compositor is the client of the mailbox in a frame. So we reuse MailboxHolder::sync_point as release sync point. However, media::VideoFrame has multiple clients, so media::VideoFrame must handle multiple release sync points. Let me explain the lifecycle of the mailbox of a video frame in detail, 1. The video decoder receives a new mailbox from gpu process. The video decoder doesn't insert a sync point, because all GPU operations for the mailbox already were executed in the gpu process. 2. Blink or the compositor reads the mailbox. After that, all clients must insert a release sync point. 3. When the ref count of the video frame is 0, the destructor of the video frame calls recycle callback of the video decoder. 4. The video decoder notifies reusable mailboxes to the gpu process after waiting for the release sync points. Currently, there are three providers that can make a texture type video frame: GpuVideoDecoder, RTCVideoDecoder, and VideoCapture. The video frame of VideoCapture is created in the browser process, not the gpu process. So, VideoCapture inserts a sync point before providing it to clients. BUG=127940, 350925, 362521 Review URL: https://codereview.chromium.org/175223003 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@267290 0039d316-1c4b-4281-b951-d872f2087c98
* Rename VideoFrame::{Get,Set}Timestamp() to {set_}timestamp().scherkus@chromium.org2014-04-101-1/+1
| | | | | | | | | | Makes the naming consistent with AudioBuffer, which is helpful now that DecoderStream<T> enforces API consistency. TBR=dmichael Review URL: https://codereview.chromium.org/229453004 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@262914 0039d316-1c4b-4281-b951-d872f2087c98
* Audit/fix use of media::VideoFrame::coded_size()sheu@chromium.org2014-03-271-15/+7
| | | | | | | | | | | | | | Add comments to media::VideoFrame about the meaning and use of coded_size(), visible_rect(), and natural_size(), and audit Chrome codebase to make sure uses of VideoFrame are consistent with this. This is in regards mostly to making sure that odd-width/height subsampled YUV format are handled correctly. BUG=344719 TEST=local build, run on CrOS snow, desktop Linux Review URL: https://codereview.chromium.org/178133005 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@259814 0039d316-1c4b-4281-b951-d872f2087c98
* Make sure natural_size is set when a frame is cropped.perkj@chromium.org2014-03-091-1/+4
| | | | | | | | | | | | | If the natural size is not set, the <video> tag will set its properties videoHeight and videoWidth to the original, uncropped width and height.If that is used for deciding the <video> render size- the aspect ratio will be wrong. This cl allow setting the natural_size as well as the visible_rect when calling media::VideoFrame::WrapVideoFrame. BUG=349450 R=fischman@chromium.org, tommi@chromium.org Review URL: https://codereview.chromium.org/189513004 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@255839 0039d316-1c4b-4281-b951-d872f2087c98
* Allow wrapping a media::VideoFrame with a new view_rect as long as the new ↵perkj@chromium.org2014-03-061-0/+33
| | | | | | | | | | | view_rect is within the original rect. BUG= 349450 R=fischman@chromium.org, tommi@chromium.org Review URL: https://codereview.chromium.org/187573006 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@255353 0039d316-1c4b-4281-b951-d872f2087c98
* Add gpu::MailboxHolder to hold state for a gpu::Mailboxsheu@chromium.org2014-02-031-33/+27
| | | | | | | | | | | | | | | | | | | | | | | | gpu::Mailbox by itself can hold only a texture id, but in common usage it comes with texture target and syncpoint information for cross-context sharing. To reduce repetition of this pattern, gpu::MailboxHolder holds: * a gpu::Mailbox * a GL texture target * a syncpoint index Refactor other classes to use a gpu::MailboxHolder instead of separate gpu::Mailbox and associated state. Syncpoints are created with uint32 indices; make sure all uses of syncpoints use the appropriate type. BUG=None TEST=local build, unittests on CrOS snow, desktop Linux TBR=piman@chromium.org, enn@chromium.orge, cevans@chromium.org, scherkus@chromium.org Review URL: https://codereview.chromium.org/132233041 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@248612 0039d316-1c4b-4281-b951-d872f2087c98
* Revert "Add gpu::MailboxHolder to hold state for a gpu::Mailbox"danakj@chromium.org2014-01-211-27/+33
| | | | | | | | | | | | | | | This reverts commit 9ee2343406a6fae9c8aacc7303f7b1e5a04aab9e. This patch is the source of the top crash in canary. See the bug for more details. TBR=sheu NOTREECHECKS=true BUG=336040 Review URL: https://codereview.chromium.org/129873005 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@245959 0039d316-1c4b-4281-b951-d872f2087c98
* Add gpu::MailboxHolder to hold state for a gpu::Mailboxsheu@chromium.org2014-01-181-33/+27
| | | | | | | | | | | | | | | | | | | | | | gpu::Mailbox by itself can hold only a texture id, but in common usage it comes with texture target and syncpoint information for cross-context sharing. To reduce repetition of this pattern, gpu::MailboxHolder holds: * a gpu::Mailbox * a GL texture target * a syncpoint index Refactor other classes to use a gpu::MailboxHolder instead of separate gpu::Mailbox and associated state. Syncpoints are created with uint32 indices; make sure all uses of syncpoints use uint32. BUG=None TEST=local build, unittests on CrOS snow, desktop Linux Review URL: https://codereview.chromium.org/105743004 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@245730 0039d316-1c4b-4281-b951-d872f2087c98
* Un-refcount media::VideoFrame::MailboxHoldersheu@chromium.org2013-12-041-165/+20
| | | | | | | | | | | | Make the media::VideoFrame exclusively own its MailboxHolder for mailbox video frames. BUG=None TEST=local build, run on CrOS snow Review URL: https://codereview.chromium.org/100453002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@238612 0039d316-1c4b-4281-b951-d872f2087c98
* Remove EMPTY from VideoFrame::Format.rileya@chromium.org2013-11-081-3/+3
| | | | | | | | | | | It was being used to indicate end-of-stream, which was sort of an abuse of the format enum. Instead, we now have a CreateEOSFrame(), rather than CreateEmptyFrame(), and an |end_of_stream_| member. BUG=313827 TBR=danakj Review URL: https://codereview.chromium.org/57403003 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@233776 0039d316-1c4b-4281-b951-d872f2087c98
* Re-land https://codereview.chromium.org/56713002/ with ChromeOS fix.rileya@chromium.org2013-11-071-22/+22
| | | | | | | | | | | | | Remove RGB32 from VideoFrame::Format. It wasn't used anywhere outside of the unit tests. BUG=313827 TBR=danakj Review URL: https://codereview.chromium.org/60573005 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@233670 0039d316-1c4b-4281-b951-d872f2087c98
* Revert 233046 "Remove RGB32 from VideoFrame::Format."shrikant@chromium.org2013-11-051-22/+22
| | | | | | | | | | | | | | | | | | | (Reverting as it seem to break ChromeOS, please re-land as soon as fixed.) > Remove RGB32 from VideoFrame::Format. > > It wasn't used anywhere outside of the unit tests. > > BUG=313827 > TBR=danakj > > Review URL: https://codereview.chromium.org/56713002 TBR=rileya@chromium.org Review URL: https://codereview.chromium.org/60393004 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@233106 0039d316-1c4b-4281-b951-d872f2087c98
* Remove RGB32 from VideoFrame::Format.rileya@chromium.org2013-11-051-22/+22
| | | | | | | | | | | It wasn't used anywhere outside of the unit tests. BUG=313827 TBR=danakj Review URL: https://codereview.chromium.org/56713002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@233046 0039d316-1c4b-4281-b951-d872f2087c98
* Send hardware video frames with mailboxes.danakj@chromium.org2013-06-251-0/+213
| | | | | | | | | | | | | | | | | | | | Change media::VideoFrame from holding a raw texture id to instead hold a gpu::Mailbox. The hardware video decoders produce a mailbox on their context from the texture id before putting it in the VideoFrame, and consume the mailbox again when they receive the texture id back. In the compositor, we hold onto the VideoFrame::MailboxHolder as long as the mailboxed texture is in use in the compositor (or its parent). This keeps the video decoders from writing to the texture id, as they register a callback in the VideoFrame to be called when it is destroyed. BUG=179729 Review URL: https://chromiumcodereview.appspot.com/14199002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@208568 0039d316-1c4b-4281-b951-d872f2087c98
* Use a direct include of strings headers in ipc/, jingle/, media/.avi@chromium.org2013-06-111-1/+1
| | | | | | | | | | BUG=247723 TEST=none TBR=ben@chromium.org Review URL: https://chromiumcodereview.appspot.com/16684003 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@205436 0039d316-1c4b-4281-b951-d872f2087c98
generated by cgit v1.1 at 2025-01-30 10:54:12 +0000