Blender does not read rotation metadata in some videos #107493

Open
opened 2023-05-01 09:00:59 +02:00 by YimingWu · 6 comments
Member

System Information
Operating system:
Graphics card:

Blender Version
Broken: 3.6
Worked: assume never

Short description of error

Blender does not read rotation metadata in some videos

Exact steps for others to reproduce the error

  • Download the .mov file from #107487
  • Open that movie in Blender, it's rotated 180 degrees.

Looks to me that from the code blender never took into account of AVStream::metadata, where the rotation info of that particular (type of ?) file is saved.

I have found some code online and fiddled it for a bit, it can read the metadata correctly, only thing lacking is the imbuf rotation implementation, or use its transform, need investigation.

**System Information** Operating system: Graphics card: **Blender Version** Broken: 3.6 Worked: assume never **Short description of error** Blender does not read rotation metadata in some videos **Exact steps for others to reproduce the error** - Download the `.mov` file from #107487 - Open that movie in Blender, it's rotated 180 degrees. Looks to me that from the code blender never took into account of `AVStream::metadata`, where the rotation info of that particular (type of ?) file is saved. I have found some code online and fiddled it for a bit, it can read the metadata correctly, only thing lacking is the `imbuf` rotation implementation, or use its `transform`, need investigation.
Author
Member

Managed to read the rotation this way:

static double ffmpeg_get_stream_rotation(AVStream *st)
{
  AVDictionaryEntry *rotate_tag = av_dict_get(st->metadata, "rotate", NULL, 0);
  uint8_t *displaymatrix = av_stream_get_side_data(st, AV_PKT_DATA_DISPLAYMATRIX, NULL);
  double theta = 0;

  if (rotate_tag && (*rotate_tag->value) && strcmp(rotate_tag->value, "0")) {
    char *tail;
    theta = av_strtod(rotate_tag->value, &tail);
    if (*tail) {
      theta = 0;
    }
  }

  if (displaymatrix && !theta) {
    theta = -av_display_rotation_get((int32_t *)displaymatrix);
  }

  theta -= 360 * floor(theta / 360 + 0.9 / 360);
  return theta;
}

later

  /* Update resolution as it can change per-frame with WebM. See #100741 & #100081. */
  anim->x = anim->pCodecCtx->width;
  anim->y = anim->pCodecCtx->height;

  printf("AVStream rotation: %lf\n", ffmpeg_get_stream_rotation(v_st));

gets AVStream rotation: 180.000000. So it's just the matter of figuring out the actual rotation thing. for 180 deg it's simpler because the w/h dimension doesn't change but if 90 deg I need to check if other parts is been affected.

Managed to read the rotation this way: ```C static double ffmpeg_get_stream_rotation(AVStream *st) { AVDictionaryEntry *rotate_tag = av_dict_get(st->metadata, "rotate", NULL, 0); uint8_t *displaymatrix = av_stream_get_side_data(st, AV_PKT_DATA_DISPLAYMATRIX, NULL); double theta = 0; if (rotate_tag && (*rotate_tag->value) && strcmp(rotate_tag->value, "0")) { char *tail; theta = av_strtod(rotate_tag->value, &tail); if (*tail) { theta = 0; } } if (displaymatrix && !theta) { theta = -av_display_rotation_get((int32_t *)displaymatrix); } theta -= 360 * floor(theta / 360 + 0.9 / 360); return theta; } ``` later ```C /* Update resolution as it can change per-frame with WebM. See #100741 & #100081. */ anim->x = anim->pCodecCtx->width; anim->y = anim->pCodecCtx->height; printf("AVStream rotation: %lf\n", ffmpeg_get_stream_rotation(v_st)); ``` gets `AVStream rotation: 180.000000`. So it's just the matter of figuring out the actual rotation thing. for 180 deg it's simpler because the w/h dimension doesn't change but if 90 deg I need to check if other parts is been affected.
Sergey Sharybin added
Type
To Do
and removed
Type
Report
labels 2023-05-01 17:24:24 +02:00

Strictly speaking missing functionality is not a bug, so converting to a TODO.

Is great to see there is even a code for this :)
Do you feel like creating a PR for this?

The worrysome lines are those:

anim->x = anim->pCodecCtx->width;
anim->y = anim->pCodecCtx->height;

If the resolution could indeed change in video we probably do not have other choice than doing so. However, I do not think this is well-supported in MovieClip. Maybe other areas like VSE transform would also need to be worked on for a full support of such videos.

Strictly speaking missing functionality is not a bug, so converting to a TODO. Is great to see there is even a code for this :) Do you feel like creating a PR for this? The worrysome lines are those: ```C anim->x = anim->pCodecCtx->width; anim->y = anim->pCodecCtx->height; ``` If the resolution could indeed change in video we probably do not have other choice than doing so. However, I do not think this is well-supported in MovieClip. Maybe other areas like VSE transform would also need to be worked on for a full support of such videos.
Author
Member

I'm not sure the design of vse would ever be able to support changing resolution, some video formats does allow that. But in this particular case, the resolution is fixed, just need to rotate the image a bit. The main thing I'm not sure is that is this the only place that we set anim->x, anim->y or if there are any other code paths that e.g. sets similar dimensions in other related data structures so we must change everything that uses this. Is every frame gonna read the x, y values? (I assume not... I'll take a look tomorrow, in which case a transformation tag needs to be recorded in animtoo, probably)

180 deg rotations are technically simpler because technically we only need to add a rotation alongside the existing flip functions without really affecting other stuff.

I'm not sure the design of vse would ever be able to support changing resolution, some video formats does allow that. But in this particular case, the resolution is fixed, just need to rotate the image a bit. The main thing I'm not sure is that is this the only place that we set `anim->x`, `anim->y` or if there are any other code paths that e.g. sets similar dimensions in other related data structures so we must change everything that uses this. Is every frame gonna read the x, y values? (I assume not... I'll take a look tomorrow, in which case a transformation tag needs to be recorded in `anim`too, probably) 180 deg rotations are technically simpler because technically we only need to add a rotation alongside the existing `flip` functions without really affecting other stuff.
Author
Member

Related: #98480

Related: #98480

Oh, we already have code which updates resolution in the ffmpeg_fetchibuf. It is fine for Image datablock, but the Movie Clip might need some work to properly support it (there was some WIP code which was commented out due to performance reasons). Anyway, that's a story for another investigation.

From looking into the code there are two important places to cover where the resolution is set: startffmpeg() and ffmpeg_fetchibuf(). If covering those cases gives correct results in the video files we have that's a pretty good starting point.

So I think what we can do is:

  • Read rotation in startffmpeg(), and store it in anim. Seems you already have code most of the important code for that :)
  • Have utility function to assign anim->x and anim->y which will take into account the rotation and anim->pCodecCtx->width/anim->pCodecCtx->height. Use this function in the startffmpeg and ffmpeg_fetchibuf
  • Somewhere in the ffmpeg_fetchibuf add a rotation filter. I think we already do some filtering there, so hopefully it will be easy to hook things up there.

Does this sound like a plan? Does it help moving towards getting code you've listed as a comment to a PR? =)

Oh, we already have code which updates resolution in the `ffmpeg_fetchibuf`. It is fine for Image datablock, but the Movie Clip might need some work to properly support it (there was some WIP code which was commented out due to performance reasons). Anyway, that's a story for another investigation. From looking into the code there are two important places to cover where the resolution is set: `startffmpeg()` and `ffmpeg_fetchibuf()`. If covering those cases gives correct results in the video files we have that's a pretty good starting point. So I think what we can do is: - Read rotation in `startffmpeg()`, and store it in `anim`. Seems you already have code most of the important code for that :) - Have utility function to assign `anim->x` and `anim->y` which will take into account the rotation and `anim->pCodecCtx->width`/`anim->pCodecCtx->height`. Use this function in the `startffmpeg` and `ffmpeg_fetchibuf` - Somewhere in the `ffmpeg_fetchibuf` add a rotation filter. I think we already do some filtering there, so hopefully it will be easy to hook things up there. Does this sound like a plan? Does it help moving towards getting code you've listed as a comment to a PR? =)
Author
Member

@Sergey It sounds pretty good! I think I can give it a try :) Thanks!

@Sergey It sounds pretty good! I think I can give it a try :) Thanks!
Sign in to join this conversation.
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset Browser
Interest
Asset Browser Project Overview
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
EEVEE & Viewport
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
EEVEE & Viewport
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No project
No Assignees
2 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: blender/blender#107493
No description provided.