810424 - User Recorded Videos play at 90deg

Status: RESOLVED DUPLICATE of bug 812924

(Firefox OS Graveyard :: Gaia::Video, defect, P1)

Description

[Dale Harvey (:daleharvey)]

Attachment: Correctly rotated video from otoro running android

Follow up from https://bugzilla.mozilla.org/show_bug.cgi?id=808099

Even when we correctly set video-param-rotation-angle-degrees we are seeing videos playing at a 90deg angle, our video decoder isnt reading this correctly. The videos are also at 90deg when played on desktop

Comment 2

[Dale Harvey (:daleharvey)]

Strangely we have no idea how that correctly rotated video came into being, my phone was flashed with an android by someone else. When manually flashing a device with android and recording a video they are shown with an incorrect rotation when played on a computer (but correctly rotated in the video player)

This would seem to suggest there could be some updated kernel that transforms the video while encoding?

Comment 3

[Mike Habicher [:mikeh] (high bugzilla latency)]

For completeness, I installed Gingerbread 2.3.6[1] on the Otoro and recorded a video.  It also shows up in VLC on my desktop as rotated 90o CCW.

1. http://blog.podtwo.com/android/rom/de-branded%20ROM%20for%20ZTE%20Roamer2%20%5Bgingerbread%5D.html

Comment 4

[Mike Habicher [:mikeh] (high bugzilla latency)]

I guess this is the final word from the Android dev docs on |setOrientationHint()|:

Quoth: "This method will not trigger the source video frame to rotate during video recording, but to add a composition matrix containing the rotation angle in the output video if the output format is OutputFormat.THREE_GPP or OutputFormat.MPEG_4 so that a video player can choose the proper orientation for playback. Note that some video players may choose to ignore the compostion matrix in a video during playback."[1]

1. http://developer.android.com/reference/android/media/MediaRecorder.html#setOrientationHint%28int%29

Comment 5

[Alex Keybl [:akeybl]]

Marking for C2, given this meets the criteria of known P1/P2 blocking-basecamp+ bugs at the end of C1.

Comment 6

[Jason Smith [:jsmith]]

Renoming - sounds like this is unagi specific.

Comment 7

[Mike Habicher [:mikeh] (high bugzilla latency)]

(In reply to Jason Smith [:jsmith] from comment #6)
> Renoming - sounds like this is unagi specific.

Otoro too.  And the Nexus S.

Comment 8

[Jason Smith [:jsmith]]

(In reply to Mike Habicher [:mikeh] from comment #7)
> (In reply to Jason Smith [:jsmith] from comment #6)
> > Renoming - sounds like this is unagi specific.
> 
> Otoro too.  And the Nexus S.

Oh...so this does affect the otoro? The comments in bug 812924 (the platform equivalent indicates this is unagi specific). Sounds like qawanted is in order.

Comment 9

[Mike Habicher [:mikeh] (high bugzilla latency)]

(In reply to Jason Smith [:jsmith] from comment #8)
> 
> Oh...so this does affect the otoro? The comments in bug 812924 (the platform
> equivalent indicates this is unagi specific). Sounds like qawanted is in
> order.

I don't think qawanted is needed.  We know it affects otoro, unagi, and the Nexus S (at least--it may affect others, but those are the phones we have tested).

Comment 10

[Jason Smith [:jsmith]]

(In reply to Mike Habicher [:mikeh] from comment #9)
> (In reply to Jason Smith [:jsmith] from comment #8)
> > 
> > Oh...so this does affect the otoro? The comments in bug 812924 (the platform
> > equivalent indicates this is unagi specific). Sounds like qawanted is in
> > order.
> 
> I don't think qawanted is needed.  We know it affects otoro, unagi, and the
> Nexus S (at least--it may affect others, but those are the phones we have
> tested).

Oh. Then Doug isn't right and this is a blocker.

Comment 11

[Dale Harvey (:daleharvey)]

New bug was originally shadow bug, but since its public this is just a dupe