Video slows way down while exporting.
Describe the bug a 4 hour video took almost 24 hours to export. it was nothing more than clipping an 8 hour video in half and then saving. I also have a ton of glitches in the final videos where it looks like it speeds up, backs up, speeds up, then goes normally.
Steps to reproduce the behavior: open video clip the video keeping the 2nd half export watch it go from 30 frames a second to 3 frames.
Expected behavior not take 20 hours to export. One of the videos has the glitch right at the beginning: https://www.youtube.com/watch?v=QfQnISXpaG4
System Details
- OpenShot Version: 2.6.1-dev
- libopenshot Version: 0.2.7-dev
- Platform: Windows-10-10.0.19041
- Processor: AMD64 Family 23 Model 113 Stepping 0, AuthenticAMD
- Machine: AMD64
- Python version: 3.8.9
- Qt5 version: 5.15.2
- PyQt5 version: 5.15.4
- Qt Detected Languages: ['en-US']
- LANG Environment Variable:
- LOCALE Environment Variable:
- Daily Build: Verified issue still exists in daily build: http://github.com/OpenShot/openshot-qt/releases/download/OpenShot-v2.6.1-dev-daily-9604-5776efd7-46255e46-x86_64.exe
Log Files
- openshot-qt.log (66 KB)
- libopenshot.log (7 KB)
Exception / Stacktrace
No stacktrace found in log files
Screenshots (Optional) If applicable, add screenshots to help explain your problem. You can include screenshots by copy/pasting them on GitHub or dragging-and-dropping into the GitHub page. All images are public, so please don't post screenshots containing personal information.
Very odd. I've seen that kind of speed glitch when video files are missing packets, and OpenShot spends time looking for, and preparing the next frame, when there isn't one for several frames.
There's an improvement in testing right now that makes OpenShot smarter in how it handles missing frames, and may help the playback performance of this video.
I'll keep you posted on when that feature makes it into the daily builds. Until then, if you want to cut a small part of this video that has these errors, I can test it myself, and see if that improvement helps your problem.
it happens seconds into this video: https://www.youtube.com/watch?v=QfQnISXpaG4
On Tue, Aug 9, 2022 at 5:23 PM JacksonRG @.***> wrote:
Very odd. I've seen that kind of speed glitch when video files are missing packets, and OpenShot spends time looking for, and preparing the next frame, when there isn't one for several frames.
There's an improvement in testing right now that makes OpenShot smarter in how it handles missing frames, and may help the playback performance of this video.
I'll keep you posted on when that feature makes it into the daily builds. Until then, if you want to cut a small part of this video that has these errors, I can test it myself, and see if that improvement helps your problem.
— Reply to this email directly, view it on GitHub https://github.com/OpenShot/openshot-qt/issues/4885#issuecomment-1209909982, or unsubscribe https://github.com/notifications/unsubscribe-auth/AYLUWGEBKYEAIT3VBFGK4ITVYLD6FANCNFSM552RF2ZQ . You are receiving this because you authored the thread.Message ID: @.***>
As for the export time, re-encoding a video will always be more demanding than playing it, and this scales linearly with the length of the video. So while the missing frames code may help some, I also recommend exporting short tests at various resolutions, and quality settings. Then you can judge which settings give the best video quality with respect to the time commitment.
it happens seconds into this video: https://www.youtube.com/watch?v=QfQnISXpaG4 Right. The trouble is if I download that, I'll get the video that you exported from openshot. And openshot will have attempted to fill in frames where the source video didn't have them. (In my experience that's what causes the Sped up glitch that I'm seeing).
I was offering (assuming you're comfortable sending the source file) to test it with the new code, and see if that fixes anything. Otherwise, we can wait until that makes it to the Daily Build.
I would send the source file, but it's 20+GIG....
On Tue, Aug 9, 2022 at 5:45 PM JacksonRG @.***> wrote:
it happens seconds into this video: https://www.youtube.com/watch?v=QfQnISXpaG4 Right. The trouble is if I download that, I'll get the video that you exported from openshot. And openshot will have attempted to fill in frames where the source video didn't have them. (In my experience that's what causes the Sped up glitch that I'm seeing).
I was offering (assuming you're comfortable sending the source file) to test it with the new code, and see if that fixes anything. Otherwise, we can wait until that makes it to the Daily Build.
— Reply to this email directly, view it on GitHub https://github.com/OpenShot/openshot-qt/issues/4885#issuecomment-1209925313, or unsubscribe https://github.com/notifications/unsubscribe-auth/AYLUWGAF54ZYSKMYDHU4PD3VYLGOPANCNFSM552RF2ZQ . You are receiving this because you authored the thread.Message ID: @.***>
It seems there are some trouble in the "export option" Choosing profile in Simple Tab the Bitrate seems not correct when set High or Medium.
Example using a 1 minute video Tab Simple Profile = HD 1080p 50 fps Bitrate = High Result = 3,4 Gb Bitrate 397168 kbps KO
Tab Advanced Profile = HD 1080p 50 fps Bitrate = 15 Mb/sec Result = 132 Mb, Bitrate 15325 kbps OK
Tab Advanced Profile = HD 1080p 50 fps Bitrate = 15.00 Mb/sec (using decimals point like is set using "simple") Result = 3,4 Gb Bitrate 397168 kbps KO
Tab Advanced Profile = HD 1080p 50 fps Bitrate = 15,00 Mb/sec (using comma like decimal separator (like in Italy)) Result = 132 Mb, Bitrate 15325 kbps OK
It seems something wrong when Bitrate is written using the decimal point, in my case decimal separator is comma and it seems to work.
Additional consideration: a bitrate of 397168 kbps is really high; I think that also if the encoding is correct a video player could not be able to show it correctly...
Let me know if you can recreate the same test with the same result.... Regards Marco
@jonoomph Please review this (the comments from Bernx01) and see if it is something that needs to be addressed.