#454 closed defect (wontfix)
Some videos not oriented correctly
| Reported by: | joar | Owned by: | |
|---|---|---|---|
| Priority: | major | Milestone: | |
| Component: | programming | Keywords: | bitesized |
| Cc: | Olivier Mehani | Parent Tickets: |
Description
Reference: https://gobblin.se/u/joar/m/using-the-penclic-r2-pointer-hid/
It's an iPhone 4 video uploaded through the Dropbox app (I think I have "Original" set as the upload format).
It shows with correct orientation when viewed on the phone.
Change History (5)
comment:1 by , 13 years ago
comment:2 by , 13 years ago
This issue seems to lie in GStreamer, using the totem video player to play the file shows the same results.
My initial thought is that this issue occurs because Apple has extended their implementation of video beyond the standards. This issue will be deprioritized by me.
comment:3 by , 12 years ago
| Milestone: | 0.3.1 |
|---|
This didn't make it into the 0.3.1 milestone.
If someone is planning on working on this for 0.3.2, then please assign the bug to yourself and move it to the 0.3.2 milestone.
comment:4 by , 12 years ago
| Resolution: | → wontfix |
|---|---|
| Status: | new → closed |
comment:5 by , 8 years ago
| Cc: | added |
|---|
Issue still present with the video recorder of Android 6+ (CM13).
As a workaround I end up rotating the videos
ffmpeg -y -i tmp_XXX-VID_YYY.medium.webm -vf transpose=1 a.webm
mv a.webm tmp_XXX-VID_YYY.medium.webm
mogrify -rotate 90 tmp_XXX-VID_YYY.thumbnail.jpg
The does the right thing with the video, but the sizes of the UI are a bit off, reflecting the unrotated dimension. Probably something stored in the DB.
So is the issue here that gstreamer should check orientation metadata and rotate things in the pipeline? What causes the difference?