Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 436721B2F95 for ; Mon, 27 Apr 2015 02:31:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.9 X-Spam-Level: X-Spam-Status: No, score=0.9 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_BACKHAIR_44=1, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fI1-bInYcRhf for ; Mon, 27 Apr 2015 02:31:10 -0700 (PDT) Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA87D1B2F91 for ; Mon, 27 Apr 2015 02:31:09 -0700 (PDT) Received: by wgin8 with SMTP id n8so109180260wgi.0 for ; Mon, 27 Apr 2015 02:31:08 -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:references :in-reply-to:content-type; bh=wXtEh1fAIHMdVEA8nH/1Q2AprZ0xmbyxDJLsc8Kum18=; b=qrD34SyIctp+I2jzFuSEcF313EOLN53exAkntEUhvb9bM/50hQRzQHpPvaj/0d4kpt +tuBzl0JAlTVH/AYt1c//RwLtMlXMWR9NGWmXsi2nwlXIB321whXsR1L7BXQ9WLk42yo xm3FUm0mLQzQ4n9PzaG/ZgdIlXhe9pkaSqcmWKwT4mDqoD3tf/61KXRq6ppLJdecUQ6Y Js4k2Q5t9KYKJRnrn18oEJY6+TV0L4dlpxjEdsIJUhFlrTIfd9K2x8KAyXRMwAvrn64f yQVT4QtwPslzIb9MhEkNWkcgCKLBDacC5EwGIuBZD1IqC2spbNbqfQtcR3f47eKS1Nqp /LFw== X-Received: by 10.194.79.199 with SMTP id l7mr1148104wjx.158.1430127068392; Mon, 27 Apr 2015 02:31:08 -0700 (PDT) Received: from [192.168.1.39] (136.Red-81-36-170.dynamicIP.rima-tde.net. [81.36.170.136]) by mx.google.com with ESMTPSA id l3sm10766227wik.16.2015.04.27.02.31.04 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Apr 2015 02:31:07 -0700 (PDT) Message-ID: <553E01D7.6070600@gmail.com> Date: Mon, 27 Apr 2015 11:31:03 +0200 From: Sergio Garcia Murillo User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "rtcweb@ietf.org" References: <52475369.9040107@gmail.com> In-Reply-To: <52475369.9040107@gmail.com> Content-Type: multipart/alternative; boundary="------------040906070107030407040609" Archived-At: Subject: Re: [rtcweb] Camera rotation on mobile phones X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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: Mon, 27 Apr 2015 09:31:16 -0000 This is a multi-part message in MIME format. --------------040906070107030407040609 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Hi all, I have just seen that Chrome 43 has added CVO as per my suggestion in the message below * Issue 4145 Added support for CVO (Coordination of video rotation) header extension in webrtc. When both sides support CVO, device rotation will not cause a new key-frame. https://code.google.com/p/webrtc/issues/detail?id=4145 I have always thought that it would be a nice addition to the WebRTC requirements, especially in terms of mobile performance and user experience (at least in theory). Would it be possible if anyone from the Chrome team could share some feedback about it's usage in the real life? Best regards Sergio On 29/09/2013 0:08, Sergio Garcia Murillo wrote: > 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 > --------------040906070107030407040609 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Hi all,


I have just seen that Chrome 43 has added CVO as per my suggestion in the message below

  • Issue 4145 Added support for CVO (Coordination of video rotation) header extension in webrtc. When both sides support CVO, device rotation will not cause a new key-frame.

          https://code.google.com/p/webrtc/issues/detail?id=4145


I have always thought that it would be a nice addition to the WebRTC requirements,  especially in terms of mobile performance and user experience (at least in theory). Would it be possible if anyone from the Chrome team could share some feedback about it's usage in the real life?

Best regards
Sergio


On 29/09/2013 0:08, Sergio Garcia Murillo wrote:
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


--------------040906070107030407040609--