-
-
Save ViktorNova/1dd68a2ec99781fd9adca49507c73ee2 to your computer and use it in GitHub Desktop.
$INPUTVIDEO='input.mp4' | |
$OUTPUTVIDEO='output.mp4' | |
ffmpeg -i $INPUTVIDEO -metadata:s:v rotate="-90" -codec copy $OUTPUTVIDEO |
It works, but only if the format of video supports rotation: OK for mp4, do nothing for WebM.
In order to keep all metadata, for example creation_time, which was dropped in my video with the above command, consider these parameters:
ffmpeg -i $INPUTVIDEO -movflags use_metadata_tags -metadata:s:v rotate="0" -map_metadata 0 -codec copy $OUTPUTVIDEO
Also, if a file is already rotated (ie, already portrait at -90 or 90) and you want to get it in landscape, use 0 degrees like the example above.
And, exiftool can rotate the metadata attribute in-file, I prefer this method as it doesn't introduce any changes to the file like the "encoded with lavc" or so of ffmpeg, it just flips a few bits and that's it:
exiftool -rotation=0 $INPUTVIDEO
Changing the mp4 files by changing the Metadata(Rotation) Flag is the great way, but it occures the wrong result when you decide to join that file, with some other files with Rotation=0
flag. So that times, you have not any choice other that use the -vf "transpose=[0|1|2|3]"
command with ffmpeg program.
I had no luck with this when using mplayer or a server's html5 player to play a video encoded on an iphone in portrait mode. Both the original clip, and the clip encoded using ffmpeg with the 'rotate="90"', displayed video rotated -90 degrees (top of the picture on the left)
This is likely related to how iphones rotate clips: the material is always encoded with width greater than height; the track header, or "tkhd", for the video track indicates width=1920 and height=1080 for this portrait-recorded clip. Apple attempts to signal rotation to the decoder (in this case mplayer or the html5 player) by using the "matrix" values in the "tkhd" to indicate that the decoder must rotate the video by 90 degrees. This clip uses a matrix which does that, rather than a unity matrix that would indicate no rotation.
However, the international standard for the video (ISO/IEC 14496-12 2015, section 8.3.2.3) indicates that the "matrix" values must be a unity matrix ...
matrix provides a transformation matrix for the video; (u,v,w) are restricted here to (0,0,1), hex (0,0,0x40000000)
In other words, ISO (International Standards Organization) does not allow the encoder to use the matrix for the rotation. Because of that, an ISO-compliant decoder can ignore the video rotation. Players may optionally support it (ffplay does), at the expense of computation complexity (cpu cycles).
I've dealt with this issue in web servers by always fully transcoding any video that's uploaded, using ffmpeg (which, like ffplay, is based on libavformat, which provides the rotation). This resets the tkhd matrix to a unity matrix.
I had success with this
ffmpeg -i input.mp4 -vf "transpose=1" output.mp4
This link explains the correct way to do it now (without reencoding), as the -metadata:s:v rotate="-90"
method has been deprecated and removed from the most recent versions of ffmpeg.
i tried hflip on a video and it made no difference :-( not your fault, i should be complaining to FFmpeg which i will now do.