orientation wrong in playback for recorded videos

btw, recording in landscape seems to work correctly and play back in the proper orientation. It's just portrait that has the issue. Same is true if you use front camera. The video is incorrectly rotated 90 to the right and displayed in landscape.

This bug was fixed in the package qtubuntu-camera - 0.3.3daily13.06.22-0ubuntu1

---------------
qtubuntu-camera (0.3.3daily13.06.22-0ubuntu1) saucy; urgency=low

  [ Guenter Schwann ]
  * Support orientation for videos. (LP: #1191934)

  [ Ubuntu daily release ]
  * Automatic snapshot from revision 55
 -- Ubuntu daily release <email address hidden> Sat, 22 Jun 2013 04:02:10 +0000

The bug is still there, but the problem is the playback. The orientation correction is done wrong (like -90° instead of +90°). So now the videos are played upside down (rotated 180°⁾.
Videos recorded by other android devices have the same issue.

changing to critical per victor

Added thumbnailer since it also needs to rotate the still image that it gets from the hardware video decoder using GStreamer. Basically it needs to look for the "image-orientation" tag in the GstTagList that gets broadcasted by the Gst pipeline. Then look for values of "rotate-0", "rotate-90", "rotate-180", "rotate-270" for the queue in what to do. This info comes from the MPEG4 container file itself, parsed by qtdemux and added to a GstTagList. Take a look at qtvideo-node shadervideomaterial.cpp file for how to do the matrix operations manually. Or you might take a look at using the "videoflip" plugin from GStreamer to do this as it listens for the exact same GstTagList values that I mentioned above.

Videoflip does not work because the pipeline is not emitting the orientation tag. I wrote a test app to dump all tags and ran it with GST_DEBUG=3. In the output we find this:

0:00:00.034587209 32036 0x7f047c0522d0 WARN qtdemux qtdemux_types.c:202:qtdemux_type_get: unknown QuickTime node type pasp
0:00:00.034666428 32036 0x7f047c0522d0 FIXME qtdemux qtdemux.c:7212:qtdemux_inspect_transformation_matrix:<qtdemux0> Unhandled transformation matrix values

The core issue is in gstreamer, so I filed an upstream bug:

https://bugzilla.gnome.org/show_bug.cgi?id=738681

@Jussi: yes it is an upstream bug, but I've been adding support for the various matrices that come from the container file into qtdemux. I currently have support in there for a recording done in portrait mode, so if you want to at least get on with that use-case it should pass you the proper tag then. I should have the other tags in there by Monday (assuming all goes well).

The upstream bug says that the orientation matrix is actually incorrect. Maybe we should fix the part that generates it rather than doing postprocessing tricks.

I just tested the rtm krillin silo for this (image 120 + silo rtm-003), and it doesn't appear to help at all. I'm not sure if the orientation tag in the videos are getting set correctly (recorded after installing the silo), but both the thumbnails and video playback are still 90 degrees off. This happens in both gallery-app and the video scope (and media player).

As a sanity check, I checked the file metadata.
'mediainfo' says this about it: Width : 1 280 pixels
Height : 720 pixels
Display aspect ratio : 16:9
Rotation : 90?

So, perhaps the rotation tag is set correctly (not sure what the '?' is about), but neither mplayer nor vlc play it in the desired orientation.

The bits that write the tags have not landed yet. The thumbnailer silo won't show any improvements over current status but once the other parts land, it will start working automatically.

Could anyone verify what change or behavior is expected in silo rtm-003 (thumbnailer)? It didn't have any effect at all that I could tell from exploratory testing, but perhaps I was looking for the wrong things.

@Selene: the rotation bits for video (non-thumbnail) are in rtm silo 16 and I hope to get this landed today (after lunch).

So if you only have silo 3 -> nothing should change (orientation is incorrect)

If you have both 3 and 16 -> orientation should be correct.

Verified, silo 3 + 16 does indeed work. I only tested the parts relevant to silo 3 though; I think 16 is still waiting on a patch.

This bug was fixed in the package media-hub - 2.0.0+14.10.20141016-0ubuntu1

---------------
media-hub (2.0.0+14.10.20141016-0ubuntu1) 14.09; urgency=low

  [ Jim Hodapp ]
  * Add an Orientation property which will indicate how the video should
    be rotated for playback vs how it was recorded. Get the video frame
    height/width from mirsink and pass it to the media-hub client via a
    Signal. (LP: #1191934)

  [ Ubuntu daily release ]
  * New rebuild forced
 -- Ubuntu daily release <email address hidden> Thu, 16 Oct 2014 20:02:01 +0000

This bug was fixed in the package qtvideo-node - 0.2.1+14.10.20141022~rtm-0ubuntu1

---------------
qtvideo-node (0.2.1+14.10.20141022~rtm-0ubuntu1) 14.09; urgency=low

  [ Jim Hodapp ]
  * Rotate the video 90 degrees and do an orthographic projection when
    necessary, otherwise render same as always. (LP: #1191934)
 -- Ubuntu daily release <email address hidden> Wed, 22 Oct 2014 16:19:20 +0000

This bug was fixed in the package qtubuntu-media - 0.7.1+14.10.20141022~rtm-0ubuntu1

---------------
qtubuntu-media (0.7.1+14.10.20141022~rtm-0ubuntu1) 14.09; urgency=low

  [ Jim Hodapp ]
  * Add simple support for Orientation Property changed signal that
    comes from media-hub. Pass the video frame dimension in from media-
    hub through to qtvideo-node (LP: #1191934)
 -- Ubuntu daily release <email address hidden> Wed, 22 Oct 2014 16:21:31 +0000

is that fixed released in its entirety in krillin?

This bug was fixed in the package thumbnailer - 1.3+15.04.20141106-0ubuntu1

---------------
thumbnailer (1.3+15.04.20141106-0ubuntu1) vivid; urgency=low

  [ Jussi Pakkanen ]
  * Fix memory leak.
  * Use videoflip to fix orientation. (LP: #1191934)
 -- Ubuntu daily release <email address hidden> Thu, 06 Nov 2014 05:38:14 +0000