Videos in portrait format get rotated

[SuperMasterPhoenix]

Hi Martin, as already stated in #42 the fix revealed another issue: publishing videos in portrait format results in a by 90° rotated video. If I add the 'Rotate-0' keyword to these videos they do get exported in portrait format so this isn't a big problem. Is this expected behaviour?

Kind regards, Mike

[flingo64]

'Rotate-0' is not supported and has no effect on video conversion at all. So, if Rotate-0 works, no Rotate-xx keyword should also work. Remember: the Rotate-xx keyword is only required for very old rotated (non-landscape) videos,where the camera did not add a rotation indication into the video header. Todays cameras typically add a rotation tag to the video, so that Photo StatLr can perform the correct hard-rotation without specifying the 'Rotate-xx' keyword.

[SuperMasterPhoenix]

Hi Martin, thanks for your fast response.

I've just tested it again using two videos in portrait format from two different smartphones, duplicated each of them and tagged one with 'Rotate-0' and the other one without any keyword. Exporting them resulted in the previously described behaviour, the one tagged with 'Rotate-0' is still in portrait mode, the other one rotated by 90°. I do not know why the video gets rotated and I am also not sure why the workaround with 'Rotate-0' works, my only guess is that it has to do with PSUploadTask.lua#L337 where (maybe) some previously set rotation flag is overwritten.

The following stuff is only for the video from one smartphone as the other one shows exactly the same behaviour. 'vid_mit.mp4' is the video with the Rotate-0 keyword, 'vid_ohne.mp4' without keyword. Video in Lightroom: Exported video: And the logfile of the export (I just removed some personal information): photostatlr portrait logfile.txt The created ffmpeg commands are in line 397 and 653. If needed I can also provide you this short videoclip.

PS: currently I need the Rotate-xx keywords for videos where the rotation indication has been set incorrectly or the camera has been turned during filming, but thats not the case in the clip I used above.

[flingo64]

With 'Rotate-0' (vid_mit.m4) you effectively disabled hard-rotation as you can see in line 397:

• no transpose option
• -s 3840x2160 -aspect 3840:2160 --> dimension still landscape

So the generated video is still soft-rotated (has the rotation tag in the video header, you can verify this with the MediaInfo app) and the player is doing the rotation on the fly.

Without the 'Rotate-0' keyword, the plugin identifies the soft-rotation by the rotation tag in the video header and does the hard-rotation:

• -vf format=yuv420p,transpose=1 --> hard rotate
• -metadata:s\:\v\:0 rotate=0 --> reset rotation flag for video stream 0
• -s 2160x3840 -aspect 2160:3840 --> set new dimension/aspect ratio

So, this video should be hard-rotated as requested.

Can you please double-check if the resulting video is the latest generated video, not an earlier one from the Browser's cache (clear cache). If this is the case, please send me the Output of MediaInfo of the resulting video.

[SuperMasterPhoenix]

I checked the resulting videos directly in Windows Explorer and VLC player (but they are also wrongly rotated in the Photo Station in two different browsers and Android).

Here is the output of MediaInfo and ffmpeg (wasn't sure, which one you mean) for the two resulting videos: mediainfo vid_ohne.txt - ffmpeg vid_ohne.txt

mediainfo vid_mit.txt - ffmpeg vid_mit.txt

PS: I tried two other cameras, too (one camcorder and one DSLR) but they do not add the rotation flag at all, so I am only able to try it with my smartphone...

[flingo64]

The 'video_mit' case is clear: 'Rotate-0' disabled any hard-rotation, source and target video are landscape video with rotation flag set to 90 --> soft rotation is done by player, OK! The 'video_ohne' case is not as expected: hard-rotation is done, but the rotation flag wasn't reset. Thus, the player applies soft-rotation to the already rotated video. It seems the option -metadata:s:v:0 rotate=0 --> reset rotation flag for video stream 0 didn' work as expected. Either a change in ffmpeg syntax or something very special with those videos. Could you provide me a video from that smart phone for testing?

[SuperMasterPhoenix]

Sorry, just saw that you edited your post. Sure, here it is: vid.zip. Thanks for your time to investigate this issue!

Probably that's also the reason why soft rotate in combination with the 'Rotate-xx' keywords didn't work for me in the beginning and I chose hard rotate...

[flingo64]

After testing different variation of the rotation metadata reset option, I search the Internet for it and in fact, it seems there is a bug in ffmpeg since version 3.3 so that overriding the rotation metadata in the video stream is not possible anymore, see: https://trac.ffmpeg.org/ticket/6370 So, hard rotation still works perfect for videos w/o embedded rotation metadata, but no longer for videos having rotation metadata embedded. :-( Going back to a very old ffmpeg version is an option, but requires different option for the video filtes and video option. I'll check if I can compose a video conversion preset that will work with an older ffmpeg version...

[flingo64]

Using ffmpeg's autorotation option seems to do the job for videos with rotation tags. That means I have to rewrite the code handling hard-rotation/soft-rotation for videos with an without rotatition metadata...

[flingo64]

Best solution for the moment: use ffmpeg v3.2.4. This version is compatible with the command line syntax used by Photo StatLr, is has support for all pre-configured video codecs (including CUDA) and last but not least it handles the rotation metadata reset required for hard-rotation correctly. This is even better than the autorotate option, because you still can override rotation behaviour by use of the 'Rotate-xx' keyword. Please, check it out.

[SuperMasterPhoenix]

Hi Martin, wow, thanks for your effort and help. I really appreciate it!

Unfortunately the CUDA profiles in 3.2.4 do not seem to work as expected, the videos are always generated in a very low quality, no matter whether I choose High-CUDA oder Higher-CUDA. But as I discovered recently that the CUDA-profiles are a lot faster than the regular profiles I'd like to stick to them ;-) So it seems that for the moment I either have to use the CPU-profiles or the Rotate-0 keyword until ffmpeg fixes the described issue.

From my side this bug can be closed as it isn't caused by Photo StatLR itself, but I leave that up to you.

Best regards, Mike

[flingo64]

You're right the CUDA profiles all generate the same output with ffmpeg 3.2.4, probably because the -preset option isn't supported in th h264_nvenc codec in that release. I don't want to miss the CUDA profiles also. It took me quite a while to understand and test the various settings and to define reasonable profiles. Also, I like the speed and the idea that my NVIDIA GPU isn't idle all the time.

To summarize the issue:

• with ffmpeg < 3.3.x:
  • hard-rotation will work for videos without embedded rotation tag via Meta-rotation feature (keywords 'Rotate-xx')
  • hard-rotation will also work for videos with embedded rotation tag
  • soft-rotation (hard-rotation disabled or enforced by 'Rotate-0') will work for all videos
  • various optimizations incl. CUDA support won't work.
• with ffmpeg >= 3.3.x:
  • hard-rotation will work for videos without embedded rotation tag via Meta-rotation feature (keywords 'Rotate-xx')
  • hard-rotation won't work for videos with embedded rotation tag, because resetting the embedded rotation tag isn't possible due to an issue in ffmpeg >= 3.3.x
  • soft-rotation (hard-rotation disabled or enforced by 'Rotate-0') will only work for videos without embedded rotation tag
  • various optimizations incl. CUDA support will work

You need to be an video expert to understand all this and to decide which way to go! I'll keep this issue open and see if I can find a more convenient way maybe using ffmpeg's autorotate option. Anyway, this may take a while ...

[flingo64]

Faster than I thought and the code is getting much cleaner: using the ffmpeg autorotate feature I was able to do hard-rotation:

• for videos w/ embedded rotation tag
• for videos w/o embedded rotation tag and meta-rotation ('Rotate-nn')
• for videos w/ embedded rotation tag and additional meta-rotation ('Rotate-nn') to fix video with wrong rotation tag (e.g. videos where the camera was turn around during recording)

And that all works well with ffmpeg 4.x including CUDA support!

I will release it within the next days (need some more testing).

:-))

[flingo64]

Version 6.8.7 should fix the issue. Please, check out!

[SuperMasterPhoenix]

Pretty cool, the rotation works now as expected :-) Thank you for your work!