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