I would like to see this implemented.

I have just one question:
Let's say, that I have project of 100fps and source of 10fps, and I want do do a cut on frame 5. Is that possible?
That is possibility of doing exact cuts.
Second question would be, if speed fx can work with this, but we can modify speed fx...

I am asking this, because I have patch D3496, that handles sped up sounds to behave "more correctly" (e.g. to respect set pitch vs timeline timebase). This patch is mess, because I didn't want to touch Sequence struct, so I had to do a lot of conversions.

Solution to exact cuts can be using floats for Sequence struct members, that affects timeline position. That is start, len, offsets and so on.
Such change would require changes in UI:

• ability to place playhead inbetween 1 frame (move playhead one "sample" / time interval)
• cut position to be represented by timelineFrameNr +SubSampleNr
• I would say that scrubbing should also in this case respect subsampling

This would be considerably more work to be done, but it would be good IMO...

In D4067#92063, @Richard Antalik (ISS) wrote:

Let's say, that I have project of 100fps and source of 10fps, and I want do do a cut on frame 5. Is that possible?

In that particular case, doing the cut on frame 50 of the strip would result in a cut on frame 5 of the source, but only because they're a nice multiple of each other. If you made the cut on frame 45, you would get 5 (scene) frames of frame 4 of the source before frame 5 was presented.

Maybe in the case of playback significantly slower than scene rate, we could draw source frame markers on the movie strip so you could see where to make cuts?

In D4067#92068, @Olly Funkster (Funkster) wrote:

In D4067#92063, @Richard Antalik (ISS) wrote:

Let's say, that I have project of 100fps and source of 10fps, and I want do do a cut on frame 5. Is that possible?

In that particular case, doing the cut on frame 50 of the strip would result in a cut on frame 5 of the source, but only because they're a nice multiple of each other. If you made the cut on frame 45, you would get 5 (scene) frames of frame 4 of the source before frame 5 was presented.

Sorry I was thinking of reverse scenario - 10fps project and 100 fps source, and cut on frame 5 of source. That would be cut at frame 0.5
Or with my all float proposal that would be cut at 0 +5

If I understand this correctly, this means that this patch will change cut operator behavior, so user will need to calculate cut position manually. I would like to keep cut operator WYSIWIG as it is now. And consistent.

Maybe in the case of playback significantly slower than scene rate, we could draw source frame markers on the movie strip so you could see where to make cuts?

May be also a way. It would be good idea to start discussion about this issue.
Or just do it, but make it so user doesn't notice :)

With sound patch that I mentioned earlier there was another magic, that user could animate pitch (FPS) so drawing that is quite a challenge.

Aren't there also formats, where you can mix framerates within one file?
We don't have to support obscure file formats however.

Ah, yes that would be impossible with this patch as-is. If all the start / end offsets etc. were made into floats then it would behave as you want with 0.5 in it.

In D4067#92081, @Richard Antalik (ISS) wrote:

Aren't there also formats, where you can mix framerates within one file?

I think so yes, and also formats where the presentation time of each frame can be specified individually. I think that's beyond the scope of the VSE though - blender itself, and any decent video camera, has constant framerate for a given clip.

In D4067#92081, @Richard Antalik (ISS) wrote:

If I understand this correctly, this means that this patch will change cut operator behavior, so user will need to calculate cut position manually.

In your example, we could over-ride the "slip" operator (or whatever it's called, press s) to allow slipping of source frames rather than scene frames, and if you are zoomed in far enough we could show source frames on the strip in between scene frame markers so that the user could slip the source until frame 5 is at the beginning of the strip.

Anyway, I think we can merge this, and deal with partial frames implementation later. Unless @Olly Funkster (Funkster) would like to do that :)
There is subframe in RenderData struct - maybe use that?

typedef struct RenderData {

	...
	int cfra, sfra, efra;	/* frames as in 'images' */
	float subframe;			/* subframe offset from cfra, in 0.0-1.0 */
	int psfra, pefra;		/* start+end frames of preview range */
	...

In this context, if any changes are to be made, I would also like to create more modular code. In this case create module, that handles strip manipulation, offsets and stuff like that.
so cut operator can look like

cut(){
	move_right_handle(seq1, -50, HARD);
	move_left_handle(seq2, 1050, HARD);
}

I think, that this has to be done at some point. It may even accelerate development further.

I think partial frames can wait, I would expect 99% of users of rate control wouldn't need such exact timing control. If someone is happy to merge it, fire away!

Yes, this is messy situation. similar to D3496.
In that patch I said, that I do not recommend committing.

I think, that I will require some underlying framework for these 2 patches to be applied.
Then I will change D3496 as a "template" of how this should look.

My earlier comments apply more to functionality then code itself.

And thanks for sample reviews :)

Latest adjustments to suit. If this approach on the UI isn't acceptable I'll try something more complicated, but I thought if the simpler, less-code option is okay I would go with it.

If you want to test it against a (unofficial) 2.80 VSE panel, you can get it here: https://devtalk.blender.org/t/can-we-in-collaboration-produce-a-working-suggestion-for-improving-the-user-interface-of-the-vse/3264/77

Oh, sorry I didn't notice it is the import options(so the link above won't make a difference. In 2.80 it seems like all panels are right aligned - however only the image input settings are right aligned, movie and sound import options are left aligned. Maybe they all should be right aligned?

Here is timeline API proposal: T59540
It may be quite a lot of work, but not difficult.

I like to write a lot, and couldn't sleep...

I may add:
When testing, srtips like to behave different when:

• strip is uncut
• left side of cut strip
• right side of cut strip
• middle side of cut strip
• is soft cut
• is hard cut
• has still frames on the end
• has still frames at start
• has still frames on both sides
• ...
• any combination of these

Don't know if you have tried such tests, just saying, that it may be better to invest time somewhere else at this point.

I will get to this eventually, it will take time. Don't know how long, we are missing so many essential things.

Impressive perseverance. I do not have any mandate to greenlight your patch, but I think those in power to do so, should let you know if this feature is wanted on not, before you invest anymore time in it.

One major problem with this approach of allowing strips to play at individual frame rates, is when exporting VSE projects to other editors is implemented, many of the export formats do not support timelines with strips played at different playrates than the project fps. Maybe this could be worked around during export by rendering fps converted intermediate files, but in general fps mismatch(or variable framerates) are handled at import by rendering high quality intermediate files.

Another thing, since this also is working during import, is that audio should be handled too, so sync isn't lost. Maybe this is already been taken care of?

Testing with a couple of videos with timecode:

This seems to be more of a Source or import setting than an alternative to Speed strips, though it can be used as such, however Speed strips are offering more speed control options, though they are presented in a very confusing way: https://developer.blender.org/D6110

You properly know this, but the UI needs to be updated to the 2.8+ style, where things are right aligned, the override checkbox can be placed on the same line as the rate value(take a look at the text strip's shadow) and decorate should be on, if the rate value can be animated.

Thanks @Peter Fog (tintwotin) - I'll fix the UI stuff soon.

Audio isn't dealt with at all, since the audio sample rate is not tied to video frame rate. However I can see the benefit of dealing with a mismatch in samplerate of the clip's audio at the same time, by adjusting the "pitch" parameter of the audio strip if it doesn't match the project's audio samplerate.

FWIW I persist with this because I use it alllll the time when editing project videos for youtube.

I have tested the patch, and here is some feedback:

Having to manage orig_rate in Sequence isn't ideal. Best approach is to keep handle to anim and read original framerate directly from file. This ensures that it is always correct. At least for playback. Otherwise we could have informative fps value for other purposes.
But I don't even think this is necessary for vast majority of cases. If playng videos in source framerate is default, you can read original file when creating strip as it is done already, get FPS from original media, calculate factor and use it during rendering. That's pretty much what you do in this patch. For other cases read FPS directly from file. I can be done with function similar to seq_open_anim_file() This function is quite monstrous and can be refactored to open anim from original or proxy and return it. That should be bug 2 and 4 fixed.

Other strip types such as scene strips, can provide you with reliable FPS, movie clip and mask strips not sure if that can be implemented nicely, because these can work with image sequences. Supporting movies initially sounds good enough for me.
I am not quite sure about using this property for meta strip. It sounds like abusing this feature to do things it is not supposed to do.

Can you clarify reason for overriding source FPS? I can understand convinience factor of not having to use speed effect. Or for overriding framerate for image sequences, but these are not supported here.
Is playback_rate supposed to simplify workflow when you have to calculate difference between scene framerate and media framerate?

UI:
I suggest to use enum wher you can choose:

• normal speed - calculate (default)
• frame by frame
• custom framerate
  • here playback_rate will be visible and editable.

Checkbox for changing length seems reasonable, I don't think it can be eliminated by design.

Panel could be moved near time panel. It's bit too prominent now IMO. Ideally you wouldn't need to touch it, and if, then only once.

bugs:

• Once you edit(split, move handle) overriden strip it doesn't follow in time correctly. pretty much in same way as when you split strip with speed effect. (Now checking again and I am not sure how to reproduce anymore, but I swear I could cause this, need to check this again more carefully)
• Changing overridden playback speed of strip that has been split result in strip content shifting. Not sure if this is due to precision issues when calculating new strip offsets.
• While only few strip types have playback speed options exposed in UI, any strip does have these properties accessible from python.
• Opening old files with proxies will result in original FPS being set to 0

There are quite a few issues with code as well, but I think I should address core principles first.

Just by the way, can you make diff more verbose with command git config diff.context 100? it is quite difficult to see where changes are here. You don't have to, it just simplify things for me a little bit.