 |
Workaround and tooltip updated. |
 |
Thanks for the improvement. I find the help text useful. |
|
|
"A small improvement regarding the new option in the settings ...written the manufacturers in the yellow info text (if you move the mouse over the down arrow) or next to them, like for example: vdpau - Nvidia, Nouveau, Amdgpu vaapi - Broadcom, Intel HD graphics, Radeon" A tooltip on the down arrow as suggested has been added. As well as the option of "cuda - Nvidia + Cuda SDK" |
|
|
Thank you for the extensive information. I think it is well solved. A small improvement regarding the new option in the settings. The terms vdpau and vaapi will not mean anything to any normal user. Two weeks ago I also didn't know what these terms mean. I would have written the manufacturers in the yellow info text (if you move the mouse over the down arrow) or next to them, like for example: vdpau - Nvidia, Nouveau, Amdgpu vaapi - Broadcom, Intel HD graphics, Radeon Many new users will then automatically understand what it is about. |
|
|
A couple of days ago, the GIT checkin included the ability to workaround a recalcitrant file, like the m2ts file which came out black and the error retrieving data from the GPU message. These errors are more than inconvenient because they prevent usage of the GPU by the other video files for decoding/playing potential hardware acceleration. The CIN_HW_DEV environment variable is either all or none. With this latest mod, you can use the environment variable and it will be effective for all of the formats it is able to handle AND you can make an exception for a recalcitrant file that you want in your project. To do this you have to create a file in the same directory with the same name as the error-ing file with the different extension of .opts (along with your file.m2ts original media, you need a file called file.opts). The contents of this .opts file would just be the one line of: cin_hw_dev=none Conversely, if you have a bunch of files in your project, like dnxhd format, that are not hardware accelerated but you have an accompanying large file of type .mp4, you can leave the CIN_HW_DEV variable unset (i.e. do not use it) and just create an .opts file containing the line: cin_hw_dev=vdpau That test.mp4 with its test.opts side-kick will use the GPU for decoding/playing and the rest will not. This has some advantage because the ones that can not use the GPU, if the environment variable is enabled, there is a teeny bit of time used to check. I have yet to update the documentation. Also, there is a Settings->Preferences, Performance tab, "Use HW device" flag with a pulldown to set up "none, vdpau, or vaapi" its current purpose is for flexibility but there is a possibility that it might eventually take the place of CIN_HW_DEV but I am resisting. Precedence of these settings are: .opts is checked first so is of the highest priority environment variable is checked next preferences HW in use settings is lowest priority Also, now when you have this issue's error message of "error retrieving data from GPU to CPU", a popup will show this right in front of you on the cinelerra window so you do not have to go to look at the startup window to see why the video is black. That way is will be easy to see the problem, and quickly create an .opts file and reload just the one file. It is important to note that using the .opts file override the default ffmpeg/decode.opts file so you will most likely see more warnings (not really errors) in the startup window because the decode.opts file has "loglevel=fatal" and the default is "loglevel=error". You can also add the loglevel=fatal to your .opts file to avoid this. |
|
|
@Andrea: it is going to take me some time to understand what all of the error messages are -- ticket 201 terminal.txt is puzzling with its error message and then the "black" thumbnails and data. In your last note, the ones that work, but still put out messages if probably due to the "enhanced ffmpeg messages" that went in the last builds. These messages might just be what ffmpeg is reporting and Cinelerra is getting past anyway. @Both: the m2ts error message of "Error retrieving data from GPU to CPU" is definitely a problem, because you might have loaded 50 files successfully with VDPAU and now have only this 1 that can not be handled. GG is going to see if he can find a way that when just the 1 file does not work, an "opts" file can be created by the user and then it will load using software instead. The graphics card is what is coming back with a problem when it tries to "convert to vframe" and is can not do so. Have to find a good solution because some graphics cards might work and others not. |
 |
I confirm the issue but I don't understand the problem: it is varying from project to project (mp4 too). Project 1 (see ticket 201, message 1449): Error in terminal and error in displaying edit and thumbnails (mp4 too). Project 2: 4 mp4, single track ==> no error Project 3: 4 mp4 + 1 ProRes, single track ==> error for only ProRes; no error display. Project 4: 2 DV on 2 tracks + 4 audio tracks ==> error in terminal; no error display.
terminal-error.txt (5,368 bytes) |
|
|
5 tested m2ts files here will not use vdpau on my computer configuration. 5 other tested m2ts files here did load with vdpau and they were viewable and playable with this graphics board. When I uploaded the working m2ts to streamable.com, its makes it into an mp4 file instead and datahost.com is having its usual problams. More later. |
- Anonymous
