MCVideo makes use of many of the same capabilities that were originally defined for MCPTT in TS 22.179
and now are mostly specified at stage 1 in the MCCoRe specification 
. Such capabilities include, but are not limited to, Group Communication, Group Management, Affiliation, Security and Confidentiality. The MCVideo service also allows the same user to have multiple user profiles defined and to simultaneously use multiple UEs.
However, the MCVideo Service also differs from MCPTT in some respects. In MCPTT there is a specific way of floor control to assert good order and appropriate use of priority to control and manage situations where multiple users in a group might attempt to speak at the same time. Simultaneous speech can degrade intelligibility of communications. The role of floor control is to manage who can transmit at a point in time and who will have to wait to speak to the group. In MCVideo the control approach is more varied. There is admission control to manage the appropriate access to network resources according to the user's priority and the UE's capabilities. In some cases, this may include control to restrict simultaneous video being sent from different users in the group (likely to be useful for network capacity/UE limitations). From a user perspective there is not the same need to restrict multiple simultaneous transmission and presentation of video within the same group, as if different streams are available at the UE then the user could choose which, to look at them simultaneously. It is assumed that users that are permitted to transmit video are generally allowed to send video to a group, unless there is a network capacity/UE restriction rule that places limitations on the number of videos to that group. In this case users would be trained in appropriate use of that choice.
The point at which video is transmitted to a group may vary, e.g. a user may press to send video and wait until allowed by the network to stream to the affiliated group according to the admission control policy. However, the user may be able to "force" the immediate transmission of the video information, for example, by pressing and holding the button to send video. In this case the UE will take immediate action to capture the video for onward transmission as soon as permitted. Also the UE will communicate the immediate nature of the video to the network, which may choose to authorise the access and then locally store it for onward transmission or stream it immediately to the relevant group. In this case the video may be slightly delayed due to the start up delay. It is also possible for the user to mark their video communication as Emergency or Imminent Peril and this will immediately elevate the priority of video communications for this group above non emergency video.
A further way that MCVideo differs from MCPTT is that group members may be configured not to automatically receive video. Video may be streamed up to the network and users invited to join when/if convenient/appropriate for them or only if they have access to a multicast enabled device. An example might be where a Police Officer driving to an incident is not able to view a video of the events unfolding, but his partner in the car can usefully receive and view the video. In this case MCVideo working together with MCPTT will provide a powerful solution to know which videos to receive for those best placed to receive them. This user reception function might be used to late join a video stream or with the store and forward capability for video.
Surveillance cameras could also use the MCVideo service in which case, in addition to the existing video storage and monitoring activity already used for the surveillance camera, authority may be given to users in the MCVideo system to connect to, control receive and forward video either to an individual or to a group. Surveillance includes the ability to locally and remotely activate video streaming automatically or on demand, to control the positioning, optical and video parameters of the camera and to recognize video features. The camera may be exclusively in the MCVideo system, or it may be accessed by connection from the MCVideo Service via an existing external interface for surveillance camera networks. In this latter case, the external interface is expected to provide requests for control and onward streaming of video, which will be managed together with the normal control network for those cameras. This external interface is outside of the control of 3GPP and existing standards may be used for part or all of the functionality of this interface e.g. TVNP.
MCVideo group communication aspects are very similar to MCPTT. Each user may be a member of several, even many, groups. Membership is determined by administration control and provides a user identity based level of authority to join a group. Each user chooses to affiliate to the groups that they want to receive video communication from. Once a user has successfully affiliated to a group they will begin to receive video communications directed to that group according to the video distribution approach used. A user who wishes to send video to a group shall select the relevant group and then they may send video to it.
Groups may interwork with other MCX Service groups, so a single group could be configured for MCPTT and MCVideo and any other combination of MCX Services. The present document does not describe how that is managed, it could be a single group with a single affiliate message and separate attributes for each service or it may be different groups managed together by administrator control and linked in the UE to allow single user action to trigger the same action e.g. affiliate, for each relevant service. It shall be possible for services actions to be taken independently because some UE may not be capable of all of the linked services and some users may not be given access to some services or some groups for some services.
4.5 Security Word‑p. 10
All MCVideo communications, video and supporting signalling and messaging which start and end entirely within MCVideo systems are protected by the security mechanisms used for other MCX Services and defined in MCCoRe. MCVideo communications to and from external end points may be security protected and routed through the normal MCVideo system and then forwarded into the required network for onward delivery to the external end point. Alternatively, such communication could just use the protection and routing provided by the transport network. Given the potential use of stored video information in evidentiary procedures, ensuring the integrity, confidentiality and accuracy of the video information and its associated meta-data is of paramount importance for MCVideo Data.
MCVideo has the same confidentiality requirements as for other MCX Services and are defined in MCCoRe .
All users have a unique identity and at least one alias for other MCServices. A single user can have the same or different aliases for any and every MCX Service and group that they are members of, but user identities and aliases for each user resolve to a unique identity even among multiple independent MCX Services in the same domain (e.g. State or Country. In this way, a user who identifies another user using one service will be able to make contact using a different service.
For example, multiple groups and multiple Mission Critical organisations working in the same building might use a map application, which shows them where all the other users are. It should be possible for one user to be able to identify a nearby user from the map and request a video (via the MCVideo Service) of the situation from a certain vantage in order to take appropriate action. The other user may be in a combined group for the mapping application (MCData) but not currently known affiliated in any other group along with the requesting user. User identities requirements are specified in MCCoRe 
It is assumed in the present document that, even when there is no configured inter-service interworking action, the User ID for any user detected in any MCService can be used to establish video communication to that user, subject to the user being authorised for the MCVideo Service and the UE being MCVideo capable.
As with MCPTT which has non-speech aspects to the service, in a similar way there are non-video aspects for the MCVideo service. Many of these services are in common with MCPTT such as Emergency Alert signalling, Location messaging etc. but some are also distinct such as video camera control (PTZ - Pan, Tilt, Zoom).
It may also be possible for some MCCoRe aspects to work in the same way between MCVideo and MCData, for example store and forward video.
4.8.2 Camera control Word‑p. 11
Camera control is specified in MCVideo but it is not intended to define a new PTZ protocol. Where protocols exist, these should be assumed for MCVideo e.g. TVNP for PTZ although TVNP is unlikely to be the only relevant standard so there should be provision to use alternative standards according to need.
As with other MCServices, from time to time MCVideo Service providing UE location is required. Ideally the same location messaging for a MCService UE supporting multiple services could be used to update all relevant services at the same time. Location messaging requirements are defined at stage 1 in MCCoRe specification 
As with other MCServices, the MCVideo Service will use an Emergency Alert to indicate an emergency state and to gain transport network priority. When multiple services are operating together it should be configurable whether the Emergency state of one service affects or not the Emergency state of another service. This situation may be complex to handle between groups using different services. Operational requirements are defined in the Interworking clause of MCCoRe specification 
In general, an MCVideo UE can support several video codecs (or video codec operating modes) of which some could be optional, some could be locally/regionally mandated via regulation, and one is globally mandated via 3GPP implicit (by reference) or explicit (by detailed specification) standardization as the mandatory universal interoperability video codec. If MCVideo UEs participate in a video session, they may need to negotiate or rely on defaults or other rules to establish a common video codec for the video session. Transcoding is not desirable on grounds of complexity and efficiency and in order to enable end-to-end ciphering.
The MCVideo service supports both combined (for efficiency and synchronization) and separate (for cases when the video component cannot or will not be received) handling of video and audio streams.