Closed Corvo0101 closed 3 years ago
rexdk
commented
4 years ago I thought this had been reported as a bug before, but I can't find it. It's been raised on the forum, and I confirm that I have also experienced it, on 2.5.1 Win10. Even if it worked it would need improving - it's very clunky in use, asking for an image sequence even if there are no other files available in the sequence.
ferdnyc
commented
4 years ago @rexdk The image sequence importer was completely reworked a couple of months ago, it should be smarter both about what is and what isn't an image sequence. (The Project Files list in general also updates multiple times faster than it used to.)
Can you try the latest Daily Build version from https://OpenShot.org/download/ and let us know if you still have the same problem? My hope is that all of these issues have been fixed, just not released yet.
ferdnyc
commented
4 years ago The problems @Corvo0101 reported, with missing frames from an image sequence that was recognized and imported correctly... that may be something different. It sounds more like an FFmpeg encoding error. (Sorry, @Corvo0101, I hadn't seen your report until now.)
After we generate the expression that selects the files for the sequence, we pass it to FFmpeg, which is responsible for importing the actual images and assembling them into a video. If it was duplicating frames, then it clearly retrieved the correct number of files. I'd need more data to investigate why it didn't assemble them correctly. Logs would be helpful, as well as a list of filenames and the expression that OpenShot built to select the frames. (It's used as the "filename" of the image sequence when it's imported.)
rexdk
commented
4 years ago @ferdnyc Thank you, super. I'll try it, but not for some days, as I am mid-project and can't afford any glitches
rexdk
commented
4 years ago @ferdnyc I've just tried the daily build of 28July20. I'm afraid the issues are still there:
Win10.
I'll gladly attach log files and the image sequence if that's useful - there seem to be several log files - which would help?
ferdnyc
commented
4 years ago @rexdk
I can't say I'm completely surprised you're still encountering issues, as just last night I discovered while working on #3630 that there were still several bugs in the image sequence import code. So, a big chunk of it got rewritten AGAIN.
The Windows responsiveness thing I doubt is fixed, unfortunately, as this is the first I'm hearing about it and nothing of the sort happens on Linux. I don't know why it would be happening as we're not doing anything special during the import process. I can only assume that's the problem, and there's something special we SHOULD be doing to keep Windows happy.
Your item 3, in particular, I think I'm surprised was still an issue, because I thought I'd addressed THAT problem last time around. But, regardless, as part of the rewrite for recursive imports I discovered that the code was doing some really strange things when it encountered more than one image sequence in a directory, so I ended up hard-limiting each import run to one sequence per disk path.
Whether you answer no or yes to the "import as image sequence?" question -- in fact, before it even ASKS you that question -- OpenShot puts the location of the discovered sequence on a list of banned paths and will refuse to even scan for any more image sequences in those same locations.
(The list is cleared at the end of the run, so it's still technically possible to import two sequences from the same directory. It just has to be done in two separate imports. Mind you, keeping more than one image sequence in the same folder is a terrible idea anyway.)
There's kind of no way that CAN'T fix the issue with multiple prompts, so at least that should be dealt with for good.
The missing frames thing is the most worrying, since as I said about @Corvo0101 's report of the same thing, all we're doing is providing the file pattern to FFmpeg. It's responsible for reading and animating the frames that match the pattern, and from your details yours should.
So, I don't expect any changes there, I'm afraid.
Logs, unfortunately I doubt would be very helpful. What MIGHT be instructive is, since OpenShot 2.5.0 we've been packaging the Windows version with a second launcher, openshot-qt-cli.exe, which is located in the same install folder as OpenShot itself. (Usually a path that starts with C:\Program Files\OpenShot Video Editor\.)
The -cli launcher is a little undocumented debugging tool, the way it works is, if you open a terminal window (Command Prompt, PowerShell, doesn't matter) and run that launcher from the terminal, OpenShot will run with the normal console output enabled, the way it does on Linux or macOS.
Normally under Windows the output is hidden. Most of it makes it into the logs, but not ALL of it. In particular, any output from FFmpeg itself will only show up there. So, if you launch OpenShot from a terminal and then reproduce the missing-frames issue with your image sequence, I'm hopeful there might be some indication in the console output why that's happening.
In the meantime, I'll try to research the Windows hangs during import a bit more. The #3630 changes aren't available in any builds yet; I could arrange for one to be generated if you were interested in testing, but it sounds like it'd only address the least of your three concerns, and the one I'm most confident about having fixed for good, so maybe there's no real urgency there. It's up to you, like I said if you're interested I can generate a Windows build with the unmerged code.
(Um, I think I can, anyway -- @jonoomph has had the build system in flux a bit recently for upgrades, so I don't want to make any promises. If not right now, a build can be available "soon", let's leave it at that.)
rexdk
commented
4 years ago @ferdnyc *My point 1 about Windows hanging is less severe than I thought - I can bring up other File Explorer windows - the only window that is frozen is the one I'm importing from. It's still wrong, but isn't as bad as I thought.
*Running from cmd, importing a01-a08 by drag and drop, loading onto timeline and playing generates the attached output.txt
I suspect you will find that useful, there appears to be a JSON error Further info - the 8 png files all have transparency
Thanks!
PS - no need for a special build thanks , but happy to help as I can
ferdnyc
commented
4 years ago @rexdk Thanks, I'll take a look at it!
I'm sort of at diminished capacity right now (since this weekend, actually) thanks to an ill-advised attempt at converting my primary desktop system over from BIOS to EFI booting, while upgrading to a new SSD and piles of additional RAM. (#PROTIP If you enjoy banging your head in frustration while your OS deflects all attempts to convince it to boot, have I got the upgrade experience of a lifetime for you! 😑 ) But, I'm sure I'll sort it out eventually. I mean, there's only so many wrong ways to fix a problem, right? If I try all of them, eventually I'll just accidentally try the RIGHT way. That's just science! (Note: I also do science wrong.)
Further info - the 8 png files all have transparency
Ooh, now THAT may definitely be a problem. Although apparently there are video codecs that support transparent video (some variation of webm, I gather), most don't, and I'm not sure ffmpeg supports outputting transparent video even to the ones that do support it. You may need to either import the frames directly as individual PNGs, or matte them all against a solid background, if you want to import them as video generated by ffmpeg.
But, I'll see what the logs have to say. Still, it's definitely worth experimentally removing the alpha layer channel from the files and importing the image sequence that way. If it works, then the transparency was almost certainly the problem.
rexdk
commented
4 years ago @ferdnyc Apologies, I should have thought that transparency might be an issue - didn't know at first that ffmpeg was generating a video, and then it didn't register with me.
But I've now tried 8 new images c01-c08.png, solid background, and where the alpha channel was removed in Gimp. The images are of numbers 1 to 8, and again only images/numbers 1, 2 and 3 show - the last frames all being 3.
So it actually isn't transparency. I did think mp4 could support alpha - but I may well be wrong, and I know it isn't common. For what it's worth, the previous first 3 images a01-a03.png showed as transparent in the sequence when played.
rexdk
commented
4 years ago @ferdnyc Further testing: With 12 solid images in the sequence, it shows 1 to 7 with 11 it shows 1-6 with 10 it shows 1-5 ... with 6 it shows just image 1 with 4 it shows nothing
========== On the import sequence mechanism, if I have c01-c06 and c08 in the folder, and I then import c08 (and say OK it's a sequence), I'm pretty sure that it is importing c01-c06, but not c08
To be honest, from a user's point of view I think Openshot is trying too hard to find a sequence - this is very rarely used, and most of the time the user will be annoyed (or worse, confused) at having to say no it's not a sequence. As an alternative, why not only ask if a whole sequence is dragged/dropped, or if a folder containing just a sequence is imported. Or maybe when the file being imported is one up from the previous file. Or maybe have a special import menu item.
For instance the 'quick tutorial' in the user guide is being revised at the moment, to help absolute beginners. The user has to import a couple of images - the last thing he wants is to have an image sequence explained at this stage, when he knows nothing. Actually perhaps the dialog ought to have a help button/pop-up?
ferdnyc
commented
4 years ago Ohh-kay, Back to full capacity, and I've done some testing of my own.
Surprisingly, at least in the ideal case transparent image sequences don't appear to be any sort of problem. I created a set of 79 frames with identical parameters according to the file command: PNG image data, 1280 x 720, 8-bit/color RGBA, non-interlaced, and imported them as a sequence in OpenShot. The transparent frames were correctly overlaid on top of another video track placed on the timeline. So, that's good to know.
I was overly optimistic about output from ffmpeg, it seems, since there was nothing in your logs that shed any light on this. Sorry about the wild goose chase there. (Even the error processing the project data was a red herring. It's expected when processing Windows file paths located on a different drive than the project file, since it's impossible to construct a relative path between the two in that scenario. The message should probably be downgraded from ERROR to something more appropriate.)
Identical-format restrictions still hold. When I removed the alpha channel from only the first frame of the sequence and then imported it, surprisingly enough ffmpeg didn't crash (its usual response to anything unexpected), but it did corrupt all of the following frames by interpreting their 32bpp data (4 × 8-bit channels per pixel) as 24bpp, which was the format of the first image.
@ferdnyc Further testing: With 12 solid images in the sequence, it shows 1 to 7 with 11 it shows 1-6 with 10 it shows 1-5 ... with 6 it shows just image 1 with 4 it shows nothing
Fascinating. Well, this just keeps getting odder. (Especially since I saw nothing like that, in my most recent tests with the transparent-images sequence.)
And this happens in both the preview and the export? Does it happen no matter where you are on the timeline. (Meaning if you were to import a ~1-minute video and place that on the timeline at 00:00:00:01, then import the image sequence and start it a third of the way in to the video at 00:00:20:01, would you still get the same N-5 frames?
I wonder if it could be some sort of synchronization issue, where some of the final frames generated are getting dropped because they're output in a different thread? That wouldn't explain why you see a previous frame repeated, though. Hmmm. Still, out of curiosity, do you happen to know how many cores your system's CPU has?
didn't know at first that ffmpeg was generating a video
Mm, well, it's not... exactly, which is the thing. It's generating a video stream that we read in, process, and pass back around to the encoder, but the stream is basically unencoded at that point, at least in the video sense. (It's encoded as individual frame images.) I wasn't sure transparent frames would be handled correctly, but happily that doesn't appear to be a concern.
On the import sequence mechanism, if I have c01-c06 and c08 in the folder, and I then import c08 (and say OK it's a sequence), I'm pretty sure that it is importing c01-c06, but not c08
It is, yeah, since the sequence discovery attempts to find a set of files that match the pattern it's going to be passing to ffmpeg. The pattern in that case would be c%02d which would match... well, it would match all 7 files, but as soon as it hit the missing c07 the sequence would terminate.
To be honest, from a user's point of view I think Openshot is trying too hard to find a sequence - this is very rarely used, and most of the time the user will be annoyed (or worse, confused) at having to say no it's not a sequence.
I tend to agree, TBH. I hate the feature completely, and would be more than happy to see it gone. It has never worked perfectly, and will likely never work perfectly because it's doing inherently heuristic things. But, the functionality is necessary for the animated titles feature, since Blender exports are imported as image sequence frames. So, we're stuck with it either way.
The UI does suck, though. I've tried to declaw it to the extent I can without breaking things for existing users, since some of them unfortunately rely on it. I'm sure we could be doing more, though.
rexdk
commented
4 years ago The processor is i5-9400 @2.9Ghz. According to the Intel site it has 6 cores and 6 threads.
In every test I've tried, the exported video is the same as the preview.
image sequence frame rate =30/sec, and frame rate = 1/sec
image sequence overlaid on a video, starting at 0, overlaid in the middle on the track above
image sequence overlaid on a video, starting at 0, overlaid in the middle on the same track
image sequence overlaid on a video, starting a bit later, overlaid on the track above 1-4 all show just the first 3 images
I've also made a fake image sequence by importing the individual images, setting them to 1 sec duration, placing them in order on the same track. It works fine; all 8 images show.
rexdk
commented
4 years ago @ferdnyc Re my earlier point about the frozen window - this may be part of something wider - I've found that when I click the icon to float the preview panel in a new separate window, that new window stays permanently on top of the main window, and there is no access to that window on the taskbar. I suspect this is new behaviour in the daily build, but I'm not sure - in any event, it may be that there is some underlying issue, nothing to do with image sequences. Just trying to save you work ;)...
I'll study it some more, and then I guess I have to raise a separate bug report.
ferdnyc
commented
4 years ago @rexdk
I've found that when I click the icon to float the preview panel in a new separate window, that new window stays permanently on top of the main window, and there is no access to that window on the taskbar. I suspect this is new behaviour in the daily build, but I'm not sure
No, that's all normal behavior I'm afraid. (I guess "I'm afraid", since it sounds like it's not to your liking.)
The detachable panels in the UI (which is all of them, at this point) are a particular type of Qt widget, a QDockWidget, that's intended to be part of a modular, reconfigurable interface, so there are a lot of special behaviors involved. It's sort of unfortunate that Windows forces the standard titlebar styling on the dock widgets when they're floated, because it gives the impression they're something they're not. In Linux, a floated Preview dock would look like this:
Exactly the same as it looks when it's not floated, IOW, except that it's detached from the interface. The dock widgets aren't true windows, even when they're floated. The Linux-type styling (which I think was also possible on Windows in earlier releases) makes that clearer. It also shows the 'float/restore' button next to the close button, which in floating mode can be used to dock the panel back at its previous location in the window. The Win10 styling doesn't provide an obvious way to do that, though it is actually possible — double-clicking the titlebar of a dock has the same effect as clicking float/restore in both floating and docked modes, and that works even on the Windows-standard titlebar in Win10.
Docks are indeed excluded from the taskbar. (Well, technically not "excluded", they don't show up the same way a tooltip doesn't show up, it's a child widget of the application window.) They're forced to always remain in front of the main window, which is actually one of the biggest features to recommend them. (We've had all sorts of trouble with people "losing" regular popups behind the main window, which is also the reason that the actual popup windows — Export, the title editors, etc. — are configured as modal dialogs, so they both disable and cover the main window while they're open.) Floated dock widgets will also minimize and restore in sync with the main window, so they can't get lost offscreen. Effectively, all of the dock panels are pieces of the main window, just pieces that have the option of being "disassembled" a bit.
ferdnyc
commented
4 years ago Another dock peculiarity I just confirmed, at least in Linux, that helps drive the point home that they're not windows — if you try to activate window snapping for any of the floating QDockWidgets by dragging it to one of the screen edges, you'll find that it's completely ignored and snapping never triggers. (Unless Win10 happens to be different from Linux in that regard, anyway.)
You may also notice that it's impossible to drag any part of a floating dock off the edge of the screen by even a single pixel, unlike a normal window.
(Actually, now that I think about it Windows might prohibit that for all windows anyway. Linux doesn't, you're perfectly free to do this:
...Just not with a QDockWidget.)
ferdnyc
commented
4 years ago
- image sequence frame rate =30/sec, and frame rate = 1/sec
Ooh, what's this part about?
Crap... I don't think I'd picked up on the fact that you were trying to use the image sequence as a slideshow. Ugh, that changes everything. Dammit, how did I miss that?
Image sequences are really intended to be imported as animation frames. (i.e. with a frame rate minimum of ~12fps, the cutoff point where human vision begins to interpret a series of successive still images as a moving image.) There's... no good reason why it shouldn't work at a frame rate of 1fps, but I admit I'm not super surprised that it doesn't work correctly because you're in untested territory there.
Heh. Yeah, OK, I think I see what's going on now. The reason the animation is stopping early is (unintuitively) that it's also playing too early — it looks like there's a bug in the FrameMapper that's responsible for converting between frame rates.
You probably couldn't pick up on it with only 8, 10, 12 frames, but it looks like the effect becomes more severe the longer the sequence is, so it starts to become obvious once you go just a few frames longer. I just tested with a 25-frame sequence I made long ago for exactly these sort of tests, and if I load it into a 30 fps timeline and change the frame rate to 1:1 (aka 1 fps), then when I place it on the timeline as a clip:
00:00:00:15, only halfway through its intended runtime.Every frame after that is slightly shorter than it should be. It looks like they're losing 1 or 2 frames more per second.
00:00:01:1500:00:02:1400:00:03:12and so on, meaning by the time we get near the end...
00:00:18:2400:00:19:23consistent with what you've been seeing, Frame 22 then holds on screen all the way until the end of the clip at 00:00:24:30.
So, there's definitely a major bug related to changing the frame rate of image sequence imports. And since the bug is exacerbated by the severity of the rate change, lowering the frame rate down to 1fps makes them entirely unusable.
I've got some theories about why this might be happening that I'll pursue. If It was JUST that the clips were playing slightly fast, I'd think it might be a quick and easy fix, but that short first frame has me concerned. I think this may take a bit to completely sort out.
Part of the issue, as I said, is that image sequence videos really weren't ever expected to be used this way. What I think we probably expected people to do in creating slideshows was the same process you can use as a workaround until this is fixed:
10:00 seconds to 1:00.OpenShot will lay out all of your images as 1-second-long clips at the project frame rate, exactly as you were trying to do with the sequence. It is a little harder to work with them like that since the images are all separate clips and can't easily be shifted around on the timeline as a single clip, but on the bright side it should actually export quicker because the export process doesn't have to do all of that frame-rate scaling (which is time-consuming even when it ISN'T completely botching it).
Meanwhile, I'll report back if I make any headway on the frame-mapping issues.
rexdk
commented
4 years ago @ferdnyc Ah, great - that sounds hopeful. The two frame rates were: 30/sec - the project rate, unchanged and 1/sec - simply for testing to make sure that it's not just a single frame that is getting missed.
At 30/sec you can still step through the frames using the arrow keys - it's just I thought a different frame rate would be a good test - more obvious. Obviously not, though it does seem to have uncovered something.
Presumably the FrameMapper still comes into play even if the rate is unchanged?
I've no need myself for 1/sec (as you say, that's a slideshow - and I did test that too to make sure the images were OK), but my original need was actually for about 8 a second, for a flash effect.
rexdk
commented
4 years ago @ferdnyc Docking windows: Win10 allows you to drag windows off screen, as long as there's still a bit visible. And with the docking OpenShot preview window, it can be dragged left and right off screeen (at least partially) - and will dock like that; but it cannot be dragged up and down off screeen. Oh joy ;).
Yes, the float icon does not appear when the window is floating, but a double click in the title bar unfloats it. Actually even the close icon is missing until the window receives focus.
It's years since I looked at Qt, but there appears to be a QDockWidget::setTitleBarWidget, which might, just might, allow the default Win10 behaviour to be overridden?
I've found it a rather difficult feature to use anyway, because every time the window is dragged it wants to dock somewhere. It might help in seeing a larger preview, but you'd almost certainly need to keep swapping to the main window to move the playhead - not currently possible on Win10 at least. But there's a good way, which is to simply double click the title bar, use the main window and then float the preview again - it actually works quite well, because the preview size and location is remembered.
I'm learning quite a l,ot here - thank you :)
ferdnyc
commented
4 years ago @ferdnyc Ah, great - that sounds hopeful.
Presumably the FrameMapper still comes into play even if the rate is unchanged?
Mmm, well... don't take this as definitive, but I believe the answer is, "Yes, but not if the input rate is the same as the project/export rate."
And therein lies the rub.
Part of the bug here, I think, is in how we're importing image sequence data — and the fact that we're assigning the wrong frame rate.
When we import an image sequence into OpenShot via discovery on one of its component frames, the initial file import is done on a single image file. That causes it to initially present as a QtImageReader-supported media file, a still image clip. Later, when we determine it's actually one frame of a sequence, we load in some of the image sequence details real quick, sloppily paint over pieces of the QtImageReader data with them, and call it a day.
Turns out, that's... well, there have been better ideas.
When an actual image sequence is loaded (and in fact, when the image sequence in question is loaded for preview or export), it goes through an FFmpegReader instead, and will have very different parameters. In particular, while QtImageReader assigns 30 fps as the frame rate for all of its generated media, FFmpegReader always imports image sequences at 25 fps. Thus is an oddity I discovered quite some time ago finally explained, though the explanation sucks.
(And, it would certainly be fair to wonder: Why in the wide world of sports do two of our readers, both of which impose arbitrary frame rates on their input, arbitrarily impose DIFFERENT arbitrary frame rates? I wonder that myself.)
So, long story short, the fact that we're importing an image sequence and treating it as if it's 30 fps, even though when libopenshot performs the export it will be reading that same data at 25 fps, is very much the source of at least a big part of this bug.
It may even be the source of all of it — the interplays are confusing enough that I'm not even going to waste time trying to puzzle out whether the mismatch in how OpenShot and libopenshot would be scaling frame rates would be enough to explain the short first frame and all of the other weirdness.
So, I'm just going to fix the image sequence loading to use the right f!@$ing frame rate, instead. Once this problem is fixed, then I guess we'll find out whether or not there are even more bugs at play in this whole mess.
ferdnyc
commented
4 years ago (Now that I've finished self-censoring...)
Well, after a bunch of testing... now I have no idea what's going on.
I started out by rewriting the image sequence import code to discard the QtImageReader details and instead re-scan the sequence as an FFmpegReader video media file. That failed to fix the immediate issue. (So it appears the frame-rate mismatch is not, itself, actually any part of the problem.) However, it did expose a whole host of other problems. More on that in a second.
So, then I went back to reading the sequence as an image, but applying more of the details from the image-sequence import, including updates to the correct fps, duration, and video_timebase (which is basically just the inverse of the frame rate). With all of those things corrected, I got the image sequence to import at the correct length, but absolutely nothing changed with this issue. No matter what length, no matter what speed, my 25-frame sequence always had a half-duration first frame and stopped at frame 22.
ffmpeg on the command line:
ffmpeg -i "filename%02d.png" /tmp/filename.mp4
So, not only is this broken, it's either somehow been broken for nearly a year and a half (or more!), or something has changed on my system that fundamentally breaks all known versions of OpenShot, even previous ones.
Along the way, I discovered other fun things. For instance, our frame-rate changing is completely broken. It actually works fairly okay for image sequences, quite possibly owing to the exact weird, semi-video status I was trying to fix, but that seems to be more a lucky accident than anything else. But when you try to adjust the rate on an actual video (whether correctly-imported image sequence or a "real" video file, like that MP4 I made), then what happens is nothing even CLOSE to correct.
If I import a 25-frame video at 25 fps, it will be 1 second long, as expected.
If I then go into the File Properties and change the frame rate from 25:1 to 1:1, placing it on the timeline will result in a clip that's TEN MINUTES long. (For those playing along at home, the correct duration would be 25 seconds. Not 600 seconds.)
I mean, on the one hand I'm sort of glad that these aren't new bugs resulting from some recent botched change, but I simply can't fathom how they've existed this long and are only coming to light now. I keep thinking I must've messed something up in testing, but if I did I can't find it. And I've certainly run enough tests and had them all come out the same. To quote Montgomery Burns, "Are you sure you haven't just made thousands of mistakes?" ...Seems unlikely, but I guess you can never be sure.
So, yeah, suffice it to say this may take a bit more effort than expected to completely solve.
rexdk
commented
4 years ago Oh dear - very sorry! It doesn't surprise me that this has been wrong for a long time - I'm pretty sure that the more esoteric things in OpenShot rarely get used. In fact the user guide doesn't even cover image sequences, except to say: "For image sequences, you can also adjust the frame rate of the animation" - so you can only find out about it by chance.
That's re-affirms my view that the biggest single improvement to OpenShot would be to sort out the user guide - then people would understand and try out out these things, and bugs would be discovered, and could be fixed before we add yet more esoteric stuff. As I've experimented, to help with the user guide, I've found more than a dozen issues - I've lost count now.
The latest - which might actually be relevant here - is that using the cut tool on a clip crops off 2 frames. I'll check some more and raise a separate issue if necessary. But as you're losing frames here it's worth mentioning, though probably a red herring.
Incidentally Jonathon's check schedule before releasing a new version has no mention of documentation at all. It's not even bottom of the list!
rexdk
commented
4 years ago @ferdnyc going back to: ffmpeg -i "filename%02d.png" /tmp/filename.mp4 I'm a bit out of my depth here, but the ffmpeg docs say: "For creating a video from many images: ffmpeg -f image2 -framerate 12 -i foo-%03d.jpeg -s WxH foo.avi" The options -f image2 -framerate 12 seem to be required - or maybe ffmpeg does its best without and gets it wrong
-s sets size and is presumably optional
That's just a thought - I'm not familiar with this. Feel free to ignore if it's not a help :)
ferdnyc
commented
4 years ago @rexdk Sorry for the delay, been buried in non-OpenShot things recently.
going back to: ffmpeg -i "filename%02d.png" /tmp/filename.mp4 I'm a bit out of my depth here, but the ffmpeg docs say: "For creating a video from many images: ffmpeg -f image2 -framerate 12 -i foo-%03d.jpeg -s WxH foo.avi" The options -f image2 -framerate 12 seem to be required - or maybe ffmpeg does its best without and gets it wrong
Yeah, command-line ffmpeg has evolved more and more sensible defaults / reasonable assumptions over the years, so that people aren't forced to write massive command lines for every operation. In particular, the -f flag is now documented to mean "force format" (emphasis mine), because typically it's pretty simple to autodetect it. ffmpeg gets it right here, and defaults to a frame rate of 25fps unless told otherwise.
More to the point, I know the ffmpeg encode was correct because I played it in VLC. :wink:
Backing up a bit...
It's years since I looked at Qt, but there appears to be a QDockWidget::setTitleBarWidget, which might, just might, allow the default Win10 behaviour to be overridden?
I won't pretend I've tried it (I didn't even have access to a Win10 system, until a month ago), but my gut says no. The setTitleBarWidget method can be used to customize the internal titlebar of a dock widget, the one that's shown when the widget is docked into the interface. (It's useful for people who need color-coded docks, or want to add additional controls for things like auto-placement or -sizing... things like that.)
The only reason I can imagine that Qt would have for showing the standard Windows titlebar on floating docks, rather than the custom one they've always used in the past, would be that Microsoft changed the window APIs to require it.
Hmm, yeah, from some more rooting around the internets it sounds like it has to do with making the floated docks draggable — I guess without a native titlebar, floating docks on Windows 10 can't be moved by dragging. There's been a bunch of back-and-forth on whether the floating docks should show their built-in titlebar in addition to (right below, IOW) the native titlebar, but it doesn't sound like the native decorations are going anywhere. Not if we want the floating docks to still be movable, anyway.
The latest - which might actually be relevant here - is that using the cut tool on a clip crops off 2 frames. I'll check some more and raise a separate issue if necessary. But as you're losing frames here it's worth mentioning, though probably a red herring.
See #3656 before you go too far down that road. The long and short of it is, a lot of this can be dependent on frame rate — where you're seeing two frames cut off for your combination of source videos and project rates, that may be the result of an adjustment made because someone else with a different combination reported frame duplication. There are a lot of things in the code that were done as reactions to prior bug reports, and did solve things for that case — but potentially at the expense of other scenarios.
In the end, it comes down to the fact that compressed video encoded in consumer formats isn't and can't ever be manipulated with perfect frame accuracy, and trying to force it to conform anyway can do more harm than good to the overall predictability and reliability of the code. I have no good solutions to offer on that front, I'm afraid.
But I'm with you on the documentation. For the most part, anyway. As far as image sequences, specifically, I still hate the feature, always have, so I figure the less documented it is and the fewer people who know about it, the better. (Though, of course, the import message popping up out of the blue offering to make use of said feature don't help none...)
stale[bot]
commented
3 years ago Thank you so much for submitting an issue to help improve OpenShot Video Editor. We are sorry about this, but this particular issue has gone unnoticed for quite some time. To help keep the OpenShot GitHub Issue Tracker organized and focused, we must ensure that every issue is correctly labelled and triaged, to get the proper attention.
This issue will be closed, as it meets the following criteria:
We'd like to ask you to help us out and determine whether this issue should be reopened.
Thanks again for your help!
rexdk
commented
3 years ago This is still a bug in a daily build I downloaded on 29Jan21
discgolfer5000
commented
3 years ago This issue happens to me also with OpenShot versions 2.5.1 and 2.6.0 on Windows 10. I've done complete uninstalls and manual file removals.
The last 8 frames are static in the OpenShot preview, scrubbing frame by frame, and in the exported video, but not in the source clip or frames.
It happens whether I import my source clip as an mp4, mkv, or a png image sequence of 120 frames.
I tried a different free and open source video editor and the same clips/frames worked fine there, so the issue is within OpenShot.
Issues #2435, #2609, #3585, #4032 all appear to be the same, some of which have auto-closed while unresolved.
Describe the bug: When I import my sequence of 9 images only the first two frames are used, the rest is just a copy of the second. Steps to reproduce the behavior:
Expected behavior: The animation should consist of all frames.
System Details:
.openshot_qt.zip