I’ve create a project “HD 1080i 25fps” and dragged-dropped several files there. After editing the project I decided to convert the format to “HD 1080p 50fps” for some reasons.
Before changing the format the full project length was 24:32:15
After changing the format the full project length is 13:06:11 and every clip in the playlist (but nut the first one!) is suddenly 2 time shorter
00:00:16:21 => 00:00:08:21
00:00:08:17 => 00:00:04:21
00:01:04:09 => 00:00:32:09 and so on
I saved the new project file and compared with the old one and had the idea why the length of the every clip (but not the fist clip) has changes:
the length of the filst clip was saved as the time <property name="length">00:01:23.080</property>
But the lengths of the following clips were saved as frames count <property name="length">421</property>
… <property name="length">217</property>
… <property name="length">1609</property>
…
I changed the xml by setting the length value from out attribute for the fist 4 clips to check my hypothesis and my hypothesis was confirmed: the lengths of the first 4 clips in the playlist is now correct (but not in the timeline, because I has independent list)
But my timeline consists of more then 40 clips and it’s too hard to change everything manually correctly.
So my request to the developers:
could you please save the lengths of the clips in the time-for for all the clips in the playlist (as you do for the fist clip)?
BTW, I’ve a question about the future version, to be sure.
If I open the existing project the clip lengths will be converted correctly in the new version and I don’t I need to created the new project and edit it from the beginning, is it?
I had a similar problem and solved it with a regex. For some reason my project defaulted to 25 FPS and I wanted 59.94 instead, but converting it from the interface messed everything up. So instead I did it all in gVim, I changed the third line to this: <profile description="HD 1080p 59.94 fps" width="1920" height="1080" progressive="1" sample_aspect_num="1" sample_aspect_den="1" display_aspect_num="16" display_aspect_den="9" frame_rate_num="60000" frame_rate_den="1001" colorspace="709"/>
and then as most “length” properties are in frame counts, I changed them to timestamps using a regex that copies the timestamp from the previous line’s “out” property: :%s/out="\([0-9:\.]*\)">\n <property name="length">[0-9]*</out="\1">\r <property name="length">\1<
if you’re new to using vim, just copy everything in the line above after the “:”, then in vim press Esc, press “:” then paste it and press enter and it replaces everything.
This turns something like: <producer id="producer3" title="Anonymous Submission" in="00:00:00.000" out="00:00:07.680"> <property name="length">193</property>
into something like: <producer id="producer3" title="Anonymous Submission" in="00:00:00.000" out="00:00:07.680"> <property name="length">00:00:07.680</property>
which solved the problem and makes everything independent of the framerate.
Note that you shouldn’t attempt to convert from the interface first because this changes the “out” properties to be 2.4 times shorter, which we don’t want.
Hello MichelRouzic,
thanks for the script, but I decide to invest some time and make the better solution.
I’ve created the very small command-line tool, which fixes lengths in project file.
The advantage over your solution - it calculates the lengths based on the framerate in the project file (framerate / framecount). It give slight more length (+40 ms for 25fps) than your solution.
I’ve uploaded the source code and the binaries on the GitHub
The tool is written on C# and has two targets - net472 and netcoreapp2.1, so it can run on Windows and Linux (if the netcore2.1 or later is installed on the linux).
The output file name is currently hardcoded as “{projectfile} [fixed].mlt”.
This issue is rather perplexing. I compared my conversion with the original and after 51 clips I lost 1.32 seconds of footage, that works out to about 26 ms per clip. With your correction after changing the framerate to 60000/1001 I still have 1.22 seconds missing! There’s clearly some bad logic at work in the MLT framework, either some flooring instead of rounding, or the length of the last frame not being taken into account, or a +1 missing somewhere.
Let’s compare the time of the start of a scene after 51 clips:
Original 25 FPS file: 7:30.600
[fixed] 25 FPS file: 7:30.600
[fixed] 50 FPS file: 7:29.540 (1.06 sec lost)
[fixed] 59.94 FPS file: 7:29.384 (1.21 sec lost)
[fixed] 1000 FPS file: 7:28.0533 (2.5467 sec lost)
Diagnosis: things are messed up and I should make my own video editor like I was going to before I decided to learn Shotcut, as I would make it properly frame-agnostic, as it should be.
In all cases the duration of “out” is 40 ms shorter than the duration if I multiply the integer length with the frame duration, so it seems like the value of “out” is quite wrong (not to mention I don’t see what it does as it seems a bit redundant in the producer tag as the length seems to be given by length) as it would be the start of the last frame instead of its end and that you have the right idea by adding 40 ms. Btw Yury you should also take frame_rate_den into account as the real framerate is frame_rate_num/frame_rate_den, so when the framerate is 59.94 it’s actually 60000/1001.
Increasing “length” even by a lot does nothing anyway, except making Shotcut crash.
The root of the drift problem is that, by definition, “out” and “length” are not the same thing. If we have a clip that is 30 frames long and the project is 30fps (non-drop frame), then the length is 30 frames (“00:00:01.000”). However, the “out” point is 29 because we are “out” after the 29th frame (which is the 30th zero-based frame) and the timestamp “00:00:00.967” is the correct reference to the 29th frame (its start point). So, we get the “out” timestamp by doing 29 * 1000 / 30000 in this example. This cannot be solved with a regex copy.
The “out” and “length” values are not redundant because it is possible for a producer to set “in” and “out” points to trim a clip. To see this in action, start a new project, do File > Open Other > Color to put a transparent clip in the Source player, then set custom in and out points. Do not drag it onto the timeline nor add it to a playlist. Leave it in the Source player and save the project. Since there are no references from the playlist or timeline to provide in and out points, those trim points are placed directly on the transparent clip’s producer. Meanwhile, its length always remains four hours long.
If you tried to write your own video editor, you would discover exceedingly quickly that it is impossible to make a fully frame rate-agnostic project file. For the sake of round numbers, let’s take the 30fps NDF example above and scale it up to 60fps NDF:
We can’t double the frame number of the 30fps “out” point to get a 60fps “out” point because the 59th frame goes unaccounted and we drift again. Instead, we need to do math in frames and then convert to milliseconds:
Truncate("Number of frames in <length> property" * "Sec/Frame Original" * "Frames/Sec New" - 1) * "Sec/Frame New"
This basically says “get the timestamp of the last frame in the new frame rate”. Obviously, you would want to rearrange the formula in code to do all the divisions last for highest decimal accuracy. But for our straight-forward example:
Unless you enjoy doing this kind of math all day long, you’ll get more joy out of life using Shotcut than writing your own video editor from scratch.
As you noted earlier, the “num/den” notation for frames per second is preferred to a decimal FPS to give more precision when converting non-integer frame rates. Also note that the “true” answer to the formula above was 0.983333333, but because we are a positive number, we multiply by 1000 and take the ceiling then divide back by 1000 to get milliseconds. If we were negative, we would take the floor. Never use rounding. When operating on a positive number, the ceiling is required because truncating to 0.983000000 would put us in territory owned by the 58th frame and we would drift again.
You could make the argument that the math is more complicated than necessary because the “out” value is a last-frame reference rather than a clip-length reference (last frame + 1). Perhaps the MLT format would be more agnostic if the MLT engine displayed every frame up to but not equal to the “out” value. And that would be true in that limited sense. But it also makes time calculation and frame lookups more complex in the engine when exporting and generating a live preview, so the conversion price has to be paid somewhere. Likewise, a project can never be fully agnostic because time values based on 30fps source footage are locked to precision of 1/30th of a second. As in, there is not an intuitive or sensible way for a user to select a value of time with more precision than that. So if the project suddenly changes to 60fps and more timescale resolution becomes available, and there are now two frames per 1/30th slice instead of one, what agnostic way would accurately choose the first or the second frame for each 1/30th slice? That would be an artistic decision on the part of the user, not something we can ask a machine to solve for us. Frames are what finally make an appearance on the screen, so timestamps will always have a hard-linked relationship to frame rate in even the most agnostic formats.
You are astoundingly wrong, I suppose either out of confusion or out of a lack of imagination. For each frame you generate you have a timestamp, to that timestamp you subtract the start position of the relevant input video, which gives you the timestamp to look for in that video, and you take whichever frame of that video whose time range (you should think of frame as having a time range) contains the requested timestamp. Like say you’re making frame #313 of your output video with a timestamp of 00:00:05.222 and your video #2 starts at 00:00:03.150, you just get whatever frame that immediately precedes the frame that starts after 00:00:02.072 in video #2, it might be the frame that has a range from 00:00:02.042 to 00:00:02.083 (excluded). Disclaimer and flex: I’ve already made a simple video player/editor (for cutting single files and play back at extremely low or high speeds and reverse) that uses the principle of a single request timestamp to do everything, it works quite well, no point in worrying about framerates, mostly when dealing with videos with very inconsistent frame durations (maybe your problem is thinking of videos as having fixed frame rates, some do, many don’t). I also used such an approach for making a tool that reverses a video regardless of the input framerate at a fixed output rate. You can do anything like this, apply whatever mathematical function to the passage of time, like smoothly increasing the playback rate exponentially (my aforementioned editor does that, it’s pretty smooth until it exceeds the decoding rate and I switch to seeking by timestamp for every frame, which is fine as long as you’re not dealing with 1080p or above).
Frame #29 of your 30 FPS example would range from 00:00:00.967 to 00:00:01.000, so frame #59 of the 60 FPS output would naturally range from 00:00:00.983 to 00:00:01.00 and therefore match frame #29 of the input video, so there’s truly no problem here. The only true potential problem with that approach is dealing with rounding errors, but that could be fixed easily. I don’t see why you talk about milliseconds btw, just use doubles for all timestamps. Note that at least when using libavcodec like I do you don’t access frames by index and you don’t use whatever frame rate is claimed (again you shouldn’t assume a fixed frame rate), you either decode frames sequentially or you request a timestamp which gives you the previous keyframe and you decode sequentially from there until you reach the frame that matches to your timestamp.
You’re overthinking the (non-)problem, because it’s so simple, it’s a sort of nearest neighbour sampling (except it’s based on explicit range which makes it even simpler). Whatever input frame fits the request timestamp is the right one. If the user doesn’t like it he can always change the start of his clip by a little.
Btw Yury you should also take frame_rate_den into account as the real framerate is frame_rate_num/frame_rate_den, so when the framerate is 59.94 it’s actually 60000/1001.
Thanks for letting me know!
I’ve added support for “frame_rate_den” property and updated the tool.
Shotcut already does this. This is standard procedure pretty much everywhere. But this is only half the battle, and I’m much more concerned about the other half because it requires human time to fix, and time is money.
Suppose a one-second source video is 60fps, and frame 59 is a hard cut to a new scene because it was loosely clipped from a video game recording. Now suppose this 60fps video is being edited and played in a 30fps project. Only frame 58 is getting displayed, so everything looks fine because we don’t see that rogue scene cut on 59. But after converting the project to a 60fps timeline, frame 59 will become visible and cause a noticeable glitch due to the extra scene cut it introduces before the next clip on the timeline. This would require manual discovery and repair.
The point is that problems are hidden any time frames are dropped during editing (like 60fps video on a 30fps timeline where every other frame is dropped). And then problems appear when dropped frames are suddenly allowed to be visible after a frame rate change. What’s in those frames that just appeared? Manual review is the only way to find and fix these problems.
There are other ways frames can be hidden at one frame rate and appear at another frame rate. Mixing 24fps footage on a 59.94fps timeline and then changing the timeline to 29.97fps for broadcast can cause the 24fps clip to come in early by a frame. The frame boundaries are not aligned between tracks when mixing drop frame and non-drop sources. If somebody had a 24fps stock footage light leak over a 59.94fps clip of a dirt bike in mid-air, it would ruin the effect to see the light leak appear a frame early and clearly announce that it was artificial. This risk of “off by one” is compounded if speed ramps are applied to individual clips, because the drop-frame videos may round up while the non-drop videos may round down within a given output frame (and by round, I mean ceiling-ed or already integer).
I think this is where our points of view diverged. Yes, a project file can be written with timestamps that are all based on elapsed time, and the playback engine can be based on a request timestamp, and the workflow can be agnostic of the frame rate. But after doing a frame rate conversion in this manner, does the user get what they expected? Not always, as shown above.
This is all semantics based on how much we demand from our algorithms. To me, the phrase “frame rate agnostic” makes an implicit promise of hassle-free frame rate conversions. But due to issues beyond mathematics (like dropped frames reappearing with stuff we don’t want), this promise cannot be kept. That’s why I said a frame rate-agnostic project file can’t be made, because manual review and intervention cannot be completely eliminated after a rate change. (I could have stated this more clearly.) My opinion – which is just an opinion – is that if an agnostic file doesn’t reduce my workload (of verifying the conversion), then it hasn’t really helped me, and my project still has messed-up scene cuts due to frame rate issues despite agnostic claims. I do see your point, though, that timestamps can make certain time manipulations a lot easier. However, whether it be timestamps or frame count at a given frame rate, either unit is a useful and reliable measure of time with equal resolution for conversion provided the math is properly done everywhere it’s needed. It’s a moot point which one is used. Both units measure time, and time is all that matters. “Agnostic” gains nothing in terms of raw functionality if everything is properly implemented.
To be fair and put things in perspective – assuming super high frame rate video isn’t involved – the margin of error here is within one or two frames and probably isn’t enough to bother most people. But it’s enough to make a commercial producer nervous.
For both our sakes, the least confusing notation at millisecond resolution would probably be 00:00:00.984 <= frame space < 00:00:01.000
This is only true in this simple example with only one video stream. The examples above involving multiple tracks show where problems beyond math can creep in.
The topic of this thread is changing the frame rate of a Shotcut project file to a higher rate. The solution to this specific problem requires math in milliseconds because that is the timestamp format Shotcut uses in the project file. I wasn’t trying to have a theoretical discussion at all. I was solving a specific problem.
If we’re going to talk about theoretically perfect video editors, doubles are not a good option either because they have gaps in their representations. Calculating “31.2 - 31” using doubles gives an answer of 0.1999999 instead of 0.2, which is enough to break a comparison operator and drift by a frame. The real solution is to use presentation timestamps stored in 64-bit integers. The default timescale of 90,000 is sufficient for most purposes. This is ultimately how a lot of media files are encoded anyway, and PTS is the backbone that makes variable frame rate possible, so it would make sense to use it as the backbone of a video editor too.
I’m genuinely curious about something. This is the second time this week I’ve tried to help somebody out, and gotten a belittling attitude with zero thanks in response. Is there something about my writing style that is causing this reaction with people? I want to change it if so, because I actually am trying to help. But this kind of behavior does not encourage me to get involved.
And it’s easy to fix, just add about 40 ULP to your timestamp if you’re worried about being a couple of ULP short of the right frame and you’ll be fine.
Yes, you told me with exceeding confidence that something I consider trivial is in fact impossible, this only invites strong rebukes because I couldn’t believe someone could be this confidently wrong. But I wasn’t just trying to be mean when I said that about a lack of imagination, I’m sorry if I sounded abrasive, I really think that if you can’t see how such an editor would work it’s because you have trouble imagining it, you see problems to which I can easily imagine solutions. Like this one:
Good point but it wouldn’t be a problem for my editor as I envision it. If you tried to cut to the very end of a scene then you would scrub to find that last source frame, this would be independent of the output frame rate (the way I see things you’d see everything at the flexible screen rate until perhaps you choose an option to see it at the fixed output rate, it’s easy to have both, in one case you add the screen frame duration to the request timestamp, in the other you do the same but floor to a multiple of the output frame duration, but I assume most editing would be done with the former). I also believe in zooming interfaces (kind of a long topic) so that could be used to see how input frames line up with everything, in case anyone is worried about that. I always find it amazing how video editing programs are so stingy with visual information when it comes to zooming on video tracks to the level of individual frames, it wouldn’t hurt to put a notch where each frame starts, it would be even better if at that level each individual frame could be shown. Imagine an editor where you can play your whole project back at any speed (like my one-file editor I mentioned, the playback speed goes from 0.04x to 1200x, plus reverse) with either playing according to the raw screen rate (so 60 Hz with a playback speed of 0.1x would be like seeing a 600 FPS output) so you could see the idealised unlimited framerate output, or with flooring to exact output frames so you could see every exact output frame, problem solved.
Well sadly this isn’t the case with Shotcut since changing the frame rate ruins everything. At least with what I’m planning there wouldn’t be any way that any output frame rate change would shift anything, as in no 1.2 second shift of all video (my voiceover track is in one piece so that 1.2 second shift is quite noticeable). And besides I don’t quite agree that you’d gain nothing. With your idea everything is limited in granularity to the output frame duration, but you might gain from being able to cut things at fractional frame times, mostly when you consider how the audio is affected, but also the problem you mentioned about a hidden end frame which wouldn’t be such a problem if you can see all frames (even if your inputs are 240 FPS and your output 24 FPS) and set an end at absolutely any arbitrary time stamp.
I guess it’s appealing trying to make a video editor that’s just like cutting actual film, with everything being about having one frame at a time, but that only works because everything would be at the same frame rate, and that still leaves the problem of time granularity which might be at times a bit too coarse for sound. It’s best to embrace the chaos and use the one approach that always works.
Thank you for explaining; I see what’s happening now. You have a deep-rooted vision for creating a video editor with a killer feature unlike any other video editor: A truly agnostic timeline with variable speed playback. When I made my sweeping statement about such a thing not being possible, I unknowingly kicked your baby and you wanted to set the record straight.
This idea has been explored before, so I assume you’re familiar with the known hurdles. I would love for this idea to be practical and possible, for sure, and I do wish you great success as you develop it. I spoke not to dampen your spirit, but out of a programmer’s awareness regarding how difficult this idea can be to implement, which is why nobody is doing it commercially.
One paragraph was of course not enough space for you to fully describe the mechanics of your system, so I want to make sure I’m understanding your unique implementation. Using the previous example of a 60fps video on a 30fps timeline with a rogue scene cut on Frame 59…
Is it accurate to say that I always have to scrub and trim the source video in its native frame rate to find the last good frame? If I don’t and I trim while previewing at the 30fps output rate, it sounds like I could get surprised by Frame 59 after a rate change to 60fps just like editors today.
If I change the output frame rate from 30fps to 60fps, the source video only provides frames up through 58. I trimmed out 59. What fills its spot now that I’m exporting 60fps? Is 58 doubled? Was the next clip on the timeline positioned to take frame 59’s place? How would I have targeted a half-frame start point while editing in 30fps mode? If that’s possible (meaning I’m not constantly flipping between free rate and fixed rate for positioning operations), suppose I started with 120fps video on a 30fps timeline then upscaled the timeline to 120fps… the next clip could have been positioned even closer because frame 58 (now 116 when at 120fps) is half the duration of a 60fps frame and a quarter the duration of a 30fps frame… what stops the positioning closeness from approaching zero as higher FPS is used for rate conversions? What if the next clip on the timeline is 30fps, not 60fps, and it’s positioned in frame 59’s spot? It is now straddling a 30fps frame boundary. Display-wise, this is not a problem, but it seems like it would complicate the workflow of a genlocked multi-cam setup if the other camera clips were not able to align to the same fractional frame due to the length of the clips prior to them. Yes, the active camera could have its start point moved fractionally earlier (or more) while keeping sync with the others, but having a ragged leading edge for a multi-cam selection set seems like a liability if I decide to re-order the clips on the timeline and the multi-cam set doesn’t sit flush against its new neighbors without re-trimming. When I say multi-cam, it implies that the ragged edge issue could happen with any multi-clip select-and-move operation as well, not just genlocked cameras. Suppose I select and move three stacked clips down the timeline, and the top clip starts earlier than the other two. If I place this trio next to another trio of clips without re-trimming, then the upper track would sit flush but the lower two tracks would have a gap before they started. I may not see this gap unless hyper-zoomed because it could be a fraction of a frame. Then suppose I hide the top clip because I want to see the second clip instead. If I rate-convert the project to a higher frame rate, what becomes of the gap that’s in front of that second-down clip? The prior clip isn’t trimmed to extend into the gap, and the timestamp of the second-down clip clearly says to come in later, so wouldn’t that create empty frames in the gap and cause a visual glitch? Granted, all of these issues could be mitigated with specialized tool support, of course, but is this extra work and fractional frame awareness on the user’s part worth the benefits?
Speaking of which, I’m unclear on the benefits of a free rate editor. It seems so far that if I take advantage of fractional (native rate) frame trimming but not fractional positioning, I risk creating gaps or duplicates where clips meet (neither one acceptable), or of not showing frames all the way out to my chosen last frame (which is acceptable). If I take advantage of fractional positioning, I appear to risk complicating a multi-cam workflow and all multi-clip select-and-move operations due to ragged fractional edges (unequal start/stop times). If I don’t take advantage of the fractional features to avoid those pitfalls, wouldn’t this editor become exactly like the editors we already have today? Since the primary selling point of a rate-agnostic workflow is the ability to change frame rate without rework, and no professional workflow is going to change frame rates on the project itself anyway (there is no need even if the option exists), wouldn’t this whole feature set add more complexity than benefits to a film cutter’s life? I am thinking in a film mindset, but I’m open to the possibility that another segment of users would find this feature valuable. I’m just trying to figure out who those users are and what their workflow looks like.
I’m not understanding this statement: “Imagine an editor where you can play your whole project back at any speed”. How is this feature useful for the task of editing? I can already get any speed I want with today’s editors by scrubbing the timeline. Then the next part… “so you could see the idealised unlimited framerate output”. If my source videos are 30fps and I change the preview frame rate up and down for fun… am I still just looking at a duplicated or dropped version of the original 30fps? If I take one second of 30fps video and stretch it to three seconds using duplication, it looks bad to me because moving objects are making big jumps with no in-between frames to smooth the movement. Without optical flow or some other interpolation algorithm being involved, I’m not grasping how viewing duplicated frames will improve my life. This can already be done with Shotcut.
I’m most concerned about the genlocked multi-cam workflow. Feature films, newsroom broadcasts, and sitcoms all use multi-cam. Even my wife’s cooking videos are multi-cam (front, side, overhead). Any tool that slows down or complicates that workflow will probably struggle for widespread adoption.
I have other questions, but they might get answered automatically if I know how you’re handling the above scenarios. Again, I’m hoping you have answers so that the idea can actually work. It’s cool in theory. I’m just curious how you’re doing it in practicality, and wondering if using the editor would be trivial to a user.
Agreed, audio trimming would be handy. Other editors besides Shotcut already have the option to trim audio at a higher granularity than frame-level for J/L transitions and such. See Blackmagic Forum • View topic - Sample Rate Trimming Resolve also has Fairlight, a full-blown audio editor built into it. As for Shotcut, I frequently export audio stems, tweak them in a DAW, and bring them back into the timeline anyway, so I’m not bothered by the frame granularity. Not everybody wants to do that much work of course, but there’s also a lot to be said for using the right tool for the job if audio manipulation is going to get complex.
To summarize, I see this project is important to you, and I’m sorry that my comment sounded like I didn’t support your goals. Had I known that the concept of an agnostic editor would be so personal to you, I wouldn’t have made that weak attempt at humor in my first post. Sometimes my jokes don’t land. Now that I know you’re working on this project, I’m curious to see how far you can take it and whether I can help. That’s all I ever wanted to do.
As for what I would like to see different in future exchanges…
You believe I am wrong because of a theoretical and unproven idea that exists only in your head. You might actually be right, but this is not admissible in court until it’s battle-tested as a product. For now, you would have been better off saying “I think I can get around that frame rate limitation and here’s how”, and then I would have naturally been curious and looking for ways to help you instead of fighting the temptation to prove you wrong after you insulted my imagination. Flies, honey, vinegar…
Are you as willing to receive strong rebukes as you are to give them?
Your post was confidently wrong on every point and was borderline slander of MLT. It was difficult to watch you create unfounded bad press for a program that has brought me so much joy. Did I “strongly rebuke” you for your lack of understanding? No, I solved your frame rate conversion problem for you. You’re welcome, by the way.
MLT works perfectly fine when used correctly. I need to make that abundantly clear so other readers in the forum don’t get discouraged about using MLT just because they heard some intelligent-sounding guy make some confident-sounding criticisms. Generally speaking, conversations are most productive when posts take the form of “Hey, something isn’t working as expected… is there a reason for this?” I’m being unusually outspoken with you because 1) you took personal jabs and “flexed” at me which does not go unnoticed, but more importantly, 2) you’re clearly intelligent and can have very persuasive power with that intellect. I’m encouraging you to use that power more responsibly so you can do more good than harm. Double-check some facts before giving Shotcut a bad name. People listen when you speak. You have the skills to be a great asset to the forum. So much so that I look forward to pleasant and productive encounters in the future, and I do truly hope that your agnostic editor idea blossoms into something great, even if that means proving me wrong. I will take that fall to move the industry forward.
Well what else would you do to find the end of a scene? You could press the button to cut the scene as it plays back in real time, but that’s if you like to live dangerously, regardless of the output framerate. With my one-file editor that’s what I do when I want to cut to the end of a scene, I scrub with my mouse cursor and press the key to set the end timestamp. Otherwise if I cut in the middle of a scene I just cut in real time by pressing the button to set the end whenever, because then precision doesn’t matter.
Why would you create gaps if you don’t want any? Just don’t put gaps between clips. And btw not everything has to be shown with proportional time, we don’t need to be stuck with only the linear proportional timeline like all editors do, you should be able to view things as a lists of elements, gaps included, like Shotcut’s .mlt files show (it’s sadly often true that using a text editor can be more informative about a project (not Shotcut specifically) than the editing program’s whole GUI), so you can see even the smallest gaps easily. Again, none of these things are real problems that invalidate the whole concept, it’s easy to imagine ways to avoid such issues.
If you go back to my original sentence that caught your eye and started it all there was no mention of adoption, I want to make a tool for myself, one that doesn’t screw me over if I realise that I picked the wrong framerate, the goal being me making videos, not anyone else. I didn’t even think about all the objections you raised, because they’re things that I’m not concerned with, but since you ask I just so happen to have answers.
It’s the second time you’re mentioning this, I don’t know why you took that personally, I was merely establishing that I’m a developer who already has experience doing what I’m talking about, that seemed relevant, I have no idea what that meant to you nor why you’re so sensitive and I don’t care to find out.
Maybe I too am sensitive, because reading such sentences upsets me. How many times do I have to tell you that I’ve already made a video player/editor/processor that uses that principle? It’s an abstract concept for you, for me it’s one that I’ve used (you’re not even a developer, are you? Who are you to tell me what’s possible or not if you don’t even know how libavcodec works?). And I cared about finding out why you insisted that the concept is outright “impossible”, but I don’t need to read a book’s worth of objections and questions about a very simple, natural and obvious concept (I’ll be honest, I couldn’t bring myself to read the entirety of your last post, I had to skim), at no point did I hint that I cared about your objections, your condescension nor cared to debate about my views, I merely tried to answer you hoping you’d understand my point of view better since you inquired. But I’m not interested in answering an endless stream of questions so we’ll have to move on.
I joined this thread to investigate the mysteries of changing framerates in Shotcut, you derailed the whole thread with huge posts about something off-topic based on one easily ignored sentence from one of my posts, apparently out of brand loyalty, then got upset because you see attacks and insults where there are none. Being told that you’re wrong about calling something impossible or that you lack the imagination to see how a concept isn’t impossible isn’t an insult, so next time that happens to you perhaps consider not being oversensitive and not treating it as an insult. I’m not interested in helping you troubleshoot your recurring Internet communication issues any further than this and I’ve heard enough of your unprompted objections and suggestions, if I don’t tell you this I have a feeling that this degenerating exchange could go on for a long time, so we’d do better to end it here. To spare you the temptation to write any kind of lengthy reply and thus spare this forum further off-topic discussion I announce that I’m unwatching this thread.
I spent hours on this issue, when making my subtitle .srt to .mlt convertor, and users complain the “subtitle drifts few seconds” after dozens of dialogs (they are clips in Shorcut). I did the hard math, it was fun… I am kidding.
Here is another part of the issue: the Project (the xml in the back-end records whats going on) respects the time (like 00:00:04.956 etc.), but the Editor in the front-end respects the frame numbers.
For example:
I have a project with 4 clips, link to each other, all the lengths are 1 second like:
00:00:01.000 ->00:00:01.000 ->00:00:01.000 ->00:00:01.000
Lets say because of the FPS, the first clip occupies 1 more frame; If we “respect the time”, the second clip should be like 1 less frame, so the total length changing of the whole video can be minimized. But NO.
Shotcut will occupy 1 more frame for each clips, making it into something like
00:00:01.033 ->00:00:01.033 ->00:00:01.033 ->00:00:01.033
Now you see the total length (and including other clips after these clips) changed a lot. Even worse, if user now change the “Framerate” into some number the editor can not perfectly divide the 00:00:01.033, each clips may occupy 1 more frame, it then becomes:
00:00:01.054 ->00:00:01.054 ->00:00:01.054 ->00:00:01.054.
For a project with dozens of clips, it will lead to few seconds major time drifts.
It is pretty bad for people who do music videos (where the picture need to sync with songs)
This sounds like the “out” value was set to 00:00:01.000, which doesn’t match what the SRT timings are requesting. In the MLT file, “out” is the timestamp of the start of the clip’s last frame. This requires subtracting one frame from the subtitle length (which will be a frame rate-dependent amount) and using the start time of that frame as the “out” value. “Out” means “the indicated frame will get displayed, and then this clip is finished”, meaning “out” is a pointer to a frame as opposed to a measure of clip length.
If the frame rate is 25fps, the chain of 1-second clips should look like this:
In: 0.000 Out: 0.960
In: 1.000 Out: 1.960
In: 2.000 Out: 2.960
In: 3.000 Out: 3.960
