Closed easy-and-simple closed 4 years ago
NVIDIA not supported right now: https://github.com/OpenShot/openshot-qt/issues/3414#issuecomment-622939444
as for the
Closes on try to open options...
Application crashes in Quick Sync encoder test. Try to exclude the crashed test from the list, (by modifying the preferences.py file) like in: https://github.com/OpenShot/openshot-qt/issues/3276#issuecomment-595052453
Can you say what Intel's GPU driver version you are using?
I installed latest Intel drivers but nothing changed so driver version not matter Intel video is HD4000 and Nvidia video is GTX750TI, but this also can't be problem because ffmpeg and supports HW acceleration for both cards, and Handbrake is working well on both of them
It looks like FFmpeg (the OpenShot uses) is compiled with use of DCH drivers (available for newer Intel devices for win10 only). As soon as this program is only port to Windows, do not expect that HW acceleration will start to work. Also, currently, OpenShot's renderer depends a lot on RAM operations, so any HW encoding will be not very effective. This wouldn't be changed any time soon. Please, look for other solutions.
All shows that you have no any idea what you are doing! 1 DCH driver At first latest Windows 10 driver for my Intel is from 3/25/2020 At second: What is the difference between NVIDIA Standard and DCH Display Drivers? Functionally, there is no difference between NVIDIA’s Standard and DCH drivers. While the base core component files remain the same, the way DCH drivers are packaged and installed differs from previous (Standard) drivers. When directly comparing the two driver types, the DCH driver package has a smaller size and a faster installation time than the Standard package
2. FFMPEG ffmpeg need correct command line options or parameters in order to activate HW accelerated encoding. There is good guides and info on Nvidia website about how to use ffmpeg, where everything is explained quite simple and clear, as well on ffmpeg website.
3.RAM I have 8GB RAM free when windows fully loads so I dont think this could be any issue, especially for my short simple videos
Porting Porting means to make it working and not just to copy all as is in original
I already told you that everything on my machine is working well, including HW accelerated video encoding and decoding so don't try to tell me that problem is in me please
The problem that you attempting to use port from Linux an claiming that it should work as native Windows application. It wouldn't work this way. I posted link to the similar issue, and by following linked threads you may find roots of the issue and why new FFmpeg may fail for non-DCH drivers from Intel when used in OpenShot.
I cited you Nvidia that say there is no any difference between DCH and standard drivers and you continue to say that problem is in drivers. Problem is in you because you have not ported anything. Porting means to make it working on other platform, something that you didn't done, because it is not working on windows I told you that I am using latest Intel video drivers for windows 10 from 3/25/2020, so issue is not in driver or my computer and configuration You still didn't read information on ffmpeg website where in tables is displayed HW support for intel, nvidia and amd for different platforms You have included in openshot some old and restricted version of ffmpeg and expect that something will work? Your copy of ffmpeg is twice smaller in size because it is obviously build without any HW support
I cited you Nvidia that say there is no any difference between DCH and standard drivers and you continue to say that problem is in drivers...
You may re-read the post written above yours. You altering words for no reason. I gave your the link to simple workaround that make it possible to run Preferences window of the current build of OpenShot. You may use it or choose other software.
I don't have Intel in my PC and OpenShot just works with SW only decoding/encoding. If you can - do it, do it better: https://github.com/OpenShot/libopenshot/pulls it's open source.
I see you dont have Intel and on your computer openshot is running all by software, so no one must run it in HW right?! I dont need your dumb workaround for preferences because there is no any thing I need to change excep HW support that is not working Look moron why then you moved my thread and replayed to my bug report if you are such dumb idiot?! Now normal guys will not help me because they think you loser have helped me Stupid morons if you can't do something don;t do it! Delete your useless garbage openshit and go to clean toilets
It is not only because of you. Other users may find this thread and thus can try available workarounds too (at least known workarounds).
Your workaround is useless if there is nothing to change in preferences!!! Also it is too dumb because I just disabled Intel video adapter in device manager and didn't editen anything so it is useless for me too And I will not edit your code because it is real garbage that need to be rewritten from scratch. With such garbage code it is not possible to have stable version without a lot of bugs
with your restricted ffmpeg build, nothing works I copied normal ffmpeg build and nvenc option appeared in export menu but your garbage code give error message that cant create frame for export
Release libs can't be substituted with different ones. Instead you may try different builds for example: https://ci.appveyor.com/api/buildjobs/8m3cpyr4b8cneopa/artifacts/OpenShot-v2.1.0-1512-gb7a95d21-win-x64-N497.7z (v4.2 of FFmpeg) I did it for my own test purposes. Link will not be valid for long...
Is it crashes for open Preferences window?
Yes it crashes with same messages version:ERROR Failed to get version from: http://www.openshot.org/version/json/ ui_util:INFO Initializing UI for dlgPreferences preferences:WARNING CheckPixel failed testing hardware decoding in preferences (i.e. wrong color found): 3-0 preferences:WARNING CheckPixel failed testing hardware decoding in preferences (i.e. wrong color found): 3-1 preferences:WARNING CheckPixel failed testing hardware decoding in preferences (i.e. wrong color found): 4-0 preferences:WARNING CheckPixel failed testing hardware decoding in preferences (i.e. wrong color found): 4-1
But in this build is working Nvidia export in addition to QSV export]If I disable intel gpu preferences opens but hw acceleration is not available GPU load with nvenc is between 18-21% In QSV export GPU power is 2W compared with 6W when I use handbrake
For future - do not use everyone's code. You don't know what it may contain.
I hope, that CRC of the 7z archive above is MD5:DC73ED1D4D47515B3C2B5763209C5F14
(about 102MB).
And how to check MD5? 7zip have no such info Your build obviously changed something because after I ran it I found that if I disable intel video, then load openshot and open preferences, next I can enable again intel video and preferences continue to open again until I close openshot Also I copied ffmepg codecs from your build in my openshot installation and now nvenc export is working with installed version too
This new behaviour of preferences dialog results in new log info
ui_util:INFO Initializing UI for dlgPreferences
preferences:WARNING CheckPixel failed testing hardware decoding in preferences (i.e. wrong color found): 2-0 preferences:WARNING CheckPixel failed testing hardware decoding in preferences (i.e. wrong color found): 2-1 preferences:WARNING CheckPixel failed testing hardware decoding in preferences (i.e. wrong color found): 3-0 preferences:WARNING CheckPixel failed testing hardware decoding in preferences (i.e. wrong color found): 3-1 preferences:WARNING CheckPixel failed testing hardware decoding in preferences (i.e. wrong color found): 4-0 preferences:WARNING CheckPixel failed testing hardware decoding in preferences (i.e. wrong color found): 4-1 preferences:WARNING Exception trying to test hardware decoding in preferences (this is expected): 7-0 preferences:WARNING Exception trying to test hardware decoding in preferences (this is expected): 7-1 main_window:INFO Preferences add cancelled ui_util:INFO Initializing UI for dlgPreferences main_window:INFO Preferences add cancelled
And how to check MD5?..
Usually, I'm checking CRC by QuickHash GUI application.
Release libs can't be substituted with different ones. Instead you may try different builds for example: https://ci.appveyor.com/api/buildjobs/8m3cpyr4b8cneopa/artifacts/OpenShot-v2.1.0-1512-gb7a95d21-win-x64-N497.7z (v4.2 of FFmpeg) I did it for my own test purposes. Link will not be valid for long...
Thank you, I tried it too: CMD: certutil -hashfile "OpenShot-v2.1.0-1512-gb7a95d21-win-x64-N497_SuslikV_v4.2 of FFmpeg.7z" MD5 MD5 hash of OpenShot-v2.1.0-1512-gb7a95d21-win-x64-N497_SuslikV_v4.2 of FFmpeg.7z: dc73ed1d4d47515b3c2b5763209c5f14 From the build number, this is an old 2.1 version of Openshot?
Shows NVENC (MP4, H264) and QVS (MP4 H264) for me too, no crashes yet - mind you I have not tried to encode anything. It is not showing H265 or others. (Still no decoders either) However, it shows NVENC regardless of the machine having an Nvidia card!
Win10x64 i3 M350, Radeon 5145 (=4000 series! , drivers barely supported under Win10) Win10x64 i7-9750H Intel UHD graphics 630 + NVidia RTX 2060
From the build number, this is an old 2.1 version of Openshot...?
No. It is last tag that were added to the develop
branch of the original repository by developers.
The build is based on develop
branch sate Mar 27 2020. Some libs version are different (Qt, FFmpeg etc.).
...it shows NVENC regardless of the machine having an Nvidia card!
Yeah? I see it too, but does it matter? On my machine it fails to create device at start of the encoding (obviously, I don't have nor NVIDIA card nor NVENC in it).
@MBB232 So, you can run Preferences window without issues on both PCs? What device number is your Intel's card (0 or 1, 2, 3, probably, still may be seen in device manager, display adapter properties)?
I don't know if it matters, I'm not a programmer. I'm a tester and I'm trying to be as complete as I can be, to hopefully help solving the problem. I thought that the green color was supposed to be the indicator, and thus only show if it was supported? So I thought to mention it.
Indeed, no issues with preferences on either. (Actually, on the new laptop it hung once, but that was after I left it alone for a while, and maybe did not give it time to wake up from standby. I could not replicate it. Worked fine 6 times, before and after)
More oddness: on the new machine QSV works when running Openshot-qt-exe, (both your version and latest daily) but fails when running the Openshot-qt-cli.
On the old machine, neither QSV nor NVENC works. (as expected)
When encoding with NVENC, Openshot is recognized by the NVidia software (tray icon), and remains so till closed. CUDA use remained steady at 1%, others variated a bit.
I have to say that I do not really see what the big fuss about Hardware encoding is : all three methods toke about 10 minutes, and all created a file size that was almost 10 times as large as the original. None used anywhere near the maximum of any processing power. (Perhaps the bottleneck is my RAM, I have 16 GB but the Intel GPU seems to claim half even if it is not using it?)
Anyway, here are my logs. OpenClose is where I only tested opening the Preferences and then closed the program. Followed by the 3 runs of the different encoders. EndoderTest.txt
PS: Intel PCI bus 0 device 2 NVIDIA PCI slot 1 (PCI bus 1 device 0 function 0)
Old machine: Radeon PCI SLot 17 (PCI bus 1 Device 0 function 0)
MBB232 you couldn't be tester if you have 0 knowledge and logical thinking SuslikV you give him like for what? I am sure you not understand why opening options doesn't lead to application crash. This is irritating and because of that I will not tell you why opening options crashes application on my machine and all others except this guy. Keep thinking it is because drivers are non-DCH haha
you give him like for what?..
For answer about the device number and additional info.
@easy-and-simple, please be mindful that folks here are trying to help you. I get this sort of thing is frustrating, but "you couldn't be tester if you have 0 knowledge and logical thinking" is uncalled for. Please refrain from comments like that.
Thank you
ctsdownloads you are talking softly saying nonsenses! You think that "If you don't like it, go find other software" could be called help?! You not only didn't read all posts, but also you have no knowledges and logical thinking at all!!! Before to comment, learn basic things, as that if someone is reporting bug he/she is this one who is trying to help! In this case I have opened this bug reporting thread, therefore I am trying to help to these insolent and ungrateful "developers", that instead to try to fix bugs are sending me and all others that report bugs, to find other software, because they have no enough knowledge and can't do anything useful.
SuslikV you send all guys that are trying to help you reporting bugs, to find other software, but you give like to guy that gave you information that you didn't understand and therefore can't use it?! Instead to make him funny you at least could tell him that running openshot in 1 thread is not very good idea right? If this guy was user of my software as minimum I would ask him why he is set program to run in 1 thread mode and what is problem at all because for his hardware it is running too slowly, but you only can envy to people that have hardware better that yours
you send all guys that are trying to help you reporting bugs, to find other software, but you give like to guy that gave you information that you didn't understand and therefore can't use it?!..
you altering events.
About using other software: In cases when resolving the issue can take about 3-5+ years I recommended to use other program solutions. This was obvious. Right now main developer @jonoomph is busy. I'm not in direct contact with him. But it is seen form the PR list updates and recent changes (obvious mistakes and reversed order of forced pulls - when dependent code wasn't ready to use).
About threads number: Unfortunately, program uses slightly different approach to threads handling than most fastest programs do. Thus, changing threads number surely can affect performance (increasing and decreasing can boost performance - this should be tested individually).
I did some contributions to the code changes - this is all I can do right now. Some of my PR has conflicts with the recent changes, and upcoming code only worsens situation - I have different view on some functions. So, some changes are delayed until code finally takes its new shape...
About the issue itself: Known workaround for crash was mentioned above ( here - https://github.com/OpenShot/openshot-qt/issues/3439#issuecomment-623138391 ) If you have better one - you may share it too. For NVIDIA encoder usage - I don't know. I have no HW to test it. I said about this in - https://github.com/OpenShot/openshot-qt/issues/3439#issuecomment-625484645 and as was mentioned above - in official Windows builds of OpenShot it shouldn't work at all.
SuslikV, So you still can't understand that Nvidia issue is in codecs? And this after I told you that after I replaced codecs in Openshot that is installed with codecs from build you supplied above, installed version started to use Nvidia encoder? After all it is clear that you will never find why options are crashing on all others machines than machine of this "tester" guy MBB232, so I will need to tell you obvious things.
Reason openshot to crash and close when someone with integrated Intel video tries to open options is obviously because intel video is not connected to display/monitor. This is case where display is connected to discrete video card and Intel integrated video is not connected. From screenshots supplied by MBB232 is seen that Windows task manager is displaying 2 GPUs - 1 Nvidia, and 1 Intel that means both GPUs are connected to displays and therefore are fully active. If Video card is not connected to display it is not used and is not displayed in Windows task manager
@easy-and-simple it is good finding but none of the encoders should crash the program. Normal behavior is when encoder generates error and stops. Instead, it performs not allowed operation (like accessing not allowed area of memory). The issue is in the way all stuff is done and root lies in the change that was made in the Intel's API, I think. Related thread was closed because it was aimed to resolve linux sandboxing driver issue, but here is the link from that thread: https://software.intel.com/en-us/forums/media/topic/800921 to significant API change.
For example, in OBS Studio, where changes to custom implementation were made by people who knows Intel from inside, some fixes to QSV were complete not less than in 6 month (and was reverted number of times)...
If you have FFmpeg compiled with the --enable-libmfx
switch, then you can test (here is examples of usage: https://github.com/Intel-Media-SDK/MediaSDK/wiki/Build-and-use-ffmpeg-with-MediaSDK) how it works and how it detects devices during encoding on Windows. At least, it shouldn't crash during encoder initialization (no matter connected display to the GPU or not).
Edit: my bad, decoders... not encoders. But initialization process (where all fails) is the same.
Issue creator refused to listen to my warning about being respectful to those trying to help them. This issue is closed.
Matt
Describe the bug Closes on try to open options and nvidia video acceleration not detected
Steps to reproduce the behavior:
Expected behavior A clear and concise description of what you expected to happen.
System Details
Log Files
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.
At first I would like yo say that you are really dumb morons and because of that it is no wonder it is not working and issues are not reported and fixed yet Obviously both issues are related to hardware acceleration because when I try to open settings it is thinking long time and after that program just close In log I found these related lines ui_util:INFO Initializing UI for dlgPreferences preferences:WARNING CheckPixel failed testing hardware decoding in preferences (i.e. wrong color found): 3-0 preferences:WARNING CheckPixel failed testing hardware decoding in preferences (i.e. wrong color found): 3-1 preferences:WARNING CheckPixel failed testing hardware decoding in preferences (i.e. wrong color found): 4-0 preferences:WARNING CheckPixel failed testing hardware decoding in preferences (i.e. wrong color found): 4-1
When I open export dialog there is detected only Intel quick sync, but not Nvidia HW encoder, so I have just one option for quick sync and all other is handled by CPU. With Handbrake are working both Intel and Nvidia HW encoders so issue is not in my computer