Openshot-qt: Clip property

[amuellerde]

Hello,

what means the Clip property "anchor"

[peanutbutterandcrackers]

Whoa. Strangely enough, the user-guide does not have an explanation for it. @DylanC @ferdnyc, any ideas, gentlemen?

[ferdnyc]

Yeah, here's the funny thing about that: The Anchor parameter appears _nowhere_ in the OpenShot source code. It is never, ever used by OpenShot.

It's coming from libopenshot, which attaches it to the parameters for a clip when creating the data structures. But _other than_ attaching it, it doesn't appear that libopenshot ever uses that parameter, either.

It's an enumerated value, with two possible settings, as you've probably noticed: "Canvas" (the default), or "Viewport". Just based on those names it clearly has _something_ to do with either the placement of the clip's video content within the output frame, or perhaps the origin-point when any scaling/translation is performed. Honestly, I'm not sure which, and there doesn't appear to be enough information to go on even in the source code.

There also doesn't appear to be much effect it could have on the timeline/clips, since as I said OpenShot literally _never_ so much as examines that parameter. Anywhere! It's not even clear to me that libopenshot does, beyond passing it along.

It seems _most_ possible that there may be side-effects to altering "Anchor", when parameters like "Scale X/Y", "Rotation", "Shear X/Y", and etc. are changed. But what those might be, and what the exact relationship is between the two possible "Anchor" values and any other parameter? ¯\_(ツ)_/¯

[peanutbutterandcrackers]

Strange, indeed...

[DylanC]

@peanutbutterandcrackers - This is a really good question. I don't really have an idea about this anchor property. 😆

[peanutbutterandcrackers]

lol Perhaps we'll have to ask Mr. Thomas....

[jonoomph]

Okay, so I had big plans for "anchor" back many years ago, but it kind of just slipped through the cracks. I should probably remove it for now, and bring it back in the future if needed. I was imaging a scenario where a viewport could be keyframed independently from the timeline, thus creating a pan-and-scan solution for switching between 16x9 formats and 4x3 formats. At least that was the concept originally, but it was never fully implemented.

Anyone want to assist in implementing that? Or should we just remove it for now to remove any confusion? Thanks!

[ferdnyc]

TBH, at _this_ point in the evolution of video, with 16:9 displays being near-ubiquitous, I'd question whether 4:3 output — and 4:3 output from widescreen source media, especially — is common enough to be worth all the effort. That might've been handy a bunch of years ago, when films were widescreen but most home displays were 4:3...

[ferdnyc]

(Although I suppose you could argue that there's still an application, in the formatting of 2.39:1 films to fit 16:9 displays. But letterboxing seems to have gained acceptance as the preferable alternative to pan&scan, for dealing with aspect ratio mismatches.)

[DylanC]

@amuellerde - Does the above from jonoomph answer your question in enough detail?

[DylanC]

I consider this question to be fully answered. Closing for now. Jonathan to possibly remove this anchor property for the future.

[amuellerde]

Hi all,
sorry i am wasn't onlne the last 2 days.
Yes, my question is answered.
Many Thanks an all.

[peanutbutterandcrackers]

Can someone please point me to a video or sth that shows the difference between the bars style of dealing with this vs the approach that Mr. Thomas is suggesting? o.O I'd like to know.....

[ferdnyc]

I don't know that there's a good _video_ of it, because in the normal case the whole point of pan&scan is that you can't see it. (There's probably a video _about_ the technique somewhere, but demonstrating the results of the technique itself is by its very nature difficult.)

Pan & Scan is how every movie wider than 4:3 aspect ratio was transferred to standard-definition video (VHS, primarily) as a full-frame picture. Since many films are wider than 16:9, and all films are wider than 4:3, you have two choices for displaying a wider-screen-format presentation on a standard-aspect television with a narrower aspect ratio:

1. You can letterbox the wide-aspect content, placing black bars above and below so that the full frame in its native aspect fits within the frame of the narrower display device.
2. You can transfer the wide-aspect content at the full _height_ of the narrower display device, in which case only a portion of its width would fit in the frame.

Pan & Scan is the technique by which the latter was achieved. Imagine a movie screen (wide 2.39:1 aspect ratio), with a 4:3 frame of the same height placed on top of it, representing the portion of the movie screen that will be seen on the television. As the movie plays, the TV frame can be slid left and right to include different areas of the movie screen, panning back and forth to focus the on the most important characters or scenery at that moment.

That's it. But anytime you've watched a movie on cable or home video that's been "formatted to fit this screen", you've been watching the results of pan & scan.

[N3WWN]

This page may help 👻

https://www.theraffon.net/~spookcentral/widescreen.htm

Sounds like @jonoomph had an idea to smoothly (seamlessly?) transition between formats.

I don't see a lot of use for this nowadays, but that doesn't mean it couldn't be very useful in a different, creative application that I can't think of at the moment. 😜

[peanutbutterandcrackers]

Perhaps keep it a low-priority will-be-implemented-in-a-very-distant-future-because-we-are-so-hip feature? :D

[ferdnyc]

Perhaps keep it a low-priority will-be-implemented-in-a-very-distant-future-because-we-are-so-hip feature? :D

Right, that's called "removing it". It can always be _added back_ later, *if* that very distant future comes to pass. Until then, there's no advantage to having the parameter there, and having undocumented parameters lying around waiting for future implementation is crazy. If it's going to be left in _now_, it needs to be documented _now_, regardless when it might be implemented. Personally I'd rather see one line of code deleted, vs. multiple lines of documentation added for a feature that doesn't exist.

[peanutbutterandcrackers]

@ferdnyc - touché