Subject: [MMUSIC] on LS Regarding Indicating Image Size in Conversational Multimedia Sessions Esablished Using SIP/SDP

From: 정경훈 <[email-masked]>
Date: Wed, 18 Jun 2008 09:53:43 +0000 (GMT)

Dear experts of IETF MMUSIC WG:

In January, 3GPP SA4 sent an LS, asking for
MMUSIC’s opinion on the procedure to extend a SDP attribute defined for 3GPP
PSS,

"a=framesize," for another objective in 3GPP MTSI. Mr. Roni Even kindly
commented on the LS.

http://www.ietf.org/mail-archive/web/mmusic/current/msg06851.html

We would like to share our answers to other
experts of MMUSIC and will appreciate further comments and questions.

--------------------------------------------------------------------------------------------------------------

Hi, I looked at the LS and would like to give the following feedback.

1. It is not clear if the request is from
the video encoder to send any resolution or from the sending terminal to scale
the

video picture.

->
"a=framesize," if extended, will designate the frame sizes that can
be supported by the camera, video encoder and decoder,

available LCD area,
bit-rate of terminals, not just for video codecs.

2. Currently RFC4587 for H.261 and RFC4629
for H.263 enable the receiver to ask for specific resolution. It also allows
the receiver

to ask for different resolutions at different frame rates. This
may be important on limited BW connections since in some cases there

may be a
preference to show low resolution at higher frame rate if motion is important.
H.261 codec supports only fixed resolutions

while H.263 may support custom
resolutions and RFC4629 defines them.

-> 3GPP does not use
H.261 and the level used for H.263, in MTSI (3GPP's video telephony), will not
allow custom sizes. (Level 45)

3. For H.264 requesting only the resolution
may not be enough. H.264 has also the sample aspect ratio value and if the receiver
will

not take it into account the display image may have geometric distortion.
For H.264 there is a work going on at the ITU on requesting

a specific
resolution from the sender (if it supports it). This work will be approved next
week and we intend to add this also to

H.264 payload specification.

-> 3GPP MTSI supports
H.264 as well as MPEG-4. The primary objective to specify the frame size in the
session setup is that since

frame size is the key parameter that covers camera,
codecs, and LCD area, negotiating the frame size between terminals will allow
us

to reduce the distortion from resizing or loss of spectrum efficiency from
encoding larger images than necessary. Therefore, we would

like to avoid any
codec-dependent signaling methods.

4. Making a generic resolution parameter
for indicating the screen size may be interesting but I am not sure you can
guarantee that

every send will be able to build the right image. An H.264 codec
is not required to have scaling capability and it is up to the

receiver to
scale to the display. The work mentioned in point 3 will enable the sender to
reply with the scaling capabilities it has.

-> Frame sizes larger
than QCIF will be recommended, not mandated. Each terminal selects sizes within
its capability / cost / service

contract or bit-rate.

5. I think that the LS should also be sent
to AVT. Thanks Roni Even

-> Our intention is
that the extended "a=framesize" be codec-independent and do not
require additional modification when a new video

codecs is introduced to MTSI
or codec capability is increased.

I would like to add another comment based
on the email.

If you requirement has to do with available
line rate then having image size is not sufficient. The rate is dependent also
on frame

rate or in H.264 terminology MBS (Macro Blocks per second) which
includes both the frame rate and size. This is one reason why the

solution for
H.264 should be specific and not general. Again I would point to H.241 that has all
this supported and some of it is

already in RFC 3984 and extension drafts

-> Yes,
specifying framesize will be necessary but not enough to determine video
codecs' operation completely. However, UE (a 3GPP

term for mobile phone)
vendors' point of view, frame rate is determined based on available bit-rate and
operators' quality policy.

Generally, UEs would not assume that the far-end
video encoder can encode any specific frame rate, since it will also depend on
the

capability of camera which 3GPP does not standardize. Even in 3G-324M,
H.245 videoTemporalSpatialTradeoff is usually not answered

properly. Once the
bit-rate and frame size are negotiated, frame rate will be determined by
implementation, within the negotiated

profile and level.

---------------------------------------------------------------------------------------------------------------------------

For further information, please refer to
the two 3GPP documents which outline how we would like to extend the
"framesize." Terminal

capability is gradually increasing and there
have been comments that recommending only a few sizes, for example between QCIF
and CIF,

will, in the long term, limit flexibility and spectrum efficiency.
We are trying to address the issue with "any-size within some

constraints" concept.

http://www.3gpp.org/ftp/tsg_sa/WG4_CODEC/TSGS4_48/Docs/

S4-080144, 080145

Please understand that UMTS networks, which
3GPP standardizes, has very unusual operating environments, where bandwidth is
very rare

and expensive, and many tasks that could be done with PCs a decade
ago are still unachievable. Therefore many cost and complexity

issues, non-existing
in desktops or laptops, are still considered very serious in mobiles.

We will be very glad to discuss with MMUSIC
experts interested in the LS. We believe further discussion will help MMUSIC's

understanding of this problem and finding better solutions. Further questions
or comments will be greatly welcomed.

Sincerely yours,

Kyunghun Jung

Samsung Electronics Co., Ltd.

_______________________________________________
mmusic mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mmusic