Changes between Version 6 and Version 7 of Video_Users_Guide

Timestamp:

Aug 15, 2011 8:40:16 AM (13 years ago)

Author:

bennylp

Comment:

--

Video_Users_Guide

@@ -28 +28 @@
 
 Windows:
- 1. ?
+ 1. -
 
 Mac OS X:
- -
+ 1. -
 
 Mobile platforms (iPhone, Symbian, Windows Mobile, etc):
@@ -62 +62 @@
 ==== 2. Configuring video support ====
 
-Add this in your {{{config_site.h}}}:
+Add this to your {{{config_site.h}}}:
 
 {{{
@@ -88 +88 @@
  1. SDL
  1. ffmpeg
- 1. !DirectX (?)
- 1. Base classes (?)
 
 ==== 2. Configure Video Settings ====
@@ -143 +141 @@
 This section provides several sample scenarios of using video in your application. Please see [#vidref Video API Reference] section for a more complete documentation about the Video API.
 
-=== Enabling video ===
+[[BR]]
+
+=== Enabling Video ===
 
 By default, video is enabled in '''{{{pjsua_acc_config}}}''', via '''{{{max_video_cnt}}}''' setting. The subsequent discussions assume that video is enabled on the account.
 
-=== Incoming video display ===
+[[BR]]
+
+=== Incoming Video Display ===
 
 As long as video is enabled in the account config (see above), incoming video by default will be accepted as long as we have matching codec for it. However, this does not necessarily mean that the video will be displayed automatically to the screen, nor that outgoing video will be transmitted automatically, as there will be separate settings for these. Outgoing video behavior will be explained in the next section.
+
+==== Display Incoming Video Automatically ====
 
 By default, incoming video '''is not''' displayed automatically, since the app may want to seek user approval first. Use the following code to change this behavior on per account basis:
@@ -159 +163 @@
 cfg.vid_in_auto_show = PJ_TRUE;
 }}}
+
+==== Show or Hide Incoming Video ====
 
 Regardless of the setting above, you can use the following steps to show or hide the display incoming video:
@@ -178 +184 @@
  1. Using the video window ID, you may retrieve the associated native video handle with '''{{{pjsua_vid_win_get_info()}}}''' and then show or hide the video window using native API, or use '''{{{pjsua_vid_win_set_show()}}}''' to show/hide the window using PJSUA API. See [#wwin Working with Window] section below for information on manipulating video windows.
 
+==== Controlling Incoming Video Stream ====
+
 Controlling the video window above will not cause any re-INVITE or UPDATE to be sent to remote, since the operation occurs locally. However, if you wish, you may alter the incoming video stream with '''{{{pjsua_call_set_vid_strm()}}}''' API, and this '''will''' cause re-INVITE or UPDATE to be sent to negotiate the new SDP. The relevant operation to control incoming video with '''{{{pjsua_call_set_vid_strm()}}}''' are:
  - ''PJSUA_CALL_VID_STRM_CHANGE_DIR'': change the media direction (e.g. to "sendonly", or even "inactive")
@@ -185 +193 @@
 Since '''{{{pjsua_call_set_vid_strm()}}}''' will result in renegotiation of the SDP in a re-INVITE or UPDATE transaction, the result of this operation will not be available immediately. Application can monitor the status by implementing '''{{{on_call_media_state()}}}''' callback and enumerate the media stream status with '''pjsua_call_info'''.
 
+[[BR]]
 
 === Outgoing Video Transmission ===
 
-Outgoing video transmission is independent from the incoming video transmission; each can be operated separately. Even though video by default is enabled on the account, outgoing video transmission '''is not started by default'''. Not even when incoming offer contains video support. This behavior is controlled by '''{{{pjsua_acc_config.vid_out_auto_transmit}}}''' setting, which default to ''PJ_FALSE''. Setting this to ''PJ_TRUE''' will cause video transmission to be started automatically on each outgoing calls and on incoming calls that indicates video support in its offer. However, it is more flexible and appropriate to leave this setting at PJ_FALSE, and add video later during the call by using '''{{{pjsua_call_set_vid_strm()}}}''' API, as will be explained shortly.
+Outgoing video transmission is independent from the incoming video transmission; each can be operated separately. Even though video is enabled by default on the account, outgoing video transmission '''is not started by default'''. Not even when incoming offer contains video support. This behavior is controlled by '''{{{pjsua_acc_config.vid_out_auto_transmit}}}''' setting, which default to ''PJ_FALSE''. Setting this to ''PJ_TRUE''' will cause video transmission to be started automatically on each outgoing calls and on incoming calls that indicates video support in its offer. However, it is more flexible and appropriate to leave this setting at PJ_FALSE, and add video later during the call by using '''{{{pjsua_call_set_vid_strm()}}}''' API, as will be explained shortly.
+
+==== Default Capture Device ====
 
 The default capture device that is used by an account is configured in '''{{{pjsua_acc_config.vid_cap_dev}}}''' setting. It is more convenient to set the "correct" device here rather than having to set it in every other API calls later.
 
-Application uses '''{{{pjsua_call_set_vid_strm()}}}''' API to control video media on a call. The following ''op_code'' can be used on the API to control the video media:
+==== Controlling Video Stream ====
+
+Application uses '''{{{pjsua_call_set_vid_strm()}}}''' API to control video stream on a call. The following ''op_code'' can be used on the API to control the video media:
  - ''PJSUA_CALL_VID_STRM_ADD'': add a new video stream
  - ''PJSUA_CALL_VID_STRM_REMOVE'': remove video stream (set port to zero)
@@ -202 +215 @@
 Some of the video operations above require re-INVITE or UPDATE to be sent, hence the result will not be available immediately. In that case, application can implement '''{{{on_call_media_state()}}}''' callback and inspect the resulting negotiation by looking at the '''{{{pjsua_call_info}}}'''. Please see [#vcm Video Call Manipulation] in the API reference section below for more information about the operations above.
 
+[[BR]]
 
 === Working with Video Window === #wwin