Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CED021E808C for ; Sat, 28 Sep 2013 15:08:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_BACKHAIR_44=1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VhFH6+305iow for ; Sat, 28 Sep 2013 15:08:43 -0700 (PDT) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) by ietfa.amsl.com (Postfix) with ESMTP id 5CB3F21E811F for ; Sat, 28 Sep 2013 15:08:41 -0700 (PDT) Received: by mail-wi0-f176.google.com with SMTP id cb5so2254587wib.9 for ; Sat, 28 Sep 2013 15:08:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type; bh=yvIetwskAvqFp94GUGVIhjfx51Y5VSUgOmxSQcGUVgQ=; b=YLGfgMfU/VkSednRWx4duo5KtOvZpEYqk7ckPrjJyIbWnBLSeehAdoME5/EyUeMQVm 461lrIVFvF3FgTOqw9qsTbEh8exa/XsAQAE7Op6o1DfXWaIUgpGgLNscDHEchw4yuliF a9Hwjcy3KlxJsjEHIfm4/SZ3Kg+PFz27JFF9YXhH06Z5iccMvaxW8lE3kZ+PHqwgR6jo /glzSPL2iYP52J4ALqUnhZC4oycAFP5GmRm+wYZNOZU9TR7NmrStxzBLMkuSaJ8PDD15 +d8hsEdKGxDr2XOSTXw7wtwKEJLDK+GN627sbs0Q7PppS1I3gcbviv6hz8ME7pnC875N 5k7g== X-Received: by 10.194.9.70 with SMTP id x6mr11035172wja.22.1380406120489; Sat, 28 Sep 2013 15:08:40 -0700 (PDT) Received: from [192.168.1.2] ([90.165.209.121]) by mx.google.com with ESMTPSA id iz19sm10085808wic.9.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 28 Sep 2013 15:08:39 -0700 (PDT) Message-ID: <52475369.9040107@gmail.com> Date: Sun, 29 Sep 2013 00:08:41 +0200 From: Sergio Garcia Murillo User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary="------------010403020909070001000908" Subject: [rtcweb] Camera rotation on mobile phones X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Sep 2013 22:08:44 -0000 This is a multi-part message in MIME format. --------------010403020909070001000908 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Hi all, Currently, in order to keep image property displayed on the receiver side if the sender rotates the phone (and the camera), it is needed that the sender rotates the image from WxH to HxW so it is sent in upward position over the wire. Also, if the receiver is a mobile phone and has it rotated, it will have to rotate it again to match the current phone orientation. How about using Coordination of Video Orientation as in 3GPP TS 26.114 (http://www.3gpp.org/ftp/Specs/html-info/26114.htm)? Coordination of Video Orientation consists in signalling of the current orientation of the image captured on the sender side to the receiver for appropriate rendering and displaying. When CVO is succesfully negotiated it shall be signalled by the MTSI client. The signalling of the CVO uses RTP Header Extensions as specified in IETF RFC 5285 [95]. The one-byte form of the header shall be used. CVO information for a 2 bit granularity of Rotation (corresponding to urn:3gpp:video-orientation) is carried as a byte formatted as follows: Bit#76543210(LSB) Definition0000CFR1R0 With the following definitions: C = Camera: indicates the direction of the camera used for this video stream. It can be used by the MTSI client in receiver to e.g. display the received video differently depending on the source camera. 0: Front-facing camera, facing the user. If camera direction is unknown by the sending MTSI client in the terminal then this is the default value used. 1: Back-facing camera, facing away from the user. F = Flip: indicates a horizontal (left-right flip) mirror operation on the video as sent on the link. 0: No flip operation. If the sending MTSI client in terminal does not know if a horizontal mirror operation is necessary, then this is the default value used. 1: Horizontal flip operation R1, R0 = Rotation: indicates the rotation of the video as transmitted on the link. The receiver should rotate the video to compensate that rotation. E.g. a 90° Counter Clockwise rotation should be compensated by the receiver with a 90° Clockwise rotation prior to displaying. Table 7.2: Rotation signalling for 2 bit granularity R1 R0 Rotation of the video as sent on the link Rotation on the receiver before display 0 0 0° rotation None 0 1 90° Counter Clockwise (CCW) rotation or 270° Clockwise (CW) rotation 90° CW rotation 1 0 180° CCW rotation or 180° CW rotation 180° CW rotation 1 1 270° CCW rotation or 90° CW rotation 90° CCW rotation CVO information for a higher granularity of Rotation (corresponding to urn:3GPP:video-orientation:6) is carried as a byteformatted as follows:** Bit#76543210(LSB) DefinitionR5R4R3R2CFR1R0 where Cand Fare as defined above and the bits R5,R4,R3,R2,R1,R0 represent the Rotation, which indicates the rotation of the video as transmitted on the link. Table 7.3 describes the rotation to be applied by the receiver based on the rotation bits. Table 7.3: Rotation signalling for 6 bit granularity R1 R0 R5 R4 R3 R2 Rotation of the video as sent on the link Rotation on the receiver before display 0 0 0 0 0 0 0° rotation None 0 0 0 0 0 1 (360/64)° Counter Clockwise (CCW) rotation (360/64)° CW rotation 0 0 0 0 1 0 (2*360/64)° CCW rotation (2*360/64)° CW rotation *.* *.* *.* *.* *.* *.* *.* *.* *.* *.* *.* *.* *.* *.* *.* *.* *.* *.* *.* *.* *.* *.* *.* *.* 1 1 1 1 1 0 (62*360/64)° CCW rotation (2*360/64)° CCW rotation 1 1 1 1 1 1 (63*360/64)° CCW rotation (360/64)° CCW rotation Best regards Sergio --------------010403020909070001000908 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi all,

Currently, in order to keep image property displayed on the  receiver side if the sender rotates the phone (and the camera), it is needed that the sender rotates the image from WxH to HxW so it is sent in upward position over the wire. Also, if the receiver is a mobile phone and has it rotated, it will have to rotate it again to match the current phone orientation.

How about using Coordination of Video Orientation as in 3GPP TS 26.114 (http://www.3gpp.org/ftp/Specs/html-info/26114.htm)?

Coordination of Video Orientation consists in signalling of the current orientation of the image captured on the sender side to the receiver for appropriate rendering and displaying. When CVO is succesfully negotiated it shall be signalled by the MTSI client. The signalling of the CVO uses RTP Header Extensions as specified in IETF RFC 5285 [95]. The one-byte form of the header shall be used. CVO information for a 2 bit granularity of Rotation (corresponding to urn:3gpp:video-orientation) is carried as a byte formatted as follows:

Bit#                   7                 6                 5                 4               3                 2                 1                 0(LSB)
Definition      0           0           0           0           C          F           R1          R0

With the following definitions:

C = Camera: indicates the direction of the camera used for this video stream. It can be used by the MTSI client in receiver to e.g. display the received video differently depending on the source camera.

    0: Front-facing camera, facing the user. If camera direction is unknown by the sending MTSI client in the terminal then this is the default value used.

1: Back-facing camera, facing away from the user.

F = Flip: indicates a horizontal (left-right flip) mirror operation on the video as sent on the link.

    0: No flip operation. If the sending MTSI client in terminal does not know if a horizontal mirror operation is necessary, then this is the default value used.

    1: Horizontal flip operation

R1, R0 = Rotation: indicates the rotation of the video as transmitted on the link. The receiver should rotate the video to compensate that rotation. E.g. a 90° Counter Clockwise rotation should be compensated by the receiver with a 90° Clockwise rotation prior to displaying.

Table 7.2: Rotation signalling for 2 bit granularity

R1

R0

Rotation of the video as sent on the link

Rotation on the receiver before display

0

0

0° rotation

None

0

1

90° Counter Clockwise (CCW) rotation or 270° Clockwise (CW) rotation

90° CW rotation

1

0

180° CCW rotation or 180° CW rotation

180° CW rotation

1

1

270° CCW rotation or 90° CW rotation

90° CCW rotation

 

CVO information for a higher granularity of Rotation (corresponding to urn:3GPP:video-orientation:6) is carried as a byte  formatted as follows:

Bit#                   7                 6                 5                 4               3                 2                 1                 0(LSB)
Definition      R5          R4          R3          R2          C          F           R1          R0

where C and F are as defined above and the bits R5,R4,R3,R2,R1,R0 represent the Rotation, which indicates the rotation of the video as transmitted on the link. Table 7.3 describes the rotation to be applied by the receiver based on the rotation bits.

Table 7.3: Rotation signalling for 6 bit granularity

R1

R0

R5

R4

R3

R2

Rotation of the video as sent on the link

Rotation on the receiver before display

0

0

0

0

0

0

0° rotation

None

0

0

0

0

0

1

(360/64)° Counter Clockwise (CCW) rotation

(360/64)° CW rotation

0

0

0

0

1

0

(2*360/64)° CCW rotation

(2*360/64)° CW rotation

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

1

1

1

1

1

0

(62*360/64)° CCW rotation

(2*360/64)° CCW rotation

1

1

1

1

1

1

(63*360/64)° CCW rotation

(360/64)° CCW rotation

 

Best regards
Sergio

--------------010403020909070001000908--