具体实施方式
本发明实施例提供了一种媒体处理方法及媒体处理系统以及相关设备,能够提高系统性能并提高用户体验。
请参阅图1,本发明实施例中媒体处理方法一个实施例包括:
101、接收第一媒体处理请求;
本实施例中,AS可以从对端用户接收第一媒体处理请求,例如对端用户请求增加媒体的请求;或从本端受控端用户设备(Controllee UE)接收第一媒体处理请求,例如本端受控端用户设备请求删除自身媒体的请求,该第一媒体处理请求中包含有对应的媒体。
需要说明的是,本实施例中的AS在实际应用中可以为SCC AS,也可以为其他类型的AS,具体类型此处不作限定。
102、向各控制端用户设备UE发送第一媒体处理请求;
AS在接收到第一媒体处理请求之后,会向与对端用户正在进行会话的本端用户的各控制端UE发送媒体第一处理请求。
本端用户的控制端UE至少包括第一控制端UE以及第二控制端UE,还可以进一步包括更多的控制端UE。
103、接收第一控制端UE针对第一媒体处理请求反馈的第二媒体处理请求;
各控制端UE在接收到媒体处理请求之后,会向AS反馈媒体处理请求,由于传输路径和网络状况的不同,各控制端UE反馈的媒体处理请求可能会先后到达AS。
本实施例中,假设AS会最先收到第一控制端UE反馈的第二媒体处理请求,例如,将该媒体转移到第二控制端UE中传输。
如果2个以上控制端UE发出的媒体处理请求同时到达AS,则AS可以根据用户的偏好和运营商策略仅选择一个控制端UE的处理请求进行处理。
104、判断是否接收到第二控制端UE针对第一媒体处理请求反馈的第三媒体处理请求,若是,则执行步骤105,若否,则执行步骤107;
本实施例中,AS在接收到第一控制端UE反馈的第二媒体处理请求之后,等待第二控制端UE针对第一媒体处理请求反馈的第三媒体处理请求。
105、判断第二控制端UE是否同意在自身传输媒体,若同意,则执行步骤106,若不同意,则执行步骤107;
当收到第二控制端UE的第三媒体处理请求后,可以根据第三媒体处理请求判断第二控制端UE是否同意在自身传输媒体,例如,当第二控制端UE接受了媒体在其自身传输,则认为同意,当第二控制端UE拒绝媒体在其自身传输或将发起媒体转移到其他UE的请求时,则认为不同意。
106、向第一控制端UE发送第一通知消息以指示媒体处理成功;
若第二控制端UE的第三媒体处理请求是同意在自身传输媒体,则AS可以向第一控制端UE发送第一通知消息以指示媒体处理成功,不再进行后续的媒体转移处理过程,之后第一控制端UE向AS返回确认消息,AS再向对端用户发送确认消息,则媒体处理过程完成。
如果存在第一、第二控制端UE外的其他控制端UE,AS在收到第二媒体处理请求后,需要向其他控制端UE发送取消消息。
107、向第一控制端UE发送第二通知消息以指示媒体处理失败。
若第二控制端UE的第三媒体处理请求是不同意在自身传输该媒体,则AS向第一控制端UE发送第二通知消息以指示第一控制端UE第二媒体处理请求失败。此时第一控制端UE可以选择将媒体在自身传输、转移到其他UE或拒绝该媒体等操作。
需要说明的是,若在预置时间内未收到第二控制端UE针对第一媒体处理请求反馈的第三媒体处理请求,则认为第二控制端UE不同意媒体在自身进行传输,则同样执行步骤107。
如果存在第一、第二控制端UE外的其他控制端UE,AS在收到第二媒体处理请求后,需要向其他控制端UE发送取消消息。如果AS未收到第三媒体处理请求,则AS也需要向第二控制端UE发送取消消息。
本实施例中,AS向各控制端UE发送第一媒体处理请求之后,若第一控制端UE的针对第一媒体处理请求反馈的第二媒体处理请求先到达AS,且要求媒体在第二控制端UE进行传输时,则AS会等待第二控制端UE针对第一媒体处理请求反馈的第三媒体处理请求,并判断第二控制端UE是否接受该媒体在其自身传输,若第二控制端UE接受了媒体在其自身传输,则AS会直接向第一控制端UE发送第一通知消息以指示媒体处理成功,若第二控制端UE不接受在其自身传输,则AS直接向第一控制端UE发送第二通知消息以指示媒体处理失败,因此,AS无需向第二控制端UE重复发送相同内容的媒体处理请求,从而可以减少网络数据传输量,提高系统性能;
其次,由于AS不会向第二控制端UE发送两次相同内容的媒体处理请求,因此,第二控制端UE所执行的操作为有效操作,不会重复执行相同的处理,因此减少了操作时长,增加了用户体验。
为便于理解,下面以两个具体实例对本实施例中的媒体处理方法进行说明:
一、第二控制端UE同意在自身传输媒体:
具体请参阅图2,本发明实施例中媒体处理方法另一实施例包括:
201、第一控制端UE与对端用户传输媒体A;
202、第二控制端UE与对端用户传输媒体B;
203~204、第一控制端UE向第二控制端UE共享控制权;
205、对端用户通过re-Invite消息向SCC AS1发送第一媒体处理请求;
本实施例中,以媒体增加请求作为媒体处理请求的例子进行说明,在实际应用中,该媒体处理请求还可以是其他的请求,例如媒体修改请求等,具体此处不作限定。
206、SCC AS1采用re-Invite消息向第一控制端UE发送第一媒体处理请求;
207~208、SCC AS1通过SCC AS2采用re-Invite消息向第二控制端UE发送第一媒体处理请求;
需要说明的是,本实施例中,步骤206与207为同时执行的步骤,没有先后顺序。
209、SCC AS1接收第一控制端UE的第二媒体处理请求;
本实施例中,假设第一控制端UE针对该第一媒体处理请求的第二媒体处理请求消息比第二控制端UE的第三媒体处理请求消息先到达SCC AS1。
第一控制端UE的第二媒体处理请求消息可以指示媒体在第二控制端UE中进行传输。
210、SCC AS1等待第二控制端UE的第三媒体处理请求消息;
SCC AS1在接收到第一控制端UE发送的第二媒体处理请求消息之后,获知第一控制端UE指示第二控制端UE传输媒体,则SCC AS1等待第二控制端UE的第三媒体处理请求消息。
211~212、第二控制端UE通过SCC AS2向SCC AS1发送200OK消息;
当第二控制端UE在步骤208中接收到SCC AS1发送的第一媒体处理请求之后,若第二控制端UE确定由自身来传输该媒体,则会通过SCC AS2向SCC AS1发送200OK消息。
213、SCC AS1向第一控制端UE发送第一通知消息;
当SCC AS1接收到第二控制端UE反馈的第三媒体处理请求消息为200OK消息时,则确定第二控制端UE同意自身传输媒体,而第一控制端UE发送的应答消息正是要求第二控制端UE传输媒体,则SCC AS1直接向第一控制端UE发送第一通知消息,以告知操作成功,不需要再进行后续的媒体转移处理过程。
214~215、第一控制端UE通过SCC AS1向对端用户发送200OK消息。
需要说明的是,若本端用户有三个或以上的控制端UE,即除了第一控制端UE以及第二控制端UE之外,还有其他的控制端UE,则SCC AS1还会在步骤206或207的同时向其他的控制端UE发送第一媒体处理请求,并且SCCAS1在步骤209之后会向除第一控制端UE以及第二控制端UE之外的其他控制端UE发送取消消息以取消发送至这些控制端UE的媒体处理请求。
本实施例中描述的SCC AS1与SCC AS2在实际应用中可以为同一个物理实体,则SCC AS1与SCC AS2之间的交互为网元内部交互,可以理解的是,SCC AS1与SCC AS2也可以为不同的物理实体,则SCC AS1与SCC AS2之间的交互为网元间交互。
本实施例中,步骤209时,SCC AS1会先接收到第一控制端UE反馈的第二媒体处理请求消息,在实际应用中,SCC AS1若同时接收到两个控制端UE反馈的媒体处理请求消息,则SCC AS1可以根据用户的偏好或运营商策略选择其中的一个媒体处理请求消息作为最先收到的媒体处理请求消息,则后续处理与上述处理过程相同。
二、第二控制端UE不同意在自身传输媒体:
具体请参阅图3,本发明实施例中媒体处理方法另一实施例包括:
301~310、与前述图2所示实施例中的步骤201至210相同,此处不再赘述;
311~312、第二控制端UE通过SCC AS2向SCC AS1发送第三媒体处理请求;
当第二控制端UE在步骤308中接收到SCC AS1发送的第一媒体处理请求之后,可以通过SCC AS2向SCC AS1发送第三媒体处理请求。
这里的第三媒体处理请求可以是媒体转移消息或拒绝传输消息(例如4xx消息)。若第二控制端UE发送的第三媒体处理请求是媒体转移请求,则SCCAS1还需要进一步向第二控制端UE发送拒绝消息,该拒绝消息的call-info消息头中指明拒绝的原因,例如可以为“禁止转移”等。
需要说明的是,在实际应用中,第二控制端UE也可能不反馈任何应答消息,即不执行步骤311~312,则在这种情况下,SCC AS1向第二控制端UE发送了第一媒体处理请求之后,即启动定时器,当该定时器超过预置的时长仍未收到第二控制端UE反馈的应答消息时,则默认认为第二控制端UE不同意在自身传输媒体,则SCC AS1需要向第二控制端UE发送取消消息。
313、SCC AS1向第一控制端UE发送第二通知消息;
当SCC AS1确定第二控制端UE不同意在自身传输媒体时,则SCC AS1向第一控制端UE发送第二通知消息以指示第一控制端UE拒绝媒体处理请求。
314、第一控制端UE进行相应处理;
第一控制端UE接收到SCC AS1发送的第二通知消息之后,则进行相应的处理,可以拒绝媒体处理请求,或安排其他控制端UE传输媒体,具体处理过程此处不作限定。
315、SCC AS1向第二控制端UE提供当前联合会话的状态信息。
本实施例中,SCC AS1具体可以通过通知(Notify)消息或re-Invite消息向第二控制端UE提供当前联合会话的状态,具体的消息体可以为:
<?xml version=″1.0″?>
<collaborative-session xmlns=″urn:ietf:params:xml:ns:
collaborative-session″>
<media-description media_type=″Media-A″
port=″6787″
aor=″sip:UE-1@example.com″
media_state=″sendrecv″
/>
<media-description media_type=″Media-B″
port=″6788″
aor=″sip:UE-2@example.com″
media_state=″sendrecv″
/>
</collaborative-session>
该联合会话的状态用以表明当前传输的媒体有哪些媒体类型,各媒体所在的UE,所使用的端口,以及媒体状态等信息。
需要说明的是,若本端用户有三个或以上的控制端UE,即除了第一控制端UE以及第二控制端UE之外,还有其他的控制端UE,则SCC AS1还会在步骤306或307的同时向其他的控制端UE发送第一媒体处理请求,并且SCCAS1在步骤309之后会向除第一控制端UE以及第二控制端UE之外的其他控制端UE发送取消消息以取消发送至这些控制端UE的媒体处理请求。
本实施例中描述的SCC AS1与SCC AS2在实际应用中可以为同一个物理实体,则SCC AS1与SCC AS2之间的交互为网元内部交互,可以理解的是,SCC AS1与SCC AS2也可以为不同的物理实体,则SCC AS1与SCC AS2之间的交互为网元间交互。
本实施例中,步骤309时,SCC AS1会先接收到第一控制端UE发送的第二媒体处理请求,在实际应用中,SCC AS1若同时接收到两个控制端UE反馈的媒体处理请求,则SCC AS1可以根据用户的偏好或运营商策略选择其中的一个媒体处理请求作为最先收到的应答消息,则后续处理与上述处理过程相同。
本实施例中,AS向各控制端UE发送第一媒体处理请求之后,若第一控制端UE的针对第一媒体处理请求反馈的第二媒体处理请求先到达AS,且要求媒体在第二控制端UE进行传输时,则AS会等待第二控制端UE针对第一媒体处理请求反馈的第三媒体处理请求,并判断第二控制端UE是否接受该媒体在其自身传输,若第二控制端UE接受了媒体处理在其自身传输,则AS会直接向第一控制端UE发送第一通知消息以指示媒体处理成功,若第二控制端UE不接受在其自身传输,则AS直接发送向第一控制端UE发送第二通知消息以指示媒体处理失败,因此,AS无需向第二控制端UE重复发送相同内容的媒体处理请求,从而可以减少网络数据传输量,提高系统性能;
其次,由于AS不会向第二控制端UE发送两次相同内容的媒体处理请求,因此,第二控制端UE所执行的操作为有效操作,不会重复执行相同的处理,因此减少了操作时长,增加了用户体验。
下面介绍本发明实施例中另一种媒体处理方法,请参阅图4,本发明实施例中媒体处理方法另一实施例包括:
401、接收第一控制端UE发送的控制权共享请求;
本实施例中,在执行联合会话的控制权共享过程中,AS会接收到第一控制端UE发送的控制权共享请求,该控制权共享请求指示将控制权共享给第二控制端UE,该控制权共享请求中包含第一控制端UE以及第二控制端UE的优先级信息。
402、当接收到媒体处理请求时,仅向优先级最高的控制端UE发送媒体处理请求。
AS接收到第一控制端UE发送的控制权共享请求之后,会记录第一控制端UE的优先级以及第二控制端UE的优先级。
当从对端用户接收到媒体处理请求时,AS仅会向优先级最高的控制端UE发送媒体处理请求。
本实施例中,由于第一控制端UE发送的控制权共享请求中指示将控制权共享给第二控制端UE,该控制权共享请求中包含第一控制端UE以及第二控制端UE的优先级信息,因此AS在接收到媒体处理请求时,会按照该优先级,仅向优先级最高的控制端UE发送媒体处理请求,由于只会有一个控制端UE接收到媒体处理请求,则可以避免多个控制端UE同时接收到媒体处理请求时所导致的操作冲突,因此可以避免第二控制端UE多次接收到媒体处理请求,从而可以减少网络数据传输量,提高系统性能;
其次,由于AS不会向第二控制端UE发送两次相同内容的媒体处理请求,因此,第二控制端UE所执行的操作为有效操作,不会重复执行相同的处理,因此减少了操作时长,增加了用户体验。
上面是从AS的角度进行描述,下面从第一控制端UE的角度进行描述,大致流程为:
(1)第一控制端UE确定需要共享控制权的第二控制端UE;
第一控制端UE可以根据本端用户的指令将控制权共享给第二控制端UE,具体的确定过程此处不作限定。
(2)第一控制端UE生成第一控制端UE以及第二控制端UE的优先级;
在确定了第二控制端UE之后,第一控制端UE即可生成优先级。
(3)第一控制端UE向应用服务器发送控制权共享请求。
本实施例中,该控制权共享请求指示将控制权共享给第二控制端UE,该控制权共享请求中包含第一控制端UE以及第二控制端UE的优先级信息,之后AS即可根据该优先级发送媒体处理请求。
为便于理解,下面以一具体实例进行说明,请参阅图5,本发明实施例中媒体处理方法另一实施例包括:
501、第一控制端UE与对端用户传输媒体A;
502、第二控制端UE与对端用户传输媒体B;
503~504、第一控制端UE向第二控制端UE共享控制权;
第一控制端UE发起将联合会话控制权共享给第二控制端UE的请求,在请求中可以包括如下信息:
共享联合会话控制权的指示;
控制权共享的发起方为第一控制端UE的指示;
控制权共享的目标方为第二控制端UE的指示;
第一控制端UE和/或第二控制端UE在联合会话中控制权的优先级的指示;可以是第一控制端UE为主控制端(master)、第一控制端UE为辅控制端(slave)的指示,或第一控制端UE的优先级为高,第一控制端UE的优先级为低的指示。
505、SCC AS1执行校验过程;
SCC AS1在接收到第一控制端UE发送的控制权共享请求之后,会判断第一控制端UE是否可以将控制权共享给第二控制端UE,具体的校验过程此处不作限定。
506、SCC AS1建立联合会话控制路径;
若SCC AS1确定第一控制端UE可以将控制端共享给第二控制端UE,则SCC AS1通过SCC AS2与第二控制端UE建立会话控制路径,即用于控制联合会话的接入分支,并向第二控制端UE告知其优先级。
507、对端用户通过re-Invite消息向SCC AS1发送媒体增加请求;
本实施例中,以媒体增加请求作为媒体处理请求的例子进行说明,在实际应用中,该媒体处理请求还可以是其他的请求,例如媒体修改请求等,具体此处不作限定。
508、SCC AS1采用re-Invite消息向第一控制端UE发送媒体增加请求;
当SCC AS1接收到媒体增加请求时,会根据优先级确定第一控制端UE的优先级高于第二控制端UE的优先级,则向第一控制端UE发送媒体增加请求。
需要说明的是,若第一控制端UE向多个控制端UE共享了控制权,则这些控制端UE的优先级也均低于第一控制端UE,则SCC AS1会向优先级最高的第一控制端UE发送媒体增加请求。
509、第一控制端UE执行后续的处理过程。
需要说明的是,若SCC AS1在步骤508之后的预置时长之内未能收到第一控制端UE反馈的应答消息,则SCC AS1可以认为第一控制端UE失效,则此时SCC AS1可以按照优先级顺序向优先级次高的控制端UE发送媒体增加请求,以此类推,每次只发送一个媒体增加请求。
本实施例中,由于第一控制端UE发送的控制权共享请求中指示将控制权共享给第二控制端UE,该控制权共享请求中包含第一控制端UE以及第二控制端UE的优先级信息,因此AS在接收到媒体处理请求时,会按照该优先级,仅向优先级最高的控制端UE发送媒体处理请求,由于只会有一个控制端UE接收到媒体处理请求,则可以避免多个控制端UE同时接收到媒体处理请求时所导致的操作冲突,因此可以避免第二控制端UE多次接收到媒体处理请求,从而可以减少网络数据传输量,提高系统性能;
其次,由于AS不会向第二控制端UE发送两次相同内容的媒体处理请求,因此,第二控制端UE所执行的操作为有效操作,不会重复执行相同的处理,因此减少了操作时长,增加了用户体验。
下面对本发明实施例中的应用服务器进行说明,请参阅图6,本发明实施例中应用服务器一个实施例包括:
请求接收单元601,用于接收第一媒体处理请求;
请求发送单元602,用于向各控制端用户设备UE发送第一媒体处理请求,各控制端UE至少包括第一控制端UE以及第二控制端UE;
应答接收单元603,用于接收第一控制端UE针对第一媒体处理请求反馈的第二媒体处理请求,第二媒体处理请求指示媒体在第二控制端UE中进行传输;
通知单元604,用于在应答接收单元接收第二控制端UE针对第一媒体处理请求反馈的第三媒体处理请求时,若第二控制端UE同意在自身传输媒体,则向第一控制端UE发送第一通知消息以指示媒体处理成功,若第二控制端UE不同意在自身传输媒体,则向第一控制端UE发送第二通知消息以指示媒体处理失败。
需要说明的是,若本实施例中除了第一控制端UE以及第二控制端UE之外,还包括有其他的控制端UE,则本实施例中的应用服务器还可以进一步包括:
取消单元605,用于向除第一控制端UE以及第二控制端UE之外的其他控制端UE发送取消消息以取消发送给其他控制端UE的媒体处理请求。
本实施例中的应用服务器还可以进一步包括:
确定单元606,用于当第三媒体处理请求为200OK消息时确定第二控制端UE同意在自身传输媒体,当第三媒体处理请求为媒体转移消息或拒绝传输消息时确定第二控制端UE不同意在自身传输媒体,当应答接收单元在预置的时长内未接收到第二控制端UE针对第一媒体处理请求反馈的第三媒体处理请求时确定第二控制端UE不同意在自身传输媒体。
需要说明的是,本实施例中的确定单元606具体确定第二控制端UE是否同意在自身传输媒体的过程与前述图2以及图3所示的实施例中描述的过程类似,此处不再赘述。
本实施例中,请求发送单元602向各控制端UE发送第一媒体处理请求之后,若第一控制端UE的针对第一媒体处理请求反馈的第二媒体处理请求先到达AS,且要求媒体在第二控制端UE进行传输时,则AS会等待第二控制端UE针对第一媒体处理请求反馈的第三媒体处理请求,并判断第二控制端UE是否接受该媒体在其自身传输,若第二控制端UE接受了媒体在其自身传输,则通知单元604会直接向第一控制端UE发送第一通知消息以指示媒体处理成功,若第二控制端UE不接受在其自身传输,则通知单元604直接向第一控制端UE发送第二通知消息以指示媒体处理失败,因此,AS无需向第二控制端UE重复发送相同内容的媒体处理请求,从而可以减少网络数据传输量,提高系统性能;
其次,由于AS不会向第二控制端UE发送两次相同内容的媒体处理请求,因此,第二控制端UE所执行的操作为有效操作,不会重复执行相同的处理,因此减少了操作时长,增加了用户体验。
请参阅图7,本发明实施例中应用服务器另一实施例包括:
共享请求接收单元701,用于接收第一控制端UE发送的控制权共享请求,控制权共享请求指示将控制权共享给第二控制端UE,控制权共享请求包含第一控制端UE以及第二控制端UE的优先级信息;
处理请求接收单元702,用于接收媒体处理请求;
第一发送单元703,用于仅向优先级最高的控制端UE发送媒体处理请求。
本实施例中的应用服务器还可以进一步包括:
控制建立单元704,用于判断是否允许将控制权共享给第二控制端UE,若允许,则为第二控制端UE建立用于控制联合会话的接入分支,并向第二控制端UE告知其优先级。
本实施例中的应用服务器还可以进一步包括:
第二发送单元705,用于向下一优先级较低的控制端UE发送媒体处理请求;
控制单元706,用于判断在预置时长内是否收到优先级最高的控制端UE反馈的应答消息,若未收到,则触发第二发送单元执行相应操作。
本实施例中,由于第一控制端UE发送的控制权共享请求中指示将控制权共享给第二控制端UE,控制权共享请求包含第一控制端UE以及第二控制端UE的优先级信息,因此处理请求接收单元702在接收到媒体处理请求时,第一发送单元703会按照该优先级,仅向优先级最高的控制端UE发送媒体处理请求,由于只会有一个控制端UE接收到媒体处理请求,则可以避免多个控制端UE同时接收到媒体处理请求时所导致的操作冲突,因此可以避免第二控制端UE多次接收到媒体处理请求,从而可以减少网络数据传输量,提高系统性能;
其次,由于第一发送单元703不会向第二控制端UE发送两次相同内容的媒体处理请求,因此,第二控制端UE所执行的操作为有效操作,不会重复执行相同的处理,因此减少了操作时长,增加了用户体验。
下面介绍本发明实施例中的控制端用户设备实施例,请参阅图8,本发明实施例中的控制端用户设备包括:
控制权确定单元801,用于确定需要共享控制权的第二控制端UE;
生成单元802,用于生成自身以及第二控制端UE的优先级;
共享请求发送单元803,用于向应用服务器发送控制权共享请求,控制权共享请求指示将控制权共享给第二控制端UE,该控制权共享请求包含第一控制端UE以及第二控制端UE的优先级信息。
本实施例中,由于共享请求发送单元803发送的控制权共享请求中指示将控制权共享给第二控制端UE,该控制权共享请求包含第一控制端UE以及第二控制端UE的优先级信息,因此AS在接收到媒体处理请求时,会按照该优先级,仅向优先级最高的控制端UE发送媒体处理请求,由于只会有一个控制端UE接收到媒体处理请求,则可以避免多个控制端UE同时接收到媒体处理请求时所导致的操作冲突,因此可以避免第二控制端UE多次接收到媒体处理请求,从而可以减少网络数据传输量,提高系统性能。
下面介绍本发明实施例中的媒体处理系统实施例,请参阅图9,本发明实施例中的媒体处理系统包括:
第一控制端用户设备901,第二控制端用户设备902以及应用服务器903;
需要说明的是,本实施例中的媒体处理系统可以分为两种情况:
在一种情况中,该第一控制端用户设备901与第二控制端用户设备902可以为本领域技术人员的公知常识,而应用服务器903可以为如图6所示实施例中的应用服务器,具体的单元功能以及单元间的联系均与图6所示实施例中描述的内容相同,此处不再赘述。
在另一种情况中,该第二控制端用户设备902可以为本领域技术人员的公知常识,而应用服务器903可以为如图7所示实施例中的应用服务器,具体的单元功能以及单元间的联系均与图7所示实施例中描述的内容相同,第一控制端用户设备901可以为如图8所示实施例中的控制端用户设备,具体的单元功能以及单元间的联系均与图8所示实施例中描述的内容相同,此处不再赘述。
本领域普通技术人员可以理解实现上述实施例方法中的全部或部分步骤是可以通过程序来指令相关的硬件完成,该程序可以存储于一种计算机可读存储介质中,上述提到的存储介质可以是只读存储器,磁盘或光盘等。
以上对本发明所提供的一种媒体处理方法及媒体处理系统以及相关设备进行了详细介绍,对于本领域的一般技术人员,依据本发明实施例的思想,在具体实施方式及应用范围上均会有改变之处,因此,本说明书内容不应理解为对本发明的限制。