I’m using the newest version - 16.08.12 as of writing - and I’ve noticed that the playback framerate for my videos is buttery smooth when I’m using the regular (windowed) preview from the project tab but if I use my external monitor Shotcut skips frames even though Realtime playback is disabled.
Video plays back perfectly fine if I’m previewing a source file; there’s no frameskipping at all when a “Source” is playing back on my external monitor, even if it’s the same clip I’ve got on my timeline.
For a little extra context: I’m running this on Ubuntu 16.04. GPU processing is enabled. I’ve got a six-core AMD cpu, 8 GB of RAM, a GTX 760 and everything is running on an SSD. I don’t experience this bug when using the fullscreen preview on other editors (Kdenlive, Flowblade, etc.)
Hi, thanks for your detailed report. It’s really easy to follow and I think I can reproduce it for you. Only thing is I don’t have the right adapter right now to set up an external monitor to test it. Right now I only have HDMI to DVI and I need one the other way around.
I’m going to go out and get one today and I’ll get back to you later.
Seems to be playing back fine on OSX for me. I don’t have any devices that run linux so I’m not sure if it could be exclusive to your system. As always there could be other factors at play too.
Sorry I couldn’t provide more help but good luck to you.
I tested it on Linux, and it is working fine for me. I assume you are using X Windows for the “external monitor” and not some Blackmagic Design SDI/HDMI peripheral. I too am using Ubuntu 16.04 with NVIDIA GT 440 GPU running nvidia driver. I used a special clip that has numbers and increments a horizontal bar across the screen to more easily observe drops, and I could not see it. However, what about something more hard and fast than viewing the video?
There are two places where video frames can drop - in the MLT engine and in the handoff from the engine to Shotcut. Today, only the dropping in the engine is logged (in debug mode, which is not available in release build). I added logging for the second spot for when realtime is turned off, and I still not get any dropping even when giving it a heavy workload. That is available outside debug mode and will be in the next version.
Oh, I just thought of a third spot - in the OpenGL repaints. I have seen a problem in OS X in this area that I had to workaround. It has something to do with Qt event (signal) processing. I suppose that could be the problem, but I’m not sure and not affected myself. Besides the solution for that was to intentionally limit the frequency of events, which reduces the viewable framerate to around 15 fps and would therefore incur frame-dropping rather defeating the purpose of non-realtime mode! (It is safe to say non-frame-dropping mode is actually broken on OS X simply to make video playback not entirely broken). I will have to revisit this after the Qt 5.6.1 upgrade, which is in progress.
