FYI
From: stephen botzko
[mailto:stephen.botzko@gmail.com]
Sent: Friday, September 25, 2009 3:31 PM
To: t09sg16avd@lists.itu.int
Subject: [T16AVD] Request for input to the "Multiple video streams
FECC AHG"
I
would remind you all of the following item in the Q1/16 Experts Meeting Report
(24-25 June 2009):
>>>
Q1-I08 was presented and a short discussion followed. The
group noted the limitations and considerations raised by the contribution. It
was noted that, if the solution would involve enhancements to both H.281 and
H.224, it would be desirable to consent those recommendations at the same time.
Because of the absence of several experts, the proponent himself and not
being able to fully discuss this topic, Q1 experts agreed to create an Ad-hoc
group (chaired by S. Botzko) to progress this work through electronic
correspondence in the interim period. The contributor was asked to submit a
contribution to the next meeting of SG16 to allow a continuation of the
discussion. Experts interested in participating in this work are encouraged to
contact the Rapporteur and/or the AHG Chair.
>>>
Feedback on these approaches would be appreciated - please reply to this
email. If desired, contact me directly and I will set up a meeting.
Alternatively, interested parties can communicate through email.
At this point
I see three possible ways to progress the work:
(1) Use the Q1-I08 contribution (June 2009 meeting) as the basis
This contribution proposes "channeling" the existing H.281 messages,
so that the video channel can be carried in the new messages. Backwards
compatibility is provided since the existing messages are still used for the
main video channel. Existing H.281 clients would not be able to control
the second (or third) channels.
(2) Use the C-0399 contribution (April 2008 meeting) as the basis
This contribution proposes adding a second H.224 CME client id for the second
video channel. Backwards compatibility is provided since the existing
client ID is still used for the main video channel. Existing H.281 clients
would not be able to control the second (or third) channels.
(3) Revise H.281 Video Source Capability to include a channel number (Figure
10/H.281)
There is no contribution (yet) for this approach. This idea proposes
specifying the channel number within the existing H.281 Video Source Capability
for sources 6-15. The channel is transmitted in ASCII in the existing camera
name. Backwards compatibility is provided since existing clients can
decode this message. This idea allows existing H.281 clients to control
the cameras for both video channels - it is the only current proposal which
does this. The syntax of only one message in H.281 is slightly adjusted.
The existing video source capability for these sources looks like this:
|
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
|
|
|
Motion |
Normal resolution
still |
Double resolution
still |
|||
|
Up to 16 ASCII
encoded characters |
|||||||
|
All zeros octet |
|||||||
|
Pan |
Tilt |
Zoom |
Focus |
Reserved |
|||
The revision is to set the Reserved Bit if the Video Source is sending on a
secondary video channel. If the reserved bit is set, the first character
of the source name is a channel number (in ASCII), the second character is a
space. The remaining 14 characters have the existing meaning. This
is backwards compatible, since if the reserved bit is ignored the message can
be decoded properly by existing receivers. An alternative is to leave the
reserved bit alone - since use of these extended sources is rare, this might be
sufficient.
All three approaches share a common issue. H.323 and H.320 video channel
numbering is not preserved end-to-end. Therefore, sometimes the user may
discover that they are moving the camera for the "wrong" video
stream. One solution is bind the channels to H.239 role labels, which are
preserved. For instance, use channel 0 for main, channel 1 for
presentation, and channel 2 for live. Expanding beyond 2 channels could
be done by adding new role labels to H.239.
Stephen Botzko
Chair - Multiple video streams FECC AHG
Polycom
+1 978 292 5395