-
Notifications
You must be signed in to change notification settings - Fork 554
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Mismatching Source Profile Shenanigans #5684
Comments
Hello @Pixelz22 Please provide some additional information so I can try and replicate this in my environment as well.
Some of the information you have provided is more suited for the lead developer since I am not a dev person and just a regular user and a volunteer trying to help others. |
The files are both mp4s and 1920x1080. However, it turns out I had the original framerates wrong. The first clip, the first one that I imported to the project and was recorded through OBS, is running at 60 fps (I guess I had assumed it was 30 fps since it was working fine). The second clip, which I downloaded from the internet, is actually running at 59.94 fps. I only discovered this after looking at the file data with the inspector. This is what I getting for trusting internet descriptions. My bad. This explains why changing the second clip to 30 fps didn't fix the problem: it still wasn't matching the original clip. My default profile on OpenShot is The second clip was a static tv background I was gonna use for a transition between two clips. I downloaded it from the description of this video. Upon further testing from a blank project, it would appear that the second clip does eventually play if you leave it running for long enough, but the audio is desync'd and the beginning still loops the last couple frames of the previous clip. |
Thank you @Pixelz22 for this information. Please provide me some details about how you have your project setup so I can try and replicate your issue. Please be as specific as possible with your edits in OpenShot. One thing you can also try is to run both of your .mp4 files through a converter like VLC, HandBrake, or ShutterEncoder and convert them both to .mp4 files again, but with different names. |
I tried recreating the issue myself from a blank project, and it still occurred. Here's what I did:
|
Here is what I tested so you can further confirm if I am testing like you are:
A screen shot of what you are seeing that is wrong will help as well. |
Sorry, I had meant to mention that I had already tried running it through VLC or other convertors. Funnily enough, VLC didn't change the framerate at all. I found an online one that did, however. Still no luck, error was still present. So the export looks completely fine? Very strange. All this leads me to think it might not be the framerates that's screwing this up. Perhaps there's some other factor here that I'm missing. I can try to record a clip of the error when I get home tonight, though it will be late. |
No worries. I can look at whatever you provide tomorrow when time permits. Hopefully we can get to the bottom of it. |
static.frame.tearing.mp4Here's a recording of the error, sorry I wasn't able to get it in this morning. Things ended up being a lot busier than I expected. This is an export of a video after following the exact steps listed above. As you can see, when switching between the two clips at around 0:09, the video sorta fights between which clip it's showing for a while, despite using the audio from the TV Static clip. I'll admit, this is slightly different behavior than the looping I was seeing on the original project, but clearly something is still going wrong. |
Describe the bug:
I have two source files of different framerates, 30 and 60. After putting them both in the timeline, the preview handles it fine. However, when looking at the exported video, the 30 fps clip loops where the 60 fps clip should be playing.
Steps to reproduce the behavior:
Expected behavior:
The exported video should match the preview.
System Details:
I've done a little bit of research into why this might be happening, and I think it might be tied to previous issue #1438. I have a good amount of experience in C and a little less in C++, so I dug around the lipopenshot repo and found the frame# dependency that was mentioned. TLDR for that thread: Keyframe points are positioned via their frame#, so changing project framerates after placing the keyframes was ruining the timings.
I wonder if perhaps a similar problem is going on here. Maybe it's not directly tied to the keyframes, but if something else were linked to frame#, that could easily screw things up when mix and matching different framerates together. Clip starts seem to be seconds-based, so I'm not sure where that problem would lie.
However, the problem might not be the framerate at all. The clips also have different quality, one at 720p, the other at 1080p. When I tried reducing the framerate of the second clip with VLC, the problem didn't go away, so it's possible that the quality is the cause. Haven't gotten around to trying a manual fix for that part yet, just thought I'd mention it. Seems less likely that image quality would be causing this big of a hiccup, but who could say?
Honestly, the biggest thing confusing me here is that it works in the preview. If it works there, is there really a reason it can't be working in the export as well?
As a sidenote/potential fix, I'm actually kinda curious if changing the keyframes to be time-based rather than frame-based would be that hard. I know one of the guys in that thread I mentioned earlier was saying it would bring up more problems, but surely converting from time to frames would be as simple as converting to a fractional frame# and rounding? Consecutive clips would still work correctly because the end of one and the stat of the other would round to the same frame. And if you really wanted manual control over the frames, you could create a little button in the UI that calculated the exact number of milliseconds to move to the next frame and added it to the keyframe time. It's just an interesting thought, perhaps one worth exploring. Heck, I'd consider doing it myself, wouldn't mind working on this one fix (though I'm not nearly familiar enough with the codebase to be aware of the extending consequences any of my changes may have).
The text was updated successfully, but these errors were encountered: