MPC-HC v2.0.0

[hubblec4]

Hi clsid

Since when can MPC-HC process the ProjectionPoseRoll element and rotate the video?

My test file from the Matroska Playback repo is suddenly rotated correctly. The test version at the time was 1.8.6 and it didn't work there.

[nevcairiel]

Parsing of the element was added to LAV 0.75.1 (mid 2021), all you need after that is a video renderer that can perform rotations based on the metadata.

[hubblec4]

Cool, great news and thank you nevcairiel for improvements for Matroska playback.

[hubblec4]

One more question:

Is there also a support to rotate for the the x-axis and y-axis (ProjectionPoseYaw and ProjectionPosePitch)?

[nevcairiel]

A 2D image does not rotate around those axis.

[hubblec4]

OK, but why not?
It is technical not a problem, right?

[nevcairiel]

Its a 2D image, you want to rotate it into a third dimension, with a 2D video renderer. Why? Cameras don't record like this, displays dont show like this, renderers dont render like this.

[huhn]

to get the most inefficient way to create a letterbox?

[Cutterkin]

Just FYI, the MediaInfo.dll inside the MPC-HC.2.0.0.138.x64.zip development build is the 32 bit version. The one installed by MPC-HC.2.0.0.138.x64.exe is the proper 64 bit flavor.

And as always, thank you greatly for your continued work on this.

Edit - now fixed.

[v0lt]

I found a problem with rotation.
I used the following command.

ffmpeg -display_rotation 90 -i "movie.mp4" -y -c copy movie90.mp4
ffmpeg -display_rotation 90 -i "movie.mp4" -y -c copy movie90.mkv

ffplay.exe plays MP4 and MKV equally, rotates the frame 90 degrees counterclockwise.

MPC-HC and MPC-BE rotate the MP4 frame counterclockwise (same as ffplay.exe), but rotate the MKV frame clockwise.

Is there a bug in MPC-HC and MPC-BE or in FFmpeg?

[hubblec4]

Matroska defines all positive values from 0 to 180 use the clockwise rotation, all negative values means counterclockwise rotation.

[v0lt]

Originally Posted by hubblec4

Matroska defines all positive values from 0 to 180 use the clockwise rotation, all negative values means counterclockwise rotation.

Hmm.
Element Specifications > ProjectionPoseRoll

Specifies a roll rotation to the projection. Value represents a counter-clockwise rotation, in degrees, around the forward vector. ...

Here it is not clear where the “vector forward” is directed (from the viewer or from the display) and which side of the vector should be looked at to count the angle (usually from the side of the arrow, but I would like confirmation). You can find “heads” and “planes” on the Internet, which doesn’t help. In general, an illustration for the article or official samples could close the question.

Therefore, we read the notes.
Specification Notes > Rotation

The ProjectionPoseRoll Element (see (#projectionposeroll-element)) can be used to indicate that the image from the associated video track SHOULD be rotated for presentation. For instance, the following representation of the Projection Element (#projection-element)) and the ProjectionPoseRoll Element represents a video track where the image SHOULD be presented with a 90 degree counter-clockwise rotation, with the EBML tree shown as XML :

<Projection>
  <ProjectionPoseRoll>90</ProjectionPoseRoll>
</Projection>

I don't remember seeing this before when I implemented frame rotation support for MKV in MPC-BE. This description is more understandable and it differs from what you write.

If I understood everything correctly, then support for frame rotation for MKV in MPC-BE and MPC-HC is done incorrectly.

[hubblec4]

Oh yes, you are right.

What a inaccurate description LOL.
You could ask Steve for better text there. I'm also confused now.

I can understand the counter-clockwise method but we have positive and negative values and this changes the direction too.

Negative value plus counter-clockwise = clockwise?

Before ProjectionPoseRoll element there was the Tags method and there was only positive values for a clockwise rotation.
90 means clockwise rotation and why should now value 90 with ProjectionPoseRoll a counter-clockwise and -90 is then the clockwise rotation?

really weird.

[nevcairiel]

I tried to look at the ffmpeg code, but its written very confusingly. One path negates the rotation, the other one doesn't, it doesn't use the defined helper functions to get the rotation but calculates it itself for some reason or another.

From my understanding of the wording of it, I would think that the ffmpeg code is at fault here, because the forward vector of an image should be coming out of the image towards the user? But its a very weird way to describe it without an example or reference file to confirm.

[Emulgator]

Coming from most physic rules, (and geometry does see ccw as positive too) the right-hand rule should imply that:
If thumb points to viewer (positive values assumed), then index finger would point ccw for positive Z-rotation values.
(hope I did not screw that one up ;-)