chrome/common/encrypted_media_messages_android.h - Issue 23513055: Populate canPlayType to renderer

Side by Side Diff: chrome/common/encrypted_media_messages_android.h

Issue 23513055: Populate canPlayType to renderer (Closed) Base URL: svn://svn.chromium.org/chrome/trunk/src

Patch Set: moving ipc to chrome/common/ Created 7 years, 3 months ago

Use n/p to move between diff chunks; N/P to move between comments. Draft comments are only viewable by you.

Jump to:

View unified diff | Download patch | Annotate | Revision Log

« chrome/browser/media/encrypted_media_message_filter_android.cc ('K') | « chrome/common/common_message_generator.h ('k') | chrome/common/render_messages.h » ('j') | chrome/common/render_messages.h » ('J')
Toggle Intra-line Diffs ('i') | Expand Comments ('e') | Collapse Comments ('c') | Hide Comments ('s')

OLD	NEW
(Empty)
	1 // Copyright 2013 The Chromium Authors. All rights reserved.

	2 // Use of this source code is governed by a BSD-style license that can be

	3 // found in the LICENSE file.

	4

	5 // IPC messages for EME on android.

	6 // Multiply-included message file, hence no include guard.

	7

	8 #include <string>

	9 #include <vector>

	10

	11 #include "ipc/ipc_message_macros.h"

	12

	13 #define IPC_MESSAGE_START EncryptedMediaMsgStart

	14

	15 IPC_STRUCT_BEGIN(SupportedKeySystem)

	16 // Key system UUID.

	17 IPC_STRUCT_MEMBER(std::vector<uint8>, uuid)

	18

	19 // Name of the key system.
	ddorwin 2013/09/16 17:58:10 I don't think the Android IPC layer needs to know I don't think the Android IPC layer needs to know about key system strings or parents. We probably do want to have some way to pass attribute(s) of the uuid so we can add subdomains. xhwang 2013/09/17 18:56:46 Yeah, we probably only care about UUID, container Show quoted text On 2013/09/16 17:58:10, ddorwin wrote: > I don't think the Android IPC layer needs to know about key system strings or > parents. We probably do want to have some way to pass attribute(s) of the uuid > so we can add subdomains. Yeah, we probably only care about UUID, container type and codecs here. KeySystemInfo et al will do the UUID -> key_system translation. qinmin 2013/09/17 19:21:06 Done. Show quoted text On 2013/09/16 17:58:10, ddorwin wrote: > I don't think the Android IPC layer needs to know about key system strings or > parents. We probably do want to have some way to pass attribute(s) of the uuid > so we can add subdomains. Done.
	20 IPC_STRUCT_MEMBER(std::string, key_system)

	21

	22 // Name of the parent key system.

	23 IPC_STRUCT_MEMBER(std::string, parent_key_system)

	24

	25 // A list of supported codecs.

	26 IPC_STRUCT_MEMBER(std::vector<std::string>, codecs)

	27

	28 // Whether video composition is enabled.

	29 // TODO(qinmin): this may be replaced by a new key_system string.

	30 IPC_STRUCT_MEMBER(bool, video_composition_enabled)
	xhwang 2013/09/17 18:56:46 Also add container type here? For now, we only sup Also add container type here? For now, we only support MP4. xhwang 2013/09/17 18:56:46 Can we have: IPC_STRUCT_MEMBER(std::vector<std::s Can we have: IPC_STRUCT_MEMBER(std::vector<std::string>, compositing_codecs) and IPC_STRUCT_MEMBER(std::vector<std::string>, non_compositing_codecs) Then we can probably drop \|video_composition_enabled\|. qinmin 2013/09/17 21:26:23 passing the codecs bitmask inside the IPC On 2013/ passing the codecs bitmask inside the IPC On 2013/09/17 18:56:46, xhwang wrote: Show quoted text > Also add container type here? For now, we only support MP4. qinmin 2013/09/17 21:26:23 Done. Show quoted text On 2013/09/17 18:56:46, xhwang wrote: > Can we have: > > IPC_STRUCT_MEMBER(std::vector<std::string>, compositing_codecs) > > and > > IPC_STRUCT_MEMBER(std::vector<std::string>, non_compositing_codecs) > > Then we can probably drop \|video_composition_enabled\|. Done.
	31 IPC_STRUCT_END()

	32

	33 // Messages sent from the renderer to the browser.

	34

	35 // Synchronously get a list of supported EME key systems.

	36 IPC_SYNC_MESSAGE_ROUTED0_1(ChromeViewHostMsg_GetSupportedKeySystems,

	37 std::vector<SupportedKeySystem>)
	xhwang 2013/09/17 18:56:46 It seems the UUID, container types and codecs are It seems the UUID, container types and codecs are orthogonal to each other. If we have two lists of codecs as suggested above (compositing_codecs and non_compositing_codecs). Then we don't need the std::vector here. Only one SupportedKeySystem will have all information we need. qinmin 2013/09/17 21:26:23 Done. Show quoted text On 2013/09/17 18:56:46, xhwang wrote: > It seems the UUID, container types and codecs are orthogonal to each other. If > we have two lists of codecs as suggested above (compositing_codecs and > non_compositing_codecs). Then we don't need the std::vector here. Only one > SupportedKeySystem will have all information we need. Done.
OLD	NEW