I found this Feb. 2020 topic started by "beernoo" and have found new difficulties. My rotated video was created on an Android phone. Some of my videos are sideways (portrait) and some are upsidedown when viewed on Windows 7 laptop or on Roku TV or other TV's that play videos directly from USB. Mysteriously, they all appear upright when opened on a Windows 10 machine. (Creepy. What if I really wanted them to be sideways or upside down!?) They also automatically appear correctly when opened with VLC on the Windows 7 laptop. It would be nice to see them on one of my 55" TV's so I want an easy way to rotate the file(s) itself.
The exiftool seems ideal since I wouldn't have to deal with GUI (I'm an old DOS guy!).
I followed the directions provided in the 2020 beernoo topic. I tried both the "Stack Overflow" and exiftool creator's directions, deleting files and renaming (name restoring) the original in between to start clean each time. Working from the command line, I use the 2-step process. It seems the 1st step "sets" the starting point (angle). Then the 2nd step (with the $ signs) is supposed to rotate from there. Each time the tool replies "1 image files updated". The 1st step creates a new file and renames the original, but the second step does not create a 3rd file (just fine, shouldn't be necessary). I monitor these things with Windows and see that the tile for the new file never changes (still shows inverted image) and, when opened with Microsoft viewer, appears upsidedown (or sideways, depending on file).
I opened the files with Notepad (rename to .txt) to compare and maybe see changes. The original and final "updated" files appear identical so I wonder where any update is hiding?
I've heard that not all mp4's are created equally. Perhaps exiftool couldn't find what it was looking for inside my file and couldn't change what apparently did not exist?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
There should be no 2-step process necessary unless you are using the "$_ += 90" command which adds 90 degrees to the rotation angle. Writing the Rotation tag sets the MatrixStructure according to the angle you specify. Player inconsistencies may indicate that some players ignore the MatrixStructure and display the video without rotation.
But I can't help any more without seeing your commands. Also, try adding -v2 to the command to see what is actually changing, and looking at the output of this command afterwards:
exiftool -matrixstructure -a -G1 FILE
Also, ExifTool only creates the "original" file if it doesn't already exist. After that you are working on an edited version, not the original.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I added -v2 and got "the dump". Please see attachment.
The result was the usual: still upsidedown with Windows MediaPlayer and file mgr tile, right side up (both original and updated files) with VLC. This is all done on Win7 laptop.
Let's define "correctly". I usually record landscape style, but this time I did some portait style and managed to invert some, but not all, of the landscape videos. With Win10 (movie player?) all are rotated as necessary for easy "correct" viewing automatically. Even the thumbnails (tiles) are "corrected" in the file manager.
Different story with Win7 (and TV's). I have created many landscape videos and have put them on TV without trouble and opened with Media Player w/no trouble, but this time I did some different things with the phone (regretfully).
When I have some more time I want to find out how Win10 (and VLC) are doing it. Maybe I'll make a vid of me standing on my h---Wait a minute! The phone needs to know its orientation to do "auto-rotate" function (which I normally have off). The phone probably includes this info in the mp4 file. Win7 might not recognize this info, but VLC and Win10 probably do.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I also tried rotation=0 and rotation=360. Same dump except change in TrackHeader:Matrixstructure 1 0 0 0 1 0 0 0 16384 for 0 degrees and 1 2.04e-011 0 -2.04e-011 -0 (snipped) for 360 degrees. I guess 2 X 10^-11 is close enough to zero. :)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Just checked here with a video on Windows Media Player (Win 10, ver 12.0.19041.2006) and it displayed a video correctly after I set -rotation=180 and -rotation=90.
Can you share a sample problem video?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This has nothing to do with the issue, but the 2.04e-011 is the computed value. The value actually written to the file is exactly 0 since the storage format can't represent such a small number. But regardless, I'll fix the verbose output to round small numbers like this down to 0.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
My new working theory was that TV's and older media software were ignoring phone orientation info in phone-created mp4 files and that exiftool was effecting a change by simply changing this info.
So I expected Win10 Movie player (on the desktop I rarely use as it has no wifi) to notice a change made by exiftool. It didn't! (nor did VLC). I re-ran from scratch the same command shown in the attachment above which should have rotated 180, making it upsidedown with players that use that info. Win10 and VLC (run in Win7) are still showing my preferred orientation with both the original and updated files. It's like nothing is happening. I'm back to my original guess that exiftool can't edit because something is missing in the original file, but the v2 dump appears to show what the matrix structure was in the original and what it was being changed to. Maybe the matrix structure edit alone is not enough?
Phil, did everything look hunky dory in that "printout" above?
BTW: The tiny number reference was meant as a poke in the ribs. (I was hoping the :) would be the tip-off.) I've seen stuff like that before. I can't remeber the specifics, but the BASIC compiler Gates supposedly wrote came up with a tiny number when subtracting two particular identical rational numbers. Each number was the same, but calculated a different way and then subtracted. Result should have been zero. That was back in the 90's.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes, it looks like something other than just the MatrixStructure of the video track is controlling the orientation. There is also a MatrixStructure in the movie header. I wonder if this needs to be changed. When the ability to write MatrixStructure was added, it worked fine with the software we tested when only the MatrixStructure of the video track was written.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Found an older VLC version on an old XP laptop. It doesn't fix it like the newer VLC automatically does.
I also tried to rotate some old videos that were created with a Logitech webcam and Videopad. Again, no change.
I think I'll use a video editing package to rotate and I'll compare the original and edited files to see if anything jumps out. I can use Notepad again, but I'm guessing your package might help me find the important stuff quicker?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Just be aware that video editing software may actually rotate the image data (and possibly re-compress the image) instead of just changing the MatrixStructure. If it does this, then the output MatrixStructure should always be the identity matrix (1 0 0 0 1 0 0 0 1).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Update. I was hasty with my Logitech video test. (and very busy with other matters since) The thumbnails did not change after exiftool (remained right side up), but the actual video was inverted as I intended for the test. I didn't bother to play the videos that time, but I did not rely on the thumbnails for the cell phone videos and I just double checked to confirm.
So exiftool works for the logitech webcam files, but not for Android cam files.
Sorry for the misinformation!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I found this Feb. 2020 topic started by "beernoo" and have found new difficulties. My rotated video was created on an Android phone. Some of my videos are sideways (portrait) and some are upsidedown when viewed on Windows 7 laptop or on Roku TV or other TV's that play videos directly from USB. Mysteriously, they all appear upright when opened on a Windows 10 machine. (Creepy. What if I really wanted them to be sideways or upside down!?) They also automatically appear correctly when opened with VLC on the Windows 7 laptop. It would be nice to see them on one of my 55" TV's so I want an easy way to rotate the file(s) itself.
The exiftool seems ideal since I wouldn't have to deal with GUI (I'm an old DOS guy!).
I followed the directions provided in the 2020 beernoo topic. I tried both the "Stack Overflow" and exiftool creator's directions, deleting files and renaming (name restoring) the original in between to start clean each time. Working from the command line, I use the 2-step process. It seems the 1st step "sets" the starting point (angle). Then the 2nd step (with the $ signs) is supposed to rotate from there. Each time the tool replies "1 image files updated". The 1st step creates a new file and renames the original, but the second step does not create a 3rd file (just fine, shouldn't be necessary). I monitor these things with Windows and see that the tile for the new file never changes (still shows inverted image) and, when opened with Microsoft viewer, appears upsidedown (or sideways, depending on file).
I opened the files with Notepad (rename to .txt) to compare and maybe see changes. The original and final "updated" files appear identical so I wonder where any update is hiding?
I've heard that not all mp4's are created equally. Perhaps exiftool couldn't find what it was looking for inside my file and couldn't change what apparently did not exist?
I think this is the forum topic you are referring to:
https://exiftool.org/forum/index.php?topic=10806.0
There should be no 2-step process necessary unless you are using the "$_ += 90" command which adds 90 degrees to the rotation angle. Writing the Rotation tag sets the MatrixStructure according to the angle you specify. Player inconsistencies may indicate that some players ignore the MatrixStructure and display the video without rotation.
But I can't help any more without seeing your commands. Also, try adding -v2 to the command to see what is actually changing, and looking at the output of this command afterwards:
exiftool -matrixstructure -a -G1 FILE
Also, ExifTool only creates the "original" file if it doesn't already exist. After that you are working on an edited version, not the original.
I added -v2 and got "the dump". Please see attachment.
The result was the usual: still upsidedown with Windows MediaPlayer and file mgr tile, right side up (both original and updated files) with VLC. This is all done on Win7 laptop.
Do you have a file that is rotated but plays correctly on Windows MediaPlayer? It's entirely possible that it doesn't honor any rotation settings.
Let's define "correctly". I usually record landscape style, but this time I did some portait style and managed to invert some, but not all, of the landscape videos. With Win10 (movie player?) all are rotated as necessary for easy "correct" viewing automatically. Even the thumbnails (tiles) are "corrected" in the file manager.
Different story with Win7 (and TV's). I have created many landscape videos and have put them on TV without trouble and opened with Media Player w/no trouble, but this time I did some different things with the phone (regretfully).
When I have some more time I want to find out how Win10 (and VLC) are doing it. Maybe I'll make a vid of me standing on my h---Wait a minute! The phone needs to know its orientation to do "auto-rotate" function (which I normally have off). The phone probably includes this info in the mp4 file. Win7 might not recognize this info, but VLC and Win10 probably do.
I also tried rotation=0 and rotation=360. Same dump except change in TrackHeader:Matrixstructure 1 0 0 0 1 0 0 0 16384 for 0 degrees and 1 2.04e-011 0 -2.04e-011 -0 (snipped) for 360 degrees. I guess 2 X 10^-11 is close enough to zero. :)
Just checked here with a video on Windows Media Player (Win 10, ver 12.0.19041.2006) and it displayed a video correctly after I set
-rotation=180and-rotation=90.Can you share a sample problem video?
Check my above answer for how Win10 (and VLC) is accomplishing it.
If you don't have access to an older OS (w/older Media Player) you won't be able to see this happen.
This has nothing to do with the issue, but the 2.04e-011 is the computed value. The value actually written to the file is exactly 0 since the storage format can't represent such a small number. But regardless, I'll fix the verbose output to round small numbers like this down to 0.
My new working theory was that TV's and older media software were ignoring phone orientation info in phone-created mp4 files and that exiftool was effecting a change by simply changing this info.
So I expected Win10 Movie player (on the desktop I rarely use as it has no wifi) to notice a change made by exiftool. It didn't! (nor did VLC). I re-ran from scratch the same command shown in the attachment above which should have rotated 180, making it upsidedown with players that use that info. Win10 and VLC (run in Win7) are still showing my preferred orientation with both the original and updated files. It's like nothing is happening. I'm back to my original guess that exiftool can't edit because something is missing in the original file, but the v2 dump appears to show what the matrix structure was in the original and what it was being changed to. Maybe the matrix structure edit alone is not enough?
Phil, did everything look hunky dory in that "printout" above?
BTW: The tiny number reference was meant as a poke in the ribs. (I was hoping the :) would be the tip-off.) I've seen stuff like that before. I can't remeber the specifics, but the BASIC compiler Gates supposedly wrote came up with a tiny number when subtracting two particular identical rational numbers. Each number was the same, but calculated a different way and then subtracted. Result should have been zero. That was back in the 90's.
Yes, it looks like something other than just the MatrixStructure of the video track is controlling the orientation. There is also a MatrixStructure in the movie header. I wonder if this needs to be changed. When the ability to write MatrixStructure was added, it worked fine with the software we tested when only the MatrixStructure of the video track was written.
It might be useful to look at the output of this command for a few files to see if you can figure out a pattern:
exiftool -a -G1 -handlertype -matrixstructure FILE
I got your light-hearted "close-to-zero" reference, but the output still bugged me so I patched it. :)
Found an older VLC version on an old XP laptop. It doesn't fix it like the newer VLC automatically does.
I also tried to rotate some old videos that were created with a Logitech webcam and Videopad. Again, no change.
I think I'll use a video editing package to rotate and I'll compare the original and edited files to see if anything jumps out. I can use Notepad again, but I'm guessing your package might help me find the important stuff quicker?
Just be aware that video editing software may actually rotate the image data (and possibly re-compress the image) instead of just changing the MatrixStructure. If it does this, then the output MatrixStructure should always be the identity matrix (1 0 0 0 1 0 0 0 1).
Update. I was hasty with my Logitech video test. (and very busy with other matters since) The thumbnails did not change after exiftool (remained right side up), but the actual video was inverted as I intended for the test. I didn't bother to play the videos that time, but I did not rely on the thumbnails for the cell phone videos and I just double checked to confirm.
So exiftool works for the logitech webcam files, but not for Android cam files.
Sorry for the misinformation!